前端菜鸟来讲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中，对任何请求，都检查两者是否一致。

后话

夜深了，早点休息！