笑えない笑い話二種
いち
http://d.hatena.ne.jp/JavaBlack/20081111/p5
経由
http://d.hatena.ne.jp/masayang/20081111/1226429835
某大手SI業者にて働く知人は「この規模のプロジェクトなら、外注先の自殺率は○%だな」みたいな冗談だか本気だかわからないことを言ってたもんだ。
（≧∇≦）ぶぁっはっはっ！！
o(>▽<)o ウキャキャウキャキャ
o( (*^▽^*) )o ゲラゲラゲラ
（T-T)ノ＿彡☆ばんばん
………笑えねぇ orz
に
http://d.hatena.ne.jp/JavaBlack/20081111/p2
経由
http://business.nikkeibp.co.jp/article/person/20081027/175268/
番組を作れないテレビ局、プログラムが書けないIT企業──。
気がつけば、日本中が「正社員だけでは何もできない会社」だらけになった。
コスト削減を優先するあまり、多くの企業が陥った派遣・請負依存の構図。
偽装、捏造、不具合が頻発するのは他人任せの“抜け殻”正社員が増えたから。
非正社員の正社員化や高卒採用拡大の動きも、まだ付け焼き刃の域を出ない。
短絡的な外部依存が、どれだけ現場を退化させたか。
正社員のあなた、そしてあなたの会社は、それに気づいていますか。
え？
なにをおっさりますやら
そんなものは「にちじょうのよくあるふうけい」ぢゃぁないですか
どこでもいっしょですもの もーまんたいでございますわ〜っはっはっは………
ε-(ｰдｰ)ﾊｧ
validateとescapeは違う概念だと思うのだが…
先に。sanitizeについてはなんか定義が色々と怪しいので使いませんｗ
…とかいいつつ少しだけ書くと。
sanitizeって、基本的に「antidote(解毒)」って概念だと思うのですが。
問題は。現実の毒でもそうなのですが「実際の解毒法は毒の種類によって変わる」です。ゲームアイテムにあるような「毒消し草」は存在しないです。
ついでに「何を以て毒とするか」って定義も曖昧ですしね。人間に作用する毒が同じように鳥類に作用するとは限りません。
なので。
sanitizeという言葉は「概念」として用いる可能性はあったとしても「実装周り」に使える単語では、結局ないんじゃないかと思うです。
ついでに。sanitizeって単語、もう一つ「防毒*1」なのか「解毒*2」なのかも微妙ですしね。使われ方的に。
で、本題。
んと…セキュリティ系の文脈でよく出てくるのですが…もう一つ混ざってる気がしてならないvalidateとescape。
ちとこの概念をいい加減きちんと整理して使い分けたいなぁと思うです。
validateは「有効であるかどうかを検証する」という意味合いがあります。
例えば日本の郵便番号は、2008年現在とりあえず「アラビア数字で３桁と４桁」ってのが有効範囲なので。ここでアラビア数字以外の、例えばローマ数字を持ち込んだり英字をぶち込んだりすると、それは「無効(invalid)なデータ」って事になります。
誕生日であれば「日付が存在しうる月日」ですし。…これが年になると微妙なんですがね(苦笑
ここらあたり、いわゆる「valid(正統)な」データが判断しやすいところになります。
つぎに。
メールアドレス…の正当性(valid)を論じるのは大変に厄介である事は以前に何度か書いたのですが。
今回はまたちぃと別の切り口から。
んと。例えば hoge@foo.com ってのは、存在するかはともかくとして、とりあえずvalidなメアドです。
んで。
小美人＜hoge@foo.com＞(本当は半角)というアドレスもまた、これはちゃんとvalidなメアドになります。有効部分はhoge@foo.comだけですが。
さらに。
例えば「プログラムを語る掲示板」なんかだったりすると、当然ながら様々な文字が出てくるわけです。
とりあえず
string s = 'INSERT INTO bar(hogera,mugera) VALUES(?,?);';
なんて文字列を想定。
当然ながら掲示板ですし、データとしてはvalid。
ただ。
当然ながら。
HTMLに出力するときに、メールの＜＞はエスケープせにゃあきませんし、DBにぶち込む時に掲示板の’だの；だのはエスケープしなきゃ酷い事が起きます。
つまり、例題のデータのいくつかは「validではある」けれども「escape対象の文字を含みます」。
ここまでOKでしょうか？
さて。
まぁ結局のところ、発端は「“入力時のサニタイズ”やめれ」いう話からなのですが。
入力時のサニタイズ推奨派の皆様がいう単語の一つに「ちゃんとホワイトリストで云々間ぬん」とかいう発言があります。
ホワイトリストにせよブラックリストにせよ、基本的にこれらは「validate」というチェックに属するものになります。
つまり「ホワイトリストにあるもの以外をinvalidにするのか、ブラックリストに載っているものをinvalidにするのか」という感じですね。
一方で。セキュリティの文脈でXSSとかSQL-Injectionとかの文脈で語られるのは「エスケープ処理が出来ているか否か」という部分であります。
つまりですね。
エスケープ処理を論じるべきところで「ホワイトリスト云々」言われても「駄目だなぁ」と思ってしまうわけですよ。
validateは、もちろん「入力のタイミングで」チェックする事が可能です。なぜなら、validateは「そのデータ項目に紐付いた」属性だから。
でもescapeはそうじゃなくて。escapeは「出力先に紐付いた」属性を持っているので、だからこそ「出力先にあったescape方法が各種とりそろえられている」はず、なのです。
一番肝心なのは「validateとescapeは、意味も趣旨も全然違うんだ」ってところ。
この二つをまぜまぜすると…ちょっと危険な香りが漂います。
あなたは、ちゃんと使い分けて話ができますか？
「おまえが悪い」ネタ第二弾 orz
んと。ちと色々ありまして
- 現行本番のDBを色々したいってかとりあえず「ちと細工などしつつ」吸い上げたい
- 本番DBくん、ぶっちゃけ「uptimeとかすごい事になってる orz」
- 幸い、いくつか別マシンがある
って状況がお膳立てとしてありまして。
まぁ
って処理して、別マシンで安心して吸い上げを開始したです。
さて………日本語が全然吸い上がらない orz
具体的には。0x3fからなります、いわゆる？か連打されております。
実際に？であることは、
head 対象ファイル.sql | od -x | less
で確認してございます orz
で、調査。
んと…my.cnfが違う orz
コンソールに入りまして。statusっちゅ〜コマンドを叩くです。
で、一部抜き出し。
元DB
Server characterset: sjis
Db characterset: sjis
Client characterset: sjis
Conn. characterset: sjis
ぶち込んだ吸い上げ用DB
Server characterset: latin1
Db characterset: sjis
Client characterset: latin1
Conn. characterset: latin1
orz orz orz
いいぢゃん所詮バイナリデータなんだしなにもしねぇで素直にはき出してくれよ ；；
中でなにをどのように処理してるのかかなり不明ですが。
とりあえず「copyするならmy.cnfまで全部コピらないと駄目」というノウハウを「げっとだぜ〜」(号泣
アクセルとブレーキがそろってこその車なんだなぁと思うのですが
「あれやるなこれ危険」なブレーキだけでは車は1mmたりとも前に進まない。
イケイケどんどんでアクセル床まで踏みっぱなしだと、多分いろは坂あたりでどえりゃぁ事になる。
急がなきゃいけない時にはそれなりにアクセルも床まで踏み込めて。
でもちゃんと必要な時には、場合によってはフルブレーキかけることが出来て。
別に「ヒール・アンド・トウ」しろたぁ言わないけど。せめて「スロウインファストアウト」くらいは把握してようよ。
うちら、それで飯喰ってるんでしょ？ それでお金貰ってるんでしょ？
腕が知識が判断力がないのは。
無い事を理由に「ブレーキしかない」「アクセルしかない」車になるということは。
努力を成長を教育を学習を放棄しちゃうのは。
もちろん全てが十全に出来るわけではないけれども、「出来ないのが当たり前」って開き直っちゃうのは。
それらを肯定しちゃったらもはや詐欺と変わらないんじゃないかなぁと思うのですが。
どんなもんなんですかねぇ？
などとつらつら…かなりの猛毒を雑感ｗ
やっぱり怖いよ orz
元ネタはこちら。
IP制限は必要悪。
http://d.hatena.ne.jp/m_norii/20081106/1225981496
うんid:m_noriiさんが言っている事はすべてtrueだと思う。
つまり
- 本質的にはIP制限なんて無意味な「はず」なんだけど
- いわゆる簡単ログイン(契約者識別ID)が、特にPCブラウザとかだと極めて容易に偽装出来る
- から結果としてIP帯域を制限せざるを得ない
ただ。じゃぁ「IP制限によってとりあえずどうにかなるのか」といえば…
- そもIP制限そのものが「キャリアが明示的に未保証である」と明記している
- っつかその「IPを取得できるPage」がDNSポイゾニングとかであっというまにアタックNo1
- っつかrawパケットのfrom IPを書き換うわなにをするやめくぁｗせｄｒｆｔｇｙふじこｌｐ
わ〜いヽ（￣￣∇￣￣）ノ
なんていうか…相変わらずの八方ふさがり orz
かくして。
おまんま喰わにゃならんうちらとしては…
それらを必要悪と認識した上で、それが何故必要悪なのか、本来はどうあるべきなのか、それが何故今出来ないのかを理解すること。
また、そういうリスクのあるサービスを提供してるんだ、ということを経営層にもきちんと認識してもらうこと。
そして、大本である携帯キャリアにはもっと声をあげて、しかるべき機能をきちんと実装することを訴え続けること。
・・・が、良識ある携帯技術屋としては必要かなぁ。。。と考えた次第。
というあたりに帰結するわけですね。
っつか。
とりあえず書籍とかで胸はって「IP制限がセキュリティのためには必要」とか一言で片付けるのいい加減やめようよ orz
まぁまっすぐにぶっちゃけまして。この本とかなんですがね。…ネットで無駄に風評いいだけに*1、めっさ気になります orz
- 作者: 荒木稔
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2008/09/27
- メディア: 大型本
- 購入: 16人 クリック: 148回
- この商品を含むブログ (24件) を見る
一応念のため。絵文字その他、いわゆる携帯サイトを作る上でのノウハウ自体は色々ときちんとまとまってる…らしい。いくつかのサイトの記述を信用するのであれば。
おいちゃん的にはいくつかのソースコードとIP制限周りの話を立ち読みで斜めに見た瞬間にぶっちゃけ買う気が失せたので詳細は不明ですが orz
追記
んと…著者のBlogとかいうのがありまして。
http://ideaup.seesaa.net/article/108141154.html
7章にかいてある「かんたんログイン」に関する方法は、リクエストヘッダーなどを書き換えることにより、第三者がなりすましてログインされてしまう可能性があります。
そのため「かんたんログイン」を実装する際は、携帯キャリアゲートウェイのIPアドレスから来るアクセスのみに限定するように留意して実装してください。
ユーザーエージェントではなくIPアドレスで制限することで携帯電話本体からサイトにアクセスされていることを確認する事が出来ます。
IPアドレスからのアクセス制限の方法については、第3章に詳しく書かれておりますので、そちらをご参考にIPによる制限を実施して頂ければと思います。
携帯における「かんたんログイン」はそのままの使用ではセキュリティ上問題がありますので、対策をご理解の上ご使用くださいますようお願いします。
えと…だから「IP絞りゃいいってもんじゃなかんべ？」と思うのですが…
どうしてこう「バッドノウハウ」って速やかに広がるんですかねぇ？
*1:一部ではさんざこき下ろされてますが
