「line://msg/text/～ 」からのLINEメッセージ送信の仕様が危険なので注意
LINEにて、「line://msg/text/」で始まるURLが拡散されています。このURLは、「指定された文章を送信するためのURL」で、「LINEで送る」ボタンの中身として利用されているURLなのですが、このURLから送信に至るまでの画面遷移で、送信内容の確認画面が無い仕様のため、自分が何を送信するのかを確認できないまま送信してしまい、意図と反した投稿を行ってしまう危険性があります。 何を送信するのかが表示されないまま先に進む画面の途中で止める判断ができれば問題にはならないのですが、LINEのユーザー層と、実際送信してしまった人が多数見つかること、そして、「次こそ送信内容の確認画面が出るだろう」と考えて先に進む人（←以前の仕様では表示された）、などなどを考慮すると、今後悪用された場合に大きな危険を招きそうな仕様であると感じました。 今回ユーザーが意図せず送信してしまうのは「ずっと前か
Endpoint Protection - Symantec Enterprise
過去数カ月、ソーシャルネットワークサイトへと誘導しようとするさまざまなスパム攻撃が確認されています。これらの攻撃のほとんどは、何らかのソーシャルエンジニアリング手法の特徴を備えていますが、ときとして、画期的なソーシャルエンジニアリング手法も登場しています。ここでは、そうした手法のなかでも、Facebook で特に重要な CSRF 対策トークンを盗み出そうとしてユーザーを欺く手口を紹介します。 クロスサイトリクエストフォージェリ攻撃 クロスサイトリクエストフォージェリ（CSRF）とは、ある Web サイトで認証済みのセッションを再利用して、ユーザーに気づかれないまま、または同意を得ずにその Web サイトで悪質な処理を実行する攻撃です。たとえば、ユーザーが自分のオンラインバンキングのサイトにログインしているとします。この Web サイトに CSRF の脆弱性があると、別の悪質な Web サイ
正しいCSRF対策のまとめ2012年版
そしてその手段としては iframeとjavascriptによってGETやPOSTをユーザーのクリックなしにエミュレートするcssで偽装したiframeによって、ユーザーが意図しないクリックを行うよう誘導するscriptタグによってJSONや部分的にjavascriptとして解釈可能なページを（攻撃者のサイトのページ内に）読み込むflashなどを使ってヘッダをエミュレートしたリクエストをブラウザ経由で行うがある。 他の手法はほとんどブラウザ側のsameoriginポリシー（ほかドメインに対するjavascriptでのajax要求は禁止される）で排除されるはずである。 これら全てを回避する方法として 何らかの処理を起動するような、ユーザのクリック（＝意思あるいは同意）を確認すべき全ての画面遷移とその前後で（ログインパスワード入力フォームを含む）で、ワンタイムトークンを発行・検証する。ワンタイ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
hsgw先生のXMLHttpRequestを使ったCSRF対策について
http://d.hatena.ne.jp/hasegawayosuke/20130302/p1 について サーバ側でセッション管理せずに済むというメリットはでかくていいですね。 ログインの有無も関係なくなるのでｶｸｲｲです。 これからの時代はこういうのが主流になるべきという気がします。 デメリットですが ・JavaScript必須（hsgw先生が書いているとおり） ・画面遷移に影響が出る。普通のPOSTと違うので、アプリの挙動に影響がある ・古いブラウザでは動かない という感じでしょうか。 追記： var s = encodeURIComponent( document.getElementById(“mail”).value ) + “&” + encodeURIComponent( document.getElementById(“msg”).value ); みたいに自分でフォーム
クッキーモンスターバグがあると、IPアドレス偽装防止のCSRF対策が回避される
日経Linux 2013年1月号に「“誤認逮捕”を防ぐWebセキュリティ強化術」を書き、それが今週4回連載で、ITproに転載されました。この中で、クロスサイトリクエストフォージェリ(CSRF)対策について説明しましたが、クッキーモンスターバグ(Cookie Monster Bug)がある場合に対策が回避されることに気がつきました。 それでは、どのような対策が望ましいかを考えてみると、中々難しい問題です。以下、その内容について検討します。 解決すべき課題の整理 記事の趣旨は、昨年無実の市民のパソコンからCSRFによる犯行予告が横浜市のサイトに書き込まれたことを受けて、サイト側でCSRF対策をして、なりすまし書き込みができないようにしようというものです。なりすましの犯行予告には、CSRFのほか、マルウェアを用いる方法、CSRF以外のWebサイトへの攻撃手法もあるので、CSRF対策だけで十分と
http://blog.monoweb.info/blog/2012/02/18/ruby-secure-web-app/
See related links to what you are looking for.
はてなグループの終了日を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の例と思われます）。 また、３つ目として、利用者からの投稿を受け付ける掲示板側にセキュリティー上の欠陥があった場合、利用者がウイルスに感染しなくても、書き込みをされるおそれがあります。 このうち、ＣＳＲＦ＝クロスサイトリクエストフォージェリと呼ばれる攻撃手法では、利用者に攻撃者が用意したホームページのリンクをクリックさせただけで、別の掲示板に文章を投稿させることが可能だということです。 この場合、利用者はクリックしただけなので、文章を投稿したことにはほとんど気付かないとい
CSRF脆弱性のあるフォーラムに犯罪予告を書き込んだとして人が逮捕される
CSRF脆弱性のあるフォームに犯罪予告を書き込んだとして人が逮捕されるニュースが流れた。ところが、どうもそのニュースにはきな臭いところがある。 というのも、その書きこまれたフォームには、CSRF脆弱性があるのだという。つまり、攻撃用のWebサイトを閲覧したものなら誰でも、犯罪予告の書き込みをおこなってしまう状況にあった。 もちろん、このブログを今読んでいるという事は、すでに攻撃が完了している可能性だってあるのだ。おっと、今ブラウザを閉じてももう遅い。確認のためには、ソースコードを読むべきである。 そのような脆弱性の存在するフォームへの書き込みをもとに逮捕するのは危険だ。無知によるものでなければ、邪悪な意図があるのだ。ただ、この場合は、無知によるものであろう。 さて、件の逮捕された被害者は、今、外部との連絡を遮断され、非人道的な方法で自白を迫られていることだろう。 犯行予告に使われたと思われ
ログイン機能への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 になっていて、アドレス
CSRF対策は基本? | 水無月ばけらのえび日記
コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや
OpenIDのライブラリにはCSRFに脆弱な物が多い
(Last Updated On: 2018年8月8日)GNUCitizenによると CSRF – It comes very handy. It seams that no matter how much you talk about it, very few pay attention on the problem. And it is not a problem that you can afford to have. And among the XSS issues, which most OpenID libraries have, CSRF (Cross-site Request Forgery) seams to be the most pervasive form of attack. http://www.gnucitizen.org/blog/hijacking-ope
クイズ:XSSとCSRFはどこにありますか? - ockeghem's blog
先の日記(XSSはブラウザ上でスクリプトが動き、CSRFはサーバー上でスクリプトが動く - ockeghem(徳丸浩)の日記)は、仕込んだネタがあたって多くの方に読んでいただいた。細かい内容については、頂戴した批判や反省もあるが、このテーマに対して多くの関心を集めることができたのは良かったと思う。今回も、手を変え品を変えて、XSSとCSRFの違いを説明しよう。ということで、今回はクイズ仕立てにしてみた。 といっても、非常に簡単なクイズだ。 認証を必要とする会員制サイトmaitter.comで、個人情報を入力する画面がある。典型的な、入力(A)-確認(B)-登録(C)という画面遷移（下図）を想定した場合、 XSSが発生しやすい画面を一つあげよ CSRFが発生しやすい画面を一つあげよ というものだ(入力画面は初期入力のみ想定)。エラー時の挙動などは指定されていないので想定しないものとする。 解
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全なPHPアプリケーションの作り方2014
http://cache.gyazo.com/b72c0672cc2ee2a3c498aa4c6ced4c4f.png
http://blog.monoweb.info/article/2012021823.html
結果発表 - 【20モリタポ】僕のサイト見てよ（＾ω＾；） - コッソリアンケートβ