Kazuho's Weblog: ウェブアプリの「合理的な」セキュリティ対策に関する一考察

※※※ミドルウェアを中心に、ウェブ関連の研究開発に携わっている者による雑文です※※※

ウェブの脆弱性は、ウェブアプリケーションのバグに起因するものと、ウェブブラウザのバグに起因するものの２者に大別することができる。

ウェブアプリケーションを開発／提供する仕事に従事している者には、この前者、すなわち、ウェブアプリケーションのバグに起因する脆弱性を最小限に抑え込むことを求められる^注1。

かといって、脆弱性がないことを保障するのは難しい。「ウェブアプリケーションにバグがあっても脆弱性とはならない（あるいは被害が限定される）ような設計」を採用するのが現実的だと考えられる。

OSにおける、プロセス間のメモリ分離やuserIDに基づいたファイルへのアクセス制御を考えてみると、OSがセキュリティを「強制」するため、アプリケーション側で不正なコードが実行されても脆弱性とならない、もしくは、影響を小さく抑え込むことができるようになっていることがわかる。

ウェブ技術における同様の例は数多いが、たとえばXSS脆弱性対策を見ると、

Content Security Policy

実行可能なスクリプトを制限する機能

HttpOnly

スクリプトからアクセス不可能なクッキー

自動エスケープ対応のテンプレートエンジン

Xslate等^注2

といったものを挙げることができる。また、SQL Injection対策を見ると、

(ある種の)2-way SQL

SQLは外部ファイルに書き、プログラムからはバインドするパラメータしか操作できない
参考: 外だしSQLの使い方 | DBFlute

ストアドプロシージャによるアクセス手法限定

参考: パスワードが漏洩しないウェブアプリの作り方〜ソルトつきハッシュで満足する前に考えるべきこと

等の手法が知られている。

これらの対策をひとつ選択し、あるいは組み合わせて使うことで、コーディングミスがあったとしても脆弱性が発現しない（もしくは発現する可能性が低い）アプリケーションを実現することができる。

ただ、この種の技術には多かれ少なかれ、アプリケーション側のコードに不自由を強いるという側面がある。

たとえば、Content Security Policyには、インラインの<SCRIPT>タグを実行しづらいという制限がある（1.1で修正見込）し、例として挙げたSQL Injection対策のいずれもが現実的でないウェブアプリケーションも多いだろう。また、SQLにおける条件節の漏れによる情報漏洩のように、本質的に対策が難しい^注3問題も存在する。

以上のように、共通モジュール（あるいは下位レイヤ）でアクセス方法を「強制」する仕組みを用いることで、脆弱性への耐性を高めるという情報工学における一般的なアプローチは、ウェブ技術においても有効であり、積極的に使用すべきである^注4。一方で、述べたように、今後の発展が期待される分野も存在する^注5。

注1: 後者については、一義的にはウェブブラウザベンダーが対応すべき問題である。もちろん、ウェブアプリケーション側で緩和策が実装できるならすれば良いケースもある

注2: 最新のテンプレートエンジン事情を良く知らないので列挙はしません。また、DOM　APIベースのアプローチについても本稿では割愛します。

注3: ウェブアプリケーションにおいては、アクセス制限とアクセスを単一のクエリで記述することを求められることが多いため。この点は、ケーパビリティの概念を導入したORMのようなアプローチで解決可能なのかもしれないが…

注4: 「IPA 独立行政法人情報処理推進機構：安全なウェブサイトの作り方」では、脆弱性を９種類に類型化して説明しているが、そのほとんどは「アプリケーションプログラマがミスをしても問題ない」ような共通コード（ウェブアプリケーションフレームワークやライブラリ等）の使用により回避することが可能であるし、そのような実装が称揚されるべきである

注5: なので、研究課題として面白いと思います