セキュリティ

サニタイズとハンガリアンとヒューマンエラーとアスペクト指向

凪瀬 — Sun, 06 Jul 2008 18:34:00 GMT

このあたりの話題は、個々のプログラマに対して「気をつけろ」と注意喚起してもなくならない話題なのですが、その背景的な部分をば少し。

サニタイズは消毒足り得ない

sanitize = 「無害にする」、という英単語ですが、≒ sanitate 「消毒する」と紹介されることが多いですね。でも、この消毒という比喩は文学的ではあるけども、技術的には問題のある比喩に思います。 XSS(Cross Site Scripting、クロスサイトスクリプティング)への対処として言われることが多いですね。

現実の消毒というのは、過剰に繰り返しても問題はなく、消毒済みのものをそのままもう一度消毒しても構わない。なので、食品衛生的な現場では過剰なぐらいに「とりあえず消毒」というスタンスでやるわけです。

これに対しプログラム上やりたいことというのは「その場の文脈でメタ文字となる文字をエスケープすること」 ( 続・「サニタイズ言うなキャンペーン」とはより)なわけで、例えば対HTMLでのエスケープ処理として"&"といった記号を"&"と置き換えたりするような処理です。これは何度でも行える「消毒」ではなく、 正しい場所で一度きりしか実行してはいけない「変換処理」なんですよね。

しかし、プログラムにおけるエスケープは消毒とは違ってあくまで「変換処理」ですから、 正しい場所で一度だけ、しかも漏れなく行う必要がある。そして、その場所というのが、「HTMLを出力する場所全て」というどうやって網羅するんだよ、と言いたくなる広範な個所なのですね。

ハンガリアン記法

話は変わってハンガリアン記法。 Jittaさんの言う「型によるハンガリアン（システムハンガリアン）使うな」の話です。

Wikipediaでも見てもらうと掴めると思うのですが、"iWindowHeight"みたいに、変数名の頭に型を表現する情報を付加すると言う記法です。

この記法、Javaなどの強い型付けの言語の場合、プログラム上の「型」と変数名での「型」と冗長になるんですね。そしてプログラムでの「型」はコンパイル動作で機械的にチェックされるので型の相違などは検出・修正できるわけでバグとなっていつまでも残るようなことはないわけです。そして、この冗長を常に保つことの難しさというのが欠点として挙げられていて、メリットがないということが言われている。

ハンガリアン記法を保つためには、「全ての変数を宣言する箇所で」網羅的に命名を確認する必要があります。そしてソースコードを修正する際に「型を変更する全てのケース」で網羅的に変数の命名も直さなくてはならない。

ヒューマンエラー

例えば、小学生低学年向けの、算数のドリルをやるとしましょう。算数の足し算を延々とやるわけです。算数の足し算ぐらいは誰でもできますね。では、1万問のドリルで全問正解してください、と言われたら「そんなの簡単だよ」と言えるでしょうか？

これは単純で簡単な作業であっても、人間はなんらかの間違いを犯すと言うことです。「うっかりして」の「うっかり」なのです。

あなたがチームリーダーだとしましょう。10人のメンバー全員に1万問のドリルで全問正解させるにはどうしたらいいでしょうか？この「うっかり」に対して「気合いを入れて」とか「集中して」とか精神論を掲げても、確実性が上がるわけではありません。

俗にサニタイズと呼ばれる処理も、ハンガリアン記法も、原理を理解して対処することは難しくはない。 (いや、サニタイズ言うなキャンペーンはその原理の理解がされていないことを憂いてのキャンペーンだったか…) 算数ドリルのような話題です。ただし、その数がべらぼうで、「うっかり」間違えることもあるというものです。

10人分の計算ドリルをあなたが検算することで全問正解を目指すとしましょう。あなたは検算を間違えないでやりとおせるでしょうか？「うっかり」検算を間違えたりしないでしょうか？ XSSの話題というのはこの個々は簡単な作業なのだけども、漏れなく実施しそれを保証するのが難しいというところが本題です。そして一か所でも漏れがあるとそれでセキュリティホールになる可能性があるって言うんだから嫌になる。

ハンガリアンでもやはりきっちりと網羅して行うことの難しさというのがあって運用に堪えない。

こうした部分にはヒューマンエラーがするりと入り込んでくるので頭が痛い問題です。

アスペクト指向というパラダイム

拙稿アスペクト指向の概念でおおむね解説しているわけですが、アスペクト指向では「全てのXXに全部YYをする」という事象を扱います。これをアスペクト、「横断的関心事」と呼ぶわけです。上記、挙げてきた件を解決しようという試みなわけですね。

このアスペクト指向というのはOOP(オブジェクト指向プログラミング)の概念とぶつかるものではなく、相補的なものと言えます。

AOP(アスペクト指向プログラミング)に対応した言語では、関数のようなものを作って、この処理を「全てのXX」に差し挟む、ということが記述できます。この「全てのXX」という部分にOOPでのオブジェクトなどが用いられたりするわけです。

また、AOP対応言語でなくとも、設計のパラダイムとしてのアスペクト指向というのはあって、 OOPでのデザインパターンでProxyパターンというものがありますが、これは、 Proxyするオブジェクトで前後に処理を一律に差し挟むことを可能とする。アスペクト指向的な概念に対してOOPの枠内でできる対処法のひとつなんですね。

XSSに代表されるように、横断的関心事というのは人間の手作業ではヒューマンエラーとも密接に関わって非常に対処しにくい。 AOPはプログラミングのパラダイムとしてだけではなく、開発体制をいかに構築するか (私はこれをシステムを構築するプログラミングの仕事と類似する事項と思っています) という部分にも応用することができる。

日常の開発の中で、こうしたアスペクトを捉えて、それを一網打尽にするジョインポイントはどこか、そう考えると見えてくるものがいろいろあるのです。

OOPでシステム内のオブジェクトのアクセス権を管理する

凪瀬 — Tue, 13 May 2008 00:22:00 GMT

ちゃっぴさんのblogに変な返答をしてしまったので、言い出しっぺの法則に基づき、方法論を考えてみました。

テーマはあるWebアプリケーション(以下、システムと言う場合はアプリケーション全体を指す)があったとして、そのシステム全体でデータに対するアクセス権を管理するためにはどうしたらよいだろうか？です。 *1

ここではOOP(オブジェクト指向)でいうObject単位での権限管理を考えます。これらのObjectはRDBMSなどで管理されるような永続性のあるデータを想定しています。

ユーザの保有する権限の管理

例えば、システム内でプロジェクトを表現するクラスProjectがあったとして、参照、新規、更新、削除の４つの権限を持つとしましょう。さらに、Projectのインスタンス単体でこれらの権限が設定できるとしたならば、ユーザ側の情報に、どのProjectに対して何権限を持つのかの情報を持たなくてはなりません。

まず、権限の種別を表す列挙を用意します。

public enum AuthorityType { /** 参照権 */ SELECT, /** 登録権 */ INSERT, /** 更新権 */ UPDATE, /** 削除権 */ DELETE, }

そして、権限管理クラスでは対象となるオブジェクトのID・型とその権限を保持するようにします。今回は簡単のためIDによって対象データを特定する方式をとっています。 *2

一般的なWebシステムを想定するとすれば、このユーザの権限情報はセッションに保持されます。このオブジェクトをProjectオブジェクトを操作するたびに権限確認のために引き渡すのはデータの取り回しがあまりに大変なので HTTPの1リクエストごとに、1つのThreadが立てられることを利用してjava.lang.ThreadLocalにこの権限情報を格納して利用するとしましょう *3。 ThreadLocalはそのThread内だけをスコープとするグローバル変数のようなものとイメージしてもらうと大体当たっていると思います。

/** * ユーザが保持する権限を管理するクラス * ユーザ単位で1インスタンスが作られる。 */ public class AuthorityManager { /** ThreadLocalでThread内をスコープとするグローバル変数を作る */ private static ThreadLocal<AuthorityManager> manager = new ThreadLocal<AuthorityManager>(); private static final String SESSION_KEY = "AuthorityManager"; /** セッションから権限情報を取得してThreadLocalに設定する */ public static void initManager(HttpServletRequest request) { HttpSession session = request.getSession(); AuthorityManager auth = (AuthorityManager) session.getAttribute(SESSION_KEY); manager.set(auth); } /** ThreadLocalから権限情報を解放する */ public static void releseManager() { manager.remove(); } /** 保有権限のList */ private List<Tips> authList; static class Tips { /** 対象オブジェクトのID */ int id; /** 対象オブジェクトの型 */ Class objectType; /** 権限タイプ */ AuthorityType type; } }

/** * HTTPのリクエスト毎に権限情報を設定するFilter */ public class AuthorityInitFilter implements Filter { @Override public void init(FilterConfig config) throws ServletException {} @Override public void destroy() {} @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // 権限情報をThreadLocalに設定 HttpServletRequest httpRequest = (HttpServletRequest)request; AuthorityManager.initManager(httpRequest); try { // 実際のServletの処理 chain.doFilter(request, response); } finally { // 権限情報をThreadLocalから解放する AuthorityManager.releseManager(); } } }

実装は省いていますが、保有データからユーザ側に保有権限のListを持たせ、権限認証の際に割符のように操作対象となるオブジェクトと付き合わせようという思惑なのをイメージして頂けますでしょうか。

権限チェックを漏れがないように執り行う

さて、Thradにアクセス権限の情報を持ちました。あとは対象となるProjectオブジェクトから権限のある場合のみデータが参照できるように網羅しなくてはなりません。これは、Projectオブジェクトへのアクセス全てに対して 「権限チェックをし権限のないアクセスであれば例外を投げるという処理」 を差し挟むということですから、AOP(アスペクト指向)で言う「横断的関心事」となります。

さて、この横断的関心事ですが、AOP対応の言語であれば、言語機能を用いてウィービング (アスペクトはWeaving、縫い付けると表現します)すればよいのでしょうがご承知のとおりJavaはそうではないので、なんらかの手段を講じなければなりません。

ProjectオブジェクトがDIコンテナによって管理されている場合、DIコンテナのAOP機能でウィービングする手が使えるでしょう。 DIコンテナは現行の非AOPな言語でAOPを実践するための工夫と捉えることもできます。 *4

DIコンテナを用いていなくとも、Projectオブジェクトの取得する口が特定できるならそこを抑えてProxyを噛ませる手が使えます。 GoFデザインパターンのProxyパターンはOOPの範囲で出来るAOPへの対処法とも言えます *5 *6。

場合によってはダサいですがProxyクラスさえも用意せず、Projectオブジェクトの各メソッドに権限チェック処理を直接実装する手法を用います。横断的関心事を分離できていないわけですが、setter、getterなんぞそもそも処理が希薄なので割りきることもできることでしょう。

注意点として、Proxyパターンや、直接Projectオブジェクトに権限チェックを実装するような場合、メソッドの網羅は保証できません。なんせ、手で個別のメソッドに対応を差し挟むわけですから。機械的な網羅ではないのでヒューマンエラーで容易に漏れてしまいますし、なにより記述が面倒です…。もちろん、Projectクラス自体をアーキテクト管理下に置いて、勝手に改変されないような状況である必要があります。 *7

ここまですると、開発時に参照件のないProjectオブジェクトを取得して、その情報を参照しようとした時点で実行時例外を起こすことができるようになるわけです。もちろん、処理効率的にはよくないわけですが、セキュリティ的にはいくらかの安全性を担保できることでしょう。

まとめ

設計パラダイムとしては、まず該当オブジェクトへの操作に対する権限チェックをアスペクトとして捉える事。また、これをうまくウィービングして全ての参照/設定メソッドに網羅させること。

そして、処理の実行体であるThreadと、操作対象であるオブジェクト（上記例ではProjectオブジェクト）との間の権限確認を行います *8。

Threadを用いないでオブジェクトを操作することはできないですし、アスペクト指向によってオブジェクトに対するアクセス全てに権限確認処理をウィービングすることで、ヒューマンエラーによる誤操作をすべてはじき出すわけです。

また、悪意ある故意の操作に対しても処理をはじくことがある程度できます。もっともThreadの持つ権限管理データまで改ざんされるとアウトなわけですが…。

なお、ここで挙げた設計方法は、1案に過ぎません。よりよい方法論もあることでしょう。この方法論を試すのは自由にしていただいて構いませんが、私はこの設計方法を採用して発生したいかなる損失に対してもなんらの責任は負わないものとします。

注釈

*1元のコメントではシステムの範囲を誤解させてしまいました… orz

*2 RDBMSでのプライマリキーとなることも考慮してIDによって対象となるObjectを対応付けていますが、本当はProjectオブジェクトへの参照によって対応付けを行いたいところです。 Projectオブジェクトの数が限られ、システム全体で完全にキャッシュされるようなケースであれば容易でしょう。
全てキャッシュできるほどにProjectオブジェクトが少ないわけではないとすれば、 Projectオブジェクトの参照は同一に遅延ロードを実装する手法も考えられます。
なお、アクセス速度を考えるとListよりはMapなどの構造を取った方が適切でしょう。このあたりは実際のデータを鑑みて考慮する必要があります。

*3 ただし、通常ServletではThreadがプールされるため、HTTPのリクエストの処理開始で格納し、処理終了時には削除するようにしておかなければいけません。これはjavax.servlet.Filterで処理することで漏れなく確実な処理を行うことができます。

*4 アスペクトがDIのすべてとは言いませんが、AOP対応言語ではDIコンテナを使う意味があまりないはずです。 DIはコンストラクタに対するアスペクトとして実装することができてしまう。強いて言えば、設定ファイルを読み込んでリフレクションで設定を行うところが面倒なので、そのあたりをやってくれる程度には便利と思いますが。

*5 例えば、Projectオブジェクトを取得するためのサービスが限定されているようなケースでは、その出口を抑えて、GoFデザインパターンのProxyパターンを適用すればよいのです。 Proxyクラスの実装はProjectオブジェクトを継承し、全機能をProjectに委譲するようにしておきます。ただし、getterメソッド全てに参照件のチェックを差し挟むし、setter全てに更新件のチェックを差し挟むわけです。

*6 ProxyパターンでAOPをする場合の最大の障壁は、オブジェクトの生成箇所をどのようにして抑えるかという点。 new演算子で生成されると手の打ちようがありません。生成に関するデザインパターンなどを用いて、オブジェクトの生成部を一元管理できているようなケースではどうにかなります。 DIコンテナも生成をDIコンテナが一身に背負うことでProxyパターンによるAOPを成し遂げているわけです。

*7 変更する人が状況をよく理解している少数であったとしても、修正に際してAOPの対応漏れは容易に発生します。誰もが変更できる状況下では維持するためのコストは膨大になることでしょう。

*8 1Threadあたり1Userという状況下である必要があります。世の中にはあるいは1Threadあたり複数userとなるシステムもあるかもしれませんが、そういうケースではこの手法ではうまくいかないことになってしまいます。

Gmail遮断の動き

凪瀬 — Wed, 09 Apr 2008 12:50:00 GMT

はてながCAPTCHAの費用対効果で見落としていることでは、あまりにお粗末なものを飾っておくのは、ブランドイメージがあまりに悪くならないかい？という話でした。

このエントリでは、そもそものCAPTCHAという手法の良し悪しについては語っていませんでしたが、本気で取り掛かられると破れるがスクリプトキディ避けにはなるという程度のものというのが一般的な技術者的評価でしょう。

少し古いですが変形文字「CAPTCHA」はもう無意味？というニュースが2008年02月27日に報じられていました。

このニュースの続報といいますか、影響と思われるニュースが出ています。
2008年2月はGoogle発のスパムメールが倍増、CAPTCHAが破られた可能性も～米MessegeLabs調べ
 大手プロバイダーが相次いでGmailからのメールを遮断、Gmail発のスパムメールが急増

GoogleのCAPTCHAの強度

そもそもCAPTCHを破る需要は結構あるらしく、サイボウズラボの秋元さんが CAPTCHA解読ソフトの価格表に見るCAPTCHAのレベル差という非常に興味深い記事を書いていました。

この記事、2007年11月22日なのだけど、

表によれば、Googleやhotmail、YahooのCAPTCHAは、「たいへん読み取り困難」で、それらを50%以上正しく読み取れるようなツールの値段はついてない。たぶん現在研究中なのだろう。

とあり、強度が高いという評価だったのです。

CAPTCHAの強度についてははてなのCAPTCHAは簡単に破れるで取り上げたように

ちょっと古い記事になりますが、Radium Software DevelopmentにCAPTCHAの強度に関する記事「 Breaking CAPTCHAs with NNs 」がありました。

CAPTCHAをプログラムで破ろうとする場合、プログラムは二つの過程を経ることになります。それは、文字の分割と認識です。

まずは、個別の文字を切り分けなくてはなりません。それから、その個々の文字が何であるかを判別するのです。

先の記事によると、CAPTCHA破りにおいて難しいのは分割のほうであり、認識はさほど難しくないとあります。

という話で、GoogleのCAPTCHAは機械にとって難しい「分割」に注視しており、強度は高く、そして人には比較的読みやすいシンプルなものとなっていました。

CAPTCHAの質

CAPTCHAの質は2つの軸で評価されるのではないでしょうか。

機械にとって読み取りにくいこと（強度）
人間にとって読み取りやすいこと（対人でのストレスをどこまで軽減できるか）

人間にとっての読みやすい/読みにくいというものと、機械にとってのそれは違うものだから、そこを利用して人間にとっては読みやすく、機械にとっては読みにくいものがよいわけです。

その点で、GoogleのCAPTCHAは評価が高い。

CAPTCHAに求められる役割

さて、CAPTCHAの役割は逆チューリングテストであって、機械による処理をさせないことにあります。なぜ機械に処理させないかということになると、

機械処理による大規模な荒らし行為を防ぐため
機械処理による大量のアカウント登録といった不正利用を防ぐため
機械処理によるパスワードのブルートフォースアタックといった攻撃を防ぐため( 飾りじゃないのよCAPTCHAは～前代未聞のCAPTCHAもどき参照)

などなど。

もっとも、逆チューリングテストに完璧なものはないことでしょう。技術の進歩とともに、人間が持つ認識能力は機械によっても実現されてきました。機械による大量処理を不効率にすることはできても、完全に機械処理を退けることはできないでしょう。

高木浩光氏が CAPTCHAのレベルはblog主が選択できるようblogサービスが提供してはどうかで以下のように書いています。

このようなやり方は、「spamするならうちより他へ行ったほうがいいよ」戦略であり、サイト横断的な無差別spamには通用する話であっても、何らかの原因で、ピンポイント爆撃の標的として狙いを定められてしまった場合には、通用しない。

Googleは言うまでもなく、世界の頂点に君臨する超メジャーサイトであり、あらゆる目的でspam行為の標的として狙いを定められている。だから、「うちより他へ」戦略は通用しないわけで、世界で最も高度なCAPTCHAを採用する以外にないわけだ。

どんな簡易なCAPTCHAでもスクリプトキディ避けぐらいにはなりますが、狙いを定めて攻撃されたのならば Googleといえども抜けられてしまうというこが今回実証された形になったわけですね。

逆チューリングテストはいつまで生き残るだろう？

ペンローズ卿の皇帝の新しい心という本で述べられているのですが、要するにゲーテルの不完全性定理による「証明も反証もできない命題」で、かつ、人間には証明可能な例を出すことで、人間の脳みそというのはチューリングマシン以上の何かだ、ということを言っているのでした。(この説は現在係争中)

私は強いAI論寄りの立場なので、アルゴリズムが十分に発達すれば人間の脳みそをシミュレーションして知能を、意識を作り出せると思っています。これは逆に「証明も反証もできない命題」は人間にも答えが出せないということになる。ペンローズ卿の例にはどこかにトリックが含まれているのではないかと思うわけです。

完全な逆チューリングテストというのはチューリングマシンで解けない（計算不可能）な問題を出す必要がある。しかし、人間もチューリングマシンなのだとしたら、人間さえもことごとく逆チューリングテストを越えられない。人間だけが答えられ、機械には決して答えられないという問題は論理的に存在しないことになりますから…。

人間がチューリング機械以上なのでなければ、機械だけを完全にはじく方法論は存在しないと言えましょう。（実際にそういう逆チューリングテストが存在したとして人間でも超えることが困難になるとは思うけども）

そうすると、人間に用意で機械に困難なことをテストとすることで、それが解決される未来までの間で比較的効率よく機械をはじくという妥協点を利用するしかない。

では、そのための問題となると、人間にはハードとしてビルドインされた機能があるのでそういった「人間には得意なこと」を用いようというアイデアが浮かぶわけです。

例えば人間の顔の判別。人間は生物として必要性から同種である人間の表情を非常によく読み取れる

しかし、近年、デジカメで笑顔を検出するなど、人間が持っている対人での顔判別・表情判別さえも機械で行えるようになってしまいました。 ( 富士フイルム、顔検出技術をWebアプリに　APIも公開)

こうした技術の進歩を見る限り、CAPTCHAも「あぁ、破られたか」と思うより仕方がない気もしますね。

*で隠されたパスワードがJavaScriptによって抜取られる

凪瀬 — Tue, 01 Apr 2008 00:28:00 GMT

アスタリスクで隠されたパスワードを確認する方法という記事が上がっています。

以下のJavaScriptをアドレスバーに入力すると、次のようなダイアログ内にパスワードが表示されます。

該当blogでは「便利」といった感想が書かれていますが、これは重大なセキュリティホールです。

例えば、以下のような、コードを書くと分かるのですが、フレームの外側から、フレームの内側に表示されたHTMLの passwordがJavaScriptによって参照することができるのです。

 <html> <head> <script> function aa() { var f = window.frames; var inputTag = f[0].document.getElementById("innerTarget"); alert(inputTag.value); } </script> </head> <body> <input type="button" value="CHECK" onclick="aa()"/> <iframe src="pass.html" id="wrap" /> </body> </html>  <html> <body> <input type="password" id="innerTarget"/> </body> </html>

上記ソースではiframeを用いています。つまり、画面全体をiframeとした入れ子構造を、それと悟らせずに表示させることでHTMLのあらゆるパスワード欄に入力される文字列を引き抜くことができます。

これは例えSSLで通信していても防ぐことができません。複合化された後のHTMLからパスワードを読み取っているためです。

現在使用しているブラウザがこの問題に対処できているかを確認するには、以下のコードをコピーし、ブラウザのアドレスバーに入力して見てください。

javascript:alert('%32%30%30%38%2f%34%2f%31%20%3a%2d%50');

これは、クロスドメインによる制約によって実際には機能しません。同一のドメインではフレームの内外でJavaScriptによる参照を行うことができますが、ドメインが違う場合は参照することができないため、iframeの内側に別のページを表示させてパスワードを抜くことはできません。

アドレスバーで実行されるJavaScriptは特殊で、該当ドメイン扱いで実行されるため、どこのページでもパスワードが抜けてしまいます。

iframによる入れ子HTMLでのパスワード抜きはできませんが、離席中などに直接マシンを操作されるような場合、このようなスクリプトでパスワードを盗み見られる可能性がありますので、相応の注意は必要です。

アスペクト指向の概念

凪瀬 — Tue, 25 Mar 2008 10:33:00 GMT

アスペクト指向(AOP : Aspect-oriented programming)はオブジェクト指向(OOP : object-oriented programming)とは直行的な概念で、相補的なものですが、2008年現在、未だ広く普及しているパラダイムではなく、その機能を取り込んだ言語もあるものの（Javaの拡張であるAspectJ、Rubyの拡張であるAspectRなど）普及しているとは言えない状況です。

近年ではDIコンテナの普及で、AOPを部分的に利用できるようになりました。オブジェクト指向言語の普及前に、例えば言語としてのオブジェクト指向をサポートしないC言語で、オブジェクト指向の概念を表現する工夫がなされたと聞きます。 DIコンテナによる部分的なAOPサポートは、言語機能としてAOPがサポートされた言語が普及する「夜明け」に対して、「前夜」の趣を感じさせるものです。

アスペクト指向が解決しようとしていること

アスペクト指向の解説書でアスペクト（横断的関心事と呼ばれる。後述）の例として、よくロギングが挙げられます。が、正直な話、私はあまりこの例でピンときませんでした。

横断的関心事とはどういう事象でしょうか？

オブジェクト指向では複数のクラスに跨って存在してしまう機能性ということですが、どういうものがあるのでしょうか？

私がシステム設計をしてきた中で、「あぁ、これが概念としてのアスペクトなのだな」と思ったことは

SQL injection対策
XSS対策の出力文字エスケープ
OS command injection対策
バッファオーバーラン防止のためのバウンダリチェック
例外処理

といったことです。開発でこれらの対策に頭を悩ませている方は多いのではないでしょうか？

これらの事象は、「すべての該当箇所に対して、一律の対応を行う必要がある」という点です。これこそが、概念としてのアスペクト、横断的関心事なのです。

こうした、XXに全部YYをする、というのは自然言語で表現すると１文にも関わらず、プログラム言語的には該当箇所を検索して１つずつ虱潰しにコードクローンを挿入する必要があります。アスペクト指向が解決しようとしているのは、まさにこの部分なのです。

アスペクト指向の概念で重要なのはこのアスペクトという抽象概念を捉える事。そして、どういったターゲットにウィービング（weaving : 縫い付けるの意。アスペクトを適用させること）させるのかということです。ウィービングできるポイントをジョインポイントと呼んだりします。端的には、メソッドが呼ばれる前、および呼ばれた後などをジョインポイントとすることが多いですね。

どのように実装するか

DIコンテナでは部分的にAOPが利用できると述べました。 DIコンテナはオブジェクトの生成をDIコンテナが管理します。このDIコンテナに管理されたオブジェクトに対してGoFのProxyパターンを利用してAOPを実現しています。

これはOOP的な環境で疑似的にAOPを実現するためのひとつの答えです。

あるクラスのインスタンス生成が制御されうるなら、その段階でProxyを挟むことで、そのクラスの特定のメソッドの前後に処理を一律に差し挟むことができます。

DIコンテナではコンテナがクラスの生成を管理するためにそれが可能でした。そうではない場合でも、Factory Method、Abstract Factory、Builder などといった生成にまつわる GoFデザインパターンと組み合わせることで、一律にProxyを噛ませることができます。

また、ウィービング対象となるオブジェクトが特定の箇所を必ず通過するようなケースでは、そこでトラップしてProxyを噛ませるような方法論も考えることができます。 ServletでのRequest#setAttribute()のような場所をイメージするとよいでしょう。

実行時による動的なウィービングでなくとも、コンパイル時に機械的に処理を差し挟むような方法論も考えられます。

Java SE 5.0からはアノテーションが使えるようになりました。これにより、こうした機械的な処理が断然しやすくなった点も見逃せません。コンパイル時にジョインポイントを自動生成するような仕掛けを作ることで概念としてのAOPを実装することができるわけです。

アスペクト指向の問題点

アスペクトというものが横から入り込んでくるわけですから、OOPのソースコードを見ただけでは実行時の動作がわかりません。そう言った意味でプログラムが複雑化する危険性をはらんでいます。また、アスペクト同士の干渉が起こることもあり、アスペクトの適応順序によって挙動が変わることもあります。

また、アスペクト指向でウィービングの対象をどう管理するかも疑問が多い。「全ての」の適用範囲はどこまでなのか。あるいは、特定の範囲だけに適用したいこともあるでしょう。現行のDIコンテナでのAOPではメソッド名のマッチングによって特定の名称のメソッドの前後に適用、といったことができますがこれが酷く気持ち悪い。

gattaislime氏のアスペクト指向の問題点では

　要するに、現在の典型的なアスペクト指向では、アスペクトを織り込むオブジェクトがホワイトボックスであることを要求するか、逆にアスペクト自体がオブジェクトの実装を規定するか、ということになってしまい、結果としてアスペクトが単なる暗黙的多重TemplateMethodに成り下がっているのではないかと感じてしまうのだ。

　このような暗黙のTemplateMethodは非常に厄介で、ソースコードをそのまま追っても処理の流れがつかみにくく、最悪の場合ソースコード全体をメソッド名や属性名でgrepして、関連するすべてのアスペクトを洗い出さなければならない。

と指摘しています。

ウィービング対象は集合論的に抽出されるわけで(つまり、SQLのWhere句のようなイメージ)Javaなどの強い型付け言語でなされる型の安全性のような安心感がまったくない。

しかし、集合論というとジェネリクスも集合論ですが、型の安全性を確保できている（参考:ジェネリクスと代入と落とし穴）わけで、ウィービングのための型のようなシステムが必要なのではないかと思う次第。

IE7でJavaWebStartを使うと警告が出る

凪瀬 — Fri, 28 Dec 2007 14:31:00 GMT

JavaWebStartはWebからJavaアプリケーションを起動できる便利な機能なのですが、 Vista上のIE7からJavaWebStartを起動すると以下のような警告が表示されます。

Webサイトで、このプログラムを使ってWebコンテンツを開こうとしています：
このプログラムには、発行元を確認するための有効なデジタル署名がありません。
このプログラムは保護モードの外で開かれ、コンピュータが危険にさらされる恐れがあります。
信頼している発行元からのプログラムだけを実行するようにしてください。

名前： ...ram Files\Java\jre1.6.0_03\bin\javaws.exe
発行元： Sun Microsystems, Inc.

IE7がJavaWebStartのプラグインを起動するときにVistaが待ったをかけるみたい。XP + IE7では発生しません。

まぁ、確かにjavaws.exeに何かをしこまれた状態で起動されると、キックできてしまうわけですから正当性を証明するために署名をつけろというのは分かる。
これはSunになんとかして欲しいところ。

バインディングの対象は単なるオブジェクトであるべき

凪瀬 — Tue, 04 Dec 2007 14:27:00 GMT

masa氏の WebアプリケーションとリフレクションAPI ではStrutsでバインドに起因するセキュリティ上の懸念が取り上げられています。

詳しくは該当エントリを読んでいただきたいのですが、Strutsの場合、データのバインド先となるオブジェクトは org.apache.struts.action.ActionFormを継承して作ることになっていますが、バインド機能により外部からActionFormクラスのフィールドに対して値を格納できてしまうという問題があります。 http://issues.apache.org/bugzilla/show_bug.cgi?id=38534

私の感想としては、これはStrutsの設計ミスではないか。バインド対象のオブジェクトが単なるObjectではなく、 ActionFormのサブクラスとしたことがそもそもの誤りではないかと思うのです。

ActionFormの持つ役割

オブジェクト指向でのクラスの設計指針に「A is B」なのか「A has B」なのかを考えるということがよく言われます。継承するということはisの関係で、子のクラスは親と同じ役割を果たした上で、プラスアルファの拡張を行う必要があります。

もし、継承関係にあるクラスを設計して、子のクラスで親で定義されたクラスが不要に感じたのなら、それはis関係ではないということを意味しています。その場合は、継承を用いるのではなく、 has関係、つまり、該当オブジェクトをフィールドに持つようにし、そのオブジェクトに機能を委譲するように作るべきだということです。

さて、データがバインドされるオブジェクトとはどのような役割を持つ型なのでしょうか？
外部からの入力データを表すという役割が本来の役割なのではないでしょうか。

StrutsのActionFormはそのメソッドから推測するに、入力データそのものではなく、 入力データを管理するための付随した機能という役割 に思えるのです。
つまり、ActionFormはデータ格納用オブジェクトとis関係ではない！

ここを継承関係にしてしまったことがStrutsの設計ミスに思います。確かに、実装だけのことを考えれば、ActionFormの継承クラスではオーバーライドしたメソッド中からバインドされた入力データにフィールドアクセスでアクセスできるのですから便利ではあります。例えばvalidate()メソッドで入力チェックを実装する場合に、入力データに対してフィールドアクセスで操作できるのだから楽といえば楽なのです。

Spring frameworkでのバインディング方法

この点、SpringではValidatorというクラスを別途設けており、 validate()メソッドで入力チェックを行うわけですが、この際、引数で対象となるデータを格納したObjectを受け取る作りになっています。

これは先のStrutsのバリデーションがデータを格納するオブジェクトと一体化しているのに対し対照的です。

また、バインド処理もとくに何かの継承クラスである必要は無く、単なるオブジェクトを指定することができます。 Strtusではデータのチェックなどで必要になるであろう情報をActionFormに持たせ、ActionFormのメソッドで各種処理をさせるのに対し、Spring frameworkでは必要なものはその都度引数で渡されます。 (先のValidator.validate()がその一例)

このあたりのクラスの設計はSpring frameworkの方法論が綺麗で機能的に思えます。冒頭かかげたバインドによって操作されたくないフィールドに値がバインドされるような穴もありません。

このような事例から我々はクラス設計のあり方について多くのことを学ぶことが出来るのだと思います。

【業務連絡】javascriptの脆弱性の検討について

凪瀬 — Tue, 27 Nov 2007 16:14:00 GMT

調べていたらちょっと不味そうなネタが見つかったのでmixiに検討スレを作りました。

わんくまメンバーのみなさまのご協力をお願いします。

CAPTCHAとスパマー

凪瀬 — Sat, 03 Nov 2007 18:06:00 GMT

はてなのCAPTCHAは簡単に破れるというエントリが非常に大きな反響を受けました。
本来、機械によって破られない必要のあるCAPTCHAが、その作りのまずさからあまりに容易に機械によって破られるということを指摘し、また対策として機械に破られにくいCAPTCHAとは何なのかということにも触れました。

先の稿ではなぜCAPTCHAを設置するのか？という点については触れませんでしたので今回それをまとめておきたいと思います。

スパマーは何を思ってスパムをばらまくのか

サイトへの誘導を目的としたスパムが日々投稿されています。これらは何を思って投稿されるのでしょうか？

ひとつは検索エンジンで被リンクが重視されることに注目しての間接的な広告行為という側面ではないでしょうか。

もうひとつはそのサイトへの直接的な誘導なのですが、当然のことながら真っ当な企業がこの広告手法を行うことはありません。それは、スパム行為が忌み嫌われる行為であることを理解しているからです。
スパムという手段をもって広告をした場合、そもそも企業の信用が失墜します。スパムは時に法的な手段で排除されることもあるでしょう。利用規約上、許されない行為とされているのが通常ですし、そうした中で技術的に可能だからという理由で実施すれば、信用を失い回りまわって不利益なることが容易に想像できます。

では、なぜスパムでの広告がなくならないのでしょうか。それは、スパムで広告されている事業が信用を必要としないからです。
その一番最たるものが架空請求サイトです。詐欺には本物の信用などまったく必要ない。ですからスパム広告による信用低下というデメリットがない。だからスパムを行えるのです。

コメントスパムのほかにも電子メールによるスパムを幅を利かせています。これらは送信にほとんど費用がかからない。ダイレクトメールなどに比べて格段に安いわけです。コメントスパムも機械化することで非常に安価に多量にばらまくことができます。ここがポイントになります。
例えば5万円の架空請求サイトがあったとしましょう。 1億通のメールを送付して、もし仮に100万人に一人の割合でひっかかる人間がいれば、100人×5万円で500万の儲けです。このように、99.9999%が無駄になっても元が取れる、という経済的な仕掛けがあるわけです。そして、その0.0001%のために我々が迷惑をこうむる、それがスパムというものなのです。

また、詐欺ではなかったとしても短期に利益を上げては潰すといったタイプの経営手法であれば信用を必要としません。これにエロといった人間の本能に基づく部分に働きかけ稼ごうとする、そういった連中によってスパムが繰り広げられているわけです。

スパムとの闘い

jkondo氏が自身のblogにてスパムとの闘いというエントリを書かれています。

スパマーは機械によって大量のコメントスパムをばら撒いていきます。これに対抗する手段としてCAPTCHAが採用されていることがわかります。

さきほど、スパムは広くばら撒いてごく一部が引っかかればよいという方法論であることを述べました。コメントスパムは機械によって大量に送付されていると考えられます。ですから、機械と人間とを判別して機械を通さない、逆チューリングテストを行おうという考えが出てくるわけです。

ですから、CAPTCHAは機械によって破られないことが求められるわけですね。

そして、はてなのCAPTCHAもどきは機械によって簡単に破ることが実証済みです。しかし、jkondo氏は以下のように述べている。

まず、スパムコメントですが、これは特定の条件に適合したコメントをスパムとして自動判定して書き込めない措置を取ったり、ゲストがコメントを書くときには画像認証を行うようにしました。（この画像認証については、機械的に識別が可能だという話が先日上がっていましたが、現時点では大きな効果を上げています。効果が無くなればまた改善をします）

機械によって破れるにも関わらず効果が上がっている。それはなぜ？という話になります。
それは、スパマーの大半がスクリプトキディであるからではないか。
何かしらのスパム送信ツールが出回っており、それを使っているだけではないかということです。こうした、ツールを使うだけのダサい低脳なクラッカーは侮蔑を込めてスクリプトキディと呼ばれます。人の作ったものを使うだけ、しかも使い方が人に迷惑な方向性なのですから始末に終えません。

いまや一般の方まで広くパソコンを扱うようになりました。プログラマというのは全体比率からすればごく一部でしょう。いくらプログラム的には簡単にやれることだといっても、出回っているツールにそれを組み込むような改造をできる人間は限られる。

スパマーなんてのはコンピュータ犯罪者というイメージがあるわけですが、別に凄腕なわけでもなんでもない、実はツールを使うためにパソコンを使うような一般人と変わらないのではないか、そう思えるのです。つまり、悪意に満ちた、ただの人。

ですからスパマーが扱うようなツールを供給するクラッカーが、CAPTCHA破りに対応しようと考えるまではたとえどんなに貧弱なCAPTCHAもどきでも効果があるということになるでしょう。
だってただの人であるスパマーにツールの改造なんてできないでしょうから。

クラッカーは個別対応はあまりしない

以下の内容はプログラム的観点からの推測です。実際にスパムツールを手にして検証したものではありません。

Webでコメントの投稿をしたければ、HTTPのPOSTを送信すればいいわけです。その際のパラメータ名は投稿先のシステムによって違っています。しかし、コメントスパムの文面を検索すると、複数のBBSシステムに対して同じ文面が投稿されている例を見つけることができます。
同一文面が結構な数ばらまかれていることからも複数のシステムへの仕分けを手作業でやっているとは思いえません。多分、スパムツールはメジャーなBBSシステムの種類とパラメータ名ぐらいはマッチングさせられる用にリストを用意しているのでしょう。

Webで公開されているフリーのBBSシステムなどをダウンロードしてきてサーバに設置していると、よくコメントスパムが送られてきます。これは運営している人間が違っても使っているシステムが同じである以上は同じ方法でスパムを投稿できるからでしょう。
逆に独自に作ったBBSには機械的な大量のコメントスパムが送られてきたことはありませんでした。これはスパマーの対応BBSシステムにリストアップされていないからではないでしょうか。対応したところでたかだかひとつのBBSがターゲットにできるだけのことですし。

しかし、独自に作ったシステムといえど、シェアが大きい場合はスパムの標的にされることでしょう。はてなのようなシステムではひとつ破ればはてなユーザ分のダイアリーにスパムできるわけですから。
はてなのシステムはスパムツールの対応BBSの一種としてリストアップされているのではないでしょうか。

さて、ここまでならどの種類のBBSシステムはどういうパラメータを持っている、というだけの話でした。
この程度の管理であればパソコンを触れる程度の人間でできてしまうでしょう。ツールを使える程度の人間でスパム対象となるBBSシステムを追記していける。

しかし、ここにCAPTCHAというものが入ってくるとスクリプトキディの手には負えなくなる。もしスパムツールがよく設計されたものであれば（そうでないことを祈りたい）CAPTCHA解読部分だけプラグインで増設可能なように設計することでしょう。
しかし、単にパラメータを調整するだけというものから、プラグインを個別に作るというところまで手間が一気に増大するわけです。どれだけこの手間が大きいか、難易度が高いか。そこがポイントとなります。

クラッカーがはてなのCAPTCHA解読プラグインを作ったとしても、それはシステム運用側がなんらかの対策をするまでの寿命しか持ち得ないわけです。この手間と利益(?)バランスこそがCAPTCHAを有効たらしめているのです。

もっとも、小一時間で破れるCAPTCHAもどきというのは、システム変更までの時間×ターゲットとなるユーザ数というものと秤にかけたときに、クラッカーが割に合わないと考えてくれるのか微妙に思えたのです。

トラックバックのスパムは厄介

さきほど、独自システムではコメントスパムがくることは少ないという話をしましたが、トラックバックの場合は独自システムだったとしてもがんがんスパムが飛んできます。

それは、トラックバックというシステム自体が、システム同士でやり取りできるように作られたモノであるからです。

BBSは作った人によってパラメータの名前も違えば入力できる項目も違う。
しかし、システム間でやりとりされるトラックバックは規格が決まっているわけです。

だからこそ、標準規格に則って作ることで、非常に汎用的なトラックバックスパムツールを作れてしまう。
トラックバックにはCAPTCHAのような仕掛けをはさむ余地はありませんから、むしろ厄介なのはトラックバックスパムなのではないかと思います。

個人的な経験からすると、トラックバックスパムの大半は、aタグによるリンクを含む本文を送ってくるため、そのようなタイプのトラックバックpingをはじくことで比較的効率よくはじけるのですが、単なる被リンク稼ぎのトラックバックなどもあって対策が難しい。

いろいろと工夫してフィルタリングすることになるのですが、誤認識も多くあり、トラックバックpingを飛ばしたけどもうまく受理されないこともよくありますね。

ココログのCAPTCHAも貧弱らしい

凪瀬 — Tue, 30 Oct 2007 10:39:00 GMT

http://seldon.cocolog-nifty.com/petapeta/より。

該当記事でやっているのはパターンマッチング用の元になるフォントの抽出作業なのだけど、実は、これは別に機械でやる必要がないのです。手作業でも構わない。

先の「はてなのCAPTCHAは簡単に破れる」では抽出作業をメインに解説しましたが、適当な画像編集ツールで、それこそWindowsのペイントで十分なのですが、手作業で元フォントを抽出しておけば、あとはマッチングで一致率をみるだけ。

つまり、あの記事の殆どは比較のための下準備の話だったりします。

実際に機械でのマッチング処理をして検証してはいませんが、ココログも抽出した元フォントとの一致率を見れば相当な高精度でCAPTCHAの文字を認識できることでしょう。

CAPTCHAの基本的な思想とは？

wikipediaの記事には初期のCAPTCHAは、

ブラザー工業のスキャナの取扱説明書には、OCRの結果を改善するためには均質な活字面、無地の背景を用いるよう薦められていた。そこで彼らは取扱説明書に「OCR認識の結果を悪くする」と書いてある条件を真似て最初のCAPTCHAを作り出した。

という発想の元、作られているのです。OCRというのは画像から文字を認識するソフトのことですね。

OCR技術の逆を行くことで機械では読み取りにくい文字にすることができ、それをもって機械をはじこうというのです。

CAPTCHAに込められた思いを汲み取らず、画像の文字を手で入力させるという手法だけを汲み取ったプログラマが機械で認識することが難しくないCAPTCHAもどきを作ってしまう…。

プログラミングをするには、対象となる事象への関心を持つことから始めなければなりません。現実世界をどんどん取材してまわないといけない。「プログラムのことしか知らない」ようでは「世間知らずなシステム」を作り上げてしまうことになるのです。