Asegurar las solicitudes AJAX a través de GUID

Question

Estoy escribiendo una aplicación web que realizará solicitudes a través de AJAX y desea bloquear esas llamadas. Después de un poco de investigación, estoy considerando usar algún tipo de token (cadena) aleatorio para pasar junto con la solicitud (¿GUID?). Aquí están las partes importantes de mi algoritmo:

1. Asigne un token a una variable de JavaScript (servidor generado).
2. Además, almacene ese token en un DB y asígnele un período de tiempo válido (es decir, 10 minutos).
3. Si el token aún no se ha utilizado y se encuentra dentro de su ventana de tiempo válida, permita la llamada.
4. Devuelva la información solicitada si es válida; de lo contrario, registre la solicitud e ignórela.

Con miras a la seguridad, ¿tiene sentido esto? Para el token, ¿funcionaría un GUID? ¿Debería ser algo más? ¿Hay una buena manera de encriptar variables en la solicitud?

EDIT:

entiendo que estas peticiones AJAX no serían verdaderamente "seguras", pero me gustaría añadir seguridad básica en el sentido de que me gustaría evitar que otros utilicen el servicio que pretendo escribir. Este token aleatorio sería una defensa básica de primera línea contra llamadas abusivas. Los datos que se solicitarían (e incluso se enviarían para generar dichos datos) tendrían ALTAS probabilidades de repetirse.

Tal vez estoy equivocado al usar un GUID ... ¿Qué tal una cadena generada al azar (token)?

Answer 1

Si está haciendo esto para confiar en el código que envió al navegador del cliente, cambie la dirección. Realmente no quiere confiar en la entrada del usuario, que incluye las llamadas de js que envió al navegador. La lógica en el servidor se debe hacer para que no se pueda hacer nada incorrecto allí. Dicho esto, asp.net utiliza un campo firmado, es posible que desee ir por ese camino si es absolutamente necesario.

Expandiendo un poco: Asp.net a prueba de manipulaciones el viewstate, que se envía como un campo oculto html (dependiendo de la configuración). Estoy seguro de que hay mejores enlaces como referencia, pero al menos se menciona en este: http://msdn.microsoft.com/en-us/library/ms998288.aspx

validación. Esto especifica el algoritmo hash utilizado para generar HMACs en para hacer que ViewState y formularios autentiquen tickets a prueba de falsificaciones. Este atributo también se usa para especificar el algoritmo de cifrado utilizado para el cifrado ViewState . Este atributo soporta las siguientes opciones:

• SHA1-SHA1 se utiliza a prueba de manipulaciones ViewState y, si está configurado, el vale de autenticación formas. Cuando se selecciona SHA1 para el atributo de validación , el algoritmo utilizado es HMACSHA1.

Un enlace para la clase .NET para ese algoritmo http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx.

Actualización 2: Para protección contra falsificaciones, debe firmar los datos (no cifrarlos). Tenga en cuenta que al usar la criptografía en general, realmente debería evitar el uso de una implementación personalizada o algoritmo. En cuanto a los pasos, me quedaría con:

• Asigne un token a una variable de JavaScript (servidor generado). Incluye información para identificar la solicitud y la fecha exacta & hora en que se emitió. La firma validará la aplicación del servidor emitió los datos.
• Identifique los envíos dobles si corresponde.

Dicho esto, el motivo por el cual asp.net valida el viewstate de forma predeterminada, se debe a que los desarrolladores confían en que la información que ingrese allí será manejada solo por la aplicación cuando no deberían hacerlo. Lo mismo aplica probablemente para su escenario, no confíe en este mecanismo. Si desea evaluar si alguien puede hacer algo, use autenticación + autorización. Si desea saber que la llamada ajax está enviando solo opciones válidas, valídelas. No exponga una API en un nivel de granularidad que no sea aquel en el que pueda autorizar adecuadamente las acciones. Este mecanismo es solo una medida extra, en caso de que algo resbale, no es una protección real.

Ps. con el HMACSHA1 anterior, lo instanciaría con una clave fija

Answer 2

"Asegurar" es un término vago. ¿Qué estás tratando de lograr exactamente? El uso de un GUID es una excelente manera de evitar envíos duplicados de la misma solicitud, pero eso es todo.

Si la información que se pasa entre el cliente y el servidor es realmente confidencial, debe hacerlo a través de HTTPS. Esa es realmente la única respuesta en lo que respecta a asegurar la comunicación real.

Editar: Para responder a su pregunta con respecto a si un GUID es el camino "correcto", no hay una forma correcta de hacer lo que está sugiriendo. Usar cualquier token, ya sea un GUID o algo de tu propia creación, no tendrá ningún otro efecto que evitar la duplicación de envíos de la misma solicitud. Eso es.

Answer 3

Realmente depende de lo que está tratando de lograr por seguridad. Si se refiere a evitar el uso no autorizado de los puntos finales HTTP, hay muy poco que puede hacer al respecto, ya que el usuario tendrá acceso completo al HTML y JavaScript utilizados para realizar las llamadas.

Si se refiere a evitar que alguien detecte los datos en las solicitudes AJAX, simplemente usaría SSL.

Un GUID utilizado en la forma que sugiere es, en realidad, reinventar una cookie de identificación de sesión.