0

ここで何かをチェックする必要があります。入力が1行のコードで取得されるため、いくつかのコードでフィルターで除外されることを知っています。ここでは、コードを取得した後に順番に実行しましたが、これも受け入れられますか？または、データを取得すると同時に、1行でデータをフィルタリングしてエスケープする方法を理解する必要がありますか？これがImが話していることのサンプルです...

  // Get data and prevent XSS attack
  $user = htmlentities($_POST['email'], ENT_QUOTES, 'UTF-8');
  $pass = htmlentities($_POST['pass'], ENT_QUOTES, 'UTF-8');

  // MySQL Injection prevention
  $userdata = mysql_real_escape_string($user);
  $passdata = mysql_real_escape_string($pass);

考え？

ここで達成しようとしている主な目的は、MySQLインジェクションの試みを回避し、XSS攻撃を防ぐことです。

4

3 に答える 3

2

Key objective I'm trying to achieve here is to escape a MySQL injection attempt AND prevent an XSS attack

You can't do both of those at the same time.

SQL-escaping needs to happen at the point you create SQL queries including text strings. Although you are better off using parameterised queries (eg mysqli or PDO), in order not to have to worry about it.

HTML-escaping needs to happen at the point you create HTML markup including text strings. Although in an ideal world you'd be using a templating language that HTML-escaped by default, so you didn't have to worry about it.

If you apply both HTML-escaping and SQL-escaping at the input stage instead of their respective output stages, you'll get HTML-encoded data in your database that you won't be able to apply consistent text handling to (search, substrings, etc), and you'll get SQL-encoded data spat out onto the page where the value hasn't gone through a database I/O cycle (the cause of the O\\\\\\\\'Reilly problem. Plus you will still be at risk from any data that hasn't gone through the input path - for example fetch a string from the database, process it and return it to the database, and it'll not have had an escaping step and you're vulnerable to SQL injection again.

Neither escaping scheme is suitable to blanket-apply to input. Input filtering should only be about blocking characters you never want to handle and enforcing business rules. Do output escaping only at the moment you move text content into a new context - and wherever possible use frameworks that prevent you from having to manually escape at this point.

于 2012-07-10T08:13:49.373 に答える
1

を使用するだけでは不十分mysql_real_escape_stringです。無効なマルチバイトエンコーディングを悪用してSQL攻撃を仕掛けることができる特定の状況があります（とは異なりaddslashes、このタイプの攻撃mysql_real_escape_stringは、接続文字列で文字エンコーディングがオーバーライドされた場合にのみ発生する可能性があります）。

MySQLと対話するときは、プリペアドステートメントも使用する必要があります。

XSSに関しては、HTMLPurifierの統合を検討してください。

HTML Purifierは、PHPで記述された標準準拠のHTMLフィルターライブラリです。HTML Purifierは、徹底的に監査され、安全でありながら寛容なホワイトリストを使用してすべての悪意のあるコード（XSSとして知られる）を削除するだけでなく、ドキュメントが標準に準拠していることを確認します。これは、W3Cの仕様に関する包括的な知識がなければ達成できません。

于 2012-07-10T04:42:40.260 に答える
0

関数を使用してすべての文字列を渡すことをお勧めします。

function safe($value){ 
return mysql_real_escape_string($value);
}

入力を収集したい場合は、次のようにします。

$name=safe($_POST['name']);
于 2013-11-10T07:54:03.740 に答える