How i get $100 in just 10 minutes !を訳してみた

Hello there, ('ω')ノ

わずか10分で100ドルを手に入れる方法！を。

脆弱性：

　レースコンディション

記事：

　https://jodyritonga.medium.com/how-i-get-100-in-just-10-minutes-b018b28645ce

今回は、Web アプリケーションの簡単な機能をテストして。

10 分ほどで 100 ドルを手に入れた方法を。

簡単に説明すると、この Web アプリケーションは、仕事やつながりを検索したり。

会社に関する最新ニュースを読んだりできるlinkedin のようなもので。

この Web アプリケーション Redacted.com として。

最初に会社の Web アプリケーションにアクセスしたとき。

通常、レート制限なしとポイズン ヘッダー インジェクションを探し。

しかし、その機能には運がなく。

そして、自分の方法論は、これら2つのバグが見つからない場合は。

他の通常のユーザと同じようにWebサイトを使用して。

すべての要求と機能を理解しようとすることで。

その後、投稿したり、他の人のコメントを気に入ったりできる機能が表示され。

頭の中でlikeボタンを見たらいいねと。

なので、Burp Suiteを起動してインターセプトをオンにして。

この種のリクエストを取得して。

その後、このリクエストをイントルーダに送信し。

ちなみに、このバグを見つけたとき、ターボイントルーダについて知らなかったので。

古い伝統的なBurp Intruderをまだ使用していて。

Intruderに送信した後、ペイロードを100リクエストでnullペイロードに設定し。

リソースプールもこれに設定して。

その後、リクエストを送信すると、リクエストは次のようになり。

そして、「ダブルレスポンスだで、それ働いているか、 競合状態はあるか」を。

そして、投稿をチェックして。

すると、 like には負の値があって。 

Best regards, (^^ゞ

Sleep SQL injection on Name Parameter While Updating Profileを訳してみた

Hello there, ('ω')ノ

プロファイルの更新中に名前パラメータで SQLインジェクションをスリープ状態にを。

脆弱性：

　SQLインジェクション

記事：

　https://medium.com/@umeryousuf26/sleep-sql-injection-on-name-parameter-while-updating-profile-2bbac9f47336

今回は、プライベート プログラムに招待され。

そのプログラムに属するすべての資産を追跡することができて。

通常の偵察から始めますが、Target でプロフィール画像の更新時に。

異常なパラメータ応答を見つけ。

そのため、SQLiスリープ ペイロードを使用し、sleep(5) から 5 秒間スリープして。

再度使用しても、うまくいって。

ペイロード：

　0'XOR(if(now()=sysdate(),sleep(5),0))XOR’Z

脆弱な更新プロファイル リクエストは、Burp Intruderを介して。

ペイロードを注入した後、次のようになり。

重要なヒント：

　各パラメータを手動で確認して。

Best regards, (^^ゞ

MY FIRST ACCOUNT TAKEOVERを訳してみた

Hello there, ('ω')ノ

初めてのアカウント乗っ取りを。

脆弱性：

　アカウントの乗っ取り

　ロジックの欠陥

記事：

　https://medium.com/@nireshpandian19/my-first-account-takeover-fd5570f09c0a

今回のサイトを「Magma.com」と呼ぶことに。

Burp Suite を使用して、XSS と SQLiの Web アプリケーションをサーフィンして。

応答を確認したところ、興味深い応答がいくつか見つかりましたが、残念ながら。

それらを実際の XSS にエスカレートする方法が見つからず。

Web サイトを閲覧するのに 3 ～ 4 日ほど費やしましたが、P4 は数件しか取得できず。

次に、サブドメインの列挙のために行った小さな自動化ツールに戻り。

それらをバックグラウンドで実行し。

多くのサブドメインの列挙を行い、アクティブなサブドメインが。

約 4 つしかなかったことを推測し、残りの乗っ取りをテストしましたが。

うまくいかず。

サブドメインを開いたとき、本当の楽しみが訪れて。

     staging.Magma.com

これは、ステージングに使用された元の Web サイトを正確に複製したもので。

ここにあるように、このステージングが前面にある多くのサブドメインに。

出くわしましたが、それらの目的がよくわからず。

元のWebサイトと同じように機能するために使用された可能性がありますが。

テスターと開発者向けで。

メインのウェブサイト www.Magma.com で試したすべてのテクニックを。

このウェブサイト (staging.Magma.com) でも試し。

その時だけ、彼らのページで下記を見て。

範囲外 ：

　メイン Web サイトの脆弱性につながる場合を除き。

　サード パーティがホストするサイトの脆弱性。

その後、staging.Magma.com の XSS、SQLi、IDORS などのバグのチェックをやめ。

これは役に立たないからで。

アカウント引き継ぎの一部：

staging.Magma.comは、www.Magma.comの正確な複製でしたので。

サインアップ／ログインページもあり。

サインアップ プロセスは次のようになり。

１．ユーザーが自分の電子メールを入力して。

２．電子メールが既に存在する場合は、ログインするためのパスワードが求められ。

３．そうでない場合、ユーザは自分の電話番号を入力し。

　　OTP を確認してアカウントを作成し、ログインする必要があり。

基本的に、アカウントを作成するにはメールアドレスと電話番号が必要で。

メインのウェブサイト www.Magma.com で、すでにアカウントを作成していて。

そこで「staging.Magma.com」にも同じアカウントでログインしてみて。

そして自分の電子メールを入力すると。

メールがデータベースに登録されていないかのように。

ログイン フォームではなくサインアップ ページが表示されて。

最後に、ログインページに電子メールと電話番号を格納するデータベースが。

両方のサイト (stagingと www) で異なることを理解して。

したがって、「staging.Magma.com」で既存の電子メールを送信すると。

サインアップフォームが表示され、電話番号にはメインサイトと。

同じ番号を使用せず。

代わりに、母の電話番号を教えたところ、電話番号を確認するために。

OTP を入力するように再度求められ。

古いアカウントにログインして。

自分がメインのウェブサイトで作成したもので。

ここで何が起こっているのかを理解するのに数秒かかり。

両方の Web サイトの登録またはサインイン ページは異なっていましたが。

それを過ぎると、アカウント データベースは分離されず。

staging.com の電子メールと電話番号がメインの Web サイトのアカウントに。

ログインして。

基本的に、被害者の電子メールを知っている攻撃者は、

　staging.Magma.com/login-signup

被害者の電子メールを入力し、攻撃者の電話番号を入力して OTP を確認すると。

攻撃者は実際に被害者のアカウントにログインして。

Best regards, (^^ゞ

Some Tips to Finding IDORs more easily and Fixing themを訳してみた

Hello there, ('ω')ノ

IDOR をより簡単に見つけて修正するためのヒントを。

脆弱性：

　IDOR

記事：

　https://medium.com/@nxenon/some-tips-to-finding-idors-more-easily-and-fixing-them-2c9d0c58bb4a

今回は、IDOR をより速く見つけるための鍵となる IDOR ブリンカーと。

IDOR の一般的な知識を持ち、おそらくそれらを修正したいプログラマー向けの。

ヒントについてお話ししたいと思い。

最初に IDOR とは何かを説明することに。

PortSwigger によると：

安全でない直接オブジェクト参照 (IDOR) は、アプリケーションがユーザ提供の。

入力を使用してオブジェクトに直接アクセスするときに発生するアクセス制御の。

脆弱性の一種で。

IDOR 脆弱性は、水平権限昇格

(自分と同じ権限を持つユーザへのアクセスを変更することを意味して)

に最も一般的に関連していますが垂直権限昇格

(管理者ユーザなどのより高い権限を持つユーザーへのアクセスの変更を意味して)

に関連して発生することもあり。

一般に、リクエスト内に ID が含まれている場合、またはオブジェクトの。

バックエンドまたは概念内のオブジェクトである何かが見つかった場合は。

IDOR の脆弱性についてテストする必要があり。

気をつけているのは、目隠しのようなもので。

時間オブジェクト：

ほとんどの場合、この記事でオブジェクトと言うときは。

リクエスト内のパラメータを意味して。

この場合、それ自体が時間を持つパラメータを意味して。

最初に、ペネトレーション テスターまたはバグ バウンティ ハンターが。

時間オブジェクトに注意を払う必要があり。

過去に期限があった変更不可能なものについて扱いたい場合は。

プログラマは、時間入力を使用していることを知っていて。

アプリケーションの機能に依存しますが。

例として、アイテムと異なるタイムラインを繰り返す場合は。

ユーザから時間を取得する必要があり。

これは、コントロールが正しく実装されていれば問題なくて。

では、オブジェクト ID とタイムラインが異なる場合はどうなるか。

下記は、オブジェクトにアクセスするための 2 つの異なるケースで。

したがって、ケース 1 では、ユーザが時間に基づいて項目を。

変更または追加できるように、プログラマはユーザから時間を取得する必要があり。

ケース 2 では。

Web アプリケーションは時刻をチェックするだけで。

時刻チェック レベルを通過した後は、ID と指定された時刻を比較しないため。

ハッカーは過去に発生した項目を簡単に変更または追加できて。

下記がオブジェクトにアクセスしてチェックする脆弱な方法と安全な方法で。

これは、現在詳細を表示できないプログラムの IDOR の例で。

下記は、過去の時間のリクエストで。

したがって、攻撃を成功させるために必要なことは。

時間をその時間の翌日に変更することだけで。

これは、後でアイテムを変更する権限があるためで。

ただし、Web アプリケーションは、リクエスト内の時間で ID をチェックしておらず。

Best regards, (^^ゞ

CSRF Leads to Delete User Accountを訳してみた

Hello there, ('ω')ノ

CSRF によりユーザ アカウントが削除されるを。

脆弱性：

　CSRF

記事：

　https://medium.com/@omarbakrey90/csrf-leads-to-delete-user-account-fc362078be2f

今回は、攻撃のシナリオが非常に単純なので。

実際の標的にそれが見つかるとは想像もしていませんで。 

いつものように、target.com には 2 つの機能があり。

メールの変更とパスワードの変更で。

テストしましたが、現在のパスワードが必要なため、CSRF がないようで。

しばらくして、独立したDELETEボタンを見つけ。

CSRFのように見えたので、Burp Suiteを起動すると。

予想どおり、CSRF トークンが必要で。

　トークンを削除　⇨　403 Forbidden.
　別のアカウント トークンに変更　⇨　403 Forbidden.

さて、どうやって手に入れるか。

target.com/signin/requestPassword をテストしていたときに。

csrf トークンを何度も目にしたことを思い出し。

新しいパスワードを要求し、CSRF トークンの削除を変更し。

要求を送信すると機能して。

さらに、ORIGIN ヘッダと REFERER ヘッダが。

問題を引き起こさないことを確認する必要があり。

    Origin: http://attack.com　⇨　200 Ok.
    Referer: http://attack.com/　⇨　403 Forbidden. //悪いニュース
    Referer: http://attack$target$.com/　⇨　200 Ok. //今すぐ報告を

Best regards, (^^ゞ