HOME > Scutumを支える技術 > Scutum技術ブログ

技術者ブログ

クラウド型WAF「Scutum(スキュータム)」の開発者/エンジニアによるブログです。
金床“Kanatoko”をはじめとする株式会社ビットフォレストの技術チームが、“WAFを支える技術”をテーマに幅広く、不定期に更新中!

2020年8月

            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Scutum開発者/エンジニアによる技術ブログ WAF Tech Blog

サブクエリとSQLインジェクション

はじめに

SQLインジェクションという攻撃手法(脆弱性)は10年以上前から基本的な原理は変わっていません。しかし攻撃される対象であるデータベースそのものは少しずつ進化し、新たな機能や文法、関数をサポートしていきます。そのため、SQLインジェクションの脆弱性が存在する場合に、そこから「どのように攻撃して、その結果何ができるか?」という点については、データベースの進化に合わせた変化があります。

WAFは防御対象となるウェブアプリケーションに脆弱性がある前提でSQLインジェクション攻撃を見つけるものであるため、データベースの比較的新しい機能や文法を使われたとしても、きちんと見つけることができるようになっていることが理想的です。

Scutumにおいてもデータベースが比較的最近サポートするようになった文法等に合わせて防御を強化しています。今回はサブクエリを使ったSQLインジェクションを例として紹介します。

普通のサブクエリの形

攻撃者が任意のテーブル(SQLを注入できる場所とは別のテーブル)のデータを盗むために頻繁に使われるのがサブクエリです。そもそもサブクエリとは何か?という事についてはここでは説明を省略します。

サブクエリは一般的に

(select ...

という形、つまり始め小括弧(←が正式名称なのかどうか自信がないですが)に続いてselectが来ます。

攻撃者の立場からするとサブクエリは非常に便利な存在であり、攻撃において頻繁に利用されます。そのため、WAFの立場からはSQLインジェクションの検知においてサブクエリを見つけることはとても大きなポイントになります。

selectという単語自体はポピュラーなので、単にselectの存在だけで「SQLインジェクションの攻撃である」と分類してしまうと、ごく普通の英文に対しての誤検知が増えてしまいます。しかし(に続いてselectとなると、それはSQLインジェクションである確率がぐっと高くなります(もちろん、誤検知の可能性もあります)。

そのせいか、私が調査してみたところ、シグネチャを使って検知を行おうとする(いわゆるシグネチャ依存型の)WAFでは、(に続いてselectという単語があるかどうか?という点をはっきりと認識し、それを大きな材料として分類するものが存在するようです。

「(select...」ではないサブクエリ

さて攻撃者の立場から、「WAFを回避しつつ、サブクエリを使いたい」と考えてみます。先述したようにWAFが(selectを注視してくるケースが想定できるので、攻撃者としては「select文だが、出だしはselectでない文を作る」ことを目指します。

次のようにwith句を使うことで、目的が達成できます。

with foo as ( values(1) ) select 1;

with foo as(values row(1)) select 1;

上はPostgreSQL、下はMySQLの例です。MySQLでは比較的最近のバージョンでwith句がサポートされました。

この例ではselectは一般的なサブクエリとは異なり、「始め小括弧」ではなく、「終わり小括弧」の次に来ています。また、with foo as(に続いてselectが来てしまっては意味がないので、valuesをうまく使うことで(selectが存在しないselect文にしています。

WAFの穴になる場合がある

WAFが「サブクエリは必ず"(select ..."という形だ」という検知ロジックの場合には、このようにwith句を使うことで回避(Evasion)が成立する場合があります。

私は以前の記事「WAFにおけるシグネチャの功罪」において、シグネチャ依存型WAFには「回避されやすい」という欠点があると書きました。ここで

一度回避する方法を見つけてしまえば、以後その部分に気をつけることで、シグネチャに見つかること無く様々な攻撃を行うことができます。

と説明したのが、まさに今回のようなケースになります。一部分だけ(今回でいえば、selectの左側に「始め小括弧」があるかどうか)でも突破口が見つかってしまうと、後はそこからやりたい放題、自由にselect文を組み立てられてしまうのです。

Scutumのようにシグネチャ依存型ではなく、確率を用いて判断するWAFでは、(selectがない場合でも他の部分から総合的に「これはSQLインジェクションだ」と判断できます。

まとめ

今回はデータベースやSQLの機能拡張が、SQLインジェクション攻撃やそれを見つけるWAFにどのような影響を及ぼすのかについて、わかりやすい例を元に簡単に紹介しました。

これ以外にも、データベース固有の、新しく実装された関数などで同じ問題が起こることもあります。Scutumではこのようなケースにも引き続きしっかり対応していきたいと考えています。