開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
IEを華麗に撃墜する一行 - ぼくはまちちゃん！(Hatena)
はい！ こんにちは！！！！！ 今日は、偶然ブラクラ発見しちゃったから、それをお伝えしますね！ これだよ！ <style>*{position:relative}</style><table><input></table> → サンプル (IEだとブラウザが終了しちゃうよ！ 注意してね！) IE6とかIE6のコンポーネントブラウザだと確実に落ちちゃうみたいだね！ IE7は確認してないけど！ tableとかtrの直下に、inputとかselectがあって、 そのあたりにcssの全称セレクタでposition:relativeがあたっているとダメなかんじかな！ ちなみにinputにstyleで直接relativeあてても落ちなかったよ！ なにこれ！ よくわかんないけど面白いね…！ FirefoxとかOpera大好きっ子は、 これをたくさんバラまいてIEのシェアをどんどん下げちゃえばいいと思うよ！
情報処理推進機構：セキュリティセンター：脆弱性関連情報取扱い：安全なウェブサイトの作り方
IPAでは、ウェブサイト運営者が、ウェブサイト上で発生しうる問題に対し、適切な対策ができるようにするための注意事項として、『安全なウェブサイトの作り方』を取りまとめ、公開いたしました。 この資料は、昨年（2005年3月4日）にショッピングサイト運営者がウェブサイト上で発生しうる問題に対し、適切な対策ができるようにするための注意事項として発行した『消費者向け電子商取引サイトの運用における注意点』を、より広いウェブサイトの運営者に利用いただくことを目的に、内容の全面改訂を行ったものです。 『安全なウェブサイトの作り方』では、「ウェブアプリケーションのセキュリティ実装」として、IPAが届出を受けたソフトウエア製品およびウェブアプリケーションの脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、脆弱性の原因そのものをなくす根本的な解決策と、攻撃による影響の低減
高木浩光＠自宅の日記 - 対策にならないフィッシング対策がまたもや無批判に宣伝されている, 追記（26日）
■ 対策にならないフィッシング対策がまたもや無批判に宣伝されている 「PCからオンライン取引、ケータイで認証」−ソフトバンクBBの新発想・認証サービス, Enterprise Watch, 2007年9月20日 「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。本当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。（略） 「PCを標的にしたハッキングやDoS攻撃を受ける可能性がゼロになる」（中島氏）。また、偽サイトとはシンクロしないため、フィッシング詐欺を100％防止することも可能だ。 ソフトバンクBB、携帯活用認証システムでWebサイトログイン対応に, ケータイWatch, 2007年9月20日 今回の新機能は、安全・簡便・低コストで、そう
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CodeZine：Rubyを使ってWebアプリケーションの脆弱性を早期に検出する（Web, テスト, Ruby）
携帯で端末ID詐称は可能かもしれない話