bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点
宅ふぁいる便から平文パスワードが漏洩した件を受けて、あらためてパスワードの安全な保存方法が関心を集めています。現在のパスワード保存のベストプラクティスは、パスワード保存に特化したハッシュ関数（ソルトやストレッチングも用いる）であるbcryptやArgon2などを用いることです。PHPの場合は、PHP5.5以降で使用できるpassword_hash関数が非常に便利ですし、他の言語やアプリケーションフレームワークでも、それぞれ用意されているパスワード保護の機能を使うことはパスワード保護の第一選択肢となります。 なかでもbcryptは、PHPのpassword_hash関数のデフォルトアルゴリズムである他、他の言語でも安全なハッシュ保存機能として広く利用されていますが、パスワードが最大72文字で切り詰められるという実装上の特性があり、その点が気になる人もいるようです（この制限はDoS脆弱性回避が
徳丸浩の日記: 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）はファイアウォールで隔離されているため外部から直接
徳丸浩の日記: ECサイトからクレジットカード情報を盗み出す新たな手口
エグゼクティブサマリ 聖教新聞社が運営する通販サイト「SOKAオンラインストア」から2,481件のクレジットカード情報が漏洩した。リリースによると、漏洩に使われた手口は従来とは異なるもので、改正割賦販売法の実務上のガイドラインである「クレジットカード情報非保持化」では対策できないものであった。 はじめに 今年の9月4日に聖教新聞社の通販サイトSOKAオンラインストアからクレジットカード情報漏洩の可能性がリリースされました。以下は聖教新聞社から運営委託されているトランスコスモス株式会社のリリースです。 「ＳＯＫＡオンラインストア」の件 このたび、弊社が聖教新聞社様より運営を委託されている「ＳＯＫＡオンラインストア」において、クレジットカード情報を入力して商品をご注文いただいた一部のお客さまのクレジットカード情報が、第三者によって不正に取得された可能性があることが発覚い たしました。 http
PHPの脆弱性 CVE-2018-17082 によるキャッシュ汚染についての注意喚起
エグゼクティブサマリ PHPの脆弱性CVE-2018-17082はXSSとして報告されているが、現実にはXSSとしての攻撃経路はない。一方、Apacheのmod_cacheによるキャッシュ機能を有効にしているサイトでは、キャッシュ汚染という攻撃を受ける可能性がある。 概要 PHPの現在サポート中のすべてのバージョンについて、XSS脆弱性CVE-2018-17082が修正されました。以下は対応バージョンであり、これより前のすべてのバージョンが影響を受けます。ただし、Apacheとの接続にApache2handlerを用いている場合に限ります。 PHP 5.6.38 PHP 7.0.32 PHP 7.1.22 PHP 7.2.10 PHP 5.5以前も対象であり、これらは脆弱性は修正されていません。 脆弱性を再現させてみる この脆弱性のPoCは、当問題のバグレポートにあります。 PHP ::
安全なWebアプリケーションの作り方改訂のお知らせ
徳丸本こと、「体系的に学ぶ 安全なWebアプリケーションの作り方」は、2011年3月の発売以降大変多くの方に読んでいただきました。ありがとうございます。 ただ、発売から既に7年が経過し、内容が古くなってきた感は否めません。たとえば、クリックジャッキングの説明はほとんどないですし、OWASP Top 10 2017で選入された安全でないデシリアライゼーションやXXEの説明もありません。なにより、Web APIやJavaScriptのセキュリティ等がほとんど書かれていないことが課題となっていました。 そこで、版元のSBクリエイティブと相談して、この度改訂することにいたしました。3月末脱稿、6月頃発売の見込みです。 改訂にあたり、以下を考えています。 Web APIとJavaScriptに関する説明を4章に追加 XHR2対応に向けてCORSの説明を3章に追加 携帯電話の章は丸ごと削除して、別の内
teratailに投稿されたメールフォームにCSRF脆弱性が残存した理由 | 徳丸浩の日記
teratailに以下のような投稿がありました。 PHPでメールフォームを作成したので、脆弱性がないかアドバイスいただけないでしょうか。 エンジニアでもなければ、PHPもろくに書けない雑魚ですが、「php メールフォーム 作り方」でググって表示されるサイトを見ると、「んんんんん？？？」と思うところがあります。 これらを参考にしたり、コピペする方は、記述されているコードの良し悪しは判断できないかと思います。 そのような方々が参考にできるメールフォームを作りたいという思いで、調べて作りました。 周りに書いたコードを確認してもらえる人もいないので、皆様からのアドバイスがほしいです((_ _ (´ω｀ )ﾍﾟｺ 【PHP】作成したメールフォームに脆弱性がないか、アドバイスもらえないでしょうかより引用 どれどれ…と確認すると、トークンのチェックが入っているにも関わらずクロスサイト・リクエストフォージ
WordPress 4.7.1 の権限昇格脆弱性について検証した
エグゼクティブサマリ WordPress 4.7と4.7.1のREST APIに、認証を回避してコンテンツを書き換えられる脆弱性が存在する。攻撃は極めて容易で、その影響は任意コンテンツの書き換えであるため、重大な結果を及ぼす。対策はWordPressの最新版にバージョンアップすることである。 本稿では、脆弱性混入の原因について報告する。 はじめに WordPress本体に久しぶりに重大な脆弱性が見つかったと発表されました。 こんな風に書くと、WordPressの脆弱性なんてしょっちゅう見つかっているという意見もありそうですが、能動的かつ認証なしに、侵入できる脆弱性はここ数年出ていないように思います。そういうクラスのものが久しぶりに見つかったということですね。 WordPress、更新版で深刻な脆弱性を修正 安全確保のため情報公開を先送り Make WordPress Core Conten
MACHIDA.KANAGAWA.JPはなぜ「まぎらわしい」のか
私は検証用にいくつかのドメイン名を登録していますが、そのうちの一つが「発掘」され、世間をお騒がせすることになってしまいました。 このページのページビューは、8月16日(金) 9:00現在で、31438となっています。ずいぶんよく参照されています。ちなみに、「本物の」町田市のホームページは下記の通りです。 しかし、上記のような主張はいままでにもあったし、今更二番煎じのこのネタが、上記のような簡素な内容で話題になる理由としては、やはり MACHIDA.KANAGAWA.JPというドメイン名にあるのでしょう。これは「都道府県型JPドメイン名」というもので、「日本国内に住所を持つ個人・組織であれば、いくつでも登録ができます」（こちらより引用）。 では、どうして紛らわしいドメイン名が登録できるかという理由を説明します。 都道府県型JPドメイン名ができる前に地域型JPドメイン名というものがあり、多くの
Joomla!の「ゼロデイコード実行脆弱性」はPHPの既知の脆弱性が原因
Joomla!にコード実行脆弱性(CVE-2015-8562)があり、パッチ公開前から攻撃が観測されていたと話題になっています。 Joomlaに深刻な脆弱性、パッチ公開2日前から攻撃横行 「Joomla!」に再び深刻な脆弱性、3.4.6への速やかなアップデートを推奨 パッチ公開の前に攻撃が始まる状態を「ゼロデイ脆弱性」と言いますが、それでは、この脆弱性のメカニズムはどんなものだろうかと思い、調べてみました。 結論から言えば、この問題はJoomla!側に重大な脆弱性はなく、PHPの既知の脆弱性(CVE-2015-6835)が原因でしたので報告します。 exploitを調べてみる 既にこの問題のexploitは公開されていますが、悪い子が真似するといけないのでURL等は割愛します。以下のページでは攻撃の原理が説明されています。 Vulnerability Details: Joomla! Re
WordPressの侵入対策は脆弱性管理とパスワード管理を中心に考えよう
この記事はWordPress Advent Calendar 2015の7日目の記事です。 今年初めてWordCamp Tokyoにて講演の機会をいただき、WordPressのセキュリティについて話しました（スライド）。そこでもお話ししましたが、WordPressに限らず、Webサイトへの侵入経路は2種類しかありません。それは以下の2つです。 ソフトウェアの脆弱性を悪用される 認証を突破される したがって、侵入対策としては以下が重要になります。 全てのソフトウェア（OS、Apache等、PHP、WordPress本体、プラグイン、テーマ等）を最新の状態に保つ パスワードを強固なものにする 以上! と叫びたい気分ですが、それではシンプル過ぎると思いますので、以下、WordCampでお話した内容とリンクしながら、もう少し細く説明したいと思います。 全てのソフトウェアを最新の状態に保つ Word
嵐のコンサートがあるとダブルブッキングしてしまうホテル予約システムを作ってみた
今年の5月1日に、仙台市内のホテルで多重予約のトラブルが発生したと報道されています。 部屋数２０３室の仙台市のビジネスホテルで、９月１８～２３日の宿泊予約を数千件受け付けるトラブルがあった。アイドルグループ「嵐」のライブが宮城県内で開催される期間だった。インターネットでの申し込みが殺到し、システム障害が起きたとみられるという。 トラブルがあったのは、仙台市泉区の「ホテルルートイン仙台泉インター」。ホテルなどによると、９月１９、２０、２２、２３日に宮城スタジアム（宮城県利府町）で嵐がライブを開くことが明らかになった後の５月１日午前５時ごろ、ネットを使った予約申し込みが殺到していることに気づいたという。 ２０３室のホテルなのに「予約」数千件 嵐公演で殺到か：朝日新聞デジタル より引用 5月1日の朝に何があったのか調べてみると、この日の早朝にテレビや新聞でコンサートの情報が流れたようですね。 お
PHPのbasename関数は不正な文字エンコーディングをチェックしない
昨日のエントリにて、PHPのbasename関数はマルチバイト文字を扱えることを説明しましたが、このブログの読者であれば、きっとbasename関数は不正な文字エンコーディングについてどの程度チェックするのかという疑問が生じたことでしょう（きっぱり）。実はbasename自体は、不正な文字エンコーディングをチェックせず、垂れ流してしまいます。その理由をbasenameのソースコードで確認してみましょう。以下は、basename関数の実装の一部です。 // ext/standard/string.c // php_basenmae() while (cnt > 0) { inc_len = (*c == '\0' ? 1: php_mblen(c, cnt)); switch (inc_len) { case -2: case -1: inc_len = 1; php_ignore_valu
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 であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
自宅の鍵を定期的に取り替える佐藤君（仮名）の話
パスワードの定期的変更について元々違和感を持っています。今まで、理詰めでその違和感を解明しようとしてきましたが、それでも私の頭のなかのもやもやをうまく説明できたわけではありません。そこで、パスワードの定期的変更を「自宅の鍵を定期的に変更する比喩」を用いて、そのもやもやを説明したと思います。比喩によって精密な議論ができるとは思っておりませんので、あくまでも主観的な「もやもや」を説明する方便として読んでいただければ幸いです。ここに登場する佐藤は架空の人物です。 徳丸: 佐藤君は自宅の鍵を定期的に取り替えていると聞いたんだけど、本当? 佐藤: 本当ですよ。毎年に替えています。毎年年末に鍵を取り替えて、安心な気持ちで新年を迎えるんです。徳丸さんは替えてないんですか? 徳丸: 替えないよ。鍵を落としたりしたらまた別だけど、そういうのでもなければ替えないよね。佐藤君はなぜ毎年替えるの? 佐藤: だって
パスワードの定期的変更はパスワードリスト攻撃対策として有効か
パスワードリスト攻撃の対策として、パスワードの定期的変更に意味があるのかという議論があります。私は（利用者側施策としては）実質意味がないと思っていますが、まったく意味がないというわけでもありません。 このエントリでは、パスワードの定期的変更がパスワードリスト攻撃に対してどの程度有効かを検討してみます。 前提条件 パスワードリスト攻撃を以下のように定義します。 別のサイトから漏洩したアカウント情報（ログインIDとパスワードの組み合わせ）の一覧表（パスワードリスト）があり、そのログインIDとパスワードの組をそのまま、攻撃対象に対してログイン試行する攻撃 パスワードの定期的変更の一例として以下の条件を前提とします 利用者は、すべてのサイトのパスワードを90日毎に変更する 利用者はすべてのサイトで同じログインIDを用いている 変更後のパスワードはすべてのサイトで同じとする ※ サイト毎にパスワード
よくわかるPHPの教科書 PHP5.5対応版のクロスサイト・スクリプティング
たにぐちまことさんの よくわかるPHPの教科書がこのたび改版されて、よくわかるPHPの教科書 【PHP5.5対応版】として出版されました。旧版はmysql関数を使ってSQL呼び出ししていましたが、mysql関数がPHP5.5にて非推奨となったための緊急対処的な内容となっているようです。つまり、従来mysql関数を呼び出していた箇所をmysqliの呼び出しに変更したというのが、主な変更点のようで、これ以外はあまり変更点は見あたりません。 既に、Amazonでは、熱烈な読者の方からの詳細のレビューが届いています。 神本御降臨！ 言わずと知れたPHPプログラミング書籍のロングセラー。 2010年9月に発売された前作の改訂版。 PHPのバージョンも最新の5.5に対応、内容は前作と殆ど同じ。 少し前に前作を購入した方も本書を購入した方がいいでしょう。 【中略】 それにしても、帯の「３万人に読まれた定
正規表現によるバリデーションでは ^ と $ ではなく \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]+$/
IE9以降でもHTMLフォームでファイル名とファイルの中身を外部から指定できる
昨日の日記「IE8以前はHTMLフォームでファイル名とファイルの中身を外部から指定できる」にて、福森大喜さんから教えていただいた内容として、ファイルアップロードのHTMLフォーム（enctype="multipart/form-data"）にて、アップロードするファイル名とファイルの中身を外部から指定できることを報告しました。この際にIE8以前という条件がありましたが、今度は、三井物産セキュアディレクションの望月岳さんから、「それIE9以降でもできるよ」と教えていただきました。既にご存じだったそうです。福森さん、望月さんという日本を代表するバグハンターから「秘伝のたれ」をおすそわけいただいたようで、興奮気味ですw まず、おさらいとして、IE8以前でのパターンは下記の通りでした（要点のみ）。 <form enctype="multipart/form-data" action="pro_ad
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
