XSS跨站脚本攻击
现象
XSS（cross site scripting），即跨站点脚本工具，发生在用户的浏览器端。用户输入非法字符，向页面植入恶意代码，在目标网站上执行非原有的脚本。
如果网页会使用用户的输入渲染为HMTL内容渲染时就会执行被植入的恶意代码，利用这些恶意脚本，攻击者可获取用户的敏感信息如Cookie、SessionID等，进而危害数据安全。
XSS的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
分类
一般会分为存储型XSS、反射型XSS和DOM型XSS
（1）存储型XSS
攻击者将恶意代码提交到目标网站的数据库中，用户打开网站时网站将恶意代码从数据库中取出，拼接在HTML中返回给浏览器，在浏览器中执行恶意代码
恶意代码窃取用户数据，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作
这种攻击常见于带有用户保存数据的网站功能，比如论坛发帖、商品评论、用户私信等。
（2）反射型XSS
攻击者构造出包含恶意代码的特殊的URL，用户打开URL后，网站服务端取出URL中的恶意代码，凭借在HTML中返回给浏览器，在浏览器中执行恶意代码
反射型XSS与存储型XSS的区别是，存储型XSS的恶意代码存在数据库，而反射型XSS的恶意代码存在URL中。
反射型XSS攻击常见于通通过URL传递参数的功能，比如网站搜索、跳转等。由于需要用户主动打开URL才能生效，所以攻击者往往会结合多种手段诱导用户点击。
（3）DOM型XSS
攻击者构造出包含恶意代码的特殊的URL，用户打开URL后，JavaScript取出URL中的恶意代码并执行。恶意代码窃取用户数据，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
DOM型XSS与前两种区别是，DOM型XSS的取出和执行恶意代码都有浏览器端完成，属于前端JavaScript自身的安全漏洞，而其他两种属于服务端的安全漏洞。
防护
XSS攻击有两大要素：
- 攻击者提交恶意代码
- 浏览器执行恶意代码
针对第一个要素，需要对用户输入进行过滤，但是并非完全可靠，因为在提交较短并不确定内容要输出哪里，对内容的转义有可能导致乱码和不确定性问题。
所以更合理的预防方法是针对第二个要素，通过防止浏览器执行恶意代码来防范XSS，分为两类：
- 防止HTML中出现注入
- 防止JavaScript执行恶意代码
总结起来，可以采取的预防方法有：
（1）一定要针对用户输入做相关的格式检查、过滤等操作，防止任何可能的前端注入
（2）对于不需要考虑SEO的内部系统、管理系统，使用纯前端渲染代替服务端渲染，把代码与数据分开
（3）对于需要服务端拼接HTML的情况，要对HTML中的敏感字符（比如>、>等）进行HTML转义（<、>）
（4）由于HTML转义是很复杂的，不同情况下要采取不同的准一规则，应当尽量避免自己写转义库，而是采取成熟的、业界通用的转义库
（5）对于跳转链接例如<a href="xxx">或者location.href="xxx"要检验内容，禁止以javascript:开头的链接
（6）遵循GET请求不改变服务状态的原则，改变状态的请求都是用POST或者PUT方法
（7）前端在使用innerHTML、outerHTML、document.write时要注意，不要把不可信数据作为HTML插入到页面
（8）使用Vue/React技术栈时不要使用v-html、dangerouslySetInnerHTML功能，在前端render阶段避免XSS隐患
（9）DOM中的内联事件监听器，比如onclick、onload、onmouseover、JavaScript中的eval、setTimeout、setInterval、eval都可以将字符串作为代码运行，如果不可信数据传递给上述API，很容易产生安全隐患，所以要尽量避免，
<a href="javascript:alert(1)"></a>
<iframe src="javascript:alert(1)" />
<img src='x' onerror="alert(1)" />
<video src='x' onerror="alert(1)"></video>
<div onclick="alert(1)" onmouseover="alert(2)"><div>
（10）对于不受信任的输入，可以限制合理的长度，可以增加XSS攻击的难度
（11）某些敏感cookie应该设置HTTP-only，避免通过JavaScript读取cookie
（12）添加验证码，防止脚本冒充用户提交危险操作
（13）主动监测发现XSS漏洞，使用XSS攻击字符串和自动扫描工具寻找潜在的XSS漏洞
（14）JSONP的callback参数非常危险，风险性主要存在于会意外截断JS代码或者被添加恶意标签
CSRF
现象
CSRF（Corss Site Request Forgery），有时也被缩写为XSRF，跨站伪造请求，伪造不是来自于用户的意愿，诱导用户发起请求。
通过CSRF，攻击者可以盗用用户的身份，以用户的名义发送恶意请求，比如以你的名义发送邮件、发送消息、盗取账号等。
CSRF攻击的思想：
image
要完成一次CSRF攻击，受害者必须依次完成两个步骤：
- 登陆受信任网站A，并在本地生成cookie
- 在不登出信任网站A的情况下（session有效），访问危险网站B
CSRF攻击是源于HTTP使用cookie实现的隐式身份验证机制，这种机制可以保证一个请求是来自于某个用户的浏览器，但是无法保证该请求是用户批准发送的。
防护
CSRF的防御可以从服务端和客户端两个方面入手，服务端的效果更好一些。服务端防护的中心思想就是在客户端页面增加伪随机数。
（1） Cookie Hashing
这是比较简单的解决方案，所有的表单都包含同一个伪随机Hash值。在表单中添加一个隐藏的字段，值就是服务单构造的伪随机cookie，随表单一起发送。服务端对表单中的Hash值进行验证。
理论上攻击者无法获取第三方的cookie，那么也就无法伪造表单了，也就杜绝CSRF的攻击了。
Egg默认的预防CSRF的方式就是通过这种方式实现的，框架会在Cookie存放一个CSRF Token，放到query、body或者header中发送给服务端进行验证
注意不能放在cookie中直接验证，那样就没有意义了，因为即便是CSRF伪造的请求，也会携带cookie。
（2）验证码
这种方法也是最常见的方法之一，每次用户提交都需要在表单中填写一个图片上的伪随机字符串（或者实现某些特殊的交互），来让攻击者无法获取对应的字符串或者操作，从而伪造身份失败。
（3）JWT
可以通过JSON-WEB-Token来实现，在响应页面时将Token渲染到页面上，在提交表单的时候通过隐藏域提交上来
HTTP劫持（中间人攻击）
当我们使用HTTP请求请求一个网站页面的时候，营商可在用户发起请求时直接跳转到某个广告，或者直接改变搜索结果插入自家的广告，让客户端（通常是浏览器）展示“错误”的数据，通常是一些弹窗，宣传性广告或者直接显示某网站的内容。如果劫持代码出现了BUG ，则直接让用户无法使用，出现白屏。
数据泄露、请求劫持、内容篡改等等问题，核心原因就在于HTTP是全裸式的明文请求，域名、路径和参数都被中间人们看得一清二楚。
最直接的解决方法就是使用HTTPS协议代替HTTP协议。HTTPS做的就是给请求加密，让其对用户更加安全。对于自身而言除了保障用户利益外，还可避免本属于自己的流量被挟持，以保护自身利益。
DNS劫持
DNS劫持就是通过劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的
这种攻击作为网站开发者并没有什么好的解决方式，可能的解决方有两个：
- 使用大公司提供的CDN服务，减少被坚持的概率
- 被劫持后向工信部投诉解决，或者包茎
点击劫持
点击劫持是一种视觉欺骗，将我们的网页放置到和原页面相同大小的iframe中，用透明的iframe或者图片覆盖页面，诱导用户点击，访问其他页面。
可以在前端预防，判断当前页面是否被嵌套了在iframe中，如果被嵌套了的话则重定向外层页面到我们的正常页面。
if (top.location !== location){
top.location = self.location
}
但是前端防护很容易被绕过，更可靠的方法是通过设置HTTP头信息的X-FRAME-OPTION属性来进行方法，可取的属性值有DENY/SAMEORIGIN/ALLOWFROM
-
DENY： 拒绝任何域加载 -
SAMEORIGIN： 仅允许同源域机载 -
ALLOW-FROM： 定义允许加载iframe的页面地址
网友评论