フィッシングサイトへの自動入力のリスク SMS OTPとWebサイトが紐付かない状態では、正規のSMS OTPがフィッシングサイトへ自動入力されるリスクが生じる。現実的なリスクとして、GutmannらはMITMと組み合わせた「ログインにおける2要素認証の回避」と「ソーシャルログインの偽装による電話番号確認の回避」、「オンライン決済における取引認証の回避」の3つのシナリオを示している⁷。2要素認証の回避につながるリスクは、iOSの自動入力がPayPayの偽サイトで発動した前回の検証で確認している。今回の検証ではAndroidの自動入力がPayPalの偽サイトで発動するか確認する。 2要素認証の回避 PayPalの偽サイトは前回と同様にMITMフィッシングフレームワーク「Evilginx2」で複製し、一般利用者が誤ってアクセスしないようインバウンド接続を制御した。Android 11のChro
GitHubがWebAuthn対応を開始。MacのTouch IDやWindows Helloの指紋認証などを2要素認証に利用可能に[訂正あり] GitHubは、Web標準仕様「WebAuthn」への対応開始を発表しました。 Remember when fingerprint authentication seemed like the future? Starting today, secure access to your code with a fingerprint, facial recognition, and more. Two-factor authentication that's more secure and easier than ever to usehttps://t.co/VUEQenjERD — GitHub (@github) August 21, 201
「ループURL貼って補導」「Coinhive逮捕」に、“JavaScriptの父”ブレンダン・アイク氏も苦言 JavaScriptのループ機能を使った“ブラクラ”のURLを書き込んだ3人が摘発され物議。昨年には、JavaScriptを使った仮想通貨採掘プログラム「Coinhive」設置者が逮捕された。これらの事件について“JavaScriptの父”ブレンダン・アイク氏が意見を述べ注目を集めている。 JavaScriptのループ機能を使ってポップアップが繰り返し表示されるサイトのURLを掲示板に書き込んだとして、不正指令電磁的記録(ウイルス)供用未遂の疑いで中学生が補導され、男性2人が家宅捜索を受けた事件がネットで波紋を呼んでいる。「これだけで補導や家宅捜索はやり過ぎだ」と警察を批判する声も強い。 似た事件として昨年、JavaScriptのプログラムを使い、サイト閲覧者に仮想通貨をマイニング
パスワードを不要にするFIDO2プロトコルに、Android 7以降の全デバイスが適合。FIDOアライアンスが「AndroidがFIDO2認定取得」と発表 FIDOアライアンス(ファイドアライアンス)は、ユーザー認証の仕組みとして一般的に使われているユーザーIDとパスワードの組み合わせを止め、顔認証や指紋認証、PINコードなどを用いることによりパスワードを盗まれるといった心配のない、より使いやすく安全な技術の策定と普及を促進する団体です。 同団体が策定している技術「FIDO2」(ファイドツー)は、指紋認証や顔認証やPINコードなどを基に生成した秘密鍵と公開鍵を用いた公開鍵暗号の仕組みによって、ユーザーを認証する業界標準の技術です。 Web標準を策定しているW3Cも、FIDO2の技術をWebに対応させた「Web Authentication」(WebAuthn)を策定。WebブラウザでFID
W3C、パスワードを不要にする「Web Authentication」(WebAuthn)を勧告として発表。Chrome、Firefox、Androidなど主要ブラウザですでに実装済み W3Cは3月4日、FIDOアライアンスのFIDO2仕様の中心的な構成要素であるWeb認証技術の「Web Authentication」(WebAuthn)が勧告になったことを発表しました。 W3Cが策定する仕様はおもに、草稿(Working Draft)、勧告候補(Candidate Recommendation)、勧告案(Proposed Recommendation)を経て正式仕様となる「勧告」(Recommendation)に到達します。今回、WebAuthnが勧告となったのに合わせて、W3CとFIDOアライアンスはWebAuthnの仕様が正式版になったことも発表しました。 WebAuthnは2018
なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ(フルリゾルバ)の(主に)UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ
Yahoo! JAPANが指紋認証などによるログイン実現。ID/パスワードを不要にするFIDO2対応が国内でついにスタート Yahoo! JAPANはFIDO2対応を開始し、IDやパスワードの入力なしに指紋認証などでログインできるようになったと発表しました。 具体的には、Chrome70以上のWebブラウザを搭載したAndroid 7.0以上のデバイスで、あらかじめYahoo! JAPANにログインした状態で生体認証の設定を行うことで、それ以後は指紋認証のみでYahoo! JAPANへのログインが可能になります。 ただしこのとき指紋などの生体情報がYahoo! JAPANに登録されることはありません。生体認証はデバイス上に登録され、その照合結果のみがYahoo! JAPANに送られるため、インターネットに生体情報のようなセンシティブな情報が流れたりYahoo! JAPANに保存されることな
Yahoo! Japanが近日中にFIDO認証に対応すると表明、パスワードを使わず生体認証などでWebブラウザからのログインを可能に 最近のスマートフォンやPCには、指紋認証や顔認証などの生体認証を用いてロック画面を解除し、OSへログインする機能が備わっています。 OSへのログインはこのように生体認証などを用いて手軽にできるようになったものの、WebブラウザでソーシャルメディアやECサイトへログインするためには、いまのところユーザー名とパスワードをキーボードから入力する必要があります。 しかしもうすぐ、Webサイトへも生体認証などを用いて簡単かつ安全にログインできる時代がやってきます。 Yahoo! Japanは9月27日、「FIDO認証」(ファイド認証)への対応を近日中に行うと発表しました。 同社は2018年8月に世界で初めて開催された「FIDO2」認定テストにおいて、「FIDO2」の認
Chrome 70から、WebAuthnでMacのTouchIDとAndroidの指紋認証がデフォルトで利用可能に。Webサイトへのログインもタッチで パスワードを使わずデバイス側での指紋認証やPINコードなどによる認証によりWebサイトへログインできるWebAuthnは、2018年4月にW3Cの勧告候補になり、Chrome、Firefox、Microsoft Edgeへの実装が進められています。 参考:パスワードに依存しない認証「WebAuthn」をChrome/Firefox/Edgeが実装開始、W3Cが標準化。Webはパスワードに依存しないより安全で便利なものへ Googleは5月にリリースしたChrome 67でWebAuthnへの対応を行いましたが、10月にリリースされるChrome 70では実装を進化させ、デフォルトでMacのTouchIDとAndroidの指紋認証に対応するこ
Google、Mozilla、マイクロソフトが「WebAuthn」の実装を開始。これによって「FIDO2」の普及が期待され、Webブラウザから指紋認証や顔認証などで簡単にWebサイトへのログインや支払いの承認といった操作が実現されそうだ。 多くのWebアプリケーションは、ユーザーの認証にユーザー名とパスワードの組み合わせを用いています。 しかしユーザー名とパスワードの組合わせを用いる方法にはさまざまな問題が指摘されています。身近なところでは、安全なパスワードを生成することの手間や、安全性を高めるためにパスワードの使い回しを避けようとした結果発生する多数のパスワードを管理することの手間などがあげられます。 そしてこうしたパスワードの不便さが結果としてパスワードの使い回しを引き起こし、いずれかのサイトで万が一パスワードが流出した場合にはそれを基にしたリスト型攻撃が有効になってしまう、などの状況
これから開発されるFirefoxの新規機能は、HTTPSにしか対応しない。新規のCSSプロパティなども対象 Firefoxを開発するMozillaは、Firefoxにおいてこれから開発されるWeb関連の新機能はすべて安全なコンテキスト(Secure Context)のみを対象にすると、Mozilla Security Blogの1月15日付の記事「Secure Contexts Everywhere」で明らかにしました。 安全なコンテキストとは? 安全なコンテキストとは、W3Cのドキュメント「Secure Contexts」で厳密に定義されています。日本語での説明はMDNの「Secure Contexts」で読むことができ、次のように説明されています。 (HTTPS / TLS を介して) コンテンツが安全に配信され、安全ではないコンテキストとの通信の可能性が限られているという合理的な確信
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ(1):[これはひどい]IEの
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP(アクセスポイント)があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します(Secure属性使うと盗聴は防げますが、改変は防げません)。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
8月21~23日にパシフィコ横浜で開催された「CEDEC 2013」では、Webの世界に関するセッションも数多く行われた。本記事ではその中から、サイボウズ・ラボの竹迫良範氏による「HTML5のこれまでとこれから、最新技術の未来予測」と、セキュリティコミュニティでは大変著名なネットエージェント、長谷川陽介氏による「HTML5時代におけるセキュリティを意識した開発」の2つのセッションの様子をお送りしよう。 竹迫氏が「HTML」の周りの最新技術と、3つの未来予測を語る 未来予測その1:通信は暗号化が標準に――「スタバでドヤリング」から考える最新技術 竹迫氏はまず、スターバックスでスタイリッシュなMacBook Airをこれ見よがしに使う、「ドヤリング」という技術(?)について写真を出すところから講演を始めた。 実は、この「ドヤリング」、公衆無線LANを利用すると盗聴のリスクがあることが指摘されて
IPA(独立行政法人情報処理推進機構、理事長:藤江 一正)は、IPAに届け出られる「DOM Based XSS」の脆弱性に関する届出が2012年後半から増加していることを踏まえ、それらの情報を分析して当該脆弱性の概要や対策のポイントをまとめた技術レポート(IPAテクニカルウォッチ 第13回)を公開しました。 IPAに多くの届出があるクロスサイト・スクリプティング(XSS)の脆弱性ですが、2012年第1四半期から第3四半期の期間では合計38件だった「DOM Based XSS」と呼ばれるタイプのクロスサイト・スクリプティングの脆弱性の届出が、第4四半期だけで92件(第3四半期までの件数比約2.4倍増)と急増しました。 一般にクロスサイト・スクリプティングは、サーバ側のプログラムに作り込まれてしまう脆弱性ですが、「DOM Based XSS」と呼ばれるクロスサイト・スクリプティングの脆弱性は、
DOM Based XSSに関しては、IPA「安全なウェブサイトの作り方」でも、拙著でもごく簡単にしか触れておらず、まとまった解説が要望されていましたが、本日(2013年1月29日)にIPAから「IPA テクニカルウォッチ『DOM Based XSS』に関するレポート」が公開されました。 同冊子の目次は下記の通りです。 はじめに 1. DOM Based XSSの概要 2. IPAに報告されたDOM Based XSSの脆弱性 3. DOM Based XSSの事例 4. DOM Based XSSの対策方法 コラム おわりに IPAのレポートと言うことで、DOM based XSSの届出の状況も説明されています。以下にグラフを引用します。 一見して「急増」していることと、昨年の10月から12月の3ヶ月で92件も届出があったということで、対策が急務となっている状況が見て取れます。これは、こ
http://d.hatena.ne.jp/mala/20120220/1329751480 の続き。書くべきことは大体既に書いてあったので、補足だけ書く。 Googleは制裁金2250万ドルを支払うことでFTCと和解した http://jp.techcrunch.com/archives/20120809google-settles-with-ftc-agrees-to-pay-22-5m-penalty-for-bypassing-safari-privacy-settings/ まさか(まともに調査されれば)こんなことになるとは思わなかったので驚いた。異常な事態である。そしてGoogle側の主張を掲載しているメディアが殆ど無いのも異常な事態である。 2250万ドルもの制裁金(和解金)が課せられるのは、2009年に書かれたヘルプの記述が原因だという。 問題の記述 http://obam
昨年の11月にブログエントリ『「SQLインジェクション対策」でGoogle検索して上位15記事を検証した』という記事を書いたところ、非常に好評で、「次はXSSについて書いてください」という要望をいただいておりました。中々XSSについては手がついておりませんでしたが、ようやく書いてみました。以下のURLで検索した結果の上位15位の記事を検証しました。 http://www.google.co.jp/search?q=クロスサイトスクリプティング対策&pws=0 検索結果は変動するため、私が検索した際の結果をEvernoteの公開ノートとして記録しています。 1~10位 11~20位 記事の「正しさ」の検証基準としては、IPAの「安全なウェブサイトの作り方改訂第5版」を参考に、最低限として以下が記述されているかどうかを確認しました。 HTMLのエスケープ処理を行う 属性値はダブルクォートで囲む
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く