【问题标题】:Do I need to password protect my web app if it's at an obscure URL?如果我的 Web 应用程序位于不知名的 URL,我是否需要使用密码保护它?
【发布时间】:2012-11-14 16:35:07
【问题描述】:

如果我有一个脚本,我希望能够在接到通知后立即运行并将它放在 https 上服务器的公共端,并且只要我自己的个人缓存不被窥探,这是否安全作为一个“公众背后”脚本,我必须使用用户名和密码登录才能实例化?

例如,考虑以下两种方法:

1) 我使用用户名:xxxxxxxx,密码:yyyyyyyy 登录(例如使用 ssl 或 cpanel 然后触发脚本)

2) 我只是从我的 iPhone 上运行这条路径,https://www.iamsilly.com/xxxxxxxx/yyyyyyyy/myscript.php

排除有人拿起我的 iPhone 并查看我的历史记录的可能性,这两个安全系统之间的安全级别是否有任何实际差异?复杂度不完全一样吗? https 是不是没有加密到足以让 https 的复杂性和登录一样安全?

谢谢,如果这个话题被说死了,我很抱歉,但是看了很多关于它的帖子,我还是不太明白!

编辑:请记住,具有 8x8 随机双目录的路径有 7 quintillion(七十亿)组合,并且仅当我使用字母和数字字符时。

【问题讨论】:

  • Https 只涉及加密从服务器到终端设备的连接。这可以防止从您的服务器到客户端浏览器的流量以纯文本形式传输。它就像http一样,只是外人无法查看流量。就是这样。
  • 但是:如果在 Web 服务器上关闭了列出目录内容的功能,攻击者似乎很难猜出目录名称。特别是如果您有异常命名的目录。正确的“官方回应”是“通过默默无闻没有安全性”但是......猜测密码不像试图猜测目录组合吗?
  • 您应该使用用户名/密码和隐藏路径 :) 深度安全方法总是更好。其次要注意路径,因为它们默认记录在 apache 日志中,而 IEEE 发现它很困难:esecurityplanet.com/network-security/…
  • @fatfredyy - 从那篇文章中,“他们未能限制对其网络服务器日志的访问”......我会说问题在于有人允许访问网络服务器日志,而不是默默无闻的失败构造。我的问题是关于为什么“登录”的用户名和密码比具有相同熵的路径更安全。在 IEEE 的情况下,任何人都可以破解用户名和密码来访问网络服务器日志,然后不能直接访问日志和脚本吗?

标签: php security


【解决方案1】:

您的意思是“如果从街上看不到我的前门,我不需要锁上它,对吧?”

您假设您知道特定入侵者将如何找到您的网站。你没有。

您假设一个人正试图进入您的网站。它可能不会是人类,也可能不仅仅是一个人。入侵尝试的规模非常大。

无论我要去哪里,我都会在车上系好安全带,即使我真的要开四分之一英里远。它更安全,我不会浪费脑力去想是否需要。将密码放在您的应用上,不要浪费时间试图弄清楚它是否值得。

【讨论】:

  • 这是一个我敢打赌 OP 没有想到的攻击示例:使用 JavaScript 嗅探历史并将其传递给 badguy.com security.stackexchange.com/questions/17873/…
  • 您假设有人可以通过猜测找到该 URL。它不是。请参阅我在上面发布的链接,了解 JavaScript hack,让坏人了解访问过的网站。
  • 我开始明白你在说什么,我开始同意......但是,据我所知,上面的 JavaScript hack 需要提供它获得的链接列表是或否被访问过。我认为这和猜测是一样的。我肯定会用密码保护这些脚本。谢谢大家!
  • 是的,that 特定的 hack 要求您提供链接列表。然而,你不知道,对吧?这就是我认为你知道自己将如何受到攻击的危险的观点。
  • 触摸。谢谢@Andy,我认为它终于沉没了:o)
【解决方案2】:

不,Security through Obscurity 根本没有安全性。

【讨论】:

  • 直接来自该页面...“关于安全问题的正式文献很少。安全工程书籍将引用 1883 年的 Kerckhoffs 学说,如果他们引用任何内容的话。”
【解决方案3】:

我认为答案是“如果有人设法掌握了这个,那该有多糟糕?”然后采取相应的行动。

“那永远不会发生”总是让我偏执。

【讨论】:

  • 我同意。正如@Andy Lester 所提到的,我也同意安全带的问题。这可能是教老狗(我)一个新把戏(偏执)的问题。我认为这里故事的寓意可能是偏执狂最终可以对我有利。 :o)
猜你喜欢
  • 2021-03-22
  • 1970-01-01
  • 2014-06-07
  • 1970-01-01
  • 2017-02-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多