この先生きのこるためにも、アカデミックな内容も頭に入れていった方がいいなと思い始めたのと、単純に面白い内容が多く好奇心が満たされるので、毎月ちょっとずつ論文を軽く読み始めている。
せっかくなので感想みたいなのを書き留めていこうと思う。
Mendeley に PDF 突っ込んであれこれするほどではないので、ブログに書いていこうと思った次第。
Embassies: Radically Refactoring the Web
USENIX NSDI'13 での発表。著者は Microsoft Research の人達らしい。
この論文を読んだのは Misreading Chat #34 - Trust and Protection in the Illinois Browser Operating System で取り上げられていたのがきっかけ。
Misreading Chat でも解説されているとおり、L4 Micro Kernel 上でブラウザを動かすという話。
面白いのはクライアントを Pico Datacenter という新しい概念としていること。
つまり、ブラウザは PasS のようなものであり、JSコードをデプロイして動いている、開発者は動作する環境を変更できる、ということを言っている。
環境を変更できるので、もし XSS を作りこんでしまっても新しいレンダリングエンジンが XSS の問題を解決しているものであれば、コードを変更せずに開発者はそのレンダリングエンジンで動作するように選択できる。
お、おぅ…
雑に言うとめちゃくちゃレンダリングエンジンやその他のレイヤを非常に細かく権限分離することで安全にする、という話。
さらに面白いのがレンダリングエンジンだけでなく、GTK や Qt のような GUI ライブラリも動かしていること。
あるタブではレンダリングエンジンが動いていて Web ぺーじが表示されている、隣のタブでは C++ と Qt で書かれたアプリケーションが、さらに隣のタブでは Python で書かれたアプリケーションが動いている…みたいなことをやっている。
アプリケーションの差異は DPI と CEI と呼ばれる謎技術で吸収され、開発者は移植性を気にしなくてよい…
すべてのアプリケーションは Web Runtime として動作して、それぞれコンテナのように IP が割り振られ TCP/IP でやりとりする。
セキュリティについてだが、SOP やら Cookie の制限が変わるということで CSRF はなくなる（Cookie を盲目的に送信しなくなる）という話をしていたがよくわからん…
XSS については安全に文字列をカプセル化するレンダリングエンジンに移行することができるようになるので、解決！という話。そんなレンダリングエンジン出ればいいですね…
ブラウザのあり方をガラッと変える提案で pico-datacenter とか DPI / CEI など新しい概念が登場し読むのが大変だった…
ブラウザを PaaS と捉えるのはなるほどなーという感じ。
しかしこれを実装している MS Research すごい…
話は逸れるが Misreading Chat めちゃくちゃ面白い…
REST-ler: Automatic Intelligent REST API Fuzzing
これも MS の論文。
現在の REST API の spec は Swagger で書かれることが多く、これをパースすることでリクエストを自動で生成、送信することが可能。
この論文では API リクエストの依存関係を推測する実装をし、Fuzzing を行ったことについて述べられている。
API リクエストの依存関係というのは、Bというリクエストを送信するにはAというリクエストを送信する必要があるもの。
例えばカートの中身を削除するAPI /cart/delete を実行するには、商品をカートに入れるAPI /cart/add を実行する必要がある、といった感じ。
この論文ではその推測アルゴリズムについて述べられているが、「ウッ…」なったので読み飛ばした…
評価実験の一つとして GitLab API に対して Fuzzing を行った結果を載せている。
結果として \0 を含むと 500 エラーになるものがいくつか見つかり、その原因は Grape ( Ruby の API ライブラリ) が原因と推測されるものを見つけている。
また、本来は認証が必要な API なのに Unauthenticated でもアクセスできる脆弱性 を見つけたとも記載されている。
リクエストの依存関係を推測するというのはQAだけでなく、脆弱性診断でも使えると思っていて、これまで手動 or 半手動（事前に定義）（Burpでいうと Auth Matrix）でしかできなかった認可部分を自動化できることが実証されたのは面白い。
ACIDRain: Concurrency-Related Attacks on Database-Backed Web Applications
SIGMOD'17 での論文。
データベースのトランザクションはデータの破損や不整合性から保護するが、開発者は適切にトランザクションを使用できておらず、また、近年の Web アーキテクチャとトランザクション分離レベルが噛み合っていないために脆弱性が生じる可能性が増えているということを示した論文。
API へ同時にリクエストを送信することにより、ギフトカードを多くもらったり、在庫を操作したりといった脆弱性が生じる。そういった並行性による脆弱性をここでは ACIDRain Attack と名付けている。
ACIDRain 攻撃は Real World でも存在し、Flexcoin はこの脆弱性を利用され、預金と引き出しのリクエストを大量に同時に実行された結果、システムが並行実行に耐えられず、サービス閉鎖に至った。
評価実験では、OSS のeコマースアプリケーションを静的解析することで、22パターンの脆弱性が20万のWebサイトで発見されたとし、ひとつのギフトカードを使い回すことで無限に購入ができる脆弱性も発見している。
論文紹介: AcidRain: Concurrency Related Attacks on Database-Backed Web Applications にて大変わかりやすくまとめられているので、興味がある人はそちらを参照してほしい。
マイクロサービス化などが主流になりつつある中で、本来一貫性を持たせなければいけないところを分けてしまって本脆弱性を生じることになる、というのは十分に考えうることであるため、まだまだ人間はトランザクションを意識しなければならないのだ…
日々、小さなベンチャー企業が Web サービスを出し続ける昨今において、いかにセキュリティを担保していくかというのは難しい問題で、継続的な脆弱性診断やWAFなどのセキュリティ製品の導入などが打つ手として考えられる。
しかし WAF を入れて「はい終わり」というわけにはいかず、当然防げない攻撃(今回取り上げた認可不備や ACIDRain)もあるし、誤検知への対応もある。
継続的な脆弱性診断も新規サービスにおいては機能追加改善によるリリースを週単位で行うだろうし、「穴がある期間」というのは存在してしまうだろう。
開発サイクルのスピードを確保しつつセキュリティを向上させる DevSecOps を回していくには、今回取り上げたような研究の技術を現場に取り込んでいくことが大事だろうと考えている。
特に REST-ler: Automatic Intelligent REST API Fuzzing はその点において有用で、これを CI で回すなどの活用ができるし、ACIDRain を検出するようなペイロードを取り入れることも可能だ。
（アプリケーションに限らず、インストールされているパッケージの）脆弱性検出の自動化というのは、今から取り組んでいかないといけない課題だし、今自分が一番したいことだ。
また、 Embassies: Radically Refactoring the Web のようにプラットフォームやライブラリ側で安全にし、開発者はセキュリティを意識しなくてもよくなる時代が来るのも、面白いしそうあるべきだと考えている。