HTTPヘッダインジェクション
いくつかのケースでは、このようなユーザ名などの情報を、（例えば、共通のクッキーの検証など）クライアントのヘッダー情報ことを確認またはHTTPヘッダヘッダを介してクライアントに関するいくつかの情報を得るために、バックグラウンドの開発者は、フィールドを受け入れ、その上で
HTTPヘッダ情報は、クライアントを取得するとSQLを使用します十分なセキュリティ上の考慮事項は、SQLにつながる可能性がある場合は、この時点で処理を注入ベースのHTTPヘッダーの脆弱性
私たちは、最初のプロンプトにページクリックは、ユーザーのパスワードを入力することをHTTPヘッダを注入することができ、彼は表情を与えたページは、受け入れるHTTPポートをユーザエージェントを記録し、記録機能を有することを見出しました。これを見て、私たちは、それはまた、それの動作に関連するデータベースではありません、バックエンドが取得されたHTTPヘッダデータの内側にあるべき、と考えることができます。
私たちは、テストすることができます
burpsuitを開いた後、ちょうどEtherealのを見て、リピーターに送信され、私たちは、ユーザエージェントフィールドに基づいてテストする必要があります。あなたは既に私たちの一つのため、この場所は、SQLインジェクションの脆弱性が存在していることを見ることができるように、我々は、あなたが一重引用符、ポイント送信を提出することができ、このフィールドの値が削除された独自の構造を置くことを返します構文エラーデータベースを見つけました引用符の内側に配置されたSQLの実行レポートは、この時間は、我々は、ペイロード検査を構築することができ、文法の間違いを出てきました。
それは何な点があり、クッキーの内側にこのパッケージで、クッキー情報がセッションを追跡するために使用されるクッキーは、実際にバックエンドの髪ダウンしているが、背景には、クッキー情報のフロントエンドを取得しますが、ときにしている中ページ間をジャンプするとき、クライアントは、実際にクッキーのフロントを取得します、関連する検証は、スプライスされている同じデータベースにクッキー以降に取得した場合、関連する操作だった、SQLインジェクションの脆弱性を生成することも可能です。
私たちは、関連するテストをクッキー
私たちは、SQLインジェクションの脆弱性、ペイロード構成ベースの機能、リターンを見ての存在を示す、エラーをエラーが表示されます、ユーザー名の後ろに単一引用符を追加します。
だから、ときに我々のテストSQLインジェクションは、共通エントリポイントの事故は、http頭の一部に加えて、多くの場合、いくつかのSQLインジェクションの脆弱性を生み出します。
