サニタイズデータの処理方法については、ここで多くの話があります。 この再書き込みルールを.htaccessに追加するだけで簡単にできますか？ApacheでGETクエリをサニタイズする
RewriteRule ^([\w\-]+)$ index.php?page=$1
私の理解によれば、これは$ 1の文字、数字、_と - のみを許可しますか？
SQLクエリのプリペアドステートメントのこの使用法を追加すると、それはかなり証明するはずです。 はそうでしょうか？
どういうわけか、あまりにも簡単に真実であると感じる、私は何かを欠いている、それを固める方法はありますか？
SQLクエリのプリペアドステートメントのこの使用法を追加すると、それは正しいでしょうか？
ほとんどの使用例ではルールが厳しくないため、実際はそうではありません。文字列入力のUmlautsの例を考えてみましょう。いくつかの入力に対して非ASCII文字を許可する必要があります。そのようなデータはURLにはpercent encodedなので、特定の文字をフィルタリングする必要があります。その場合でも、セキュリティ上は無用です。データベースの注入だけではなく、より多くの攻撃ベクトルがあります。
これらすべての危険に対して、「1つのサイズはすべてに適合」という衛生方法はありません。すべてのシナリオ（ファイル名での使用、HTML出力、Javascript出力、E-Mails .....）には、正しい方法が1つあります。 Webサーバーレベルで「無効な」文字をフィルタリングすることは実際的ではありません。完全なセキュリティのためには、不可能に近いApache構文で特定の衛生関数をすべて再作成する必要があります。
も参照してください：PHP: the ultimate clean/secure function
あなたがウェブサーバーレベルで物事を希望している場合mod_securityのようなものを使用して調査することをお勧めします。それはいくつかの攻撃を緩和するのに役立ちますが、最終的な防御レベルはPHP自体の中で行わなければなりません。 Webサーバーによって「ちょうど良い」とみなされる攻撃は常に存在しますが、アプリケーションに混乱を引き起こします。注入脆弱性を防ぐためにクエリパラメータをどれだけロックしても、あなたが逃したことがあります。
PHP内でシンプルにmysql_real_escape_string()を実行してすべてをキャッチすることができる場合、時間の無駄な時間/日が完璧なRewriteRuleになるのはなぜですか？
SQLクエリの使用法について言えば、さらに安全のためのステップとして何を提案しますか？url_decodeは何か良いことができますか？ XSSのHTML出力についても、ストリッピングはしません。
CodeVirtuoso
@Freelancer PDOまたはmysqliの準備文は、注射に対して十分な保護とみなされます。他に何もする必要はありません。 Re XSS、リンクを掘り起こしましょう –
@Freelancer Re XSS、HTMLで出力する前に、すべてのユーザーデータで 'htmlspecialchars（）'を実行してください。かなり異例の攻撃から保護するために 'strip_tags（）'が必要であると主張する一つの答えがあります：http://stackoverflow.com/questions/3623236/htmlspecialchars-vs-htmlentities-when-concerned-with-xss私はそれをどう考えるべきか分かりません - 私は個人的に 'htmlspecialchars（）'がすると思います。 –