安全性 - 通过HTTP GET发送用户名和密码是否可以?

时间:2008-10-26 22:34:19

标签: security http

我们是一个购买了一个系统的组织,医生用它来查看患者的测试结果(非常敏感的信息)。 作为一名程序员,我对系统进行了调查,并发现它通过HTTP GET请求提交用户名和密码。 在运行的域上,所有计算机都设置为绕过代理,因此带有请求的URL将不会保存在某个代理日志中。 但我认为这是一种处理用户名和密码的不安全方式。

供应商会争辩说,既然我们从未要求它,它将是一个“增强”,需要额外的$$$。 (我们从未编写过该系统的规范)。

我可以向管理层提出哪种情况让他们觉得这不符合标准,而且这个系统安全的唯一方法是通过HTTPS?

编辑:感谢您的所有回复! 我向项目负责人提出了这个问题,她的回答是“什么是HTTP?”。 因此,我打算更详细地向她解释这一切,调查法律含义,并尝试直接询问程序员为什么走这条道路来解决问题。我也会尝试向没有任何直接参与的其他同事解释这种情况,但可能会对此事产生影响。

9 个答案:

答案 0 :(得分:16)

如果是医疗数据并且您居住在美国,那么访问它的机会很可能符合HIPAA法规,包括安全要求。您应该查看http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidanceforRemoteUseFinal122806.pdf。如果你不住在美国,我建议你仍然可以指出HIPAA与域名相关。

如果您的供应商试图收取额外费用,请说“您是说您不符合相关的政府标准吗?很棒,也许您应该向我们提供有关您的安全和隐私标准的完整文档,保护措施和程序。因为很明显,如果我们被罚款,我们会跟着你。“(IANAL等等。)

从技术层面来看,当然有一个空灵痕迹的建议显示清除用户名和密码是多么容易,这应该让你的管理层大开眼界。考虑到嗅探正常的网络流量以及使用SSL进行传输是多么容易,这一点非常简单,供应商将 作为“安全增强”推回的想法是令人愤慨的。

答案 1 :(得分:10)

一个很好的方法就是抓住一个相对技术性(或聪明)的经理,如果你向他们展示一个登录的现场空灵痕迹,你就会明白(看!这是用户的密码:MrGreen。什么,不要不相信我吗?亲自试试吧!)。

只有在没有先询问您是否信任并了解经理的情况下才能这样做,否则只需与他谈谈此事,如果他不相信您,请求许可证明。如果他不授予它,您可以指向此问题或其他在线资源。但是,如果他们不在乎,你会说运气不好。

进行实时跟踪,简单解释一下你做了什么(我们网络上的任何人都可以做到这一点,就像安装这个程序一样简单)。之后解释说,几乎可以自由地在系统上进行加密,这样就可以防止加密,而且应用程序至少不需要修改。并且它将有利于传输加密的所有内容,因此记录也会更加安全。

然后让该经理负责相应的权限/预算批准/无论如何。

唯一明智的解决方法就是使用POST(修复URL中发送的密码)和HTTPS。

最让我担心的是,通过网络发送明文密码的人可能会有许多其他安全漏洞。

答案 2 :(得分:8)

这里有两个问题,一个是技术问题,一个是合同问题(因此是合法的)。我不会要求Stack Overflow提供法律建议。

技术上的答案是显而易见的 - 这些做你的系统的人都是小丑,因为他们在其中留下了一个巨大的安全漏洞。

从法律上讲,这取决于你所在的国家(我注意到你来自布里斯班,所以你好,来自该国的另一边)。许多人将拥有可能违反的医疗和/或隐私法规,因此需要检查一件事。其他人建议调查的HIPAA法律仅限于美国;我们可能在澳大利亚有一个等价物,但我很确定奥兹的隐私法可以被用来发挥作用。

同样地,你需要查看合同(无论你是否起草合同,我假设你(或你的前任)签署了它,否则你没有义务支付他们的费用)看看隐私是否是要求。即使不是,一位称职的律师可能会认为这是一项隐含的要求。

你可能不得不掏钱并支付额外的钱 - 我曾为一些大公司工作过,他们倾向于对未在交付物中列出的任何东西承担全部责任(通常写入合同)。如果您的供应商是一个称职的(当然,就业务而非客户满意度而言),他们就会做到这一点。

首先,请联系律师寻求建议。他们是愚蠢的底部喂食器:-),但他们是知道该做什么的人,他们最能检查合同并告知你最好的选择。我大约10年前使用过一个我不能再负担的汽车合同,即使花费数千美元,也比其他合同要好得多。

除非他们经常这样做,否则你要在这里提出的建议要么偏向于技术方面(最好的情况),要么在法律意义上是彻头彻尾的危险(特别是因为它主要基于美国法律) 。不希望为律师类型做广告,我知道你可以找到一个here

祝你好运。

答案 3 :(得分:3)

即使使用SSL,请记住,当使用GET发送用户名和密码时,它们会作为URL的一部分包含在内。

这意味着任何服务器日志都将包含用户名和密码作为日志记录过程的一部分。因此,您需要保护这些日志,或者至少阻止记录查询字符串。

答案 4 :(得分:2)

我认为,对于您的情况,您应该坚持使用https - 即使它是通过“安全”网络。

这类似于http basic(基本允许它在标题中 - 这是首选,但您也可以将其以特定格式放入URL中,有关详细信息,请参阅rfc2617。)

使用SSL / https,主机名将清除(显然必须找到服务器),但URL的其他部分应安全加密。

答案 5 :(得分:1)

这比基本的http身份验证内置的安全性更低。只需确保客户端Web浏览器没有缓存用户名/密码(它是否在您的浏览器历史记录中?)

我认为最简单,最便宜的方法是要求HTTPS保护您的Web应用程序。如果用户转到HTTP的URL,您只需将它们重定向到HTTPS等效URL即可。

如果您必须允许HTTP访问(并且我不确定为什么会出现这种情况),那么它绝对不安全。您应该实现类似HTTP digest access authentication的内容。

我不认为增强安全性是你应该从编码人员那里免费获得的东西。这是除非u / p出现在浏览器历史记录中。

由于您正在处理医生和患者信息,因此对我而言,内容本身应该加密,而不仅仅是身份验证。所以你真的应该使用HTTPS。

答案 6 :(得分:1)

  

这并不比内置安全   基本的http身份验证。

除了一个微妙的点,用户名&密码,取决于系统的设计方式,可能会出现在浏览器窗口的地址栏中。

至少,我认为他们应该将这些信息发布到服务器上。

答案 7 :(得分:1)

永远不要通过网络以非加密方式发送用户名和密码,因此至少要通过HTTPS进行身份验证。我的偏好是只能通过POST接受用户名/密码(因此它根本不会出现在URL中),但您可以想象加密和编码密码,以便将其放入GET请求中。我无法想象为什么我会这样做而不是POST。

[编辑]正如其他人所指出的,如果您有与患者相关的数据,您可能需要加密与服务器的所有通信。如果您在美国,我会建议您查看HIPAA规则,了解有关保护数据的具体内容,特别是Privacy Rule(PDF)的第164.306小节。 / p>

答案 8 :(得分:0)

这是自定义软件还是其他人使用的东西?如果是后者,请考虑加入或启动代表所有使用该软件的用户组。