WEB安全性-2010_OWASP_TOP10

OWASP TOP 10-2010

开放式Web应用程序安全项目（OWASP，Open Web Application Security Project）是一个组织，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。https://www.doczj.com/doc/2b18999220.html,

OWASP发布了最新的Web应用脆弱性的top 10，这是继2007年OWASP对TOP10进行修订后进行的又一次更改，该版本暂定为OWASP TOP 10- 2010。在新版本的OWASP TOP10中主要由以下变化：

1. Top10的命名发生了变化。

原先的Top10全称为“The top 10 most critical web application security vulnerabilities”，即“Web应用的十大关键脆弱性”，现在Top10的全称为“The top 10 most critical web application security risks”，即“Web应用的十大关键风险”

2. OWASP Top 10的风险评估方法

此次Top 10的评估是依据OWASP的风险评估方法来对OWASP TOP10排序的。

3. 替换了2个风险

此次Top 10与2007年的Top 10相比，在内容上去掉了“Malicious File Execution”(恶意文件执行)和“Information leakage and improper error handling”(信息泄露及不恰当的错误处理)，增加了“Security misconfiguration”(错误安全配置)和“Unv alidated redirects and forwards”(未验证的重定向和传递)。

OWASP TOP10 2007 OWASP TOP10 2010

A2-注入 A1-注入

A1-跨站脚本（XSS） A2-跨站脚本（XSS）

A7-错误的认证和会话管理 A3-错误的认证和会话管理

A4-不正确的直接对象引用 A4-不正确的直接对象引用

A5-伪造跨站请求（CSRF） A5-伪造跨站请求（CSRF）

A6-安全性误配置

A10-限制远程访问失败 A7-限制远程访问失败

A8-未验证的重定向和传递

A8-不安全的加密存储 A9-不安全的加密存储

A9-不足的传输层保护 A10-不足的传输层保护

A3-恶意文件执行

A6-不安全的通讯

OWASP风险评估方法

OW ASP所选取的10大风险是依据OW ASP的风险评估方法，我们从标准的风险模型开始，即风险=可能性*后果，下面我们以以下步骤来说明某个风险的严重程度：

第一步：识别风险

识别风险作为评估的第一步，我们必须找到与这个风险相关的威胁、相应的攻击方法、隐含在里面的脆弱性以及最终可能造成的后果，当然可能存在多种攻击方法和多种后果，在评估时我们往往会采用最坏选择，这样就能更客观的反应该风险的最终评级；

第二步：考虑影响可能性的因素

通常，我们不可能很精准的说出某个风险的可能性数值，所以我们一般用高、中、低来表示，而且影响某个风险的可能性的因素有很多，对于每个因素我们用0到9的数值来表示。

类别因素分项分值

威胁技能要求无需技能1

需要一些技术3

高级的计算机用户4

需要网络和编程技术6

安全渗透技术9

成功攻击后攻击者的益

处

很低或无益1可能会有回报4高回报9

所需资源或机会需要很大资源或高权限访问0

需要特定的访问权限和特定的资

源

4

需要一些访问权限和资源7

无需权限或资源9所需的攻击者的角色开发者2

系统管理员2

内部用户4

合作伙伴5

认证用户6

匿名Internet用户9脆弱性发现该弱点的难易度技术上不可行1

困难3

容易7

可用自动化工具发现9利用该弱点的难易度只是理论上的1

困难3

容易5

可用自动化工具实现9

该弱点的流行度不为人知1

隐藏4

明显6

公众皆知9入侵被察觉的可能性应用程序主动检测1

记录日志并审核3

记录日志未审核8

无日志9

第三步：考虑影响后果的因素

在考虑攻击后果的时候，我们会考虑两种后果，一种是应用的“技术后果”，它所使用的数据，提供的功能等等，另一种就是它的“商业后果”，显然后者则更为重要，但往往后者难以估量，所以我们需要尽可能从技术上去考虑，进而来估计后者的数据。

类别因素分项分值技术后果保密性损失很少的非敏感的数据泄漏 2

很少的敏感数据泄漏 6

大量的非敏感数据泄漏 6

大量的敏感数据泄漏9

A1-注入

注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行。常见的注入包括SQL注入，OS Shell，LDAP，Xpath，Hibernate等等，而其中SQL注入尤为常见。这种攻击所造成的后果往往很大，一般整个数据库的信息都能被读取或篡改，通过SQL注入，攻击者甚至能够获得更多的包括管理员的权限。

防范SQL注入——编程篇

SQL注入往往是在程序员编写包含用户输入的动态数据库查询时产生的，但其实防范SQL注入的方法非常简单。程序员只要a）不再写动态查询，或b）防止用户输入包含能够破坏查询逻辑的恶意SQL语句，就能够防范SQL注入。在这篇文章中，我们将会说明一些非常简单的防止SQL注入的方法。

我们用以下Java代码作为示例：

String query =＂SELECT account_balance FROM user_data WHERE user_name =＂+ request.getParameter(＂customerName＂);

try { Statement statement = connection.createStatement( …); ResultSet results = Statement.executeQuery(query);

}

在以上代码中，我们可以看到并未对变量customerName做验证，customerName的值可以直接附在query语句的后面传送到数据库执行，则攻击者可以将任意的sql语句注入。

防范方法1：参数化查询

参数化查询是所有开发人员在做数据库查询时首先需要学习的，参数化查询迫使所有开发者首先要定义好所有的SQL代码，然后再将每个参数逐个传入，这种编码风格就能够让数据库辨明代码和数据。

参数化查询能够确保攻击者无法改变查询的内容，在下面修正过的例子中，如果攻击者

输入了UsrID是“’or ‘1 ‘=’1”，参数化查询会去查找一个完全满足名字为‘or ‘1 ‘=’ 1的用户。

对于不同编程语言，有一些不同的建议：

Java EE——使用带绑定变量的PreparedStatement()；

.Net——使用带绑定变量的诸如SqlCommand()或OleDbCommand()的参数化查询；

PHP——使用带强类型的参数化查询PDO（使用bindParam()）；

Hibernate——使用带绑定变量的createQuery()。

Java示例：

String custname = request.getParameter(＂customerName＂); String query =＂SELECT account_balance FROM user_data WHERE user_name= ?＂;

PreparedStatement pstmt = connection.prepareStatement(query); Pstmt.setString1,custname();

ResultSet results = pstmt.executeQuery();

C# .Net示例：

String query =＂SELECT account_balance FROM user_data WHERE user_name = ?＂; Try { OleDbCommand command = new OleDbCommand(query,connection);

command.Parameters.Add(new OleDbParameter(＂customerName＂,CustomerName.Text));

OleDbDataReader reader = command.ExecuteReader();

} catch (OleDbException se){

//error handling }

防范方法二：存储过程

存储过程和参数化查询的作用是一样的，唯一的不同在于存储过程是预先定义并存放在数据库中，从而被应用程序调用的。

Java存储过程示例：

String custname = request.getParameter(＂customerName＂); try { CallableStatement cs = connection.prepareCall(＂call sp_getAccountBalance(?)}＂);

cs.setString(1,custname);

Result results = cs.executeQuery(); }catch(SQLException se){ //error handling }

VB .Net存储过程示例：

Try

Dim command As SqlCommand = new SqlCommand(＂sp_getAccountBalance＂,connection) https://www.doczj.com/doc/2b18999220.html,mandType = CommandType.StoredProcedure command.Parameters.Add(new SqlParameter(＂@CustomerName＂,CustomerName.Text)) Dim reader As SqlDataReader = command.ExecuteReader() ‘…

Catch se As SqlException ‘error handling End Try

防范方法三：对所有用户输入进行转义

我们知道每个DBMS都有一个字符转义机制来告知DBMS输入的是数据而不是代码，如果我们将所有用户的输入都进行转义，那么DBMS就不会混淆数据和代码，也就不会出现SQL注入了。

当然，如果要采用这种方法，那么你就需要对所使用的数据库转义机制，也可以使用现存的诸如OWASP ESAPI的escaping routines。ESAPI目前是基于MySQL和Oracle的转义机制的，使用起来也很方便。一个Oracle的ESAPI的使用示例如下：

ESAPI.encoder().encodeForSQL(new OracleCodec(),queryparam);

那么，假设你有一个要访问Oracle数据库的动态查询代码如下：

String query =＂SELECT user_id FROM user_data WHERE user_name = ‘＂+req.getParameter(＂userID＂)+＂’ and user_password = ‘＂+req.getParameter(＂pwd＂)+＂’＂; try { Statement statement = connection.createStatement(…);

ResultSet results = statement.executeQuery(query) ; }

那么，你就必须重写你的动态查询的第一行如下：

Codec ORACLE_CODEC = new OracleCodec(); String query =＂SELECT user_id FROM user_data WHERE user_name = ‘＂+ ESAPI.encoder().encodeForSQL(ORACLE_CODEC,req.getParameter(＂userID＂))+＂’ and user_password = ‘＂+ ESAPI.encoder().encodeForSQL(ORACLE_CODEC,req.getParameter(＂pwd＂))+＂’＂;

当然，为了保证自己代码的可读性，我们也可以构建自己的OracleEncoder：Encoder e = new OracleEncoder(); String query =＂SELECT user_id FROM user_data WHERE user_name = ‘＂+ oe.encode(req.getParameter(＂userID＂)) +＂’ and user_password = ‘＂+ oe.encode(req.getParameter(＂pwd＂))+＂’＂;

除了上面所说的三种防范方法以外，我们还建议可以用以下两种附加的方法来防范SQL 注入：最小权限法、输入验证白名单法。

最小权限法：

为了避免注入攻击对数据库造成的损害，我们可以把每个数据库用户的权限尽可能缩小，不要把DBA或管理员的权限赋予你应用程序账户，在给用户权限时是基于用户需要什么样的权限，而不是用户不需要什么样的权限。当一个用户只需要读的权限时，我们就只给他读的权限，当用户只需要一张表的部分数据时，我们宁愿另建一个视图让他访问。

如果你的策略是都是用存储过程的话，那么仅允许应用程序的账户执行这些查询，而不给他们直接访问数据库表的权限。诸如此类的最小权限法能够在很大程度上保证我们数据库的安全。

输入验证白名单法：

输入验证能够在数据传递到SQL查询前就察觉到输入是否正确合法，采用白名单而不是黑名单则能在更大程度上保证数据的合法性。

防范SQL注入——测试篇

对于测试人员来说，如何测试SQL注入漏洞是否存在呢？

首先，我们将SQL注入攻击能分为以下三种类型：

Inband：数据经由SQL代码注入的通道取出，这是最直接的一种攻击，通过SQL注入获取的信息直接反映到应用程序的Web页面上；

Out-of-band：数据通过不同于SQL代码注入的方式获得（譬如通过邮件等）

推理：这种攻击是说并没有真正的数据传输，但攻击者可以通过发送特定的请求，重组返回的结果从而得到一些信息。

不论是哪种SQL注入，攻击者都需要构造一个语法正确的SQL查询，如果应用程序对一个不正确的查询返回了一个错误消息，那么就和容易重新构造初始的查询语句的逻辑，进而也就能更容易的进行注入；如果应用程序隐藏了错误信息，那么攻击者就必须对查询逻辑进行反向工程，即我们所谓的“盲SQL注入”

黑盒测试及示例：

这个测试的第一步是理解我们的应用程序在什么时候需要访问数据库，典型的需要访问数据库的时机是：

认证表单：输入用户名和密码以检查是否有权限

搜索引擎：提交字符串以从数据库中获取相应的记录

电子商务站点：获取某类商品的价格等信息

作为测试人员，我们需要列对所有输入域的值可能用于查询的字段做一个表单，包括那些POST请求的隐含字段，然后截取查询语句并产生错误信息。第一个测试往往是用一个单引号“‘”或是分号“；”，前者在SQL中是字符串终结符，如果应用程序没有过滤，则会产生一条错误信息；后者在SQL中是一条SQL语句的终结符，同样如果没有过滤，也会产生错误信息。在Microsoft SQL Server中，返回的错误信息一般是这样：

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string ‘’. /target/target.asp, line 113

同样可用于测试的还有“--”以及SQL中的一些诸如“AND”的关键字，通常很常见的一种测试是在要求输入为数字的输入框中输入字符串，会返回如下的错误信息：

Microsoft OLE DB Provider for ODBC Drivers erro r ‘80040e07’[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the varchar value ‘tester’ to a column of data type int. /target/target.asp, line 113

类似上面这样的出错返回信息能让我们知道很多数据库的信息，通常不会返回那么多信

息，会返回诸如“500 Server Error”的信息，那就需要“盲SQL注入”了。注意，我们需要对所有可能存在SQL注入漏洞的输入域进行测试，并且在每个测试用例时只变化一个域的值，从而才能找到真正存在漏洞的输入域。

下面我们看一下标准的SQL注入测试是怎样的。

我们以下面的SQL查询为例：

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

如果我们在页面上输入以下的用户名和密码：

$username = 1' or '1' = '1 $password = 1' or '1' = '1

那么整个查询语句就变为：

SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'

假设参数值是通过GET方法传递到服务器的，且域名为https://www.doczj.com/doc/2b18999220.html,，那么我们的访问请求就是：

https://www.doczj.com/doc/2b18999220.html,/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or %20'1'%20=%20'1

对上面的SQL语句作简单分析后我们就知道由于该语句永远为真，所以肯定会返回一些数据，在这种情况下实际上并未验证用户名和密码，并且在某些系统中，用户表的第一行记录是管理员，那这样造成的后果则更为严重。

另外一个查询的例子如下：

SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password')))

在这个例子中，存在两个问题，一个是括号的用法，还有一个是MD5哈希函数的用法。对于第一个问题，我们可以很容易找到缺失的右括号解决，对于第二个问题，我们可以想办法使第二个条件失效。我们在查询语句的最后加上一个注释符以表示后面的都是注释，常见的注释起始符是/*（在Oracle中是--），也就是说，我们用如下的用户名和密码：

$username = 1' or '1' = '1'))/* $password = foo

那么整条SQL语句就变为：

SELECT * FROM Users WHERE ((Username='1' or '1' = '1'))/*') AND (Password=MD5('$password')))

我们的URL请求就变为：

https://www.doczj.com/doc/2b18999220.html,/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo

Union查询SQL注入测试

还有一种测试是利用Union的，利用Union可以连接查询，从而从其他表中得到信息，假设我们有如下的查询：

SELECT Name, Phone, Address FROM Users WHERE Id=$id

然后我们设置id的值为：

$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

那么整体的查询就变为：

SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable

显然这样就能得到所有信用卡用户的信息。

盲SQL注入测试

在上面我们提到过盲SQL注入，即blind SQL injection，它意味着对于某个操作我们得不到任何信息，通常这是由于程序员已经编写了特定的出错返回页面，从而隐藏了数据库结构的信息。

利用推理方法，有时候我们能够恢复特定字段的值。这种方法通常采用一组对服务器的布尔查询，依据返回的结果来推断结果的含义。仍然延续上面的https://www.doczj.com/doc/2b18999220.html,，有一个参数名为id，那么我们输入以下url请求：

https://www.doczj.com/doc/2b18999220.html,/index.php?id=1'

显然由于语法错误，我们会得到一个预先定义好的出错页面，假设服务器上的查询语句为SELECT field1, field2, field3 FROM Users WHERE Id='$Id'，假设我们想要得到用户名字段的值，那么通过一些函数，我们就可以逐字符的读取用户名的值。在这里我们使用以下的函数：SUBSTRING (text, start, length)，ASCII (char)，LENGTH (text)

我们定义id为：

$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1

那么最终的SQL查询语句为：

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'

那么，如果在数据库中有用户名的第一个字符的ASCII码为97的话，那么我们就能得到一个真值，那么我们就继续寻找该用户名的下一个字符；如果没有的话，那么我们就递增猜测第一个字符的ASCII码为98的用户名，这样反复下去就能判断出合法的用户名。

那么，什么时候我们可以结束推理呢，我们假设id的值为：

$Id=1' AND LENGTH(username)=N AND '1' = '1

其中N是我们到目前为止已经分析的字符数目，那么整体的sql查询为：

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'

这个查询的返回值如果是真，那我们就已经完成了推理并且我们已经得到了想要的数值，如果为假，则表示我们还要继续分析。

这种盲SQL注入会要求我们输入大量的sql尝试，有一些自动化的工具能够帮我们实现，SqlDumper就是这样的一种工具，对MySQL数据库进行GET访问请求。

存储过程注入

在上一篇《如何防范SQL注入—编程篇》中，我们提到使用存储过程是能够防范SQL 注入的，但同时也要注意，存储过程如果使用不得当，使用存储过程的动态查询事实上也会造成一定的SQL注入漏洞。

以下面的SQL存储过程为例：

Create procedure user_login @username varchar(20), @passwd varchar(20) As

Declare @sqlstring varchar(250)

Set @sqlstring = ‘

Select 1 from users Where username = ‘ + @username + ‘ and passwd = ‘ + @passwd

exec(@sqlstring) Go

用户的输入如下：

anyusername or 1=1' anypassword

如果我们没有对输入进行验证，那么上面的语句就会返回数据库中的一条记录。

我们再看下面的一条：

Create procedure get_report @columnamelist varchar(7900) As

Declare @sqlstring varchar(8000)

Set @sqlstring = ‘Select ‘ + @columnamelist + ‘ from ReportTable‘

exec(@sqlstring) Go

如果用户输入是：

1 from users; update users set password = 'password'; select *

后面则显而易见，用户的所有密码都被更改且得到了报表信息。

A2-跨站脚本（XSS）

排在OWASP TOP10第2位的是Cross Site Scripting（XSS），翻译成中文即“跨站脚本攻击”。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常忽略其危害性。

以下内容转自百度空间的一篇关于OWASP的文章，个人觉得基本已经把跨站脚本攻击的内容阐述的比较清楚。

如何寻找XSS漏洞，XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。另一类则是来来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开，然后利用下面的技术得到一个shell。

如何利用

传统的跨站利用方式一般都是攻击者先构造一个跨站网页，然后在另一空间里放一个收集cookie的页面，接着结合其它技术让用户打开跨站页面以盗取用户的cookie，以便进一步的攻击。这种方式太过于落后，对于弊端大家可能都知道，因为即便你收集到了cookie 你也未必能进一步渗透进去，多数的cookie里面的密码都是经过加密的，如果想要cookie 欺骗的话，同样也要受到其它的条件的限约。而另一种思路，则从一定程度上解决上述的问题。比较成熟的方法是通过跨站构造一个表单，表单的内容则为利用程序的备份功能或者加管理员等功能得到一个高权限。下面将详细的介绍这种技术。

寻找跨站漏洞

如果有代码的话比较好办，我们主要看代码里对用户输入的地方和变量有没有做长度和对”<”,”>”,”;”,”?”等字符是否做过滤。还有要注意的是对于标签的闭合，像测试QQ群跨站漏洞的时候，你在标题处输入，代码是不会被执行的，因为在源代码里，有其它的标签未闭合，如少了一个，这个时候，你只要闭合一个，代码就会执行，如：你在标题处输入，这样就可以弹出一个test的框。

如何利用

跨站脚本(Cross-site scripting，XSS)漏洞是Web应用程序中最常见的漏洞之一。如果您的站点没有预防XSS漏洞的固定方法，那么就存在XSS漏洞。这个利用XSS漏洞的病毒之所以具有重要意义是因为，通常难以看到XSS漏洞的威胁，而该病毒则将其发挥得淋漓尽致。

这个利用XSS漏洞的蠕虫病毒的特别之处在于它能够自我传播。https://www.doczj.com/doc/2b18999220.html,上的一个用户希望自己能够在网站的友人列表上更“受欢迎”。但是该用户不是通过普通的方法来结交新朋友，而是在自己的个人信息中添加了一些代码，导致其他人在访问他的页面时，会不知不觉地利用XSS漏洞将他加为好友。更恶劣的是，它会修改这些人的个人信息，使其他人在访问这些被感染的个人信息时，也会被感染。由于这种呈指数传播的方式，这种病毒才很快就被发现。

很难预防站点中的XSS。因此一定要认真检查您的应用程序是否存在XSS漏洞。此外，WebLogic Server的encodeXSS()也可以有所帮助。可以试着针对所有牵涉到使用encodeXSS()或其他某个筛选方法的输出找出一种编码模式——找出对一种编码模式来说不正确的应用程序往往要比找出XSS漏洞要容易的多。更重要的是，不要认为，就因为XSS漏洞是一个常见问题，所以它危害不大。

之所以出现XSS漏洞有两个原因。首先，HTML没有明确区分代码和数据。无法确定指出“这个字符串表示的是数据”。您可以将其放入引号中，但是数据是否包含引号呢？……

其次，程序在将用户数据发送回浏览器时没有进行有效的转义。这导致包含有（例如说）引号的数据被放入页面中，从而引发了问题。而AJAX要提供的好处是，它包含一个专用渠道XML链接，其中全是数据而没有代码。这样，就有可能让客户端AJAX引擎负责对字符串进行转义、检测不正确的值，等等。说是这么说，直到AJAX更为成熟（可能也更为标准化）之前，它只会导致错误的编程和安全漏洞。

XSS漏洞可能造成的后果包括窃取用户会话，窃取敏感信息，重写Web页面，重定向用户到钓鱼网站等，尤为严重的是，XSS漏洞可能使得攻击者能够安装XSS代理，从而攻击者能够观察到该网站上所有用户的行为，并能操控用户访问其他的恶意网站。

对于XSS漏洞，我们有两种常见的措施，第一种就是消除漏洞，简而言之就是在输出页面上不提供任何用户的输入信息；另外一种就是想办法来抵御这种漏洞，可以采用对所有用户的输入编码后再输出（可以用OWASP的ESAPI），也可以对所有用户输入进行“白名单”验证，另外，OWASP还提供了AntiSamy对HTML页面做优化以消除这个漏洞。

防范XSS跨站脚本攻击——测试篇

XSS也是一种对浏览器的解释器的代码注入攻击，这些攻击能够通过HTML，JavaScript，VBScript，ActiveX，Flash等其他客户端语言执行，同时，这些攻击也可能造成用户信息泄露，配置更改，cookie窃取等造成危害，甚至能够用于对Web服务器进行DOS攻击。

与大部分攻击不同的是，大部分攻击往往只涉及2方（攻击者和网站，攻击者和受害者），而XSS则涉及3方，攻击者、客户端、网站，XSS的目的就是窃取客户端的cookie或是其他信息以冒充客户在网站上进行认证，进而在网站上操作任何想进行的操作。

下面我们看看到底有哪些类型的XSS攻击：

Stored XSS（存储式跨站脚本攻击）

这是最强大的一种XSS攻击，所谓存储跨站攻击是指用户提交给Web应用程序的数据首先就被永久的保存在服务器的数据库，文件系统或其他地方，后面且未做任何编码就能显示到Web页面，最典型的就是2005年在MySpace发现的XSS漏洞以及利用该漏洞的Samy MySpace Worm。

举例，假设我们的网站允许我们给其他用户留言，但事实上我们没有留言而是写入了一段代码：

那么服务器将会存储这些信息，当用户点击我们伪造的留言时，他的浏览器就会执行我们的脚本。

Reflected XSS（反射跨站脚本攻击）

这是最常见也是最知名的XSS攻击，当Web客户端提交数据后，服务器端立刻为这个

客户生成结果页面，如果结果页面中包含未验证的客户端输入数据，那么就会允许客户端的脚本直接注入到动态页面中。传统的例子是站点搜索引擎，如果我们搜索一个包含特殊HTML 字符的字符串时，通常在返回页面上仍然会有这个字符串来告知我们搜索的是什么，如果这些返回的字符串未被编码，那么，就会存在XSS漏洞了。

初看上去，由于用户只能在自己的页面上注入代码，所以似乎这个漏洞并不严重，但是，只需一点点社会工程的方法，攻击者就能诱使用户访问一个在结果页面中注入了代码的URL，这就给了攻击者整个页面的权限。由于这种攻击往往会需要一些社会工程方法，所以研发人员往往不会太过看重，但是我们看如下的例子，在服务器上有如下代码：

article.php?title=

这就使得浏览器每3秒就刷新一次页面，而且是一个死循环的状态，这就形成了DOS 攻击，导致Web服务器挂掉。

DOM-Based XSS（基于DOM的XSS）

这个漏洞往往存在于客户端脚本，如果一个Javascript脚本访问需要参数的URL，且需要将该信息用于写入自己的页面，且信息未被编码，那么就有可能存在这个漏洞。

黑盒测试和示例：

比较简单的测试是否存在XSS漏洞的方法是验证Web应用是否会对一个包含了HTTP响应的简单脚本的访问请求，例如，Sambar服务器（5.3）包含一个众所周知的XSS漏洞，我们向服务器发送如下的请求，从服务器端能够产生一个响应从而在Web浏览器中执行http://server/cgi-bin/testcgi.exe?

这个脚本会在客户浏览器端被执行。

我们再举个例子：

由于Javascript是区分大小写的，有些人会尝试将所有字符转换为大写字符来避免XSS 漏洞，在这时，我们最好还是使用VBScript，因为它是大小写不区分的：

JavaScript.

VBScript.

alert(DOCUMENT.COOKIE)

如果我们已经过滤了”<”，或者是，那么我们就需要尝试各种编码方法了

%3cscript. src=https://www.doczj.com/doc/2b18999220.html,/malicious-code.js%3e%3c/script%3e

\x3cscript. src=https://www.doczj.com/doc/2b18999220.html,/malicious-code.js\x3e\x3c/script\x3e

A3-错误的认证和会话管理

OWASP TOP10排名第3的威胁“遭破坏的认证和会话管理”，简而言之，就是攻击者窃听了我们访问HTTP时的用户名和密码，或者是我们的会话，从而得到sessionID，进而冒充用户进行Http访问的过程。

由于HTTP本身是无状态的，也就是说HTTP的每次访问请求都是带有个人凭证的，而SessionID就是为了跟踪状态的，而sessionID本身是很容易在网络上被监听的到，所以攻击者往往通过监听sessionID来达到进一步攻击的目的。

这些漏洞往往会存在于Web页面的“更改我的密码”、“记住我的密码”、“忘记密码”、“安全提问”、“注销登录”、“邮件地址”等环节上。

那么，一般来说，如何来防范这种漏洞呢？

第一，我们要整体审视我们的架构

●认证机制本身必须是简单、集中和标准化的；

●使用容器提供给我们的标准session id；

●确保在任何时候用SSL来保护我们的密码和session id

第二，验证认证的实现机制

●检查SSL的实现方法

●验证所有与认证相关的函数

●确保“注销登录”的动作能够关闭所有的会话

●使用OWASP的WebScrab来测试你的应用

如何进行验证测试

所谓认证，就是建立确信某物或某人是真实的这么一个过程，authentication来自于希腊语αυθεντικ??，即真实的，可信的。认证本身依赖于多个认证因子，在计算机安全领域，认证意味着验证通讯发起者的数字身份，常见的认证过程就是用户登录认证，所谓认证测试就是理解系统中的认证机制并找到方法绕过该认证机制。

认证测试需要考虑的点有很多，下面我们逐一来进行解释说明

在加密通道上传递密码

原则上，用户的认证必须通过加密信道进行传输，我们在这里的目的不是要验证诸如HTTPS是否安全，我们要验证的仅仅是用户的认证信息是否已经被加密了。

在用户登录时，最常见的方式是用户输入用户名和密码后，通过POST方法传输，一般来说，认证信息或者是通过不安全的HTTP传递，或者是通过加密的HTTPS传递。我们注意到，甚至有些网站在登录页面显示给我们的是HTTPS，但事实上却仍然是用HTTP的，最简单的方法就是用网络监听工具，如SnifferPro或Ethereal来判断是否是真实加密了。

下面，我们用OWASP的WebScrab截取一些信息来做个例子

假设，登录页面要求用户输入用户名和密码，然后有一个“提交”按钮，那么在WebScrab 中我们得到如下的请求数据：

POST https://www.doczj.com/doc/2b18999220.html,/AuthenticationServlet HTTP/1.1

Host: https://www.doczj.com/doc/2b18999220.html,

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://www.doczj.com/doc/2b18999220.html,/index.jsp

Cookie:

JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S! Content-Type: application/x-www-form-urlencoded

Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT

在上面的数据中，我们可以看到，POST方法通过HTTP协议把数据发送到

https://www.doczj.com/doc/2b18999220.html,/AuthenticationServlet，那么显然在这时，传送的数据没有进行加密，恶意用户通过监听网络就很容易得到用户名和密码。

再看下一个例子，假设是用HTTPS协议，那么请求的头数据如下：

POST https://https://www.doczj.com/doc/2b18999220.html,:443/cgi-bin/login.cgi HTTP/1.1

Host: https://www.doczj.com/doc/2b18999220.html,

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404

Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://https://www.doczj.com/doc/2b18999220.html,/cgi-bin/login.cgi

Cookie: language=English;

Content-Type: application/x-www-form-urlencoded

Content-length: 50

Command=Login&User=test&Pass=test

可见，上述例子中的数据经加密后被传送到

https://https://www.doczj.com/doc/2b18999220.html,:443/cgi-bin/login.cgi，这就确保了数据是加密的而不被其他人所窃取。

再看下面的一个例子，我们在一个可以通过HTTP协议访问到的页面上通过HTTPS协议来发送数据

POST https://https://www.doczj.com/doc/2b18999220.html,:443/login.do HTTP/1.1

Host: https://www.doczj.com/doc/2b18999220.html,

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://www.doczj.com/doc/2b18999220.html,/homepage.do

Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F Content-Type: application/x-www-form-urlencoded

Content-length: 45

User=test&Pass=test&portal=ExamplePortal

如上，我们看到，我们的请求通过HTTPS引向了https://https://www.doczj.com/doc/2b18999220.html,:443/login.do，但如果我们再看Referer的值，就发现我们是从HTTP页https://www.doczj.com/doc/2b18999220.html,/homepage.do

过来的。在这种情况下，我们的浏览器窗口中并不会告诉我们现在使用的安全连接，而事实上我们却正在使用安全连接。

在上面的例子中，如果我们用Get方法，那么所输入的用户名和密码将会以明文的方式显示在URL中，这显然是不可取的。那么，如果我们经由Get方法通过HTTPS来传递数据是否可行呢，看下面的数据

GET https://https://www.doczj.com/doc/2b18999220.html,/success.html?user=test&pass=test HTTP/1.1

Host: https://www.doczj.com/doc/2b18999220.html,

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://https://www.doczj.com/doc/2b18999220.html,/form.html

If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT

If-None-Match: "43a01-5b-4868915f"

从上面的例子可以看到，用户名和密码都以明文的方式在URL里存在，而不像上面的几个例子中都在消息体中，但并不是说攻击者就可以很容易看到这些信息，TLS/SSL毕竟是安全性很高的协议，整个HTTP数据包是加密的，但仍然要注意的是这些用户名和密码在传输过程中会被存储在代理和服务器上，这也就有可能会泄露用户信息。

●用户列举测试法

这种测试，简而言之是通过与应用的认证机制的交互，尝试能否获得一些正确的用户名，这对后面我们会讲到的暴力破解很有效，确认了正确的用户名就能用暴力破解去尝试密码了。

通常，WEB应用对于用户名正确的输入会有一些信息反馈，例如，如果我们输错了密码，那么有时会反馈告知我们系统存在该用户，或密码错误。所以，作为测试人员，就要尝试不同的请求来判断系统是否会有不同的返回。

对于HTTP的响应消息测试：

?输入正确的用户名和密码

期望结果：使用WebScrab抓取服务器的返回信息（HTTP 200 Response,消息的长度）

?输入正确的用户名/错误的密码

Web Services业务接口规范说明书

XXXX系统 Web Services业务接口规范说明书 拟制 审核 会签 批准 【公司名称】

版本历史

目录 1.范围 (1) 2.术语、定义和缩略语 (1) 2.1 术语、定义 (1) 2.2 缩略语 (1) 3.接口设计 (1) 3.1 接口公共参数 (1) 3.1.1请求参数 (1) 3.1.2返回参数 (2) 3.2 业务功能接口 (3) 3.2.1业务模块1 (3) 4.MD5加密 (6) 5.参考文献 (6)

1.范围 本规范文档主要适用于XXXX系统和其它业务系统信息数据的接入。 2.术语、定义和缩略语 2.1术语、定义 2.2缩略语 3.接口设计 3.1接口公共参数 接口服务器通过：http://IP:port/EIP/WebService/ 连接服务器，同时对外提供业务功能接口，接收的参数和返回的参数都用一定的xml格式进行封装。 3.1.1请求参数 1.请求类型为String类型

2.头部参数体head定义 请求参数的头部参数体header格式固定，定义如下：

3.请求参数体param定义 参数体param中的具体请求参数，根据不同的业务而不同，详见各业务接口。 3.1.2返回参数 1.返回类型为String类型

2.头部参数体head定义 返回参数的头部参数体header格式固定，定义如下： 3.返回值参数体result定义 参数体result中的具体返回参数，根据不同的业务而不同。详见各业务功能返回值参数体result定义。 注意：在value值标识为失败时，无论在任何业务功能下result都有可能为空。 4.返回value 值 <-- 注释 例如：

web常用测试方法

一、输入框 1、字符型输入框： （1）字符型输入框：英文全角、英文半角、数字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。 （2）长度检查：最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。 （3）空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空 格 （4）多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回 车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）、（5）安全性检查：输入特殊字符串 （null,NULL, ,javascript,,