SQLインジェクション

コンピューティングにおいて、SQLインジェクションは、データ駆動型アプリケーションを攻撃するために使用されるコードインジェクション手法であり、悪意のあるSQL文が実行のために入力フィールドに挿入されます（たとえば、データベースの内容を攻撃者にダンプするため）。^{[1] [2]} SQLインジェクションは、アプリケーションソフトウェアのセキュリティ脆弱性を悪用する必要があります。たとえば、ユーザー入力がSQL文に埋め込まれた文字列リテラルエスケープ文字に対して誤ってフィルタリングされた場合、またはユーザー入力が厳密に型指定されておらず、予期せず実行された場合などです。SQLインジェクションは、主にWebサイトの攻撃ベクトルとして知られていますが、あらゆる種類のSQLデータベースを攻撃するために使用できます。

SQLインジェクション攻撃により、攻撃者はIDを偽装したり、既存のデータを改ざんしたり、取引の無効化や残高の変更などの否認問題を引き起こしたり、システム上のすべてのデータを完全に開示したり、データを破壊したり利用できないようにしたり、データベースサーバーの管理者になったりすることができます。ドキュメント指向のNoSQLデータベースも、このセキュリティ脆弱性の影響を受ける可能性があります。^[3]

2012年の調査では、平均的なウェブアプリケーションは月に4回の攻撃キャンペーンを受けており、小売業者は他の業界の2倍の攻撃を受けていることが観察されました。 ^[4]

1998年のPhrack Magazineの記事など、SQLインジェクションに関する議論は1990年代後半に始まりました。^{[5] SQLインジェクションは}、Open Web Application Security Projectによって2007年と2010年のWebアプリケーションの脆弱性トップ10の1つと見なされました。^[6] 2013年には、SQLインジェクションはOWASPトップ10の攻撃の第1位にランクされました。^[7]

SQL インジェクションは、攻撃者が提供したデータが SQL コードになることで発生する一般的なセキュリティ脆弱性です。これは、プログラマーが文字列補間によって、または SQL コマンドとユーザー提供データを連結することによって SQL クエリを組み立てるときに発生します。したがって、インジェクションは、SQL ステートメントが SQL ステートメントで使用されるデータと、SQL ステートメントの実行方法を制御するコマンドの両方で構成されているという事実に依存しています。たとえば、SQL ステートメントでは、文字列 ' ' はデータであり、フラグメントはコマンドの例です (この例では値もデータです)。 select * from person where name = 'susan' and age = 2susanand age = 22

SQL インジェクションは、特別に細工されたユーザー入力が受信側プログラムによって処理され、入力がデータ コンテキストを終了してコマンド コンテキストに入る場合に発生します。これにより、攻撃者は実行される SQL ステートメントの構造を変更できます。

簡単な例として、上記のステートメントのデータ ' susan' がユーザー入力によって提供されたとします。ユーザーはsusan、Web フォームのテキスト入力フィールドに文字列 ' ' (アポストロフィなし) を入力し、プログラムは文字列連結ステートメントを使用して、3 つのフラグメント、ユーザー入力 ' '、およびから上記の SQL ステートメントを形成しました。 select * from person where name='susan' and age = 2

susanここで、攻撃者が'' を入力する代わりに を入力したと想像してください。 ' or 1=1; --

プログラムは、 の 3 つのフラグメント、 のユーザー入力、およびに対して同じ文字列連結アプローチを使用し、ステートメント を構築します。多くのデータベースは、コメントを示すため、文字列 '--' の後のテキストを無視します。SQL コマンドの構造は次のようになります。これにより、年齢が 2 である 'susan' という名前の行だけでなく、すべての person 行が選択されます。攻撃者は、データ コンテキストを終了してコマンド コンテキストに入るデータ文字列を作成することに成功しました。 select * from person where name='' or 1=1; --' and age = 2select * from person where name='' or 1=1; --' and age = 2select * from person where name='' or 1=1;

すべての SQL インジェクションの根本的な原因は同じですが、それを悪用する手法はさまざまです。そのいくつかを以下に説明します。

プログラムが次の文字列割り当てコマンドを使用して SQL ステートメントを作成するとします。

var statement = "SELECT * FROM users WHERE name = '" + userName + "'";

この SQL コードは、指定されたユーザー名のレコードをユーザー テーブルから取得するように設計されています。ただし、悪意のあるユーザーによって "userName" 変数が特定の方法で細工されている場合、SQL ステートメントはコード作成者の意図を超える動作を行う可能性があります。たとえば、"userName" 変数を次のように設定します。

' または '1' = '1

または、コメントを使用してクエリの残りの部分をブロックすることもできます（SQLコメントには3つの種類があります^[8]）。3行とも最後にスペースがあります。

' または '1' = '1' --
' または '1' = '1' {
' または '1' = '1' /*

親言語によって次のいずれかの SQL ステートメントをレンダリングします。

SELECT * FROM users WHERE name = '' OR '1' = '1' ;         

SELECT * FROM users WHERE name = '' OR '1' = '1' -- ';          

このコードを認証手順で使用する場合、この例を使用して、コード作成者の意図どおりに特定のユーザー名からではなく、すべてのユーザーからすべてのデータ フィールド (*) を強制的に選択することができます。これは、「1」=「1」の評価が常に true になるためです。

以下のステートメントの「userName」の値は、複数のステートメントを許可する API を使用して、「users」テーブルを削除するとともに、「userinfo」テーブルからすべてのデータを選択します (つまり、すべてのユーザーの情報が公開されます) 。

a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

この入力により、最終的な SQL ステートメントが次のようにレンダリングされ、指定されます。

SELECT * FROM users WHERE name = 'a' ; DROP TABLE users ; SELECT * FROM userinfo WHERE 't' = 't' ;                 

ほとんどの SQL サーバー実装では、このように 1 回の呼び出しで複数のステートメントを実行できますが、PHPのmysql_query()関数などの一部の SQL API では、セキュリティ上の理由からこれが許可されていません。これにより、攻撃者が完全に別のクエリを挿入することは防止されますが、クエリを変更することは防止されません。

ブラインド SQL インジェクションは、Web アプリケーションが SQL インジェクションに対して脆弱であるが、インジェクションの結果が攻撃者には見えない場合に使用されます。脆弱性のあるページは、データを表示するページではない可能性がありますが、そのページに対して呼び出される正当な SQL ステートメントに挿入された論理ステートメントの結果に応じて、異なる表示になります。このタイプの攻撃は、回復されたビットごとに新しいステートメントを作成する必要があり、その構造によっては、攻撃が多数の失敗したリクエストで構成される可能性があるため、従来は時間がかかると考えられていました。最近の進歩により、各リクエストで複数のビットを回復できるようになり、失敗したリクエストがなくなり、より一貫性のある効率的な抽出が可能になりました。^[9]脆弱性の場所とターゲット情報が確立されると、これらの攻撃を自動化できるツールがいくつかあります。^[10]

ブラインドSQLインジェクションの1つのタイプは、通常のアプリケーション画面上の論理ステートメントをデータベースに評価させるものです。例えば、書評サイトはクエリ文字列を使用してどの書評を表示するかを決定します。したがって、URLは https://books.example.com/review?id=5サーバーにクエリを実行させます。

bookreviewsから* を選択WHERE ID = '5' ;       

そこから、 ID 5のレビューのデータをレビュー ページに入力します。このレビューは bookreviewsテーブルに格納されています。クエリは完全にサーバー上で実行されます。ユーザーはデータベース、テーブル、フィールドの名前を知らず、クエリ文字列も知りません。ユーザーには、上記の URL が書評を返すことだけがわかります。ハッカーはURL と をロードして、クエリを実行することができます 。https://books.example.com/review?id=5' OR '1'='1https://books.example.com/review?id=5' AND '1'='2

SELECT * FROM bookreviews WHERE ID = '5' OR '1' = '1' ; SELECT * FROM bookreviews WHERE ID = '5' AND '1' = '2' ;         
         

それぞれ。元のレビューが「1=1」URLで読み込まれ、「1=2」URLから空白またはエラーページが返され、返されたページがユーザーに入力が無効であることを警告するために作成されていない場合、つまり、入力テストスクリプトによってキャッチされた場合、クエリは両方のケースで正常に通過する可能性が高いため、サイトはSQLインジェクション攻撃に対して脆弱である可能性があります。ハッカーは、サーバーで実行されているMySQLのバージョン番号を明らかにするように設計された次のクエリ文字列を使用して続行する可能性があります。これにより、MySQL 4を実行しているサーバーで書籍レビューが表示され、そうでない場合は空白またはエラーページが表示されます。ハッカーは、クエリ文字列内のコードを使用して目的を直接達成するか、別の攻撃方法を見つけることを期待してサーバーからより多くの情報を収集し続けることができます。^{[11] [12]}https://books.example.com/review?id=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4

2 次 SQL インジェクションは、アプリケーションが SQL を即時のユーザー入力に対してのみ保護し、システムにすでに保存されているデータを処理する際のポリシーがそれほど厳格でない場合に発生します。したがって、このようなアプリケーションはユーザー入力を安全に処理して問題なく保存できますが、悪意のある SQL ステートメントも保存します。その後、そのアプリケーションの別の部分が SQL インジェクションから保護されていないクエリでそのデータを使用すると、この悪意のあるステートメントが実行される可能性があります。^[13] この攻撃には、送信された値が後で使用される方法についてのより多くの知識が必要です。自動化された Web アプリケーション セキュリティ スキャナーでは、このタイプの SQL インジェクションを簡単に検出することはできず、試行されている証拠を確認する場所を手動で指示する必要がある場合があります。

この種の攻撃から保護するには、データ ソースに関係なく、すべての SQL 処理が均一に安全である必要があります。

SQLインジェクションはよく知られた攻撃であり、簡単な対策で簡単に防ぐことができます。2015年にTalkTalkがSQLインジェクション攻撃を受けた際、 BBCは、このような大企業がSQLインジェクション攻撃に対して脆弱だったことにセキュリティ専門家が驚愕したと報じました。^[14]パターンマッチング、ソフトウェアテスト、文法分析などの手法は、これらの攻撃を軽減するための一般的な方法です。^[2]

以下に記載する予防策は、簡単な 2 部構成のチェックリストにまとめることができます。

1. すべての変数データリテラルは、クエリ内で特別なマーカーで表現され、後で準備されたステートメントを通じてクエリにバインドされる必要があります。
2. その他のクエリ部分（キーワードやデータベーススキーマ名など）はホワイトリストでフィルタリングする必要があります。

両方のルールの使用方法を示す PHP の簡単な例:

$mysqli  =  new  mysqli ( 'hostname' ,  'db_username' ,  'db_password' ,  'db_name' ); 
$sort_column  =  $_GET [ 'sort_column' ]  ??  'name' ; 
// 列名をホワイトリストと照合します: 
if  ( ! in_array ( $sort_column ,  [ 'name' ,  'birthday' ],  true ))  { 
    throw  new  InvalidArgumentException ( "Invalid sort column" ); 
} 
// パラメータを使用してデータ値を表します: 
$query  =  "SELECT * FROM `users` WHERE `birthday` > ? ORDER BY ` $sort_column `" , 
// SQL を準備し、誕生日の値をバインドしてクエリを実行します: 
$result  =  $mysqli -> execute_query ( $query ,  [ $_GET [ 'birthday' ]]);

こうすることで、悪意のあるデータが SQL に取り込まれることがなくなります。

インジェクションを防ぐ従来の方法の 1 つは、すべてのデータを引用符で囲んだ文字列として追加し、そのデータ内の SQL 文字列で特別な意味を持つすべての文字をエスケープすることです。 ^[15] SQL DBMS のマニュアルには、どの文字が特別な意味を持つかが説明されており、これにより、変換が必要な文字の包括的なブラックリストを作成できます。たとえば、文字列パラメータ内の単一引用符 ( ') のすべての出現の前にバックスラッシュ ( ) を付加する必要があります\。これにより、データベースは単一引用符が文字列の終端文字ではなく、特定の文字列の一部であることを理解します。PHPのMySQLiモジュールは、MySQL のmysqli_real_escape_string()セマンティクスに従って文字列をエスケープする機能を提供します。次の例では、ユーザー名は文字列パラメータであるため、文字列エスケープによって保護できます。

$mysqli  =  new  mysqli ( 'hostname' ,  'db_username' ,  'db_password' ,  'db_name' ); 
$query  =  sprintf ( "SELECT * FROM `Users` WHERE UserName='%s'" , 
                  $mysqli -> real_escape_string ( $username ), 
$mysqli -> query ( $query );

プログラマーだけが文字列パラメータを注意深くエスケープすることに頼ると、プロセス中に見落としが発生する可能性があるため、固有のリスクが生じます。この脆弱性を軽減するために、プログラマーはパラメータのエスケープを自動化する独自の抽象化レイヤーを開発することを選択できます。 ^[16]

さらに、すべてのデータが文字列リテラルとしてSQLに追加できるわけではない（MySQLのLIMIT句の引数^[17]やテーブル名/列名^[18]など）。この場合、文字列関連の特殊文字をエスケープしても何の役にも立たず、結果として得られるSQLはインジェクションに対して無防備なままになります。

HibernateやActiveRecordなどのオブジェクト リレーショナル マッピング(ORM) フレームワークは、リレーショナル データベースに対するクエリ用のオブジェクト指向インターフェイスを提供します。ほとんどの ORM は、フレームワークのクエリ API の一部として、SQL インジェクション攻撃を防ぐために必要なエスケープ処理を自動的に行います。ただし、多くの ORM はマッピング機能をバイパスして生の SQL 文を発行する機能を提供しており、この機能を不適切に使用すると、インジェクション攻撃の可能性が生じます。^[19]

ほとんどの開発プラットフォームでは、パラメータを扱うパラメータ化文（プレースホルダやバインド変数と呼ばれることもある）を、文にユーザ入力を埋め込む代わりに使用できる。プレースホルダは、任意のSQLフラグメントではなく、指定された型の値のみを格納できる。したがって、SQLインジェクションは単に奇妙な（おそらく無効な）パラメータ値として扱われる。多くの場合、SQL文は固定されており、各パラメータはテーブルではなくスカラーである。ユーザ入力はパラメータに割り当てられる（バインドされる）。^[20]

整数、浮動小数点数、またはブール文字列パラメータをチェックして、その値が指定された型の有効な表現であるかどうかを判断できます。特定のパターンまたは条件に従う必要がある文字列 (日付、UUID、電話番号など) もチェックして、そのパターンが一致するかどうかを判断することができます。

Web アプリケーションで使用されるデータベース ログインの権限を必要なものだけに制限すると、Web アプリケーションのバグを悪用する SQL インジェクション攻撃の影響を軽減できる可能性があります。

たとえば、Microsoft SQL Serverでは、データベース ログオンで一部のシステム テーブルの選択を制限できるため、データベース内のすべてのテキスト列に JavaScript を挿入しようとする攻撃を制限できます。

webdatabaselogonに対するsys.sysobjectsの選択を拒否します。webdatabaselogonに対するsys.objectsの選択を拒否します。webdatabaselogonに対するsys.tablesの選択を拒否します。webdatabaselogonに対するsys.viewsの選択を拒否します。webdatabaselogonに対するsys.packagesの選択を拒否します。     
     
     
     
     

• 2002年2月、ジェレミア・ジャックスは、Guess.comがSQLインジェクション攻撃に対して脆弱であり、適切に作成されたURLを構築できる人なら誰でも、サイトの顧客データベースから20万件以上の名前、クレジットカード番号、有効期限を取得できることを発見しました。^[21]
• 2005年11月1日、10代のハッカーがSQLインジェクションを使用して、台湾のテックターゲットグループの情報セキュリティ雑誌のサイトに侵入し、顧客の情報を盗みました。 ^[22]
• 2006年1月13日、ロシアのコンピュータ犯罪者がロードアイランド州政府のウェブサイトに侵入し、州政府機関とオンラインで取引した個人のクレジットカード情報を盗んだとされている。^[23]
• 2007年9月19日と2009年1月26日、トルコのハッカー集団「m0sted」はSQLインジェクションを利用してMicrosoftのSQL Serverを悪用し、それぞれマカレスター陸軍弾薬工場と米国陸軍工兵隊のWebサーバーをハッキングした。^[24]
• 2008年4月13日、オクラホマ州の性犯罪者および暴力犯罪者登録簿は、性犯罪者の社会保障番号10,597件がSQLインジェクション攻撃によってダウンロードされたとの通知を受け、「定期メンテナンス」のためにウェブサイトを閉鎖した^[25]。
• 2009年8月17日、米国司法省は、 SQLインジェクション攻撃を使用して1億3000万件のクレジットカード番号を盗んだとして、アメリカ人のアルバート・ゴンザレスと名前を明かしていないロシア人2人を起訴した。伝えられるところによると「アメリカ史上最大の個人情報窃盗事件」で、この男は、多数の企業の支払処理システムを調査した後、被害者からカードを盗んだ。被害を受けた企業には、クレジットカード処理業者のハートランド・ペイメント・システムズ、コンビニエンスストアチェーンのセブンイレブン、スーパーマーケットチェーンのハンナフォード・ブラザーズなどがあった。^[26]
• 2010年7月、 「Ch Russo」というハンドルネームを持つ南米のセキュリティ研究者が、人気のBitTorrentサイトThe Pirate Bayから機密性の高いユーザー情報を入手した。彼はサイトの管理コントロールパネルにアクセスし、SQLインジェクションの脆弱性を悪用して、IPアドレス、MD5 パスワードハッシュ、個々のユーザーがアップロードしたトレントの記録など、ユーザーアカウント情報を収集した。^[27]
• 2010年7月24日から26日にかけて、日本と中国の攻撃者がSQLインジェクションを使用して、大規模なオンラインスーパーマーケットサイトを運営する大阪に拠点を置く企業であるNeo Beatの顧客のクレジットカード情報にアクセスしました。この攻撃は、スーパーマーケットチェーンのイズミヤ、マルエツ、琉球ジャスコを含む7つのビジネスパートナーにも影響を及ぼしました。データの盗難は、12,191人の顧客に影響したと報告されています。2010年8月14日現在、中国で商品やサービスを購入するために第三者がクレジットカード情報を使用したケースが300件以上あると報告されています。
• 2010年9月19日、スウェーデン総選挙中に、有権者が記名投票の一環としてSQLコマンドを手書きしてコードインジェクションを試みた。^[28]
• 2010年11月8日、イギリス海軍のウェブサイトがSQLインジェクションを使用してTinKodeというルーマニア人のハッカーによって侵害されました。^{[29] [30]}
• 2011年4月11日、バラクーダネットワークスはSQLインジェクションの脆弱性を利用して侵入を受けました。入手された情報の中には、従業員の電子メールアドレスやユーザー名が含まれていました。^[31]
• 2011年4月27日の4時間にわたって、ブロードバンドレポートのウェブサイトで自動SQLインジェクション攻撃が発生し、ユーザー名/パスワードのペアの8%（アクティブな9,000アカウントと古いまたは非アクティブな90,000アカウントのうちランダムに選ばれた8,000アカウント）が抽出されました。^{[32] [33] [34]}
• 2011年6月1日、LulzSecグループの「ハクティビスト」が、SQLインジェクションを使用してソニーのウェブサイトにプレーンテキストで保存されていたクーポン、ダウンロードキー、パスワードを盗み、100万人のユーザーの個人情報にアクセスしたとして告発されました。^[35]
• 2011年6月、PBSはLulzSecによってハッキングされましたが、これはおそらくSQLインジェクションによるものでした。ハッカーがSQLインジェクションを実行するために使用した全プロセスは、このImpervaブログで説明されています。^[36]
• 2012年7月、ハッカー集団がYahoo!から45万件のログイン認証情報を盗んだと報じられた。ログイン情報はプレーンテキストで保存されており、Yahoo!のサブドメインであるYahoo! Voicesから盗まれたとされている。この集団は「ユニオンベースのSQLインジェクション技術」を使ってYahooのセキュリティを侵害した。^{[37] [38]}
• 2012年10月1日、「Team GhostShell」と呼ばれるハッカー集団が、ハーバード大学、プリンストン大学、スタンフォード大学、コーネル大学、ジョンズ・ホプキンス大学、チューリッヒ大学を含む53の大学の学生、教員、職員、卒業生の個人記録をpastebin.comに公開した。ハッカーらは、ヨーロッパの教育法の変化や米国の学費の値上げを嘆き、「今日の教育における変化に対する意識を高めようとしている」と主張した。^[39]
• 2013年11月4日、ハクティビスト集団「RaptorSwag」が中国国際商工会議所へのSQLインジェクション攻撃により中国政府のデータベース71件を侵害したとされる。漏洩したデータはアノニマスの協力により公開された。^[40]
• 2014年8月、ミルウォーキーに拠点を置くコンピュータセキュリティ会社ホールドセキュリティは、SQLインジェクションを通じて約42万のウェブサイトから機密情報が盗まれたことを明らかにした。 ^[41] ニューヨークタイムズは、この主張を確認するためにセキュリティ専門家を雇い、この発見を確認した。^[42]
• 2015年10月、英国の通信会社トークトークのサーバーから、レガシーウェブポータルの脆弱性を悪用したSQLインジェクション攻撃によって156,959人の顧客の個人情報が盗まれた。 ^[43]
• 2021年初頭、SQLインジェクション攻撃により極右ウェブサイトGabから70ギガバイトのデータが流出した。この脆弱性は、GabのCTOであるFosco MarottoによってGabのコードベースに導入された。^{[44]翌週、最初の攻撃で盗まれた}OAuth2トークンを使用して、Gabに対する2回目の攻撃が開始された。^[45]

• 2007年のxkcdの漫画には、SQLインジェクションを実行するために名付けられたロバートというキャラクターが登場しました。この漫画の影響で、SQLインジェクションは非公式に「ボビーテーブル」と呼ばれることもあります。^{[46] [47]}
• SQL インジェクションによる Web サイトへの不正ログインは、J.K. ローリングの 2012 年の小説『カジュアル・ベイカンシー』のサブプロットの 1 つに基づいています。
• 2014年、ポーランドのある個人が、スパマーの収集ボットの活動を妨害するために、法的に自分の会社名をDariusz Jakubowski x'; DROP TABLE users; SELECT '1に変更しました。^[48]
• 2015 年のゲームHacknetには、SQL_MemCorrupt と呼ばれるハッキング プログラムがあります。これは、SQL データベースに破損エラーを引き起こすテーブル エントリを挿入し、そのテーブルをクエリして、SQL データベースのクラッシュとコア ダンプを引き起こすと説明されています。

• コードインジェクション
• クロスサイトスクリプティング
• Metasploit プロジェクト
• OWASPオープン Web アプリケーション セキュリティ プロジェクト
• プロンプトインジェクション、人工知能に適用される同様の概念
• SGMLエンティティ
• 制御されていない書式文字列
• ワフ
• Webアプリケーションのセキュリティ

• OWASP による OWASP SQL インジェクション チート シート。
• WASC 脅威分類 - Web アプリケーション セキュリティ コンソーシアムによる SQL インジェクション エントリ。
• SQL インジェクションがなくならない理由 2012 年 11 月 9 日にWayback Machineにアーカイブされました(著者: Stuart Thomas)。
• Bala Neerumalla による SQL インジェクションに関する SDL クイック セキュリティ リファレンス。
• セキュリティ上の欠陥の仕組み: SQL インジェクション