rest - solicitudes - ¿Cuál es la diferencia entre HTTP-Get y HTTP-POST y por qué HTTP-POST es más débil en términos de seguridad?
solicitudes get y post (5)
¿Alguien puede explicar la diferencia entre HTTP-GET y HTTP-POST? ¿Y por qué la gente dice que HTTP-POST es más débil en términos de seguridad?
Algunas notas sobre solicitudes GET:
- Las solicitudes GET pueden almacenarse en caché
- Las solicitudes GET permanecen en el historial del navegador
- Las solicitudes GET se pueden marcar
- Las solicitudes GET nunca se deben usar cuando se trata de datos confidenciales
- Las solicitudes GET tienen restricciones de longitud
- Las solicitudes GET deben usarse solo para recuperar datos
Algunas notas sobre solicitudes POST:
- Las solicitudes POST nunca se almacenan en caché
- Las solicitudes POST no permanecen en el historial del navegador
- Las solicitudes POST no pueden ser marcadas
- Las solicitudes POST no tienen restricciones en la longitud de los datos
(Fuente: Escuelas W3)
El método GET está destinado solo a la recuperación de datos y no debe tener ningún efecto secundario . Pero POST está destinado a ese propósito específico: alterar datos en el lado del servidor.
Las solicitudes GET se pueden predecir fácilmente (consulte Falsificación de solicitudes entre sitios ) simplemente colocando una imagen en una página mientras que falsificar solicitudes POST no es tan fácil (esta es también una razón por la que solo debe permitir solicitudes POST autorizadas).
En una solicitud HTTP GET, los pares clave / valor se especifican en la URL:
http://server/something?value1=foo&value2=bar
.
En una solicitud HTTP POST, los pares clave / valor se envían como parte de la solicitud HTTP después de los encabezados. Por ejemplo:
POST /something HTTP/1.1 Host: server Content-Length: 21 Content-Type: application/x-www-form-urlencoded value1=foo&value2=bar
Es difícil describir uno como más o menos seguro que el otro, pero los datos HTTP POST no son visibles en la URL, y cuando se envían datos a un sitio web, HTTP POST generalmente solo se puede realizar como resultado de la interacción del usuario ( por ejemplo, hacer clic en el botón "Enviar").
Esto significa que no se puede engañar a un usuario para que visite una URL como http://server/update_profile?name=I_suck
y los datos confidenciales no se exponen en la URL.
También puede usar nonces y otros tokens nonces con formularios html (que usan POST) para evitar otras formas de falsificaciones de solicitudes entre sitios.
En general, POST se debe usar para solicitudes que potencialmente modifiquen el estado en el servidor, y GET se debe usar para operaciones de solo lectura.
La especificación HTTP diferencia POST y GET en términos de su intención:
GET es idempotente: es para obtener un recurso, sin cambiar nada en el servidor. Como consecuencia, debería ser perfectamente seguro volver a enviar una solicitud GET.
POST no lo es: sirve para actualizar la información en el servidor. Por lo tanto, no puede suponerse que es seguro volver a enviar la solicitud, razón por la cual la mayoría de los navegadores piden confirmación cuando pulses actualizar en una solicitud POST.
En términos de seguridad, no hay diferencia. POST es más oscuro, tal vez, pero eso es algo muy diferente. La seguridad debe agregarse en otra capa, por ejemplo, SSL.
No llamaría a POST más o menos seguro que GET. Es cierto que los parámetros se muestran como parte de la URL cuando se utiliza GET, por lo que cualquier dato sensible será inmediatamente visible para el usuario. Sin embargo, es trivial ver e incluso cambiar cualquier parte de la solicitud HTTP, por lo que simplemente porque POST no pasa los datos a través de la URL, todavía se puede leer fácilmente. A menos que esté usando HTTPS, tanto GET como POST transferirán datos en un formulario de fácil acceso.