Amazon.co.jp: 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践: 徳丸浩: 本
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
安全なセッション管理を実現するために
ログイン前とログイン後でセッションIDが変化しない セッション固定攻撃が成立する最後の条件はログイン前とログイン後でセッションIDが変化しないことだ。セッションIDを変化させるためには明示的な実装が必要となるから、意識して実装されていない限り条件が成立する可能性は高いといえるだろう。 ほかの条件については、独自に機能拡張されたアプリケーションサーバやフレームワークを使用するなど、複雑な対策が必要となるが、最後の条件だけは、容易な実装で対策することが可能である。 対策： ・ログイン成功時にセッションIDを再発行する セッションIDを変化させるには、ログインが成功したらセッションIDを再発行させればよい。再発行の時点でセッションIDは攻撃者にとって未知の値となるため、セッション固定攻撃は成功しなくなる。具体的には以下のような実装となる。 /** ログイン処理を実行して成功したらセッションを再発
[ThinkIT] 第4回：セッション乗っ取り (1/4)
今回はWebアプリケーションの脆弱性における3番目のカテゴリー「セッション乗っ取り」について解説する。 ※注意： この記事にはWebアプリケーションの脆弱性を解説する必要上、攻撃手口に関する情報が含まれています。これらの手口を他者が運営するWebサイトに向けて仕掛けると、最悪の場合刑事罰および損害賠償請求の対象となります。脆弱性の調査・検証は、必ずご自身の管理下のコンピュータシステムおよびローカルエリアネットワークで行ってください。この記事を参考にした行為により問題が生じても、筆者およびThinkIT編集局は一切責任を負いません。 Webアプリケーションのセッションとは、複数のWebページにまたがる会話処理のことである。たとえば「商品を選ぶ」「配達先を指定する」「カードで決済する」といった会話処理の流れがその例である。これらのページ間では適切に情報が引き継がれてゆくが、それは一連のHTTP
消臭力のCMが思ってた以上にやばい件 ニコニコVIP2ch
ニコVIPユーザー様、宇賀神でございます。 ポカポカ陽気になってきて、散歩でもしたくなりますね♪ それはそうと、最近女の子が重視しているのは、 「雰囲気がオシャレかどうか？」だそうです。 要はスタイルが良くても、服装がイマイチだったり、 口下手だったりするとウケが悪いのです。 オシャレな雰囲気を出す為には日々の鍛錬が必要ですね！ 特にシャツは女の子からの好感度は高しですぞ。 ⇒シャツの事は、宇賀神に訊けっ 1 以下、名無しにかわりましてVIPがお送りします 投稿日：2011/04/27(水) 00:38:13.64 ID:WdXg6YuB0 なんかわからんが最後で吹く 4 以下、名無しにかわりましてVIPがお送りします 投稿日：2011/04/27(水) 00:40:01.82 ID:q19oAFhE0 なんだこれｗｗｗｗ 2 以下、名無しにかわりましてVIPがお送りし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
