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
深刻な「ブラインドSQLインジェクション」の脅威
2013年11月18日から11月21日の4日間にわたり、アメリカ合衆国ニューヨークでWebアプリケーションのセキュリティに関する国際的なカンファレンスである「OWASP AppSec USA 2013」が開催されました。 世界各国から開発者・研究者が一堂に会するこの一大イベントに参加してきましたので、その模様を報告します。 Webアプリセキュリティにまつわるあらゆる話題を扱う「OWASP」 OWASP（Open Web Application Security Project）は、WebアプリケーションおよびWebサービスのセキュリティ向上を目的とした、ボランティアによるプロジェクトです。 今回参加した「AppSec」をはじめとするカンファレンスの開催による知識の展開やトレーニングを通じた開発者のスキル向上の他、開発者向けガイドラインの作成、テストツールの開発・公開などを行っています。ツー
俺の脳内選択肢が、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インジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?
コードゴルフという競技があります。与えられた問題（例えばFizzBuzz）を解くコードを、いかに短いプログラムで実現できるかというものです。 脆弱性の世界でもXSS Golfというものは既にあるようで、我らが はせがわようすけ氏にも、「短いXSSの話」というプレゼン資料が公開されています。第2回のOWASP Japanローカルチャプターミーティングでの講演ですね。これ、面白いので、まだ見ていない方はぜひご覧になって下さい。 XSSがあるならSQLインジェクションはどうかということで、ちょっと考えてみました。この手の遊びは、問題のルールが命というというところはありますが、最初なのであまり厳密に考えずにだらだらとやってみます。 攻撃対象プログラム やはり、SQLインジェクション攻撃でみなさまおなじみの認証回避がよいのではないかと思いました。拙著「体系的に学ぶ 安全なWebアプリケーションの作り
ちょっと変わったSQLインジェクション
＠IT編集部のセミナーに出てきました 3月2日に、＠IT編集部主催の「＠IT セキュリティソリューション Live! in Tokyo」にて、NTTデータ先端技術の辻さんとインターネットイニシアティブの根岸さんとともに、ランチセッションに出演してきました。辻さん＆根岸さんのトークに絡ませてもらい、あっという間にランチセッションは楽しく終了しました。 事前の準備中はあれだけいろいろと話そうと思っていたのに、いざ始まると時間が足りないくらい盛り上がりました。ちょっと物足りないと思うくらいがいいのかもしれませんね。その会場で使った、2002年と2012年付近の出来事を示した資料がこちらです。 私はちょうど10年前の2002年にラックに入社しました。振り返ってみればあっという間の10年の社会人生活です。こうしてみると、いろんなインシデントがリアル世界とサイバーの世界で起こっていたんだなと懐かしくな
「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH
『よくわかるPHPの教科書』のSQLインジェクション脆弱性 - ockeghem's blog
このエントリでは、数値型の列に対するSQLインジェクションについて説明します。 以前のエントリで、たにぐちまことさんの書かれた『よくわかるPHPの教科書』の脆弱性について指摘しました。その際に、『私が見た範囲ではSQLインジェクション脆弱性はありませんでした』と書きましたが、その後PHPカンファレンス2011の講演準備をしている際に、同書を見ていてSQLインジェクション脆弱性があることに気がつきました。 脆弱性の説明 問題の箇所は同書P272のdelete.phpです。要点のみを示します。 $id = $_REQUEST['id']; // $id : 投稿ID $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id) $record = mysql_query($sql) or die(
PDOにおける一応の安全宣言と残る問題点
8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。 PDOの問題とは何か 以前、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)にて報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディングを指定する機能がないため、文字列リテラルのエスケープの際に文字エンコーディングをLatin1を仮定してしまうという問題がありました。この状態ですと、DBにShift_JISで接続している際に、SQLインジェクション脆弱性が混入しました。 ※ 実は、先のエントリの「追記(2010/07/01 22:20)」に紹介した方法で文字エンコーディングを指定できるのですが、ほとんど知られていないのと
ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
新しいタイプのWebサイト改ざんSQLインジェクション攻撃(続報) - Tokyo SOC Report
February 14, 2024 IBM® has big plans for the Power Virtual Server offering, which is IBM’s virtual machine as-a-se... February 13, 2024 Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announceme... February 12, 2024 IBM® Envizi™ is pleased to announce the release of additional functionality as we continue to bu...
データベース・セキュリティの実装 第4回 最前線の防御を可能にするOracle Database Firewall | oracletech.jp
最終回は、今年に新たにデータベース・セキュリティ製品に加わったOracle Database Firewallについて取り上げよう。Firewallという名がつくことから、何となく機能のイメージはできるかもしれないが、このOracle Database Firewallは、今までのデータベース関連の製品とは毛色の違う、非常に面白い製品である。しかしながら、その中身は質実剛健のごとく的を射たものであり、その代表的な機能について触れていきたい。 ■SQLインジェクション その前に、やはりSQLインジェクションについて説明が必要かもしれない。SQLインジェクション攻撃は以前から存在してはいたが、特に2005年頃から猛威を振いはじめ、2010年もその衰えは見せてはいない。Gumblar（ガンブラー）と並ぶウェブサイトを経由した攻撃の2大トレンドといってもよいだろう。「SQLインジェクション」と
新しいSQLインジェクション攻撃が確認--データベースの特定情報を改ざん
日本IBMは4月1日、運営する東京セキュリティオペレーションセンター（SOC）で従来と異なる方法でウェブサイトを改ざんするSQLインジェクション攻撃を確認したとブログで発表した。この攻撃は同日時点で、世界9拠点のSOCのうち海外のみで確認されており、日本のSOCでは確認されていない。 この攻撃は、データベースにMicrosoft SQL Serverを利用して、ASPで構築されたウェブサイトを標的としており、ウェブサイトに不正にscriptタグを挿入することを目的としている。この攻撃により、すでに多数のウェブサイトが改ざんされていることを確認しているという。今回確認された攻撃は不特定多数のウェブサイトを狙ったものではなく、攻撃対象を絞って行われている。 今回の攻撃で使用されているSQL命令は、指定したテーブル内の特定のカラムの情報を書き換えようとするもの。指定されるテーブル名やカラム名は攻
第29回 SQLインジェクションの復習 | gihyo.jp
セキュリティは古くて新しい問題です。SQLインジェクションも古くからある問題ですが現在の問題です。対策は比較的簡単なのですが今でもなくなりません。と言うよりも今でも現役のセキュリティ上の問題で十分注意が必要です。この連載でも何度かSQLインジェクション対策について簡単に取り上げています。 第5回 まだまだ残っているSQLインジェクション 第14回 減らないSQLインジェクション脆弱性 第15回 減らないSQLインジェクション脆弱性（解答編） 第24回 無くならないSQLインジェクション脆弱性 今回はSQLインジェクションを復習してみたいと思います。 SQLインジェクションとは SQLインジェクションはプログラマが意図しないSQL文を実行させる攻撃で、2種類の攻撃方法に分類できます。 直接SQLインジェクション 間接SQLインジェクション 直接SQLインジェクション 直接SQLインジェクショ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
