SQLインジェクションに対する保護が高い優先度ではないのはなぜですか？

Stack Overflowでは、基本的な回避策が10年以上広く利用されているにもかかわらず、SQLインジェクション攻撃に対して非常に脆弱なMySQLクエリを含む質問と回答に多くのPHPコードがあります。

これらのタイプのコードスニペットが現在も使用されている理由はありますか？

私は主にa）無知b）怠toによるものだと思います。初心者は通常、SQLインジェクションについてあまり知識がなく、それを聞いたとしても、そのようにコーディングする方がはるかに簡単で簡単なので、それを無視します。

PHPは、有用な動的Webページを作成することをほとんど知らない人々にとって、意図的に本当に簡単に作成します。これは、PHPが多くの初心者を惹きつけ、有用なものを作成し、他の有用な見た目の例から学び、このクールで有用な方法を他の人に教えることを意味することを意味します。その結果、多くの不正なコードが生成され、それ以上のことを知らないプログラマーが増えます。

有能なプログラマーの大部分がPHPとは関係ないことを望んでいるのは事態を悪化させるだけです。これにより、他の人をより良く教えようとする経験豊富な人々のベースが減少します。しかし、なぜ彼らはPHPを避けるのですか？要因の組み合わせに適しています。一部には、彼らは言語いぼを扱うのが好きではありません。そして、部分的には、彼らは良いコードで作業することを好むだろうし、そこには良いPHPがあまりないからです。

この問題の正確な星座は、Perlに影響を与えていました。輝かしい例として、熱心な10代のMatt Wrightの事例を考えてみましょう。1990年代に、多くの有用で、十分に文書化された、簡単にインストールできるCGIスクリプトを提供しようとしました。残念なことに、彼はセキュリティについて何も理解していませんでした。また、彼のものを使用したい人々も理解していませんでした。その結果、Matt Wright Script Archivesが誕生しました。これは初期のCGIスクリプトの無限のセキュリティ問題でした。http://www.scriptarchive.com/nms.htmlのような努力にもかかわらず、共有ホスティングプロバイダーがPHPを他の何よりも便利にするまで、Perlの問題は改善しませんでした。そのため、問題がPerlからPHPに移行します。

残念ながら、そこにあるトン以上、より-悪いPHPのチュートリアルのは、そこに出て、いくつかの古いPHPの本も（などはregister_globalsを使用していない）適切なコードを書くために人々に伝えるに吸い込ま。

さらに、magic_quotes_gpc過去に有効化されたため、人々は「単純に機能した」ためにエスケープを気にしませんでした。

個人的には、PHPは使いやすいと思うので、当然、誤用しやすいです。

人間として、そしてプログラマーとして、私は間違いを犯すことは非常に簡単であり、特に時間に追われたとき、特定のものを見落とすことは非常に簡単です。

特定の言語を非難するのは簡単で、おそらく魅力的すぎるかもしれません。しかし、それは、プログラミングするために選択された言語に関係なく、人間の誤りやすさのより大きな問題を明らかにするでしょう。

確かに、アセンブリ言語から長い道のりを歩んできました。PHP、Python、Ruby、Javaなど、より現代的な言語ではるかに生産的なプログラミングができると思います。

PHP（およびその他のスクリプト言語）は、実際には参入障壁を下げています。これは、プログラミングの初心者が最初にPHPを試すことを意味する場合があります。しかし、それは確かに、すべてのPHPプログラマーが他の言語のプログラマーよりも何らかの形で適格性が低い、または彼らの間違いから学ぶ能力が低いことも意味しません。

ラスマスラードルフは1994年にPHPを元の形式で作成しましたが、それ以来、大幅に進化しています。最も最近の化身では、オブジェクト指向プログラミングとSymfonyなどの優れたフレームワークをサポートしています。言語としてのPHPは、当初の制約から解放され、プログラマーがそれを使用する方法を柔軟に選択できるようになりました。これを使用して9,000行のスパゲッティコードのスクリプトを作成したり、Symfonyなどの最新のMVCフレームワークのコンテキスト内で使用したりできます。

セキュリティの脆弱性は、単一の言語に限定されるものではないと強く思います。すべてのPHPプログラマーを何らかの形で能力が低いか、または安全でないコードを書く傾向があるとみなすのは魅力的です。しかし、その中のどれくらいが言語の偏りであり、どれくらいが事実なのだろうか？

問題の一部は、自分がしていることをわざわざわざわざコードをコピーするだけの人だと思いますが、本当に私の考えでは、porgamnmingを教える方法が壊れており、それが悪いコードがたくさんある理由の1つです。私たちは構文を文脈から教えているので、初心者はいつ構文を使用するのか、いつ使用しないのか、どの構文の問題を解決するのか、どのような問題を解決しないのかを知りません。そのため、レンチが優れたツールであった場合、ハンマーを使用します。

したがって、たとえば、単に構文を教えるのではなく、コースを次のように整理します（明らかに、より多くのステップがあります。これは、単に構文を教えるのではなく、基本的な問題からより複雑な問題を構築する基本的な例です）：

1. これが基本的なWebページの設定方法です
2. これは、Webページにデータベースからデータをプルさせる方法です。
3. これは、Webページからデータベースにデータを送信する方法です
4. これは、正しいデータが送信されることを確認する方法です。
5. これは、悪意のあるデータ入力からデータベースを保護する方法です

同様に脆弱なMS SQL + ASP / ASP.NETのサンプルが同量見つかると思います。

問題の一部は、何かを教えようとしているとき、たとえばWHERE句を使用してデータをフィルタリングするとき、クエリ文字列を適切にエスケープしたり、パラメーター化されたコマンドを使用してサンプルを乱雑にしたくないという事実に起因すると感じています。

私は長年開発者を訓練してきましたが、チュートリアルで恐ろしいコードを書いている人々に共感することができます。それが最も簡単に理解できる場合もあります。ただし、余談ですが、私は常に脆弱なコードを指摘し、興味深い副題にしています。

PHPの元の著者であるRasmus Lerdorfは、悪名高いブログエントリで「フレームワークなし」開発を提唱しています。SQLクエリにはPDOを使用していますが、SQLインジェクションのリスクはありません。ORM層を備えた最新のMVCフレームワークと比較すると、まだかなりくて時代遅れです。

この貧しい習慣をPHP自体のせいにすることができます。従来のバージョンのPHP（2006年頃まで）は、すべてのGETおよびPOST入力変数をエスケープするため、デフォルトでのデータベースクエリ補間に適しています。http://php.net/manual/en/security.magicquotes.phpを参照してください

チュートリアルの目的を、実稼働環境で何をすべきかと簡単に説明することと混同しないでください。たとえば、私が書いたほとんどのチュートリアルコードには、エラー/例外チェックがほとんどまたはまったくありません。コードは特定のタスクを実行する方法を示しているだけであり、考えられるすべての結果をカバーする方法を示していないことを読者に思い出させようとします。

私がPHPを学んでいたとき、私はこれらのPHP + MySQLの本をいくつか見ました。そしてそれはその悪い習慣に貢献していると感じています。しかし、私は同情を持っています、彼らは言語を教えているので、良いプログラミング慣行ではありません。それ以外の場合、どこで終了しますか？