security - puerto - https:/
Seguridad: ¿está bien enviar un nombre de usuario y contraseña a través de HTTP GET? (9)
Somos una organización que adquirió un sistema que utilizan los médicos para ver los resultados de los exámenes de los pacientes (información bastante confidencial). Siendo un programador, he pinchado y pinchado con el sistema y encontré que envía el nombre de usuario y la contraseña a través de una solicitud HTTP GET. En el dominio en el que se ejecuta, todas las computadoras están configuradas para eludir el proxy, por lo que la URL con la solicitud no se guardará en algún registro proxy en alguna parte. Pero yo diría que esta es una forma insegura de manejar nombres de usuario y contraseñas de todos modos.
El vendedor argumentará que, como nunca lo solicitamos, será una ''mejora'' que requerirá $$$ adicional. (En primer lugar, nunca escribimos las especificaciones para el sistema).
¿Qué tipo de caso podría hacerle a la gerencia para hacerles sentir que esto no es estándar y que probablemente la única manera de que este sistema sea seguro es a través de HTTPS?
EDIT: gracias por todas sus respuestas! He planteado el problema con el líder del proyecto, su respuesta fue en la línea de "¿qué es HTTP?". Así que planeo explicárselo todo con más detalle, investigar las implicaciones legales y tratar de plantear el problema con los programadores preguntándoles directamente por qué siguieron ese camino. También intentaré explicar la situación a otros colegas que no tienen ninguna participación directa, pero que pueden influir en el asunto.
Esto no es menos seguro que la autenticación HTTP básica.
Esto es cierto, excepto por un punto sutil, que el nombre de usuario y la contraseña, según cómo esté diseñado el sistema, pueden aparecer en la barra de direcciones de la ventana del navegador.
Por lo menos, creo que deberían enviar esa información al servidor.
Creo que para su caso debe insistir en https, incluso si se trata de una red "segura".
Esto es similar a http basic (básico lo permite en el encabezado, lo cual es preferible, pero también puede colocarlo en la URL en un formato determinado; consulte rfc2617 para obtener más información).
con SSL / https, el nombre de host estará despejado (obviamente, ya que tiene que encontrar el servidor), pero las otras partes de la URL se deben cifrar de forma segura.
Esto no es menos seguro que la autenticación HTTP básica. Solo asegúrese de que el nombre de usuario / contraseña no esté en la memoria caché de los navegadores web del cliente (¿está en el historial de su navegador?)
Creo que la manera más fácil y económica sería requerir HTTPS para asegurar su aplicación web. Si el usuario va a una URL que es HTTP, puede simplemente redirigirlos a la URL equivalente de HTTPS.
Sin embargo, si debe permitir el acceso HTTP (y no estoy seguro de por qué ese sería el caso), entonces no es seguro. En su lugar, debe implementar algo así como la autenticación de acceso a resumen HTTP .
No creo que mejorar la seguridad es algo que debería obtener de forma gratuita de la persona que hace la codificación. Eso es a menos que el u / p aparezca en el historial del navegador.
Como se trata de información de médicos y pacientes, también me parece que el contenido en sí mismo debe estar encriptado, y no solo la autenticación. Entonces, realmente deberías estar usando HTTPS de todos modos.
Una buena forma de presentar su caso es contratar a un gerente relativamente técnico (o brillante) que lo entenderá si les muestra un rastro etéreo vivo de un inicio de sesión (¡mire! Aquí está la contraseña para el usuario: MrGreen. Qué, no crea ¿Yo? ¡Aquí pruébalo tú mismo!).
Solo haga esto sin preguntar primero si confía y conoce al gerente, sino simplemente hable con él sobre esto y, si no le cree, pida permiso para mostrarlo. Si no lo otorga, puede señalar esta pregunta u otro recurso en línea. Pero si no les importa, no tienes suerte, diría yo.
Haga el seguimiento en vivo, explique simplemente lo que hizo (cualquiera en nuestra red puede hacer esto, es tan fácil como instalar este programa). Luego explique que es casi gratuito obtener encriptación en el sistema, lo que evitaría eso y que la aplicación apenas tiene que modificarse en lo mínimo. Y que tendría el beneficio de transmitir todo encriptado para que los registros fueran mucho más seguros también.
Luego deje que el gerente se encargue de los permisos apropiados / aprobación del presupuesto / lo que sea.
Y la única manera sensata de solucionarlo en general es usar POST (para corregir la contraseña que se envía en las URL) y HTTPS.
Lo que más me preocupa es que las personas que envían contraseñas de texto plano a través de la red probablemente tengan muchos otros defectos de seguridad.
¿Este software personalizado o algo utilizado por otros? Si es lo último, considere unirse o iniciar un grupo de usuarios que represente a todos los que usan el software.
Incluso cuando usa SSL, recuerde que cuando los nombres de usuario y las contraseñas se envían usando GET, se incluyen como parte de la URL.
Esto significa que cualquier registro del servidor contendrá los nombres de usuario y las contraseñas como parte del proceso de registro. Por lo tanto, deberá proteger estos registros o, al menos, evitar el registro de la cadena de consulta.
Los nombres de usuario y las contraseñas nunca deben enviarse sin cifrar a través de la red, por lo tanto, insista en HTTPS para al menos la autenticación. Mi preferencia sería que el nombre de usuario / contraseña solo se acepte a través de POST (para que no aparezca en la URL), pero podría cifrar y codificar la contraseña para poder ponerla en una solicitud GET. No puedo imaginar ninguna razón por la que haría esto en lugar de un POST.
[EDIT] Como otros han indicado, si tiene datos relacionados con el paciente, es posible que deba encriptar todas las comunicaciones con el servidor. Si se encuentra en los EE. UU., Le insto a que examine las reglamentaciones HIPAA para ver si aplica alguna aquí con respecto a la seguridad de los datos, especialmente la subsección 164.306 de la Regla de Privacidad (PDF).
Si se trata de datos médicos y usted vive en los Estados Unidos, existe una excelente posibilidad de que el acceso esté sujeto a las reglamentaciones de HIPAA, incluidos los requisitos de seguridad. Debe revisar http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidance forRemoteUseFinal122806.pdf . Si no vives en los Estados Unidos, sugeriría que aún puedas señalar que HIPAA es relevante para el dominio.
Si su proveedor intenta retrasar con una tarifa adicional, diga "¿Está diciendo que no cumple con las normas gubernamentales pertinentes? Golly, tal vez debería proporcionarnos documentación completa sobre sus estándares de seguridad y privacidad, las garantías y los procedimientos . Porque obviamente si nos golpearan con una multa, vendríamos detrás de ti. "(IANAL y todo eso).
Desde un nivel técnico, ciertamente la sugerencia de un rastro etéreo que muestre cuán fácil es buscar nombres de usuario y contraseñas debería ser revelador para su administración. Dado lo trivialmente fácil que es husmear el tráfico de red normal y lo fácil que es usar SSL para el transporte, la idea de un proveedor que la respalde como una "mejora de la seguridad" es escandalosa.
Tiene dos problemas aquí, uno técnico, uno contractual (y, por lo tanto, legal). No pediría consejo legal sobre .
La respuesta técnica es obvia: estos tipos que hicieron su sistema son payasos, ya que dejaron un gran agujero de seguridad en él.
Legalmente, dependerá del país en el que se encuentre (me doy cuenta de que es de Brisbane, así que hola del otro lado del país). Muchos tendrán una legislación médica o de privacidad que puede haber sido violada, así que eso es algo que debemos verificar. Las leyes de HIPAA que otros han sugerido investigar son solo en los Estados Unidos; podemos tener un equivalente en Australia, pero estoy bastante seguro de que las leyes de privacidad aquí en Oz podrían ser compradas.
Del mismo modo, debe revisar el contrato (ya sea que lo haya redactado o no, supongo que usted (o su predecesor) lo firmó, de lo contrario no hay obligación de pagarlo) para ver si la privacidad era un requisito. Incluso si no, un abogado competente podría argumentar que se trata de un requisito implícito.
Es posible que tenga que absorberlo y pagar el dinero extra. He trabajado para algunas grandes compañías y ellas tienden a suspender toda responsabilidad por lo que no figura en los documentos a entregar al cliente (esto generalmente está escrito en el contrato). Si su proveedor es competente (en términos de negocio en lugar de satisfacción del cliente, por supuesto), habrán hecho exactamente esto.
Pero primero , contáctese con un abogado para obtener consejos. Son comedores inferiores chupadores de esperma :-), pero son las personas que sabrán qué hacer y están en mejores condiciones para examinar los contratos y aconsejarle sobre las mejores opciones disponibles para usted. Utilicé uno hace unos 10 años para salir de un contrato de automóvil que ya no podía pagar y, aunque costaba varios miles de dólares, era mucho mejor que la alternativa.
A menos que estén frecuentando SO, el consejo que van a obtener aquí está sesgado al lado técnico (mejor caso) o francamente peligroso en un sentido legal (especialmente porque se basará principalmente en la legislación de los EE. UU.). Al no querer promocionar tipos de abogados, sí sé que puedes encontrar uno aquí .
La mejor de las suertes.