高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
高木浩光＠自宅の日記 - Winnyの問題で作者を罪に問おうとしたことが社会に残した禍根
■ Winnyの問題で作者を罪に問おうとしたことが社会に残した禍根 Winny作者が著作権法違反幇助の罪に問われている裁判の地裁判決がいよいよ明日出るわけだが、有罪になるにせよ無罪になるにせよ、そのこととは別に、独立事象として、Winnyネットワーク（および同様のもの）がこのまま社会に存在し続けることの有害性についての理解、今後のあり方の議論を進めるべきである。 著作権侵害の観点からすればさして致命的な問題ではないと考える人が大半だろう。しかし、情報セキュリティの観点からすると、流出の事故を防止しなければならないのと同時に、起きてしまった事故の被害を致命的でないレベルに止めることが求められる。 これまでに書いてきた通り、Winnyは、従来のファイル交換ソフトと異なり、利用者達が意図しなくても、多くの人が流通し続ける事態は非倫理的だと思うような流出データであっても、たらい回しにいつまでも流通
My RSS 管理人 ブログ : spamhaus.org に登録されてしまったら
サイドフィードの中の人（a++）のブログです RSS / Blog / SEO /SEM についての所感や雑感をまとめています。 実は先日「あとで読む」などを運営しているサーバーがネットワークごと spamhaus に登録されてしまいました。 丁度こんな記事があったので、こちらがとった対応を簡単にご紹介。 spamhaus.orgをはじめとするIPアドレスベースのブラックリスト(RBL)を使ってはいけない spamhaus を使っているところは非常に多いらしく、登録された日から異常な量の返信メールが届きました。 こんな感じです。 The original message was received at Sat, 21 Oct 2006 22:14:29 +0900 from localhost [127.0.0.1] ----- The following addresses had p
高木浩光＠自宅の日記 - ログイン前Session Fixationをどうするか
■ ログイン前Session Fixationをどうするか 21日の日記「Session Fixation脆弱性の責任主体はWebアプリかWebブラウザか」で、ブラウザベンダはCookie Monster問題をどうするのだろうかということについて書いたが、Firefox 2.0 について調べてみたところ、解決していなかった。また、IE 7 も解決していない。 そのような状況では、セッション追跡がcookieだけによって行われている場合であっても、Session Fixation攻撃に対して配慮せざるを得ない。 これまで、Session Fixation対策といえば、ログイン後の状態をセッションハイジャックされることの防止のみが語られることが多かったが、ログイン前についてはどうだろうか。 たとえば、ログイン前から使えるショッピングカートに対してSession Fixation攻撃が行われると
隠されていたSQLインジェクション ― ＠IT
星野君は赤坂さんと一緒にお客さんのWebアプリケーションの検査をすることになった。辛うじて「不必要情報」の脆弱性を見つけたものの、赤坂さんは不満げだ。 「だって、これ、ほかにもっと危険な脆弱性あるよ……」。 赤坂さん 「ってことで、今回は50点ってとこかな」 星野君 「うわっ。厳しいですね……。一応脆弱性は見つけたんだからもう少し……」 赤坂さん 「え。だって、これ、ほかにもっと危険な脆弱性あるよ」 星野君 「（ほかにも脆弱性あるっていってもなぁ……）」 赤坂さんに「ほかにもっと危険な脆弱性あるよ」と指摘されたにもかかわらず、星野君にはサッパリ見当が付かなかった。不必要情報（Unnecessary Information）の脆弱性に気付くまでの作業で、一通り思い付くことはやりつくしていた。 そうこうしているうちに時間は過ぎ、結局ほかの脆弱性を見つけられないまま、お客さんと約束した時間になっ
安全なセッション管理を実現するために ― ＠IT
HTTPを使用したWebアプリケーションにおいて、安全なセッション管理を行うことは難しい問題である。タブブラウザによる画面の複数起動や、Webブラウザの戻るボタン／更新ボタンの押下といった、予期しない画面遷移に起因するバグの発生に頭を悩ませることは多いだろう。 大きな問題が発生しないならば、画面遷移の仕様上の制限をクライアントに許容してもらう選択肢もあるだろうが、不正な画面遷移を利用したセキュリティホールが存在するならば、放置しておいてよい問題ではなくなる。今回はセッション管理を安全に行うための基本的な注意点について解説していこう。 セッション固定攻撃とは何か セッション固定攻撃（Session Fixation）という脆弱性を耳にしたことはあるだろうか。脆弱性そのものの詳しい解説は本稿の趣旨ではないため割愛するが、簡潔に説明すると、以下のような手順を踏むことによりセッション情報がハイジャ
メールアドレスの登録チェックが、余計なお世話に？
メールアドレスの登録チェックが、余計なお世話に？：星野君のWebアプリほのぼの改造計画（8）（3/4 ページ） 重複させたくなければ、重複を許容すればいい？ 星野君 「（メールアドレスが流出しただけでもニュースになるくらいだからこれは問題だろうな……）」 1つ脆弱性を見つけることができた時点で、赤坂さんが話し掛けてきた。 赤坂さん 「何か見つけられた？」 星野君 「あ、はい。1つだけですけども……」 赤坂さん 「そかそか。じゃあ、まだ終了までちょっと時間あるけど、いったん見つけた脆弱性確認しよっか」 星野君 「はい」 星野君には、一瞬赤坂さんの顔が曇ったように見えたが、ひとまず見つけた脆弱性の現象やどういった悪用方法が考えられるかなどを説明した。 赤坂さん 「お。ちゃんとそれ見つけたんだね。じゃあ、どういうふうに直したらいい？」 星野君 「えっと……。そこまで考えてなかったです……」 赤坂
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://neta.ywcafe.net/000678.html