web-dev-qa-db-ja.com

ランダムURL文字列：これはどのような攻撃であり、それを阻止するために何ができますか？

編集：

これが投稿されてからしばらく時間が経過しましたが、これは報告します[〜＃〜]ない[〜＃〜]と表示されます結局のところ、ある種の攻撃だったのです。

むしろ、この特定のURL文字列は cookieless session を示しています。

これは、Cookieを無効にしてサイトにアクセスしたユーザーの1人（または複数人）に過ぎず、URL文字列に挿入されたこれを適切に処理するようにアプリが設定されていなかったようです。

isだれかがこの効果を操作しようとした可能性はあります（タイムスタンプと頻度に関心があった）が、これは、「攻撃された！」少し早すぎるトレーニング。これに関する情報を見つけるのは驚くほど困難でした！

最終的には、私たちの（分離された）テスト環境でこの正確なURLパターンに遭遇したときにこれを理解し、この問題についてさらに調査を行うことにしました。

これであなたの助けをありがとう、そしてどんな混乱でもごめんなさい！すでに存在する回答が無効になるのを避けるため、最初の質問はそのままにしておきます。

元のテキスト：

私は、顧客向けの公開Webサイトを持つ会社で働いています。過去数週間、次のような一連のログエントリが表示されています。

_The controller for path '/(x(1)s(mpwcjessdyhikng0a1kyud1z))/' was not found or does not implement IController.
_

これらのエントリは通常約1秒間隔であり、常にx(1)sで始まり、その後にランダムな文字列が続き、その後に異なるページへのさまざまなパス、特に_/account or /account/recoverpasswordrequest/_が続きます。これは10〜30分間続く傾向があり、通常はほぼ毎日発生しますが、翌日まで再び表示されることはありません。

これが発生したいくつかのIPをブラックリストに登録しましたが、この人物は明らかに多くの異なるIPを使用して、これを実行しているスクリプトを実行しています。

ここで何が起こっているのか、特にx(1)sが何であるか、またはこの人物がどのような情報を取得しようとしているのかを誰かが私に理解するのを手伝ってくれる？この情報を受け入れるランダムに名前が付けられたコントローラーがないため、攻撃は失敗しますが、これを停止できるか、少なくとも何が起こっているのかをよりよく理解できればすばらしいでしょう。

編集：この「リクエスト」は常に同じ_(x(1)s(random))_パターンに従います。主にヒットしている3つのURLがあります。

The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/' was not found or does not implement IController. The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/register' was not found or does not implement IController. The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/recoverpasswordrequest' was not found or does not implement IController.

完全なURLは次のようになります：https://example.com/(these requests)

このサイトではMVCを使用しているため、これらの特定のエラーメッセージは、このURLで解決できる_(x(1)s(blah))_という名前のコントローラーがないために発生します。ログエントリには、3つのURLすべてに同じランダム文字列が使用されていることが示されます。その後、新しいランダム文字列が生成され、同じパターンが再試行されます。

これらのログエントリは、このリクエストが失敗し、アプリケーションロジックで例外を引き起こしたものです。したがって、それらはファイアウォールをバイパスし、実際にコード内で失敗します。

attacksattack-prevention.net
8
levelonehuman

@RomeoNinovに同意します。これはファズロジック/テストまたは利用可能なすべてのアプリケーションを一掃する単なるスキャナーである可能性があります。これを止めるという意味では、すべての受け入れ可能なリクエストをホワイトリストに登録するのが最善です。それ以外の場合は、大きすぎて追いつけない不要なリクエストをすべてブロックして、モグラを叩きます。

IISリクエストフィルタリングはIIS7 +のネイティブ機能であるため、推奨します。アプリケーションのすべてのURL（cs-uri-stem）をalwaysAllowedUrls設定に追加します。次に、デフォルトのドキュメントのみが許可され、他のファイルは許可されないため、許可されるファイル拡張子を次のように設定します。これら2つのアイテムを配置するだけで、IISパイプラインの非常に早い段階でHTTP 404が返されます。リクエストはアプリケーションコードによって処理されませんでした。

<fileExtensions allowUnlisted="false">
    <clear/>
    <add fileExtension="." allowed="true" />
</fileExtensions>

FWIW、私は自分の blog に投稿していますIISリクエストフィルタリングのしきい値の定義についてです。まだ追加することがたくさんありますが、うまくいけば、それがあなたが始めるのに役立つでしょう。

2
user2320464

このパターンは fuzz ロジック/テストのように私に見えます。

理由は、インフラストラクチャをフィンガープリントすることです

および/または

さらに分解できるWebソフトウェアのバグを取得/発見

および/または

内部/顧客情報を盗むためにWebサイトで保護されていないリソースを見つけます。

ファズロジックの使用も、Webサイト/アプリでの有効なパスの検索に使用されているようです

追伸もちろん、これは最悪のシナリオですが、セキュリティ上、これは特定の問題を適切に評価する方法です

3
Romeo Ninov

これは、ユーザーがCookieを無効にしている場合に発生する可能性があるため、URLに情報を含めることにフォールバックします。

http://blog.syedgakbar.com/2013/02/asp-net-cookieless-session-and-absolute-urls/

1
AaronLS

一部のUNIXシステムでは、特にシステムがURLの書き換えなどを行うために何らかのスクリプトを使用している場合、エスケープされていない括弧をパス名で正しく処理しません。

「MVC」（System.Web.Mvcフレームワーク）の意味がわかりません。

IPの禁止を除いて、そのような調査を停止するためにあなたができることは何もありません。 Webサーバーを実行していた昔は、台湾全体をブロックする必要がありました（当時、中国のすべてのトラフィックが台湾を通過していたため）。

0
Tyler Durden