Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
Validation nightで発表しました。
「RDBにおけるバリデーションをリレーショナルモデルから考える」という、なんとも捻りも面白みもないタイトルである。だが、RDBとValidationという2つが相容れないものだということを知っている人には、割と琴線に触れる話かも知れない。 正直なところ、現在私はデータベースエンジニア一直線なので、アプリケーション開発におけるセキュリティというのは門外漢であると言って差し支えない。しかもイベントにはあの徳丸浩氏（バリバリの本職）も発表されるというではないか！！順番的には徳丸氏の次に話したのだが、徳丸氏はSQLインジェクションの実演までするというガチっぷりである。 「場を白けさせてしまうのではないか・・・」 「ガチの人から特大のマサカリが飛んでくるのでは・・・」 そんな想いを脳裏に抱きつつ発表に望んだのであった。 今回の持ち時間は20分と短めであったが、あまりたくさん話したいネタも無かったので
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第6章 入力・注入対策：SQL注入攻撃: #1 実装における対策
SQLを用いてデータベースを扱うWebアプリケーションは、SQL注入を許さないようにする必要がある。SQL注入攻撃対策のうち、まずは実装における対策について述べる。 文脈に応じた特殊記号対策はコマンド注入攻撃対策と同様である。加えて、プリペアードステートメントの使用や言語の選択による対策を説明する。 「SQL注入（SQL injection）」は、パラメータを埋め込んでSQL文を組み立てる場合、そのパラメータに特殊記号（記号）を含ませたSQLコマンドを与えることによって、データベースの不正操作が可能となってしまう問題である。 参考： CWE-89: Improper Neutralization of Special Elements used in an SQL Command（日本語訳） SQL注入攻撃のメカニズム ここに、次のようなSQL文を使用したログイン判定プログラムがあるとする
俺の脳内選択肢が、SQLインジェクション対策を全力で邪魔している — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHP Advent Calendar 2013 in Adventarの19日目です。昨日も私の「PDOでの数値列の扱いにはワナがいっぱい（2）」でした。 うっかりtogetterなんか見てしまい、無駄に時間を使ってしまったと後悔した上に混乱してしまい余計にわからなくなってしまった人もいるかも知れません。 そこで、せっかくの機会なので、SQLインジェクション対策について、現在の私の考えをまとめておこうと思います。 選べ ①SQLインジェクション対策にプリペアドステートメントを使う ②SQLインジェクション対策にエスケープを使う もし、上記のような選択にはまってしまったら、あなたのSQLインジェクション対策は、現実的には、ほぼ100％間違っていると言えるのではないでしょうか。プリペアドステートメントとエスケープは、このような対立構造にはありませんから。 なお、この記事は、SQLインジェクシ
SQLでエスケープなんてしたら負けかなと思ってる。 - めもおきば
オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか | [ bROOM.LOG ! ] エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog SQLへの安全な値の埋め込み方について、ここ数日で色々議論というか意見の投げ合いがありましたが、自分としての考えをまとめておきます。 1. SQLに値を埋め込む場合は、プリペ
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
SQLインジェクションについてのスライドを作成した - Kentaro Kuribayashi's blog
社内で、SQLインジェクションについてあらためて原理・原則から議論したいねという風潮がにわかに起こったので、ひとまずは叩き台として僕の方でまとめて皆で議論しましょうというわけで、以下のような資料を作成した。 社内勉強会用の資料なのだけど、僕は別にセキュリティに詳しいわけでもないし、ましてやPHPのことは素人なので、外部の識者にレビューしていただいて、できるだけ正しい知識に基づいて議論できればと思い、まずスライドを先行公開することにした。そうしたところ、Twitter上で多数の識者よりいろいろとご指摘いただいて、少くとも決定的におかしな内容にはなっていないものになったようだ。ありがとうございます。 僕らの職務のひとつに「セキュリティ関連」というものも謳われているので、そのあたりの知識普及・基盤整備についても、仕事のひとつとして行っている。先にも書いた通り、僕自身がその点についてよく理解できて
PostgreSQLは標準でバックスラッシュをエスケープしない仕様になった
PostgreSQL9.1の仕様変更にて、デフォルト時の設定として、standard_conforming_stringsがonとみなされるようになりました。この仕様変更により、デフォルト設定でのPostgreSQLは、バックスラッシュをエスケープする必要がなくなり、ISO規格のSQLと同様のエスケープルール（シングルクォートを重ねるのみ）となります。 PostgreSQLの文字列リテラルは、元々MySQL同様に、バックスラッシュをエスケープする仕様でした。その後、リリース8.1にて、設定パラメータ standard_conforming_strings が追加され、この値が on の場合、バックスラッシュをエスケープしない（ISO規格と同様の）仕様となりました。従来のリリースでは、standard_conforming_stringsを指定しない場合offとみなされていました。これは、後
川口洋のセキュリティ・プライベート・アイズ 連載インデックス - ＠IT -
川口 洋 株式会社ラック チーフエバンジェリスト CISSP 毎日のように起きる脆弱性を突いた攻撃、それを守るための仕組みも多数のベンダにより提供されていますが、実際にその攻撃を検知し、どのように対処するかということは人間の手――セキュリティアナリストによって行われています。本連載ではそのセキュリティアナリストと呼ばれる人たちが、どのような考え方やマインドで仕事をしているのかを探るべく、技術とともに“人”にフォーカスしたコラムとして伝えていきます（編集部） あの「SQLインジェクション」騒動の裏で（前編） 川口洋のセキュリティ・プライベート・アイズ（1） 広大なネットで起こる数々の攻撃、それを追い続ける男の目に映るものは？ 第一線のセキュリティアナリストによる新連載！
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLインジェクション対策について
SQL Injection Basics