需要知道的前端安全问题

作为前端开发工程师，我们也需要了解一些常见的web安全漏洞，写代码的时候要谨慎，防止出现一些低级漏洞。特别是在开发公共模块组件的时候，比如网络请求模块，输入模块，富文本模块等等，都需要考虑安全性问题。

常见的web安全漏洞 #

• 反射xss
• 存储xss
• 水平越权
• Java/PHP/Python/Node 反序列化命令执行
• SpringEL/Struts/Fastjson/Webx 反序列化命令执行
• Path Traversal
• OS Command Injection
• SQL Injection
• XML Enternal Entity Injection
• LDAP Injection
• HTTP PUT method is enabled
• Server-side JavaScript code injection
• XPath Injection
• Out-of-band resource load(HTTP)
• SSI injection
• External service interaction
• CSRF
• Cleartext submission of password
• Serialized object in HTTP message
• Directory listing
• jsonp 劫持

XSS漏洞 #

跨站脚本攻击(Cross Site Scripting), 为了不和CSS冲突，称为XSS。XSS攻击需要具备两个条件：需要向web页面注入恶意代码；这些恶意代码能够被浏览器成功的执行。

XSS攻击有2种:   本地漏洞攻击，反射型攻击;    存储型攻击

XSS本地漏洞：本地利用漏洞，这种漏洞存在于页面中客户端脚本自身，通过调用客户端漏洞执行远程不可预见代码。

XSS反射型攻击，恶意代码并没有保存在目标网站，通过引诱用户点击一个链接到目标网站的恶意链接来实施攻击的。

XSS存储型攻击，恶意代码被保存到目标网站的服务器中，这种攻击具有较强的稳定性和持久性，比较常见场景是在博客，论坛、OA、CRM等社交网站上，比如：某CRM系统的客户投诉功能上存在XSS存储型漏洞，黑客提交了恶意攻击代码，当系统管理员查看投诉信息时恶意代码执行，窃取了客户的资料，然而管理员毫不知情，这就是典型的XSS存储型攻击。

危害：

1.窃取cookies，读取目标网站的cookie发送到黑客的服务器上

2.读取用户未公开的资料，如果：邮件列表或者内容、系统的客户资料，联系人列表等等。它可以获取用户的联系人列表，然后向联系人发送虚假诈骗信息，可以删除用户的日志等等，有时候还和其他攻击方式同时实 施比如SQL注入攻击服务器和数据库、Click劫持、相对链接劫持等实施钓鱼，它带来的危害是巨大的，是web安全的头号大敌。

解决：

1.在表单提交或者url参数传递前，对需要的参数进行过滤

2.过滤用户输入的 检查用户输入的内容中是否有非法内容。如<>（尖括号）、”（引号）、 ‘（单引号）、%（百分比符号）、;（分号）、()（括号）、&（& 符号）、+（加号）等。、严格控制输出

可以利用下面这些函数对出现xss漏洞的参数进行过滤

（1）htmlspecialchars() 函数,用于转义处理在页面上显示的文本。

（2）htmlentities() 函数,用于转义处理在页面上显示的文本。

（3）strip_tags() 函数,过滤掉输入、输出里面的恶意标签。

（4）header() 函数,使用header(“Content-type:application/json”); 用于控制 json 数据的头部，不用于浏览。

（5）urlencode() 函数,用于输出处理字符型参数带入页面链接中。

（6）intval() 函数用于处理数值型参数输出页面中。

（7）自定义函数,在大多情况下，要使用一些常用的 html 标签，以美化页面显示，如留言、小纸条。那么在这样的情况下，要采用白名单的方法使用合法的标签显示，过滤掉非法的字符。

水平越权 #

横向越权：横向越权指的是攻击者尝试访问与他拥有相同权限的用户的资源
纵向越权：纵向越权指的是一个低级别攻击者尝试访问高级别用户的资源

如何防止横向越权漏洞：

可通过建立用户和可操作资源的绑定关系，用户对任何资源进行操作时，通过该绑定关系确保该资源是属于该用户所有的。

对请求中的关键参数进行间接映射，避免使用原始关键参数名，比如使用索引1代替id值123等

如何防止纵向越权漏洞：

建议使用基于角色访问控制机制来防止纵向越权攻击，即预先定义不同的权限角色，为每个角色分配不同的权限，每个用户都属于特定的角色，即拥有固定的权限，当用户执行某个动作或产生某种行为时，通过用户所在的角色判定该动作或者行为是否允许。

反序列化命令执行 #

https://some_site.com.br/get-files?file=../../../../some dir/some file

https://some_site.com.br/../../../../some dir/some file

像这种如果能下载到文件，就是有漏洞。

OS Command Injection #

命令行注入漏洞，主要是常见于给操作系统传入了不可预见的参数导致。比如现在很常用的webshell，基于浏览器执行的远程终端，之前php也有这种。比如一个参数是要传给操作系统某个命令执行的，但是没有做命令过滤，可能会导致参数中的命令被执行。举个例了，catWrapper这个是做的一个输入文件内容的命令，添加了自定义参数。

catWapper -color red  xxx.txt   //比如这个命令可以用红色字体打印xxx.txt内容

catWapper -color red  xxx.txt;ls  //如果这个命令执行了ls的操作，那么这个catWapper就有漏洞

CSRF #

CSRF（Cross Site Request Forgery, 跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一。其他安全隐患，比如 SQL 脚本注入，跨站域脚本攻击等在近年来已经逐渐为众人熟知，很多网站也都针对他们进行了防御。然而，对于大多数人来说，CSRF 却依然是一个陌生的概念。即便是大名鼎鼎的 Gmail, 在 2007 年底也存在着 CSRF 漏洞，从而被黑客攻击而使 Gmail 的用户造成巨大的损失。

CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。比如说，受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 https://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：https://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”https://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

防御的方法： 参考：https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/

1、验证 HTTP Referer 字段

2、在请求地址中添加 token 并验证

3、在 HTTP 头中自定义属性并验证

JSONP劫持 #

json劫持， json劫持攻击又为”JSON Hijacking”，攻击过程有点类似于csrf，只不过csrf只管发送http请求，但是json-hijack的目的是获取敏感数据。
一些web应用会把一些敏感数据以json的形式返回到前端，如果仅仅通过cookie来判断请求是否合法，那么就可以利用类似csrf的手段，向目标服务器发送请求，以获得敏感数据。
比如下面的链接在已登录的情况下会返回json格式的用户信息：

https://www.test.com/userinfo

攻击者可以在自己的虚假页面中，加入如下标签：

<script src="https://www.test.com/userinfo"></script>

如果当前浏览器已经登录了www.test.com，并且cookie未过期，然后访问了攻击者的虚假页面，那么该页面就可以拿到json形式的用户敏感信息，因为script标签会自动解析json数据，生成对应的js对象。然后再通过

Object.prototype.__defineSetter__

这个函数来触发自己的恶意代码。
但是这个函数在当前的新版本chrome和firefox中都已经失效了。

jsonp是一个非官方的协议，利用script元素的开放策略，网页可以得到从其他来源动态产生的json数据，因此可以用来实现跨域。
web程序如果通过这种方式跨域之后，攻击者完全可以在自己的虚假页面中发起恶意的jsonp请求，这就引来了安全问题。比如：

<script>
function useUserInfo(v){
alert(v.username);
}
</script>
<script src="https://www.test.com/userinfo?callback=useUserInfo"></script>

如果服务器端的userinfo接口支持jsonp，那就会使虚假页面成功执行useUserInfo函数，从而导致安全问题。
其实json劫持和jsonp劫持属于CSRF（ Cross-site request forgery 跨站请求伪造）的攻击范畴，所以解决的方法和解决csrf的方法一样。
1、验证 HTTP Referer 头信息；
2、在请求中添加 csrfToken 并在后端进行验证；