注1:文字コードを利用した脆弱性 |
---|
文字コードを利用した脆弱性はいくつか存在するが、代表的なものとして以下のようなものがある。 |
1. 文字コードの変換による脆弱性 |
各ソフトウェア(データベース、ミドルウェア、開発言語)で取り扱っている文字コードが異なる場合、文字コードを変換する際に、別の意味を持つ文字に変換されることがあり、結果的にSQLインジェクションなどの脆弱性につながることがある。 特に、Unicodeから他の文字コード(Shift-JISなど)に変換する場合、Unicodeにあって、他の文字コードにない文字を似たような文字に変換してしまうことがある。たとえば、Unicodeのバックスラッシュ(半角の\)と円記号(\)など。 Unicodeではこれらを別のもの(それぞれ0x5CとU+00A5)と規定しているが、他の文字コード(Shift-JIS、EUC、JIS)では、同じ0x5Cと規定している。 このため、ウェブアプリケーションではUnicodeを使用しており、データベースではShift-JISを使用している場合、文字コードの変換により、ウェブアプリケーションでは問題がないU+00A5が、データベースではエスケープ文字を表すことがある0x5C(\)に変換され、正しくエスケープされなくなる。 結果として、SQLインジェクションが発生する場合がある。たとえば、ウェブアプリケーションではUnicodeを使用し、データベースではShift-JISを使用している場合、以下のようなSQL文の“入力データ1”に「0xA5」、“入力データ2”に「 or 1=1;--」という値を使用すると、データベースでは以下のようなSQL文を意味する。 ■変換前
このデータベースで「\」をエスケープ文字として利用できる場合、userNameの検索条件の文字列定数の終了を意味する「'」が検索条件の一部と解釈され、すべてのデータを検索するSQL文を実行してしまう。 |
2. マルチバイト文字の解釈のミスによる脆弱性 |
正しく日本語に対応していないソフトウェアでは、文字の1バイト目だけを見てその文字がマルチバイトの文字か、1バイトの文字かを判断していることがあり、0x81などのデータを用いることで、文字列定数の区切り記号である「'」を無効化できることがある。 たとえば、データベースがこのようにマルチバイト文字を解釈しているとすると、先のSQL文の例であれば、入力データ1に0x81、入力データ2に「 or 1=1;--」を使用した場合、そのSQL文は以下のようになる。 SELECT userID, userName FROM userTable WHERE
この結果、userNameの検索条件の文字列定数の終了を意味する「'」が別の文字と解釈されてしまい、全件が検索結果として返されてしまう。 これら文字コードを利用した脆弱性は、SQLインジェクションに限ったことではない。他の脆弱性でも文字コードに依存した問題が発生することがあるので注意が必要だ。 |
サイト脆弱性をチェックしよう!--第6回:SQLインジェクションの検査方法 - (page 5)
ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)
関連ホワイトペーパー
- 製造・金融・小売・サービスなど10社の事例から知る、セキュアなSD-WAN構築のポイントと効果
- 「2024年版脅威ハンティングレポート」より—アジアでサイバー攻撃の標的になりやすい業界とは?
- ハンズオンキーボードによる対話型侵入が前年比55%増--2024年版脅威ハンティングレポート
- アプリケーションセキュリティ調査の最新版、「ソフトウェアの時代」に専門家が持つ課題意識
- 攻撃者は侵入ではなく“ログイン”する、エンドポイントとアイデンティティセキュリティを連携すべき理由
- 講演動画:Salesforceの管理者なら知らなければならない、コンテンツに起因するリスクとその対策
- 人気カテゴリ
- 経営
- セキュリティ
- クラウドコンピューティング
- 仮想化
- ビジネスアプリケーション
- モバイル