|
|
|
|
|
||
|
||
| 
この問題 http://subtech.g.hatena.ne.jp/mala/20110624/1308881526
このパターンのXSSは未だに非常に多く見かける。jQueryを最新版にすれば、#が含まれるパターンは防げるのだけど、$("a[rel=" + user_input_string +"]")といったケースが防げない。1/3ぐらいはアップデートしても問題があるという印象。
ついでに、jQuery Mobileの古いバージョンを使ってるサイトも非常に多い印象。http://subtech.g.hatena.ne.jp/mala/20110711/1310391177
jQueryのXSSは「知らないとXSSを引き起こす可能性が高い」というもの(ポテンシャル)だけど、jQuery Mobileのbeta1より以前のバージョンは素のまま使っていれば、読み込んだだけで必ずXSSがあるというものです。jQuery Mobileの古いバージョンを使ってるサイトは基本的に必ずXSSがあります。
というわけでjQuery本体に手を入れずに直すパッチを書いた。こんな人が使うと良いです。
jQueryを読み込んだ直後に実行すればok。$ではなくjQuery.fn.initを書き換えてるので、$やjQueryがコピーされてても反映される。DOMReadyの前に適用されてれば、jQueryセレクタ誤認問題に起因するXSSは防げるはず(このコード読みこむ前にjQuery.fn.initを直接コピーして実行してるコードがあるとNG)
内容は見ての通り
副作用は殆ど無いはず。
https://gist.github.com/2499522
(function(){ jQuery.fn.__init = jQuery.fn.init; var old_expr = /^(?:[^<]*(<[\w\W]+>)[^>]*$)/; var strict_expr = /^\s*</; jQuery.fn.init = function(selector, context, rootjQuery){ if (typeof selector === "string") { // console.log(selector); if (old_expr.test(selector) && !strict_expr.test(selector)) { throw 'Syntax error, html string must start with "<"'; } } return new jQuery.fn.__init(selector, context, rootjQuery); }; })();
|
以下資料、適当に口頭で補足しながらしゃべりました。オフレコ部分は抜いてあります + 参考URL等を少し足しました。
----
|
はー、なんか色々言いたいことあるけど、面倒くさいのであとで書くわ。
|
https://developer.mozilla.org/en/DOM/navigator.doNotTrack
function some_tracking_code(){
if (navigator.doNotTrack && navigator.doNotTrack == "yes") return;
...
}
こういう使い方をすると、サーバー側で「DNTが守られているのか？」なんてことを気にせずに、そもそもトラッキングされていないことがユーザーから確認できて便利。DoNotTrackが「お願い」ではなく、ユーザーから見てちゃんと何が起きているのか分かる。
Googleがパーソナライズド広告の有無によって広告の数を調整しているように http://gyazo.com/58419e766c579c24e16f74ebbf793d99
トラッキングされている場合は、効果的な広告が出せるから広告の数を減らして、DNTが有効の場合は広告の数を増やすというのも考えられる。けど多分DNTを有効化するような人は、そもそもあまり広告をクリックしないんじゃないかとも思う。
ただ、この手の実装(クライアントサイドでdoNotTrackを見る)には問題がいくつかある
「ドメインごとにDoNotTrackの有無を切り替える」と「クライアントサイドでそもそもトラッキングを行わない実装」を両立するのは困難で、真面目に実装しようとすると実行しているJavaScriptがどのソースに起因するかに応じて、navigator.doNotTrackの値を切り替えるとか、そういうすごく面倒くさいことになる。そういう面倒くさい実装は多分好まれないし、ユーザーがドメインごとに使い分けるみたいなのも、UIが複雑になるので多分起こらない。任意のドメインに対してDoNotTrackを有効化してるかどうか調べられる、なんてAPIを備えたらそれはそれでクロスドメイン制約を突破してるし、ブラウザフィンガープリントに使えることになったりして問題だろう。
透明性を確保するためにはクライアント側でDoNotTrackの値を見て、そもそもトラッキングが行われていないのを確認できる実装が望ましいけれど、それを実現するためには(現実的には)全てのサイトに対して一律DoNotTrack有効ってことになっちゃう。DoNotTrack自体がそもそもトラッキング拒否する人はだいたい全部拒否を望んでるだろ、って方向性で設計されるんじゃないかと思う(あんまり詳しく議論追ってないけど)。少なくともブラウザの実装上はそうなっているし、より細かく制御したかったら拡張機能で、みたいな感じになるんじゃないかな。
まあそもそも、トラッキングを行なっている会社が100社あったとして、100社のうちどれか一つでもユーザーにとって許容が出来無い事をやっていて、DoNotTrackに対応してますと言った場合、他の会社はとばっちりを受ける。運命共同体だ。自分はそれが(ユーザーの意志を反映させるシステムとして)正しい方向性なのかよく分かっていない。
近い将来に、DoNotTrackを有効にしている人が○○%、みたいな統計データが出て、トラッキングを望まない人が○○%います、みたいになると思うけど、それは実状を反映したデータには決してならない。無関心な人は無関心なままだし、大体許容してるけど一社でもマズイことをやってたら困るのでDoNotTrackを有効にせざるを得ない、という状況もあるだろうから。
広告業界はとばっちりを受けないように同業他社を見はったほうがいい
|
あとで書く
アプリ内から「Twitterアカウントの所有者であること」と「そのデバイスの持ち主であること」の両方を証明するには
ポイント
