Android/iPhoneスマホのroot不要な広告除去法

Androidスマートフォンで広告をブロックしようとすると、root化してadawayのようなhostsファイル変更が必要。そう思っていた時期が僕にもありました。

root/JB化しなくてもドメイン単位の広告ブロックはできないことはない。ただし、制限もいくつかある。

• wifiオンリー。3G回線では広告が見えてしまう
• 個人単位ではブロック対象をカスタマイズできない
• DNSサーバがダウンするとブラウジングが遅くなる

というわけでroot化したくない、まだroot化方法が出回ってない人にお勧めの方法。

方法としては、広告のドメインをブロックしてくれるDNSサーバを使うというシンプルなもの。アプリのインストールも必要なく、Android/iPhoneの標準機能で出来る。

（追記）設定を自動化するAndroidアプリを公開しました。
https://play.google.com/store/apps/details?id=net.usb0.wifiadblock
http://causeless.seesaa.net/article/306520220.html

ひとまず自分で立ててみたDNSを期間限定で公開しておく。
以下、自宅のルータのDHCP設定がどうなっているかわかる人向け説明。

静的IP設定にして
IPアドレス： 元のまま（できればDHCPの割り当て範囲外）
ゲートウェイ： 元のまま
サブネットマスク： 元のまま
プライマリ： (IPを変更しました 最新のアドレスは  https://app.usb0.net/blockdns.txt を参照)
セカンダリ： 8.8.8.8
にして再起動するだけ。

AndroidならWifi Staticなどのアプリで自動化すれば、他のネットワークに切り替えても大丈夫だろう。

今のところ、ブロック対象はadawayのデフォルトリストと、
http://logroid.blogspot.jp/2012/06/adaway-hosts-for-japan.html
およびseesaa関連のいくつかを追加している。我ながら酷い。

一般的なアプリが利用している広告、ユーザー追跡や携帯端末情報送信をブロックできるが、不意に3Gに切り替わった場合はブロックできないため完全に信用することはないよう注意。続きを読む

mala氏の記事を読んで各案件を見てみた

mala氏 @bulkneets https://twitter.com/bulkneets/
の高木浩光批判記事について。

http://d.hatena.ne.jp/mala/20120830/1346309790

最近twitter始めたと言え、両者をフォローしているからには、ということで確認しつつ補足してみる。

• 2011年 10/20 GmailのスキャンとAdsenseの話

通常のウェブサイトのAdsenseやAmazonなどのインタレストマッチ広告は、

1. 掲載しているサイト管理者の推薦
2. javascriptで取得したページurlと、それに紐付けられたクロール済みページ内容
3. cookieに保存されたトラッキングIDと、それに紐ついたユーザの検索履歴などによる興味分析（オプト・アウトしていない場合）

を元に広告内容を瞬時にサーバー側で処理して表示している。もちろんGeoIPやUserAgentやもっと細かい情報も使っているだろうが、外から見える範囲ではこれが利用されている。

Gmailのインタレストマッチも同様に、

1. javascriptで取得した表示中のメールID/urlと、それに紐ついたサーバーに保存されたメール内容
2. トラッキングIDとログインユーザー、それに紐ついた検索履歴などによる興味分析（オプト・アウトしていない場合）

を利用していると考えられる。

mala氏が指摘したように、もし
https://twitter.com/HiromitsuTakagi/status/126885716553760769
が正しいなら、

• 大量の広告をブラウザに送って、ブラウザ側で取捨選択する機能
• ブラウザ側でキーワードを抽出して送信する機能

のいずれかが実装されている必要があるが、ちょっと通信を見たくらいではそのような機能は見つからない。
なお、難読化されたjavascriptを読めるほどjavascriptを扱ってないのでわからないことは、お断りしておく。

従って、GmailもYahooも、サーバー側に保存されたメール内容を（機械的に）クロールし、分析していることが推定される。
ブラウザ側でなくサーバー側での分析が違法なら、両方共違法と考えられる。

• 3/12 共産党のページのXSS

前後関係不明

• 3/18 medibaの話

window.postMessage()はjavascriptで他のフレームへデータを送るAPI。

たいていは読み込まれた広告やブログパーツに必要なデータを送り込むためのAPIだが、
http://adc.medibaad.com/public/js/medibaad-localstorage-base.js
は何も考えずにトラッキングIDを親フレーム（つまり広告を表示しているサイト）に提供してしまう。
つまりユーザー追跡情報を（恐らく意図せず）第三者に漏洩している。

というjavascriptセキュリティホールの一つに気づかなかった、という事らしい。

• はてなとTwitterの話

注目している対象とそれ以外で温度差があるとという話。
はてなとtwitterは、はてブボタンやつぶやくボタンを生成するためのjavascriptに、ユーザートラッキングコードをあとから追加した。
twitterは基本的にwebで完結しているが、はてなは課金関係で機密情報が多い分より脅威的と考えるべき、と思う。
有料サービスをしていない個人にとっては同じ程度のリスクと思われる。

• 8/2 myappeeの話

Facebookには、ユーザの情報の一部を第三者に提供するAPIがあり、他のウェブサイトからも、ユーザの入力を省略するためなど使うことが出来る。
この場合、myappee側はユーザーの同意の元、性別・メールアドレス・誕生日を取得するもので、フェイスブックアカウントそのものへのアクセスはできない。
なお、スクリーンショットでは難読化されておらず、javascriptを知っている人なら誰でも確認できたようだ。

もちろん、取得したメールアドレスなどから紐つけることは出来るだろうが、それはAPIを使うこととは関係なく出来るため、APIを使うことでユーザーが嘘を付く確率を減らすことが出来るかもしれない、程度のリスクと考えられる。
https://twitter.com/HiromitsuTakagi/status/231045813353197571
では、Facebookアカウントと紐つけることでより情報を集積したいのではないか、と指摘しているが、このAPI利用からそれを推定するのは邪推というべきだろう。

• 8/11 Pathtraqの話

メッセサンオー事件では、URLに機密情報を載せるという前時代的な危険なウェブショップアプリを利用していたために、漏れたURLを検索サイトがクロールし、そのページに含まれる機密URLが〜と連鎖的に機密情報が漏れてしまった事件だ。

URLが漏れた経路は様々考えられる。高木先生が指摘したPathtraqをはじめ、Googleツールバーほか各種ツールバーアドイン、ウイルスチェックソフトの一部もURLを取得して外部に送信する機能がある。
mala氏の指摘する通り、Pathtraq経由で漏れたという根拠は乏しい。少なくとも、最初の発覚より以前に機密URLがPathtraq上に公開されたという根拠は見当たらない。
また、最初の漏洩がHTTPSアクセスなら、Pathtraqはそれを公開し得なかったとする指摘もある
https://twitter.com/bulkneets/status/234146798472663040

ブラウザのパスワード自動入力機能の脆弱性

昨夜MozillaのBugzillaには垂れ込んだので、（隙を見て）しっかり書いておく。

前のエントリで書いたように、クリックジャッキング攻撃では、ブラウザグローバルに保存されている情報の一つである、パスワード自動入力データベースが利用されうることを書いた。
自分は勝手にautofilljackingまたはpasswordjackingと読んでいる。

これは根本的にブラウザのセキュリティ脆弱性だ。
ロケーションバー偽装に対してHTTPSの扱いが大きく変わったように（緑色でドメイン保有者が強調され、ドメイン名が太字で明確化される）ブラウザのパスワード自動入力機能をユーザーが意図せず利用されることはブラウザ側で防がなければならない。

ごく一部のブラウザ（Operaの幾つかのバージョン、今は使っていないので分からないが）は、ユーザーが自動入力対象フォームをクリックしたり、特定のキーボードショートカット入力によって自動入力が有効になるよう実装されていた。これは今回指摘したタイプのクリックジャッキングを防ぐことが出来る。ただし根本的解決ではない。
この自動入力機能の脆弱性を完全に排除するためには、ロケーションバー偽装と同様、ユーザーが認識しているウェブサイトと、自動入力フォームのSAMEORIGINを保証する必要がある。
例えば、ロケーションバーのドメインと、自動入力フォームのドメインが同じ事を検証し、そうでなければ自動入力を無効にすることで、この攻撃手法に類するすべての攻撃を排除できる。

この対策は（自動入力はそもドメインごと管理されるのだから）とても簡単のはずだが、少なくともChromeとFirefoxはチェックされていなかった。

サイト側に対策の意義が殆ど無い以上、ユーザーに近いブラウザには素早い対応を望む。

クリックジャッキングとユーザープライバシー

クリックジャッキングやCSRFは通常、攻撃対象がウェブサイトであって、ユーザーは知らず加担していただけだったり、データ消失などの二次被害に遭うことが多い。

一方、情報共有型のSNSの台頭によって、ウェブサイトではなくユーザーを標的としたクリックジャッキング攻撃がありうることを指摘したい。

リアルタイムロケーション共有SNS foursquare では、ログインフォームのCSRF対策が不完全でクリックジャッキングに対して脆弱になる。
もし、
・ブラウザにパスワードを保存している
・サードパーテイクッキーを有効にしている
・追跡されたくないのでログアウトしている
・ブラウザの位置情報取得確認ダイアログを恒久的に許可している
に合致した場合、簡単なクリックジャッキングで、ブラウザの保存済みパスワードが利用され、勝手にログインさせられることがありうる。

もし、あなたが非公開な資本提携を検討する出張先や、夜の繁華街や、宗教的な施設など人に知られたくない場所に行こうとするとき、こういった情報共有サイトからはログアウトしておきたいと思うだろう。
しかし、特に標的型の攻撃によって意図せず位置情報共有サイトにログインしてしまった場合、あなたの行動や職場で進行中の案件や人間関係が意図せず露呈することになる。

これはSNSにかぎらずトラッキング型広告のオプトアウトページなど、サービス側がなるべくログインしていて欲しいサービス全てにも発生し売る、。
この攻撃手法の問題点は、サービス提供側に対策する積極的理由が見出しにくい点にある。
ヘタをすれば、攻撃者がユーザーをログインさせること自体にインセンティブさえ出てくる可能性がある。

ユーザー側の対策は、ブラウザにパスワードを保存シないこと、現実的でないがIFRAMEを全てのサイトで拒否することに限る。
可能なら、IFRAME内にパスワードの自動入力をさせないブラウザ実装を利用すべきだが、そういったブラウザの実装は存在しない。

正しいCSRF対策のまとめ2012年版

CSRFに関する冤罪疑惑がニュースになっていることもあり、まとめてみようと思う。

まずCSRFとXSSの違いは、攻撃者がユーザに好きなコードを実行させることが出来る点にある。
XSSはWebサーバの管理者が正しくテンプレートを使ってHTMLとjavascriptをクオートし、文字エンコードを正しく設定し、IEのバグにさえ注意すれば大体は防げる。現在発生するのは単にコード上の不注意によるバグか、ブラウザ側のバグが多い。
もちろん大いに神経を使って対策スべき事柄であることには違いがないが。

一方CSRFは攻撃者のサーバとユーザの通信から始まるので、中間者攻撃と似た多様な攻撃手段になりうる。

CSRFの目的は

1. ユーザーの秘密情報を奪うこと
2. ユーザーに不適切な行動を起こさせること
3. 2によってサーバーに被害を与えること

がある。

そしてその手段としては

1. iframeとjavascriptによってGETやPOSTをユーザーのクリックなしにエミュレートする
2. cssで偽装したiframeによって、ユーザーが意図しないクリックを行うよう誘導する
3. scriptタグによってJSONや部分的にjavascriptとして解釈可能なページを（攻撃者のサイトのページ内に）読み込む
4. flashなどを使ってヘッダをエミュレートしたリクエストをブラウザ経由で行う

がある。 他の手法はほとんどブラウザ側のsameoriginポリシー（ほかドメインに対するjavascriptでのajax要求は禁止される）で排除されるはずである。

これら全てを回避する方法として

• 何らかの処理を起動するような、ユーザのクリック（＝意思あるいは同意）を確認すべき全ての画面遷移とその前後で（ログインパスワード入力フォームを含む）で、ワンタイムトークンを発行・検証する。
• ワンタイムトークンはformのhidden要素などとしてページ内に埋め込む。cookieなどブラウザグローバルなローカルストレージに格納してはならない
• ワンタイムトークンは、ログインクッキーなどで判別したユーザーと一致すること必ず確認する
• X-frame-options: deny (あるいはsameorigin)ヘッダを設定する
• JSONなどjavscriptとして解釈されうるページに秘密情報を載せたりJSONPへのアクセスを破壊的操作に利用しない。

を必要条件としてするべき。
また実装上の提案として

• ウェブアプリは多タブでのアクセスを前提として、操作はタブごとにトランザクション管理するか、多タブ表示を検出して一方をロック出来るよう実装する。
• ワンタイムトークンがユーザーの正しい使い方でも使いまわされる可能性があることを認識し、ワンタイムトークンの再発行手段を用意しておく

ことが望ましい。それについてはhttp://causeless.seesaa.net/article/288497459.html に書いた。

対策の根拠を解説する。

• 攻撃者がユーザーとウェブアプリとの間で交される秘密情報を一切入手できないことを保証しなければならない。

これは、JSONPに秘密情報を載せないこととブラウザ側のSameoriginポリシーによって保証出来る。

• 攻撃者がユーザーのSubmitクリックを偽装できないことを保証しなければならない。

これは、ページ単位のトークン（攻撃者が読めないので次のページにトークンを含めることはできない）と、X-frame-options: denyに（ユーザの意図しないクリックを発生させない）よって保証される。

• そのほか。

徳丸先生が言っているように、ログイン済みでないユーザを誘導してクリックさせる行為はCSRFに近いがCSRFではない。
ただし、ログインフォームをclipped iframeで偽装してユーザーにクリックさせ、ブラウザに保存済みのパスワードを送信させる攻撃手段はあり得る。ログインすると、プライバシー情報が露出する要な場合、たとえば今どこにいるか公開されたり、インタレストマッチ広告のターゲットになる、などといったユーザーへの被害がありうるため、ログインフォームに関してはみログイン状態出会っても、対策すべきである。

この記事には特に以下の記事を参考にさせていただきました。
金床氏

http://www.jumperz.net/texts/csrf.htm

徳丸浩氏の『徳丸本に載っていないWebアプリケーションセキュリティ』
http://www.slideshare.net/ockeghem/phpcondo
高木浩光氏
http://takagi-hiromitsu.jp/diary/20060409.html

http://takagi-hiromitsu.jp/diary/20061115.html

CSRFとリファラー

CSRF対策の方法としてワンタイムトークン方式の他にリファラー方式がある。リファラーはブラウザが認識しているリンク元ページアドレスをサーバに送信するものだ。

攻撃者がiframeやscript要素で他のドメインのデータを読み込もうとした場合、リファラーとしては攻撃者のドメインが送られる。
すなわち、リファラーが自分のドメインでない場合は攻撃の可能性が高いと見て、ユーザーを適当な場所にリダイレクトするなど安全にリクエストを拒否すべきだ。

ただし、この方法には幾つか穴があり、JavaやFlashなどそれ自体がブラウザ機能を持ちうる場合、リファラーを偽装することが可能になる。したがって、リファラーだけを根拠にCSRF対策とすることは避けるべきだ。この点は
高木先生の日記が詳しい

http://takagi-hiromitsu.jp/diary/20061115.html

CSRF対策とクリックジャッキング

CSRF対策をどんなに講じていても、インラインフレームで自サイトを表示されてしまうと無力である。たとえば、投稿ボタンやさらにその一部だけ拡大して表示するようCSSをいじったインラインフレームを用意すれば、簡単にユーザーの目を欺くことができる。たとえば、”次のページへ進む”ボタンだと思ったら、実はtwitterでツイートする、ボタンのクリップされた一部だった、なんて状況だ。これはクリックジャッキングと呼ばれる

そこで、多くのブラウザでは X-Frame-Options というヘッダーでインラインフレームに読み込まれることを拒否できる。
たとえば

X-Frame-Options: SAMEORIGIN

とすることで、同一ドメインからのみiframeで呼び出せるようになる。Twitterではこの方法でCSRFを防いでいる。

https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header

なお、javascriptで判別する方法もあるが、javascriptを無効にしたユーザーが引っかかる可能性があり、あまりおすすめできない。

日本語の解説はやっぱり徳永本くらいっぽい。

http://www.slideshare.net/ockeghem/phpcondo

CSRF対策とワンタイムトークンの利便性について

CSRFはユーザーに意図せず他のサイトの機能を使わせてしまう攻撃だ。
対策が不完全だと例えば、とある掲示板のリンクをクリックしたら、twitterで罵詈雑言を投稿してしまった、なんてことが起こる。
twitterでは、”いまどうしてる?”という投稿確認ページを入れ、”投稿内容を確認したユーザー”と”投稿内容をツイートボタンを押したユーザー”と”twitterが認識しているユーザー”が一致することを保証して回避している。

この対策にはワンタイムトークンが必要になる。ワンタイムトークンの原理は省略。いろんなところで対策自体はすでに十分述べられている。（追記：正しいCSRF対策のまとめ2012年版  http://causeless.seesaa.net/article/288690661.html でいくらか解説しました）

ワンタイムトークンを正しく実装すると、サービス提供側からみれば完全にCSRFを排除することができる。（別の脆弱性が無い限り）　ただし、よく考慮しないと、ユーザーの利便性を損なうおそれがある。主なものは、ワンタイムトークンがキャッシュを通じて使いまわされることだ。

通常、ワンタイムトークンはフォームのhiddenパラメータに保存されるがトークン使用後、トークン発行ページにブラウザの”戻る”で戻った場合など、使い回しが発生する。HTTPヘッダでHTTPキャッシュ破棄を指示してもレンダリング済みキャッシュを持つブラウザには意味が無い。

これを排除するには、トークン取得ページにPOSTを使って、ブラウザに警告を出してもらい、ユーザーにはもっと戻ってもらって、再入力を促す方法がある。参考にした金床氏の http://www.jumperz.net/texts/csrf.htm にある
> リクエスト1はGETよりもPOSTを用いる方が好ましい
はこれを指していると思われる。ただこれは2009年の記事だ。

もっとスマートな方法として、Ajaxでトークン消費ページヘPOSTする瞬間に有効なトークンを取得する方法がある。現在Ajaxではクロスドメイン取得が制限されている（外部scriptタグでの取得防止にX-requested-withヘッダを検証するなどAjax向け対策は別に必要）ので、他ドメインの攻撃者がトークンを得ることはできないし、ユーザーが投稿内容を確認することにも支障はないはない。トークンの有効期限を無駄に長く取る必要もない。
実装は面倒だが、ユーザが入力したフォーム内容などを失ったりすることなく、ブラウザの警告画面も必要ない。

ただこの方法はjavascript有効でドメインを適切に管理できていることが前提になる。
もう少し保守的な方法として、有効なtokenを予め埋め込んでおき、formをポストしたらjavascriptで使用済みtokenに登録しておくことでもよい。もし使用済みトークンでフォームが再送信されそうになったら、ユーザーに警告したり、フォーム自体を再取得する。POSTでないフォームページの再取得では、ブラウザがフォーム内容を保存してくれることが多いし、今はjavascriptで安全なブラウザローカルストレージが利用できる。

この2つを合わせれば、ちょっとした入力内容の手直しのために、ユーザが一番最初から全てのフォームを打ち直すといったストレスを感じなくて済む。

ほか、ブラウザに複数タブを開いていた場合。ワンタイムトークンはユーザーあたりいくつでも発行できるようにしておくことは重要だ。トークンをキーに、ユーザへのリンクを保存しておいた方がいい。あとはレースが発生しないように投稿など破壊的操作全てにトランザクション管理するほかない。

プロクシがトークンをキャッシュした場合、HTTPでは対策不可。プロクシ側の問題なのでHTTPSで全通信経路を保護するほかない。

最後に、CSRF回避には、フォームのSubmitボタンをユーザーが意図した通り押せるよう、サイトをデザインすることも大切。とにかく"はい"をクリックするユーザーは多いのだから。

Androidの広告除去

AndroidでWebの広告を除去しようとすると、hostsふぁいるでドメインごとにブロックするしか無い。
と思っていたが、WiFi限定でroot不要な方法があった。

ここで少し詳しく http://causeless.seesaa.net/article/289244107.html 

でこの作業が面倒くさい。

幸運にもAdawayアプリがhostsファイルを自動取得してくれるが、hostsファイルの作成自体は手動。
主にここのhostsファイルを使わせてもらっている。
http://logroid.blogspot.jp/2012/06/adaway-hosts-for-japan.html

hostsファイルの登録方法としては

・AdawayのTCPダンプ機能を使う方法
端末が発行するドメイン検索を記録する方法。ただし、ホスト名しかわからず、ad.***というようなわかりやすいドメインしかブロックしづらい。

・HTMLのソースを読みながら手作業で登録
確実だけど面倒すぎる。あと、管理が手間でいちいちファイルをアップロードする必要もある。

ということで手作業の登録を半自動化するウェブアプリを作っている。

http://hostsaway.appspot.com/

androidを模したクライアントで該当アドレスを取得し、外部ドメインのsciprtなど怪しい広告っぽいファイルをリストするものだ。
チェックしたドメインはホストファイルとしてadawayに自動インポートできるので試してもらえると嬉しい。

yumでプライマリミラーを指定する方法

/etc/yum.repos.d/fedora-updates.repo
ほかrepoファイル全部に、コメントアウトされているbaseurlに代えて
baseurl=http://ftp.jaist.ac.jp/pub/Linux/Fedora/updates/$releasever/$basearch/
などとする。

jaistが落ちていてもmirrorを自動で見てくれるようだ。

debian/GnomeのGUIのマネージャに慣れてると面倒