脆弱Webアプリのテスト環境 — (n)
life is penetration. geeks cheer. geeks be ambitious.ちょっと調べてみるとよくまとまっているサイトを見かけたので拝借して、自分用にメモ。 こうして見ると結構あるものですね。まだまだ、世の中では「SQLインジェクションの注意喚起」という言葉をちょくちょく目にします。Web系の攻撃は、比較的手法が公開されている印象を受けますので、守る立場の方もお好みのものをセットアップして、調べながら手元で試してみてはいかがでしょうか。 守るだけではなく攻めることでまた、違った視点を持てることができ、守る力に磨きがかかるかもしれませんね。 ・Moth サイト: http://www.bonsai-sec.com/en/research/moth.php 環境: Linux VMWare image インストール: VM上で再生 ・Mutilli
2009-09-14
…という分析を読みました。 http経由。httpのGETやPOSTメソッドを用いた通信が主流だ。さて、GETやPOSTによって送られるパラメータは何者だろうか？ パラメータは決して文字列ではない。それどころかバイト列ですらない。答えはオクテット列だ。 つまり。ただのオクテット列をそのまま文字列として扱えば不都合が出るのは当然だろう。ここでしている操作はC++で言えばreinterpret_castなのだから。もしオクテット列が想定している文字エンコードに合致していたとすれば、それは単に幸運だったのだと思うくらいでちょうど良い。 〆。で、対策は次の通り。要するに「自分が欲しいもの＝文字列」と「実際に受け取るもの＝オクテット列」を区別すれば良い。 文字列を期待しているパラメータは、最初にオクテット列から文字列への変換を行う。 文字列の処理はそのエンコーディングに対応した文字列処理関数だけを使
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
NAVITIME
新しい地図ポータルサイト『NAVITIME』地図を探す、電車の乗換案内、自動車ルート検索、徒歩ルート案内はもちろん、週間イベント情報や季節特集も充実！さらに携帯アプリ連携もバッチリ！
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPカンファレンス2009 ビジネスデイに参加する - Kwappa開発室
はてなブログ | 無料ブログを作成しよう
