がるの健忘録 このページをアンテナに追加 RSSフィード

2011-10-16

[][][]XSSソースコードリトマス試験紙

いやまぁ何カ所かで偶然「ほぼ同じ話」をしていたので、ちと自分の脳内整理を兼ねて。

一言で結論を書くと「ようは割れ窓理論」って話です。


とりあえず、お題は「XSSは非常にまずい」と。

その辺の「おいちゃん的思考」を、だらりんこんと書いていきたいと思います。

…って、細かく書くとすげぇ長くなったので(文章支離滅裂になったので全部消したw)、割と端的に。


かみ砕いて。

セキュリティホールがある」ってのはまぁそもそもとして「知識不足の可能性」を疑うべきではあるのですが、まぁそのあたりは適宜「学んでいただく」として。

そこから先、少なくとも「実務」の場合、「costその他との天秤」が待っているですだよ。


えと…具体的に。

「そこそこしゃれになっていない」セキュリティホールがあると仮定します。

もしそれが「10分程度で修正可能」であれば、これをやらないケースというのは、あんまりないと思います(あんまり、の理由は後述)。

一方でそれが「2人月ほどかかる」となった場合、特に「おじぇじぇを握っている層」が難色を示す可能性が高いのは、まぁ社会人であれば容易に想像が付こうか、と。


ちなみに「10分程度で修正可能なのに修正をしないケース」というのが、これがまた実際にありまして。

これはおおよそ「問題を全く理解していない(知識不足)」にくわえて「ゴミのようなプライド(「修正しろ」と人に言われたので、技術レベル的に"出来てるつもり〜"な技術者のプライドが傷付いた)」というのが、おおよその構成要素かと思われます。


閑話休題


で、XSSなのですが。

じゃぁまぁ「発覚した」として、実際問題「どれくらいの作業量」で修正ができるのでしょうか?

ここで「井坂さん」と「路地さん」、「葉桜さん」にお話を伺ってみましょう(…夜中だからテンションが怪しいw)。


井坂さん:

そんなはずないのですが…ありゃ、エスケープ処理にミスがありますね。

エスケープしている箇所を書き直す程度ですので、テストをしたとしても…(1時間あれば終わりそうだから)半日くらいで終わると思いますよ?


路地さん:

そうなんですか?

えと…テンプレートに値をセットするのは、だいたい同じ箇所でやっているので…例外部分を洗い出すとして…多分、多めに見積もって一週間くらいだと思うのですが…


葉桜さん

イヤ正直無理ですよぶっちゃけ。

値のセットはソースコード中に散乱、部分的に「プログラムでエスケープ」してたり部分的に「テンプレート側でエスケープ」してたり、ばらんばらんなんで。

やってもいいですが…2〜3ヶ月は確実にかかりますよ?


…んで。

正直、「井坂さん」のところだと「XSSが見つかった → 直せ〜 → 直った〜」で片付いちゃうと思うんですよ。いやまぁ「気付いたら連絡してあげよう」とは思うのですが。

「路地さん」のところだと…軽く微妙かなぁ、と。ただまぁ一週間程度の工数であれば、なんだかんだ「ひねり出す」ところも多いかなぁ、と。

「葉桜さん」ところのレベルになると「XSSが見つかった? とりあえず個人情報は漏れないっぽい? ンじゃほっとけ」になること請け合い。…なにせ実例を何件も知ってますから orz


さらに、んで。

もちろん例外はあろうかと思うのですが。

上述、端的に言うと「随所に関所( http://d.hatena.ne.jp/gallu/20080225/p1 )」が出来ているかどうか、なんですが。

もうちょっと深読みをすると、現場のソースコードや、その前提になる設計が「びりほな設計/ソース」なのか「見るも無惨な設計もどき/駄ソース」なのか、ってのが、透けて見えてくるですよ。


そんなこんなを総合するとですね。

XSSは、いやその「セキュリティホール自体」、じゅ〜〜〜〜ぶんにまずいとは思うのですが。

別の角度として「XSSがたれ流れていて、かつ修正がままならないようなサイトのプログラムは、その中身、推して知るべし」ってなることが多いんですね。


なのでまぁ「XSSソースコードリトマス試験紙」と、そんな風においちゃんは思うわけですよ。

いやまぁ「おいちゃんが関わっていない」ものがどんな状態であっても、別段、目くじらを立てるようなもんじゃないとは思うんですがね B-p

2011-09-20

[][]パスワードの「hash化」の変わりに「暗号化」は使えないかなぁ?

先に結論。「面倒くさい」と思われます(笑


以下、思考過程を。


ものすごく大まかには「id + デリミタ + パスワード、の文字列を公開鍵暗号によって暗号化 & 秘密鍵は[完全に削除する | まったく物理的にも別な場所に保存しておく]」。

基本的には「id + デリミタ + パスワード、の文字列を公開鍵暗号によって暗号化」の部分が、hashと多分大体同じような効果を表すと予測。具体的には「人間が見ても元文字列がわからん程度にぐちゃぐちゃになっている」という条件を満たすと思われ。

hashの「非可逆性」については。「公開鍵暗号であること+秘密鍵をぽいぽいすること」で大体同じ程度の状況が作成可能(厳密には解読可能だけど…それについては「十分な暗号強度がある」ことで等価とみなす、ってあたりでごかんべんを)。


そうすると後は、「id + デリミタ + パスワード、の文字列を公開鍵暗号によって暗号化」を複数回やることでストレッチすればよいか、と。具体的には「パスワード」のところが「暗号文」になる、と思われ。

一応、暗号文の長さで「ある程度、元文字列の長さの予測」が出来るんだけど、その辺は「一定length以下なら、適当にパディングする」とかいうギミックでバミることが出来るので、無問題


っちゅわけで…大体「hashと同等程度と思われる」機構は組み上げられるのですが…いかんせん、文字列がすんげぇ長くなりそうだし(ストレッチのたんびにIV入るしなぁ…二回目以降はなしでもいい気もするが)。

同等なら、「素直にhashでストレッチ」したほうが、間違いなく、楽(笑


まぁ一応「秘密鍵の保存に気をつける」前提で「本当にどうしようもなくいざとなったら暗号文字列の復元が可能」ってところが、状況と要求によっては「利点となる」可能性が、まったく0ではないと考えられるので。

そ〜ゆ〜「極めて稀なシチュエーション」においては、もしかすると、役に立つ、かも、しれない。


というわけで。

限りなく駄文なわけなのですが、せっかくなので、memo。

2011-03-23

[][]技術メモ:認証変

認証系を作り直しているので、備忘録兼ねて。


とりあえず

パスワードの持ち方を変えつつ

・セッションIDにmcryptを使わないように

してみやう。…いやmcryptは捨てがたいのだが(苦笑)、オプションとして。


パスワードの持ち方

以前はsha1でハッシュしていたのですが(何がしかの暗号ロジックを使うことも考えたのですが。… http://d.hatena.ne.jp/gallu/20060731/p3 うわぁ2006年って何年前よw)

ちょいと「一意じゃないお塩で味付け」しつつ「柔軟体操」をしてみようか、と。


・・明日に向かってその1:お塩

ソルト(salt)っていいますねぇ普通。

対象文字列の前後どっちかに(普通前かなぁ? あんまり後ろって見ないような…なんで?)、いらん文字列を付けます。この文字列が「お塩」。

うちでは「ユーザさんは固有のID持ってる」んで(普通そうか)、ユーザIDをお塩につかいます。

お塩で味付けをすると

→レインボーアタックが出来ない http://d.hatena.ne.jp/gallu/20071211/p1

というメリットがあり、またユーザごとに違うお塩にすると

→「同一パスワード」でも出力(保存される文字列)が異なるので、より推測がしにくい

なんてメリットもあります。


・・明日に向かってその2:柔軟体操

ストレッチいいます。上述の「お塩大作戦」だと、いわゆる「ブルートフォース(Brute Force:総当り/力ずく)」な攻撃には無力です。

なので、ストレッチっていう方法を使って「クラック時間を少し延ばします」。あくまで「少し延ばすだけ」なので、そんなに過信されてもまぁ困るのですが。

参考は…わかりやすいあたりですとこちら。

〜 ハワイより 〜 Mikeのプログラミング・メモ

http://blog.makotoishida.com/2011/03/blog-post.html

頑張って英文読むなら(…頑張らずに読めるようになりたいっていうかまず「ちゃんと読める」ようになりたい orz )

Key stretching

http://en.wikipedia.org/wiki/Key_strengthening


んで…ざっくりググってみたのですが…数千回程度から数万回程度まで、ちょいと幅がある感じですねぇ…どしよ?

とりあえずMagicWeaponでは、きりよく「65536」という数値にしてみます。…でも、ふつ〜のサーバでこれやって、150ms程度で処理がおわる orz 10倍くらいにしたほうがよいのかしらん?

ちょっとデフォルトの数値については、もう少し悩んでみまふ。


とまぁこんな思考過程を経て、「DBに保存するパスワード文字列」は、概ねこんな感じになります。

コードっぽい書き方してますが限りなく「嘘言語」なので、適当に脳内で補完してください。

なお、事前に、idとpassを、文字列で入手していると仮定します。

注:ストレッチ回数を微妙に「ぶらしている」理由は。記憶が定かではない「ストレッチ回数もユーザごとに可変なほうがより好ましいって誰かが言ってたような気がする」的記憶によります。理由が定かではないので削除ってもよいのですが、とりあえず書いてみると、是非のどちらに拠らず、なにか突っ込んでいただけるんじゃかなろうか、的な甘くて淡い期待を元に、残しておきます(笑

stretching_num = ( hash_md5(id) % 0xff ) + config(stretching_num, default:65536);

loop stretching_num
 pass = hash_sha512(id + pass);
pool

hashed_pass = pass;

後は、ここで書く内容でもないのですが「パスワード固定、IDをぶん回す系総当り攻撃」用のギミックも用意しておきたいなぁ、っと。

アラート鳴るだけでもなにか違うっしょ。たぶん。


おちゅぎ。セッションID。

セッションIDのベースになるのは、MagicWeaponの中にある「トークナイザ」ってやつです。

この子は

・現在のエポック秒

・現在のミリ秒

・現在のプロセスID

・乱数

から、概ね「一意な文字列」を作り出します。その気になると「自分のIP」も足せるので、並列させてもまずもって一意なんじゃなかろうか、と。

推測不能性については概ね「乱数」部分に頼ってる気がするので、今度この辺を「暗号学的に安全性の高い擬似乱数」に差し替える予定です。

…いつにしよう?


で。

いやまぁトークン自身が丈夫ならそれでいい気もするのですが、現在は

・セッションID(の前後にソルトぶち込んだ文字列)を暗号化(具体的にはRijndael 256)した文字列

を使ってます。

これだと、まず「Rijndael 256の解析コスト」があるので&セッションIDのデフォルト寿命が10分なので、比較的安全性は担保されるんじゃなかろうか、と。少し重いけど。


ただまぁ、PHPだとmcryptライブラリいれなきゃいけなくて、その辺で微妙に不評だったりもしたので。

ちと考えているのが

・セッションIDのベース(トークン)をsha512でハッシュした文字列

にしようかなぁ、とかも考えてます。

うちのトークナイザのトークンは多分レインボーテーブルには入れにくいのですが、一応「お塩&ストレッチ」は「オプション的に考慮」してみようかなぁ、とかなんとか。


こっちもなんか「ブルートフォース系」への対策をしておきたいような気がするのですが…DDoSまでを視野に入れたときに…どうしようかなぁ? と。

とりあえず「いい手があったらやる」程度に備忘録。


まぁ基本的に「ガチャコン構成(気に食わなかったら、インタフェースあわせた「別クラス」に差し替えられる構成)」にするつもりなので。

「まずいってわかったらその時点で改修すりゃいいや」的に楽観視はしているのですが。

# きっと親切な おもひかね が突っ込んでくれるって信じてる。


以上、明らかにメモ(笑

2010-01-18

[][]NTT研究所の「素因数分解問題」をうけて

暗号強度の一つの根拠である「素因数分解問題」で、いやんなニュースが出回りました。

まぁ、冷静に考えてこのあたり「いつか出る"可能性"」は、いつも想定していないといかんわけで。

基本的には

・ある程度細かい周期で定期的に鍵を入れ替える

・ある程度大きな周期で「暗号」自体を入れ替える

の2つを模索する必要があるわけですな、きっと。

へいへいほ〜 へいへいほ〜 ♪*1


相も変わらずWebアプリケーションを基準に想定。

例えば「DBにぶち込んでいる情報」を暗号化するケースは、もちろん「あり得ない」わけではないのですが、通常、やらんとです*2

多分、一番「やる」のはっていうかより正確には「やっている」のは、認証(authorization)における「セッションID」の暗号化です。

…このパターンだと。うちのデフォのセッションIDの寿命は10分なので「10分を超えるシステムメンテナンス」一回発生させれば、とりあえず普通に「鍵交換」だけで片付くなぁ。


いやまぁそこで片付けると終わっちゃうから。


えと…雑な発想。

鍵の入れ替えがあったとして、ある一定期間「新旧(いやべつにn世代前まででもよいですが)」の鍵で複合化してみるです。

で、平文に「明示的になんか印」を入れておいて。印が出てきたら「鍵あってたんぢゃね?」的な方法とか。

やり口としては「乱雑きわまりない」と言い切ってもいいような方法ですが…多分けっこう楽だと思う。


もうちょいして、本格的にこのあたり実装するようになったら、あらためて考察&実験してみます。

*1:模索とよさくをかけてみました…って説明せにゃならんギャグ飛ばすな orz

*2:つまり、通常じゃないケースでやった事があるわけですが。おいといて。

2009-11-28

[]勘弁してくれ orz

JavaScriptからローカルファイルシステムへのアクセスを可能にするFile API、標準化へ一

http://slashdot.jp/it/09/11/27/0545257.shtml



大惨事が起きるであろうことは、予想がつく。

「どれくらい惨い」状況になるかが、想像できませぬ orz