ASP.NET PageMethods y JQuery AJAX Post & # 8211; ¿Qué tan seguro es realmente?

Question

Tengo un escenario siguiente & # 8211; y lo que realmente estoy buscando es la ayuda real de personas reales. Sugerencias / Soluciones? Por favor.

Tengo un sitio web extranet por ej. www.foo.com (asp.net 3.5) Estoy utilizando JQuery 1.3.2 para llamar a ValidateLogin PageMethods en la página default.aspx (www.foo.com/default.aspx)

El código se verá así

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

El código se almacena en un archivo js externo. Para ex default.js.

Dado que este sitio web es público, cualquiera puede descargar el archivo default.js y, por lo tanto, puede echar un vistazo al código indicado anteriormente.

Mi pregunta es una vez que la persona recibe este URL: " Default.aspx / ValidateLogin " ;, puede hacer una solicitud al servidor y el servidor responderá con orgullo a la solicitud.

¿Cuáles son mis opciones aquí? ¿Cómo valido la solicitud? ¿Cómo puedo evitar este tipo de solicitudes no autorizadas?

Answer 1

Las solicitudes web son por su propia naturaleza, públicas. Ni siquiera necesitan mirar el archivo fuente. Simplemente podrían monitorear las solicitudes HTTP y reproducirlas (es muy fácil con una herramienta como Fiddler, por ejemplo).

Problema con la limitación

Las soluciones de limitación realmente no son viables, aunque reducirán la tasa de ataques. El problema es que un adversario puede escribir una secuencia de comandos que se ejecuta en un transcurso de días. Por otra parte, puede usar proxies para enviar solicitudes paralelas. Y si acelera por nombre de usuario, el adversario puede lograr DoS al intentar inicios de sesión falsos en nombres de usuario legítimos y cuando el usuario real intenta iniciar sesión, no sabrá por qué está bloqueado.

Solución

El enfoque típico es utilizar claves de nonce. Requerirá un poco de trabajo extra, pero mitigará el problema y solo se recomienda si realmente anticipa una avalancha de ataques o algo así. Una versión simplificada de esto haría que el cliente pase la clave de nonce como un parámetro de consulta URI. La clave es emitida por el servidor al cliente en primer lugar. Una vez que se ha realizado la solicitud, el servidor valida la clave de nonce que existe en la base de datos y permite las solicitudes. Inmediatamente elimina la clave de nonce para que el usuario no pueda realizar otra solicitud con la misma clave de nonce, pero entonces el servidor tendría que emitir más claves de nonce para el usuario.

La solución simplificada es permitir que solo los usuarios autenticados realicen solicitudes de servicio web, pero como está diseñando un sistema de inicio de sesión, esto obviamente no se mantiene.

No me preocuparía por eso a menos que tengas algunos adversarios desagradables.

Answer 2

Supongo que ha expuesto que su método de Página carga la sesión, por lo que supongo que podría establecer una variable de sesión cuando se cargue la página y luego verificar si existe cuando se llama al método de página. No es la cosa más segura del mundo, pero ayudará.

Personalmente, no me molestaría en intentar hacerlo más seguro, como han dicho otros, los servicios web son intrínsecamente públicos.

Answer 3

Yo diría que no hay problema; Sin embargo, es probable que desee hacer algo de Limitación de tarifas para que la gente no pueda probar Bruto forzándolo.

Answer 4

También puede poner un captcha después de, por ejemplo, 2-3 fallos de inicio de sesión que evitarán la fuerza bruta.