XSS攻撃からPHPアプリケーションを保護するためのベストプラクティスと推奨事項
機能するWebアプリケーションの作成は、戦いの半分に過ぎません。 最新のオンラインサービスとWebアプリケーションは、独自のコンテンツに加えて、ユーザーデータを保存します。 このデータの保護は、信頼性とセキュリティの観点から正しく記述されたコードに依存しています。
ほとんどの脆弱性は、外部から受信したデータの不適切な処理、または不十分な厳密な検証に関連しています。 そのような脆弱性の1つは、クロスサイトスクリプティング（クロスサイトスキャッターリング、XSS）です。これにより、Webサイトが改ざんされ、ユーザーが感染したリソースにリダイレクトされ、悪意のあるコードがWebリソースに挿入され、Cookie、セッション、およびその他の情報が盗まれます。 安全なプログラミングのためのベストプラクティスと推奨事項の使用（これについては以下で説明します）は、XSS独自の強みで抵抗するのに役立ちます。
ベストプラクティスと推奨事項：
1.入力/出力シールドを使用します。 組み込み関数を使用して、悪意のあるスクリプトからコードを削除します。 これらには、htmlspecialchar（）、htmlentities（）、strip_tags（）などの関数が含まれます。
使用例：
$name = strip_tags($_POST['name']); $name = htmlentities($_POST['name'], ENT_QUOTES, "UTF-8"); $name = htmlspecialchars($_POST['name'], ENT_QUOTES);
PHPの組み込み関数は、自己完結型の関数とは異なり、はるかに高速に動作し、セキュリティエラーや脆弱性が少ないため、 常に改善しています。 また、組み込み関数とフィルターに基づいた特別なライブラリーを使用することをお勧めします。 例には、OWASP Enterprise Security API（ESAPI）、HTML Purifier、Reform、ModSecurityが含まれます。
ライブラリが正しく機能するためには、最初に設定する必要があります！
2.ホワイトリスト方式を使用します。 このアプローチは、「許可されていないものは禁止されている」という原則に基づいて機能します。 これは、保存、表示されるデータを受け入れる前に、ヘッダー、Cookie、クエリ文字列、非表示フィールド、およびフォームフィールドの長さ、タイプ、構文、有効な文字、その他のルールを含むすべての入力データをチェックするための標準フィールド検証メカニズムですサイト。 たとえば、フィールドに姓を指定する必要がある場合は、文字、ハイフン、スペースのみを許可する必要があります。 他のすべてを拒否すると、d'Arcという名前は拒否されます。悪意のあるデータを受け入れるよりも、信頼できる情報を拒否する方が適切です。
残念ながら、PHPデータを検証するための組み込みフィルターはタスクに対応していないため、独自のフィルターを作成し、必要に応じて「仕上げ」ることをお勧めします。 したがって、時間の経過とともに、入力フィルタリング方法が改善されます。 また、アクティブなコンテンツとエンコード方法の種類が多すぎて、このようなフィルターをバイパスできないことも覚えておく必要があります。 同じ理由で、ブラックリストを使用しないでください。
3.各Webページでエンコードを指定します。 Webページごとに、カスタムフィールドの前にエンコード（ISO-8859-1やUTF-8など）を指定する必要があります。
使用例：
<?php header("Content-Type: text/html; charset=utf-8"); ?> <!DOCTYPE html> <html> <head> <title>harset</title> <meta charset="utf-8"> </head>
または、Apache Webサーバーの.htaccessファイルに次の行を追加します。
AddDefaultCharset UTF-8
http-headerまたはmetaタグでエンコーディングが指定されていない場合、ブラウザはページエンコーディング自体を決定しようとします。 HTML 5は、JIS_C6226-1983、JIS_X0212-1990、HZ-GB-2312、JOHAB（Windowsコードページ1361）を含むエンコーディング、およびISO-2022およびEBCDICに基づくエンコーディングの使用を推奨していません。 さらに、Web開発者はCESU-8、UTF-7、BOCU-1、またはSCSUエンコーディングを使用しないでください。 これらのエンコーディングは、Webコンテンツ向けではありませんでした[1]。 タグがタグの前にあり、ユーザーデータで満たされている場合、攻撃者はUTF-7でエンコードされた悪意のあるhtmlコードを挿入し、「<」や「 "」などの文字のフィルタリングをバイパスできます。
4. HttpOnlyフラグを設定します。 このフラグにより、JavaScriptなどのスクリプト言語を介してクライアントCookieを使用できなくなります。
この設定は有効です。
-php.ini [2]：
session.cookie_httponly = True
-関数session_set_cookie_params（）を使用したスクリプト内[3]：
void session_set_cookie_params ( int $lifetime [, string $path [, string $domain [, bool $secure = false [, bool $httponly = true ]]]] )
-setcookie（）関数[4]を使用したWebアプリケーション：
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = true ]]]]]] )
この機能は、一般的なブラウザの最新バージョンでサポートされています。 ただし、XMLHttpRequestやその他の強力なブラウザーテクノロジーを介した一部のブラウザーの古いバージョンは、HttpOnlyフラグが設定されているSet-Cookieヘッダーを含むHTTPヘッダーへの読み取りアクセスを提供します[5]。
5.コンテンツセキュリティポリシー（CSP）を使用します。 これは、JS、CSS、画像など、さまざまなデータをロードできるソースの「ホワイトリスト」を明示的に宣言できる見出しです。攻撃者がWebページにスクリプトを埋め込むことができたとしても、そうしないと失敗します許可されたソースのリストと一致します。
CSPを使用するには、WebアプリケーションがContent-Security-Policy HTTPヘッダーを介してブラウザーにポリシーを送信する必要があります。
使用例：
Content-Security-Policy: default-src 'self'; script-src trustedscripts.example.com style-src 'self' ajax.googleapis.com; connect-src 'self' https://api.myapp.com realtime.myapp.com:8080; media-src 'self' youtube.com; object-src media1.example.com media2.example.com *.cdn.example.com; frame-src 'self' youtube.com embed.ly
「Content-Security-Policy」は公式のW3C承認済みhttpヘッダーで、Chrome 26以降、Firefox 24以降、およびSafari 7以降のブラウザでサポートされています。 X-Content-Security-Policy HTTPヘッダーは、Firefox 4-23およびIE 10-11、Chrome 14-25、Safari 5.1-7 [6]のX-Webkit-CSPヘッダーに使用されます。
Web開発者の立場からすると、サイトの各ページに個別のポリシーを設定する必要があるため、リソースにCSPを正しく正しく展開することは非常に問題です。
6.コードセキュリティ分析と侵入テストを定期的に実施します。 手動と自動の両方のアプローチを使用します。 Nessus、Nikto、OWASP Zed Attack Proxyなどのツールは、WebアプリケーションのXSS脆弱性を識別するのに役立ちます。
7.ユーザーは、ブラウザを新しいバージョンに定期的に更新し、NoScriptなどの拡張機能を使用することをお勧めします。
ご覧のとおり、各推奨事項にはそれぞれ長所と短所があります。したがって、包括的な保護を適用することで、クロスサイトスクリプトの実行に対抗する効果が得られます。 記載されている推奨事項をまとめて使用します。
便利なリンク：
1. HTML Standart。 HTMLの要素。
2. PHP：実行時のチューニング。
3. PHP：session_set_cookie_params。
4. PHP：setcookie。
5. OWASP HttpOnly。
6. コンテンツセキュリティポリシーを使用できますか。
7. PHPセキュリティガイド。
8. 2011 CWE / SANS最も危険なソフトウェアエラーのトップ25。 CWE-79：Webページ生成中の入力の不適切な無効化（「クロスサイトスクリプティング」）。
9. コンテンツセキュリティポリシーの紹介。
10. OWASP XSS。
11. OWASP Top 10 2013-A3-Cross-Site Scripting（XSS）。
12. OWASP XSSフィルター回避チートシート。
記事の著者：PentestITフリーランスワーカー、 Sergey Storchak