タグ付けされた質問 「sql-injection」

誰かに雇われて、サイトでちょっとした仕事をしています。大企業向けのサイトです。非常に機密性の高いデータが含まれているため、セキュリティは非常に重要です。コードを分析すると、セキュリティホールで満たされていることに気付きました-読み取り、ユーザーのget / post入力をmysqlリクエストとシステムコマンドに直接投げる多くのPHPファイル。 問題は、彼のためにサイトを作った人は、その仕事に依存している家族や子供を持つプログラマーだということです。「あなたのサイトはキディ遊園地のスクリプトです。あなたのためにやり直してください。元気になります。」 この状況で何をしますか？ 更新： 私はここでいくつかの良いアドバイスに従い、サイトでいくつかのセキュリティ上の欠陥を発見したことを開発者に丁寧に報告しました。私はそのラインを指摘し、そこにSQLインジェクション攻撃の潜在的な脆弱性がある可能性があると述べ、彼がそれについて知っているかどうか尋ねました。彼は答えた：「確かに、しかしそれを悪用するには、攻撃者はデータベースの構造に関する情報を持っているべきだと思う。もっとよく理解しなければならない」。 アップデート2： 私はそれが常にそうではないと言って、彼がそれを適切に扱うためにこのStack Overflow質問リンクに従うことを提案しました：PHPでSQLインジェクションを防ぐ方法は？彼はそれを勉強するだろうと言い、以前彼に言ったことに感謝した。おかげさまで、私の役目は終わったと思います。

109 php  security  sql-injection 

私の考えでは、SQLインジェクション攻撃は次の方法で防止できます。 入力を慎重にスクリーニング、フィルタリング、エンコードする（SQLへの挿入前） 使用して準備された文 /パラメータ化クエリを それぞれに長所と短所があると思いますが、なぜ＃2が離陸し、インジェクション攻撃を防ぐための事実上の方法であると見なされるようになったのですか？単に安全でエラーが発生しにくいのですか、それとも他の要因がありましたか？ 私が理解しているように、＃1が適切に使用され、すべての警告が処理されれば、＃2と同じくらい効果的です。 サニタイズ、フィルタリング、エンコード 私の側では、サニタイズ、フィルタリング、およびエンコードの意味が混乱していました。この場合、サニタイズとフィルタリングは入力データを変更または破棄する可能性があることを理解していますが、エンコードはデータをそのまま保持しますが、エンコードしますインジェクション攻撃を避けるために適切に。データをエスケープすることは、それをエンコードする方法と考えることができると信じています。 パラメータ化されたクエリとエンコーディングライブラリ parameterized queriesとの概念がencoding libraries相互に交換可能に扱われている答えがあります。私が間違っている場合は修正しますが、私はそれらが異なっているという印象を受けています。 私が理解しているのは、encoding librariesどんなに優れていても、SQL「プログラム」を変更する可能性は常にあるということです。 Parameterized queries 一方、SQLプログラムをRDBMSに送信すると、RDBMSはクエリを最適化し、クエリ実行プランを定義し、使用するインデックスを選択するなどして、RDBMS内の最後のステップとしてデータをプラグインします。自体。 エンコーディングライブラリ data -> (encoding library) | v SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement パラメータ化されたクエリ data | v SQL -> RDBMS (query execution plan defined) -> …

59 security  sql  history  hacking  sql-injection 

SQLインジェクション攻撃で私が見たすべては、パラメータ化されたクエリ、特にストアドプロシージャのクエリが、このような攻撃から保護する唯一の方法であることを示唆しているようです。私が（暗黒時代に）働いていたとき、主に保守性が低いと見られていたため、ストアドプロシージャは貧弱なプラクティスと見なされていました。テスト可能性が低い。高度な結合; システムを1つのベンダーにロックしました。（この質問は他のいくつかの理由をカバーしています）。 私が働いていたとき、プロジェクトはそのような攻撃の可能性にほとんど気づいていませんでした。さまざまな種類の破損からデータベースを保護するために、さまざまなルールが採用されました。これらのルールは次のように要約できます。 クライアント/アプリケーションは、データベーステーブルに直接アクセスできませんでした。 すべてのテーブルへのすべてのアクセスはビューを介して行われました（ベーステーブルへのすべての更新はトリガーを介して行われました）。 すべてのデータ項目にドメインが指定されていました。 データ項目をNULL可能にすることは許可されませんでした-これは、DBAが時々歯を磨くという意味がありました。しかし、強制されました。 ロールと権限が適切に設定されました-たとえば、ビューのみにデータを変更する権限を与える制限されたロール。 SQLインジェクション攻撃を防ぐために、このような（強制的な）ルールのセット（必ずしもこの特定のセットである必要はありませんが）は、パラメーター化されたクエリの適切な代替手段ですか？そうでない場合は、なぜですか？データベースは、データベース（のみ）固有の手段によって、このような攻撃から保護できますか？ 編集 質問の強調は、受け取った最初の回答に照らして、わずかに変わりました。基本質問は変更されていません。 EDIT2 パラメータ化されたクエリに依存するアプローチは、システムに対する攻撃に対する防御の周辺ステップにすぎないようです。より根本的な防御が望ましいと思われ、特にインジェクション攻撃から防御する場合でも、そのようなクエリへの依存は不要であるか、それほど重要ではないようです。 私の質問に暗示されているアプローチは、データベースの「装甲」に基づいており、それが実行可能なオプションであるかどうかはわかりませんでした。さらなる研究は、そのようなアプローチがあることを示唆しています。このタイプのアプローチへのポインタを提供する以下のソースを見つけました。 http://database-programmer.blogspot.com http://thehelsinkideclaration.blogspot.com これらのソースから取得した主な機能は次のとおりです。 広範なセキュリティデータディクショナリと組み合わせた広範なデータディクショナリ データディクショナリからのトリガー、クエリ、および制約の生成 コードを最小化し、データを最大化する これまでの回答は非常に有用であり、パラメータ化されたクエリを無視することから生じる困難を指摘していますが、最終的には元の質問に回答しません（太字で強調されています）。

13 design  security  sql  sql-injection