- この文章に関しても所属組織とは関係のない個人の見解です
- 本当に全く打ち合わせをしていないので、話題が分散しがちだったかもしれない。
- せっかくの所属組織とは無関係のレギュレーションなので、具体名を上げてガンガン治安の悪いことを言うつもりだったのだけど、直前に「具体的な企業名は避けましょう」と言われて若干遠慮した。
- マズいことをガンガンしゃべる覚悟で来たので、防刃ベストを着ているが、特に出番は無かった。トイレにも行った。
- 本当は話す予定だったトピックについて、いくつかは、別途private gistに書く。
CDN設定の話、request collapsing という名前の機能
- https://tech.mercari.com/entry/2017/06/22/204500
- http://www.itmedia.co.jp/news/articles/1806/07/news084.html
- CDN側のミスではなく、利用する側の設定ミス。予想外の挙動で、罠っぽさはある。
カスタムヘッダ / Flashで昔 cross originで任意ヘッダを送ることが出来た
- https://gist.github.com/mala/8857629
- 既知になってから結構長い期間直らなかった。
cross originでの任意のcontent-type送信
- https://github.com/sp1d3r/swf_json_csrf
- https://bugs.chromium.org/p/chromium/issues/detail?id=490015
- Chromeのこれも結構長い期間直らなかった。
Double submit cookie によるCSRF対策 / Cookie parser挙動に依存したCSRF
- コロンとセミコロンと発言していたが、カンマとセミコロンの誤りでした。訂正いたします。
- https://gist.github.com/mala/457a25650950d4daf4144f98159802cc
Cookie prefixes
- https://asnokaze.hatenablog.com/entry/20151012/1444636636
- https://googlechrome.github.io/samples/cookie-prefixes/
- サブドメイン経由やMITMで上書きされないcookieを作ることが出来る。便利。
- HSTSをマゾい設定で運用しない限りCookie上書きは防げないので、重要なCookieに使うことをおすすめする。
- しかし仕様作ったGoogle自身は使ってなかったりする。
ユーザー属性情報が攻撃者に漏洩してしまう広告配信手法
- https://twitter.com/bulkneets/status/203863241003237376
- Yahoo名指し https://twitter.com/bulkneets/status/723364782653333505
- Yahooに対しては、後にXSS報告のついでに正式な報告もしているけど、修正完了の連絡は受けていない。
- adのセッションでも触れかけていたが、配慮が発生した。
証明書検証不備が公表されていない事例がめちゃくちゃ多い
- 一体どれだけの数のアプリに証明書検証不備があったことか(外部SDKが処理上書きや著名ライブラリで実装ミス、AFNetworkingとか)
- https://twitter.com/bulkneets/status/607548746738507776
- MITM起因でパスワードが盗聴される可能性があることのアナウンスをしたのは自分の知る限りでドワンゴぐらいしかない(尊い) http://blog.nicovideo.jp/niconews/ni055746.html
- 実際に、証明書差し替えまでも含んだMITM攻撃が世の中でそこまで横行しているとは想像し難いが、クライアント側で起きることで、サービス運営者からは把握しようがない。
- 攻撃があったとしても事業者側での観測が出来ないにもかかわらず「実際の被害は確認していない」として無かったことにされている。
mitmproxy と Android
- mitmproxy/mitmproxy#2054
- https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html
- "APIレベル24以上をターゲットとするアプリは、デフォルトで、安全な接続のためにユーザーまたは管理者が追加したCAを信頼しなくなりました。"
ソフトウェアと製造物責任の話
- ドローンが墜落したらPL法
Same Site Cookieに対する気持ち
- Same siteを一律全てのcookieに付けられるかというと、微妙なケースが存在している。cross originでのPOSTは認証、決済系のAPIで正規フローでも存在している。
- 当初は first party only cookie だったものが、後にCSRF対策を主眼としたものに変わったという経緯 https://tools.ietf.org/html/draft-west-first-party-cookies-00
- 無思考で(外部サイト埋め込み必要ない)セッションcookie等に一律付けられるほどではなく、Laxは全ての攻撃を防げるわけではなく、Strictはマゾい設定で副作用が大きすぎる
触れなかった: window.length がcross originで読めることによる情報漏洩
- 最近の面白い脆弱性事例ですぐに浮かんだけどマニアックで説明ながくなるので触れなかった
- https://twitter.com/bulkneets/status/1062941658528894976
- same origin policy に反してcross originで参照可能なプロパティがいくつか存在している(いくつかは必要とされていて廃止できない)
- Same Site strictであれば、popup windowも3rd party扱い(未ログイン状態)になるので、この手の問題も防げることになるがstrictだと弊害大きい。
- popup windowは、cross originであるにも関わらずopenerからも制御可能であるという、例外中の例外。
ソフトウェア産業における倫理について
- 自分は、ソフトウェアの欠陥が隠蔽されたり、難読化やリバースエンジニアリング禁止条項がまかり通っていることに、強い懸念を抱いている。
- ときにはセキュリティの名のもとに、そういったことが行われる(企業の評判や資産を守るだとか、利用者保護のためだとか)
- オープンに検証可能であること、自分の計算機でどんなプログラムが動いているかや、どんな通信が行われているのか知る権利は、サービス運営者の都合よりも優先されるべきものだと考えている。
- ソフトウェアは複雑に依存しあっていて、脆弱性を公表することは社会に対する責務だ。
- ソフトウェアが産業としてまだ日が浅く、社会全体の安全や、人命に関わるという認識が薄い。IoT、自動運転、医療機器、ぼちぼち無視できなくなってくるのでは。
- 現状、ソフトウェアの脆弱性を公表しなくてはならない、といった法的な義務は無いのだけれど自動車のリコールだとか食品の安全性だとかと見比べてみればいい。欠陥を公表しないことは、他の産業だったら、単なる不祥事の隠蔽だ。
- しかし、自分はまた、早急な法整備、法規制にも反対の立場をとっている。将来に禍根を残すだけでろくなことにならないからだ。
- そんなものがなくとも自主的にちゃんとやれ