XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
[話題][刑事事件] 遠隔操作事件・真犯人と称する者からのメール全文 08:28 / 2012-10-21 - 弁護士 落合洋司 （東京弁護士会） の 「日々是好日」
既に報道されているように、私に対し、上記のようなメールが、 【遠隔操作事件】私が真犯人です という件名で送られてきましたが、関心が高まっていることや、既に一部で（不完全なまま）公開されつつあることも考慮し、全文をここに公開しておきます。 なお、個人名、URL、メールアドレス等で、支障があると考えられるものは、赤字の括弧書きで差し替えてあります。 以下、全文です。 ■はじめに 現在報道されている大阪・三重の遠隔操作ウィルス事件について、私が犯人です。 このメールには犯人しか知り得ない事実、つまり「秘密の暴露」が多く含まれているので、 このメールを警察に持っていって照会してもらえば、 私が本物の犯人であることの証明になるはずです。 ■私の目的 「犯行予告で世間を騒がすこと」 「無実の人を陥れて影でほくそ笑むこと」 などではなく、 「警察・検察を嵌めてやりたかった、醜態を晒させたかった」という動
![[話題][刑事事件] 遠隔操作事件・真犯人と称する者からのメール全文 08:28 / 2012-10-21 - 弁護士 落合洋司 （東京弁護士会） の 「日々是好日」](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
CSRFによる冤罪、誤認逮捕か。大阪市ウェブに大量殺人予告での逮捕の件: ホットコーナー
ブログ(iiyu.asablo.jpの検索) ホットコーナー内の検索 でもASAHIネット(asahi-net.or.jp)全体の検索です。 検索したい言葉のあとに、空白で区切ってki4s-nkmrを入れるといいかも。 例 中村(show) ki4s-nkmr ウェブ全体の検索 ASAHIネット(http://asahi-net.jp )のjouwa/salonからホットコーナー(http://www.asahi-net.or.jp/~ki4s-nkmr/ )に転載したものから。 --- 橋下徹市長の大阪市のウェブで「大量殺人をする」と投稿したという容疑で、 アニメ演出家が逮捕された件。 たとえば、 http://mainichi.jp/select/news/20120827k0000m040038000c.html 殺人予告:大阪市ＨＰに書き込んだ疑いで４２歳演出家逮捕 http://
クロスサイト・リクエスト・フォージェリ
Webサイトへの攻撃手法は，日々巧妙になっている。クラッカが会員制サイトのユーザーを装ってWebサイト上の情報を変更したり消去したりするには，ユーザーIDとパスワードの組や，Cookieで管理しているセッションIDを盗む必要があると思うかもしれない。しかし，それは間違い。クロスサイト・リスエスト・フォージェリという手口を使えば，こうした情報なしに，Webサイトのユーザーになりすまして不正アクセスできる。 クロスサイト・リクエスト・フォージェリとは，Webサイトにログイン中のユーザーのパソコンをスクリプトで操ることで，Webサイトに被害を与える攻撃手法である。「フォージェリ」（forgery）とは「偽装」の意味。つまりサイトをまたがってリクエストを偽装する攻撃といえる。2005年4月，ソーシャル・ネットワーク・サービスの「mixi」がこの攻撃を受けた。mixiは，会員の日記に勝手な書き込みが
ITmedia エンタープライズ：大量の「はまちちゃん」を生み出したCSRFの脆弱性とは？
「mixi」上で、あるURLをクリックすると「ぼくはまちちゃん！」という日記が勝手にアップされてしまうという現象が多発した。その原因はCSRFの脆弱性だ。 4月19日以降、ソーシャル・ネットワーキングサイトの「mixi」で、URLをクリックすると勝手に「ぼくはまちちゃん！」というタイトルで日記がアップされてしまうという現象が多発した。 サービスを提供しているイー・マーキュリーでは、この現象について一応の対処は取った模様だ。ただ、技術的な詳細については「ハッキングでもなく、サーバ攻撃やウイルスでもない。ID盗難などの被害は発生していない」という回答のみで、「それ以上はコメントできない」と述べるにとどまっている。 だがある意味、このコメントは正しい。「はまちちゃん」現象は、ウイルスなどの仕業ではないからだ。 正規ユーザーの操作で「意図しない」結果に URLをクリックすると勝手に日記が書き込まれ
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
第2回 しーさーふって何ですか？ | gihyo.jp
※ src： 画像の場所を指定する属性。相対パスではなくURLで書けば、他のドメインにある画像を表示することも可能。つまりURLに対してGETリクエストを行う（閲覧者に行わせる）お手軽な手段とも言え、これを用いてなんらかの攻撃が行われることもしばしば。 まとめ このように、imgタグなどによって、閲覧者のブラウザからどこかのURLへ任意のリクエストを「送らせる」ことは簡単にできてしまいます。しかも、それで発生するリクエストは、閲覧者自身がリンクをクリックしたときとなんら変わりはありません。では、これを攻撃として用いられた場合（つまりCSRF）、Webプログラム側ではどのように防げばよいのでしょう。 きっとまっさきに思いつくのは、「POSTリクエストを使うようにする」、あるいは「リファラヘッダ（リンク元が記載されているヘッダ行）のチェックを行う」などでしょうか。しかしそれだけでは不
@IT: 「ぼくはまちちゃん」 ――知られざるCSRF攻撃
ある日、大手SNS（Social Networking Site）のmixiの日記にこのような書き込みがあった。それも1人だけでなく、同日に数多くのユーザーの日記に同じ文面が掲載されていた。 これは、単にこのような文章がはやり、ユーザー自身が意図して掲載したのではなく、ある仕掛けによってユーザー自身が気付かないうちに引き起こされた現象なのである。その仕掛けとは、CSRF（Cross-Site Request Forgeries）と呼ばれる攻撃手法の一種だ。 編集部注： 現在、「はまちちゃん」トラップは、mixi運営者により対策されています。上記のサンプルは、mixi風に再構成したものです。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
第2回 意図しない操作をさせられる「クロスサイト・リクエスト・フォージェリ」
今回はセッションに関連したぜい弱性について解説する。まずは，クロスサイト・リクエスト・フォージェリ（CSRF）を取り上げよう。 CSRFのぜい弱性とは，「サイト利用者が意図しないところで，何らかの情報変更を無理やり実行させられてしまう」問題のことである。例えば，「自分の名前で勝手にブログに書き込まれる」，「パスワードがいつのまにか書き換えられる」などといった問題が発生することになる。 攻撃は次のように実行される。 ユーザーが，ターゲット・サイト http://target.example.com にログインする。 http://target.example.comのサーバーが，ユーザーのブラウザにクッキーをセットする。 ユーザーが，メールによる誘導などによって，罠を仕掛けられた攻撃者のサイト http://attacker.example.com にアクセスする。 罠の例：ブログへの意図し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
