SQLインジェクションの考慮漏れは恥ずかしい
今となっては、ソフトウェア／システムというとセキュリティを考慮するのは「当たり前」となりました。
その「当たり前」をほんの少しでも軽視すれば
ということが平気で起きてしまいます。
セキュリティについてはソフトウェア品質の世界でも重要視されているため、ISO 9126の頃には機能性の一部としてしか取り扱われなかった「セキュリティ」の品質特性は、ISO 25010へとバージョンアップした際にランクアップするようになりました。
「セキュリティ」に関する観点は、ハードウェア、ネットワークのみならずソフトウェアの構成やプログラム内容にも及びます。
その１つがSQLインジェクション。インジェクションとは「挿入」などと言われますが、弱い部分（脆弱性）を利用して、そこに悪意ある何かを挿し込んでくる攻撃のことです。
なかでも、データベースアクセスで用いられるSQLという言語…というか操作命令文の取り扱いに慣れていないエンジニアの初歩的な検討漏れによって利用者の悪意が挿し込めるように作りこんでしまうのが、このSQLインジェクションです。
仕組みとしてはいたって簡単です。
このようにユーザ情報などを取得するSQLでは、上記の例を解釈すると
// 全項目取得せよSELECT *とすることでそのユーザ情報すべてを取得するように仕向け、
// idが'john'のもの、または 'A'と言う文字が'A'と言う文字と一致する場合
WHERE id='john' or 'A'='A'と言う条件にすることで、or 'A'='A' が常に条件を満たしてしまうため、かならず全データを引き出せてしまうような漏洩目的の攻撃となります。
SQLインジェクションには多様性がありません。
このように、SQLを利用者がそのまま悪用できるような仕組みとなってさえいれば簡単に実施できてしまうようになっています。
このようなシンプルな攻撃であるため、普通に
「指定した意味を持つ値以外、入力を許可しない」
と言うチェック意識が開発者側に存在していれば、セキュリティ云々以前に機能性と言う品質観点から防げる問題です。
また、O/Rマッピング機能を持つフレームワークであれば大抵の場合は良きに計らってくれるためそういった検討の必要もありません。たとえば、有名なO/Rマッパーであるmybatisの場合
<select id="selectUsers" resultType="User">
select
*
from some_table
where id = #{id}
</select>と記述されていれば、SQLインジェクションの心配はありません。
mybatisがエスケープしてくれます。
しかし、
<select id="selectUsers" resultType="User">
select
*
from some_table
where id = ${id}
</select>と記載されれば、SQLインジェクションの対象になりかねません。mybatisについてはわかりやすい書籍が少ないという点もありますが、公式サイトの説明を読むだけでも使い方は８割方理解できます。
ちなみに、この問題については次のように記載されています。
まぁmybatisを例に挙げたのは、私のなかの得意言語がJavaでSpringBootあたりで止まってしまっているから…というだけですが。
さて。
先述にもあるように、この手の観点は厳密には「セキュリティ」や「信頼性」に帰属する課題ではありません。問題として顕在化した際にセキュリティや信頼性に影響が出るというだけで、設計思想や品質の観点から言えば、
取り扱うデータの妥当性を保証する
という一般的な機能品質のレベルにとどまります。もっと具体的に言えば「コードレビューで見つかってもおかしくないんじゃね？」というレベルのバグです。
特にSQLインジェクションなんてものはセキュリティ対策においてもよく聞くキーワードで、しかも問題として取り沙汰されてからかれこれ10年…15年以上経ったレガシーな品質観点です。さすがに昨今では考慮しない方がエンジニアとして恥ずかしい問題だったりもしますので、忘れることがないようにしましょう。
でも、テストケースなどを第三者的にチェックしていても、この程度のソフトウェアレベル（…なので、一般的には機能内結合テスト相当）のチェックリストには必ずと言っていいほど存在していて当然かと思われるのですが、なかなか見かけたことが無いんですよね。
どこか私の与り知らないほかのテストの中で実施しているのかな…。
いいなと思ったら応援しよう！
