SQLインジェクションの脆弱性のテストは、最新のWebアプリケーションに関連していますか？
最初にいくつかの背景：
私は、主に仮想化とネットワーキングで5年の経験を持つインフラストラクチャエンジニアです。
過去1年間、セキュリティについて多くの自己学習を行い、Security +に合格し、Webアプリケーションハッカーハンドブックを読み、BugcrowdとHackeroneを使用してバグを発見するためにかなりのお金を稼ぎました。
脆弱性を探すときはいつでも、SQLインジェクションは常にスキップします。これは、最新のアプリケーションのほとんどが、本やオンラインチュートリアルに示されている従来のSQLインジェクションメソッドに対する弱点を示さないためです。
さて、これは他のセキュリティ愛好家にも当てはまりますか？これにどのように取り組みますか？異常な文字をたくさん送信しようとしましたが、これまでのところ最高の結果はエラー500でした。
前もって感謝します
実際、OWASPによると、SQLインジェクションはWebアプリケーションによる脆弱性トップ10に含まれています。 https://www.owasp.org/index.php/Top_10_2013-Top_1
そして、この主題に関する懸念に関する多くの論文、記事、ニュースがあり、Joomla、Wordpress、Webサイトなどの有名なWebアプリケーションに対するSQLインジェクション攻撃に関するニュースが毎日あるため、「最新のアプリケーションには、従来のSQLインジェクションメソッドに対する符号の弱点はありません」と、毎日新しいSQLインジェクションメソッドが導入されています。
私は現代のアプリケーションが正確に何を意味するのかわかりません。はい、多くのフレームワーク、ORM、Entity Frameworkなどがクエリを分解し、デフォルトのフィルタリングを適用する場合があります。ただし、カスタムコーディングが必要なより複雑なシナリオ、またはORMまたはライブラリ関数が期待どおりに動作しない場合、SQLインジェクションまたはその他の攻撃への扉を開きます。
多くのORMとフレームワークでは、セキュリティの部分が組み込まれています。これは、いくつかのセキュリティの問題を自動的に処理する影響がありますが、同時に、多くの開発者は、これらのライブラリ関数がそれらのために何をするか、いつオーダーメイドのソリューションを作成する必要があります。彼らはいくつかのチュートリアルに従うだけで、セキュリティを考慮する必要があることを知りません。
また、基本的なエンドユーザーのCRUDタイプのアプリの外に出る場合、開発者はあまりメンテナンスされていないライブラリを使用する必要がある場合があります。たとえば、誰かがCSVファイルをアップロードでき、処理されているビジネスアプリがあるとします。多分誰かがこれを処理するためにライブラリを書いてORMを使用しなかったかもしれません、それはあなたの開発者がそれで行くように機能します。次に、CSVが1行ずつ読み込まれ、データベースに処理されます。SQLインジェクションが可能です。
SQLインジェクションは症状であり、適切な入力検証が行われていないため、ベイクできない一般的なシナリオや複雑なシナリオ、または後から考えると、この可能性が高くなります。
また、「モダン」なアプリケーションはモダンに見えるかもしれませんが、期待を裏切った古いジャンクまたは奇妙なレガシー接続に基づいて構築されています。
SQLインジェクションは、セキュリティをテストするときにスキップするものではありません。 Ponemon Institute Breach Report によると、SQLインジェクションは悪意のあるまたは犯罪的な違反の30％を占めており、違反の原因となった攻撃ベクトルのほとんどを占めています。
私の会社では、独自のアプリケーションのSQLインジェクションの脆弱性を見つけるためにさまざまな方法を使用しています。開発、テスト、本番環境では、静的コード分析によるアプリのソースコードのスキャンとアプリの侵入テストを組み合わせて使用します。これは、侵入検知システム（IDS）やWebアプリケーションファイアウォール（WAF）などの技術的制御と組み合わされます。
静的コード分析ベンダー/製品：
- Checkmarx
- 白い帽子
ペンテストを行うベンダー/テクノロジー：
- 白い帽子
- 剣と盾
- 正確な
- Nexpose（Rapid7）
- ヘイルストーム（Trustwave、以前はCenzic）
ここで確認できるSQLインジェクションを検出またはブロックする方法はいくつかあります Imperva-SQLインジェクションをブロックする方法 。ブロッキングはあなたが探しているものではないかもしれませんが、それはそれが脆弱かどうかを判断するためのいくつかの優れたツールを間違いなく持っています。
最も簡単な方法は、Webサイトでゴミ/攻撃をスローする単純なスクリプトを実行することですが、私は最初にそれをクリアします。
[〜＃〜] owasp [〜＃〜] は、存在しないことに関して、SQLインヒクションを見つける方法についての情報を持っています。 A 最近Drupal SQLインジェクション は、それが（Drupalのような成熟した環境でも）単に真実ではないことを示しています。
これらを見つける方法は、多くの場合、単純にファザーを使用し、ランダムなゴミをWebアプリに送信することです。
長年にわたって多くのアプリケーションが成長しています。現在のベストプラクティスを反映するためにコードが時々リファクタリングされない限り（つまり、SQLインジェクションの場合：パラメータ化）、多くのアプリケーションには、何年も触れられていない非常に多くのレガシーコードが含まれています。そして、他の部分がそれに依存しているので、触れられない可能性があります。リファクタリングには時間とお金がかかります。正直なところ、機能する限り、リファクタリングは必要ありません。
たとえば、Wordpressを見ると、彼らは wp_magic_quotes という関数を使用しています。これは、基本的に PHPのマジッククオート の動作を模倣しています。 $_GET、$_POST、$_COOKIE、および$_REQUESTの特定の文字を自動的にエスケープする機能。この「機能」はPHP 5.3.0で廃止され、PHP 5.4.0で削除されました 悪い考えいくつかの理由 （コメントにも注意してください）。
しかし、Wordpressはマジッククオートに依存し、強制しますが、それでも プラグインまたはテーマにSQLインジェクションの脆弱性がたくさんあります です。
別の事実： CWE-89：SQLコマンドで使用される特殊要素の不適切な中和（ 'SQLインジェクション'） は、すべてのCVEの弱点の中で10％で3番目に配置されます（全体的なCWEセキュリティデータベースのダッシュボード ）。
さて、これは他のセキュリティ愛好家にも当てはまりますか？
私の経験では、No-SQLインジェクションはまだ普及していますです。
私は四半期ごとに平均30〜50のWebアプリケーション評価を実行しており、SQLインジェクションは依然として最新のアプリケーションの問題であることを保証できます。
そうは言っても、私の評価は約85％自動化され、15％が手動でフォローアップ/検証/検証されます（私はプロのペンテスターではありません）
自動スキャナーには、他の方法では見落とされている可能性のあるパラメーターフィールドでSQLインジェクションを見つけることができるという利点があります。
欠点は、自動化されたスキャナーは、人間のようにロジックの欠陥を悪用するのに優れていないことです。
これは、アプリケーションが構築されているプラットフォームによって異なります。 DrupalまたはWordpressは、アプリを設計するための成熟した開発者のツールの選択になるとは思わない。そして、分析における経験豊富なソフトウェアエンジニアとしてのあなたおそらく、そのような低品質のアプリケーションに直面することはありません。Wordpressを使用する場合、彼は確実にSQLインジェクションまたはXSS攻撃を受けるでしょう。これらのプラットフォームはWindowsのようなものです。不適切な使用と人気は脆弱性をもたらします。
はい、SQLインジェクションはまだ存在しており、注意する必要があります。一方、扱う成熟した開発者が多いほど、心配する必要は少なくなります。
今日SQLインジェクションを見つけることは非常に簡単で、誰でもそれを行うことができます。
SQLインジェクションの終了を予測する開発者や研究者はたくさんいますが、年々、OWASPトップ10に残っています。
SQLインジェクションは至る所に存在し、安全なコードを作成する方法の教育または知識（またはおそらく悪い習慣）の欠如が問題です。たとえば、この本の第6章の「Head First PHP＆MySQL」では、SQLインジェクションとmysqli_real_escape_string（）でそれを阻止する方法を紹介していますが、サニテーションメソッドは、残りの本に適切な衛生設備を使用しないことにより、ユーザーはもちろん、衛生設備の使用も忘れることになります。
パスワードについては、本でMySQLのSHA（）メソッドを紹介していますが、適切なパスワードアルゴリズムやソルトは使用されていません。
付録A（「カバーしなかったすべてのトピック」という名前）に、「PHPアプリケーションの保護」と呼ばれるトピックがあります。これらのページには、phpinfo（）スクリプトの削除に関するいくつかのページしか含まれていませんでした。 XSSとの戦い。
つまり、SQLインジェクションは依然として非常に重要です。
古典的な古い学校'or 1=1 # SQLインジェクションはもうなくなっています。しかし、洗練されたものは時々忍び寄ります。これは、TrustWavesが ModSecurityルールセット を更新して収益を上げる方法の1つです。
最新のWebアプリのほとんどは、「セキュリティ導入チェックリスト」を通過し、通常は本番導入前に既知の脆弱性についてもテストされます。配備されると、バウンティハンターが現れ、独自のテストを実行します。システムは、その時点で取得できるので「安全」であると見なされます。
自動化されたツール 使用済み 開発者と賞金稼ぎによって、高速で役立つ一方で、決心した人間の攻撃者が最終的に発見するであろう洗練されたインジェクションも見逃します。