Amazonのすごいアクセス解析サービス - ぼくはまちちゃん！
こんにちは！ Amazonほしい物リスト、すごい話題になってますね！ なんでも、メールアドレスで検索すればAmazonに登録してある本名がでてくる (ケースもある) とか…。 で、さっそくぼくも試してみたよ！ ほしい物リストサーチ！ これって、いま話題になっているのは、誰かのメールアドレスを手がかりにして ウィッシュリストや本名、下手すると住所まで知られてしまうってところだよね。 それだけでも面白いんだけど、 あまり注目されていない機能として、こんなものがあったよ。 友だちにほしい物リストについて知らせる これ。 自分のほしい物リストを誰かにメール送信できちゃう機能らしいね！ じゃあ試しにメール送信時のリクエストを確認してみると… http://www.amazon.co.jp/gp/registry/send-nudge.html?ie=UTF8&type=wishlist&__mk_j
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
はてなスターの認証強化について - はてなスター日記
先ほど、はてなスターの仕組みを変更し、正常なはてなスターのコード以外で☆が付けにくくなりました。 これまでの仕様では、画像（img）タグなどに☆を追加するためのURLを仕込ませるだけで、そのページにアクセスしただけで☆をつけたことになってしまうなどの問題が発生していましたが、今回の変更により、セッションごとに暗号化された文字列を追加でやりとりするようになり、意図しない☆がつきにくい仕組みになりました。 なお、既存のはてなスターを設置のユーザー様は、特に設定の変更などは必要ございません。 新しい仕様でも、JavaScriptが実行可能な環境で意図的にスクリプトを仕込むことで意図しない☆が付く動作を実行させることが可能ですが、はてなダイアリーやグループなどのJavaScriptを自由に書くことができない環境ではこのようなことはできなくなっています。 はてなスターでは、外部のブログサイトなど様々
クロスドメインのHTML読み取り(IEのバグ CSSXSS）とCSRF
(Last Updated On: )追記：このブログを記載する理由となったURLを記載された方が内容を削除されたようです。「間違っている」と言われるのは心外である、と思ったことは確かですがページの内容が削除されるのは私の本意ではありません。書かれていた情報はとても役に立つ情報だと思います。非常に残念なので再度掲載されることを望みます。（本当 —– セキュリティ対策ではよくあることですが、条件の見落としによりセキュリティ対策を行っていても脆弱性が発生することがあります。「Webアプリセキュリティ対策入門」に書かれているCSRF対策にも「クロスドメインのHTML読み取り(IEのバグ）」の問題が修正されていない為、書籍に記載した対策を行ってもバグを持つIEに対してはCSRFに脆弱になります。 しかし、このバグの影響を持って「Webアプリセキュリティ対策入門」のCSRF対策を「間違った対策」と書
なぜCSSXSSに抜本的に対策をとることが難しいか - いしなお! (2006-03-31)
_ なぜCSSXSSに抜本的に対策をとることが難しいか CSSXSSの説明について、その脅威を過剰に表現している部分がありました。その部分について加筆訂正しています。 @ 2006/4/3 tociyukiさんによる「[web]MSIE の CSSXSS 脆弱性とは何か」および「[web]開発者サイドでの CSSXSS 脆弱性対策」には、より正確なCSSXSS脆弱性の内容およびそれに対するサーバーサイド開発者で可能な対策について紹介されていますので、是非そちらもご覧ください。 @ 2006/4/4 今までも何度かこの辺の話はあまり具体的ではなく書いてきたけど、そろそろCSSXSSを悪用したい人には十分情報が行き渡っただろうし、具体的な話を書いてもこれ以上危険が増すということはないだろうから、ちょっと具体的に書いてみる。 ちなみに私自身は、CSSXSSの攻撃コードなどを実際に試したりといった
おさかなラボ - CSRF対策法と効果
自分でもう一度整理するために、他のサイトに倣って現在挙げられているCSRF対策法とその効果を列挙してみる。ざっと書いたので多分ツッコミどころ満載だと思うがとりあえず公開。現在思いつく最善解は一番下に書いた。あとは順不同。 POSTを用いる 推奨: とりあえず 効果: あり 回避法: あり(Javascriptによる自動Submitなど) 実装: 簡易 副作用: なし 確かにPOSTでのCSRFを破る手法は存在するが、だからといってこの対策に全く効果がないわけではない。完了画面への直接リンクでのCSRFの発生は抑制できる。実装が簡単な上、副作用が特にないので実装しておいて別に損はない。 リファラ(Referer: ヘッダ)をチェックする 推奨: ケースバイケース 効果: 大 回避法: 特になし 実装: やや難(コードに汎用性を持たせるのが難しい) 副作用: ブラウザ
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
