Popular Websites Vulnerable to Cross-Site Request Forgery Attacks
Freedom to Tinker Research and commentary on digital technologies in public life Update Oct 15, 2008 We’ve modified the paper to reflect the fact that the New York Times has fixed this problem. We also clarified that our server-side protection techniques do not protect against active network attackers. Update Oct 1, 2008 The New York Times has fixed this problem. All of the problems mentioned belo
Cross Site Printing
(Last Updated On: 2008年1月11日)クロスサイトスクリプティングと同じ要領でネットワークプリンタに接続して印刷してしまう「Cross Site Printing」と呼ばれている手法が公開されています。 <img src=”myprinter:9100/Print_from_the_web”> ポート9100でネットワークプリンタが印刷できる状態で待機しているので印刷できてしまいます。クロスサイトリクエストフォージェリと同じようなもの、と言った方が分かりやすいかも知れません。PDFにはFAXの送信方法も記載されています。 Cross Site Printingの仕組みは単純ですが根本的な対策は簡単ではありません。
「メールを読むだけでルーターが設定変更される」、驚異の新攻撃出現
米シマンテックは2008年1月22日（米国時間）、ブロードバンドルーターの設定を勝手に変更する悪質なメールが確認されたとして注意を呼びかけた。メールを開くだけでルーターのDNS設定が変更され、ある銀行のWebサイトにアクセスしようとすると、偽サイトへ誘導される恐れがある。その結果、個人情報などを盗まれる危険性がある。 WebページやHTMLメールに悪質なHTMLとJavaScriptを仕込んで、それらを閲覧したユーザーのブロードバンドルーターの設定を変更する攻撃は「ドライブバイ・ファーミング（Drive-by Pharming）」と呼ばれる。 この攻撃では、ブロードバンドルーターのDNS設定を変更し、攻撃者のDNSサーバーなどを参照させるようにする。これにより、ファーミング詐欺を可能にする。具体的には、ユーザーが本物のWebサイトのURLをWebブラウザーに入力しても、攻撃者が意図した偽サ
Webアプリの落とし穴に改めて注意
今年9月，Gmailにクロスサイト・リクエスト・フォージェリ（CSRF）のぜい弱性が見付かった。ユーザーはメールを盗み見される危険にさらされていた。また，10月にはバッファローの無線LAN製品「AirStation」に組み込まれている設定ツール（Webアプリケーション）に存在するCSRFのぜい弱性が発見された。第三者にAirStationの設定を勝手に書き換えられる可能性があった。 これらのぜい弱性は， ユーザーがWebアプリケーションにログインした状態で，攻撃者が用意した悪意のあるリンクを誤ってクリックすると，ユーザーが予期しない処理を実行されてしまうというもの。Gmailなら例えば勝手にフィルタ・プログラムを作成して任意のアドレスにメールを転送するなどの仕組みを実現できる。 グーグルは既にこのぜい弱性を修正済みだが，万が一，利用者のフィルタ・リストに攻撃者が作成したフィルタが存在してい
CSRFのはなし - teracc’s blog
ひさびさの更新です。 CSRFTesterというツールを試した Category:OWASP CSRFTester Project - OWASP 頑張ってCSRF脆弱性の検査をしてくれるツールだと思って期待して試したのですが、残念ながら違いました。 このツールの動作は以下のようなものです。 Proxyツールとして動作して、リクエストを記録する。 記録したリクエストパラメータをユーザがGUI上で変更できる。 変更したリクエストパラメータを送信するようなフォームHTMLを作成する。 使ってみると、日本語のパラメータがおかしくなったりします。まあそれはそれとして、この程度の機能なら通常のProxyツールを使った検査で十分な気がします。 私が期待していたのは、最初に書いたように、CSRF脆弱性が存在する箇所を特定する（しようと試みる）ツールです。 そのためには、 CSRF対策が必要なリクエストを
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
特集：クライアントステート管理、3つの手法
状態保存にビューステートを使う Webアプリケーションにおける通信は、一般的にHTTPというステートレスなプロトコルに基づいたものだ。 ASP.NETのセッション状態機能は、SessionIDをクッキーに保存したりページのURLに埋め込んだりすることで実現されたHTTPのステートレスな世界からの抜け道だと言えよう。この共有されるセッションキー（SessionID）は、その後、リクエストを発生したブラウザにおいて、サーバに保存されたデータを関連づけるために用いられる。 幾つかの場面では、セッション状態を要求することが必要無い時や望ましくないケースがある。共通テクニックは、次のように、フォームのフィールドにデータを隠して保存することだ。 クライアントサイドでがページをSUBMITし、HTTPのPOSTやGETリクエストがサーバに向けて発生した場合には、このデータはPOSTのボディデータやクエリ
Piece Frameworkを試した - teracc’s blog
Piece FrameworkはPHPのフレームワークです。 セキュリティに強い、そして日本人が開発している、というのが特徴のようです。 【PHPウォッチ】第34回 セキュアでロバストなPHPフレームワーク「Piece Framework」：ITPro Piece Framework - A stateful and secure web application framework for PHP 早速触ってみました。 概要 以下の3つの要素から構成されます。 Piece_Unity: 基本 Piece_Right: Validation Piece_Flow: フロー制御 一番の売りは、フロー制御のようです。これを使うと、Webアプリ開発者が意識せずとも、CSRF脆弱性を持たないフォームを作れます。 デモサイトでフロー制御を体験 デモサイトが用意されています。 Piece Framewo
hide-k.net#blog: Catalyst::Plugin::RequestToken
StrutsでいうところのAction#generateToken, Action#resetToken, Action#isValidTokenメソッドと同様の機能をCatalystに提供するプラグインを書いてみました。 調子に乗ってCPAN登録してみました。 要はアプリケーションにSubmitの二重送信による二重登録防止とCSRF防止をさせるためにTokenを埋め込む仕組みです。 WEBアプリケーションでありがちな 入力→確認→結果 というような画面遷移において、「確認」画面でTokenを生成してクライアントにはhiddenタグなどで、Tokenを埋め込み、サーバーではSessionに保持しておいて、「結果」画面において、validateとTokenの無効化を行うことによって、「結果」画面から「確認」画面にブラウザのバックボタンで戻って再度submitした場合などのtransactio
[Struts] Transaction Token
サブミットボタンの二度押し、ページ遷移の割り込み、ブラウザの戻るボタンによる処理再実行といった微笑ましいユーザオペを根こそぎシャットダウン。ものすごく幸せになれます。エンドユーザ様におかれましては、何度でも「戻るボタン」押してその美しいエラーメッセージを堪能いただきたいほどです。 気持ちいいあまり、トークン設定と比較を Input → Validate にまで仕込んだら、入力内容ミスでページを戻ってという正常処理まで「不正なページ遷移処理が行われました」と言われました。ううむ恐るべしトランザクショントー君（＜当たり前 1. ValidateするAction でまずトークンを設定 public final class SampleValidateAction extends Action { public ActionForward execute( ActionMapping mappin
![[Struts] Transaction Token](https://cdn-ak-scissors.b.st-hatena.com/image/square/126e9c63960837b5815901e11e1f6c1303c17f2b/height=288;version=1;width=512/https%3A%2F%2Fblog.seesaa.jp%2Fimg%2Fogp_logo.png){kind=logo}
Flash による Referer 偽装攻撃の有効性 - おおいわのこめんと(2006-11-08)
■ [Security] Flash による Referer 偽装攻撃の有効性 なんか僕が海外に出かけるとなにかしらの事件が起こっている気がする……。とりあえず今回の件は、単純に Flash の脆弱性なんで、とっとと update しましょう、まる。 で、Flash の実験環境がないので試せないでいるし、アドバイザリもまだちゃんと読んでいないのだが、あくまで一般論として言えば XMLHTTP のようなインタフェースを提供されている状態で、Referer が設定できるだけではセキュリティへの影響は限りなく低い。むしろ、ほかのヘッダが設定できる方がやばい。Flash の脆弱性に特異な状況があればぜひ知らせてほしい。 実際、この件は昨年9月の XMLHTTP インタフェース経由の Content-Length 偽装による Request Splitting 脆弱性をレポート した際に Bugzi
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://portal.spidynamics.com/blogs/developersecurity/archive/2006/08/23/191.aspx