5.1.1. —perdido, buscando el diseño ideal

Cierto sitio (argentino) de contactos personales??
Cual, cual, cual??

La página de CTI hace lo mismo en la sección para enviar mensajes a celulares (pasa el número y el mensaje en la URL).

Gracias al autocompletar le hemos hecho unas joditas (sanas) a compañeros desprevenidos de laburo

Uhhh, esos ya se fueron al canio!

Se me ocurre que lo mas probable es que sea un sitio viejo, que este usando variables globales y no hayan definido el parametro method en el form… Si no es eso, es idiotez nomas

Gance: Tenés tres pistas. Es de contactos, es argentino (usan dominio .ar) y si me conoces lo suficiente, tenes un dato más.
Diego: Para colmo, la paginación está hecha en Javascript —cada enlace activa una función que envia el número de página. Sumado a eso, está hecho de una manera en que la URL nunca cambia (el número de página no se muestra en la query string), entonces recargar la página implica volver a la primer página de resultados.

en este caso no veo que tenga algo de malo usar GET, siempre y cuando tengas un sistema anti-bruteforce… sino me ekivoko, todo keda solucionado al encriptar los datos de usuario con md5 no?…

eso de usar GET en las páginas de formulario es muy útil, ya que por ejemplo, permites busquedas “pre-cocinadas” que se pueden mostrar en el formulario permitiendo modificarlas antes de que se enviasen,,, además potencias tu aplicación al permitir, por ejemplo, crear contenidos de una manera “both”,,, eso sí, como ya dije, con un sistema anti-bruteforce ó algo por el estilo…

a por cierto,, se me olvido decir que algo más para tapar ese hueco es usar las cabeceras de no-cache…

estoy abierto a correciones

imm.vxk: Sí, podrías mostrarlo en la medida que la contraseña esté encriptada con algo mejor que sólo MD5 (según los artículos anteriormente enlazados). Y no digo que usar GET sea siempre malo —Google usa GET— sino que para estos casos de autentificación termina siendo inseguro —algunas API públicas aceptan autenficación con GET enviando los datos como parametros sin encriptar; por ejemplo, la de FeedBurner según FeedBurner Developers: HTTP Parameter Authentication.

oooH!

SSL+POST de entrada … de ahi en adelante que hagan lo que deben.

Si bien GET y POST son idempotentes, según las especificaciones POST debería ser usado cuando se modifican datos en el servidor … y un update del valor last_login es suficiente para satisfacer qué método elegir en el caso de un login.

También mencionan que GET pregunta y POST ordena. Aplicado a este caso sería “logueame!” en vez de “¿me logueás?”

http://www.w3.org/2001/tag/doc/whenToUseGet.html

Quizás no sea idiotez sino mera ignorancia

Federico, mil gracias por la mención.

Juan: Me dejaste pensando en la utilidad real de POST, porque éste envia los datos en una forma estandarizada apenas modificada en base64. O sea que, si no me equivoco, o mostras (a través de GET o POST) la clave encriptada (como dije antes) o usas SSL (como decis vos).
Pero, ¿para SSL no tenés conseguir un certificado? Y llegado el caso, no encuentro el dato de cuanto puede costar (en todo sentido) conseguir uno.
Al magen, te mencioné porque el artículo es bueno, porque complementa lo que escribió Diego, y porque los tres artículos me recordaron este incidente con el sitio —que no ha tomado precauciones a pesar de mi aviso.

Siguiendo la línea de Juan, “GET pregunta y POST ordena”, la autenticación SIEMPRE debe hacerse a través de POST, y mas allá de si la comunicación es encriptada o no, los datos se validan en el servidor y nunca se le revelan al usuario.

Las contraseñas SIEMPRE deben encriptarse, en lo posible usando una combinación de algoritmos o un “salt”, pero NUNCA pueden ser almacenadas en texto plano.

Con respecto a SSL, encriptar la comunicación, significa no solo un costo económico (certificado) sino un costo tecnológico enorme ya que todos los datos que pasan por SSL son previamente encriptados con un algoritmo complejo, tenes que justificar que los datos lo merezcan.

marcoss: Estamos hablando de un sitio que permite el pago para funciones avanzadas, así que no es una opción que alguien más use tus datos. Claro que también hay que tener en cuenta que hablamos de un sitio que apenas llega a fin de mes con sus suscriptores, así que, al menos, podrían encriptar sus claves y evitar GET (según lo que se viene diciendo).

En cuanto a los datos de login enviados por GET ya de entrada son cacheados por el historial del browser, de ahi el problema de que un vecino, pariente o spyware puedan obtener fácilmente los datos … porque quedan almacenados en la PC del cliente.

Con las cookies pasaría algo parecido porque los datos también quedan almacenados en el disco de la PC cliente.

Además, si la conexion no va por SSL, los datos se van a transmitir crudos a través de la conección, tanto por GET como por POST y, por ende, si el cliente está detrás de una LAN y alguien está capturando los paquetes que pasan por esa LAN (sniffing) entonces ese alguien va a poder ver los datos crudos sin ningún tipo de problemas (saludos a los dueños de cybers).

Si el cliente no está detrás de una LAN pero, por ejemplo, en el servidor remoto hay algún tipo de programa corriendo y también sniffeando paquetes … los datos van a ser obtenidos sin problemas nuevamente porque en este extremo es básicamente lo mismo. El problema acá radica justamente en el típico servidor mal mantenido que hostea 80 sitios y tiene SSH habilitado para los usuarios… pícaros usuarios.

Acá en casa yo estoy corriendo Apache con mod_ssl y un certificado hecho “así nomás” como pa’ que ande. Se puede y la conexión es segura entre las dos máquinas. El tema de los servers en producción es que el certificado necesita estar aprobado por alguna entidad certificadora tipo Verisign y eso es justamente lo que cuesta money.

Hace un par de meses cuando estaba viendo de que iba esto me topé con Cacert que es una entidad que emite certificados gratuitamente, pero honestamente mi conocimiento del tema no llega al 10% .

Volviendo al tema, no importa el método que se utilize, si no se está utilizando SSL los datos (paquetes) pueden ser interceptados sin ningún tipo de problemas desde un extremo hasta el otro … en cualquier parte del camino.

Con SSL en cambio, toda la información que se transmita entre el browser y el server va a ir transparentemente cifrada y solo unos pocos grandes hermanos tienen en sus manos el poder para descifrar los datos en tiempo real.

Lo que dijo marcoss sobre el consumo de recursos es cierto, imaginate que toda la información (texto e imágenes en gral.) está siendo cifrada y descifrada en tiempo real mientras se mantiene una comunicación entre un server y vaya uno a saber cuántos clientes. Por eso la mayoria aplica SSL en donde la información realmente no debe ser capturada, en los formularios de tarjetas de crédito.

Concluyendo, que los datos vayan por GET o POST en lo único que se diferencian, en este caso, es en dos cosas: con el primer método los podés obtener a simple vista y quedan cachedos en disco. Con el segundo tenés que renegar un poquito más pero si los querés los tenés ahi y no quedan cacheados.

Jukka Korpela se tomó el tiempo (hace ya más de 3 años) de explicar la diferencia entre el método GET y POST, diferencia que quizás tendría que estar explicada de la misma manera en la especificación hecha por la gente de la W3C. Lectura recomendadísima.

mas alla de lo tecnico.. era tan lindo entrar en un ciber y luego dehacer lo queuno debia hacer… jugar con el history del IE

Espero que no lo modifiquen

Me van a denunciar por publicar eso.