想象一下，你登录了 bank.com 网站。此时：您有网站的身份验证 cookie。每次请求时，您的浏览器都会到 bank.com，为了识别你，并执行所有敏感的财务操作。

现在，当你在另一个窗口浏览网页时，你不小心访问了另一个网站 evil.com。该网站有向 bank.com 该网站提交了具有开始与黑客账户交易字段的表格 <form action="https://bank.com/pay"> 的 JavaScript 代码。

你每次访问 bank.com 时，浏览器都会发送 cookie，即使表单是从 evil.com 提交。因此，银行会识别你的身份并实施真实付款。

这是跨网站要求伪造伪造（Cross-Site Request Forgery，简称 XSRF）”攻击。

当然，实际银行会防止这种情况。一切都是由 bank.com 生成的表单有一个特殊的字段，即所谓的 “XSRF 保护 token恶意页面既不能生成，也不能从远程页面提取（它可以在那里提交表格，但不能获取数据）。而且，网站 bank.com 收到的每个表单都会这样做 token 的检查。

然而，实现这种保护需要时间：我们需要确保每个表单都有 token 还必须检查所有请求。

Cookie 的 samesite 选项提供了另一种防止此类攻击的方式，（理论上）不需要要求 “XSRF 保护 token”。

它有两个可能的值：

• samesite=strict(和没有价值 samesite 一样)

如果用户来自同一个网站，则设置它 samesite=strict 的 cookie 永远不会被发送。

换句话说，无论用户是通过邮件链接还是从 evil.com 从其他域下提交表格或进行任何操作，cookie 不会发送。

若身份验证 cookie 具有 samesite 选项，那么 XSRF 攻击没有成功的机会，因为它来自 evil.com 的提交没有 cookie。因此，bank.com 将无法识别用户，也不会继续付款。

这种保护相当可靠。 bank.com 只发送操作 samesite cookie，例如来自 bank.com 提交另一页的表格。

虽然，这样有一些不方便。

当用户通过合法链接访问时 bank.com 例如，他们会对自己的笔记感到惊讶，bank.com 他们的身份无法识别。事实上，在这种情况下不会发送 samesite=strict cookie。

我们可以用两个 cookie 解决这个问题：一个 cookie 仅用于一般识别 “Hello, John另一个带 samesite=strict 的 cookie 用于数据更改。这样，来自网站外的用户就会看到欢迎信息，但支付操作必须从银行网站开始，这是第二个 cookie 只能发送。

• samesite=lax

一种更容易防止的方法 XSRF 不会破坏用户体验的攻击。

宽松（lax）模式，和 strict 类似的模式，当从外部到网站时，禁止浏览器发送 cookie，但是增加了一个例外。

如果建立了以下两个条件，它们将被发送 samesite=lax 的 cookie：

这个选项和 JavaScript 没有关系，但是我们必须为了完整性也提一下它。

Web 服务器使用 Set-Cookie header 来设置 cookie。并且，它可以设置 httpOnly 选项。

这个选项禁止任何 JavaScript 访问 cookie。我们使用 document.cookie 看不到此类 cookie，也无法对此类 cookie 进行操作。

这是一种预防措施，当黑客将自己的 JavaScript 代码注入网页，并等待用户访问该页面时发起攻击，而这个选项可以防止此时的这种攻击。这应该是不可能发生的，黑客应该无法将他们的代码注入我们的网站，但是网站有可能存在 bug，使得黑客能够实现这样的操作。

通常来说，如果发生了这种情况，并且用户访问了带有黑客 JavaScript 代码的页面，黑客代码将执行并通过 document.cookie 获取到包含用户身份验证信息的 cookie。这就很糟糕了。

但是，如果 cookie 设置了 httpOnly，那么 document.cookie 则看不到 cookie，所以它受到了保护。

CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开。跟验证码类似，只是用户无感知。

• 服务端给用户生成一个token，加密后传递给用户
• 用户在提交请求时，需要携带这个token
• 服务端验证token是否正确

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

• 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
• 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
• 盗窃企业重要的具有商业价值的资料
• 非法转账
• 强制发送电子邮件
• 网站挂马
• 控制受害者机器向其它网站发起攻击

**主要原因：**过于信任客户端提交的数据！

**解决办法：**不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

**进一步分析细节：**客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！！！

漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)，例如，正常发送消息：

http://www.test.com/message.php?send=Hello,World！

接收者将会接收信息并显示Hello,World；但是，非正常发送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息显示的时候将会弹出警告窗口！

XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。与非持久性XSS攻击相比，持久性XSS攻击危害性更大。从名字就可以了解到，持久性XSS攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

例如，留言板表单中的表单域：
<input type=“text” name=“content” value=“这里是用户填写的数据”>

正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示；而非正常操作流程是攻击者在value填写:

基于 Flash 的跨站 XSS 也是属于反射型 XSS 的一种，虽然现在开发 ActionScript 的产品线几乎没有了，但还是提一句吧，AS 脚本可以接受用户输入并操作 cookie，攻击者可以配合其他 XSS（持久型或者非持久型）方法将恶意 swf 文件嵌入页面中。主要是因为 AS 有时候需要和 JS 传参交互，攻击者会通过恶意的 XSS 注入篡改参数，窃取并操作cookie。

避免方法：

• 严格管理 cookie 的读写权限
• 对 Flash 能接受用户输入的参数进行过滤 escape 转义处理

有一些场景是后端需要对一个传进来的待跳转的 URL 参数进行一个 302 跳转，可能其中会带有一些用户的敏感（cookie）信息。如果服务器端做302 跳转，跳转的地址来自用户的输入，攻击者可以输入一个恶意的跳转地址来执行脚本。

这时候需要通过以下方式来防止这类漏洞：

• 对待跳转的 URL 参数做白名单或者某种规则过滤
• 后端注意对敏感信息的保护, 比如 cookie 使用来源验证。

漏洞产生的根本原因是 太相信用户提交的数据，对用户所提交的数据过滤不足所导致的，因此解决方案也应该从这个方面入手，具体方案包括：

• 将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能 获取到cookie了（如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击）；

• 表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合。。。。

• 对数据进行Html Encode 处理

• 过滤或移除特殊的Html标签，例如:

需要注意的是，在有些应用中是允许html标签出现的，甚至是javascript代码出现。因此，我们在过滤数据的时候需要仔细分析哪些数据是有特殊要求（例如输出需要html代码、javascript代码拼接、或者此表单直接允许使用等等），然后区别处理！

SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

(1). 寻找到SQL注入的位置 　　(2). 判断服务器类型和后台数据库类型 　　(3). 针对不通的服务器和数据库特点进行SQL注入攻击

比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：

用户名： ‘or 1 = 1 --
密 码：

用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?下面我们分析一下：从理论上说，后台认证程序中会有如下的SQL语句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，当输入了上面的用户名和密码，上面的SQL语句变成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL语句我们知道， username=‘ or 1=1 这个语句一定会成功；然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。

(1). 参数绑定

使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中，对于传递的参数我们一般是使用#和KaTeX parse error: Expected 'EOF', got '#' at position 11: 来获取参数值。当使用#̲时，变量是占位符，就是一般我们…时，变量就是直接追加在sql中，一般会有sql注入问题。

(2). 使用正则表达式过滤传入的参数

• 客户端向服务端发送请求链接数据包
• 服务端向客户端发送确认数据包
• 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

• 限制同时打开SYN半链接的数目
• 缩短SYN半链接的Time out 时间
• 关闭不必要的服务

流量劫持应该算是黑产行业的一大经济支柱了吧？简直是让人恶心到吐，不吐槽了，还是继续谈干货吧，流量劫持基本分两种：DNS 劫持 和 HTTP 劫持，目的都是一样的，就是当用户访问 zoumiaojiang.com 的时候，给你展示的并不是或者不完全是 zoumiaojiang.com 提供的 “内容”。

DNS 劫持，也叫做域名劫持，可以这么理解，「你打了一辆车想去商场吃饭，结果你打的车是小作坊派来的，直接给你拉到小作坊去了」，DNS 的作用是把网络地址域名对应到真实的计算机能够识别的 IP 地址，以便计算机能够进一步通信，传递网址和内容等。如果当用户通过某一个域名访问一个站点的时候，被篡改的 DNS 服务器返回的是一个恶意的钓鱼站点的 IP，用户就被劫持到了恶意钓鱼站点，然后继而会被钓鱼输入各种账号密码信息，泄漏隐私。

这类劫持，要不就是网络运营商搞的鬼，一般小的网络运营商与黑产勾结会劫持 DNS，要不就是电脑中毒，被恶意篡改了路由器的 DNS 配置，基本上做为开发者或站长却是很难察觉的，除非有用户反馈，现在升级版的 DNS 劫持还可以对特定用户、特定区域等使用了用户画像进行筛选用户劫持的办法，另外这类广告显示更加随机更小，一般站长除非用户投诉否则很难觉察到，就算觉察到了取证举报更难。无论如何，如果接到有 DNS 劫持的反馈，一定要做好以下几件事：

• 取证很重要，时间、地点、IP、拨号账户、截屏、URL 地址等一定要有。
• 可以跟劫持区域的电信运营商进行投诉反馈。
• 如果投诉反馈无效，直接去工信部投诉，一般来说会加白你的域名。

HTTP 劫持您可以这么理解，「你打了一辆车想去商场吃饭，结果司机跟你一路给你递小作坊的广告」，HTTP 劫持主要是当用户访问某个站点的时候会经过运营商网络，而不法运营商和黑产勾结能够截获 HTTP 请求返回内容，并且能够篡改内容，然后再返回给用户，从而实现劫持页面，轻则插入小广告，重则直接篡改成钓鱼网站页面骗用户隐私。能够实施流量劫持的根本原因，是 HTTP 协议没有办法对通信对方的身份进行校验以及对数据完整性进行校验。如果能解决这个问题，则流量劫持将无法轻易发生。所以防止 HTTP 劫持的方法只有将内容加密，让劫持者无法破解篡改，这样就可以防止 HTTP 劫持了。

HTTPS 协议就是一种基于 SSL 协议的安全加密网络应用层协议，可以很好的防止 HTTP 劫持。

“点击劫持”攻击允许恶意页面 以用户的名义 点击“受害网站”。

许多网站都被黑客以这种方式攻击过，包括 Twitter、Facebook 和 Paypal 等许多网站。当然，它们都已经被修复了。

原理十分简单。

我们以 Facebook 为例，解释点击劫持是如何完成的：

1. 访问者被恶意页面吸引。怎样吸引的不重要。
2. 页面上有一个看起来无害的链接（例如：“变得富有”或者“点我，超好玩！”）。
3. 恶意页面在该链接上方放置了一个透明的 <iframe>，其 src 来自于 facebook.com，这使得“点赞”按钮恰好位于该链接上面。这通常是通过 z-index 实现的。
4. 用户尝试点击该链接时，实际上点击的是“点赞”按钮。

最古老的防御措施是一段用于禁止在 frame 中打开页面的 JavaScript 代码（所谓的 “framebusting”）。

它看起来像这样：

if (top != window) { 
        
  top.location = window.location;
}

意思是说：如果 window 发现它不在顶部，那么它将自动使其自身位于顶部。

这个方法并不可靠，因为有许多方式可以绕过这个限制。下面我们就介绍几个。

阻止顶级导航

我们可以阻止因更改 beforeunload 事件处理程序中的 top.location 而引起的过渡（transition）。

顶级页面（从属于黑客）在 beforeunload 上设置了一个用于阻止的处理程序，像这样：

window.onbeforeunload = function() { 
        
  return false;
};

当 iframe 试图更改 top.location 时，访问者会收到一条消息，询问他们是否要离开页面。

在大多数情况下，访问者会做出否定的回答，因为他们并不知道还有这么一个 iframe，他们所看到的只有顶级页面，他们没有理由离开。所以 top.location 不会变化！

X-FRAME-OPTIONS是微软提出的一个http头，专门用来防御利用iframe嵌套的点击劫持攻击。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。

可以设置为以下值:

• DENY: 拒绝任何域加载
• SAMEORIGIN: 允许同源域下加载
• ALLOW-FROM: 可以定义允许frame加载的页面地址

sandbox 特性的限制之一就是导航。沙箱化的 iframe 不能更改 top.location。

但我们可以添加具有 sandbox="allow-scripts allow-forms" 的 iframe。从而放开限制，允许脚本和表单。但我们没添加 allow-top-navigation，因此更改 top.location 是被禁止的。

代码如下：

<iframe sandbox="allow-scripts allow-forms" src="facebook.html"></iframe>