トランザクショントークン メモ(Hishidama's struts transaction token Memo)
Strutsトランザクショントークン 画面遷移の順序性の確認や サブミットボタンの二度押し（重複サブミット）の防止チェックの為に、Strutsではトランザクショントークン（同期トークン）を使用する仕組みが用意されている。 トランザクショントークンの概要 トランザクショントークンの使用法 概要 トランザクショントークンは、以下のように実現される。 表示する画面の中にhiddenでランダムなID（トークン）を埋め込んでおき、そのトークンをサーバー側でもセッション内に保持しておく。 その画面でサブミットされると、hiddenに埋められていたトークンがリクエストに入れられてサーバーに届く。 サーバーでは、届いたhiddenのトークンとセッション内に保持していたトークンを比較する。一致していれば正しい遷移と判断する。 別の画面のhiddenには別のトークンが埋められている為、意図しない画面から来た場
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
クロスサイトリクエストフォージェリ (CSRF, XSRF) - 情報セキュリティWiki - セキュアなWebアプリケーション構築のために
Web Application ※今後はクロスサイトリクエストフォージェリー（CSRF, XSRF） | セキュリティゆいがどくそんにて記事を更新します… クロスサイトリクエストフォージェリ その名のとおり、サイトを跨って（クロスサイト）ユーザの要求（リクエスト）を偽装（フォージェリ）する攻撃手法です。 IT：セキュリティ用語事典[クロスサイトリクエストフォージェリ（CSRF）]より引用 想定していない外部のサイトからのHTTPリクエストにより、本来拒否すべき処理が実行させる攻撃。例えばログイン認証が必要な掲示板や日記サービスに対して、別のWebサイトに用意されたリンクをクリックすることで、掲示板への投稿や退会処理など、正規のアカウントでログインを行わなければできないような処理が実行されてしまう。 対策 サーバのセッションに紐付くトークンを使用する。 セッション管理と無関係な文字列では意味
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
azito.com
