浅析history hack、心血漏洞、CSS欺骗、SQL注入与CSRF攻击

漏洞产生的缘由主要有系统机制和编码规范两方面，因为网络协议的开放性，目前以 Web 漏洞居多

---

关于系统机制漏洞的典型有JavaScript/CSS history hack，而编码规范方面的漏洞典型有心血漏洞（Heart Bleed）。
在对漏洞概念有必定了解后，将搭建一个测试网站，对CSS欺骗、SQL注入与CSRF攻击进行实验测试。

JavaScript/CSS history hack 漏洞

漏洞影响：攻击者可以获取用户浏览器的某些历史记录。

攻击原理：利用浏览器自动查询历史记录，以及CSS对访问过的和未访问过超连接样式的不一样渲染。好比 百度 这个连接是紫色，由于你最近访问过百度。而 自建CA证书搭建https服务器 这个连接是黑色，由于你当前没有访问过我上一篇博客。若是是紫色，删除访问历史后刷新会变成黑色。

攻击方法：因为JavaScript能够读取任何元素的CSS信息，因此能分辨浏览器应用了哪一种样式从而判断用户是否访问过该连接。攻击者能够搭建本身的网站，在上面定义一些网站的超连接。当其余用户访问该网站时，浏览器会自动根据用户的历史记录判断哪些网址曾经访问过，从而以不一样颜色呈现给用户。

攻击者的网站后台能够将用户访问过的网站发回给服务器，达到的效果是可以检测用户是否访问过某个网站，但并非直接获取用户访问的历史记录。

该漏洞已被修复，现在虽然可以看到对超连接状态的不一样显示，可是js已没法获取到其中的颜色差别。

Heart Bleed漏洞

又称为心脏出血漏洞，编号(CVE-2014-0160)

漏洞由来：该漏洞由谷歌白帽子尼尔·梅塔（Neel Mehta）提出，他可从特定服务器上随机获取64k的工做日志，整个过程如同钓鱼，攻击能够一次次持续进行，大量敏感数据会泄露。

产生缘由：编码时未能在memcpy()调用用户输入的内容前，对长度进行边界检查。攻击者能够输入超出范围的字节，再返回等长的缓存内容。

攻击方法：
OpenSSL有一个叫 Heartbeat（心跳检测）的拓展，所谓心跳检测，就是创建一个 Client Hello 问询来检测对方服务器是否是正常在线，服务器发回 Server hello，代表SSL通信正常。就像咱们打电话时会问对方 “喂听获得吗？”同样。
刚才测试超连接的博客有关于SSL与https的介绍

每次问询都会附加一个问询的字符长度，若是这个字符长度大于实际的长度，服务器还是会返回相同规模的字符信息，因而造成了内存里信息的越界访问。

漏洞影响：每发起一个心跳，服务器就能泄露一点点数据（理论上最多泄露 64K），这些数据里可能包括用户的登陆帐号密码、电子邮件甚至是加密密钥等信息，也可能并无包含这些信息，但攻击者能够不断利用 “心跳”来获取更多的信息。就这样，服务器一点一点泄露愈来愈多的信息，就像是心脏慢慢在出血，心脏出血的名字由此而来，漏洞目前已修复，但该漏洞被提出以前是否已被利用就不得而知。

---

以上是两种类型漏洞的简单介绍，如下将对CSS欺骗、SQL注入与CSRF攻击进行实验

---

CSS欺骗

正如名字同样，CSS欺骗主要是做为一种欺骗手段，给浏览器用户呈现出虚假信息。

虽然是很简单的手段，可是应用却十分普遍

欺骗原理：经过CSS定位方式和伪类，实现网页内容覆盖

html如人的骨骼，css是外表装饰，js控制页面的效果相似神经，CSS欺骗主要是利用CSS对页面的渲染。

定位方式和伪类简介

CSS对网页元素的定位方式有如下四种：

• 静态定位（static）：全部元素的默认定位方式，能够将元素定位于静态位置，所谓静态位置就是各个元素在HTML文档流中默认的位置。
• 相对定位（relative）：不脱离文档流，参考自身静态位置经过 top,bottom,left,right定位，而且能够经过z-index进行层次分级。
• 绝对定位（absolute）：脱离文档流，经过 top,bottom,left,right 选取其最近的父级元素定位，当父级 position 为 static 时，absolute元素将以body坐标原点进行定位，能够经过z-index进行层次分级。
• 固定定位（fixed）：所固定的对象是当前可视窗口（浏览器窗口）而并不是是body或是父级元素，页面滚动也不会移动，可经过z-index进行层次分级。

经常使用定位方式：子绝父相

• 当子元素是绝对定位时，父元素采用相对定位，这样父容器既能够在原文档流中保留位置，子元素也能参照父容器绝对定位。

CSS伪类能够与 CSS 类配合使用，有anchor伪类、first-child伪类等。

如anchor伪类：

• a:link {color:#FF0000;} /* 未访问的连接 */
• a:visited {color:#00FF00;} /* 已访问的连接 */
• a:hover {color:#FF00FF;} /* 鼠标划过连接 */
• a:active {color:#0000FF;} /* 已选中的连接 */

欺骗案例：早年的淘宝店铺装修直接使用css控制页面显示效果，有商户就此制做虚假店铺信息。

如下是2012年先后的一家店铺信息

图中所呈现的信息并不是真实的店铺信息。

30天销售量实际值为0，经过店铺装修时设置背景图，呈现出了580件的字样。

“购物须知”被背景图假装成了 “优质商家 7天无理由退换”。

评价详情与成交记录一样是使用背景图进行虚假宣传。

实际并无买家评价，只是添加了背景图片。

为何说CSS欺骗虽然简单可是应用普遍？

就我的网页浏览经历而言，在4G以前或者4G刚开始那个时候，这种利用图片作虚假页面是很常见的。

最近一次是2018年双十一时候，在某电商平台申请退款，商家一直不理会，在平台进行投诉时发现提交投诉的按钮怎么点都没反应。一开始觉得是手机显示不兼容，后来发现那个页面下半部分是张图片，提交按钮只是图片的一部分。

不过双十一也能够理解，可是就大多数没什么计算机基础的网民而言，CSS欺骗仍是颇有效的。

下面将会先介绍SQL注入，而后再将CSS欺骗与SQL注入结合，在搭建的测试网站上实现利用SQL注入前端代码进行CSS欺骗。

SQL注入

SQL注入便是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者能够在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的状况下实现非法操做，是目前最多见危险的漏洞之一。

SQL注入不是一个过时的安全问题，偏偏相反，它是一种很是容易被使用的攻击方式，SQL注入并不须要高深的攻击手段即可以轻易使敏感的数据库信息被非法浏览或删除。

通常注入过程：

1. SQL注入点探测。
   经过适当的分析应用程序，判断什么地方存在SQL注入点。一般只要带有输入提交的动态网页，而且动态网页访问数据库，就可能存在SQL注入漏洞。
2. 收集后台数据库信息。
   不一样数据库的注入方法、函数都不尽相同，在注入以前先要判断一下数据库的类型。能够输入特殊字符如单引号，让程序返回错误信息，根据错误信息提示进行判断；还可使用特定函数来判断，好比输入“1 and version（）>0”，程序返回正常说明version（）函数被数据库识别并执行，而version（）函数是MySQL特有的函数，所以能够推断后台数据库为MySQL。
3. 猜解用户名和密码。
   数据库中的表和字段命名通常都是有规律的，经过构造特殊SQL语句在数据库中依次猜解出表名、字段名、字段数、用户名和密码。

网站搭建与SQL注入测试

若是有简单网站的搭建经验，只须要理解了SQL注入的原理，就能够构建本身的测试。
下图是搭建的测试网站的登录界面：

先注册一个userA的帐号并登陆：

网站有三个简单的页面，分别是Home、Users、Transfer：

• Home: 显示用户的zoobars（当前网站用户的虚拟货币）数量，设置用户的我的简介。
  
• Users：能够搜索其余用户并显示用户财富和简介。
  
• Transfer：能够将本身的zoobars转给其余用户。
  

如下有两种SQL注入可使得本身的zoobars变多：

1. 经过填写我的简介修改本身的zoobars，会改动数据库zoobars数量
2. 经过填写我的简介注入CSS代码，使得别人搜索本身时zoobars看上去变多，不会改动数据库zoobars数量

方法一

注入代码：

userA的我的简介', Zoobars='20

保存我的简介后刷新页面，userA的zoobars变成了20，简介显示“userA的我的简介”：

这种方法直接改动了数据库数据，后台更新我的简介的php代码以下：

<?php
  if($_POST['profile_submit']) {  // Check for profile submission
    $profile = $_POST['profile_update'];
    $sql = "UPDATE Person SET Profile='$profile' ".
           "WHERE PersonID=$user->id";
    $db->executeQuery($sql);      // Overwrite profile in database
  }
  $sql = "SELECT Profile FROM Person WHERE PersonID=$user->id";
  $rs = $db->executeQuery($sql);
  $rs = mysqli_fetch_array($rs);
  echo $rs["Profile"];
?>

第四、5行的$sql值是数据库要执行的语句，方法1使得实际执行的sql语句变成了：

UPDATE Person SET Profile='userA的我的简介', Zoobars='20' WHERE PersonID=userA

方法二

因为场景不一样，有时候会使用方法二注入，仅修改网页的显示进行CSS欺骗：

userA的zoobars数量是20，经过SQL注入前端代码，可使得这个网站的用户在搜索userA时看到的数量为200，这里为了方便观察，欺骗的字体设置了红色。

注入代码：

<span style="color:#000000;position:relative;left:60px;top:-54px;">0</span>

与以前介绍淘宝商家用CSS直接设置背景图片不一样，这里是经过SQL注入在我的简介里写了个相对定位的标签，当网站用户搜索userA的我的简介时，我的简介里的html代码会被浏览器解释渲染成数字0，并显示在zoobars数量的后面。

下面将介绍与浏览器机制相关的另外一种攻击方式。

CSRF攻击

CSRF（Cross-site request forgery），即跨站请求伪造。

引诱浏览器用户访问本身的攻击网站进行跨站访问，经过浏览器保存用户原网站cookie的机制，在攻击网站获取用户的身份权限并伪造请求进行攻击。

浏览器机制：

当用户登陆某一网站后，本地会保存一份cookie用于身份认证，若是cookie没有过时，就不须要反复进行登陆操做。

与JavaScript/CSS history hack不一样的是，CSRF暂时没法像修改CSS或JS引擎那样进行漏洞修补，由于目前的浏览器须要这种机制。

场景模拟：程序员登陆博客园浏览博客，发现一篇不错的博客后打算分享到朋友圈，但第一次分享时网页会要求先登陆朋友圈。当登陆分享成功后，没过多久程序员又发现一篇不错的博客，打算再次分享，以此往复循环，浏览器会怎么作？

目前浏览器的机制是会在第一次登录后保存用户的cookie，使得用户在有效期内没必要反复认证身份，因此后续的跨站不须要再登陆。（没有实际操做过，也可能博客园分享每次都须要登陆，只是举个例子模拟网页跨站情景）

浏览器保存cookie的机制是须要的，但同时给了攻击者可乘之机。

web中用户身份验证的漏洞：

简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求自己是用户自愿发出的。

也就是说，用户的浏览器发送了一条请求，同时浏览器的cookie也能证实用户身份，可是并不能保证这条请求是用户主动在原网站上进行的操做。

以搭建的网站为例进行攻击演示

攻击步骤：

1. 搭建一个网页，用于伪造请求，请求内容是从被攻击者的帐户转1个zoobar到本身帐户
2. 在攻击者申请的网站帐户里，填写我的简介，SQL注入一个本身的网站链接
3. 诱导其余用户点击攻击者帐号我的简介上的网页连接进行攻击

搭建网页

原网页与代码：

Transfer界面点击Send按钮会发送一条请求，执行转帐操做。

攻击者须要制做一个本身的网站，在网站上编写攻击操做。
这里直接将原网站的界面代码复制了一份，而后Send的金额写入默认值1，转帐对象默认设置成攻击者的userA帐户，再经过JS代码让网站在加载时自动执行Send按钮的提交操做。

攻击网页与代码：

虽然看上去同样，可是经过浏览器地址能够看出这个另外一个网页，用来模拟进行攻击的网站。

而后在我的简介里注入一个超连接：

<a href="https://localhost/myzoo/send.php">点击获取</a>

网址是攻击者本身的网站

这时其余用户搜索userA时，会看到以下简介：

目前userB的zoobars数量为9，若是点击一下这个连接，会跳转到攻击者网站并自动给userA转一个zoobar，以后userA的数量变成21个，userB只剩下8个。


攻击实际上就是经过用户浏览器保存的cookie认证，伪造出用户请求。

应对CSRF攻击的方法有不少，有一种是能够经过检查请求的Referer字段判断请求的来源网站，不过这是一个攻防的过程，攻击者也有可能进一步攻击篡改Referer字段。

小结

• JavaScript/CSS history hack
  利用了浏览器为了方便用户浏览而查询历史记录的机制漏洞，已经过完善CSS/JS修补。
• 心血漏洞
  代码不规范引发的数据泄露漏洞，已被修补。
• CSS欺骗
  经常使用的欺骗技术，须要根据特定场景结合其余攻击方式。
• SQL注入
  最多见安全漏洞之一，数据泄露的主要缘由之一，安全风险较高，必定程度上超过缓冲区溢出漏洞，只能尽可能避免。
• 跨站请求伪造 利用浏览器的机制漏洞，没法直接根治，与SQL注入同样是个攻防的过程。