2007-02-27

フレームワークのセキュリティ問題

Security

まとめたい。

フレームワークが持つ脆弱性に対して、開発者はどこまで認識すべきか

既知の問題だけ認識すればよいか？
未知の問題に対してどう取り組むべきか

フレームワークを使用する場合、開発者はどこまでテストすべきか

フレームワーク固有の問題に関しては一切テストしないと割り切るか
受け付けインタフェースを持つパラメータのテストまではカバーすべきか
受け付けインタフェースを持つパラメータを列挙できるか
フレームワークの設計に起因する問題までカバーできるか

フレームワークに起因する脆弱性が検出された場合、どう改修するか

パッチが出ていない場合どうするか
パッチが出ることを期待出来ない場合どうするか
報告→パッチリリースまでの期間に対するリスクをどう捉えるか
ソースに手をいれるか

2007-02-24

Apacheの

Security

'Apache Multiple Injection Vulnerabilities' - SecuriTeam
ニセ脆弱性？

2007-02-21

メモ

Apache IIS

Apache,IISはchunkedリクエストに反応する

GET / HTTP/1.1
Host: localhost
Transfer-Encoding: chunked

4
hoge
0

2007-02-20

言語別変換メモ

Java ASP.NET

shift-jis

Java

→
%→null Nullpo
%A→null Nullpo
%A1→?
%81→?

セキュリティ対策はいたちごっこか？

Security

最近、「セキュリティ対策はきりがない、いたちごっこになるだけじゃないか。」という声を耳にすることがよくあります。年々新しい攻撃手法が発見されるため、いつまで経っても安心できない、というのが理由のようです。
ただ、正しく実装している限り、いたちごっこになることはありませんので安心してください。
Webアプリケーションのセキュリティ対策には、IPAの安全なウェブサイトの作り方にもあるように

保険的な対策
根本的な対策

の2種類があります。XSSを例にすると、根本的な対策とはHTML生成時の特殊文字エンコードであり、保険的な対策は入力値の妥当性チェックとなります。
いたちごっこの問題は、保険的な対策(特に問題となるのはブラックリスト方式でのチェック)のみで実装されているアプリケーションにおいて発生します。妥当性チェックを通過した値が後続の処理で別の値に変換される仕様によって問題が顕在化したり、IIS+IE+Unicodeでスクリプト挿入を弾くためのブラックリストが回避されてしまったり・・・
これらの問題は非常に厄介で、例えセキュリティベンダに検査を依頼したとしても、あらゆる攻撃手法に耐えうる実装となっていることを短い期間で検証することは不可能に近いと言い切ってもいいかもしれません。従って、年々新しい攻撃手法が発見されるため対策にきりがないという結論に結びつくのでしょう。
しかし、きりがない対策を永遠に行う必要がある訳ではありません。問題の本質を理解し根本的な対策を行えばよいのです。根本的な対策が取られていれば、新しい攻撃手法に脅える必要はありません。残念ながら、根本的な対策がなんであるのかは私が考えていた以上に浸透していないようですが・・・

このような現状を踏まえると、高木先生の啓蒙活動は大変有益なものであると感じられます。
高木浩光＠自宅の日記 - WASF Times版「サニタイズ言うな！」

2007-01-19

ServerPush型HTTP通信は革新的な技術か？

HTTP Comet

遅ればせながらCometという新しい技術が話題になっていることを知りました。
http://blog.japan.cnet.com/kenn/archives/003149.htmlより引用

チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。

ServerPush型HTTP通信が革新的な技術であるのか？というと、実は昔昔にNetscape社が定義したけれど流行る事がなくすたれていった技術だったりします。multipart/x-mixed-replace - Google 検索
流行らなかった理由は、MSIEがサポートしなかったことにあるでしょう。この技術が革新的なのは、MSIEでも動作することと、コネクション繋ぎっぱのサービス提供に耐えうるインフラが台頭してきたことにあるのだと思います。

ちなみにmultipart/mixedをMSIEがサポートしてくれるとtext/htmlとapplication/octet-streamのレスポンスを一つのリクエストに対して返すことが出来るようになります。
http://d.hatena.ne.jp/masakiti2005/20051210/1134224888

2006-12-29

HTTPとHTTPSを併用しログイン後の画面遷移はHTTPSしか許可しないサイトでの安全なセッション管理その３

Security ASP.NET

HTTPとHTTPSを併用しログイン後の画面遷移はHTTPSしか許可しないサイトでの安全なセッション管理その２ - masaのメモ置き場
の続き

セッション管理に使用するCookieと認証状態の管理に使用するCookieが独立して存在するため、認証CookieにSecure属性を設定することで、認証後のセッションデータを保護することが出来るという概念です。
この仕組みが安全に動作するならば、ログイン時にSecure属性付きのセッションCookieを再発行することが難しくてもサイトの安全性を守ることが可能となります。

と書きましたが、この仕組みは、どちらかというと危険な動作をします。ASP.NETが使用するCookieは以下の2種類で構成されますが、それぞれが紐付けされた状態で管理されていないことが要因です。

認証状態を管理するCookie - AuthCookie(名称は任意) ログインしたユーザIDを保持する
セッションを管理するCookie - ASP.NET_SessionID セッション変数へアクセスするためのキーとなる

この仕組みは、以下の攻撃に対し耐性がありませんので、セッション変数が漏えいする危険性があります。

サイトへログインすることが可能な攻撃者が、攻撃者のアカウントでAuthCookieを取得
正規ユーザのSecure属性を持たないASP.NET_SessionIDを盗聴
攻撃者が持つAuthCookieと盗聴したASP.NET_SessionIDを組み合わせてサイトへアクセスする

従って、この実装ではHTTPとHTTPSの併用サイトで安全なセッション管理を行うことが出来ません。

1年程前マイクロソフトにこの問題について問い合わせてみましたが、

この仕組み単体を捉えて脆弱性であるとみなすことはない
ASP.NET_SessionIDに盗聴の危険がある場合、重要な情報をセッション変数に保持させるべきではない
重要な情報をセッション変数に格納する場合、ASP.NET_SessionIDをSecure属性付きで発行すべきである

との見解のようです。

この攻撃が成功する要因は、「認証状態を管理するCookieとセッションを管理するCookieが紐付けされていない」ことにあります。紐付けすることにより問題が解決するならば、相応の実装を取ることでサイトの安全性を守ることが可能となります。