Usando HTTPS GET de la aplicación al servidor

El punto sobre "GET destructivo" es que los atacantes pueden hacer que algunos usuarios víctimas envíen de forma involuntaria tales solicitudes "GET". Esto es simple: el atacante solo tiene que incluir, en el sitio web his , una etiqueta <img> que apunta a la URL de destino. El navegador de la víctima luego realizará el GET fatídico.

Que las solicitudes normales provienen de una aplicación, y no de un navegador, no cambia este hecho. El problema no es de donde provienen las solicitudes normales, sino lo que pueden hacer las solicitudes anormales .

Lo que podría imaginar es hacer que su aplicación agregue algunos encabezados HTTP específicos de la aplicación, que el servidor verifica, y que un navegador web básico no se configuraría en un GET normal. Pero entonces, realmente ya no tienes un "GET normal". Parece más simple, más seguro y menos intrépido usar simplemente las solicitudes POST para cualquier cosa que pueda ser destructiva (incluidas las actualizaciones de datos ); o, aún más simple, las solicitudes POST para todo . Si el cliente es una aplicación personalizada, no debería tener ninguna razón para preferir las solicitudes GET a POST.

Solo para agregar a la respuesta de Thomas Pornin, las solicitudes GET están sujetas al almacenamiento en caché por parte de los servidores proxy, por lo que no puede garantizar al 100% que una solicitud GET llegará al servidor de destino y no obtendrá la respuesta de un proxy. Sí, puede agregar encabezados para especificar que no habrá almacenamiento en caché, pero no todos los proxy cumplen con las reglas. ¿No es más fácil utilizar las mejores prácticas y POSTAR sus actualizaciones? No puedo ver por qué querría usar GET (aparte de la pereza). Al utilizar POST, informa a todo (navegador / proveedor HTTP, proxy y servidor) que la solicitud realiza un cambio "destructivo" y debe garantizar que su solicitud se realice de manera adecuada sin la necesidad de administrar los encabezados de solicitud.

Además, es menos probable que las solicitudes POST tengan parámetros registrados, por lo que cualquier parámetro sensible en la cadena de consulta en un GET no es probable que se almacene fuera del control de la aplicación, como en los registros de proxy o servidor (por ejemplo, tokens) cuando se realizan en el cuerpo POST en su lugar. Nuevamente, esto no está garantizado, pero al utilizar el método de solicitud adecuado, está insinuando la intención de la solicitud.

Agregando a la respuesta de Thomas, siempre debes recordar hacer que tu aplicación verifique el certificado recibido en el saludo de SSL.

Es su trabajo, como desarrollador móvil, verificar correctamente si el certificado es válido (si su servidor usa uno autofirmado, asegúrese de incluirlo dentro de la aplicación), o sus usuarios serán propensos a < a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack"> ataques MITM y las cosas MALAS tienden a suceder en esos escenarios. Los usuarios aman el wifi gratis ...