前端菜鸟来说web安全

前言

哎 七月份开始实习，九月份开始奔波校招。很忙碌也很累也没怎么好好学习了。最近面试被问到有关于前端安全，才发现自己一直忽略了这方面，于是赶紧恶补！！！

分类

开发者，一般主要分为前端和后端。而对于开发者来说，安全就主要分为了前端安全和后端安全，而WEB基本攻击大致可以分为三大类：“资源枚举”、“参数操纵” 和 “其它攻击”。。

资源枚举

对于一个团队来说，会有很多编码规范，命名规范来规范团队的开发，例如类名用'-'连接，id用驼峰命名法等。然后需要对项目做备份，把代码压缩成back.rar。然后还把代码备份放到了服务器上，那么那些想要访问你源码的“有心人”就可以有途径去访问下载到你的源码，那么你的项目源码将不再是秘密。
“有心人”会遍历你站点所有可访问的项目，然后把一些常用的备份文件一个个都枚举下载。如果你想对你站点的编码语言和数据库进行保密，但没有配置好后端错误信息的提示。那么“有心人”就可以在站点例的某个搜索结果页面篡改url参数，导致数据库查询错误而返回数据库错误提示信息，或者输入一个根本不存在的子页面地址来获取错误信息，进而可判断该站点使用了什么数据库或动态语言。

参数操纵 - XSS

什么是XSS呢？XSS全称是Cross-site scripting，跨域脚本攻击，是最常见的Web攻击之一。它是一种典型的出现在web应用中的计算机安全漏洞。XSS允许攻击者注入客户端脚本到Web页面中。一段跨域脚本漏洞可能会被攻击者用于通过一些入站控制，如同源策略。xss攻击主要侧重于客户端。

xss的攻击力：轻则用户体验异常弹窗，重则用户cookie数据被盗取，引导用户到非法地址。

a.HTML元素：

 <input v-model = "textXSS"/>
 <p>{{ textXSS }}</p>

input：
    <script type='text/javascript'>alert('xss');</script>//一个alert弹框将会出现。

b.HTML属性:

<img src = "{{ img_url }}" />
if img_url = "xss = "alert('xss')' 
浏览器就会解析成：
<img src = "" xss = "alert('xss')" />

c.url链接：

假如你想要在一个网站的输入框中输入你想搜索的关键字（例：“apple”），此时URL会变为http://dodomonster.org?keywor...正常的搜索。如果没有结果，则一般会显示‘apple’搜索结果为空。但是，如果你输入"<script type='text/javascript'>alert('xss');</script>"一个alert弹框将会出现。会提示<script type='text/javascript'>alert('xss');</script>搜索结果为空伴随着错误信息提示弹框“xss”，而且url还会变成http://dodomonster.org?<sc... type='text/javascript'>alert('xss');</script>-这是一个“有心人”可利用的漏洞

d.Javascript脚本：

 <script>var user_data = {{ user_data|json_encode }};</script>
 if user_data = {"xss": "</script><script>alert('xss');"}
 
 浏览器会解析成：
 <script>var user_data = {"xss": "</script>
 <script>alert('xss');"};</script>
 

解决办法：
① 在不同上下文中，使用合适的escape方式
② 不要相信任何来自用户的输入

参数操纵 - SQL注入

所谓SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

SQL注入的攻击力：轻则暴露数据，刷爆数据库，重则表数据被恶意编辑、删除，或表被删除。

发生的主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。

根据相关技术原理，SQL注入可以分为平台层注入和代码层注入。前者由不安全的数据库配置或数据库平台的漏洞所致；后者主要是由于程序员对输入未进行细致地过滤，从而执行了非法的数据查询。基于此，SQL注入的产生原因通常表现在以下几方面：

• 不当的类型处理；

• 不安全的数据库配置；

• 不合理的查询集处理；

• 不当的错误处理；

• 转义字符处理不合适；

• 多个提交处理不当。

如：你想在一个超市站点查看apple的相关信息，url：http://dodomonster.org?id=99,你就会知道哦，原来apple的键值id为99

后台收到url会执行查询语句：select * from fruit where id = 99;

如果我们把url改为http://dodomonster.org?id=99 or 1>0，数据库查询语句就会变为select * from fruit where appleId = 99 or 1>0，从而有心人就会获取了整个数据库中所有的水果信息。

参数操纵 - XPath注入

XPath注入和SQL注入原理差不多，只不过XPath注入的数据库是xml格式的。

参数操纵 - 会话劫持

在现实生活中，比如你去市场买菜，在交完钱后你要求先去干一些别的事情，稍候再来拿菜；如果这个时候某个陌生人要求把菜拿走，卖菜的人会把菜给陌生人吗？！当然，这只是一个比喻，但这恰恰就是会话劫持的喻意。所谓会话，就是两台主机之间的一次通讯。[引自百度百科]

访问一个http网站要与服务器建立一次HTTP回话。假设跟你处于同一个子网上的“朋友”，想伪装成你来劫持你的HTTP会话，那么服务器会信息返回给那个人吗？

答案是肯定的，因为HTTP会话并不安全。它在经过TCP/IP协议封装传输数据时，在传输的数据的每一个字节中插入一个32位的序列号码，这个序列号用来保持跟踪数据和提供可靠性（序列号是依循数据顺序逐步递增的）。第三方攻击者可以通过嗅探的方式来获取用户与服务器通讯中的报文信息，如果他能猜测到数据中的序列号，那便能把合法的用户断开，伪装成合法用户让自己控制后续的通话。

对于会话劫持的预防，可以走SSH协议、增强网络安全系统健壮性，也可以使用无序的UUID来替代通讯中的序列号码（而非逐步递增）。

其他攻击 - CSRF

CSRF，cross-site request forgery,跨站请求伪造。与XSS非常相似，但是XSS是利用用户对当前网站的信任来发起攻击，而CSRF是利用网站对用户的信任来发起攻击。

CSRF攻击力：以你的名义发送邮件、发消息，盗取你的账号，甚至购买商品，虚拟货币转账，个人隐私泄露以及财产安全。

对于一个安全性很低的电商网站，如果你已经登录了网站，且没关闭浏览器，在任何情况都可以作为一个已通过身份验证登录的用户来购买商品等操作，而无须重新登录或者输入支付密码。

我们可以给一个用户的邮箱发送一份邮件里面包含一张图片
<img src = "http://dodomonster.com/pay?ap... = 99"/>
img、src、iframe都是不受同源限制的，假设你使用的邮箱很直白地显示了这张图片那你就会直接跳到购买id为99的支付页面，直接支付，做了购买的动作操作。

这就是为什么现在大部分的邮箱都不会直接显示图片的原因！all for u！

防范CSRF：

1. 检查报头中的Referer参数确保请求发自正确的网站（但XHR请求可调用setRequestHeader方法来修改Referer报头）；

2. 对于任何重要的请求都需要重新验证用户的身份；

3. 创建一个唯一的令牌（Token），将其存在服务端的session中及客户端的cookie中，对任何请求，都检查二者是否一致。

后话

夜深了，早点休息！