--昨日私は開発者と話していました、そして彼はデータベースフィールドへの挿入を制限することについて何かを述べました、例えば（マイナスマイナス）のような文字列。
同じタイプで、私が知っているのは<、>などのHTML文字をエスケープするための良いアプローチであるということです。ではありません--。これは本当ですか？心配する必要が--あり++ますか？それは神話や古いもののようなものですか？
たくさんの回答をありがとうございました。私はこれらすべてに慣れていないので、そのように理解するのは簡単です。さて、この場合、より具体的には、私たちが開発しているC＃ASP.NET MVC Webサイトについて話し合ったので、重要な情報が記載された複雑なアカウント開設フォームがあります。MVCがLinqを使用してデータベースとのインターフェイスには、この種の保護がすでに付属しているかどうかはわかりません。ですから、誰かがそれについていくつかのヒントを提供できれば、それは素晴らしいことです。再度、感謝します
SQLインジェクション攻撃を回避する適切な方法は、特定の問題のある文字を単に許可しないことではなく、パラメーター化されたSQLを使用することです。つまり、パラメータ化されたSQLは、データベースがSQLコマンドの一部として生のユーザー入力を実行するのを防ぎます。これにより、「ドロップテーブル」などのユーザー入力が実行されなくなります。文字をエスケープするだけでは、すべての形式のSQLインジェクション攻撃が阻止されるわけではなく、「ドロップ」などの特定の単語を除外しても、すべての場合に機能するわけではありません。「ドロップ」がデータ入力の完全に有効な部分である特定のフィールドが存在する可能性があります。
ここで、パラメーター化されたSQLに関するいくつかの優れた記事を見つけることができます。
https://blog.codinghorror.com/give-me-parameterized-sql-or-give-me-death/
http://www.codeproject.com/KB/database/ParameterizingAdHocSQL.aspx
ASP.netを使用しているとおっしゃったので、ASPでのSQLインジェクションを具体的に扱うリンクをいくつか紹介します。
https://dzone.com/articles/aspnet-preventing-sql-injectio https://www.c-sharpcorner.com/UploadFile/75a48f/how-sql-injection-can-be-possible-in-asp-net -ウェブサイト/
ASPをより安全にするためのより一般的な記事は次のとおりです：http： //www.codeproject.com/KB/web-security/Securing_ASP_NET_Apps.aspx
そしてもちろん、SQLインジェクションに関するMSDNの記事：http： //msdn.microsoft.com/en-us/library/ms998271.aspx
SQLインジェクションは、ほとんどのWebサイトにとって高いセキュリティリスクであり、ユーザーがデータベースで実行されるステートメントにパラメータを吹き込むことができます。
簡単な例は次のとおりです。
入力フィールド「名前：_________
"SELECT * FROM tblCustomer WHERE Name = '" + nameInputField + "'"
したがって、「ボブ」と入力すると、
"SELECT * FROM tblCustomer WHERE Name = 'Bob'"
しかし、「'; DROP TABLE tblCustomer」と入力すると、かなり不吉になります
"SELECT * FROM tblCustomer WHERE Name = ''; DROP TABLE tblCustomer"
これらの問題を回避する方法はたくさんあり、その多くは使用している言語に組み込まれているため、「;」、「-」、「/ *」などの危険な可能性をすべて考えるのではなく、次のようなものを使用してみてください。もう存在している。
使用している言語を叫んでください。これらの攻撃を回避する方法を教えてくれると確信しています。
彼が言ったことは非常に正しいので、彼はSQLインジェクション攻撃について話していました。
問題は、データベースに存在するそのようなデータではなく、サニタイズせずに入力データをデータベースに直接渡すことです。
クリーンアップせずに、誰かがで終わる文字列を渡した場合、必要なもの（たとえば）またはテーブルを削除するなどのより悪意のあるものを;続けることができます。select * from sys.objects
完全に防御することは困難ですが、コードから適切なDBライブラリを使用し、パラメーター化されたクエリを使用するなどの既知の方法に従うと、起こりうる損害を制限できます。
必要な数--だけデータベースに保存しますが、クリーンアッププロセスを実行せずにデータベースに渡さないでください（これは、優れたDBライブラリが不可欠な場所です。引用符やその他の潜在的に有害な入力をクリーンアップする必要があります）。
--データベースに含まれる文字列を挿入することについて「危険」なことは何もありません。
ユーザー入力から直接取得したものを処理せずにデータベーステーブルに挿入するのは危険です。そうしないと、SQLインジェクション攻撃を受けやすくなります。例：コーダーは、ユーザーがフィールドに自分の名前を入力できるようにし、ユーザーは次のように入力します。
Joe '); drop table users; commit transaction; --
次に、コーダーはそれを次のようにMySQLデータベースに配置します。
conn.execute("insert into users (username) values ('" + userInput + "')");
ブームユーザーがusersテーブルを削除しました（データベースログインにそれを行う権限があると仮定しますが、これは別のトピックです）。これは、コーダーがユーザーからの文字列が正しくエスケープされていることを確認しなかったためです。そのため、DBエンジンに直接送信され、攻撃者は大笑いします。:-)
文字列が正しくエスケープされるように、環境が提供するツールを使用してください。たとえば、JDBCはPreparedStatementこのためにクラスを使用します。ほとんどの環境には似たようなものがあります。
パラメータ化されたクエリを使用します。これらのクエリは、変数をSQLのプレースホルダーとして表します（など）select * from person where name = ?。SQLクエリを作成した後、クエリにパラメータ値を設定します。パラメータ化されたクエリにより、プレースホルダーの代わりに使用されたものがSQLステートメントの一部と見なされないことが保証されます。
パラメータ化されたクエリの概要については、JeffAtwoodの記事を参照してください。
INSERT / UPDATE / ...を実行するときにデータを正しくエスケープする限り、危険ではありません。
また、HTML文字をエスケープすることは良いアプローチではありません。そのような文字をエスケープする関数を作成し、エスケープされたテキストをデータベースに保存したとします。次に、関数が'<'をエスケープしなかったことに気付いたので、関数を変更します...データベースに既に存在するレコードはどうなりますか？-それらの「<」文字はエスケープされないままになります。したがって、データベースに保存する前にテキストをエスケープしないでください（もちろん、SQLクエリをエスケープしてください）。HTML / XML / ...ページがテキストから生成されたとき、つまりデータベースから元のテキストをクエリした後、エスケープが発生するはずです。