ASP.NET PageMethodsおよびJQuery AJAX Post＆＃8211;本当に安全なのでしょうか？

StackOverflow https://stackoverflow.com/questions/812945

質問

次のシナリオがあります＆＃8211;そして私が本当に探しているのは、実在の人々からの真の助けです。提案/ソリューション？お願いします。

私はexのエクストラネットWebサイトを持っています。 www.foo.com（asp.net 3.5） JQuery 1.3.2を使用して、default.aspxページ（www.foo.com/default.aspx）でValidateLogin PageMethodsを呼び出しています

コードは次のようになります

$.ajax({
            type: "POST",
            contentType: "application/json; charset=utf-8",
            dataType: "json",
            url: "Default.aspx/ValidateLogin",
            data: '{' + arg + '}',
            success: function(data) {
                if (data.d != 0) {
                    window.location = "http://www.google.com";
                } else {
                    alert("Invalid UserName/Password.");
                    ResetLoginForm();
                }
            },
            error: function(xhr, status, error) {
                var strerror = xhr.status + error;
                alert("Error Communicating with Server:" + strerror);
                ResetLoginForm();
            }
        });

コードは外部jsファイルに保存されます。 ex default.jsの場合。

このWebサイトは公開されているため、誰でもdefault.jsをダウンロードでき、上記のコードを見ることができます。

私の質問は、ユーザーがこのURL「＆quot; Default.aspx / ValidateLogin＆quot;」を取得すると、サーバーにリクエストを送信でき、サーバーがそのリクエストに誇らしげに応答することです。

ここでの私のオプションは何ですか？リクエストを検証するにはどうすればよいですか？この種の不正なリクエストを防ぐにはどうすればよいですか？

役に立ちましたか？

解決

Webリクエストは本来、パブリックです。ソースファイルを見る必要すらありません。 HTTPリクエストを監視し、それらのリクエストを再生するだけです（たとえば、フィドラーなどのツールを使用すると非常に簡単です）。

スロットルの問題

スロットリングソリューションは、攻撃の割合を減らしますが、実際には実行できません。問題は、敵が数日間にわたって実行するスクリプトを作成できることです。次に、プロキシを使用して並列リクエストを送信できます。また、ユーザー名ごとに調整すると、攻撃者は正当なユーザー名で偽のログインを試みることでDoSを達成でき、実際のユーザーがログインしようとすると、ロックアウトされた理由がわかりません。

解決策

典型的なアプローチは、ナンスキーを使用することです。追加の作業が必要になりますが、問題は軽減され、攻撃などの猛攻撃が本当に予想される場合にのみ推奨されます。これを簡略化したバージョンでは、クライアントはURIクエリパラメータとしてnonceキーを渡します。キーは、最初にサーバーからクライアントに発行されます。要求が行われると、サーバーはデータベースにナンスキーが存在することを検証し、要求を許可します。ナンスキーはすぐに削除されるため、ユーザーは同じナンスキーで別のリクエストを行うことはできませんが、サーバーはユーザーにさらにナンスキーを発行する必要があります。

単純化された解決策は、認証されたユーザーのみがWebサービスリクエストを行うことを許可することですが、ログインシステムを設計しているためこれは明らかに固執しません。

悪意のある敵がいなければ心配しません。

他のヒント

セッションをロードするPageメソッドを公開していると想定しているため、ページのロード時にセッション変数を設定し、ページメソッドの呼び出し時にセッション変数が存在するかどうかを確認できると思います。これは世界で最も安全なものではありませんが、役立ちます。

個人的には、これ以上安全にしようとはしません-他の人が言ったように、Webサービスは本質的に公開されています。

問題はないと思います。ただし、レート制限を実行して、強引に強制する。

また、2〜3回ログインに失敗した後、ブルートフォースを回避するためにキャプチャを追加することもできます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top