57
¿Es POST lo suficientemente seguro para enviar las credenciales de inicio de sesión?¿Qué tan seguro es un HTTP POST?
O es una conexión SSL a debe?
A
Respuesta
69
SSL es una necesidad. POST no es más seguro que GET ya que también se envía sin cifrar. SSL cubrirá toda la comunicación HTTP y encriptará el envío de datos HTTP entre el cliente y el servidor.
+6
A debe? Para un foro de fans de My Little Pony? ¿Se requiere un terminal blindado de perdices nivales, un cifrado cuántico y una línea arrendada probada? –
+12
@mgb: ¿Arrendado? Tienes que estar bromeando. Si no posee el cobre durante todo el proceso, ¿cómo puede estar seguro de que es seguro? –
+108
Sí, porque las personas usan la misma contraseña para el foro de admiradores de My Little Pony y su cuenta bancaria. – erickson
5
SSL es un :) debe
HTTP Post se transmite en texto plano. Por ejemplo, descarga y usa Fiddler para ver el tráfico HTTP. Puede ver fácilmente la publicación completa allí (o a través de un monitor de tráfico de red como WireShark)
2
No ... POST no es lo suficientemente seguro. SSL es IMPRESCINDIBLE.
POST solo oculta eficazmente los parámetros en la cadena de consulta. Esos parámetros aún pueden ser recogidos por cualquiera que mire el tráfico entre el navegador y el punto final.
4
No es seguro. Un POST puede ser olido tan fácilmente como un GET.
8
Eso depende de sus circunstancias, ¿cuánto le costaría la interceptación de las credenciales a alguien?
Si es solo un inicio de sesión en un sitio de software Q + A, entonces SSL podría no ser necesario, si es un sitio de banca en línea o almacena datos de tarjetas de crédito, entonces sí lo es.
Esta es una decisión comercial, no técnica.
+12
downvoted porque las personas reutilizan las contraseñas. – Malfist
+1
Malfist: las personas reutilizan contraseñas todo el tiempo, pero si interceptas una contraseña aleatoria, ¿sabes dónde más usarla? – TheTXI
+2
si está escuchando tráfico para obtener credenciales, puede ver cualquier sitio que el usuario visite. SSL no oculta la dirección, solo los datos – Jim
1
POST es texto sin formato.
Una conexión segura es una necesidad.
Es por eso que se llama conexión segura.
0
Una solicitud POST sola no es segura porque todos los datos están "viajando" en texto sin formato.
Necesita SSL, para que sea seguro.
1
No, utilice SSL.
Con POST, los valores se siguen enviando como texto sin formato a menos que se use SSL.
0
Los datos POST se envían en texto sin formato si está utilizando una conexión HTTP no encriptada. SI esto es lo suficientemente seguro depende de su uso (pista: no lo es).
Si el servidor, la máquina del cliente y TODAS LAS MÁQUINAS ENTRE ELLOS son parte de una red controlada y totalmente confiable, esto puede estar bien.
Fuera de estas circunstancias tan limitadas (y, a veces, incluso dentro de ellas) la autenticación de texto sin formato está buscando problemas.
1
La única diferencia entre HTTP GET y HTTP POST es la forma en que se codifican los datos. En ambos casos, se envía como texto sin formato.
Con el fin de proporcionar cualquier tipo de seguridad para las credenciales de inicio de sesión, HTTPS es una necesidad.
No necesita un certificado caro para proporcionar HTTPS tampoco.Hay muchos proveedores que emitirán certificados muy básicos por alrededor de $ 20USD. Los más caros incluyen la verificación de identidad, que es más una preocupación para los sitios de comercio electrónico.
+0
Eddy Nigg's [Startcom] (https://www.startcom.org/) emitirá un certificado para [gratis] (https://www.startssl.com/?app=25#90). Sus certificados son de confianza para [la mayoría de los navegadores] (https://www.startssl.com/?app=40). Cobran por revocación porque ahí es donde radica la mayor parte del costo. – jww
-3
Depende de dónde lo está usando y qué tan seguro realmente lo necesita.
No hay manera de que alguien obtener los datos enviados que envía desde su casa a menos que esté utilizando un proxy (TOR) o alguien está aprovechando sus cables.
Sin embargo, si le preocupa que alguien va a iniciar la sesión utilizando una red no segura inalámbrica, que SSL es importante.
Si usted es un banco, ni siquiera se puede tomar ese riesgo. Si es un techer con inicios de sesión para ver asignaciones, entonces debería estar bien
+0
Perdón por -1, pero ¿cómo podría ser "imposible que alguien" vea los datos entre el hogar y un servidor? –
+0
Por favor, explique. Esta publicación se está haciendo a SO desde la computadora de mi casa. Incluso suponiendo que usted, Ilya, supiera las direcciones IP de mi (y SO), aún no podría interceptar los datos que he publicado en SO. No puedes saber qué hay a menos que puedas interceptarlo. [Y a menudo, cuando puedes interceptarlo, una conexión SSL no ayudará.] Si crees que esto es un error, pruébalo. – SamGoody
+1
@SamGoody Esto demuestra una completa ignorancia de lo que es un ataque de hombre en el medio y cómo SSL lo previene. Sé que este es un comentario antiguo y es posible que ya no refleje tu comprensión actual; si ese es el caso, debes eliminarlo y eliminar esta respuesta, ya que ambos son completamente incorrectos. – meagar
6
HTTP POST no está encriptado, puede ser interceptado por un sniffer de red, por un proxy o filtrado en los registros del servidor con un mensaje personalizado nivel de registro Sí, POST es mejor que conseguir porque los datos POST es no usualy conectado por un proxy o servidor, pero no es seguro . Para proteger una contraseña u otra información confidencial, debe usar SSL o cifrar los datos antes de PUBLICAR. Otra opción sería usar autenticación implícita con el navegador (ver RFC 2617). Recuerde que el cifrado (de cosecha propia) no es suficiente para evitar los ataques de repetición, debe concatenar un nonce y otros datos (por ejemplo, el reino) antes de cifrar (consulte RFC 2617 para ver cómo se hace en Digest Auth).
+0
+1 para observar las diferencias en el registro –
2
La forma más segura es no enviar las credenciales.
Si usa Digest Authentication, entonces SSL es NO imprescindible.
(NB: No quiero decir que la autenticación implícita a través de HTTP es siempre más seguro que usar la POST a través de HTTPS).
36
<shameless plug> Tengo un blog post que detalla cómo se ve una solicitud HTTP y cómo una solicitud GET se compara con una solicitud POST. Por razones de brevedad, GET:
GET /?page=123 HTTP/1.1 CRLF
Host: jasonmbaker.wordpress.com CRLF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF
Connection: close CRLF
y POST:
POST/HTTP/1.1 CRLF
Host: jasonmbaker.wordpress.com CRLF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF
Connection: close CRLF
CRLF
page=123
(El CRLF es sólo un salto de línea)
Como se puede ver, las únicas diferencias con el punto de vista de cómo una solicitud se forma * es que una solicitud POST utiliza la palabra POST y los datos del formulario se envían en el cuerpo de la solicitud frente al URI. Por lo tanto, usar HTTP POST es seguridad por oscuridad. Si desea proteger los datos, debe usar SSL.
* Nota que hay are other differences.
0
Consulte este gran artículo:
proteger contra el malicioso ingrese requerimientos de
Cuestiones relacionadas
- 1. ¿Qué tan seguro es PHP?
- 2. ¿Qué tan seguro es javax.crypto.Cipher?
- 3. ¿Es seguro un POST de HTTP a HTTPS?
- 4. ¿Qué tan seguro es $ _SERVER ["HTTP_HOST"]?
- 5. PHP Mcrypt, ¿qué tan seguro es realmente?
- 6. ¿Qué tan seguro es usar document.body.innerHTML.replace?
- 7. ¿Qué tan seguro es ProtectedData.Protect (DPAPI)?
- 8. ¿Qué tan seguro es actualizar la base?
- 9. ¿Qué tan seguro es usar Maven?
- 10. ¿Qué tan seguro es `UnsafePerformIO (newTVarIO 0)`?
- 11. ¿Qué tan seguro es Spring Security?
- 12. Captcha alternativa, ¿qué tan seguro?
- 13. ¿Qué tan seguro es un AppDomain con sandboxed con SecurityPermissionFlag.Execution?
- 14. ¿Qué tan seguro es php curl en ssl/https?
- 15. ¿Http POST es ilimitado?
- 16. ¿Qué es un HTTP POST multiparte y cómo hacerlo? (scribd)
- 17. ¿Qué tan seguro es "git" con una conexión no confiable?
- 18. https URL con el parámetro token: ¿qué tan seguro es?
- 19. ¿Qué tan seguro es SQLite WAL en fallas de energía?
- 20. ¿Qué tan seguro es almacenar la sesión con Redis?
- 21. ¿Qué tan seguro es el filtrado de la dirección IP?
- 22. ¿Qué tan seguro es el thread enum en java?
- 23. ¿Qué tan seguro es apache Commons-javaflow mientras usa jasperreports
- 24. ¿Qué tan seguro es el marco de membresía de ASP.NET?
- 25. ¿Qué tan seguro es usar enlaces `// domain.com /` (sin esquema)?
- 26. ¿Qué tan seguro para los hilos es V4L2?
- 27. ¿Qué tan seguro es el modo seguro de MongoDB en los insertos?
- 28. ¿Qué tan caro es lanzar un objeto?
- 29. ¿Por qué el verbo HTTP POST se llama POST?
- 30. ¿Qué tan aleatorio es urandom?
vea la pregunta anterior (http://stackoverflow.com/questions/1008539/how-secure-is -a-http-get-when-the-data-is-url-encoded). –
Hola Matt, antes de preguntar, sí, necesitas hash la contraseña de inicio de sesión que almacenas en el servidor. – erickson
Creo que es una pregunta seria. Mira las otras preguntas de Matt y verás que probablemente sea un novato, de ahí la pregunta aparentemente ingenua. – JohnFx