DNSリバインディング(DNS Rebinding)対策総まとめ
サマリ DNSリバインディングが最近注目されている。Google Chromeは最近になってローカルネットワークへのアクセス制限機能を追加しており、その目的の一つがDNSリバインディング対策になっている。Googleが提供するWiFiルータGoogle Nest WiFiはデフォルトでDNSリバインディング対策機能が有効になっている。 DNSリバインディング対策は、攻撃対象アプリケーションで行うべきものであるが、ブラウザ、PROXYサーバー、リゾルバ等でも保護機能が組み込まれている。本稿ではそれら対策機能の状況と対策の考え方について説明する。 DNSリバインディング（DNS Rebinding）とは DNSリバインディングはDNS問い合わせの時間差を利用した攻撃です。DNSのTTL（キャッシュ有効期間）を極めて短くした上で、1回目と2回目の問い合わせ結果を変えることにより、IPアドレスのチ
徳丸浩の日記: 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）はファイアウォールで隔離されているため外部から直接
解答：間違ったCSRF対策～初級編～
この記事は、先日の記事「問題：間違ったCSRF対策～初級編～」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 はじめに CSRF対策の不備として、ありがちなパターンは以下のとおりです。 トークンが予測可能（ユーザIDのハッシュ値をトークンとして用いている等） 他人のトークンが利用できてしまう（参考記事） トークンのチェック方法に不備がある。 問題のコードは、暗号論的に安全な乱数生成器（PHPのrandom_bytes関数）を用いてトークンを生成し、それをセッション変数に記憶しているので、上記1 と 2 は問題ないと考えられます。したがって、3 が該当しそうだと当たりをつけます。そのためには、攻撃者は以下のトークンチェック(chgmail.php内)を回避する必要がありま
徳丸浩の日記: 問題：間違ったCSRF対策～中級編～
この記事は「問題：間違ったCSRF対策～初級編～」の続編です。前回同様、この記事では問題のみを出し、想定解答は後日公開することにします。ネタバレとなるブックマークコメントやツイートなどは控えていただけると幸いです（「思いのほか簡単だった」など感想は可）。ブログ記事等に解説記事を書くことは歓迎いたします。 この問題が果たして「中級」なのかについては異論があると思います。きわめて易しいと思う人もいれば、きわめて難しいと思う人も多いと思います。中をとって中級としましたが、現実には難し目かと思います。 今回の問題は、前回（初級編）のトークンチェック部分（chgmail.php内）のみを変更したものです。まずは変更箇所を説明します。 前回のおさらい if ($_POST['token'] !== $_SESSION['token']) { // ワンタイムトークン確認 die('正規の画面からご使用
問題：間違ったCSRF対策～初級編～
脆弱性診断の学習のお供に、比較的簡単なCSRF対策バグの問題を提供します。この記事では問題のみを出し、想定解答は後日公開することにします。ネタバレとなるブックマークコメントやツイートなどは控えていただけると幸いです（「思いのほか簡単だった」など感想は可）。ブログ記事等に解説記事を書くことは歓迎いたします。 以下はテスト用に「ログインしたことにする」スクリプト（mypage.php）。ログイン状態で呼び出すこともでき、いずれの場合でもログインユーザのメールアドレスを表示します。 <?php // mypage.php : ログインしたことにする確認用のスクリプト session_start(); if (empty($_SESSION['id'])) { // ログインしたことにしてメールアドレスも初期化 $_SESSION['id'] = 'alice'; $_SESSION['mail'
クレジットカード情報盗み出しの手口をまとめた | 徳丸浩の日記
はじめに 先日の日記「ECサイトからクレジットカード情報を盗み出す新たな手口」は多くの方に読んでいただき、ありがとうございました。この記事では、「新たな手口」ではなく、従来からある手口についてまとめてみました。 1.SQLインジェクション 古典的な手法としてはSQLインジェクションがあります。下図のように、SQLインジェクション攻撃により、DBに保存されたクレジットカード情報を盗み出します。 攻撃が成立する条件は下記のとおりです。 DBにクレジットカード情報が保存されている ウェブサイトにSQLインジェクション脆弱性がある いずれも、現在の観点では論外の状況と言えますのでさすがに頻度は減っています。今年6月1日から施行されたカード情報非保持化により、今後はほとんど見られなくなると予想されます。過去の代表的な事例には以下があります。 エクスコムグローバル、SQLインジェクションで約11万件の
徳丸浩の日記: ECサイトからクレジットカード情報を盗み出す新たな手口
エグゼクティブサマリ 聖教新聞社が運営する通販サイト「SOKAオンラインストア」から2,481件のクレジットカード情報が漏洩した。リリースによると、漏洩に使われた手口は従来とは異なるもので、改正割賦販売法の実務上のガイドラインである「クレジットカード情報非保持化」では対策できないものであった。 はじめに 今年の9月4日に聖教新聞社の通販サイトSOKAオンラインストアからクレジットカード情報漏洩の可能性がリリースされました。以下は聖教新聞社から運営委託されているトランスコスモス株式会社のリリースです。 「ＳＯＫＡオンラインストア」の件 このたび、弊社が聖教新聞社様より運営を委託されている「ＳＯＫＡオンラインストア」において、クレジットカード情報を入力して商品をご注文いただいた一部のお客さまのクレジットカード情報が、第三者によって不正に取得された可能性があることが発覚い たしました。 http
安全なWebアプリケーションの作り方改訂のお知らせ
徳丸本こと、「体系的に学ぶ 安全なWebアプリケーションの作り方」は、2011年3月の発売以降大変多くの方に読んでいただきました。ありがとうございます。 ただ、発売から既に7年が経過し、内容が古くなってきた感は否めません。たとえば、クリックジャッキングの説明はほとんどないですし、OWASP Top 10 2017で選入された安全でないデシリアライゼーションやXXEの説明もありません。なにより、Web APIやJavaScriptのセキュリティ等がほとんど書かれていないことが課題となっていました。 そこで、版元のSBクリエイティブと相談して、この度改訂することにいたしました。3月末脱稿、6月頃発売の見込みです。 改訂にあたり、以下を考えています。 Web APIとJavaScriptに関する説明を4章に追加 XHR2対応に向けてCORSの説明を3章に追加 携帯電話の章は丸ごと削除して、別の内
[書評]サイバー攻撃 ネット世界の裏側で起きていること
中島明日香氏の近著『サイバー攻撃 ネット世界の裏側で起きていること』を読んだので紹介したい。本書は、一見すると入門者向けの初歩的なセキュリティ解説書の体裁をとっているが、その内部に著者の恐ろしい野望が秘められていると感じた。 重要事項説明 著者と評者には特筆すべき利害関係はない 評者は本書を自費で購入した（献本等ではない） この記事のリンクにはアフィリエイトが含まれる はじめに 本書は、ブルーバックスの１冊として、サイバーセキュリティの分野の、特に脆弱性について焦点をあて、入門的な解説を試みるものである。本書6ページから、「本書で扱う内容」の一節を引用しよう。 本書の目的は、適切なサイバー攻撃対策を講じる際の一助となることです。そこで、脆弱性そのものとそれを突く攻撃手法について、情報科学の知識を持たない人でも理解できるように、基本的なところから解説します。 この一節だけでも、本書の狙いが意
スマートフォンアプリケーションでSSLを使わないのは脆弱性か
このエントリでは、スマートフォンアプリケーションの通信暗号化の必要性について議論します。 はじめに 先日、スマートフォンアプリケーションのセキュリティに関するセミナーを聴講しました（2月8日追記。講演者からの依頼によりセミナーのサイトへのリンクをもうけました）。この際に、スマートフォンアプリケーションの脅威に対する共通認識がまだないという課題を改めて感じました。その課題を痛感できたという点で、セミナーは私にとっては有益でした。 このため、当ブログではスマートフォンアプリケーションの話題をあまり取り上げていませんでしたが、今後は、とりあげようと思います。まずは、スマートフォンアプリケーションでは暗号化を必須とするべきかという話題です。この話題は、前記セミナーでもとりあげられていました。 暗号化の目的は何か まず、暗号化の必要性を論じるためには、暗号化の目的を明確にする必要があります。前記セミ
安全でないデシリアライゼーション(Insecure Deserialization)入門 | 徳丸浩の日記
先日のブログ記事にて、Welcartのオブジェクトインジェクション脆弱性について説明しましたが、オブジェクトインジェクションという脆弱性自体の情報源があまりないので、入門記事を書こうと思い立ちました。 （2017/11/22追記） OWASP Top 10 2017に正式に公開され、そのA7に安全でないデシリアライゼーション (Insecure Deserialization) が入りました。これは、本稿で扱うオブジェクトインジェクションと同内容ですが、OWASPの表記にならい、タイトルを変更しました。 以下、「そんなプログラムあり得るか?」という現実性についてはあまり気にしないで、原理的にオブジェクトインジェクションがどのようなものかについて順を追って説明していきます。以下、PHP言語のケースを題材として具体例を提示しますが、概念自体は他の言語でも通用するものです。 シリアライズとオブジ
teratailに投稿されたメールフォームにCSRF脆弱性が残存した理由 | 徳丸浩の日記
teratailに以下のような投稿がありました。 PHPでメールフォームを作成したので、脆弱性がないかアドバイスいただけないでしょうか。 エンジニアでもなければ、PHPもろくに書けない雑魚ですが、「php メールフォーム 作り方」でググって表示されるサイトを見ると、「んんんんん？？？」と思うところがあります。 これらを参考にしたり、コピペする方は、記述されているコードの良し悪しは判断できないかと思います。 そのような方々が参考にできるメールフォームを作りたいという思いで、調べて作りました。 周りに書いたコードを確認してもらえる人もいないので、皆様からのアドバイスがほしいです((_ _ (´ω｀ )ﾍﾟｺ 【PHP】作成したメールフォームに脆弱性がないか、アドバイスもらえないでしょうかより引用 どれどれ…と確認すると、トークンのチェックが入っているにも関わらずクロスサイト・リクエストフォージ
SQLiteのクォートにまつわる奇妙な仕様
SQLiteでは、ISO SQL標準同様に、文字列リテラルはシングルクォートで囲み、識別子をクォートする場合は、ダブルクォートで囲むことになっています。 'foo' : 文字列リテラル "foo" : 識別子（テーブル名、列名等） しかし、マニュアルによると、SQLiteのクォーティングには例外があります。それを実例で紹介しましょぅ。まずは、実験の準備として、列 a だけを持つテーブル a を作成します。 $ sqlite3 test.db sqlite> CREATE TABLE a(a integer); sqlite> INSERT INTO a VALUES(1); sqlite> SELECT * FROM a; 1 sqlite> 続いて、以下を実行します。実行結果はどうなるでしょうか? sqlite> SELECT 'a', "a", [a], `a`, "aa" FROM
GodaddyのSSL証明書にドメイン認証の脆弱性があり8850件の証明書が失効された
エグゼクティブサマリ GoDaddy社の発行するドメイン認証SSL証明書に認証不備の脆弱性があり、予防的な処置として8850件の発行済証明書が失効された。これは同期間に発行された証明書の2%未満である。現在は脆弱性は解消されている。 概要 GoDaddy社は米国のホスティング（レンタルサーバー）やレジストラの大手で、認証局（CA）の事業も手がけています。 GoDaddyが発行するドメイン認証証明書の認証手続きに不備があったとして報告されています。 In a typical process, when a certificate authority, like GoDaddy, validates a domain name for an SSL certificate, they provide a random code to the customer and ask them to p
PHPのescapeshellcmdを巡る冒険はmail関数を経てCVE-2016-10033に至った
エグゼクティブサマリ 2011年始めに徳丸がescapeshellcmdの危険性を指摘したが、この問題はmail関数のadditional_parameters経由で攻撃可能であることが2013年末に指摘された。その後2016年末に、PHPMailerの脆弱性CVE-2016-10033として現実のものとなった 経緯 2011/1/1 徳丸が「PHPのescapeshellcmdの危険性」を書いて、クォート文字がペアになっている場合にエスケープしないという仕様が余計なお世話であり、危険性が生じていることを指摘 2011/1/7 大垣さんがブログエントリ「phpのescapeshellcmdの余計なお世話を無くすパッチ」にて修正案を提示 2011/10/23 廣川さんが、大垣さんのパッチ案を少し修正してbugs.php.netに提案。修正案は却下され、マニュアルを修正することに 2011/1
PHPMailerの脆弱性CVE-2016-10033について解析した
エグゼクティブサマリ PHPMailerにリモートスクリプト実行の脆弱性CVE-2016-10033が公表された。攻撃が成功した場合、ウェブシェルが設置され、ウェブサーバーが乗っ取られる等非常に危険であるが、攻撃成功には下記の条件が必要であることがわかった PHPMailer 5.2.17以前を使っている Senderプロパティ（エンベロープFrom）を外部から設定できる 現在出回っているPoCはMTAとしてsendmailを想定しており、postfixを使っている環境では問題ない 対策版として公開されている PHPMailer 5.2.19も不完全であるので、回避策の導入を推奨する。 はじめに 12月24日にPHPMalerの脆弱性CVE-2016-10033が公表され、とんだクリスマスプレゼントだと話題になっています。 PHPからのメール送信に広く使われているライブラリの「PHPMai
PDOに複文実行を禁止するオプションが追加されていた
エグゼクティブサマリ PHP 5.5.21、PHP 5.6.5 以降、PHPにPDO::MYSQL_ATTR_MULTI_STATEMENTSというオプションが追加され、PDO+MySQLの組み合わせで、SQLの複文を禁止できるようになった。この設定はSQLインジェクションの緩和策として有効である。 はじめに 2013年12月に公開した PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能 にて、PDOとMySQLの組み合わせで、SQLインジェクションの文脈で複文呼び出しが可能であることを報告していましたが、その後のPHPのバージョンアップで、複文実行を禁止するオプションが追加されていましたので報告します。 対象のバージョンは以下の通りです。 PHP 5.5.21 以降 PHP 5.6.5 以降 全ての PHP 7.0、7.1 前述の記事を書いた後、3大
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. ウェブサイトの所有権を検証しないで、正当な証明書が交付されるというものですね。脆弱性は報告の後数時間で修正されたとのことです。 以下、彼のブログ記事を元に、脆弱性の内容と修正方法について説明します。 問題
ウェブアプリケーションにおいて「ホワイトリスト」と"White List"は用法が異なる
海外（主に米国）のウェブアプリケーションセキュリティのドキュメントを読むと、"white list input validation" という言い方がたびたび出てきます。たとえば、OWASPのSQL Injection Prevention Cheat Sheetには、まさにWhite List Input Validationという節があります。 3.2 White List Input Validation Input validation can be used to detect unauthorized input before it is passed to the SQL query. For more information please see the Input Validation Cheat Sheet. 【私訳】 3.2 ホワイトリスト入力値検証 SQLクエリに渡
決済代行を使っていてもクレジットカード情報が漏洩するフォーム改ざんに注意
先日以下の記事が公開されました。決済代行会社を使っていたのにカード情報が漏洩したというものです。 同社は、薬局への医薬品の卸売りのほか、運営するショッピングサイト「eキレイネット」でコラーゲンやヒアルロン酸などの美容関連製品を販売している。流出した疑いがあるのは、平成26年10月8日～27年11月5日、サイトでカードを使って商品を購入した顧客の氏名や住所、クレジットカードなどの情報だった。この間、1955人が利用していた。 名の売れた大企業ではない。従業員わずか10人の小さな会社がサイバー攻撃の標的になったのだ。 問題が発覚したのは昨年11月。決済代行会社からカード情報が流出した疑いがあると指摘があった。 従業員10人なのに「標的」に サイバー攻撃、中小企業が狙われる理由より引用 これに対して、以下のブックマークコメントがつきました。 そもそも、決済代行会社を使っているのになぜカード情報が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
