3

我已经对 HttpOnly cookie 和存在的问题进行了一些研究，这些问题可能会结合使用 XHR 请求和 TRACE 方法来获取从服务器回显的 cookie 值。

对于安全的网络应用程序，我目前有以下设置：

  • 会话 cookie 在登录时发送，并设置了安全和 httpOnly 属性
  • 对整个域禁用 TRACE http 方法（返回“405 Method not allowed”）

为了避免跨站点请求伪造，我在表单的隐藏字段中添加了一个随机密钥。必须在每个 POST 请求中返回此密钥，才能接受该请求。

除此之外，默认情况下，所有 HTML 都使用白名单进行转义，以选择允许的标签和属性，但为了说明这还不够：我们之前允许使用 span 上的样式属性（例如为文本着色），这可用于通过以下方式在 Internet Explorer 中传递 javascript：

<span style="width: expression(alert('Example'));"> </span>

然后是最后一个问题：任何人都可以指出任何缺陷或建议以解决此设置中可能存在的缺陷吗？还是您使用相同或完全不同的方法？

已知问题：

  • 并非所有浏览器都支持 httpOnly
  • 过滤 css JS 表达式是不够的，@import(external-style-sheet) 也可以
4

2 回答 2

7

根据您的帖子（标题有点误导），我假设您了解 Httponly 属性可以防止通过 document.cookie 访问 cookie，并且没有做任何其他事情来防止 XSS 允许的其他讨厌的事情，包括冒充用户（即，不需要窃取 cookie 并可以使用检索到的 CSRF 令牌），检查浏览器上的易受攻击的插件以安装恶意软件，安装 javascript 键盘记录器，扫描您的内部网络等，重写页面等。

正如您所说，将每个标签的标签和属性列入白名单是不够的。您可能必须通过白名单正则表达式对属性值应用更严格的验证。

需要考虑的其他事项的不完整列表，其中一些与 XSS 或 CSRF 没有直接关系：

  • 您如何处理不完整的 html，例如缺少结束标签？
  • 您如何处理用户输入中的单引号、双引号和反斜杠？
  • 您如何处理在不同上下文中输出的用户输入 - 例如在 url 链接、属性值等中？
  • 您是否检查输入是否与输入字符集编码匹配？
  • 您是否在响应标头和元标记中明确设置 Content-Type？
  • 对于通过 HTTP 提供的中度敏感用户页面（如果有），您是否设置了适当的 Cache-Control 标头？
  • 您如何确保用户输入被沙盒化？具体来说，如果您允许 CSS，您如何确保样式仅应用于受限区域而不能更改其他区域？
  • 你有 3rd 方 javascript，包括网站上的广告吗？
  • 会话 cookie 是否应该受到保护以防篡改？
  • 您是否清理了所有输入，包括用户可以修改的 HTTP 标头？
  • CSRF 令牌是否真的是随机的 - 如果是，您如何生成随机令牌？如果没有，你如何构建它？
  • 您是否使用准备好的语句和绑定参数？
  • 用户可以上传文件吗？
  • 您是否提供用户上传的内容，例如图像等？如果是，您如何验证文件内容（GIFAR 缺陷）以及文件是否来自同一域？
  • 您是否提供 API 访问权限，如果是，是否托管在同一域上？你有什么跨域限制？
于 2010-02-17T07:33:32.410 回答
2

HttpOnly Cookies 是一种很好的安全措施，但它并非旨在阻止 XSS，只是让攻击者更难以利用 xss 漏洞。让我详细说明。

使用 XSS 可以绕过基于令牌的 xsrf 安全系统，因此攻击者无需知道 cookie 即可利用 xss 漏洞。

为了避免跨站点请求伪造，我在表单的隐藏字段中添加了一个随机密钥。必须在每个 POST 请求中返回此密钥，才能接受该请求。

例如，使用 XSS，攻击者可以执行 JavaScript，该 JavaScript 可以使用 xmlhttprequest 读取域上的任何页面。因此，通过使用 xmlhttprequest，攻击者可以读取 XSRF 令牌，然后使用它来伪造 POST 请求。这是因为 XSS 的一个属性是它允许在Same Origin Policy中中断。举个例子，这是我写的一个真实世界的漏洞利用，它做了我刚才解释的事情。

防止 XSS 的最佳方法是将讨厌的字符转换<>为相应的 html 实体。在 PHP 中，我推荐：

$var=htmlspeicalchars($var,ENT_QUOTES);

这将修复单引号和双引号，因此它可以停止大多数xss。即使生成的刺痛位于 html 标记中。例如，如果您替换引号，攻击者将无法使用此漏洞。这是因为攻击者必须打破引号才能执行“onload=”。

$var="' onload='alert(document.cookie)'";

进入这个html：

print("<img src='http://HOST/img.php?=".$var."'>");

但是，您使用<span>标签列出的特定情况仍然可能存在问题，因为攻击者不需要引号！如果您放入<script>标签中，您也将有一个 xss 漏洞。只是要确保用户输入的放置位置是安全的，没有针对所有漏洞的“包罗万象”或“灵丹妙药”。

利用 HTTP“TRACE”方法的“XST”攻击在实践中并不是一种现实的攻击。原因是攻击者不可能强制 Web 浏览器发出“TRACE”http 请求。在“GET”的情况下，攻击者可以使用 javascript 或<img>标签强制“GET”和“POST”方法，但 HTTP 标头的其余部分不受限制。请记住，几乎所有 Apache 系统都默认启用 TRACE，如果它真的很危险，它将被一起删除。如果 Apache 支持 TRACE，许多像 Nessus 这样的安全测试工具会抛出错误，也可以很容易地禁用它。

于 2010-02-17T07:46:26.370 回答