ASP.NET Pagemethods und JQuery AJAX Post - Wie sicher ist es wirklich?

Question

Ich habe ein folgendes Szenario - und was ich wirklich bin auf der Suche ist eine echte Hilfe von echten Menschen. Vorschläge / Lösungen? Bitte.

Ich habe eine Extranet-Website für ex. www.foo.com (asp.net 3.5) Ich benutze JQuery 1.3.2 ValidateLogin Pagemethods in default.aspx Seite (www.foo.com/default.aspx)

zu nennen

Der Code wird wie folgt aussehen

$.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();
            }
        });

Der Code wird in externen js-Datei gespeichert. Für die Ex-default.js.

Da diese Website öffentlich ist, kann jeder die default.js herunterladen und somit einen Blick auf Code oben angegebenen nehmen.

Meine Frage ist, wenn die Person, die diese URL bekommt: „Default.aspx / ValidateLogin“, wird er eine Anfrage an den Server und Server machen können mit Stolz auf die Anfrage antworten

.

Was sind meine Optionen hier? Wie validieren ich Anfrage? Wie verhindere ich, diese Art von unberechtigten Anfragen?

Answer 1

Web-Anfragen sind von ihrer Natur Öffentlichkeit. Sie brauchen nicht einmal in der Quelldatei zu suchen. Sie können einfach die HTTP-Anfragen überwachen und wiederholen diese Anfragen (es ist sehr einfach, mit einem Tool wie Fiddler zum Beispiel).

Problem mit Throttling

Die Drosselung Lösungen sind wirklich nicht lebensfähig, obwohl sie die Rate der Attacken reduzieren. Das Problem besteht darin, dass ein Angreifer ein Skript schreiben kann, die einen Kurs von Tagen laufen. Dann wieder, kann er Proxies parallel Anfragen zu senden. Und wenn Sie pro Benutzernamen drosseln sie die Gegner können DoS erreichen durch falsche Logins auf berechtigte Benutzernamen versuchen und wenn die tatsächliche Benutzer versucht, sich anzumelden, wird er nicht wissen, warum er gesperrt.

Lösung

Der typische Ansatz ist nonce Schlüssel zu verwenden. Es wird einige zusätzliche Arbeit erfordern, aber es wird das Problem zu mildern und es ist nur zu empfehlen, wenn Sie wirklich einen Ansturm von Angriffen oder etwas zu antizipieren. Eine vereinfachte Version davon würde der Kunde übergibt den Schlüssel nonce als URI-Abfrageparameter. Der Schlüssel wird vom Server an den Client an erster Stelle ausgestellt. Sobald der Antrag gestellt wurde, überprüft der Server die Nonce Schlüssel in der Datenbank vorhanden ist und erlaubt es, die Anfragen. Es löscht sofort die Nonce Schlüssel, damit der Benutzer keine andere Anforderung mit dem gleichen nonce Schlüssel machen kann, aber dann würde der Server benötigt mehr nonce Schlüssel für den Benutzer zu erteilen.

Die vereinfachte Lösung ist nur authentifizierten Benutzern zu ermöglichen, Web-Service-Anfragen zu machen, aber da Sie ein Login-System entwerfen dies offensichtlich klebt nicht.

Ich würde mir keine Sorgen, wenn Sie einige bösen Gegner haben.

Answer 2

Ich gehe davon aus Sie Ihrer Seite Methode ausgesetzt haben die Sitzung geladen, so dass ich glaube, dass Sie ein Session-Variable einstellen könnten, wenn die Seite geladen wird und dann prüfen, ob es vorhanden ist, wenn die Seite Methode aufgerufen wird. Es ist nicht die sicherste Sache der Welt, aber es hilft.

Persönlich würde ich nicht die Mühe versucht, es nicht mehr sicher zu machen - wie schon andere gesagt haben, ist Web-Service von Natur aus öffentlich

.

Answer 3

Ich würde sagen, es ist kein Problem; Allerdings wollen Sie wahrscheinlich einige Rate tun Begrenzung , damit die Leute nicht versuchen können, brute force es.

Answer 4

Sie können auch setzen ein Captcha nach etwa 2-3 Login Fehler, die Brute-Force vermeiden.