LIKE句のSQLインジェクション | Yakst
GitHubのエンジニアがデータベースのスローログから見つけた、LIKE句を使ったクエリーのパフォーマンス問題につながる可能性のある文字列。問題の仕組みと、それを回避するためのスニペット。 先日、例外情報のトラッカーを見回していたら、目を引くスロークエリーログを発見しました。SELECT ... WHERE ... LIKEといったクエリーのLIKE句にたくさんのパーセントが付いているのです。この部分はユーザが入力した部分なのは明らかで、最初私はSQLインジェクションを疑いました。 [3.92 sec] SELECT ... WHERE (profiles.email LIKE '%64%68%6f%6d%65%73@%67%6d%61%69%6c.%63%6f%6d%') LIMIT 10 コードを見てみると、ここで解釈されるメタ文字(%や_や\)のチェックをまったくせずにユーザが指定し
PHP入門書のSQLインジェクションとXSS対策をあらためて調べてみた
継続的にPHP入門書のセキュリティ問題を確認していますが、今回は「やさしいPHP 第3版」を取り上げ、今どきのPHP入門書のセキュリティ状況を報告したいと思います。 やさしいPHP やさしいシリーズ 単行本 – 2008/2/29 やさしいPHP 第2版 (やさしいシリーズ) 単行本 – 2010/8/28 やさしいPHP 第3版 (「やさしい」シリーズ) 大型本 – 2014/9/26 上記のように、2008年に初版が出版された後2回の改版がありました。 第2版ではクロスサイトスクリプティング(XSS)の説明が追加され、第3版ではXSSに加えSQLインジェクションの説明が追加されました。つまり、初版ではこれらの説明はなかったということです。 第3版におけるSQLインジェクションの対策方法はプレースホルダによるもので、結果として本書にSQLインジェクション脆弱性は見当たりません（パチパチパ
Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
ラックの扱われ方に見る脆弱性調査のあり方 | クロスジール
SQLインジェクション判決が広まりを見せています 先日、以下の記事を書きました。 ・SQLインジェクション脆弱性の有無が重過失の判断に影響を与えた判決 http://www.crosszeal.co.jp/blog/20150209_sqlインジェクション脆弱性の有無が重過失の判断に影響を与えた判決.html この記事にも書いたとおり、北海道大学の町村先生、HASHコンサルティングの徳丸先生のエントリでこの件を知りブログを書いたわけですが、同じ方々も多いようで、この判決に関する情報や意見が検索で多くヒットするようになりました。 中には「脆弱性が一つでもあったら損害賠償が認められる」といった誤っている認識であったり、「SQLインジェクション対策をしたら費用が多くかかってしまう」といった首をかしげる意見もありますが、こういった情報が広まるのは良いことだと思います。今後広まっていく中で、正しい認
DrupalのSQLインジェクションCVE-2014-3704(Drupageddon)について調べてみた
既に日本でも報道されているように、著名なCMSであるDrupalのバージョン7系にはSQLインジェクション脆弱性があります（通称 Drupageddon; CVE-2014-3704）。この脆弱性について調査した内容を報告します。 ログイン時のSQL文を調べてみる MySQLのクエリログを有効にして、Drupaのログイン時に呼び出されるSQL文を調べてみます。リクエストメッセージは以下となります（一部のヘッダを省略）。 POST /?q=node&destination=node HTTP/1.1 Host: xxxxxxx User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Cookie: has_js=1; Drupal.toolbar.collapsed=0 Conn
JSON SQL Injection、PHPならJSONなしでもできるよ
DeNAの奥さんと、はるぷさんがJSON SQL Injectionについて公表されています。 The JSON SQL Injection Vulnerability 不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) 上記の記事は、主にPerlスクリプトがJSONデータを受け取るシナリオで説明されています。もちろん、この組み合わせに限定したはなしではないわけで、それではPHPではどうだろうと思い調べてみました。 JSON SQL Injectionとは 以下、はるぷさんの「不正なJSONデータによる…」にしたがってJSON SQL Injectionについて説明します。 Perl向けのSQLジェネレータの一つであるSQL::Makerにおいて、以下のスクリプトを想定します。 my ($sql, @bind) = $builde
ユーザ由来の構造化データによるSQLインジェクション | tech - 氾濫原
Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
JSON SQL Injection and the Lessons Learned