実践経験はあまりありませんが、CTF（水の競技）の経験はたくさんあります🐶。自分の脆弱性に対する理解が十分ではないと感じ、論理的な脆弱性からまとめ始める準備をしています。
先輩たちの経験を参考に、論理的な脆弱性のマインドマップを簡単にまとめました。
一般的な論理的な脆弱性の分析#
任意のパスワードの回復 / 任意の電話番号の変更#
クラシックなプロセス：
古い電話番号 / 古いパスワードの確認 -> 新しい電話番号 / パスワードの提供 -> 変更の提出
最初のステップでは、元の電話番号またはパスワードを確認し、変更のレスポンスパケットを変更できる場合、このステップをバイパスできます。
この時、第三のステップで最初の認証が成功したかどうかを確認しない場合、任意の電話番号をバインドしたり、任意のパスワードを変更することができます。
並行抽選 / サインイン#
抽選やサインインの並行問題は、複数回のリプレイを使用してログイン日数を累積し、複数の抽選券などを獲得することができます。
一般的な解決策は、CAS 操作を使用して行われます。CAS 操作には 3 つのパラメータが含まれます：
- メモリ位置 V
- 期待される元の値 A
- 新しい値 B
CAS はまず V の現在の値が A と一致するかどうかをチェックし、一致する場合は B に更新し、それ以外の場合は操作を行いません。この操作はすべてアトミックであり、同期が保証されます。
フロントエンド JS#
フロントエンドの JS を探索すると、多くのポイントを見つけることができます。例えば：
- 隠されたインターフェース
- JS ソースマップファイル
主にこの記事を参考にしてください：
[https://xz.aliyun.com/t/9453]
ログイン情報の漏洩#
いくつかの H5 シナリオや小プログラムシナリオでは、多くの開発者が手抜きをしています。実際には、ログイン情報の設計が複雑すぎるため、簡単に openid などを使用して直接検証してしまいます。
このようなケースは非常に多く、特に WeChat エコシステムの下でよく見られます。
エラーページ#
エラーページには多くの情報が含まれています。最も一般的なのは、CTF でテンプレートインジェクションを実現するためにエラーページを使用することです。
実践シナリオでは、エラーページはログイン情報などの多くの機密情報を漏洩する可能性があります🐶（実際に遭遇したことがあります）
Google ハッキングの拡張#
これだけの論理的な脆弱性を知っているので、どのようにテストすればよいですか？
Google ハッキングの構文を使用すると、多くのサイトを見つけることができます。一つずつテストしてみるだけです。たとえば、支払い機能を探す場合は、次のように検索できます。
inurl:m intitle:订单详情 inurl:id=
我的订单 订单详情
inurl:order 订单详情
inurl:wap intitle:订单详情
inurl:m intitle:订单详情
inurl:php intitle:订单详情
title:订单详情 手机号
site:.com title:订单详情
title:订单详情 身份证
このアプローチで実際の支払いサイトを多数見つけることができ、一つずつ検証テストすることができます。
もし脆弱性が一般的なものであれば、xray や他のパッシブスキャンツールに統合するための poc を作成することもできます。
次の記事では、これらのサイトの探索について共有します🤔。まずはこの記事を終わらせましょう。