0

SQLインジェクション攻撃からの保護について読んで宿題をしました。パラメーターバインディングを使用する必要があることはわかっていますが、次のようになります。

  • 私はすでにこれをします、ありがとう。
  • 私のユーザーが使用するdbドライバーのいくつかは、可能な限り最も愚かな方法でパラメーターバインディングを実装していることを知っています。つまり、SQLインジェクション攻撃を受けやすいです。使用できるdbドライバーを制限することもできますが、この戦略は失敗する運命にあります。
  • まともなdbドライバーを使用している場合でも、パラメーターバインディングを少なくとも1回使用することを忘れないように自分自身を信頼していません

そこで、httpに面したユーザー入力のサニタイズを追加することで、保護のレイヤーを追加したいと思います。秘訣は、これを一般的に行うのは難しいことを知っているので、セキュリティの専門家によって作成された、十分に監査された適切に設計されたサードパーティのライブラリを使用して、入力文字列を危険性の低いコンテンツにエスケープしたいのですが、明らかな候補。私はPythonを使用しているので、Pythonベースのソリューションに興味がありますが、Pythonにバインドできれば、他の提案でも問題ありません。

4

4 に答える 4

2
  • 私はすでにこれをします、ありがとう。

良い; これだけで、ユーザー入力が値としてのみ解釈されていることを完全に確信できます（はい、完全に確信できます）。他の種類の脆弱性からサイトを保護することに力を注ぐ必要があります（XSSとCSRFが頭に浮かびます。SSLを適切に使用していることなどを確認してください）。

  • 私のユーザーが使用するdbドライバーのいくつかは、可能な限り最も愚かな方法でパラメーターバインディングを実装していることを知っています。つまり、SQLインジェクション攻撃を受けやすいです。使用できるdbドライバーを制限することもできますが、この戦略は失敗する運命にあります。

まあ、愚か者はとても独創的であるため、愚か者の証拠のようなものはありません。あなたの聴衆が彼らのデータを保護するためのあなたのすべての努力を弱体化させると決心しているなら、あなたはそれについて本当に何もすることができません。あなたができることは、あなたが安全だと信じているドライバーを決定し、あなたのユーザーが何か他のものを使用していることを検出したときに大きな恐ろしい警告を生成することです。

  • まともなdbドライバーを使用している場合でも、パラメーターバインディングを少なくとも1回使用することを忘れないように自分自身を信頼していません

  1. だからそれをしないでください！

  2. 開発中に、ドライバーに送信されたすべてのSQLステートメントをログに記録します。定期的に、ユーザーデータがこのログに記録されていないことを確認してください（または、パラメーターについては別のイベントとして記録されます）。

  3. SQLインジェクションは基本的に文字列フォーマットです。通常、各データベーストランザクションを元のSQLまでさかのぼって追跡できます。ユーザーデータが途中でそのようにフォーマットされている場合は、問題があります。プロジェクトをスキャンすると、grepと選択したエディターを効果的に使用して、1分あたり約1回の速度でプロジェクトを見つけることができます。何万もの異なるSQLステートメントがない限り、それぞれを調べることは実際には非常に難しいことではありません。
  4. データベースの相互作用をアプリケーションの他の部分から十分に分離しておくようにしてください。sqlを残りのコードと混合すると、管理が困難になるか、上記で説明したチェックを実行するのが困難になります。理想的には、ある種のデータベース抽象化（完全なORMまたはおそらくより薄いもの）を実行して、データベース関連のコードだけで作業できるようにする必要があります。
于 2012-04-26T15:20:19.033 に答える
1

これが何らかの形で当てはまるかどうかはわかりませんが、完全を期すためにそこに載せているだけで、専門家は私を自由に反対票を投じることができます...言うまでもなく、場合によってはそのパフォーマンスに懸念があります。

私はかつて、クラシックaspで記述された古いWebアプリをSQLインジェクションから保護するという任務を負っていました（当時はかなりひどい打撃を受けていました）

私はすべてのコードを調べる時間がないので（選択できない場合があります）、標準のインクルードファイルの1つにメソッドを追加して、ユーザーによって送信されたすべてのものを調べ（リクエストパラメーターで繰り返し）、ブラックリストに登録されたhtmlタグをチェックしました（例：スクリプトタグ）およびSQLインジェクションサイン（例：";-"および"'; shutdown"）。

見つかった場合はリダイレクトされ、送信は疑わしいとユーザーに伝え、問題のある電話やメールがある場合は..何とか何とか。

また、インジェクションの試行をテーブルに記録し（エスケープされた後）、攻撃のIPアドレス時間などの詳細を記録しました。

全体的にそれは御馳走になりました..少なくとも攻撃は止まりました。

私が使用したすべてのWebテクノロジーには、このようなものをいじくり回す方法があり、開発とテストに約1日しかかかりませんでした。

それがお役に立てば幸いです、私はそれを業界標準などとは呼びません

tl;dr?:すべてのリクエストパラメータを文字列のブラックリストと照合します

于 2012-04-26T08:24:45.840 に答える
0

そこで、httpに面したユーザー入力のサニタイズを追加することで、保護のレイヤーを追加したいと思います。

この戦略は失敗する運命にあります。

于 2012-04-26T14:56:03.440 に答える
-1

PHPでは、preg_replaceを使用して、SQLインジェクションによる攻撃からWebサイトを保護しています。preg_matchも使用できます。Pythonでこれと同等の関数を検索してみてください。

于 2012-04-26T08:14:20.903 に答える