ASP.NET PageMethods e JQuery AJAX Post & # 8211; Quanto è davvero sicuro?

Question

Ho uno scenario seguente & # 8211; e quello che cerco davvero è il vero aiuto di persone vere. Suggerimenti / soluzioni? Per favore.

Ho un sito Web Extranet per es. www.foo.com (asp.net 3.5) Sto usando JQuery 1.3.2 per chiamare ValidateLogin PageMethods nella pagina default.aspx (www.foo.com/default.aspx)

Il codice sarà simile a questo

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

Il codice è memorizzato in un file js esterno. Per ex default.js.

Poiché questo sito Web è pubblico, chiunque può scaricare default.js e quindi può dare un'occhiata al codice sopra indicato.

La mia domanda è una volta che la persona riceve questo url: " Default.aspx / ValidateLogin " ;, può fare una richiesta al server e il server risponderà con orgoglio alla richiesta.

Quali sono le mie opzioni qui? come convalidare la richiesta? Come posso evitare questo tipo di richieste non autorizzate?

Answer 1

Le richieste Web sono per loro stessa natura pubbliche. Non hanno nemmeno bisogno di guardare il file sorgente. Potrebbero semplicemente monitorare le richieste HTTP e riprodurre quelle richieste (è molto facile con uno strumento come il violinista per esempio).

Problemi con la limitazione

Le soluzioni di limitazione non sono realmente praticabili sebbene ridurranno il tasso di attacchi. Il problema è che un avversario può scrivere uno script che dura più giorni. Inoltre, può utilizzare i proxy per inviare richieste parallele. E se si accelera per nome utente, l'avversario può raggiungere il DoS tentando accessi falsi su nomi utente legittimi e quando l'utente effettivo tenta di accedere, non saprà perché è bloccato.

Soluzione

L'approccio tipico è usare chiavi nonce. Richiederà un po 'di lavoro extra ma mitigherà il problema ed è consigliato solo se prevedi davvero un assalto di attacchi o qualcosa del genere. Una versione semplificata di ciò consentirebbe al client di passare la chiave nonce come parametro di query URI. La chiave viene emessa dal server al client in primo luogo. Una volta effettuata la richiesta, il server convalida la chiave nonce presente nel database e consente le richieste. Elimina immediatamente la chiave nonce in modo che l'utente non possa effettuare un'altra richiesta con la stessa chiave nonce, ma il server dovrebbe emettere più chiavi nonce per l'utente.

La soluzione semplificata è consentire solo agli utenti autenticati di effettuare richieste di servizi Web, ma poiché si sta progettando un sistema di accesso questo ovviamente non si attacca.

Non me ne preoccuperei se non avessi degli avversari cattivi.

Answer 2

Suppongo che tu abbia esposto il tuo metodo Page caricando la sessione, quindi suppongo che potresti impostare una variabile di sessione quando la pagina viene caricata e quindi verificare se esiste quando viene chiamato il metodo page. Non è la cosa più sicura al mondo, ma aiuterà.

Personalmente non mi preoccuperei di provare a renderlo più sicuro: come altri hanno già detto, i servizi web sono intrinsecamente pubblici.

Answer 3

Direi che non ci sono problemi; Tuttavia, probabilmente vorrai fare un po 'di Limitazione della tariffa in modo che le persone non possano provare bruta forzandolo.

Answer 4

Puoi anche mettere un captcha dopo dire 2-3 errori di accesso che eviteranno la forza bruta.