安全问题汇总

无标签
网络
发布日期:   2021-03-15
文章字数:   7.9k
阅读次数:  

前言

Egg的网络安全介绍

1.XSS

什么是XSS

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击，通过注入恶意脚本，，使之在用户浏览器上运行，然后利用这些恶意脚本，攻击者可以获取用户的敏感信息Cookie、SessionID等

web安全模型是基于同源策略的，但是XSS攻击通过诱使站点与预期内容一起提供恶意代码来绕过同源策略。这是一个巨大的问题，因为浏览器相信页面上显示的所有代码都是该页面安全来源的合法部分。

XSS 常见的注入方法：

  • 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
  • 在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
  • 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
  • 在标签的 href、src 等属性中，包含 javascript: (伪协议)等可执行代码。
  • 等等。。。。

XSS攻击类型

存储型XSS，它是最危险的一种跨站脚本，相比反射型XSS和DOM型XSS具有更高的隐蔽性，所以危害更大

  • 攻击者将恶意代码提交到目标网站数据库中
  • 客户端最后从服务器得到的就是恶意代码，在浏览器执行的也是该恶意代码
  • 恶意代码将用户数据发送至攻击者网站

反射型XSS（有点像那种色情小广告，点进去你就没了）

  • 攻击者构建特殊URL，里面包含恶意代码
  • 当用户打开此URL时，网站的服务端将恶意代码从中取出，并且拼接在HTML返回给浏览器（这应该属于后端渲染范围）
  • 恶意代码被浏览器执行，然后将用户数据发送给攻击者网站

DOM型XSS（感觉和反射型XSS很像，只不过这个是属于JavaScript的安全漏洞（浏览器的DOM解析），反射型XSS时属于服务端的安全漏洞），所以防范DOM型XSS是前端的责任

  • 同样的，攻击者构造特殊URL，其中包含恶意代码
  • 用户打开后，浏览器解析，JavaScript取出URL然后执行
  • 恶意代码被浏览器执行，然后将用户数据发送给攻击者网站

实际案例：

<a href\="javascript:alert('xss')"\>click me</a\>
<p onclick="alert('xss')">this is a text</p>
<img src="xxx.com/test.jpg" onerror="alert('xss')"/>

甚至是CSS

<div style="background:url(javacript:alert('xss'))">

防范XSS

常用的防范手段：

  • httpOnly: 在 cookie 中设置 HttpOnly 属性后，js脚本将无法读取到 cookie 信息。
  • 输入过滤: 一般是用于对于输入格式的检查，例如：邮箱，电话号码，用户名，密码……等，按照规定的格式输入。
  • 转义 HTML: 如果拼接 HTML 是必要的，就需要对于引号，尖括号，斜杠进行转义（比如 将 > 转译为 &gt;）
  • 添加白名单：对于显示富文本来说，以上方法可能会将需要的格式也过滤掉，这时我们可以添加白名单的方式，其实也就是对匹配到的字段进行处理

预防存储型XSS和反射型XSS攻击：

  • 纯前端渲染（这样就不会拼接html返回了）
  • 同上面常用的防范手段一样的转义html

预防DOM型XSS攻击

DOM型XSS攻击实际上是JavaScript代码本身不够严谨，

  • .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。（尽量避免这种直接插入式的写法）
  • Vue的 v-html也容易导致xss攻击（原理也是innerHTML），与此同时，v-html也会替换掉标签内部子元素，所以 v-html尽量别用
  • 减少eval()的使用

添加白名单防范XSS

https://jsxss.com/zh/index.html

一个添加白名单进行过滤防范XSS攻击的工具，它的名字也叫做XSS

安装和使用

$ npm install xss --save

node端使用

var xss = require('xss');
console.log(xss('<a href="#" onclick="alert(/xss/)">click me</a>'));

浏览器端使用

console.log(filterXSS('<a href="#" onclick="alert(/xss/)">click me</a>'));

当然除了XSS过滤工具，还有Sanitizer这个API，可以配置白名单，黑名单，但兼容性很差

1.5 CSP

内容安全策略( CSP )

内容安全策略 (CSP) 是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS (en-US)) 和数据注入攻击等

通过第三方注入代码，浏览器无法识别哪个网站ok哪个网站不ok，而csp就是来定义HTTP 标头，它允许您创建受信任内容来源的允许列表，并指示浏览器仅执行或呈现来自这些来源的资源。即使攻击者可以找到注入脚本的漏洞，该脚本也不会匹配白名单，因此不会被执行。

CSP 本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。

使用（开启 CSP）

  1. 设置 HTTP Header 中的 Content-Security-Policy（有时你会看到一些关于X-Content-Security-Policy头部的提法, 那是旧版本，你无须再如此指定它）

    • Content-Security-Policy: policy

    policy参数是一个包含了各种描述你的CSP策略指令的字符串。

    使用案例：

    示例 1

    一个网站管理者想要所有内容均来自站点的同一个源 (不包括其子域名)

    Content-Security-Policy: default-src 'self'

    示例 2

    一个网站管理者允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)

    Content-Security-Policy: default-src 'self' *.trusted.com

    示例 3

    一个线上银行网站的管理者想要确保网站的所有内容都要通过SSL方式获取，以避免攻击者窃听用户发出的请求。

    Content-Security-Policy: default-src https://onlinebanking.jumbobank.com

    该服务器仅允许通过HTTPS方式并仅从onlinebanking.jumbobank.com域名来访问文档。

    示例 4

    Content-Security-Policy: script-src 'self'; object-src 'none';
style-src cdn.example.org third-party.org; child-src https:
    • 脚本：只信任当前域名
    • <object>标签：不信任任何URL，即不加载任何资源
    • 样式表：只信任cdn.example.org和third-party.org
    • 框架（frame）：必须使用HTTPS协议加载
    • 其他资源：没有限制

    每个限制选项可以设置以下几种值，这些值就构成了白名单。

    • 主机名：example.org，https://example.com:443
    • 路径名：example.org/resources/js/
    • 通配符：*.example.org，*://*.example.com:*（表示任意协议、任意子域名、任意端口）
    • 协议名：https:、data:
    • 关键字'self'：当前域名，需要加引号
    • 关键字'none'：禁止加载任何外部资源，需要加引号

    更多可以收看阮一峰老师的教程http://www.ruanyifeng.com/blog/2016/09/csp.html

  2. 在HTML的放到head区域设置 meta 标签的方式 <meta http-equiv="Content-Security-Policy">

  3. 或者直接 

    <meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">
    • 这不能用于frame-ancestors、report-uri或sandbox。

各项政策

示例：

script-src它是一个指令，用于控制特定页面的一组与脚本相关的权限

Content-Security-Policy: script-src 'self' https://apis.google.com

虽然脚本资源是最明显的安全风险，但 CSP 提供了一组丰富的策略指令，可以对允许加载页面的资源进行相当精细的控制。

让我们快速浏览其余的资源指令。下面的列表代表了 2级指令的状态。 3 级规范已经发布，但在主要浏览器中基本上没有实现。

  • base-uri限制可以出现在页面<base>元素中的 URL。
  • child-src列出工作人员和嵌入框架内容的 URL。例如：child-src https://youtube.com将启用嵌入来自 YouTube 但不来自其他来源的视频。
  • connect-src限制您可以连接的来源（通过 XHR、WebSockets 和 EventSource）。
  • font-src指定可以提供网络字体的来源。谷歌的网络字体可以通过font-src https://themes.googleusercontent.com.
  • form-action<form>列出从标签提交的有效端点。
  • frame-ancestors指定可以嵌入当前页面的来源。该指令适用于<frame>、<iframe>、<embed>和<applet>标签。该指令不能在<meta>标签中使用，仅适用于非 HTML 资源。
  • frame-src在级别 2 中已弃用，但在级别 3 中恢复。如果不存在，它仍会child-src像以前一样回退。
  • img-src定义可以加载图像的来源。
  • media-src限制允许传送视频和音频的来源。
  • object-src允许控制 Flash 和其他插件。
  • …..

默认情况下，指令是完全开放的。如果您没有为指令设置特定策略，比如说font-src，那么默认情况下，该指令的行为就像您指定*为有效源一样（例如，您可以从任何地方加载字体，没有限制）。

您可以通过指定default-src指令来覆盖此默认行为。该指令定义了您未指定的大多数指令的默认值。通常，这适用于任何以 . 结尾的指令-src。如果default-src设置为https://example.com，并且您未能指定font-src指令，那么您可以从 加载字体https://example.com，而其他任何地方都无法加载。我们仅script-src在前面的示例中指定，这意味着可以从任何来源加载图像、字体等。

更多可以看 https://web.dev/csp/（可惜要翻墙）

其他

  1. 您将在网络上的各种教程中看到X-WebKit-CSP和X-Content-Security-Policy标题。展望未来，您应该忽略这些带前缀的标头。现代浏览器（IE 除外）支持无前缀Content-Security-Policy标头。那是您应该使用的标题。

  2. CSP对于内联代码有所限制，一般来说内联代码被认为是有害的：CSP 是基于允许列表来源的，因为这是一种指示浏览器将特定资源集视为可接受并拒绝其余资源的明确方式。然而，基于来源的白名单并不能解决 XSS 攻击带来的最大威胁：内联脚本注入。如果攻击者可以注入直接包含某些恶意负载 ( <script>sendMyDataToEvilDotCom()</script>) 的脚本标记，则浏览器没有将其与合法的内联脚本标记区分开来的机制。CSP 通过完全禁止内联脚本解决了这个问题：这是唯一可以确定的方法。

    • 比如以下代码 no！no！no！

    • <script>
    function doAmazingThings() {
    alert('YOU AM AMAZING!');
    }
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>

    • 如果不得不使用内联代码，CSP 级别 2 允许您使用加密随机数（使用一次的数字）或哈希将特定的内联脚本添加到允许列表，从而为内联脚本提供向后兼容性。虽然这可能很麻烦，但它在紧要关头很有用。（https://web.dev/csp/）

  3. 假设您运行一个银行网站，并希望确保只有您自己编写的那些资源可以被加载。在这种情况下，从绝对阻止所有内容的默认策略开始 ( default-src 'none')，然后从那里开始构建。

    • 假设银行从位于的 CDN 加载所有图像、样式和脚本https://cdn.mybank.net，并通过 XHR 连接到https://api.mybank.com/以提取各种数据位。使用框架，但仅用于站点本地的页面（无第三方来源）。网站上没有 Flash，没有字体，没有额外内容。我们可以发送的最严格的 CSP 标头是这样的：

    • Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

作用效果

CSP 的主要目标是减少和报告 XSS 攻击 ，XSS 攻击利用了浏览器对于从服务器所获取的内容的信任

CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略所有的其他脚本

2.CSRF

什么是CSRF

CSRF是一种跨站请求伪造，也被称为 one-click-attack 或者 session riding

下面的图源自这个大佬 ： https://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html （随便点开，放心绝对不是XSS或者CSRF ，手动狗头）

触发条件：

  • 用户登录并且信任网站A，并产生cookie
  • 未登出A的情况下，访问网站B（此网站虽然是攻击网站，但是它可能是一个存在其他漏洞的可信任的经常被人访问的网站）

（感觉通俗来讲就是，你在存放重要信息的网站A登录后，没有关闭 且 本地的cookie没有过期，登陆了另外一个（攻击）网站，它就会偷你的cookie，冒充你来操作你网站A的账号）

常见类型

  • Get类型的CSRF
  • POST类型的CSRF
  • 链接类型的CSRF，上面两种打开网页就中招，这种要点击的，比较low

再来一个生动的例子认识CSRF：

用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。

攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。

倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了（此时cookie会根据path和domain发现当前访问域名和银行相同，则携带cookie信息），由此形成CSRF攻击

防御CSRF

  • 验证码；强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 csrf，但是用户体验比较差
  • Referer check：请求来源限制，即同源检测，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险。
  • token：token 验证的 CSRF 防御机制是公认最合适的方案。若网站同时存在 XSS 漏洞的时候，这个方法也是空谈，因为XSS攻击有可能泄露Token * - *

3.劫持

DNS劫持

DNS ： 域名 -> ip地址 ，进行域名解析的服务器

DNS劫持又称域名劫持,是指通过某些手段取得某域名的解析控制权，修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址。

DNS劫持其实并不是真的“黑掉”了对方的网站，而是冒名顶替、招摇撞骗罢了

案例

  • 在查找本机系统是否缓存ip地址时，可能碰到黑客设置绑定好的解析ip（host文件），使得我们到达了一个错误的ip地址（本地DNS劫持）;

  • 亦或者是像《巴西银行钓鱼事件》，黑客利用D-Link路由器的漏洞，更改对应的DNS配置，重新定向到黑客自己搭建的恶意DNS服务器上（DNS解析路径劫持）

（DNS服务器的IP地址，有可能是动态的，每次上网时由网关分配，这叫做DHCP机制；也有可能是事先指定的固定地址。Linux系统里面，DNS服务器的IP地址保存在/etc/resolv.conf文件。）

防止DNS劫持

网络层面：

  • 手动修改DNS
  • 修改路由密码

应用层面：

  • 安装杀毒软件，防御木马病毒和恶意软件；定期修改路由器管理账号密码和更新固件。

  • 有点复杂，可以网上查询（泪。。）

HTTP劫持

你DNS解析的域名的IP地址不变。在和网站交互过程中的劫持了你的请求。在网站发给你信息前就给你返回了请求。

HTTP劫持很好判断，当年正常访问一个无广告的页面时，页面上出现广告弹窗，八成就是运营商劫持了HTTP。

4.SQL注入攻击

什么是SQL注入攻击

sql作为一种解释型语言（数据库语言），在运行时是由一个运行时组件解释语言代码并执行其中包含的指令的语言。基于这种执行方式，产生了一系列叫做代码注入（code injection）的漏洞

程序员在web开发时，没有过滤敏感字符，绑定变量，导致攻击者可以通过sql灵活多变的语法，构造精心巧妙的语句，不择手段，达成目的，或者通过系统报错，返回对自己有用的信息。

个人感觉有点像XSS攻击，都是利用语言漏洞进行代码注入

类似于合成这种永真的语句，让黑客用户登陆成功 select * from users where username='' or 1=1

防御SQL注入

1、预编译，在SQL映射文件中尽量使用#指示符标识参数位置，避免使用$。

2、确认每种数据的类型，比如是数字，数据库则必须使用int类型来存储

3、规定数据长度，能在一定程度上防止sql注入

4、严格限制数据库权限，能最大程度减少sql注入的危害

5、避免直接响应一些sql异常信息，sql发生异常后，自定义异常进行响应

6、过滤参数中含有的一些数据库关键词

5.序列化

反序列化漏洞

简单来说，序列化可以理解为就是将对象转化为字节流，字节流中包括这个对象的数据和信息，序列化和反序列化便于类的持久保存，并且很利于网络传输

而在反序列化处理中，如果攻击者通过构建恶意输入，使得反序列化产生非预期的类或者对象，这个类或者对象就有可能带来任意代码的执行

所以这个问题的根源在于，字节流进行还原时，即用到ObjectInputStream在反序列化时，没有对生成的对象的类型做限制

6.DDos攻击

DOS：Denial of Service，拒绝服务，通过占用网络资源让它应接不暇，从而拒绝正常业务流量的一种网络攻击方式

DDOS：Distributed denial of service，分布式拒绝服务，俗称群殴（单台设备攻击能力有限，但是成百上千设备同时攻击很猛）

发起攻击的网络（组成成百上千设备的攻击网络）称为僵尸网络

这个网络可以通过木马、蠕虫等感染大量设备从而获取僵尸网络（亦或者富人直接买就行了）

DDos攻击可以出现在网络的很多层：

  1. 网络层：霸占服务器网络带宽资源，发送大量的IP协议数据包（比如ping工具，产生ICMP包），这种攻击方式也称为ICMP flood
  2. 除此之外还有 UDP flood
    • 多损的招数：
    • 反射攻击：伪造自身ip地址为攻击目标的地址，然后向大量第三方机器发送请求，然后让第三方机器回复的响应大量涌入攻击目标ip
    • 放大攻击：一次DNS查询，返回的数据往往大于请求数据，根据带宽放大因子，一般60B的请求数据可以获得3000B的返回数据，此时再结合反射攻击，让DNS返回的数据响应到攻击地址上，更加BT（maybe，50倍的攻击效果）
  3. TCP flood，因为有三次握手，所以无法伪装ip
  4. RST洪水攻击，同样是利用TCP协议，一方可以发送RST数据强行切断连接，而不用四次挥手，此时我们让攻击设备不断尝试伪造各种ip地址，发送RST数据，进行盲打，此时有可能可以命中某位xx用户的连接

反击

根治DDos攻击的方法：

  • 网络设备检测ip，过滤掉伪装的ip地址
  • 根据路由转发逻辑，过滤伪装ip

保守治疗：

  • 使用CDN节点
  • 流量清洗设备（有点像保镖），先自己来应答，如果是正常的流量就放行

7.重放攻击

API重放攻击（Replay Attacks）又称重播攻击、回放攻击，这种攻击会不断恶意或欺诈性地重复一个有效的API请求。攻击者利用网络监听或者其他方式盗取API请求，进行一定的处理后，再把它重新发给认证服务器，是黑客常用的攻击方式之一。

百科：

重放攻击的基本原理就是把以前窃听到的数据原封不动地重新发送给接收方。很多时候，网络上传输的数据是加密过的，此时窃听者无法得到数据的准确意义。但如果他知道这些数据的作用，就可以在不知道数据内容的情况下通过再次发送这些数据达到愚弄接收端的目的。例如，有的系统会将鉴别信息进行简单加密后进行传输，这时攻击者虽然无法窃听密码，但他们却可以首先截取加密后的口令然后将其重放，从而利用这种方式进行有效的攻击。

小情景1.0：假设网上存款系统中，一条消息表示用户支取了一笔存款，攻击者完全可以多次发送这条消息而偷窃存款。

小情景2.0：A给B写了一封信，说：“老友，请给我转账100块吧！A敬上。” B照做了，然后有人（不一定是A)复制了一样的信和签名发给B，骗B再转账100块，这是重放攻击（replay attack）。

小情景3.0：一个电子商务网站，要求客户对电子订单签名以防止非授权用户下订单。攻击者如要冒充某位客户下订单，最好可以获得他的私钥，如果不成功，攻击者可以监听这位顾客的通信，将顾客以前发送的订单记录下来，然后他就可以直接将这些订单发给网站了。因为这些订单的确是合法客户签名过的，如果网站没有一种识别重放订单的机制，它就会不加犹豫地接收这些订单。

防御：

(1)加随机数。该方法优点是认证双方不需要时间同步，双方记住使用过的随机数，如发现报文中有以前使用过的随机数，就认为是重放攻击。缺点是需要额外保存使用过的随机数，若记录的时间段较长，则保存和查询的开销较大。
(2)加时间戳 该方法优点是不用额外保存其他信息。缺点是认证双方需要准确的时间同步，同步越好，受攻击的可能性就越小
(3)加流水号，也就是双方在报文中添加一个逐步递增的整数，只要接收到一个不连续的流水号报文(太大或太小)，就认定有重放威胁。

8.SSH

Secure Shell（安全外壳协议，简称SSH）是一种加密的网络传输协议

它的整个过程：

（1）远程主机收到用户的登录请求，把自己的公钥发给用户。

（2）用户使用这个公钥，将登录密码加密后，发送回来。

（3）远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

其实也就是和https的非对称密钥一样，只不过它：不像https协议，

SSH协议的公钥是没有证书中心（CA）公证的，也就是说，都是自己签发的。所以这个机制防止不了“中间人攻击”

解决办法

一、口令登录

第一次登录对方主机的时候，通过它提供的公钥指纹，去自己一一对应远程主机在网站上自己贴出来的公钥指纹，让我们自行核对

当远程主机的公钥被接受以后，它就会被保存在文件$HOME/.ssh/known_hosts之中。下次再连接这台主机，系统就会认出它的公钥已经保存在本地了，从而跳过警告部分，直接提示输入密码。

每个SSH用户都有自己的known_hosts文件，此外系统也有一个这样的文件，通常是/etc/ssh/ssh_known_hosts，保存一些对所有用户都可信赖的远程主机的公钥。

二、公钥登录

先让用户将自己的公钥储存在远程主机上

远程主机发东西过来 -> 用户用私钥加密后再发过去 -> 远程主机用存储好的公钥解密

参考链接：阮一峰https://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html

9.心脏出血漏洞

wiki定义

Heartbleed是OpenSSL加密库中的一个安全漏洞，它是传输层安全(TLS) 协议的广泛使用的实现，无论易受攻击的 OpenSSL 实例是作为 TLS 服务器还是客户端运行，都可以利用 Heartbleed。这是由于在 TLS心跳扩展的实现中输入验证不正确（由于缺少边界检查）造成的。[3]因此，该错误的名称源自heartbeat。[4]该漏洞被归类为缓冲区过度读取 , [5]可以读取的数据多于应允许的数据的情况。[6]

系统管理员经常很慢地修补他们的系统。截至 2014 年 5 月 20 日，在 800,000 个最受欢迎的启用 TLS 的网站中，仍有 1.5% 的网站容易受到 Heartbleed 的攻击。[9]截至 2014 年 6 月 21 日，309,197 台公共网络服务器仍然易受攻击。[10]截至 2017 年 1 月 23 日，根据Shodan的一份报告[11]，仍有近 180,000 台联网设备易受攻击。[12] [13]根据 shodan.io 对“vuln:cve-2014-0160”的搜索，截至 2017 年 7 月 6 日，该数字已降至 144,000 人。[14]截至 2019 年 7 月 11 日，Shodan 报告[15]91,063 台设备易受攻击。美国以 21,258 (23%) 位居第一，前 10 位国家有 56,537 (62%)，其余国家有 34,526 (38%)。该报告还按其他 10 个类别对设备进行了细分，例如组织（前 3 名是无线公司）、产品（Apache httpd、Nginx）或服务（HTTPS，81%）。

除 OpenSSL 之外的 TLS 实现，例如GnuTLS、Mozilla的网络安全服务和TLS 的 Windows 平台实现，都没有受到影响，因为缺陷存在于 OpenSSL 的 TLS 实现中，而不是协议本身。[16]

传播历史

2012年3月14日，OpenSSL 1.0.1版发布，漏洞开始传播。心跳支持默认是启用的，这使受影响的版本易受攻击

实例：早在2014年，互联网安全协议OpenSSL被曝存在一个十分严重的安全漏洞。在黑客社区，它被命名为“心脏出血”，表明网络上出现了“致命内伤”。利用该漏洞，黑客可以获取约30%的https开头网址的用户登录账号密码，其中包括购物、网银、社交、门户等类型的知名网站。今天就为大家带来平台事件规则解读系列第四篇——震惊全球的“心脏出血”漏洞。

具体内容

所谓心跳检测，就是建立一个 Client Hello 问询来检测对方服务器是不是正常在线 ，服务器发回 Server hello，表明正常树立SSL通讯。就像我们打电话时会问对方 “喂听得到吗？”一样。

每次问询都会附加一个问询的字符长度 pad length，bug 来了，如果这个 pad length 大于实际的长度，服务器仍是会回来相同规模的字符信息，于是形成了内存里信息的越界访问。

这是因为OpenSSL的心跳功能缺少了一个至关重要的安全维护手段：受影响的OpenSSL版本根据请求消息中的长度字段分配内存缓冲区，用于存储要返回的消息，而不考虑消息中有效载荷的实际长度。所以计算机接受心跳请求时从不检查该请求和它声称的内容是否一致。

就这样，每发起一个心跳，服务器就能泄露一点点数据（理论上最多泄露 64K），例如，正常的心跳请求可能会要求一方“返回4个字符的单词‘bird’”，那一方就返回“bird”；“心脏出血请求”（恶意的心跳请求）如“返回500个字符的单词‘bird’”会导致受害者返回“bird”，紧接着是恰储存在受害者活跃内存中的496个字符。这样，攻击者便可能会收到敏感数据，从而危及受害者其它安全通信的保密性。虽然攻击者能对返回的内存块大小有所控制，但却无法决定它的位置，因而不能指定要显示内容。

这些数据里可能包括用户的登录账号密码、电子邮件甚至是加密秘钥等信息，也可能并没有包含这些信息，但攻击者可以不断利用 “心跳”来获取更多的信息。就这样，服务器一点一点泄露越来越多的信息，就像是心脏慢慢在出血，心脏出血漏洞的名字由此而来。

漏洞出现的版本

  • heartbleed漏洞主要存在于有心跳机制的OpenSSL协议中。
  • IANA组织把开启心跳扩展机制的SSL数据包type类型定义为24（0x18）。
  • heartbleed漏洞主要存在于TLS和DTLS两种协议中，在含有heartbleed漏洞的OpenSSL协议中需要开启心跳扩展机制（beartbeat），而含有心跳扩展机制的TLS版本主要包含在0（0x0301），TLSv1.1（0x0302），TLSv1.2（0x0303）三种版本中。
  • heartbleed漏洞攻击主要由于攻击者构造异常的心跳数据包，即心跳包中的长度字段与后续的数据字段不相符合，来获取心跳数据所在的内存区域的后续数据。

参考：

心脏出血漏洞wiki

事件分析OPENSSL“心脏出血”漏洞

小错误引发大危机——心脏出血到底是什么？

文章作者: Hello
文章链接: https://taylor12138.github.io/2021/03/15/an-quan-wen-ti-hui-zong/
版权声明: 本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 Hello !
无标签
赏
 上一篇
深入JavaScript内存 深入JavaScript内存
内存概述内存也是有生命周期的，不管什么程序语言，一般可以按顺序分为三个周期： 分配期 分配所需要的内存 使用期 使用分配到的内存（读、写） 释放期 不需要时将其释放和归还 定义变量自动分配内存 绝大部分情况下也不需要手动释放内存
2021-03-21 前端
下一篇 
超文本传输协议new 超文本传输协议new
1.http概述从计算机网络的学习我们了解到：HTTP协议[超文本传输协议]，协议详细规定了浏览器和万维网服务器之间相互通信的规则 http 2.0 使用二进制传输（二进制分帧），减少服务端压力，连接吞吐量更大，改善TCP拥塞状况，同时慢启
2021-03-15 网络
  目录