CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かったYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
クッキーモンスターバグがあると、IPアドレス偽装防止のCSRF対策が回避される
日経Linux 2013年1月号に「“誤認逮捕”を防ぐWebセキュリティ強化術」を書き、それが今週4回連載で、ITproに転載されました。この中で、クロスサイトリクエストフォージェリ(CSRF)対策について説明しましたが、クッキーモンスターバグ(Cookie Monster Bug)がある場合に対策が回避されることに気がつきました。 それでは、どのような対策が望ましいかを考えてみると、中々難しい問題です。以下、その内容について検討します。 解決すべき課題の整理 記事の趣旨は、昨年無実の市民のパソコンからCSRFによる犯行予告が横浜市のサイトに書き込まれたことを受けて、サイト側でCSRF対策をして、なりすまし書き込みができないようにしようというものです。なりすましの犯行予告には、CSRFのほか、マルウェアを用いる方法、CSRF以外のWebサイトへの攻撃手法もあるので、CSRF対策だけで十分と
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
なりすまし犯行予告に悪用可能なWebアプリケーション脆弱性
なりすまし犯行予告が話題になっています。現在問題になっているものは、マルウェアが使われているようですが、それ以外に、無線LANの乗っ取りや、Webアプリケーションの脆弱性悪用などの手法があります。NHKの報道では、クロスサイトリクエストフォージェリ(CSRF)脆弱性が、過去に悪用された事例が紹介されています（ただしmixiの例と思われます）。 また、３つ目として、利用者からの投稿を受け付ける掲示板側にセキュリティー上の欠陥があった場合、利用者がウイルスに感染しなくても、書き込みをされるおそれがあります。 このうち、ＣＳＲＦ＝クロスサイトリクエストフォージェリと呼ばれる攻撃手法では、利用者に攻撃者が用意したホームページのリンクをクリックさせただけで、別の掲示板に文章を投稿させることが可能だということです。 この場合、利用者はクリックしただけなので、文章を投稿したことにはほとんど気付かないとい
hostsファイルに127.0.0.1を指定した場合のCSRF対策回避の可能性
Kazuho Oku @kazuho @ockeghem same origin policyとクッキーのドメイン分離は別概念なので、127.0.0.1に外部のホスト名を指定することは、後者の分離を侵すと思います。なので、理屈の上では問題が発生する可能性があると思います（続く） 2012-09-25 09:45:57 Kazuho Oku @kazuho @ockeghem たとえば、cookieの値とhiddenフィールドの値の同一性を確認する方式のCSRF対策は、クッキーのドメイン分離が保証されている場合(hostsをいじっていない場合)有効な方法です。が、hostsをいじると攻撃が成立する可能性がでてきます 2012-09-25 09:47:34
ログイン機能へのCSRFによるセッション固定 - 知らないけどきっとそう。
危険なのかよくわかんないですけど、はてダ初め書きます http://ido.nu/ayaya/yj.html（対策されてた！） iframe 内で http://login.yahoo.co.jp/config/login に logout=1 を POST して強制的にログアウト状態にする ログインフォームの form タグ部分をスクレイピングし、あらかじめ用意しておいた Yahoo! JAPAN ID とパスワードを埋め込む その HTML を iframe にロードし、submit() で POST させることにより、用意しておいたアカウントでログインさせる メールで「住所情報を更新しないとアカウントが消えます」とか書いて誘導したら、どのくらい釣れるかなあ あーあと、個人情報の入力だけじゃなくて、OAuth の認可とか権限を与える操作もまずい ページは SSL になっていて、アドレス
pixiv開発者ブログ:［不具合報告］意図しない作品へのコメントについて
2010年02月15日お知らせ pixiv事務局です。 このたび、一部ユーザー様の作品へのコメントが改ざんされたとの報告があり、弊社にて調査をいたしましたところ、「作品のコメント欄」の脆弱性を利用した不正が行われていた事実が判明いたしました。 本件の詳しい状況につきまして、下記の通りです。 ・経緯 2010年2月5日より2月14日までの間、一部ユーザー様の作品において、ユーザー様の意図によらないコメントが書き込まれた旨のお問い合わせを頂きました。 お問い合わせをいただいた後、該当する全てのサーバのログ・関連データベースを調査しましたところ、問題となったコメントの書き込みの前に、あるURLへアクセスし、外部サイトを経由をした後にコメントを投稿した形跡を発見しました。 また、本不具合を利用したアクセスを調査しましたところ、影響があったのは作品へのコメントの書き込みのみで、他の機能へ
URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる
12月10日にPC版がスタートしたサイバーエージェントのミニブログサービス「Amebaなう」で、あるURLをクリックすると、「こんにちは こんにちは!!」というフレーズとクリックしたURL文字列が自動で投稿され、「はまちや2」さんのアカウントを自動でフォローしてしまうという現象が広がった。 URLをクリックしたユーザーが意図しない機能を実行させられるWebアプリの脆弱性の一種・クロスサイトリクエストフォージェリ（CSRF）を突いたもの。同社は10日夜、URLをクリックしないようユーザーに告知。誤ってクリックした場合は投稿を削除し、はまちや2さんのフォローを外すよう呼び掛けた。11日朝までに脆弱性も修正したという。 mixiでも2005年、あるURLをクリックすると「ぼくはまちちゃん！」という日記が勝手に投稿されるという、CSRFを利用したスパムが流通したことがあった。コミュニティーサイト構
ドコモはiモードIDの生成方法を見直すべきだ « mpw.jp管理人のBlog
昨年、「iモードID」の送出が開始されたことにより、「iモードID」のみでユーザ認証を行う携帯サイトが増えてきました。 そして、それら携帯サイトの中に、iモードIDハイジャック（悪意もった第三者による乗っ取り操作）の被害を受けると思われるサイトが、多数散見されます。 被害を受けるサイトの条件 ユーザ認証を「iモードID」のみで行っている。 FORMの入力内容をPOSTメソッドで送信しているものの、受け取り側でリクエストメソッドのチェックを行っていない。もしくは、GETメソッドで送信している。 iモードIDハイジャックの方法 以下のような形で登録処理を行っている攻撃対象サイト(targetdomain.com)を探す。 [http://targetdomain.com/form.php] <html> 会員登録開始<br> IDとパスワードとメアドを入力してください<br> <form me
Webアプリの落とし穴に改めて注意
今年9月，Gmailにクロスサイト・リクエスト・フォージェリ（CSRF）のぜい弱性が見付かった。ユーザーはメールを盗み見される危険にさらされていた。また，10月にはバッファローの無線LAN製品「AirStation」に組み込まれている設定ツール（Webアプリケーション）に存在するCSRFのぜい弱性が発見された。第三者にAirStationの設定を勝手に書き換えられる可能性があった。 これらのぜい弱性は， ユーザーがWebアプリケーションにログインした状態で，攻撃者が用意した悪意のあるリンクを誤ってクリックすると，ユーザーが予期しない処理を実行されてしまうというもの。Gmailなら例えば勝手にフィルタ・プログラムを作成して任意のアドレスにメールを転送するなどの仕組みを実現できる。 グーグルは既にこのぜい弱性を修正済みだが，万が一，利用者のフィルタ・リストに攻撃者が作成したフィルタが存在してい
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Pocket WiFi（GP02）」にCSRFの脆弱性、ファームウェアのアップデートを 
はてなブログ | 無料ブログを作成しよう