はてなキーワード: XORとは
新卒で入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェアを制作販売するソフトウェアハウスだった。
入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページの管理があった。主な業務は、ページの文章の更新と確認、誤字脱字の修正、古く間違ったHTMLの修正など。
会社のホームページには自社のサービスや製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションのセキュリティを勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)
http://tatsu-zine.com/books/sbcr-taiketekinimanabu
この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。
頭から読み進める。1章に用語の整理があるおかげでだいぶ理解しやすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。
なるほど、XSS(クロスサイト・スクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックスに入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社のホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テスト用サーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……
検索ワード: +----------------+ | | | 1 | | [ OK ] | +----------------+
なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性の修正の実習もできるな。
このようにして、徳丸本を読み進め、(テスト用サーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:
ショッピングシステムの中身が、フレームワークやライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性の修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダもエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。
これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性の始末書は、すべて現在の担当である自分が書くことになった。
自分が入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正し始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会とコードレビューとバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。
自分の作業はすべてgitで記録していたので、自分が担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験から、バージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。
こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さらに勉強し、3年目に入るころには情報セキュリティスペシャリスト試験に合格し、転職した。
Webサービスのセキュリティを勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験用環境のCDもついているので、A社でホームページを担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)
アホか
ついったーに送るにはいつか生のキーでXORしなきゃいけなくって、その時ダンプを取ったら丸見えだよ、っていう話だろ
だからこの作者が「プロテクト強化した(ドヤァ」とかやっても意味ないよ、と。
tweetdeckの中の人は多分それはわかっていてだから面倒なプロテクト(笑)はしなかったんだろうけど、もふったーの作者であるところのスーパーハカー様はなんか勘違いされているようですね
「プロテクトかけたアルゴリズムを実装したバージョンに差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。
動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアのリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。
だから、リバースエンジニアリングではいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。
この場合も同様だ。TwitterのGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。
OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。
HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))
ここで
である。
まずはこのあたりから攻めようと思った。SHA-1の計算にはいくつか特徴的な定数が使われるので、そこからSHA-1の計算に使われているであろう関数444190を特定する。この関数のエントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザで認証」ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。
CPU Disasm Address Hex dump Command Comments 00401311 |. 33F6 xor esi, esi 00401313 | 8D8C24 A40000 /lea ecx, [local.54] 0040131A |. 394C24 14 |cmp dword ptr ss:[local.90], ecx 0040131E |. 75 0E |jne short 0040132E 00401320 |. 3BF5 |cmp esi, ebp 00401322 |. 73 29 |jae short 0040134D 00401324 |. 0FB68434 A400 |movzx eax, byte ptr ss:[esi+esp+0A4] 0040132C |. EB 21 |jmp short 0040134F 0040132E | 3BF5 |cmp esi, ebp 00401330 |. 73 1B |jae short 0040134D 00401332 |. 8B5424 18 |mov edx, dword ptr ss:[local.89] 00401336 |. 52 |push edx ; /Arg1 = [LOCAL.89] 00401337 |. 8D8C24 FC0000 |lea ecx, [local.33] ; | 0040133E |. 8BD6 |mov edx, esi ; | 00401340 |. E8 CB4D0000 |call 00406110 ; \mofooter.00406110 00401345 |. 83C4 04 |add esp, 4 00401348 |. 0FB6C0 |movzx eax, al 0040134B |. EB 02 |jmp short 0040134F 0040134D | 33C0 |xor eax, eax 0040134F | 34 5C |xor al, 5C 00401351 |. 888434 B80000 |mov byte ptr ss:[esi+esp+0B8], al 00401358 |. 83C6 01 |add esi, 1 0040135B |. 83FE 40 |cmp esi, 40 0040135E |.^ 72 B3 \jb short 00401313 00401360 |. 895C24 3C mov dword ptr ss:[local.80], ebx
0040134F | 34 5C |xor al, 5C
が注意を引く。もしかしてこれはopadとのxorではないか?
00401351 |. 888434 B80000 |mov byte ptr ss:[esi+esp+0B8], al
はxorした結果を格納している。
先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。
Hex dump 64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F| 18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E| 05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C| 5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|
あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。
はてなは増田のスーパーpre記法で半角の<>が含まれていると投稿が出来ないのを早く直してください。
もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。
CPU Disasm Address Hex dump Command Comments 00401324 |. 8D4424 20 |lea eax, [local.102] 00401328 |. 50 |push eax ; /Arg1 = 00401329 |. E8 623A0400 |call 00444D90 ; \mofooter.00444D90
ここでeaxが指すメモリーを見ると以下のようになっている。
01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10| F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00| 40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57| 61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63| 79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36| 36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|
ほんと、そのへんが、プログラマの領域だと思う。
俺はそうは思わない
コンパイラの賢さを考えると、人間が注力すべきは、プログラム全体のアルゴリズムであって、姑息な最適化じゃない
コンパイラが出力するコードは、人間が書くコードよりも、圧倒的に賢い
まず、基本ブロックの入れ替えが起るような、大域的な最適化は、手じゃ絶対に無理
例えば Lazy Code Motion (PLDI '92) を手でできる人はいないだろうし
partial redundancy elimination が扱っている冗長性を理解している人すら、あまりいないだろう
それに、局所的な最適化でもコンパイラ(を書いた人)のほうが賢い(ハードウェアに詳しい)
ターゲットマシンが x86 で、レジスタを0で初期化するときに、gcc で最適化オプション付けると
xorl %eax, %eax
ってなるけど
subl %eax, %eax
でも
movl $0, %eax
でも無く、xor が一番速い理由を知ってるやつとか、なかなかいないだろう
数学用語として定着する前の日本語の「以上」「以下」には、等しいものを含まない用法もあったらしい。
つまり、古い用法では、以上は「より上」、以下は「より下」(つまり、未満だな)を意味することがあった。
「~より上でも下でもない」なら「~と等しい」で何もおかしいことはない。
古い用法が今でも慣用的に「以上でも以下でも無い」という言い回しに使われてるんだろう。
数学用語と日本語の日常的用法にズレがあるものとしては、たとえば「高々」「または」がある。
日本語の日常的用法の「または」は、ORよりはXOR演算に近い語感がある。数学ではORの意味で使うけど。
日本語の日常的用法の「高々」は、侮る意味が付加されていることが多い。数学では単に「~を超えることは無い」という意味に使う。
str.charCodeAt(0) + str.charCodeAt(str.length-1) (str.charCodeAt(0) + str.charCodeAt(str.length-1)) * str.length
while (*key != '\0') hashval += *key++;
do{ x = (x * 0x60 + *s - 0x20) % hashsize; }while(*++s);
/* ハッシュ値算出ルーチン */ /* 各文字コードを左に3シフトしたものでXORをとり、 */ /* ハッシュテーブルのサイズで割った余りを返す */ int HashCalc( SearchData ) char *SearchData; { int HashValue; for ( HashValue = 0 ; *SearchData != '\0' ; ) HashValue ^= (int)*SearchData++ << 3; return( HashValue % HASHSIZE ); }
最近Perl界隈ではMoose、MooseってなんかMooseってのが流行ってるらしい。
自分自身のブログでは、さもずっと前からMoose知ってたかのように振舞うために、増田で先に放出しておく。てへへ。
プログラマ層が限りなく低い増田にこんなこと書いてもだれも見てくれない気はするけど。
初めてのMoose - Mooseのすすめ - はてな#hide-k
meta object protocol について考えてみる - TokuLog 改めChumbyとどきました日記
YappoLogs: Moose のコードを探索して理解を深めた
Mooseってのは結局のところClass::MOPのラッパーみたいなもんだと。
で、Class::MOPってのは何だ?ってことだけど、メタなんとかプログラミング?え?プロトコル?まーどっちでもいい。
よくよく読んでいくとメタなんとかとか大層な名前が付いてるけど、結局のところPerlのpackageそのものの操作をオブジェクティブ扱えるようにしたものみたいだ。
つまりだな、例えばpackageに対して動的に(静的ではなく!)メソッドを追加したい場合、今までなら
package Foo; **Foo::method = sub { return 'hoge'; }; print Foo->method;
のように型グロブに関数のリファレンスを突っ込むということをしなければなかったが
use Class::MOP; my $class = Class::MOP::Class->create('Foo'); $class->add_method('method',sub { return 'hoge'; }); print Foo->method;
みたいな感じでかっこよく追加できるってわけさ。ま、これはほんの一例だけどな。(他にもメソッドを削除したりフックしたり色々できる。その辺は今回省略。)
本来なら「package Foo」とするところを「my $class = Class::MOP::Class->create('Foo');」と書ける。
これの何が良いのかというと、$classというオブジェクト経由でFooパッケージを色々操作できるところにつきる。
型グロブを使用したり「no (warnings|strict)」をしたりパッケージを操作する処理っていうのはPerlのキチャナイ構文が多かったのだが、Class::MOPのおかげでスッキリ綺麗に書けるようになったってこった。
で、次にMooseだが、これは結局のところClass::MOPのパッケージ管理の部分に+αしただけのラッパーだ。
でもその+αってのが結構凄かったりする。
もうこの辺の話はさんざん既出だが、例えばhasという関数を使ってアクセサや型定義が出来たり
package Foo; use Moose; has 'method' => ( is => 'rw', isa => 'Int' , default => '10' ); my $obj = Foo->new; print $obj->method; # 10 $obj->method(50); print $obj->method; # 50 $obj->method('hoge') # Int型じゃないのでエラー
Moose::Roleを使ってRubyのMixinみたいなことができたりする。
でも実はこれらの処理ってのは本当は別に凄くもなんとも無い。
アクセサ生成なんてClass::Accessorがあるし、関数の引数の型チェックなんてのもParams::Validate等昔から存在してるし、Mixinに関してはもともとPerlは多重継承できるので最初からできるし。
じゃあなんでみんなMoose、Moose言ってるのかっていうと、それはやはりClass::MOPの存在が大きいであろう。
綺麗且つ柔軟にパッケージの操作が出来るClass::MOPが土台にあって、今まで別々の役割として存在してきたモジュール達を統合し、よりわかりやすく、より柔軟に、そしてより強力なPerlのオブジェクト指向を構築できるようにした。それがMooseなのだ。
・・・しかし、小生。
Mooseについて調べていくうちに一つ残念に思ったことがある。
オブジェクトにメソッドを追加する機構がないのだ。
オブジェクトにメソッドを追加する、だ。パッケージにではなく、オブジェクトに、だ。
具体例をあげる。
package Foo; use Moose; my $obj = Foo->new; $obj->meta->add_method('hoge', sub { return 'hoge' }); print $obj->hoge; # hoge
ちなみに$obj->metaというのはFooパッケージを管理するClass::MOPへのアクセサだ。
ということは上記の処理はFooに対してhogeというメソッドを追加していることになる。
では次の例。
package Foo; use Moose; my $obj = Foo->new; $obj->meta->add_method('hoge', sub { return 'hoge' }); print $obj->hoge; # hoge my $obj_2 = Foo->new; print $obj_2->hoge; # hoge
$obj_2->hogeが呼べてしまうわけだ。
$obj->metaは結局のところFooパッケージなのだから、そこにメソッドを追加しているので当然の結果である。
$objだけにメソッドを追加することは、Mooseではできないのだ。
非常に残念である。ああ、残念だ。
・・・しかし、小生。
これでもプログラマの端くれである。こんなことでめげていてはMooserを名乗れないのである。(あ、MooserってのはMoose使いの人の俗称ね。今僕が考えたの)
なのでオブジェクトにメソッドを追加できるように拡張して見せよう。
package Foo; use Moose; use Class::Object; my $class_object = Class::Object->can('new'); override new => sub { ref($class_object->(shift))->SUPER::new(@_) }; my $obj = Foo->new; $obj->meta->add_method('hoge', sub { return 'hoge' }); print $obj->hoge; # hoge my $obj_2 = Foo->new; print $obj_2->hoge; # エラー
たった3行追加するだけで実現できる。さすがMoose。
ただし、Class::Objectを利用しているのでFoo->newで返ってくるパッケージがFoo::0といったようにFooではなくなってしまっているのでrefとかでパッケージ名の比較ができなくなってしまう問題が発生する。
でもこれも継承順をいじったりと本気で頑張れば、表向きに見せるパッケージ名をFooすることも可能だろう。
その添削の役目はどこかのハッカーに任せるとして、今日のところはこの辺で終了としたい。
Moooooooooooooose!と叫ぶのが流行ってるみたいなので、もっとも長くMooooooooooooooose!と叫んだ最初の男となるべく下記の処理を残しておく。
length q chdir uc and print chr ord uc q rmdir and do { print chr ord q xor x while $a++ < 0xffffffff } or print chr ord qw q sin q and print chr ord q ne sin and print chr hex length q q shift shmread bless q;