死にゆくアンチウイルスへの祈りSecurity meets Machine Learning 第1回キックオフミーティング https://connpass.com/event/62844/ 発表資料
暮らしに役立つITコラム ChromeやSafariの自動入力機能が、なぜ「悪いデザイン」なのか
autofill_ui.md 見た目の上で、隠されているフィールドに対しても自動入力してしまうという問題が話題になっている(2017年1月) https://github.com/anttiviljami/browser-autofill-phishing のだけれど、この問題の歴史はとても古い。自分も調査したり問題を報告したりしているので、振り返ってみる。 2012年の話 2012年4月のShibuya.XSS #1 https://atnd.org/events/25689 で、Hamachiya2が発表した http://hamachiya.com/junk/x-autocompletetype.php この問題に関連して「手の込んだクリックジャッキング」を使って情報を盗み出すデモを作った。 https://plus.google.com/112675818324417081103/
AWSのアクセスキーをハニートークンとして使うアイディア
Early Warning Detectors Using AWS Access Keys as Honeytokens この発想はなかった。 AWSのアクセスキーはハニートークンとして使える。 ハニートークンとは、普段使用しないものが使用されたことを検知して、意図しない利用を検知するトリックである。例えば、通常ならば使われないメールアドレスをパスワードとともに、自分しかアクセスできないストレージに格納しておく。その状態で、もしメールサーバーにログインされた場合は、自分しかアクセスできないはずのストレージに他人がアクセスして、マヌケにもメールアドレスとパスワードをストレージ上に保存しているのを発見して、利用を試みたということになる。つまり、侵入を検知できる。 AWSのアクセスキーは、ハニートークンに使うことができる。AWSに権限を持たないユーザーを追加して、そのユーザーでアクセスキーを発行
HTTP Headers という 5万人が使っている Chrome 拡張のマルウェア疑惑。セッション盗まれて BTC も盗まれそうになった話。 - clock-up-blog
疑惑どころか 99.99% くらい黒な話。 （後記：セッション盗まれたと思ってたけど、よくよく考え直してみると生パスワードごと盗まれてる可能性もあるしやばい） 追記：続報 11月3日 今回指摘した HTTP Headers 以外にも、「Tab Manager」「Give Me CRX」「Live HTTP Headers」等で同様（？）の問題が報告されています。第三者が元の作者からソフトウェア権利を買い取って悪用する、というケースが割とある模様（？）。皆さま情報ありがとうございます。 11月4日 Zaif については、「不正な Chrome 拡張」と「スクリプトから保護されていなかったクッキー」のコンボによりセッションが盗まれていた可能性あり。 Zaif のセッション情報が盗まれた原因のひとつについて。JavaScript からクッキー値を取得させない方法。 - clock-up-blog
Timing attack - Wikipedia
A example of a timing attack being performed on the web cache. The graph on the left denotes a case where the timing attack is successfully able to detect a cached image whereas the one on the right is unable to do the same. In cryptography, a timing attack is a side-channel attack in which the attacker attempts to compromise a cryptosystem by analyzing the time taken to execute cryptographic algo
IPスプーフィング - Wikipedia
IPスプーフィング（アイピースプーフィング）とは、IP通信において、送信者のIPアドレスを詐称して別のIPアドレスに「なりすまし」（英：spoofing）を行う攻撃手法を指す。ハッキング、サイバーテロ（サイバー攻撃）の一つ。より原義に近い形としてIPアドレススプーフィングと呼ぶこともある。 IP通信において、不正アクセスを防止する観点からポリシーに基づくフィルタリングを行うケースは多く、「特定のIPアドレスからの接続のみ可能」といったアクセス制限が施されている場合がある。このようなアクセス制限が施されている状況下にあっても、送信元IPアドレスを詐称することができればアクセス制限を迂回できてしまうため、攻略対象システムへの不正アクセスを成功させる可能性が高まる。また、攻略対象システムに残されるログにも詐称されたIPアドレスが記録されるため、攻撃者が攻略対象システムの管理者による追跡を逃れられ
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
CVE-2016-7401 CSRF protection bypass on a site with Google Analytics の解説
gistfile1.md CVE-2016-7401 https://www.djangoproject.com/weblog/2016/sep/26/security-releases/ https://hackerone.com/reports/26647 pythonのcookie parserが ; 以外もpairsの区切り文字として解釈するので、google analyticsのreferrer経由でsetされるcookieを使ってCSRF tokenを上書き可能だったという問題。 django側でcookie parser自前で実装、python本体は直ってないようだ https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a 多くのcookie parserは、pairsの区
独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
「WebAPIのステートレスなCSRF対策」という2011-12-04の記事がありました。 ここで説明されているCSRF対策は、 GET、HEAD、OPTIONSメソッドのHTTPリクエストはCSRF保護の対象外 HTTPリクエストにX-Requested-Byヘッダがなければエラーにする という非常にシンプルなものです。 そして、この対策の原理として以下の説明がありました。 form, iframe, imageなどからのリクエストではHTTPリクエストに独自のヘッダを付与することができません。独自のヘッダをつけるにはXMLHttpRequestを使うしかないわけです。そしてXMLHttpRequestを使う場合にはSame Origin Policyが適用されるため攻撃者のドメインからHTTPリクエストがくることはない、ということのようです。 ここで、 XMLHttpRequestを使
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
クロスサイトスクリプティング対策 ホンキのキホン - 葉っぱ日記
本稿はCodeZineに2015年12月28日に掲載された記事の再掲となります。 クロスサイトスクリプティング(XSS)は、古くから存在し開発者にもっともよく知られたセキュリティ上の問題のひとつでありながら、OWASP Top 10でも2010年に引き続き2013年でも3位と、未だに根絶できていない脆弱性です。 本記事では、Webアプリケーションの開発においてXSSを根絶するために必要な対策の基本を本気でお伝えします。 はじめに OWASPでは開発者に向けたセキュリティ対策のためのドキュメントやチートシートを多数用意しており、XSSへの対策としても「XSS (Cross Site Scripting) Prevention Cheat Sheet」というドキュメントが用意されています。 ただし、このXSS Prevention Cheat Sheetはシンプルなルールを定めたチートシートで
はてなブログにあったセルフXSS 脆弱性"&'<<>\ Advent Calendar 2014 (19日目) - ooooooo_qの日記
この記事は脆弱性"&'<<>\ Advent Calendar 2014の19日目の記事です。 前の記事はid:matsukawarさんのASPXのサイトのValidation機能からみるサイト攻撃ルート - matsukawarの日記です。 はてなブログの編集モードの一つに見たままモードというのが有り、そこにセルフXSSがあったので１年ほど前に報告しました。 はてなブログではyoutubeなどの別サイトの要素を読み込む場合iframeが使用されています。 そして、iframeのsrcはjavascript:で始まるuriを書くとXSSが起こります。当時その対策として先頭がjavascript:だったら置換する処理が書かれていたのですがそれが不十分でした。 html中に含まれる空白などはDOMが生成される際に無視されるためjava(空白)scirpt:などが入力されるとセルフXSSとなりま
高木浩光＠自宅の日記 - 続・「サニタイズ言うなキャンペーン」とは
■ 続・「サニタイズ言うなキャンペーン」とは 「サニタイズ」という言葉はもう死んでいる サニタイズ言うなキャンペーンがわかりにくい理由, 水無月ばけらのえび日記, 2006年1月5日 というコメントを頂いた。まず、 これは「サニタイズという言葉を使うな」という主張ではありません。「そもそもサニタイズしなくて済むようにすべきだ」という主張です。言い方を変えると、「サニタイズせよと言うな」という主張になります。 「サニタイズ言うなキャンペーンがわかりにくい理由」, 水無月ばけらのえび日記, 2006年1月5日 とある。「サニタイズせよと言うな」キャンペーンでもよいのだが、 その場合は次の展開が予想される。 「サニタイズせよと言うな」を主張する際の具体例として、XSSやSQLインジェ クションのケースを挙げた場合、正しいコーディングは、「その場の文脈でメ タ文字となる文字をエスケープすること」と
高木浩光＠自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに
■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP
ダイヤルQ2風の電話番号でInstagramやGoogleやMicrosoftから金をむしりとれる脆弱性
セキュリティ研究者が、とても興味深い脆弱性を報告して報奨金をもらった記事が上がっている。 How I Could Steal Money from Instagram, Google and Microsoft – Arne Swinnen's Security Blog プレミアムナンバーという電話上のサービスがある。これは一時期日本で行われていたダイヤルQ2と同等の仕組みを持つサービスで、プレミアムナンバーという電話番号にかけた電話の通話料は、通常より高い。通話料の差分は、電話サービスの提供元に支払われる。 ダイヤルQ2は電話越しに何らかのサービスを提供して、電話料金で利用料を徴収できる、手軽な仕組みだった。その利用例は、投資顧問、アダルト、占い、人生相談、義援金、ダイヤルアップISPなどに利用されていた。ダイヤルQ2自体は2014年に終わったが、海外ではまだ同等の仕組みをもつサービス
警察からの問い合わせ電話にこたえるにあたって - davsの日記
警察からの照会電話がたびたびかかってくる職場で働いていたことがある。 警察からの照会だからこたえることが許される、あるいはこたえなければならない照会が多かったのだが、必ず守らなければならないルールがあった。 それは、その電話ではこたえず、一旦、電話を切ることだった。その後、ネットなりで警察本部や警察署の代表番号を調べて、回答の電話をかけるのだ。それはもちろん、警察をかたる電話を警戒してのことだが、この警察からの問い合わせへの回答ルールには続きがあった。 問い合わせ電話の担当を把握していても、その人物を電話口に呼び出さず、「こういう照会があったのですが、担当者を失念しました。問い合わせされたのはどなたですか」というのだ。これは、照会者が真正な警察官であっても、公務でない照会をしていることを恐れるためだ。乱暴な要約をすれば、悪徳警官でないかを心配しているということだ。前段の警察の代表番号にかけ
第3回 Webセキュリティのおさらい その3 CSRF・オープンリダイレクト・クリックジャッキング | gihyo.jp
前回は、Webアプリケーションにおける受動的攻撃の代表例の1つであるXSSについて、原理や対策を振り返りました。今回は、同じく受動的攻撃の代表例であるCSRF、オープンリダイレクト、クリックジャッキングについて掘り下げて解説していきます。 CSRF（クロスサイトリクエストフォージェリ） CSRFはどのように引き起こされるのか CSRFとは、たとえば掲示板の書き込みや設定情報の変更などの機能に対して、攻撃者のサイト上に設置されたフォームなどから強制的にリクエストを発行することで、ユーザーの意図していない操作と同様の結果をもたらす攻撃手法です。Webアプリケーションに永続的な副作用がある機能が攻撃の対象となります。 たとえば、http://example.jp/上に設置された掲示板で以下のようなHTMLがあったとします。 <form method="POST" action="/board">
リンクのへの rel=noopener 付与による Tabnabbing 対策 | blog.jxck.io
なお IE は(security zone setting をいじらない限り)この問題が発生しないようだ。 引用元: blankshield demo | Reverse tabnabber phishing tabnabbing 上記の挙動を、フィッシング詐欺に利用できることが既に指摘されている。 この手法は Tabnabbing と呼ばれている。 Tabnabbing: A New Type of Phishing Attack Aza on Design Target="_blank" - the most underestimated vulnerability ever この攻撃方法を解説する。 攻撃の概要 https://cgm.example.com (左上) というサービスがあるとし、これは SNS やチームコラボレーション系サービスを想定する。 攻撃者は、このサービスの不
第1回 Webセキュリティのおさらい その1 | gihyo.jp
はじめに みなさんこんにちは、セキュアスカイ・テクノロジーのはせがわようすけと申します。 周知のとおり、ここ数年のブラウザの機能強化は目覚ましいものがあり、CSS3やSVGを含むHTML5ブーム以降のブラウザ内での表現力の向上や、JavaScriptエンジンの最適化による実行速度の向上は、数年前では考えられないような目を見張るものがあります。また、HTML5の仕様策定後の現在でも、WHATWGやW3Cではさまざまな議論が継続的に行われており、これまでブラウザ上に存在しなかったような多様なAPIの仕様が生み出され、各ブラウザに日々実装されています。 利用者視点だけでなく、以下のような開発者視点での需要に応えるフロントエンド開発環境の改善も、ここ数年でかつてないほど大きく進んでいます。 CoffeeScriptやTypeScriptに代表されるaltJSと呼ばれる言語処理系の登場 ES2015
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webシステム／Webアプリケーションセキュリティ要件書 2.0 - OWASP Japan セキュリティ要件定義書ワーキンググループ
