OWASP TOP10-2010
开放式Web应用程序安全项目（OWASP，Open Web Application Security Project）是一个组织，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。https://www.doczj.com/doc/e011091835.html,
OWASP发布了最新的Web应用脆弱性的top10，这是继2007年OWASP对TOP10进行修订后进行的又一次更改，该版本暂定为OWASP TOP10-2010。在新版本的OWASP TOP10中主要由以下变化：
1.Top10的命名发生了变化。
原先的Top10全称为“The top10most critical web application security vulnerabilities”，即“Web应用的十大关键脆弱性”，现在Top10的全称为“The top10most critical web application security risks”，即“Web应用的十大关键风险”
2.OWASP Top10的风险评估方法
此次Top10的评估是依据OWASP的风险评估方法来对OWASP TOP10排序的。
3.替换了2个风险
此次Top10与2007年的Top10相比，在内容上去掉了“Malicious File Execution”(恶意文件执行)和“Information leakage and improper error handling”(信息泄露及不恰当的错
误处理)，增加了“Security misconfiguration”(错误安全配置)和“Unvalidated redirects and forwards”(未验证的重定向和传递)。
OWASP TOP102007OWASP TOP102010
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
}
https://www.doczj.com/doc/e011091835.html,存储过程示例：
Try
Dim command As SqlCommand=new SqlCommand(＂sp_getAccountBalance＂,connection) https://www.doczj.com/doc/e011091835.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,line113
同样可用于测试的还有“--”以及SQL中的一些诸如“AND”的关键字，通常很常见的一种测试是在要求输入为数字的输入框中输入字符串，会返回如下的错误信息：
Microsoft OLE DB Provider for ODBC Drivers error‘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,line113
类似上面这样的出错返回信息能让我们知道很多数据库的信息，通常不会返回那么多信
息，会返回诸如“500Server 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/e011091835.html,，那么我们的访问请求就是：
https://www.doczj.com/doc/e011091835.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/e011091835.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=1UNION ALL SELECT creditCardNumber,1,1FROM CreditCarTable
那么整体的查询就变为：
SELECT Name,Phone,Address FROM Users WHERE Id=1UNION ALL SELECT creditCardNumber,1,1FROM CreditCarTable
显然这样就能得到所有信用卡用户的信息。
盲SQL注入测试
在上面我们提到过盲SQL注入，即blind SQL injection，它意味着对于某个操作我们得不到任何信息，通常这是由于程序员已经编写了特定的出错返回页面，从而隐藏了数据库结构的信息。
利用推理方法，有时候我们能够恢复特定字段的值。这种方法通常采用一组对服务器的布尔查询，依据返回的结果来推断结果的含义。仍然延续上面的https://www.doczj.com/doc/e011091835.html,，有一个参数名为id，那么我们输入以下url请求：
https://www.doczj.com/doc/e011091835.html,/index.php?id=1'
显然由于语法错误，我们会得到一个预先定义好的出错页面，假设服务器上的查询语句为SELECT field1,field2,field3FROM Users WHERE Id='$Id'，假设我们想要得到用户名字段的值，那么通过一些函数，我们就可以逐字符的读取用户名的值。在这里我们使用以下的函数：SUBSTRING(text,start,length)，ASCII(char)，LENGTH(text)
我们定义id为：
$Id=1'AND ASCII(SUBSTRING(username,1,1))=97AND'1'='1
那么最终的SQL查询语句为：
SELECT field1,field2,field3FROM Users WHERE Id='1'AND ASCII(SUBSTRING(username,1,1))=97AND'1'='1'
那么，如果在数据库中有用户名的第一个字符的ASCII码为97的话，那么我们就能得到一个真值，那么我们就继续寻找该用户名的下一个字符；如果没有的话，那么我们就递增猜测第一个字符的ASCII码为98的用户名，这样反复下去就能判断出合法的用户名。
那么，什么时候我们可以结束推理呢，我们假设id的值为：
$Id=1'AND LENGTH(username)=N AND'1'='1
其中N是我们到目前为止已经分析的字符数目，那么整体的sql查询为：
SELECT field1,field2,field3FROM 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=‘
Select1from users
Where username=‘+@username+‘and passwd=‘+@passwd
exec(@sqlstring)
Go
用户的输入如下：
anyusername or1=1'
anypassword
如果我们没有对输入进行验证，那么上面的语句就会返回数据库中的一条记录。
我们再看下面的一条：
Create procedure get_report@columnamelist varchar(7900)As
Declare@sqlstring varchar(8000)
Set@sqlstring=‘
Select‘+@columnamelist+‘from ReportTable‘
exec(@sqlstring)
Go
如果用户输入是：
1from 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/e011091835.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.
如果我们已经过滤了”<”，或者是
%3cscript.src=https://www.doczj.com/doc/e011091835.html,/malicious-code.js%3e%3c/script%3e
\x3cscript.src=https://www.doczj.com/doc/e011091835.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/e011091835.html,/AuthenticationServlet HTTP/1.1
Host:https://www.doczj.com/doc/e011091835.html,
User-Agent:Mozilla/5.0(Windows;U;Windows NT5.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/e011091835.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/e011091835.html,/AuthenticationServlet，那么显然在这时，传送的数据没有进行加密，恶意用户通过监听网络就很容易得到用户名和密码。
再看下一个例子，假设是用HTTPS协议，那么请求的头数据如下：
POST https://https://www.doczj.com/doc/e011091835.html,:443/cgi-bin/login.cgi HTTP/1.1
Host:https://www.doczj.com/doc/e011091835.html,
User-Agent:Mozilla/5.0(Windows;U;Windows NT5.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/e011091835.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/e011091835.html,:443/cgi-bin/login.cgi，这就确保了数据是加密的而不被其他人所窃取。
再看下面的一个例子，我们在一个可以通过HTTP协议访问到的页面上通过HTTPS协议来发送数据
POST https://https://www.doczj.com/doc/e011091835.html,:443/login.do HTTP/1.1
Host:https://www.doczj.com/doc/e011091835.html,
User-Agent:Mozilla/5.0(Windows;U;Windows NT5.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/e011091835.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/e011091835.html,:443/login.do，但如果我们再看Referer的值，就发现我们是从HTTP页https://www.doczj.com/doc/e011091835.html,/homepage.do
过来的。在这种情况下，我们的浏览器窗口中并不会告诉我们现在使用的安全连接，而事实上我们却正在使用安全连接。
在上面的例子中，如果我们用Get方法，那么所输入的用户名和密码将会以明文的方式显示在URL中，这显然是不可取的。那么，如果我们经由Get方法通过HTTPS来传递数据是否可行呢，看下面的数据
GET https://https://www.doczj.com/doc/e011091835.html,/success.html?user=test&pass=test HTTP/1.1
Host:https://www.doczj.com/doc/e011091835.html,
User-Agent:Mozilla/5.0(Windows;U;Windows NT5.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/e011091835.html,/form.html
If-Modified-Since:Mon,30Jun200807:55:11GMT
If-None-Match:"43a01-5b-4868915f"
从上面的例子可以看到，用户名和密码都以明文的方式在URL里存在，而不像上面的几个例子中都在消息体中，但并不是说攻击者就可以很容易看到这些信息，TLS/SSL毕竟是安全性很高的协议，整个HTTP数据包是加密的，但仍然要注意的是这些用户名和密码在传输过程中会被存储在代理和服务器上，这也就有可能会泄露用户信息。
●用户列举测试法
这种测试，简而言之是通过与应用的认证机制的交互，尝试能否获得一些正确的用户名，这对后面我们会讲到的暴力破解很有效，确认了正确的用户名就能用暴力破解去尝试密码了。
通常，WEB应用对于用户名正确的输入会有一些信息反馈，例如，如果我们输错了密码，那么有时会反馈告知我们系统存在该用户，或密码错误。所以，作为测试人员，就要尝试不同的请求来判断系统是否会有不同的返回。
对于HTTP的响应消息测试：
?输入正确的用户名和密码
期望结果：使用WebScrab抓取服务器的返回信息（HTTP200Response,消息的长度）
?输入正确的用户名/错误的密码
期望结果：从浏览器我们往往会得到如下的返回
最受欢迎的十大WEB应用安全评估系统 在国内一些网站上经常看到文章说某某WEB应用安全评估工具排名，但是很可惜，绝大多数都是国外人搞的，界面是英文，操作也不方便，那游侠就在这里综合下，列举下国内WEB安全评估人员常用的一些工具。当然，毫无疑问的，几乎都是商业软件，并且为了描述更准确，游侠尽量摘取其官方网站的说明： 1.IBM Rational AppScan IBM公司推出的IBM Rational AppScan产品是业界领先的应用安全测试工具，曾以Watchfire AppScan 的名称享誉业界。Rational AppScan 可自动化Web 应用的安全漏洞评估工作，能扫描和检测所有常见的Web 应用安全漏洞，例如SQL 注入（SQL-injection）、跨站点脚本攻击（cross-site scripting）及缓冲溢出（buffer overflow）等方面安全漏洞的扫描。 游侠标注：AppScan不但可以对WEB进行安全评估，更重要的是导出的报表相当实用，也是国外产品中唯一可以导出中文报告的产品，并且可以生成各种法规遵从报告，如ISO 27001、OWASP 2007等。 2.HP WebInspect
目前，许多复杂的Web 应用程序全都基于新兴的Web 2.0 技术，HP WebInspect 可以对这些应用程序执行Web 应用程序安全测试和评估。HP WebInspect 可提供快速扫描功能、广泛的安全评估范围及准确的Web 应用程序安全扫描结果。 它可以识别很多传统扫描程序检测不到的安全漏洞。利用创新的评估技术，例如同步扫描和审核（simultaneous crawl and audit, SCA）及并发应用程序扫描，您可以快速而准确地自动执行Web 应用程序安全测试和Web 服务安全测试。 主要功能： ·利用创新的评估技术检查Web 服务及Web 应用程序的安全 ·自动执行Web 应用程序安全测试和评估 ·在整个生命周期中执行应用程序安全测试和协作 ·通过最先进的用户界面轻松运行交互式扫描 ·满足法律和规章符合性要求 ·利用高级工具（HP Security Toolkit）执行渗透测试 ·配置以支持任何Web 应用程序环境 游侠标注：毫无疑问的，WebInspect的扫描速度相当让人满意。 3.Acunetix Web Vulnerability Scanner
浅谈WEB应用安全问题及防范 随着WEB应用技术的发展，越来越多的企业或学校使用WEB应用来进行企业或学校信息开放性管理，使机构管理信息暴露在越来越多的威胁中。由于WEB应用具有一定的运行特点，传统防火墙对于其存在的安全问题缺少针对性和有效性，新的防护工具——Web应用防火墙应运而生。 标签：web应用开放性安全问题Web防火墙 随着信息资源逐渐向数据高度集中的模式，Web成为一种普适平台，Web 应用成为了越来越多的企业或学校进行核心业务及信息管理的承载者。Web应用提供了丰富的开放资源和高效率的新工作方式，但它的开放性、易用性和易开发性同样也使Web应用的安全问题日益突出，已成为了网络安全核心问题之一。 1 Web应用的工作原理和特点 Web应用程序首先是“应用程序”，和用标准的程序语言，如C、C++等编写出来的程序没有什么本质上的不同。然而Web应用程序又有自己独特的地方，就是它是基于Web的，而不是采用传统方法运行的。 目前广泛使用的Web应用程序一般是B/S模式，使用标准的三层架构模型：第一层是客户端；使用动态Web内容技术的部分属于中间层；数据库是第三层。在B/S模式中，客户端运行浏览器软件。浏览器以超文本形式向Web服务器提出访问数据库的要求，Web服务器接受客户端请求后，将这个请求转化为SQL 语法，并交给数据库服务器，数据库服务器得到请求后，验证其合法性，并进行数据处理，然后将处理后的结果返回给Web服务器，Web服务器再一次将得到的所有结果进行转化，变成HTML文档形式，转发给客户端浏览器以友好的Web 页面形式显示出来。 因此，Web应用具有以下特点： 1.1 易用性 Web应用所基于的Web浏览器的界面都很相似，对于无用户交互功能的页面，用户接触的界面都是一致的，因此Web应用的操作简单易上手。 1.2 开放性 在Web应用的B/S模式下，除了内部人员可以访问，外部的用户亦可通过通用的浏览器进行访问，并且不受浏览器的限制。 1.3 易扩展性
五个常见的Web应用漏洞及其解决方法开放Web应用安全项目（OW ASP）很快会发布今年的10大Web应用安全漏洞清单。这个清单与去年并没有太大差别，这表明负责应用设计与开发的人仍然没能解决以前那些显而易见的错误。许多最常见的Web应用漏洞仍然广泛存在，许多恶意软件搜索和攻击这些漏洞，连黑客新手都能轻松做到。 本文介绍了5个最常见的Web应用漏洞，以及企业该如何修复初级问题，对抗那些针对这些漏洞的攻击。 注入攻击和跨站脚本攻击 Web应用主要有2种最常见的严重缺陷。首先是各种形式的注入攻击，其中包括SQL、操作系统、电子邮件和LDAP注入，它们的攻击方式都是在发给应用的命令或查询中夹带恶意数据。别有用心的数据可以让应用执行一些恶意命令或访问未授权数据。如果网站使用用户数据生成SQL查询，而不检查用户数据的合法性，那么攻击者就可能执行SQL注入。这样攻击者就可以直接向数据库提交恶意SQL查询和传输命令。举例来说，索尼的PlayStation 数据库就曾经遭遇过SQL注入攻击，并植入未授权代码。 跨站脚本(XSS)攻击会将客户端脚本代码（如JavaScript）注入到Web应用的输出中，从而攻击应用的用户。只要访问受攻击的输出或页面，浏览器就会执行代码，让攻击者劫持用户会话，将用户重定向到一个恶意站点或者破坏网页显示效果。XSS攻击很可能出现在动态生成的页面内容中，通常应用会接受用户提供的数据而没有正确验证或转码。 为了防御注入攻击和XSS攻击，应用程序应该配置为假定所有数据——无论是来自表单、URL、Cookie或应用的数据库，都是不可信来源。要检查所有处理用户提供数据的代码，保证它是有效的。验证函数需要清理所有可能有恶意作用的字符或字符串，然后再将它传给脚本和数据库。要检查输入数据的类型、长度、格式和范围。开发者应该使用现有的安全控制库，如OW ASP的企业安全API或微软的反跨站脚本攻击库，而不要自行编写验证代码。此外，一定要检查所有从客户端接受的值，进行过滤和编码，然后再传回给用户。 身份验证和会话管理被攻破 Web应用程序必须处理用户验证，并建立会话跟踪每一个用户请求，因为HTTP本身不具备这个功能。除非任何时候所有的身份验证信息和会话身份标识都进行加密，保证不受其他缺陷（如XSS）的攻击，否则攻击者就有可能劫持一个激活的会话，伪装成某个用户的身份。如果一个攻击者发现某个原始用户未注销的会话（路过攻击），那么所有帐号管理功能和事务都必须重新验证，即使用户有一个有效的会话ID。此外，在重要的事务中还应该考虑使用双因子身份验证。 为了发现身份验证和会话管理问题，企业要以执行代码检查和渗透测试。开发者可以使用自动化代码和漏洞扫描程序，发现潜在的安全问题。有一些地方通常需要特别注意，其中包括会话身份标识的处理方式和用户修改用户身份信息的方法。如果没有预算购买商业版本，那么也可以使用许多开源和简化版本软件，它们可以发现一些需要更仔细检查的代码或进程。
常见WEB安全漏洞及整改建议 1. HTML表单没有CSRF保护 1.1 问题描述： CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。 CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。 1.2 整改建议： CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。有以下三种方法： (1).Cookie Hashing(所有表单都包含同一个伪随机值)： (2).验证码 (3).One-Time Tokens(不同的表单包含一个不同的伪随机值) 1.3 案例： 1.服务端进行CSRF防御 服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。 1.3.1 Cookie Hashing(所有表单都包含同一个伪随机值)： 这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败.
//构造加密的Cookie信息 $value = “DefenseSCRF”; setcookie(”cookie”, $value, time()+3600); ?> 在表单里增加Hash值，以认证这确实是用户发送的请求。 $hash = md5($_COOKIE['cookie']); ?> ”> 然后在服务器端进行Hash值验证 if(isset($_POST['check'])) { $hash = md5($_COOKIE['cookie']); if($_POST['check'] == $hash) { doJob(); } else {
Web应用常见的安全漏洞有哪些 随着存在安全隐患的Web应用程序数量的骤增，Open Web Application Security Project （开放式Web应用程序安全项目，缩写为OWASP）总结出了现有Web应用程序在安全方面常见的十大漏洞，以提醒企业及其程序开发人员尽量避免它们给企业IT系统带来的安全风险： 一、非法输入 Unvalidated Input 在数据被输入程序前忽略对数据合法性的检验是一个常见的编程漏洞。随着OWASP对Web应用程序脆弱性的调查，非法输入的问题已成为大多数Web应用程序安全漏洞方面的一个普遍现象。 二、失效的访问控制 Broken Access Control 大部分企业都非常关注对已经建立的连接进行控制，但是，允许一个特定的字符串输入可以让攻击行为绕过企业的控制。 三、失效的账户和线程管理 Broken Authentication and Session Management 有良好的访问控制并不意味着万事大吉，企业还应该保护用户的密码、会话令牌、
账户列表及其它任何可为攻击者提供有利信息、能帮助他们攻击企业网络的内容。 四、跨站点脚本攻击 XSS 跨站漏洞以及钓鱼式攻击 XSS，中文名称为跨站脚本，是一种很常见的脚本漏洞。因为跨站脚本攻击不能直接对系统进行攻击，所以往往被人们忽视。 由于WEB应用程序没有对用户的输入进行严格的过滤和转换，就导致在返回页面中可能嵌入恶意代码。远程攻击者可以利用这些漏洞在用户浏览器会话中执行任意HTML和脚本代码。跨站脚本执行漏洞的攻击效果需要借助第三方网站来显现，此这种攻击能在一定程度上隐藏身份。 由于跨站脚本不能直接对系统进行攻击，所以跨站脚本总是伴随社会工程学来 实现攻击的，这种攻击的主要表现形式是钓鱼式攻击。钓鱼式攻击方式有很多，如获取Cookie, 伪造页面,屏蔽页面特定信息,与其它漏洞结合攻击操作系统等等。钓鱼式攻击是针对人脑的攻击方式，它的传播手段有EMAIL、IM、聊天室、恶意连接、游戏中的聊天系统，凡是能实现用户之间互动操作的系统都存在钓鱼式攻击的风险。 在电子商务蓬勃发展的今天，针对个人财务信息的钓鱼攻击事件数量成直线上升，其中一个主要攻击途径就是跨站脚本执行漏洞。据统计，国内外存在跨站脚本漏洞的网站多达60%, 其中包括许多大型知名网站。 这是一种常见的攻击，当攻击脚本被嵌入企业的Web页面或其它可以访问的Web 资源中，没有保护能力的台式机访问这个页面或资源时，脚本就会被启动，这种攻击可以影响企业内成百上千员工的终端电脑。 网站开发者角度，如何防护XSS攻击? 对XSS最佳的防护应该结合以下两种方法：验证所有输入数据，有效检 测攻击;对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。 网站用户角度，如何防护XSS攻击? 当你打开一封Email或附件、浏览论坛帖子时，可能恶意脚本会自动执行，因此，在做这些操作时一定要特别谨慎。建议在浏览器设置中关闭
相关名词解释、危害与整改建议 1、网站暗链 名词解释 “暗链”就是看不见的网站链接，“暗链”在网站中的链接做的非常隐蔽，短时间内不易被搜索引擎察觉。它和友情链接有相似之处，可以有效地提高PR值。但要注意一点PR值是对单独页面，而不是整个网站。 危害： 网站被恶意攻击者插入大量暗链，将会被搜索引擎惩罚，降低权重值；被插入大量恶意链接将会对网站访问者造成不良影响；将会协助恶意网站（可能为钓鱼网站、反动网站、赌博网站等）提高搜索引擎网站排名。可被插入暗链的网页也意味着能被篡改页面内容。 整改建议： 加强网站程序安全检测，及时修补网站漏洞； 对网站代码进行一次全面检测，查看是否有其余恶意程序存在； 建议重新安装服务器及程序源码，防止无法到检测深度隐藏的恶意程序，导致重新安装系统后攻击者仍可利用后门进入。 2、网页挂马 名词解释 网页挂马是通过在网页中嵌入恶意程序或链接，致使用户计算机在访问该页面时触发执行恶意脚本，从而在不知情的情况下跳转至“放马
站点”（指存放恶意程序的网络地址，可以为域名，也可以直接使用IP地址），下载并执行恶意程序。 危害： 利用IE浏览器漏洞，让IE在后台自动下载黑客放置在网站上的木马并运行（安装）这个木马，即这个网页能下载木马到本地并运行（安装）下载到本地电脑上的木马，整个过程都在后台运行，用户一旦打开这个网页，下载过程和运行（安装）过程就自动开始，从而实现控制访问者电脑或安装恶意软件的目的。 整改建议： 加强网站程序安全检测，及时修补网站漏洞； 对网站代码进行一次全面检测，查看是否有其余恶意程序存在； 建议重新安装服务器及程序源码，防止有深度隐藏的恶意程序无法检测到，导致重新安装系统后攻击者仍可利用后门进入。 3、SQL注入 名词解释 SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL 命令。 危害： 可能会查看、修改或删除数据库条目和表。严重的注入漏洞还可能以当然数据库用户身份远程执行操作系统命令。
1.1身份认证安全 1.1.1弱密码 ●密码长度6个字符以上 ●密码字符必须包含大写字母、小写字母和数字，并进行密码复杂度检查 ●强制定期更换密码 1.1.2密码存储安全 密码存储必须使用单向加密 单纯的md5,sha1容易被破解，需要添加随机的盐值salt 涉及支付及财产安全的需要更高的安全措施，单纯的密码加密已经不能解决问题。 可以考虑手机验证码、数字证书、指纹验证。 1.1.3密码传输安全 1.1.3.1密码前端加密 用户名、密码传输过程对称加密，可以使用密钥对的对称加密，前端使用公钥加密，后端使用私钥解密。 前端加密示例
注意：前端密码加密如果还用了md5加密的，先md5加密再rsa加密。 后端解密，省略了其他验证步骤 1.1.3.2启用https协议 登录页面、支付页面等高危页面强制https协议访问。 前端加密和https可以结合使用 1.2SQL注入 1.2.1描述 SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应
用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。 1.2.2解决办法 1.养成编程习惯，检查用户输入，最大限度的限制用户输入字符集合。 2.不要把没有检查的用户输入直接拼接到SQL语句中，断绝SQL注入的注入点。 ●SQL中动态参数全部使用占位符方式传参数。 正确 ●如果不能使用占位符的地方一定要检查SQL中的特殊符号和关键字，或者启用用户输 入白名单，只有列表包含的输入才拼接到SQL中，其他的输入不可以。 1.2.3应急解决方案 nginx 过滤规则naxsi模块
2. jQuery 跨站脚本漏洞 2.1 问题描述 jQuery是继prototype之后又一个优秀的Javascrīpt框架。 jQuery 1.6.3之前版本中存在跨站脚本漏洞。当使用location.hash选择元素时，通过特制的标签，远程攻击者利用该漏洞注入任意web脚本或HTML。 2.2 整改方法 目前厂商已经发布了升级补丁以修复此安全问题，补丁获取： .ubuntu./usn/USN-1722-1/ 2.3 整改案例 升级jQuery版本。 3. 跨站脚本编制 3.1 问题描述： 跨站脚本攻击是通过在网页中加入恶意代码，当访问者浏览网页时恶意代码会被执行或者通过给管理员发信息的方式诱使管理员浏览，从而获得管理员权限，控制整个。攻击者利用跨站请求伪造能够轻松地强迫用户的浏览器发出非故意的HTTP请求，如诈骗性的电汇请求、修改口令和下载非法的容等请求。 风险等级：高 风险围： 任何存在输入/输出方法（包括GET与POST）的页面皆可能存在恶意符号输入缺陷，主要影响应用包括留言板、在线通讯信息、文章发布页面等。 3.2 整改建议： 对用户输入的参数执行严格检测： 1、对产生漏洞模块的传入参数进行有效性检测。int类型的只允许0-9的整型数字；string等字符类型的只允许(1-9，a-z，A-Z)的英文字母； 2、当客户端输入限定值意外的字符后，立即转向自定义的错误页，而不能使用服务器默认的错误输出方式； 3、对穿入参数进行危险字符过滤，禁止('、"、+、%、&、<>、（）、;、,.等)特殊字符的传入。 3.3 案例： 加固例（一）： /*将login.jsp中[String u =request.getParameter("u");]替换为如下容：*/ String u = request.getParameter("u"); u = u.replace ('＜','_'); u = u.replace ('＞','_'); u = u.replace('"','_');
SQL Injection(SQL 注入) 严重性 非常高 概述 就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。 原理 它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句 例子 程序从Http 请求中读取一个sql 查询， String sql ="SELECT * FROM accountWHERE name = 'Bob'AND password = '123'" request.getParameter(sql); ... stmt = conn.createStatement(); ... stmt.execute(sql)) 在执行execute()之前，并未进行对字符串sql检查，因此存在SQL 注入弱点。 所以，当在输入密码（password = '123'）之后+加上or '1'='1'则SQL查询语句变为：SELECT * FROM accountWHERE name = 'Bob'AND password = '123'or '1'='1'这样的SQL注入会使得输入任意密码进入程序,这会使WEB程序本身和使用用户产生极大的安全威胁。 后果 ?挂蠕虫、木马、病毒、制作钓鱼网站 ?操纵受害者的浏览器、盗取用户的cookie/referer/ip等信息
防范 1.永远不要信任用户的输入，要对用户的输入输出进行校验，可以通过正则表达式，或限制长度，或者使用过滤函数，对单引号和双"-"进行转换等。 2.永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。 3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。 4. 不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。 5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。 Cross-Site Scripting(跨站点脚本（XSS）) 严重性 非常高 概述 它指的是恶意攻击者往Web页面或者客户端脚本的页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。 原理 Stored XSS（存储式跨站脚本攻击） 这是最强大的一种XSS攻击，所谓存储跨站攻击是指用户提交给Web应用程序的数据首先就被永久的保存在服务器的数据库，文件系统或其他地方，后面且未做任何编码就能显示到Web页面。 Reflected XSS（反射跨站脚本攻击） 当Web客户端提交数据后，服务器端立刻为这个客户生成结果页面，如果结果页面中包含未验证的客户端输入数据，那么就会允许客户端的脚本直接注入到动态页面中。传统的例子是站点搜索引擎，如果我们搜索一个包含特殊HTML字符的字符串时，通常在返回页面
EMA服务管理平台二期扩容安全验收 漏洞修复总结 2011年5月
目录 1WEB安全介绍 (1) 2SQL注入、盲注 (1) 2.1SQL注入、盲注概述 (1) 2.2安全风险及原因 (2) 2.3A PP S CAN扫描建议 (2) 2.4应用程序解决方案 (4) 3会话标识未更新 (7) 3.1会话标识未更新概述 (7) 3.2安全风险及原因分析 (8) 3.3A PP S CAN扫描建议 (8) 3.4应用程序解决方案 (8) 4已解密登录请求 (9) 4.1已解密登录请求概述 (9) 4.2安全风险及原因分析 (9) 4.3A PP S CAN扫描建议 (9) 4.4应用程序解决方案 (9) 5跨站点请求伪造 (11) 5.1跨站点请求伪造概述 (11) 5.2安全风险及原因分析 (12) 5.3A PP S CAN扫描建议 (13) 5.4应用程序解决方案 (13) 6不充分账户封锁 (13) 6.1不充分账户封锁概述 (13) 6.2安全风险及原因分析 (13) 6.3A PP S CAN扫描建议 (14) 6.4应用程序解决方案 (14) 7启用不安全HTTP方法 (14) 7.1启用不安全HTTP方法概述 (14) 7.2安全风险及原因分析 (15) 7.3A PP S CAN扫描建议 (15) 7.4应用程序解决方案 (15) 8HTTP注释敏感信息 (16) 8.1HTTP注释敏感信息概述 (16) 8.2安全风险及原因分析 (16) 8.3A PP S CAN扫描建议 (16) 8.4应用程序解决方案 (17) 9发现电子邮件地址模式 (17)
Web应用是指采用B/S架构、通过HTTP/HTTPS协议提供服务的统称。随着互联网的广泛使用，Web应用已经融入到日常生活中的各个方面：网上购物、网络银行应用、证券股票交易、政府行政审批等等。在这些Web 访问中，大多数应用不是静态的网页浏览，而是涉及到服务器侧的动态处理。此时，如果Java、PHP、ASP 等程序语言的编程人员的安全意识不足，对程序参数输入等检查不严格等，会导致Web应用安全问题层出不穷。 本文根据当前Web应用的安全情况，列举了Web应用程序常见的攻击原理及危害，并给出如何避免遭受Web 攻击的建议。 1Web应用漏洞原理 Web应用攻击是攻击者通过浏览器或攻击工具，在URL或者其它输入区域（如表单等），向Web服务器发送特殊请求，从中发现Web应用程序存在的漏洞，从而进一步操纵和控制网站，查看、修改未授权的信息。 1.1Web应用的漏洞分类 1、信息泄露漏洞 信息泄露漏洞是由于Web服务器或应用程序没有正确处理一些特殊请求，泄露Web服务器的一些敏感信息，如用户名、密码、源代码、服务器信息、配置信息等。 造成信息泄露主要有以下三种原因： ?Web服务器配置存在问题，导致一些系统文件或者配置文件暴露在互联网中； ?Web服务器本身存在漏洞，在浏览器中输入一些特殊的字符，可以访问未授权的文件或者动态脚本文件源码； ?Web网站的程序编写存在问题，对用户提交请求没有进行适当的过滤，直接使用用户提交上来的数据。 2、目录遍历漏洞 目录遍历漏洞是攻击者向Web服务器发送请求，通过在URL中或在有特殊意义的目录中附加“../”、或者附加“../”的一些变形（如“..\”或“..//”甚至其编码），导致攻击者能够访问未授权的目录，以及在Web服务器的根目录以外执行命令。 3、命令执行漏洞 命令执行漏洞是通过URL发起请求，在Web服务器端执行未授权的命令，获取系统信息，篡改系统配置，控制整个系统，使系统瘫痪等。 命令执行漏洞主要有两种情况：
Web应用中常见39种不同的安全漏洞漏洞分析及检查方法 1.1SQL注入漏洞 风险等级：高危 漏洞描述： SQL注入漏洞产生的原因是网站应用程序在编写时未对用户提交至服务器的数据进行合法性校验，即没有进行有效地特殊字符过滤，导致网站服务器存在安全风险，这就是SQL Injection，即SQL注入漏洞。 漏洞危害： 1) 机密数据被窃取； 2) 核心业务数据被篡改； 3) 网页被篡改； 4) 数据库所在服务器被攻击从而变为傀儡主机，导致局域网(内网)被入侵。 修复建议： 1)在网页代码中对用户输入的数据进行严格过滤；（代码层） 2)部署Web应用防火墙；（设备层） 3)对数据库操作进行监控。（数据库层） 代码层最佳防御sql漏洞方案：采用sql语句预编译和绑定变量，是防御sql注入的最佳方法。 原因：采用了PreparedStatement，就会将sql语句："select id, no from user where id=?" 预先编译好，也就是SQL引擎会预先进行语法分析，产生语法树，生成执行计划，也就是说，后面你输入的参数，无论你输入的是什么，都不会影响该sql语句的语法结构了，因为语法分析已经完成了，而语法分析主要是分析sql
命令，比如select ,from ,where ,and, or ,order by 等等。所以即使你后面输入了这些sql命令，也不会被当成sql命令来执行了，因为这些sql命令的执行，必须先的通过语法分析，生成执行计划，既然语法分析已经完成，已经预编译过了，那么后面输入的参数，是绝对不可能作为sql命令来执行的，只会被当做字符串字面值参数，所以sql语句预编译可以防御sql注入。 其他防御方式：正则过滤 1.2目录遍历漏洞 风险等级：中危 漏洞描述： 通过该漏洞可以获取系统文件及服务器的配置文件。利用服务器API、文件标准权限进行攻击。 漏洞危害： 黑客可获得服务器上的文件目录结构，从而下载敏感文件。 修复建议： 1)通过修改配置文件，去除中间件（如IIS、apache、tomcat）的文件目录索引功能 2)设置目录权限 3)在每个目录下创建一个空的index.html页面。 1.3跨站脚本漏洞 即XSS漏洞，利用跨站脚本漏洞可以在网站中插入任意代码，它能够获取网站管理员或普通用户的cookie，隐蔽运行网页木马，甚至格式化浏览者的硬盘。
常见WEB开发安全漏洞原因分析及解决
目录 1会话标识未更新 (3) 1.1原因 (3) 1.2解决 (3) 2SQL注入 (3) 2.1原因 (3) 2.2解决 (5) 3XSS跨站脚本编制 (5) 3.1原因 (5) 3.2解决 (5) 4XSRF跨站请求伪造 (7) 4.1原因 (7) 4.2解决 (8) 5登录错误消息凭证枚举（不充分帐户封锁） (8) 5.1原因 (8) 5.2解决 (8) 6HTML注释敏感信息泄露 (9) 6.1原因 (9) 6.2解决 (9) 7应用程序错误 (9) 7.1原因 (9) 7.2解决 (9) 8已解密的登录请求 (9) 8.1原因 (9) 8.2解决 (9) 9启用了不安全的HTTP方法 (10) 9.1原因 (10) 9.2解决 (10) 10禁止页面缓存 (11) 10.1原因 (11) 10.2解决 (11) 11数据库错误模式 (11) 11.1原因 (11) 11.2解决 (12)
1 会话标识未更新 1.1 原因 在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息，登录以后，session的id不会改变，也就是说还是以前的那个session（事实上session也确实不会改变，因为没有建立新session，原来的session也没有被销毁）。 很多人只是让会话invalidate没有用（request.getSession().invalidate();），是因为invalidate方法不是真正的将session销毁，只是将session中的内容清空，所以当invalidate以后再新建session，新建的session其实不是新的，是将之前的session重新启用了。于是session的id 不变就不奇怪了。只有cookie失效掉，才能换成新的session id 1.2 解决 在登录页面上加上一段代码： request.getSession().invalidate() ; //清空session if (request.getCookies()!=null) { Cookie cookie = request.getCookies()[0]; // 获取cookie cookie.setMaxAge(0); // 让cookie过期 } 注：会话失效后，请不要在代码前面使用SESSION保存数据。 2 SQL注入 2.1 原因 1. 没有正确过滤转义字符 在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL 语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞： statement := "SELECT * FROM users WHERE name = '" + userName + "'; " 将用户名变量(即username)设置为：a' or 't'='t，此时原始语句发生了变化. 2. 用户输入错误的数据类型 如果一个用户提供的字段并非一个强类型，或者没有实施类型强制，就会发生这种形式的攻击。