🥇网站安全的致命罪过：我们从今年的漏洞扫描统计数据中学到了什么

大约一年前，我们 DataLine 推出了服务搜索和分析 IT 应用程序中的漏洞。该服务基于Qualys云解决方案，其运作方式我们已经告诉过。在使用该解决方案的一年时间里，我们对不同站点进行了 291 次扫描，并积累了 Web 应用程序中常见漏洞的统计数据。

在下面的文章中，我将向您展示不同严重程度背后隐藏的网站安全漏洞。让我们看看扫描仪最常发现哪些漏洞、它们可能发生的原因以及如何保护自己。

Qualys 将所有 Web 应用程序漏洞分为三个严重程度级别：低、中和高。如果按照“严重程度”来观察分布情况，似乎一切都还不错。很少有严重程度较高的漏洞，大多数都是非严重的：

但不批判并不意味着无害。它们还会造成严重损害。

最重要的“非关键”漏洞

混合内容漏洞。
网站安全的标准是通过HTTPS协议在客户端和服务器之间传输数据，该协议支持加密并保护信息不被拦截。

一些网站使用 混合内容：一些数据是通过不安全的HTTP协议传输的。这是最常传达的方式 被动内容 – 仅影响网站显示的信息：图片、CSS 样式。但有时这就是它的传播方式 活跃内容：控制网站行为的脚本。在这种情况下，使用特殊的软件，您可以分析来自服务器的活动内容的信息，动态修改您的响应，并使机器以非其创建者预期的方式工作。

较新版本的浏览器会警告用户含有混合内容的网站不安全并阻止该内容。网站开发人员还会在控制台中收到浏览器警告。例如，这就是它的样子火狐:

为什么这很危险：攻击者使用不安全的协议来拦截用户信息、替换脚本并向网站发送请求。即使网站访问者没有输入数据，这也不能保护他免受 网络钓鱼 – 使用欺诈方法获取机密信息。例如，使用脚本，您可以将用户重定向到一个伪装成用户熟悉的站点的不安全站点。在某些情况下，恶意网站看起来甚至比原始网站更好，用户可以自己填写表格并提交机密数据。

Web 开发人员应该记住什么：即使站点管理员安装并配置了 SSL/TLS 证书，也可能因人为错误而出现漏洞。例如，如果您在其中一个页面上放置的不是相对链接，而是来自 http 的绝对链接，而且您没有设置从 http 到 https 的重定向。

您可以使用浏览器检测网站上的混合内容：搜索页面的源代码，阅读开发人员控制台中的通知。然而，开发人员将不得不长时间且乏味地修改代码。您可以使用自动分析工具加快该过程，例如：检查SSL、免费 Lighthouse 软件或付费软件 Screaming Frog SEO Spider。

此外，该漏洞可能是由于遗留代码（继承的代码）的问题而出现的。例如，如果某些页面是使用旧模板生成的，则没有考虑网站向 https 的转换。
没有“HTTPOnly”和“secure”标志的 Cookie。
“HTTPOnly”属性可防止 cookie 被攻击者用来窃取用户数据的脚本处理。 “安全”标志不允许以明文形式发送 cookie。仅当使用安全 HTTPS 协议发送 cookie 时才允许通信。

这两个属性都在 cookie 属性中指定：
```
Set-Cookie: Secure; HttpOnly
```
为什么这很危险：如果网站开发者没有指定这些属性，攻击者就可以从 cookie 中拦截用户信息并利用它。如果cookie用于身份验证和授权，他将能够劫持用户的会话并代表他在网站上执行操作。

Web 开发人员应该记住什么：通常，在流行的框架中，这些属性是自动设置的。但仍然检查 Web 服务器配置并设置标志：Set-Cookie HttpOnly；安全的。

在这种情况下，“HTTPOnly”属性将使 cookie 对您自己的 JavaScript 不可见。
基于路径的漏洞。
如果扫描器发现包含潜在机密信息的可公开访问的文件或网站目录，则会报告此类漏洞。例如，它检测单个系统配置文件或对整个文件系统的访问。如果站点上的访问权限设置不正确，则可能出现这种情况。

为什么这很危险：如果文件系统“突出”，攻击者就可以进入操作系统界面并尝试查找带有密码的文件夹（如果它们以明文形式存储）（不要这样做！）。或者，您可以窃取密码哈希值并暴力破解密码，还可以尝试提升系统权限并更深入地了解基础设施。

Web 开发人员应该记住什么：不要忘记访问权限并配置平台、Web 服务器、Web 应用程序，这样就不可能“逃脱”Web 目录。
用于输入敏感数据并启用自动填充的表单。
如果用户经常在网站上填写表单，他们的浏览器会使用自动填充功能存储此信息。

网站上的表单可能包含包含敏感信息的字段，例如密码或信用卡号。对于此类字段，值得禁用网站本身的表单自动填充功能。

为什么这很危险：如果用户的浏览器存储敏感信息，攻击者可以稍后拦截它，例如通过网络钓鱼。从本质上讲，一个忘记了这种细微差别的网络开发人员正在设置他的用户。

Web 开发人员应该记住什么：在这种情况下，我们遇到了一个经典的冲突：便利性与安全性。如果Web开发人员考虑用户体验，他可以有意识地选择自动完成。例如，如果遵循很重要 Web内容可访问性准则 – 针对残障用户无障碍内容的建议。

对于大多数浏览器，您可以使用 autocompete="off" 属性禁用自动完成，例如：
```
 <body>
    <form action="/zh-CN/form/submit" method="get" autocomplete="off">
      <div>
        <input type="text" placeholder="First Name">
      </div>
      <div>
        <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
      </div>
      <div>
        <input type="number" placeholder="Credit card number">
      </div>
      <input type="submit">
    </form>
  </body>
```
但它不适用于 Chrome。这是使用 JavaScript 规避的，可以找到配方的变体这里.
站点代码中未设置 X-Frame-Options 标头。
此标头影响框架、iframe、嵌入或对象标记。在它的帮助下，您可以完全禁止将您的网站嵌入框架内。为此，您需要指定值 X-Frame-Options：deny。或者您可以指定 X-Frame-Options: sameorigin，然后嵌入 iframe 将仅在您的域上可用。

为什么这很危险：缺乏这样的标头可被恶意网站用来 点击劫持。对于此攻击，攻击者在按钮顶部创建一个透明框架并欺骗用户。例如：诈骗者在网站上构建社交网络页面。用户认为他正在单击该网站上的按钮。相反，点击被拦截，用户的请求被发送到存在活动会话的社交网络。这就是攻击者代表用户发送垃圾邮件或获得订阅者和点赞的方式。

如果您不禁用此功能，攻击者可以将您的应用程序按钮放置在恶意站点上。他可能对您的推荐计划或您的用户感兴趣。

Web 开发人员应该记住什么：如果在 Web 服务器或负载均衡器上设置了具有冲突值的 X-Frame-Options，则可能会出现该漏洞。在这种情况下，服务器和平衡器将简单地重写标头，因为与后端代码相比，它们具有更高的优先级。

X-Frame-Options标头的deny和sameorigin值会干扰Yandex Web查看器的操作。要允许 Web 查看器使用 iframe，您需要在设置中编写单独的规则。例如，对于 nginx，您可以这样配置：
```
http{
...
 map $http_referer $frame_options {
 "~webvisor.com" "ALLOW-FROM http://webvisor.com";
 default "SAMEORIGIN";
 }
 add_header X-Frame-Options $frame_options;
...
}
```
PRSSI（路径相对样式表导入）漏洞。
这是网站样式中的一个漏洞。如果使用像 href="/zh-CN/somefolder/styles.css/" 这样的相对链接来访问样式文件，就会发生这种情况。如果攻击者找到一种将用户重定向到恶意页面的方法，他们就会利用这一点。该页面将在其 url 中插入一个相对链接并模拟样式调用。您将收到类似 badsite.ru/.../somefolder/styles.css/ 的请求，该请求可以以样式为幌子执行恶意操作。

为什么这很危险：如果欺诈者发现另一个安全漏洞，他们就可以利用此漏洞。因此，可以从 cookie 或令牌窃取用户数据。

Web 开发人员应该记住什么：将 X-Content-Type-Options 标头设置为：nosniff。在这种情况下，浏览器将检查样式的内容类型。如果类型不是text/css，浏览器将阻止该请求。

严重漏洞

带有密码字段的页面通过不安全的通道从服务器传输（包含密码字段的 HTML 表单通过 HTTP 提供）。
服务器通过未加密通道的响应容易受到“中间人”攻击。当页面从服务器传输到客户端时，攻击者可以拦截流量并将其自身插入客户端和服务器之间。

为什么这很危险：欺诈者将能够替换页面并向用户发送机密数据表单，该表单将发送到攻击者的服务器。

Web 开发人员应该记住什么：某些网站通过电子邮件/电话向用户发送一次性代码而不是密码。在这种情况下，该漏洞并不是那么严重，但该机制将使用户的生活变得复杂。
通过不安全的通道发送包含登录名和密码的表单（未通过 HTTPS 提交登录表单）。
在这种情况下，带有登录名和密码的表单通过未加密的通道从用户发送到服务器。

为什么这很危险：与之前的情况不同，这已经是一个严重漏洞。拦截敏感数据更容易，因为您甚至不需要编写代码来执行此操作。
使用具有已知漏洞的 JavaScript 库。
在扫描过程中，最常用的库是 jQuery，其版本数量非常多。每个版本都至少有一个甚至更多已知漏洞。根据漏洞的性质，影响可能会有很大不同。

为什么这很危险：存在针对已知漏洞的利用，例如：

Web 开发人员应该记住什么：定期返回循环：搜索已知漏洞-修复-检查。如果您故意使用旧库，例如为了支持较旧的浏览器或为了省钱，请寻找修复已知漏洞的机会。
跨站脚本（XSS）。
跨站点脚本 (XSS) 或跨站点脚本是对 Web 应用程序的攻击，会导致恶意软件被引入数据库。如果Qualys发现这样的漏洞，则意味着潜在的攻击者可以或已经将自己的js脚本引入到站点代码中来执行恶意操作。

存储型 XSS 更危险的是，因为该脚本嵌入在服务器上，并且每次在浏览器中打开受攻击的页面时都会执行该脚本。

反射式 XSS 由于可以将恶意脚本注入到 HTTP 请求中，因此更容易执行。应用程序将收到 HTTP 请求，不会验证数据，将其打包并立即发送。如果攻击者拦截流量并插入如下脚本
```
<script>/*+что+то+плохое+*/</script> 
```
那么恶意请求将代表客户端发送。

一个引人注目的 XSS 例子：js 嗅探器模拟输入 CVC、卡到期日期等页面。

Web 开发人员应该记住什么：在 Content-Security-Policy 标头中，使用 script-src 属性强制客户端浏览器仅从受信任的源下载和执行代码。例如，script-src 'self' 仅将我们网站上的所有脚本列入白名单。
最佳实践是内联代码：仅允许内联 javascript 使用 unsafe-inline 值。该值允许使用内联js/css，但不禁止包含js文件。与 script-src 'self' 结合使用，我们可以禁用外部脚本的执行。

请务必使用 report-uri 记录所有内容，并查看将其实施到站点中的尝试。
SQL注入。
该漏洞表明可能将 SQL 代码注入到直接访问网站数据库的网站中。如果不筛选来自用户的数据，则可能发生 SQL 注入：不检查其正确性并立即在查询中使用。例如，如果网站上的表单不检查输入是否与数据类型匹配，就会发生这种情况。

为什么这很危险：如果攻击者在此表单中输入 SQL 查询，他可能会导致数据库崩溃或泄露机密信息。

Web 开发人员应该记住什么：不要相信来自浏览器的内容。您需要在客户端和服务器端保护自己。

在客户端，使用 JavaScript 编写字段验证。

流行框架中的内置函数也有助于逃避服务器上的可疑字符。还建议在服务器上使用参数化数据库查询。

确定与数据库的交互到底发生在 Web 应用程序上的何处。

当我们收到任何信息时就会发生交互：带有 id 的请求（id 的更改）、新用户的创建、新评论或数据库中的新条目。这就是 SQL 注入可能发生的地方。即使我们从数据库中删除一条记录，SQL注入也是可能的。

一般建议

不要重新发明轮子——使用经过验证的框架。一般来说，流行的框架更安全。对于 .NET - ASP.NET MVC 和 ASP.NET Core，对于 Python - Django 或 Flask，对于 Ruby - Ruby on Rails，对于 PHP - Symfony、Laravel、Yii，对于 JavaScript - Node.JS-Express.js，对于 Java - 春季MVC。

关注供应商更新并定期更新。他们会发现一个漏洞，然后编写一个漏洞利用程序，将其公开发布，然后一切都会再次发生。订阅软件供应商的稳定版本更新。

检查权限。在服务器端，始终将您的代码从第一个字母到最后一个字母视为是由您最讨厌的敌人编写的，他们想要破坏您的网站，破坏您数据的完整性。而且，有时确实如此。

使用克隆、测试站点，然后将它们用于生产。首先，这将有助于避免生产环境中的错误和错误：生产环境带来金钱，简单的生产环境至关重要。添加、修复或解决任何问题时，值得在测试环境中工作，然后检查发现的功能和漏洞，然后计划在生产环境中工作。

保护您的 Web 应用程序 Web应用防火墙并将漏洞扫描器的报告与其集成。例如，DataLine 使用 Qualys 和 FortiWeb 作为服务包。

来源： habr.com

网站安全的致命罪过：我们从今年的漏洞扫描统计数据中学到了什么

最重要的“非关键”漏洞

严重漏洞

一般建议

添加评论 取消回复

添加评论取消回复