¿Cómo bloquear solicitudes HTTP externas? (asegurando llamadas AJAX)

Question

Quiero usar la publicación para actualizar una base de datos y no quiero que la gente lo haga manualmente, es decir, solo debería ser posible a través de AJAX en un cliente. ¿Hay algún truco criptográfico bien conocido para usar en este escenario?

Supongamos que estoy emitiendo una solicitud GET para insertar un nuevo usuario en mi base de datos al site.com/adduser/<userid>. Alguien podría sobrepoblar mi base de datos emitiendo solicitudes falsas.

Answer 1

No hay forma de evitar solicitudes falsificadas en este caso, ya que el navegador del cliente ya tiene todo lo necesario para realizar la solicitud; es solo cuestión de depurar para que un usuario malintencionado descubra cómo hacer solicitudes arbitrarias a su back-end, y probablemente incluso usar su propio código para hacerlo más fácil. No necesita "trucos criptográficos", solo necesita ofuscación, y eso solo hará que la falsificación sea un poco incómoda, pero no imposible.

Answer 2

Funciona como cualquier otra página web: autenticación de inicio de sesión, verifique la referencia.

Answer 3

Prevent Direct Access To File Called By ajax Function parece responder a la pregunta.

Usted puede (entre otras soluciones, estoy seguro) ...

• gestión de sesiones utilización (Iniciar sesión para crear una sesión);
• envíe una clave única al cliente que debe devolverse antes de que caduque (no se puede volver a utilizar y no se puede almacenar para usarla más adelante);
• y/o establezca encabezados como en la respuesta vinculada.

Pero cualquier cosa puede ser falsa si las personas se esfuerzan lo suficiente. El único sistema completamente seguro es uno al que nadie puede acceder en absoluto.

Answer 4

Este es el mismo problema que CSRF, y la solución es la misma: use un token en la solicitud AJAX que haya almacenado previamente en otro lugar (o puede regenerar, por ejemplo, encriptando los parámetros usando el ID de sessin como clave) Chriss Shiflett tiene algunas notas sensatas sobre esto, y hay un OWASP project para detectar CSRF con PHP

Answer 5

La solución es agregar la línea en negrita a las solicitudes ajax. También debes buscar autenticación básica, este no será el único protector. Usted puede coger los ingresos con estos código de la página ajax

Ajax llamada

function callit() 
{ 
if(window.XMLHttpRequest){xmlhttp=new XMLHttpRequest();}else{xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");} 
xmlhttp.onreadystatechange=function(){if(xmlhttp.readyState==4&&xmlhttp.status==200){document.getElementById('alp').innerHTML=xmlhttp.responseText;}} 
xmlhttp.open("get", "call.asp", true); 
**xmlhttp.setRequestHeader("X-Requested-With","XMLHttpRequest");** 
xmlhttp.send(); 
} 

PHP/ASP página solicitada respuesta

ASP

If Request.ServerVariables("HTTP_X-Requested-With") = "XMLHttpRequest" Then 
'Do stuff 
Else 
'Kill it 
End If 

PHP

if(isset($_SERVER['HTTP_X_REQUESTED_WITH']) && ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest')) 
{ 
//Do stuff 
} else { 
//Kill it 
} 

Answer 6

Realmente no necesito restringir el acceso al servidor (aunque sería genial), estoy buscando un truco criptográfico que permita al servidor saber cuándo las cosas provienen de la aplicación y no forjadas por el usuario usando una ficha olfateada

No puede hacer esto. Es casi uno de los problemas fundamentales con las aplicaciones cliente/servidor. He aquí por qué no funciona: supongamos que tiene una forma para que su aplicación cliente se autentique en el servidor, ya sea una contraseña secreta o algún otro método. La información que necesita la aplicación es necesariamente accesible para la aplicación (la contraseña está escondida en alguna parte, o lo que sea).Pero debido a que se ejecuta en la computadora del usuario, eso significa que también tienen acceso a esta información: todo lo que necesitan es mirar el origen, el binario o el tráfico de red entre su aplicación y el servidor, y eventualmente se darán cuenta el mecanismo por el cual su aplicación se autentica y la replica. Quizás incluso lo copien. Tal vez escriban un truco ingenioso para hacer que su aplicación haga el trabajo pesado (siempre puede enviar una entrada falsa del usuario a la aplicación). Pero no importa cómo, tienen toda la información necesaria, y no hay forma de evitar que la tengan, lo que tampoco evitaría que tu aplicación la tenga.

Answer 7

Este es un problema relacionado con la autorización: solo las solicitudes autorizadas deben dar lugar a la creación de un nuevo usuario. Por lo tanto, al recibir dicha solicitud, su servidor debe verificar si es de un cliente autorizado para crear nuevos usuarios.

Ahora el problema principal es cómo decidir qué solicitud está autorizada. En la mayoría de los casos, esto se realiza mediante roles de usuario y/o algún sistema de emisión de tickets. Con las funciones de usuario, tendrá problemas adicionales para resolver, como identificación de usuario y autenticación de usuario. Pero si eso ya está resuelto, puede asignar fácilmente los usuarios a roles como Alice es un administrador y Bob es un usuario normal y solo los administradores están autorizados a crear nuevos usuarios.

Answer 8

Se puede lograr.
Siempre que represente una página que se supone que debe realizar dicha solicitud. Genere un token aleatorio y guárdelo en sesión (para el usuario autenticado) o en la base de datos (en caso de que esta solicitud esté permitida públicamente).
y en lugar de llamar site.com/adduser/<userid> llamada site.com/adduser/<userid>/<token>
siempre que reciba dicha solicitud si el token es válido o no (de la sesión o base de datos)
En señal caso es correcto, el proceso de la solicitud y eliminar símbolo usado de la sesión/db
En caso de que el token sea incorrecto, rechace la solicitud.