.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
1。誤ってほうれん草のサイトを見つけてからテストしました。アイデアは次のとおりです。ほうれん草のサイトであるため、ユーザーは間違いなく登録します。そうでなければ、どのようにお金を請求できますか？ユーザーと強く対話するページを登録する場合、脆弱性の可能性は次のとおりです。
SQLインジェクション：ユーザーが入力したアカウント情報が、フィルタリングなしでデータベースを書き込みまたはクエリするために直接使用されている場合、SQLインジェクションXSSが必要です。入力ボックスに入力された個人情報がユーザーのページに表示されます。同時に、管理者はバックグラウンドでユーザーの個人情報を表示する許可を持たなければならず、ここにストレージXSSがある場合があります。そのようなサイトにはカスタマーサービスがあるため、反射的またはDom XSSであっても、Cookieやその他の目的を盗む目的を達成するために、顧客をトリックしてリンクをクリックしてリンクをクリックする方法を見つけることができます。並行したオーバーライトの権利：ユーザーがログインし、ログイン後に特定のページをチェックしてからパケットをキャッチすると、同様のIDフィールドがある場合、ID番号CSRFを変更することにより、他のユーザーや管理者の情報が表示される場合があります。または、メールアドレスを変更してから、メールアドレスを介してパスワードを変更します。支払いの脆弱性：パケットをキャッチしてパラメーターを変更し、0元を支払います。このアイデアに従ってください。3つまたは7つか7つまたは2つのいずれかに関係なく、最初に登録ページを試すツールに移動します。結果は次のとおりです。
（1）最初に2番目のものを見てみましょう。プロンプトパラメーターを検出ツールのペイロードに変更した後、ページは次のとおりです。ペイロードは実際にフィルタリングなしでページに表示されるので、とても幸せです。
ペイロード自体はJS内にあるため、スクリプトタグは最初に作成されませんでしたが、「19736％0A」、}％0AALERT（666）;％0A 'などのペイロードを直接使用しました。ペイロードの目的は、アラート（666）をバックグラウンドの元のスクリプトタグに直接公開することですが、それらの多くを繰り返し試すことはできませんでした。思考を調整して、スクリプトタグを再構築することしかできませんでした。今回は、次のように成功しました。これは、このXSSに誤ったアラームがないことを意味します。
もう1つはクッキーにあります。 SessionIDが変更された場合、ページのHTMLソースコードにも直接表示される可能性があります。上記の最初のものと同様に、独自のJSコードを実行するためにスクリプトを構築できます。ただし、バックグラウンドソースコードがわからないため、これがストレージ型XSSであるかどうかを判断することはできず、他の人がURLの構築をクリックしてクリックすることはできません。私は個人的にそれがあまり意味がないと思うので、私はもうここでそれを確認しません。
バックグラウンドにログインすることはできないため、他のXSSがストレージタイプであるかどうかはまだ不明です。この段階では、他のXSSの脆弱性を引き続き検証しません。
（2）ログインインターフェイスがパケットをキャプチャし、ユーザー名とパスワードは実際にはプレーンテキスト、WTFで送信されます.
手放した後、私は新しいパッケージをキャッチし、リピーターに入れて試してみてください。フィールドキャプチャがあります。これが検証コードです。削除した後、サーバーはとにかくそれを実行し、検証コードが間違っていることを促しませんが、ユーザー名またはパスワードが間違っているため、多くのトラブルが節約されます。最初に正しいアカウントを使用してテストし、返されたステータスがyであることがわかります。すべてが正常であることがわかります。
次に、単一の引用符、二重引用符、ブラケット、 '）または1=1でさまざまなSQL注入ペイロードを試してみます - QWEおよびその他のSQLインジェクション、そしてリターンは次のとおりです。
右側のネイティブコードの文字列は:です。「4〜15文字を入力してください。英語の文字と番号のみを入力できます」。フィルタリングすることは意図的であり、文字と数字のみを入力することができ、特別なシンボルを入力することはできません。また、SQL注入がここに存在しない可能性が高い。 （一部のWebサイトのフロントエンドページも説明しており、実際にバックエンドサーバー側でチェックされており、JSを使用してフロントエンドをチェックすることはできません。
（3）並列/垂直のオーバーリーチ：ログインした後、一部のサイトは、UID=123、GroupID=456、Telno=135000387465など、CookieにさまざまなIDをもたらします。フィールドの意味を簡単に確認でき、値を変更した後、他のユーザーのデータを確認します。しかし、ここのCookieはすべてセッションであり、さまざまな数字を持つフィールドは意味が何であるかを見ることができません。 Burpを使用してさまざまな値を試し、Status:Nを返します。これも従うことも不可能です。
（4）0 Yuan支払い：支払いインターフェイスでパケットをつかみ、リクエストパケットのコンテンツをデコードし、内部に別のサインフィールドがあることを確認し、他のフィールドがチェックされます。金額が変更された場合、検証アルゴリズムを逆にしてから、符号値を再計算する必要があります。ここでは一時的にあきらめます。 PS：user_idが最終的にここに公開されます。
3。Xrayスキャンを通じて、樹脂ビューファイルの脆弱性が見つかりました。
ファイル=xxxxのコンテンツを変更するスキャンプロンプトによると、以下の構成ファイルなどのファイルを実際に見つけることができます。
この脆弱性は、イントラネットファイルを横断できるSSRFに似ています。次に、GitHubで搾取のためのツールを見つけ、Burpを使用して辞書の徹底的なディレクトリとファイルを1つずつ実行しますが、次のファイルのみが見つかりました。これらはすべて通常のファイルとパスであり、予想される構成（アカウントなど）が見つかりませんでした。
Cドライブを通過したい場合は、保護されているようです。
この抜け穴は一時的に放棄されます。
4。今のところ、XSSのみを使用できることがわかっており、それも反射的です。 XSSプラットフォームを見つけて、Cookieを盗み、XSSの脆弱性を備えたURLに埋め込んだスクリプトタグを生成し、カスタマーサービスMMを見つけてクリックしてクリックします。その結果、カスタマーサービスMMは愚か者に落ちなかっただけでなく、新しいサイトをもう一度試してみるための新しいリンクを送ってくれました。
さて、もう一度やり直して、新しいサイトを構築し続けます。アカウントで新しいサイトにログインした後、私は主にユーザーと対話するページを探します（多くのパラメーターが関係しており、変更の余地がたくさんあり、脆弱性の可能性は静的なWebページの可能性よりもはるかに大きいです）。私は多くの時間を費やし、無数のリンクをチェックしましたが、次のようにターニングポイントがあるように見えました。
これは、アカウント名、電話番号、ニックネーム、アクセス許可などのさまざまな機密データを含むJSON文字列であり、URLにクライアントキーワードがあります。これはユーザー情報を表示するためのインターフェイスですか？すぐにBurpを使用してパケットをつかみ、URL内の純粋な数値のパラメーターを変更します（純粋な数字はインデックス作成を意味し、網羅的になりやすいです）。予想どおり、登録されたユーザーの情報は爆破されました。
5.さらに、CORSの脆弱性（CSRFのタイプ）もXrayを通じて発見されました。また、プラットフォーム上の顧客、管理者、または他のユーザーをクリックする方法を見つける方法も見つける必要があります。当面はここに行きません。
このほうれん草サイトの概要：1。ユーザーはフォームの入力を厳密に制限しており、SQL注入とXSSの両方がブロックされています。 2.樹脂の脆弱性は痛みを伴わず、機密データを取得できません。 3。支払い：標識フィールドの検証があり、検証アルゴリズムを最初にクラックする必要があります。 4。最終的に、ページはパラメーターを渡しましたが、チェックしませんでした。一部のユーザー情報は、数値パラメーターの値を変更することで爆破されました。 5.それはビジネス上の理由のためかもしれません。フロントエンドページはまだファイルをアップロードする場所を見つけていませんが、Xiaomaをアップロードする方法を見つけることはまだ不可能です。
参照：1。https://blkstone.github.io/2017/10/30/resin-attack-vectors/樹脂サービスに対する攻撃ベクトル照合
元のリンクアドレスから転載：https://www.cnblogs.com/theseventhson/p/13738535.html