CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん！
こんにちはこんにちは！！ 今日はCSRF脆弱性のちょっとした話です！ このCSRFってなにかっていうと、 サーバーへのリクエストを『誰かに勝手に送らせる』っていうセキュリティがらみの攻撃手法のひとつ。 わかりやすい例だと、 HTMLの画像タグを以下のようにしたページを誰かに教える。 <img src="何々SNSの足跡.php" width="1" height="1"> そうすると、そのページを「見た人」が何々SNSの足跡.phpにアクセスしたことになる。 ※詳しくはこちらのマンガで → ［はまちちゃんのセキュリティ講座］ここがキミの脆弱なところ…！ ： 第2回 しーさーふって何ですか？ CSRFってこんな風に、 「ログイン済みの人に何か操作させる」ってイメージが強くて、 対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。 例えば、勝手に日記に投稿させないように対
イー・アクセスのPocket WiFiに脆弱性、意図しない動作の恐れ
情報処理推進機構とJPCERT コーディネーションセンターは2月1日、イー・アクセスが提供するHuawei Technologies製のモバイル無線LANルータ「Pocket WiFi（GP02）」に脆弱性が見つかったと発表した。 それによると、ファームウェアバージョンが11.203.11.05.168およびそれ以前のGP02のWeb管理画面には、クロスサイトリクエストフォージェリの脆弱性が存在する。ユーザーがログインした状態で悪意あるページを読み込んだ場合、設定の初期化や再起動をさせられる可能性があるという。 イー・アクセスは同日付で脆弱性を解決した最新版ファームウェアを公開し、ユーザーに適用を呼び掛けている。
warszawa.jp - このウェブサイトは販売用です！ - warszawa リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
pixiv開発者ブログ:［不具合報告］意図しない作品へのコメントについて
2010年02月15日お知らせ pixiv事務局です。 このたび、一部ユーザー様の作品へのコメントが改ざんされたとの報告があり、弊社にて調査をいたしましたところ、「作品のコメント欄」の脆弱性を利用した不正が行われていた事実が判明いたしました。 本件の詳しい状況につきまして、下記の通りです。 ・経緯 2010年2月5日より2月14日までの間、一部ユーザー様の作品において、ユーザー様の意図によらないコメントが書き込まれた旨のお問い合わせを頂きました。 お問い合わせをいただいた後、該当する全てのサーバのログ・関連データベースを調査しましたところ、問題となったコメントの書き込みの前に、あるURLへアクセスし、外部サイトを経由をした後にコメントを投稿した形跡を発見しました。 また、本不具合を利用したアクセスを調査しましたところ、影響があったのは作品へのコメントの書き込みのみで、他の機能へ
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
twitterにクロスサイトスクリプティング(XSS)脆弱性があればパスワードを変更できる - ockeghem's blog
秋のDK収穫祭などで騒がれている、いわゆるDK祭り。 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 http://blog.livedoor.jp/dankogai/archives/50959103.html 現象から見てセッションハイジャックされたと思われるが、原因となる脆弱性が小飼弾氏の主張どおりCSRF(Cross Site Request Forgeries)だったのか、パスワードは窃取されたのか、元々のパスワードが類推しやすいものだったのかなど、議論を呼んでいる。 私は、現象からみて、原因となる脆弱性はCSRFではなく、XSSだったと思う*1。twitterにXSS脆弱性があれば、セッションハイジャックにより、第三者が小飼弾氏になりすまして発言するところまでは可能だ。しかし、一般的にはXSSではパスワードまでは窃取できない。id:ha
クロスサイト・リクエスト・フォージェリ
クロスサイト・リクエスト・フォージェリ（forgery＝偽造）は，踏み台サーバーを閲覧したユーザーから攻撃対象となっているWebサーバーに対し，閲覧者が意図していないHTTPリクエストを送らせる攻撃手法です。CSRF（またはXSRF）と呼ぶこともあります。 CSRFは，掲示板への書き込みを実行するURLをクリックさせるなどの攻撃手法として，比較的古くから知られています。2005年ころに，ログインが必要なWebサイトを攻撃対象としたCSRFが登場し始めたことから，大きな被害につながる恐れのある攻撃手法として認識されるようになりました。 攻撃者は踏み台サーバーに，攻撃対象サーバーへのリクエストを発行するリンクやスクリプトを挿入しておきます。このリンクやスクリプトは，踏み台サーバーを閲覧したユーザーのブラウザに送り込まれます。閲覧者が誤ってこのリンクをクリックするなどの操作をすると，攻撃対象サー
@IT: 「ぼくはまちちゃん」 ――知られざるCSRF攻撃
ある日、大手SNS（Social Networking Site）のmixiの日記にこのような書き込みがあった。それも1人だけでなく、同日に数多くのユーザーの日記に同じ文面が掲載されていた。 これは、単にこのような文章がはやり、ユーザー自身が意図して掲載したのではなく、ある仕掛けによってユーザー自身が気付かないうちに引き起こされた現象なのである。その仕掛けとは、CSRF（Cross-Site Request Forgeries）と呼ばれる攻撃手法の一種だ。 編集部注： 現在、「はまちちゃん」トラップは、mixi運営者により対策されています。上記のサンプルは、mixi風に再構成したものです。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください
GmailのCSRF脆弱性修正 - デベロッパもユーザもCSRFに対して認識を | エンタープライズ | マイコミジャーナル
Netcraftは9月30日(米国時間)、GoogleがGmailに存在していたクロスサイトリクエスト偽装(CSRF: Cross-site Request Forgery)に関する脆弱性問題を修正したことを発表した。これまでのGmailにはログインした状態のユーザに対して、メールフィルタを追加してメールを特定のアカウントへ転送することが可能な脆弱性があるとされていた。 今回修正されたCSRFだが、特別な脆弱性ではなくWebアプリケーションに存在する脆弱性として以前から存在する代表的なもののひとつ。特に最近Webアプリケーションを攻撃する場合によく使われる方法となっている。Webアプリケーションの普及にともない、CSRFを使った問題が今後ますます増えると思われる。 Gmailは代表的なWebアプリケーションだ。今回GMailにおいてCSRFの修正が実施されたことは啓蒙の点でも注目に値する。
Gmailにゼロデイの脆弱性情報、メール盗み見の恐れ - ITmedia Biz.ID
米GoogleのWebメールサービス「Gmail」に、他人のメールを盗み見できてしまう脆弱性が報告された。Googleをめぐっては、このほかにも複数のサービスでゼロデイの脆弱性情報が公開されている。 Gmailの脆弱性情報は、ハッカーサイトの「GNUCITIZEN」などで公開された。同サイトによれば、この問題を悪用するとクロスサイトリクエストフォージェリ（CSRF）攻撃を仕掛け、Gmailアカウントにバックドアをインストールして会話をすべて盗み見することができてしまうという。 ユーザーがGmailにログインした状態で悪質サイトを閲覧すると、バックドアがインストールされ、被害者のフィルタリストに新しいフィルタが作成される。例えば、添付ファイルが付いたメールを自動的に別のメールに転送するフィルタを作成することが可能だという。 この攻撃は非常に悪質であり、ユーザーが被害に気付くことはまずあり得な
Login GeneratorのSession Fixation Attack対策(2), Login GeneratorのSession Fixation Attack対策(3) - Journal InTime(2005-07-16)
_ Login GeneratorのSession Fixation Attack対策(2) これを回避するには以下のようにセッションをリセットしてやればよい。 [Journal InTime - CSRF対策 , Login GeneratorのSession Fixation Attack対策 , クッキーのパス , セッションファイルの作成場所より引用] 某所でセッションデータは引き継ぎたいという話があったのでちょっと改良。 def login case @request.method when :post user = User.authenticate(@params[:user_login], @params[:user_password]) if user @session[:user] = user data = @session.instance_variable_get
CSRF対策, Login GeneratorのSession Fixation Attack対策, クッキーのパス, セッションファイルの作成場所 - Journal InTime(2005-07-15)
_ CSRF対策 0.13.0にもCSRF対策のコードはとくにないようだ。 MLの議論を追ってなかったのだが、結局アプリケーション側で対策する べしということだろうか。 まず、ApplicationControllerとApplicationHelperに以下のような記述をしておく。 app/controller/application.rb: class ApplicationController < ActionController::Base private def validate_session if @params[:session_id_validation] == @session.session_id return true else render(:text => SESSION_VALIDATION_FAILED_HTML, :status => "403 Forbi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.monoweb.info/article/2012021823.html