crud中的r——特性和公开漏洞之间的界限在哪里?

所以你的问题提出了一些我希望我知道更多的观点,但我会尽我最大的努力,至少找出一些事情…

您的浏览器正在缓存路径中包含私有/安全信息的URL,从而为您的私有信息留下一个潜在窗口。含义:

1. 有人可以在你不在的时候走到你的计算机前,或者远程访问你的计算机,或者——如果在几个级别上没有采取适当的预防措施——使用XSS方法通过javascript获取你缓存的URL。

这种担心是正当的,但是你已经指出了你可以采取哪些步骤来让他们平静下来:

• 不要打开多个窗口,有些是私有的,有些不是私有的。使用私人浏览器会话进行私人浏览。实际上,我有一个想法是开发一个火狐插件,允许你创建一个“黑名单”,一个应该始终处于匿名模式的域名列表。这样你就可以在你的银行网站上,跳到Twitter上,它知道有不同的评价,等等。

• 将浏览器设置为在每次关闭时删除(或至少要求删除)所有个人数据。

• 在服务器端,任何负责的Web应用程序设计器都不应 曾经 在安全站点的URL中使用凭据或个人数据。这可不太圆滑,太懒了。我认为ID号或会话ID并没有太好(我将在第二点中讨论)。您的银行应使用: /onlinebanking/UserServices/transactions 作为RESTful的URL,应该在服务器级别(mod ou auth和一个非常好的cert)确认每个请求的所有内容,包括IP。听到人们谈论“减少服务器负载”,甚至“减少数据库点击量”,我感到非常疲惫。该软件是专门为接收大量请求而设计的。我的惠普笔记本电脑是6年前制造的,听起来像是一台旧冰箱,它的设计并不是为了减轻服务器的工作负荷,而是等待10分钟,等待一个设计糟糕的JS脚本(参见:new yahoo!邮件客户端)使我想刺伤。而且,如果没有其他的东西可以让这个被滥用的可怜的巨型服务器来处理,那么它应该每次都能确保您的安全。

好吧,那咆哮结束了。

• 你弟弟能看到你缓存的网址吗?也许吧。我女朋友可以告诉我什么时候访问过XXX网站,即使我清除了历史记录(为什么?因为它仍然出现在最近关闭的选项卡中!YY隐私!而这些缓存并不是为了让人休息,而是因为浏览器就是这样做的。所以你应该在去一个网站后采取同样的预防措施 iamgoingtokillhimtonight/posts 当你去pron网站或是在寻找生日礼物的想法时,你会把你的…自我…放在网址上。

关于我的解释:

所以,是的,URL是缓存的,这对于任何想仔细阅读所说的缓存以进入您的业务的人来说都是令人毛骨悚然的。但是,您所表达的另一个关注点似乎是他们可以用它做什么,即跨浏览器的攻击。有人能用那个缓存的URL编写一个脚本来获取您的实际银行信息并清除您吗?对。但是,如果他们已经知道如何做到这一点,他们所获得的优势是微乎其微的。这更像是先给他们留一步,然后把钥匙挂在门上。如果我能通过JS以某种方式看到你的缓存,从而看到你的安全银行URL,那么如果他们不使用可爱的URL,我也可以很容易地看到你银行的URL,并且可以很容易地在它周围写上我的XSS。如果我能看到你的缓存,我肯定能看到你的cookie并偷取它们(只有在网上才有比缓存更值钱的cookie)。所以在Ajax之前同样的规则也适用:

• 用户不应该写下密码
• 会话cookie应在会话结束时过期
• Web应用程序需要使用白名单、证书和非证书来保护用户请求的完整性和真实性。

我不能足够强调XSS的成功是基于开发人员(包括我自己)的懒惰(或无知)和用户的困惑和天真。大多数真正的XSS分数都是在网络黑客攻击之前进行的社交黑客攻击。一个网络钓鱼骗局或一封老朋友或西班牙囚犯的信,只要求你跟踪这个无辜的链接或分享一些毫无意义的个人信息。我能从你的银行例子中看到的一件更糟的事情是,现在我从这个网站上知道你的名字是亚历克斯,从网址上知道你的名字是福雷斯特。这可能会使挖掘细节更容易让你从其他信息中逃脱出来。

因此,无论是长的还是短的,最后:

RESTfulity和Ajax并没有像以往那样对浏览器历史和糟糕的服务器安全构成太大威胁,因此同样的规则适用于用户和开发人员。但是你完全正确的是,这样的RESTful URL指出,我们对这些实践的了解越来越差,而不是更好;使用技术变得更懒,而不是利用优势来专注于真正的艰苦工作。

嗯,那很有趣。回到盐矿。

避免这种公开的最简单方法是使用ID号而不是字符串。

没有什么可以透露的 /forum/Board-214/Thread-5625/posts 或者类似的。

请注意,我不一定同意这个问题,只是提供一个解决方法。

恶意用户可以在什么情况下获得Ajax请求URL而不是响应主体?

归根结底,您的用户的浏览器、历史记录、缓存等不是秘密的或受到适当保护的(在许多情况下,未经授权的用户可以访问这些内容,您提出问题的事实表明您可能意识到它们…)。

因此,不要假定缓存的任何内容都将受到保护-并且不允许 “敏感”信息将缓存在那里。你问,什么是敏感的?好吧,任何你不想透露给其他用户的信息。银行帐户、秘密论坛、用户名、会话ID、事务详细信息-不允许将这些内容缓存或存储在客户端上。

这确实是您提出的一个很好的观点,因为开发人员通常会匆忙使用Ajax和其他一些不能提高可用性的东西,而忘记了在客户机上和在客户机上保护这些信息。

由于URL是Web浏览器的不透明标识符,因此向其添加人类可读文本的唯一目的是便于记忆。

银行应该用匿名身份证代替你的名字。当连接是(希望!)加密后,该URL仍将存储在浏览器的历史记录中,第三方可以访问该历史记录。匿名ID,甚至是每个会话的临时ID,将更加安全。

这个论坛示例包含一个奇怪的短语,“普通用户不应该知道的受限线程存在”。普通用户是否知道线程存在真的很重要?问题是该线程的主题在URL中被公开,这是一个漏洞。URL应该类似于 /forum/thread/12345/ .

老实说,这与crud、ajax或你在问题中使用的任何其他流行词无关。问题是是否可以接受明文形式的秘密信息,答案是“不”。

很好的对话,以及所有非常有趣的回答!很抱歉,我不得不大量回复,但我想尽快下班,没时间去弄清楚我是否在某个地方有一个OpenID提供者。

虽然我的例子是编出来的,但我今天确实发现自己在这个场景中。我的项目正逐渐脱离设计,首先要构建的是HTTP/JSONWebService。昨天,我梳理了所有的UI概念,并列出了Web服务需要提供某些数据的每个点。然后,当我试图将所有这些操作嵌入到一个一致的URL方案中时,我发现自己想要在GET请求中放入一些看起来有点敏感的信息。我承认,我最初的帖子并不是一个问题,而是对本文中使用的RESTfulWebservices(特别是CRUD端点)提出的潜在安全问题的评论。我从未听过任何人从这个角度谈论这个话题,我对你们所有人的想法都很感兴趣。

我认为对我的问题最有用的答案来自约翰·米利金,他指出基于iframe的Ajax确实会将请求URL抛出到历史中,这让我很惊讶。我敢肯定,任何XHR请求都只能存在于浏览器的缓存中,在缓存中响应也是可用的,此时您遇到了一个更大的问题。提到XSS攻击是另一个有趣的地方;在很多情况下,人们都找到了一种方法来公开浏览器历史记录,或者获取某个URL的缓存。如果有人知道我的银行帐户ID是“aforster”,然后找到一种方法从另一个域的上下文中获取我缓存的/onlinebanking/aforster/transactions版本,他们可以获得大量信息。

奇怪的是,我可能最终会将谨慎抛诸脑后,通过GET传递我的敏感数据,因为这个特定的敏感数据根本不敏感,它是一个企业内部网,我们下面有TLS。对于自我记录、人类可读、易于记忆的URL,有很多话要说。但是,我知道这些请求将被记录:1)我们的Web服务器,2)Websense,和3)我们的VPN基础设施。我拥有的每一个家庭路由器都有家长控制,可以记录URL,上帝禁止你运行一些花哨的CMS/where/every thing damn thing i s/addressed by title/然后有人找到一种方法来获取你的网络服务器的请求日志。在我的特殊情况下,这对我来说是一个可以接受的折衷,但在另一种情况下,我相信我会有一些值得关注的理由。