0

XSS攻撃からコードを保護したいと思っていますが、私が読んでいるすべての例は、直接のユーザー入力検証（連絡フォームやログインなど）を扱っています。

直接入力する方法がない場合（つまり、私のWebサイトがデータベースからの読み取りのみでデータベースへの書き込みが行われていない場合）にコードを保護する必要があるかどうかについて少し混乱していますか？データベースを外部ソースとして分類し、エコーされた変数内のデータがまだ他の場所から来ているため、私はまだ必要だと考えています。

読み取られたデータはユーザー入力を構成し、それに応じて処理する必要があると私は考えていますか？また、連絡フォームを追加した場合、すべてのページでデータベースから取得したすべての情報を検証/サニタイズ/エスケープする必要がありますか、それともフォーム自体でのみ処理する必要がありますか？

4

2 に答える 2

4

「ユーザー入力」という用語を忘れて、「不明な文字列」の観点から考えてください。何が含まれているのかわからないことは、適切な状況では潜在的に危険または破壊的です。

すべての場合に単一の解決策があるわけではないことを覚えておくことも重要です。たとえば、これらはすべて、さまざまなタイプの消毒またはエスケープを必要とする場合があります。

  • HTML属性：<a href="$unknown">
  • HTMLテキストコンテンツ：<p>$unknown</p>
  • javascript：<script>var B = $unknown;</script>
  • SQL：SELECT * from $unknown
  • CSS：.myClass { color:$unknown; }

一般に、HTML属性、CSS、またはJavascriptで不明なデータを使用することは（可能であれば）避ける必要があります。これらは複雑になる可能性がある場所だからです。ほとんどの場合、HTML文字をエスケープするだけで十分です。

ここでのキーワードはコンテキストです。これが、入力を「サニタイズ」するのではなく、出力を「サニタイズ」したい理由の1つです。同じデータがさまざまなコンテキストで使用される可能性があり、エスケープまたはフィルタリングのさまざまな手段が必要になります。

XSSとセキュリティ全般について学ぶためのリソースとしてOWASPを使用することを強くお勧めします：https：//www.owasp.org/index.php/Cross-site_Scripting_（XSS）

于 2012-10-07T20:53:58.910 に答える
1

読み取られたデータはユーザー入力を構成し、それに応じて処理する必要があると私は考えていますか？

一般的に-はい。ほとんどのデータベースには、ほとんどプレーンテキストと数字が含まれています。

ただし、例外があります。たとえば、HTMLを明示的に格納し、入力時に安全である（または少なくとも信頼できる）ことを確認している場合は、データを引き出すときにXSSから身を守ることを心配する必要はありません。この例としては、ユーザーが記事にHTMLを入力できるCMS（Wordpressなど）があります。

また、連絡フォームを追加した場合、すべてのページでデータベースから取得したすべての情報を検証/サニタイズ/エスケープする必要がありますか、それともフォーム自体でのみ処理する必要がありますか？

このフォームでは、システム外部からのデータを入力できます。そのデータをどこにでも置くときは、適切な手段を講じる必要があります。SQLの文字列に入れる場合は、SQL用にエスケープする必要があります。あなたがそれを電子メールの件名に入れるならば、あなたはそれのためにそれをエスケープする必要があります。それをHTMLドキュメントに入れる場合は、そのためにエスケープする必要があります。（等々）。

于 2012-10-07T20:27:24.950 に答える