WEB安全性-2010_OWASP_TOP10

OWASP TOP 10-2010开放式Web应用程序安全项目（OWASP，Open Web Application Security Project）是一个组织，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。

其目的是协助个人、企业和机构来发现和使用可信赖软件。

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 2010A2-注入 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大量的敏感数据泄漏9A1-注入注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行。

常见的注入包括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存储过程示例：TryDim command As SqlCommand = new SqlCommand(＂sp_getAccountBalance＂,connection) 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 注入：最小权限法、输入验证白名单法。