mysqlインジェクション防止は必要ないと思いますか？

最近、ユーザーが入力した一部の特殊文字をエスケープする SQL インジェクション防止について研究していますが、これは必要ないと感じています。

ユーザーがログインするとき、数字、文字、アンダースコアのみを許可します。特殊文字がある場合は、何かが間違っていることを直接プロンプトが表示され、DQL がわかりません。

そうですか?

ディスカッション (解決策) への返信

あなたはクライアント側で制限されていますか、それともサーバー側で制限されていますか?

クライアント側で制限していますか、それともサーバー側で制限していますか?

サーバー側では、PHP 正規表現が許可されていない文字を検出すると、特殊文字があることを直接プロンプトし、DQL を認識しないため、これらの特殊文字が使用される機会が与えられません。

もちろん、これは私の考えです。デメリットがあるかどうかはわかりません

では、なぜ他の人はあらゆる手段を使って注射を阻止しようとするのでしょうか

もちろんこれは私の考えです、あるかどうかは分かりません デメリットは何ですか

投稿者は最近どんな悪事をしていますか？

ちょっと考えただけで解読できる高度なシステムがたくさんあります。新人に崩されないようにするだけです。他の人は運命に任せます

あなたのプログラムを破壊したい人は、アドレスバーで直接操作するなどして、あなたのページを絶対に使用しません。準備を整えて、隙間があれば他の人に注射してもらいましょう。 。 。

数字、文字、アンダースコアのみを許可します

これが当てはまる場合、実際にはデータベース インジェクションはありません

SQL インジェクションは入力ボックスだけでなく、アドレスバーにもあります。 パラメーターの受け渡し

多くの高度なシステムは、ちょっと考えただけでも解読できます。新人に崩されないようにするだけです。他の人は運命に任せます

基本的に同意します。

クライアント側で制限していますか、それともサーバー側で制限していますか?

サーバー側では、PHP が許可されていない文字を見つけた場合、DQL を認識しないため、特殊文字が存在することを直接通知し、これらの特殊文字を挿入する機会を与えません。
サーバーサイド検証なので、検証さえできていれば問題ありません~~~

合格して学ぶ初心者

判断するとき

パラメータについては、すでにアンチインジェクション作業を行っています。

に従ってください。国内のオープンソース システムの多くは気軽にインジェクションできますが、完全にデータベース抽象化レイヤーであり、インジェクションできない Drupal ではこれは不可能です。 🎜>

------------------------ ------------------- ----------AutoCSDN 署名ファイル--------------- -------- ----------------------- ヤード ファーム— —プログラマーがコードをまき、アイデアを放牧するファームです。

登録時とログイン時の検証は、ユニバーサルパスワードの発生を防ぐことしかできないと感じます。SLQ の後に判決文をコメントアウトするのと似ています。 = = Web サイトがさらに挿入します。 Web ページのパラメータ

PDO を使用し、形式に厳密に従ってください。そうすれば、

の挿入について心配する必要はありません SQL インジェクションを防ぐために投稿者が理解した方法は、あまりにも一方的で特殊文字ですエスケープとパラメータ 強力な検証は、SQL インジェクションを防ぐ手段です。ベストはこの 2 つの組み合わせです。

不正な文字をフィルタするためにユーザーによって送信されたリクエスト。

16# は絶対に正しい

アンチインジェクション、アンチインジェクションとか！大切なのは悪人ではなく、紳士から身を守ることです。

クライアントに直接判断を下していますか?クライアントで判断する場合は、クライアントが JS を使用して判断するので、JS をロードまたは実行しないようにクライアントで JS スクリプトを設定することもできます。サーバーを使用する場合は、やはり SQL インジェクションを行う必要があります。

場合によっては、SQL インジェクションを防ぐことの存在には意味があります。クライアントはデータベースをクラッシュさせるだけです。クライアントはユーザーにとって唯一のパスであり、最も危険な SQL 出口です。通常、フィルタリングは SQL での SQL インジェクションを防ぐためにクライアントで実行されます。