Webサイトを運営する上で、避けて通れないのがセキュリティ脆弱性への対策です。これまで「暗号」や「防壁（WAF/FW）」について学んできましたが、アプリケーションそのものに欠陥（脆弱性）があると、それらをすり抜けて致命的な被害が発生します。
今回は、Webサイトの2大脅威と言われる「SQLインジェクション」と「クロスサイトスクリプティング（XSS）」について、その巧妙な手口と、エンジニアが実装すべき根本的な対策を深掘りします。
SQLインジェクション：データベースを背後から操る
SQLインジェクションは、Webアプリケーションがデータベース（DB）へアクセスする際の「入力チェック」の不備を突く攻撃です。
仕組みと手口
多くのWebサイトでは、ユーザーが入力した情報を元にSQL文（データベースへの命令）を組み立てます。攻撃者は、入力フォームに特殊な記号やSQLコマンドを紛れ込ませることで、開発者が意図しない命令をDBに実行させます。
- 被害例： IDとパスワードを無視してログインされる、顧客名簿（個人情報）がすべて盗まれる、DB内のデータがすべて消去されるなど。
根本的な対策：プレースホルダの利用
最も有効な対策は、SQL文の組み立てに「静的プレースホルダ（準備された文）」を使用することです。
- バインド機構： ユーザーの入力を「命令」としてではなく、単なる「値（文字列）」として機械的に処理させることで、SQL文の構造を書き換えられるのを防ぎます。
- WAFの活用： 「WAF」を導入し、不自然なSQL命令が含まれるリクエストをネットワークの入口で遮断するのも有効な補助策です。
クロスサイトスクリプティング（XSS）：ブラウザ上で悪意を動かす
XSSは、Webサイトの表示内容に「悪意のあるスクリプト（JavaScriptなど）」を埋め込み、それを閲覧したユーザーのブラウザ上で実行させる攻撃です。
3つの種類
- 反射型XSS： 悪意あるリンクをクリックさせることで、その瞬間にスクリプトを実行させる。
- 格納型（蓄積型）XSS： 掲示板などにスクリプトを投稿し、閲覧した不特定多数のユーザーに実行させる。最も被害が広がりやすいタイプです。
- DOM-based XSS： ブラウザ側のJavaScript処理の不備を突く。
被害の引き金は「Cookie」
XSSの最大の目的の一つは、第1回で学んだ「Cookie」の奪取です。ブラウザ上で動くスクリプトによってセッションIDが盗まれると、攻撃者はユーザーになりすましてログインできてしまいます。
根本的な対策：サニタイジング（無害化）
- エスケープ処理：
<や>といった記号を、<や>などの安全な文字に置換します。これにより、スクリプトがプログラムとして実行されるのを防ぎます。 - HttpOnly属性： Cookieの設定に
HttpOnly属性を付与することで、JavaScriptからCookieを読み取れないように制限します。
脆弱性を生む「入力値の盲信」を捨てる
これらすべての攻撃に共通する原因は、開発者が「ユーザーからの入力は安全である」と信じてしまうことにあります。
セキュリティ設計の基本原則は、「外部からの入力はすべて汚染されている（Untrusted）」とみなすことです。
- 入力時には、想定外の文字を弾く（バリデーション）。
- 出力時には、無害な形式に変換する（エスケープ）。
- データベース操作時には、命令とデータを分ける（プレースホルダ）。
この3層の構えを徹底することが、堅牢なアプリケーションを作る第一歩です。
試験（FE/AP）でのポイント：攻撃の「結果」で見分ける
情報処理技術者試験では、攻撃の仕組みと結果を正しく結びつける問題が頻出します。
- SQLインジェクション ＝ データベースの不正操作、情報漏洩。
- XSS ＝ ブラウザでのスクリプト実行、Cookie奪取、なりすまし。
- ディレクトリトラバーサル ＝ サーバー内の非公開ファイルへの不正アクセス。
それぞれの攻撃が、OSI参照モデルのどの部分（主にL7：アプリケーション層）を狙っているかを意識して学習しましょう。
まとめ
脆弱性攻撃は、暗号技術だけでは防げない「実装上の隙」を狙ってきます。
- SQLインジェクションは、プレースホルダでデータの「意味」を固定して防ぐ。
- XSSは、エスケープ処理とCookieの属性設定で「実行」を阻止する。
- サニタイジングは、Webエンジニアにとって必須の技術的マナーである。
本連載の「Web技術・セキュリティ編」はこれで一区切りとなります。これまでの20回を通じて、インターネットがいかに複雑で、かつ緻密な信頼の積み重ねで成り立っているかを感じていただけたでしょうか。
コメント