SQLインジェクション攻撃についてはいくつかのヒステリーがあるようです。最近では、ここに
別のフィールドのルックアップ値に基づいて、あるフィールドの値を返す方法
Accessデータベースに接続するマクロをExcelで作成している場合、SQLインジェクションについて本当に心配する必要がありますか？Web上ではなく、私のオフィスで使用されています（デスクトップを覚えていますか？）。同僚が私を妨害することを心配していません。彼らがSQLインジェクションを行うのに十分賢いのなら、彼らは私のアドインパスワードを解読してコードを変更するのに十分賢いのではないでしょうか？
マクロでSQLを構築している場合、SQLインジェクションに対して脆弱です。モノを使用する人を信頼している場合でも、データベースフィールドに一重引用符とセミコロン文字を入れようとする人のように、少なくとも基本に注意する必要があります。これは、データの検証だけでなく、セキュリティの問題ではありません。
SQL インジェクションは単なるセキュリティ上の脅威ではなく、バグの非常に現実的な原因でもあります。
どのレコードにもアポストロフィ (') が含まれていないことを確信していますか?
INSERT INTO NAMES (FIRSTNAME, LASTNAME) VALUES('Jack', 'O'Neill')
この場合、誰もあなたのシステムをクラックしようとはしませんでしたが、あなたにはバグがあります。
正直なところ、これがあなたが話している既存のアプリであるなら、私はそれを書き直しに行きません。ただし、私たちが話しているように開発している場合、代替の代わりにパラメーター化されたクエリを使用するのがそれほど難しいとは思えません。
開発者は、アプリケーションが保持するデータのセキュリティについて、全体的ではないにしても、少なくとも部分的に責任を負います。
これは、アプリケーションがオンラインであるか、オフィスでのみ使用されているかに関係なく当てはまります。データストアの気密性を確保するために、できる限りのことをしてください。
結局のところ、あなたは昨年の売上高がどこに行ったのかを上司に説明しなければならない人になりたくありません。
物理的セキュリティは、常にデータセキュリティの最前線です。アプリケーションがオフィス内でのみ配布され、アクセスされたデータの価値が不十分で、誰かが盗んだりクラッキングしたりする手間や費用がかかる場合は、外部で使用するよりも低いセキュリティ基準を順守できます。 Webアプリケーションに直面しています。
しかし、本当のセキュリティとは、最終的には何が起こるかということであり、私たちが期待することではありません。アプリケーションが一般から委託されたデータ（SSN、クレジットカード番号など）を処理する場合、またはそれが会社にとって重要なデータの唯一のリポジトリである場合は、悪意のある可能性のあるユーザーがコードを使用して何を行う可能性があるかを考慮する必要があります。未来。今日の幸せな従業員は、明日の不満を持った社会人です。
経験則として、この製品を十分に理解している私が、この製品を使用して会社を傷つけたいと思った場合、どの程度の損害を与えることができますか？次に、その数を許容レベルまで下げるのに十分なセキュリティを組み込みます。
いいえ（はい）はい :)
多くの場合、開発者は「正面玄関」の強化に貴重なリソースを浪費しているのを目にしますが、背面の網戸が揺れていることに気付かないだけです。これは通常、フロントエンドを安全でないバックエンドに強化したり、基本的にさまざまなユーザーに公開されているアプリを強化したりするようなものです...
セキュリティについて包括的な声明を出すことはすべて素晴らしいことですが、要件に一致する必要があります。
IMOシステムが、害を及ぼす可能性のある人々（インターネットなど）にさらされる場合は、SQLインジェクションから保護する必要があります。
一方、SQLインジェクションにアクセスできる悪意のあるユーザーが他の方法でそれを害する可能性がある内部システムの場合、それは実際にはそれほど重要ではありません。
私はSQLインジェクションに対して脆弱なコードを自分で作成しましたが、そのようなアクセス権を持つのはとにかくSQLアクセス権を持つ同僚だけです。
私たちは皆、あらゆる攻撃に対して無防備なアプリケーションを望んでいますが、すべての防弾の開発にかかる時間と、追加の利点を比較検討する必要があります。セキュリティ要件がそれほど高くないと合理的に予想できる場合、これはあなたが伝えたいものかもしれません。心配する可能性があると思われる場合は、今すぐその可能性を防ぐための措置を講じて、もう心配する必要がないようにする必要があります。
Access データベースに接続するマクロを Excel で作成している場合、SQL インジェクションについて本当に心配する必要がありますか?
多分。それは本当に依存します。個人的には気にしませんが、保存しようとしているデータの種類とその機密性は何ですか?
彼らが SQL インジェクションを実行できるほど賢いのなら、アドインのパスワードをクラックしてコードを変更するほど賢いのではないでしょうか?
多分。だれかが SQL インジェクションを実行できるからといって、その人があなたのアドイン パスワードをクラックできるほど賢いとは限りません。一方、そうなる可能性もあります。
ディック、パラメータの処理方法によって異なります。やってはいけないことを示す VBA の例を次に示します。
Friend Function DeleteAnAccount() As Boolean
Const SQL_DELETE_AN_ACCOUNT As String * 50 = _
"DELETE FROM Accounts WHERE account_owner_ID = '?';"
Dim sql As String
sql = Replace$(SQL_DELETE_AN_ACCOUNT, "?", txtAccountOwnerID.Text)
m_Connection.Execute sql
End Function
アカウント ID (txtAccountOwnerID) をテキスト ボックスに入力する代わりに、実際に次のように入力したとします。
dummy' OR 'a' = 'a
結果の SQL 文字列は次のようになります。
DELETE FROM Accounts WHERE account_owner_ID = 'dummy' OR 'a' = 'a';
'a' = 'a'述語が解決されTRUE、すべてのアカウントが削除されるため、良くありません。
ADODB.Command オブジェクトなどの Parameter オブジェクトを使用して準備済みステートメントを使用することをお勧めします。
ジェイミー。
--
>パラメータ化されたクエリを使用し、異なるパラメータで再実行すると、毎回新しいクエリを作成するよりも高速になります。
実際、クエリのパフォーマンスについて言えば、Jet のパフォーマンスは向上しません。実際、JET のホワイト ペーパー「Performance Overview and Optimization Techniques」から、次のような宝石が得られます。
18ページ
ストアド クエリにはコンパイル済みのクエリ プランがあるため、インデックス付き列のパラメーターを含むパラメーター化されたクエリは効率的に実行されない場合があります。クエリ エンジンは事前にパラメーターに渡される値を認識していないため、最も効率的なクエリ プランを推測することしかできません。調査した顧客のパフォーマンス シナリオに基づいて、格納されたパラメーター化されたクエリを一時的なクエリに置き換えることで、大幅なパフォーマンスの向上を実現できる場合があることがわかりました。これは、コードで SQL 文字列を作成し、それを Database オブジェクトの DAO OpenRecordset または Execute メソッドに渡すことを意味します。
ニートえ？そして、私は上記を経験しました！
とにかく、クエリ プランのコンパイル時間は 1000 秒単位であることに注意してください。つまり、実際には、クエリ プランの時間は 0.01 から 0.0001 になります。確かに 100 倍高速ですが、全体で 100 分の 1 秒しか節約できません。クエリ プランの時間が問題にならないように、2 秒かかるレポートを実行します。
今日はGOBSの処理があります。ボトルネックとなるのは、ディスク ドライブ、メモリ、およびネットワーク I/O 速度です。また、JET に送信された新しい SQL 文字列ごとにサーバーの SQL クエリ キャッシュを浪費するという問題もありません。これらのインライン SQL クエリ プランはキャッシュされません。さらに重要なことに、JET はクライアント ベースのエンジンであるため、オフィスの LAN に 10 人のユーザーがいる場合、各マシンでローカルに実行されている JET のコピーが 10 個あります。クエリ プラン キャッシュは、SQL サーバーの場合のように問題ではありません。
上記の Jet ホワイト ペーパー (および私の経験) が示すように、パラメーターなしでその SQL の再コンパイルを強制することによる、より優れたクエリ プランの利点は、パラメーターを使用して事前にコンパイルされたクエリ プランを持つことの利点を上回ります。
ただし、軌道に乗るには、David に同意する必要があります。odbc を使用している場合、またはこの場合は dao オブジェクト モデル + ジェットを使用している場合、実際の SQL ステートメントを挿入する方法を思いつくことができないとは思いません。
おそらく、上記の「不十分な」InputBox() の例では、予期しない結果をもたらす可能性のある条件を入力できます。指摘したように、アクセスに組み込まれたアプリケーションは、このように機能することはめったにありません。
フォームを表示しているレコードを削除するなどの場合、フォームにはカスタム メニュー バー (またはリボン) が表示されるか、単に削除ボタンがフォームに配置されます。したがって、ユーザーは、このタイプの削除コードに不適切なデータを入力することはできません。
フォームでユーザーからの入力を頻繁に受け入れる場合は、フォームにデータ マスクが組み込まれていることに注意してください。結局のところ、これはまさに MS アクセスが設計されたものです。したがって、電話番号を要求している場合、ユーザーはその入力マスクに文字を入力したり、数値以外のチャーターを入力したりすることはできません。そのマスクは () と – をその電話番号の適切な場所に表示用に挿入しますが、ユーザーの実際の入力には数字のみが入ります。
他のほとんどの種類のプロンプトでは、コンボ ボックス、リスボックス、およびその他の UI 要素を使用します。これにより、フォームで許可されている以外の何かをテキスト ボックスに挿入するユーザーの能力が制限されます。
ほとんどのスクリーン ビルダーをはるかに超える豊富なマスキング機能と入力機能があるため、注入は MS アクセス ベースのアプリケーションではめったに行われません。
ユーザーがインジェクションによってSQLステートメントを実行できるJETの例を誰かが示すことができれば、dao + jetでは不可能だと思うので、私はすべて耳にします。
MS アクセス アプリケーションの場合は可能かもしれませんが、実際には非常に困難です。
Jetデータベースをバックエンドとして使用するSQLインジェクションのExcel VBAコードの証明を投稿していただけませんか? または、 （コードを壊すだけでなく）損害を与える別のフィールドのルックアップ値に基づいて、あるフィールドの値を返す方法でコードに渡すことができるパラメーターを正確に示しますか?
Jet が「;」で区切られた複数の SQL ステートメントを実行できないことを考えると、Jet バックエンドでの SQL インジェクションの脅威を理解するのに苦労しています。しかし、それはおそらく、私がハッカーほど想像力に富んでいないからです。
ああ、無料の手がかり (従来の SQL インジェクション以外の危険性について):
Access 式サービスは、ODBC 経由では利用できません。
DDE経由で利用できますが、DDE経由でSQLをAccessに渡すことができるかどうかはわかりません（AccessでDDEを約10年間使用していません）.
Access および Jet 式サービスについて何も知らない場合、Jet (および Access) に関する質問に答える資格はないでしょう。
3 つのポイント:
パラメータ化されたクエリを使用することは、一般的に、SQL を壊す可能性のある方法 (たとえば、オニール氏) をエスケープするよりも作業が少ないため、データをクエリ文字列に直接連結できます。より堅牢なオプションを実装する作業も少ない場合、なぜそれを実行したくないのでしょうか?
私は長い間 Jet を使用していないので、最近、事前に準備されたステートメントをサポートしているかどうかはわかりませんが、ステートメントを複数回実行する場合は、パラメーター化されたクエリを使用して再実行します異なるパラメーターを使用すると、毎回新しいクエリを作成するよりも高速になります。
すべてのユーザーが 100% 信頼でき、損害を与えようとするほど不満を抱くことは決してないとしても、タイプミスやその他の真のミスの可能性は常にあります。ユーザーエラーを防ぐことは、一般的に良いことと考えられています。
したがって、セキュリティのためでなくても、他の質問に対する Spolsky の回答に示されているように、パラメーター化されたクエリを絶対に使用する必要があります。安全性が向上するだけでなく、エラー耐性が向上し、多くの場合、書き込みが速くなり、繰り返しクエリのパフォーマンスが向上します。