私の脆弱性マイニングの実践を思い出してください - 企業の SQL インジェクションの脆弱性

 目次

I.はじめに

2.マイニングプロセス

1. Google文法ランダム検索

2. ウェブサイトに入る

3. 注入点検出

3. SQLMAP ブラスト

(1) 爆破図書館

(2) バースト

(3) バーストフィールド

 3. まとめ


I.はじめに

  脆弱性ボックスに脆弱性を提出しましたが、その上に公益SRCというプロジェクトがあります。公共福祉 src は、ホワイト ハットがランダムに発見された脆弱性を提出するためのプラットフォームです.脆弱性ボックスでランダムに発見した脆弱性または積極的に発見した脆弱性を提出できます. src をマイニングするときは赤い線を越えないでください.一般に、SQL インジェクションに遭遇したときに脆弱性の存在を証明するためにデータベース名を取得するだけで済みます.それ以上取得しないことをお勧めします. xss 脆弱性は、脆弱性の存在を証明するために、独自の Cookie や IP などの情報のみを取得します。情報漏えいの際、機密ファイルをダウンロードできる状況であれば、脆弱性を確認した上でファイルを削除する必要があります。

2.マイニングプロセス

1. Google文法ランダム検索

inurl:php?id=1

この Google の文法は、多くの友人にとって馴染みがあるに違いありません. SQL インジェクションの脆弱性を持つ可能性のある Web サイトを検索するために使用される非常に古典的な文法です.

Googleに行きたい友達は、fanqiangソフトウェアか何かを探すことができます. 見つからない場合は、win11に付属のエッジブラウザーもこの構文をサポートしているので、試してみることができます.

2. ウェブサイトに入る

操作の便宜上、URL を Firefox ブラウザーにコピーしました. トップ URL の後ろに id パラメーターがあることがわかります. 一般に, 脆弱性マイニングではこのパラメーターを確認することに注意する必要があります.問題点としては、まずidパラメータを表示できるサイトはGETパラメータ転送方式を採用しているのですが、このパラメータ転送方式は情報漏えいを起こしやすいので、実際にはPOSTパラメータを使うのがベストです。データを送信するための転送方法、および情報の直接開示を最小限に抑えます。

3. 注入点検出

操作の便宜上、URL を hakbar に入れます。

次のパラメータを入力した後、ウェブサイトの下部に画像が表示されないことがわかりました。テストを続けてください

id=1'

次のパラメータを入力すると、通常に戻ります(機密保持のために、ここでは地図を使用してすべての人に隠蔽しています)

id=1'and'1'='1

次のパラメータを入力すると、画像が再びエラーを報告する これは、非常に典型的な文字型 SQL インジェクションの脆弱性です。

id=1'and'1'='2

3. SQLMAP ブラスト

なぜ SQLmap を使用する必要があるのですか? 1つ目は効率を改善することです.結局のところ、SQLMAPはデータベース情報をより効率的にブラストするのに役立つ自動化ツールです.2つ目は、以前に手動で注入を試みたが、多くの情報を取得できないことがわかったため、SQLMAPを選択したことです.ブラスト。

 実際、SQLMAP の事前スキャン情報によると、SQL インジェクションの種類、オペレーティング システム、開発言語、データベースのバージョン、およびこの Web サイトに存在するその他の情報も確認できます。

(1) 爆破図書館

現在、この会社には 5 つのデータベースがあり、会社のプライバシーを確​​保するために、information_schema データベースを除いてすべてコード化されています。

また、個人的に脆弱性を掘る場合は、information_schema ライブラリを改ざんしないことをお勧めします。このデータベースにはデータベース全体の重要な情報が格納されており、何か問題が発生した場合の責任は負いかねます。

sqlmap -u URL --dbs 

(2) バースト

sqlmap -u URL --tables -D 数据库名

ここでは、自分で名前を付けたデータベースを選択したので、入力すると管理テーブルがポップアップしました. そのとき、ユーザー名とパスワードをそこに保存する必要があると推測しました.

 

(3) バーストフィールド

sqlmap -u URL --columns -T 表名 -D 数据库名

予想どおり、フィールド ブラストによって、account と userpass の 2 つのフィールドが見つかりました。その中には、ユーザー名とパスワードが含まれている可能性があります (これは単なる推測です。これ以上進むことはできません)。個人の安全のために、ここで停止し、SRC にバグ レポートを提出する予定です

 

 3. まとめ

SQL インジェクションの防御方法は数多くあり、よくある問題でもあります

1. 使用参数化查询:使用参数化查询可以防止SQL注入攻击。参数化查询是将SQL语句和参数分开发送到数据库,而不是将它们组合在一起。这样可以确保参数不会被解释为SQL代码。

2. 对输入进行验证和过滤:在将用户输入传递给数据库之前,应该对其进行验证和过滤。可以使用正则表达式或其他方法来验证输入是否符合预期格式。还可以过滤掉不必要的字符,例如单引号和双引号。

3. 最小化数据库权限:将数据库用户的权限限制为最小化,只允许其执行必要的操作。这样可以减少攻击者利用SQL注入漏洞的机会。

4.永远不要太相信用户输入的东西!


等等.............

穴を掘るときは、誰もが注意を払う必要があります.一部の非常に機密性の高い情報は、掘り出された後に無視されます.ランダムに広めたり、自由に使用したりしないでください.そうしないと、全体の性質が変わります.次に、送信することを忘れないでください.脆弱性報告が間に合う. 真っ白な帽子だけでOK!

こういう実用的な記事を書くのは初めてなので、悪いところを指摘してください!! !

おすすめ

転載: blog.csdn.net/qq_60503432/article/details/130465208