安全なウェブサイトの作り方改訂第7版の変更点と変わらない点
IPAの安全なウェブサイトの作り方 改訂第7版が公開されました。 このエントリでは、安全なウェブサイトの作り方の元々もつ特徴（変わらない点）と、第7版の変更のポイントについて説明します。 なお、私は安全なウェブサイトの作り方の執筆者の一人ではありますが、以下の記述は私個人の意見であり、IPAを代表するものではありませんので、あらかじめご承知おきください。 安全なウェブサイトの作り方の変わらぬ特徴 安全なウェブサイトの作り方の特徴は、「まえがき」の中で述べられています。 本書は、IPAが届出を受けたソフトウェア製品およびウェブアプリケーションの脆弱性関連情報に基づいて、特にウェブサイトやウェブアプリケーションについて、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、その根本的な解決策と、保険的な対策を示しています。 すなわち、以下の2点がポイントと考えます。 脆弱性の選定
Webアプリケーション脆弱性診断の検査対象をどう絞り込めばよいか
ソニーDNAさんの『入門！基礎からわかる「失敗しないWeb診断業者の選び方」』というブログ記事を読みました。 全体的に穏当な内容で異論はないのですが、興味深い内容なので、屋上屋を架すようですが少し追加して考えてみたいと思います。 私が特に注目したのは以下の箇所です。 2. 検査対象を適切に絞れるか？ セキュリティ対策をくまなく実施できれば安心ですが、それは大きな費用がかかり現実的ではないというケースも多いでしょう。そのため、Web診断では検査対象を適切に絞り込むことが必要です。ログイン画面や課金機能、個人情報管理機能など、セキュリティ対策が特に求められる機能を重点的に検査するには、検査対象を明確にすることが重要になります。 上記の考え方は、脆弱性診断の現場でよく行われているもので、筆者もこれに従うことは多いのですが、検査対象の選定は重要なのでもう少し掘り下げて考えてみたいと思います。 脆弱
PHPのbasename関数でマルチバイトのファイル名を用いる場合の注意
まずは以下のサンプルをご覧ください。サーバーはWindowsで、内部・外部の文字エンコーディングはUTF-8です。UTF-8のファイル名を外部から受け取り、Windowsなのでファイル名をShift_JISに変換してファイルを読み込んでいます。basename関数を通すことにより、ディレクトリトラバーサル対策を施しています。 <?php header('Content-Type: text/plain; charset=UTF-8'); $file_utf8 = basename($_GET['file']); $file_sjis = mb_convert_encoding($file_utf8, 'cp932', 'UTF-8'); $path = './data/' . $file_sjis; var_dump($path); readfile($path); しかし、ディレクトリト
EximのGHOST脆弱性の影響とバリデーションの関係
追記(2015/2/6) 大垣さんから訂正依頼のコメントを頂いておりますので合わせてお読みください。徳丸としては特に訂正の必要は感じませんでしたので、本文はそのままにしています。そう思う理由はコメントとして追記いたしました。 (追記終わり) 大垣さんのブログエントリ「GHOSTを使って攻撃できるケース」を読んだところ、以下のようなことが書いてありました。 1. ユーザー入力のIPアドレス（ネットワーク層のIPアドレスではない）に攻撃用データを送る。 2. バリデーション無しで攻撃用の不正なIPアドレスをgethostbyname()に渡される。 3. ヒープオーバーフローでヒープ領域のメモリ管理用の空きサイズを改竄する。 【中略】 どんなソフトウェアが危ないのか？ ユーザー入力のIPアドレスをバリデーションしないでgethostbyname()を使用している。 インタラクティブな動作を行っ
徳丸浩の日記
日経BPから4月4日発売予定の『はじめて学ぶ最新サイバーセキュリティ講義 「都市伝説」と「誤解」を乗り越え、正しい知識と対策を身につける』の監訳を担当したので紹介させていただきます。 本書の原書は、ユージーン・H・スパフォード、レイ・メトカーフ、ジョサイヤ・ダイクストラの3名の共著として書かれた「Cybersecurity Myths and Misconceptions」で、米国Amazonのレビューでは4.6の高評価を得ています。また、「インターネットの父」ことヴィントン・サーフ氏が本書に前書きを寄せています（後述）。 はじめにサイバーセキュリティは、その短い歴史にも関わらず、神話や都市伝説に満ちています。古典的なものとして、本書の冒頭では、「ウイルス対策企業が自社製品を売るためにマルウェアを作って拡散した」が紹介されています。 本書は、このようなセキュリティの都市伝説や神話をとりあげ
SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
ログインアラートはパスワード定期的変更の代替となるか
パスワードの定期的的変更には実質的にはあまり意味がないのではないかという議論（疑問）から出発した議論を続けておりますが、こちらなどで表明しているように、パスワードの定期的変更が効果をもつ場合もあります。 そこで、本稿ではパスワードの定期的変更の代替手段としてログインアラートの運用に着目し、ログインアラートの運用がパスワードの定期的変更の代替となるのか、残る課題は何かについて検討します。 パスワード定期的変更の効果まとめ まず前提条件について説明します。ウェブサイトAの利用者xが自身のパスワード voc3at を定期的変更として変更する（voc3atはあくまで例です）場合、これが効果を発揮する条件と効果は、以下と考えられます。条件1と条件2はAND条件です。 条件1: パスワード voc3at が既に漏洩していて、今後悪用される可能性がある 条件2: パスワード漏洩に利用者 x は気づいてお
IPAから「クリックジャッキング」に関するレポート出ました
Webアプリケーションのセキュリティの分野で「新しい攻撃手法」は実はそれほど多くないのですが、比較的新しく対応が求められているものとしてクリックジャッキングがあります。クリックジャッキングは、CSRFと同じように「Webアプリケーションのサーバー側機能」を利用者（被害者）に実行させる手法です。CSRFは、当該機能を実行するHTTPリクエストを送信させる罠を使いますが、クリックジャッキングの方は、iframe等に当該機能を呼び出す画面を表示しておき、利用者（被害者）に実行ボタンを押させる（=クリックジャック）手法です。クリックジャッキングに関しては従来詳しい解説がありませんでしたが、この3月26日にIPAから「クリックジャッキング」に関するレポートが公開されました。 このレポートから、クリックジャッキングのイメージを示す図4を引用します。 サイトAが攻撃対象のサイト、悪意のあるページは罠にな
パスワードリマインダが駄目な理由
昨日、某著名サイトのパスワードリマインダの方式が変更になっていることに気がつきました。 旧: 現在のパスワードをメールで送信する（パスワードリマインダ） 新: パスワード再設定の画面のURLをメールで送信する（パスワードリセット） 新しい方式（パスワードリセット）の方が優れていますが、それでは何故パスワードリマインダは駄目で、パスワードリセットの方がよいのでしょうか。このエントリではその理由について説明します。 パスワードリマインダのリスク 良く指摘されるように、パスワードリマインダの場合、２つの問題があります。 現在のパスワードをメール送信できるということは、パスワードをハッシュ値で保存していない証拠である メールは平文通信なので、パスワードを書いたメールが盗聴されると被害が甚大になる これらのうち、パスワードの保存方法については別稿にゆずるとして、このエントリでは盗聴のリスクについて検
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
パスワードの定期的変更はパスワードリスト攻撃対策として有効か
パスワードリスト攻撃の対策として、パスワードの定期的変更に意味があるのかという議論があります。私は（利用者側施策としては）実質意味がないと思っていますが、まったく意味がないというわけでもありません。 このエントリでは、パスワードの定期的変更がパスワードリスト攻撃に対してどの程度有効かを検討してみます。 前提条件 パスワードリスト攻撃を以下のように定義します。 別のサイトから漏洩したアカウント情報（ログインIDとパスワードの組み合わせ）の一覧表（パスワードリスト）があり、そのログインIDとパスワードの組をそのまま、攻撃対象に対してログイン試行する攻撃 パスワードの定期的変更の一例として以下の条件を前提とします 利用者は、すべてのサイトのパスワードを90日毎に変更する 利用者はすべてのサイトで同じログインIDを用いている 変更後のパスワードはすべてのサイトで同じとする ※ サイト毎にパスワード
気づけばプロ並みPHP 副読本：お助け電子BOOKへの寄稿の顛末
谷藤賢一さんの著書『気づけばプロ並みPHP~ショッピングカート作りにチャレンジ! 』に、発売1周年の謝恩キャンペーンとして『副読本：お助け電子BOOK』が公開されました(*1)。私はこの副読本の中で、『第2章 【徳丸 浩氏 スペシャル寄稿】安全なWebアプリケーションのために』を寄稿しています。このエントリでは、寄稿の顛末を報告したいと思います。 動機 私が本書『気づけばプロ並みPHP』を購入したのは昨年の10月29日ですから、本書が出版されてまもなく、今から約1年前です。私は本書を一読して、セキュリティ上の多数の問題があることに気がつきました。 以前は、セキュリティ上の問題が多い本は書評をブログ記事として書くことも多かったのですが、この際は書評という形にするのはためらいがありました。その理由は以下の様なものです。 私のブログの読者層はセキュリティに関心の高い方たちであり、本書の読者とは重
模倣サイトとして各所から注意喚起が出されているサイトについて徳丸さんに聞いてみた
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、今話題の『模倣サイトとして各所から注意喚起が出されているサイト』についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず問題のサイトですが、NTT東日本、NTTドコモ、日本銀行、外務省、総務省など様々なサイトを模倣したサイトが見つかっていて、各社、各省庁が注意喚起をしているというものです。詳しくは、北河拓士さんのまとめをごらんください。 徳丸: これ、総務省のサイトだと、http://www.soumu.go.jp.○○○.org/ のように、ドメイン名の先頭が本物と同じだし、中身も同一だしで、見た人がびっくりしたのでしょうね。 高橋: はい。これはパクリのサイトではないのですか? 徳丸: パクリではありません。PROXYサーバーの一種で、元のサイトのアクセスして、その内容をそ
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
Apache killerは危険～Apache killerを評価する上での注意～
Apacheの脆弱性(CVE-2011-3192)いわゆるApache killerが話題になっていますが、その脅威については一部誤解があるようです。 以下は、非常に脅威とする報告の例です。 一方今回のはプロセスの肥大化を伴うので、実メモリ消費して更にスワップも使い尽くしてOS毎激重になったあげくLinuxとかの場合はOOM Killer発動と、他のプロセスや場合によってはOSを巻き込んで逝ってしまいます。 CVE-2011-3192 Range header DoS vulnerability Apache HTTPD 1.3/2.xより引用 以下は、それほど脅威でなかったとする報告の例です。 pooh.gr.jp は結構頑丈だったので 60 並列でやっと CPU idle 30% まで減らせた。 Apache Killer (CVE-2011-3192) 対策 for CentOS 5
とあるECサイトのアクセス制御不備
商売柄、脆弱性や侵入事件のニュースがあると背景を調べることが多いのですが、このエントリは、侵入されたサイトを見に行って発見した脆弱性のお話です。 とあるECサイトが外部から侵入されたというニュースを見て、再開後のECサイトを見に行きました。普通に会員登録してログインしてみると、セッションIDの他に気になるクッキーが発行されていました（クッキーの名前と値は変えてあります）。 Set-Cookie: login=123456; path=/ Set-Cookie: loginflg=1; path=/ 直感的に、login=123456は内部的なユーザID(ユーザ番号)、loginflg=1はログイン済みであることを示すフラグのように思えました。しかし、まさかね。今時それはありえないアルよ。 そこで検証のために、先ほどとは別のユーザを登録してログインしてみました。すると、以下のクッキーが発行さ
ANAマイレージクラブのログインを少しでも安全にする運用を考えてみたが見つからない
既に「ANAの不正ログイン事件について徳丸さんに聞いてみた」で書いたように、ANAマイレージクラブ(AMC)のWebサイトに不正アクセスがあり、利用者 9人、計112万マイルがiTunesギフトコードに不正交換されました。ITproの記事を引用します。 ANAに申告があった9人分、計112万マイルについて、3月7～9日の間にiTunesギフトコードへ交換されていたことを確認したという。【中略】同社は10日18時30分以降、iTunesギフトコードへの交換サービスを停止した。不正ログインの手段など攻撃の詳細や、他にも不正ログインがあったかについては調査中という。 ニュース - ANAマイレージクラブへの不正ログインで112万マイルが詐取、住所なども閲覧可能に：ITproより引用 攻撃があってから一週間たちますが、まだANAに申告があった利用者の被害しか発表されていません。上記9名以外にも、マ
ANAの不正ログイン事件について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。先月に引き続き徳丸さんをお招きして、今度はANAの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。「ANAマイレージクラブ」のWebサイトに不正ログインがあり、顧客9人のマイレージ、総計112万マイルがiTunesギフトコードに勝手に交換されていたとするものです。当初顧客の通報で発覚した点はJALの場合と同じですね（参考）。 徳丸: で、私はなにをしゃべればいいのですかね。お招きいただいたので出てきましたが、パスワードがJALは数字6桁、ANAは4桁ですが、それ以外はあまり変わらないのですよね。 高橋: JAL、ANAと事件が続きましたが、攻撃手口は見えてきていないのでしょうか? 徳丸: 公式発表も報道もあまり情報がないので確定的なことは言えないのですが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
慎重に扱うべきコンテンツに関する警告
