Statically detecting vulnerability under memory pressure using�exhaustive search

最近はAWS WAFを触っています。こういう防御ツールは、やはり攻撃をどれぐらい防いでくれるか気になります。AWS WAFの場合、SQLインジェクション系の脆弱性を探ってくれるsqlmapをかけたところ、攻撃をブロックしてくれたという記事があります。 記事を読んだり自分でちょっと試したりして、ちゃんとSQLインジェクション攻撃を防いでくれるんだーと思っていました。が、つい先日WAFをバイパスしてSQLインジェクション攻撃をするテクニックがあることを知りました。例えばOWASPのこのページには、そういうテクニックがいくつか紹介されています。 こうなると気になるのは、AWS WAFに対してWAFバイパスのテクニックを使うとどうなるかです。というわけで、実際に試してみました。 単純にSQLインジェクションしてみる まずは、AWS WAFがないときにSQLインジェクションができること、また、AWS
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2007年11月26日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本稿ではSQLインジェクション対策として、SQLのエスケープ処理の方法について検討する。 最近SQLインジェクション攻撃が猛威を振るっていることもあり、SQLインジェクションに対する解説記事が増えてきたようだが、対策方法については十分に書かれていないように感じる。非常に稀なケースの対応が不十分だと言っているのではない。ごく基本的なことが十分書かれていないと思うのだ。 SQLインジェクション対策には二通りある。バインド機構を使うものと、SQLのエスケープによるものだ。このうち、SQLのエスケープについて、十分
社内で、SQLインジェクションについてあらためて原理・原則から議論したいねという風潮がにわかに起こったので、ひとまずは叩き台として僕の方でまとめて皆で議論しましょうというわけで、以下のような資料を作成した。 社内勉強会用の資料なのだけど、僕は別にセキュリティに詳しいわけでもないし、ましてやPHPのことは素人なので、外部の識者にレビューしていただいて、できるだけ正しい知識に基づいて議論できればと思い、まずスライドを先行公開することにした。そうしたところ、Twitter上で多数の識者よりいろいろとご指摘いただいて、少くとも決定的におかしな内容にはなっていないものになったようだ。ありがとうございます。 僕らの職務のひとつに「セキュリティ関連」というものも謳われているので、そのあたりの知識普及・基盤整備についても、仕事のひとつとして行っている。先にも書いた通り、僕自身がその点についてよく理解できて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く