ブックマーク / blog.tokumaru.org (14)

  • 徳丸浩の日記: SSRF(Server Side Request Forgery)徹底入門

    SSRF(Server Side Request Forgery)という脆弱性ないし攻撃手法が最近注目されています。以下は、ここ3ヶ月にSSRFについて言及された記事です。 EC2上のAWS CLIで使われている169.254について SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例 SSRFを利用したメール送信ドメインの乗っ取り 「CODE BLUE 2018」参加レポート(岩間編) この「空前のSSRFブーム」に便乗して、SSRFという攻撃手法および脆弱性について説明します。 SSRF攻撃とは SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。 攻撃者からは、公開サーバー(203.0.113.2)にはアクセスできますが、内部のサーバー(192.168.0.5)はファイアウォールで隔離されているため外部から直接

    徳丸浩の日記: SSRF(Server Side Request Forgery)徹底入門
  • 安全なWebアプリケーションの作り方改訂のお知らせ

    徳丸こと、「体系的に学ぶ 安全なWebアプリケーションの作り方」は、2011年3月の発売以降大変多くの方に読んでいただきました。ありがとうございます。 ただ、発売から既に7年が経過し、内容が古くなってきた感は否めません。たとえば、クリックジャッキングの説明はほとんどないですし、OWASP Top 10 2017で選入された安全でないデシリアライゼーションやXXEの説明もありません。なにより、Web APIJavaScriptセキュリティ等がほとんど書かれていないことが課題となっていました。 そこで、版元のSBクリエイティブと相談して、この度改訂することにいたしました。3月末脱稿、6月頃発売の見込みです。 改訂にあたり、以下を考えています。 Web APIJavaScriptに関する説明を4章に追加 XHR2対応に向けてCORSの説明を3章に追加 携帯電話の章は丸ごと削除して、別の内

  • 画像ファイルによるクロスサイト・スクリプティング(XSS)傾向と対策

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2007年12月6日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり 最近、画像ファイルを用いたクロスサイト・スクリプティングが注目されている。稿では、画像を悪用したXSSについて説明した後、対策方法について解説する。 画像によるXSSとはどのようなものか Internet Explorer(IE)の特性として、コンテンツの種類を判別する際に、レスポンスヘッダ内のContent-Typeだけでなく、コンテンツの内容も判断基準にしている。このため、Content-Typeが例えばimage/gif(GIF画像)となっていても、中身がHTMLであればHTMLと解釈して表示する。

    画像ファイルによるクロスサイト・スクリプティング(XSS)傾向と対策
  • CMS四天王のバリデーション状況を調査したところ意外な結果になった

    バリデーションでSQLインジェクション攻撃をブロックしないCMSが多い ログインIDにおける典型的なSQLインジェクション攻撃として、'OR 1=1# をバリデーションがブロックするかどうかを確認しました。ログインIDとして許容される文字を見る限り、WordPress、Joomla、Drupalはブロックしそうですが、結果は下記の通りです。 WordPress: ブロックしない Joomla: ブロックする Drupal: ブロックしない MovableType: ブロックしない ということで、意外なことに、バリデーションでSQLインジェクション攻撃を止めるのはJoomlaのみという結果でした。 ログインIDにヌルバイトや改行が使えるCMSがある テストをしていてもっともびっくりしたことの一つがこれです。JoomlaとMovableTypeはヌルバイトや改行など制御文字がログインIDとして

  • エラーメッセージによるXSSにご用心

    以前の記事「PHPのdisplay_errorsが有効だとカジュアルにXSS脆弱性が入り込む」では、php.ini等でdisplay_errorsを有効にしていると、スクリプトに脆弱性がなくてもXSS(クロスサイトスクリプティング)脆弱性が入り込む可能性が高いことを指摘しました。 しかし、display_errorを無効にしていても、エラー処理がまずいと、エラー表示が原因でXSS脆弱性が入り込む場合があります。ネット上のサンプルスクリプトを見ても、潜在的にXSS脆弱性があるものが多くあります。 サンプルスクリプト まずは、典型的な脆弱性の例をスクリプトで紹介します。PHP+PDO+PostgreSQLの組み合わせです。 <?php try { $db = new PDO("pgsql:host=localhost options='--client_encoding=UTF8';dbnam

    エラーメッセージによるXSSにご用心
  • Time-based SQL Injectionは意外に実用的だった

    このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間(例えば5秒)スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL

    Time-based SQL Injectionは意外に実用的だった
  • Webアプリケーション脆弱性診断の検査対象をどう絞り込めばよいか

    ソニーDNAさんの『入門!基礎からわかる「失敗しないWeb診断業者の選び方」』というブログ記事を読みました。 全体的に穏当な内容で異論はないのですが、興味深い内容なので、屋上屋を架すようですが少し追加して考えてみたいと思います。 私が特に注目したのは以下の箇所です。 2. 検査対象を適切に絞れるか? セキュリティ対策をくまなく実施できれば安心ですが、それは大きな費用がかかり現実的ではないというケースも多いでしょう。そのため、Web診断では検査対象を適切に絞り込むことが必要です。ログイン画面や課金機能、個人情報管理機能など、セキュリティ対策が特に求められる機能を重点的に検査するには、検査対象を明確にすることが重要になります。 上記の考え方は、脆弱性診断の現場でよく行われているもので、筆者もこれに従うことは多いのですが、検査対象の選定は重要なのでもう少し掘り下げて考えてみたいと思います。 脆弱

  • GHOST脆弱性を用いてPHPをクラッシュできることを確認した

    GHOST脆弱性について、コード実行の影響を受けるソフトウェアとしてEximが知られていますが、PHPにもgethostbynameという関数があり、libcのgethostbyname関数をパラメータ未チェックのまま呼んでいます。そこで、PHPのgethostbynameを用いることでPHPをクラッシュできる場合があるのではないかと考えました。 試行錯誤的に調べた結果、以下のスクリプトでPHPをクラッシュできることを確認しています。CentOS6(32bit/64bitとも)、Ubuntu12.04LTS(32bit/64bitとも)のパッケージとして導入したPHPにて確認しましたが、phpallで確認した限りPHP 4.0.2以降のすべてのバージョンのPHPで再現するようです。なぜかPHP 4.0.0と4.0.1では再現しませんでした。 <?php gethostbyname(str_

  • SQLインジェクション対策もれの責任を開発会社に問う判決

    ポイントは下記の通りです。 X社(原告)はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日) X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイ

  • 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

  • PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能

    基礎からのPHPという書籍を読んでおりましたら、SQLインジェクションの攻撃例として、以下のSQL文ができあがる例が紹介されていました。PHP+PDO+MySQLという組み合わせです。 SELECT * FROM tb2 WHERE ban=1;delete from tb2 2つのSQL文がセミコロンで区切って1つにまとめられていますが、これを「複文(multiple statement)」と言います。私は、SQLインジェクション攻撃の文脈で複文が使える組み合わせを調べたことがあり、PHPMySQLという組み合わせでは、複文は使えないと思っていましたので、この攻撃は成立しないのではないかと思いました。 しかし、決めつけも良くないと思い手元の環境で動かしてみたところ、あっさり動くではありませんか。 PDOを用いてMySQLを呼び出す場合は複文が実行できると気づきましたが、なぜPDOの場合

  • XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス

    メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下

    XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス
  • 徳丸浩の日記

    日経BPから4月4日発売予定の『はじめて学ぶ最新サイバーセキュリティ講義 「都市伝説」と「誤解」を乗り越え、正しい知識と対策を身につける』の監訳を担当したので紹介させていただきます。 書の原書は、ユージーン・H・スパフォード、レイ・メトカーフ、ジョサイヤ・ダイクストラの3名の共著として書かれた「Cybersecurity Myths and Misconceptions」で、米国Amazonのレビューでは4.6の高評価を得ています。また、「インターネットの父」ことヴィントン・サーフ氏が書に前書きを寄せています(後述)。 はじめにサイバーセキュリティは、その短い歴史にも関わらず、神話や都市伝説に満ちています。古典的なものとして、書の冒頭では、「ウイルス対策企業が自社製品を売るためにマルウェアを作って拡散した」が紹介されています。 書は、このようなセキュリティの都市伝説や神話をとりあげ

  • JSONをvbscriptとして読み込ませるJSONハイジャック(CVE-2013-1297)に注意

    はせがわようすけ氏のブログエントリ「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき」にて、巧妙な罠を仕掛けることにより、別ドメインのJSONデータをvbscriptとして読み込み、エラーハンドラ経由で機密情報を盗み出すという手法が紹介されました。これは、IEの脆弱性CVE-2013-1297を悪用したもので、MS13-037にて解消されていますが、MS13-037はIE6~IE8が対象であり、IE9以降では解消されていません。 また、MS13-037を適用いていないIE6~IE8の利用者もしばらく残ると考えられることから、この問題を詳しく説明致します。サイト側の対策の参考にして下さい。 問題の概要 JSON形式のデータは、通常はXMLHttpRequestオブジェクトにより読み出しますが、攻撃者が罠サイトを作成して、vbscript

    JSONをvbscriptとして読み込ませるJSONハイジャック(CVE-2013-1297)に注意
  • 1