你需要做的是攻击一些特定类型的攻击。即使对于非常引人注目的网站,这通常也足够了。对于一个不是最大网站之一的网站来说,这些东西应该足以阻止脚本孩子们。
跨站点请求伪造:
从本质上来说,这就是你在最初的帖子中想要指出的。正如您所指出的,这种攻击所需要的要么是找出可以执行某些用户特定操作的URL,然后直接调用它。或者,更难防范的是,通过欺骗登录用户单击一个链接来执行特定于该用户的操作。
第一种可以通过用会话密钥标记每个调用并确保其有效来阻止。然而,这不能阻止第二个。
好消息是,这种攻击可以通过URL中的一个秘密值停止,经常更改,在后端记住足够长的时间以确保正确调用它。这里我们讨论的是Ajax,所以最简单的方法是在整个页面加载时,创建一个随机数的秘密值。对于传统的表单也是如此,记住这一点,在创建新的表单之前检查旧的秘密值。您将该值保存在会话数据中,并将其附加到来自后续页面的所有Ajax调用或表单提交中。如果匹配,则为同一用户。如果没有,您只需忽略请求。
每次用户加载一个全新页面时,都要为该用户创建一个新的秘密。这意味着只有攻击者是用户,他们才能找到这个值。这意味着你已经击败了这种攻击类型。
跨站点脚本:
XSS攻击的不同之处在于,它们是CSRF攻击的另一面。这个很容易。只要确保来自用户或数据库的所有数据都通过一些函数传递,这些函数将HTML字符转换为它们的实体,比如
htmlentities()
在php中,在您的站点上显示它之前。这将阻止用户使用javascript将用户重定向到操作链接或其他恶意内容。它还可以防止Flash和其他对象嵌入到页面中。
不幸的是,它还将阻止在注释或文章正文中使用任何HTML。这可以用一个非常严格的白色标签列表或一些版本的可选代码来绕过。(如本网站使用)
没有什么好方法可以尝试创建黑名单。我试过了。我们都试过了。它们不工作。
SQL注入:
不过,我不会在这里详细介绍,可以说上面的攻击和它所造成的伤害相比,根本算不上什么。好好学习。
除此之外,您还应该遵循一些指导原则。例如,永远不要陷入相信发送到javascript的数据会像您期望的那样回来的陷阱。假设最坏。传统形式也是如此。发送给用户的数据应该被处理,不管您如何加密它,就好像它是来自用户的全新数据一样。
如果你有论坛帖子的编辑方法。在提交时检查用户是否具有编辑该日志的权限。确保他们已登录。确保秘密匹配。确保他们输入的数据没有SQL注入。
做这些事情,你就能阻止绝大多数的攻击。
不是所有的。Firesheep使用的攻击类型仍然可以通过,任何类似的攻击都可以针对用户,而不是您的站点。您可以使用https而不是http来保护自己免受火羊的攻击。但即使这样也无法抵御各种针对用户的攻击。比如从他们的机器上窃取会话cookie,或者物理访问他们的机器。