私が見たすべてのサンプルでは、ストアドプロシージャを使用しています。私は、インラインSQLを使用するClassic ASPで書かれた古いアプリケーションを採用しました。これは明らかな問題ですので、より安全なコードに変換する必要があります。クライアントはこのアプリケーションでストアドプロシージャを使用したくないので、ストアドプロシージャなしでパラメータ化されたクエリを実行する方法はありますか?ストアドプロシージャのないパラメータ化クエリ?
ありがとうございました
私が見たすべてのサンプルでは、ストアドプロシージャを使用しています。私は、インラインSQLを使用するClassic ASPで書かれた古いアプリケーションを採用しました。これは明らかな問題ですので、より安全なコードに変換する必要があります。クライアントはこのアプリケーションでストアドプロシージャを使用したくないので、ストアドプロシージャなしでパラメータ化されたクエリを実行する方法はありますか?ストアドプロシージャのないパラメータ化クエリ?
ありがとうございました
は、クライアントがストアドプロシージャを使用したくない理由何らかの理由はありますか?データベースレベルとソースコードの両方でストアドプロシージャを使用する方がはるかに簡単です。上記の2番目の方法を使用する場合は、インラインクエリでクエリプランのキャッシュを取得する必要がありますが、使用しているクライアントに納得させることができれば、他のすべてが失敗した場合、上記のリンクはかなり安定しています(特に2番目のリンク)。
- 1: "簡単"は主観的であり、ストアドプロシージャの使用はSQLインジェクションに対する保証ではありません。 – RedFilter
これは主観的なことではありません。これは、ロジック層とデータ層を分離する多層開発の標準概念です。私はストアドプロシージャがSQLインジェクションに対する保護を保証しているとは決して言いませんでした。パラメータ化されたクエリとストアドプロシージャは、SQLインジェクションを可能にする遅延コードから発生する多くの状況を防ぎますが、sprocsの動的クエリが他のものの中で脆弱にならないようにします。ダウン投票は、これが有効かつ洞察力のある対応であると考えると、かなり不適切だと思われる。 – tcnolan
最初のリンクが動作していないと表示されます – Chris
それは私のために正常に働いた –
ちょうどテストしました。 wwwがなくてもうまくロードされないようですが、それには問題ありません。ありがとう! – Chris