毕业论文-Web应用程序安全漏洞知识库初探

盐城师范学院毕业设计毕业设计Web应用程序安全漏洞知识库初探学生姓名学院专业计算机科学与技术班级学号指导教师2016年5月16日Web应用程序安全漏洞知识库初探摘要随着互联网的迅速发展，目前很多业务都依赖于互联网，比如网上银行业务、旅游在线购票业务、网上购物业务等，Web应用程序和人们的日常生活息息相关。很多恶意攻击者会想法设法对Web服务器进行攻击，从中盗取他人的个人账户信息来换取他们的利益。为了防止恶意攻击者的攻击，除了对Web服务器做相应的安全配置外，Web应用程序的设计和实现过程中也需要排除恶意攻击者攻击的隐患。但是在互联网上还无法找到对于Web应用程序安全漏洞的系统性介绍工具或文章，这对程序开发人员对于漏洞机理的理解也造成了困扰。本文主要对OWASPTOP102013的十大安全漏洞进行分析和整理研究。文中介绍了OWASPTOP10的相关漏洞的机理研究以及预防措施。针对所整理的内容制作Web应用程序安全安全漏洞展示系统，系统包括用户注册以及登录界面，调研内容展示模块。系统运用软件开发流程的方法进行相应的需求分析，然后基于C#语言进行系统编码，设计并且实现了Web应用程序安全漏洞展示系统。分析这些经典的漏洞，旨在帮助程序开发员提升他们的编码安全意识，加强Web应用程序的安全性。【关键词】Web；应用程序；漏洞展示；OWASPTOP102013TheDesignandImplementationofWebApplicationSecurityVulnerabilitiesKnowledgeBaseABSTRACTWiththerapiddevelopmentoftheInternet,manybusinessesrelyontheInternet,suchasonlinebanking,onlinetravelbookingservices,onlineshoppingservices,etc.TheWebapplicationprogramiscloselylinkedwithpeople'slife.ManymaliciousattackersfindwaystoattacktheWebserverfortheirbenefitsbystealingpeople'spersonalaccountinformation.Therefore,Webservicesplatformisoftenunderattack.InadditiontotheWebservertodothecorrespondingconfiguration,Webapplicationdesignanddevelopmentprocessalsoneedtoexcludetheriskofmaliciousattacks.Howeverweyetcouldn'tfindthesystematicintroductiontooloressayforWebapplicationprogramsecurityvulnerabilities,Whichperplexestheunderstandingofvulnerabilitymechanismfortheapplicationdeveloper.ThisthesisfocusesonOWASPTOP102013Ten-securityvulnerabilityanalysisandorganizesresearch.ThispaperdescribesthemechanismanalysisandpreventivemeasuresofOWASPTOP10thatrelatedvulnerabilities.TheproductionofWebapplicationprogramsecurityvulnerabilitiespresentationsystemisbasedoncollativecontents,whichincludinguserregistrationandloginscreen,theresearchcontentdisplaymodule.SystemdoestherelevantdemandanalysisbyusingthemethodofsoftwaredevelopmentprocessandbasingonC#languagetosystemscode,designandrealizeaWebapplicationprogramsecurityvulnerabilitiesdisplaysystem.AnalysesoftheseclassicloopholesaimtohelpprogrammerstoenhancetheircodingsecurityawarenessandstrengthenthesecurityofWebapplications.[Keywords]Web,Applicationprogram,Displaysystem,OWASPTOP10201323

目录259991引言 页，共48页1引言1.1研究背景与应用前景伴随着科技的快速发展，互联网行业成为了当今最热门、发展前景最好的行业。Internet已经成为世界上一个非常重要的基础平台，很多企业都将应用架设在该平台上，为了给客户提供更加方便和快捷的服务支持。这些Web应用在功能和性能上都在不断的完善和提高，但是在最重要的安全性上，却常常遭受到忽略。因为现在的网络技术慢慢变得成熟，黑客们也把对网络服务器的攻击的注意力都渐渐转移到了对Web应用程序的攻击上面。根据Gartner的最新调查，信息安全攻击有75%都是发生在Web应用而不是网络层面上。与此同时，数据也显示出将近三分之二的Web站点都相当容易遭受攻击[1]。目前的形式是，大部分的企业都在网络和服务器的安全上花费了大量的资金，却没有实质地保证Web应用本身的安全，给恶意攻击者提供了攻击的机会。Web攻击是当前数据窃取的主要途径。相关数据显示当前57%的数据窃取攻击都是经由对Web的攻击来实现。Web的攻击威胁是偷偷进入企业网络在用户完全没有察觉的情况下，从而对公司的业务造成极大威胁，其中这些威胁包含对数据资产的盗取、行业信誉的破坏以及关键业务的窃取。即使一些看起来不重要的信息，经过盗取者的汇集和归纳，后果也可能导致公司内部设置、核心客户等重要信息泄露。根据C#的软件开发与设计规范，本文基于该平台上设计并实现了这个Web应用程序安全漏洞展示系统软件。它里面的内容着重详述了当前热门的OWASPTOP10漏洞的成因、历史事件、和漏洞防范等。为程序开发者提供方便快捷地查询以及提升防范意识。1.2本文的论文工作介绍研究工作：近几年来，由于互联网的飞速发展，人们的生活已经离不开互联网。本人根据Web许多安全方面频频遭受攻击，对OWASPTOP102013的十大漏洞进行分析和调研。将漏洞的机理、修复方法、检测方法以及预防方法进行整合。实现工作：本人通过学习查阅C#开发资料设计并实现了本Web代码安全漏洞展示系统。实现了系统的前端用户注册登录界面，以及漏洞各方面的详述。通过查阅网站上的博客以及书籍，将OWASPTOP102013的漏洞进行了详细地整理。（1）构造程序漏洞及其机理分析框架：定义－威胁－成因－检测方法－修复建议－预防办法。（2）基于漏洞分析框架，针对2013年OWASPTOP10漏洞进行分析：1）注入式漏洞2）跨站脚本攻击3）不正确的直接对象引用漏洞4）伪造跨站请求漏洞5）未验证的重定向和转发漏洞6）安全配置错误漏洞7）敏感数据暴露漏洞8）使用已知易受攻击的组件漏洞9）缺少功能层面的访问控制漏洞10）错误的会话认证和会话管理漏洞（3）基于漏洞分析，构造漏洞知识库系统：1）注册子系统2）登录子系统3）漏洞知识展示子系统1.3论文组织结构第一部分引言部分。介绍了项目的研究背景以及应用前景，和对于论文工作的一个简要综述。第二部分Web应用程序漏洞分析框架部分。将项目所设计到的经典漏洞依次进行详细的介绍。主要是对漏洞的定义、威胁、成因、检测方法、修复方法和预防方法进行解释说明。第三部分系统分析与设计部分。提出项目需求，根据需求对项目包含的主要业务进行介绍，对项目的主要模块进行划分和介绍。对于核心业务模块的实现方法重点详述，其中包括登陆模块、注册模块和漏洞知识展示模块。2Web应用程序漏洞分析框架根据对系统的需求分析，创建一个带有登录和注册功能的漏洞知识库，主要包含登录和注册界面和对漏洞详细介绍的界面，漏洞知识库中着重讲解了OWASP（TheOpenWebApplicationSecurityProject，开放式Web应用程序安全项目）2013TOP10漏洞，经过调研和整理完成漏洞知识库的初探，典型漏洞有注入式漏洞、跨站脚本攻击漏洞、不正确的直接对象引用漏洞、伪造跨站请求漏洞、未验证的重定向和转发漏洞、安全配置错误漏洞、敏感数据暴露漏洞、使用已知易受攻击组件漏洞、缺少功能层面访问控制漏洞、错误的会话认证和会话管理这十大漏洞，下面对于各个漏洞的定义、成因、经典案例、检测方法和防范方法进行依次介绍。2.1注入式漏洞简介2.1.1注入式漏洞定义注入式攻击主要是利用系统中某一模块或组建的设计约定、语法约定等特点，采用组成新的合法设计、合法语法的方式来获得新的解释进行攻击。在这个解释中，有一部分内容根本不是程序设计者的愿意，这部分是被攻击者在原意的基础上新注入的，因此被称为注入式攻击。根据注入问题产生的原因和背景，注入可以分为很多种类型：OS命令注入、XPath注入、SSI注入、SQL注入、LDAP注入、XML注入以及XQuery注入等。2.1.2SQL注入产生的原因及过程根据不同的数据支持的SQL语法不同，SQL注入产生的原因也有可能不同，但是其根本原因是相似的，原因主要有以下几种：（1）组合SQL命令中，可以注入注释，比如，两个连续的减号字符“--”后的文字为注解，或者由“/*”与“*/”包围起来的文字为注释。（2）在组合SQL的命令字符串时，如果没有针对“’”这个特殊字符进行取代处理，将会导致该字符串在填入命令字符串时，恶意篡改原来的SQL语句结构的作用。（3）SQL命令可以进行插入、查询、删除、更新等操作，也可以将这些命令传戒起来，采用分号字符区分不同命令。（4）SQL命令对于传入的字符串参数使用单引号字符包围起来的，同时SQL也规定了连续两个单引号字符在SQL数据库中被视为字符串中的一个单引号字符，那么在这种情况下，单引号就被转义了[6]。具体注入过程如图2-1所示：图2-1SQL注入过程图2-2SQL注入界面1）恶意攻击者首先对登录界面进行访问，界面如图2-2所示。2）恶意攻击者填写用户名和密码，点击提交按钮，应用程序Web服务器接受到恶意攻击者提交的内容。3）这些含有攻击的字符串在应用程序Web服务器被组成的SQL语句，同时转发给数据库服务器执行。4）应用程序服务器接收来自于数据库的执行结果。5）浏览器接收来自应用程序发送的内容，这时恶意攻击者可以在浏览器上看到注入的数据执行结果，然后登录进去，完成此次攻击。2.1.3SQL注入漏洞经典案例及修改方法经典案例：登录网站的SQL代码可能为：Stringusername=request.getParameter(“username”);Stringpassword=request.getParameter(“password”);Stringquery=”SELECTidFROMusersWHEREusername=”+username+”ANDpassword=”+password;Statementstmt=con.executeStatement(query);ResultSetrs=con.executeQuery(query);If(rs.next()){//登录成功…}else{//登录失败…}假设有一个名叫John的用户密码为abcd，那么登录时，形成的SQL语句如下：SELECTidFROMusersWHEREusername=’John’ANDpassword=’abcd’如果恶意输入用户名：uername=“’OR’1’=’1”;或者输入密码为：Password=“’OR’1’=’1”;将会导致原来的SQL语句篡改为：StrSQL=”SELECTidFROMusersWHEREusername=’’OR’1’=’1ANDpassword=’’OR’1’=’1’”;对于SQL解析器来说，这是一个可以正确解析并且可以被执行的SQL语句，事实上它确实被执行了，执行的结果实际上等效于：SELECTidFROMusers;只要数据库有数据，那么这条语句就可以获取users表中每一条记录，有的Web应用程序会选择返回的第一条记录作为登录的用户，而很多系统可能第一个用户是管理员，那么情况就会更糟。通过这种方式，可以实现即使没有账号，也可以登录。另外，如果恶意输入用户名：Username=”’OR’1’=’1”;droptableusers;--结果SQL仍然可以正确解析，并且被执行，这样会导致users表被删除，所有用户将不能再登录。解决方法：可以把用户登录的代码改为：Stringusername=request.getParameter(“username”);Stringpassword=request.getParameter(“password”);Stringquery=”SELECTidFROMusersWHEREusername=：nmANDpassword=：pw”;Queryquery=session.createQuery(query)Query.setString(“nm”,user)Query.setString(“pw”,pass)2.1.4SQL注入的检测方法以及检测工具对于利用Web进行的攻击，变化比较多样，隐蔽性也非常强，不易被发觉，因为普通防火墙对HTTP/HTTPS是完全开放的，传统的IDS（IntrusionDetectionSystems，入侵检测系统）对其也不起什么作用。对于SQL注入的检测，目前主要通过以下两种途径进行。第一种途径就是通过Get方法发送的请求的参数的后面添加单引号（’）看看是否有报错。如果是SQL执行有错，可能就存在SQL注入的风险。例如，SQLServer报错如下：MicrosoftJETDatabaseEngine错误‘80040e14’字符串的语法错误在查询表达式‘id=16’中。/login.asp，行23如果使用的是IE浏览器，可能看到的是显示500的错误，而不是这些具体的信息，可以修改浏览器设置，具体方法是选择“工具->Internet选项->高级”，取消“显示友好HTTP错误信息”的勾选即可。对于不同的参数，判断方法也不稍有不同。（1）整形参数当输入的参数是整形时，如ID、年龄、个数等，若是查询操作，可以猜测SQL语句大致如下：select*fromtablewhere字段名=输入的值测试步骤如下。1）：HTTP:///test.asp?id=1’，如果SQL查询语句变成select*fromtablewhereid=1’，那么test.asp会出现运行异常。2）：HTTP:///test.asp?id=1and1=1，页面运行正常，且结果与HTTP:///test.asp?id=1运行结果相同。3）：HTTP:///test.asp?id=1and1=2，运行出现异常或者和HTTP:///test.asp?id=1运行结果不同。如果以上三步全部满足，则一定存在SQL注入漏洞。（2）字符串参数当输入的字符串是字符串类型时，SQL语句可能如下：Select*fromtablewhere字段名=’输入的值’HTTP:///test.asp?name=1HTTP:///test.asp?id=1’，如果SQL查询语句变成select*fromtablewhereid=1’，那么test.asp会出现运行异常。HTTP:///test.asp?id=1and1=1，页面运行正常，且结果与HTTP:///test.asp?id=1运行结果相同。HTTP:///test.asp?id=1and1=2，运行出现异常或者和HTTP:///test.asp?id=1运行结果不同。如果以上三步全部满足，则一定存在SQL注入漏洞。第二种途径是，对于一些通过POST的请求，很难直接通过浏览器URL修改参数来测试，可以通过一些工具的辅助达到测试目标，例如，OWASP的ZAP和Fiddler工具（安装Watch插件）。通过这些工具可以发动自动渗透测试，也可以拦截请求，通过修改请求消息中的参数值进行测试。2.1.5SQL注入的预防措施预防SQL注入漏洞的主要措施如下所示：1）在服务器端要对所有的输入数据验证有效性。2）在处理输入之前，验证所有客户端提供的数据，包括所有参数、URL和HTTP头的内容。3）验证输入数据的类型、长度和合法的取值范围。4）使用白名单验证允许的输入字符而不是黑名单。5）如果危险的字符必须作为输入的一部分，在使用前必须转义或者编码。6）明确所有输入的正确的字符集，如UTF-8。7）如果系统使用的是UTF-8扩展字符集，在UTF-8解码之后验证数据的有效性。8）不要动态组装SQL语句。9）如果动态组装SQL语句，确保在使用输入的数据组装SQL语句之前，对特殊字符进行转义。10）在使用第三方框架或者库时，需要确认是否有注入的问题，如果有注入问题，要做好预防措施，如Hibernate就有SQL注入问题，需要在调用之前将输入的特殊字符进行转义。11）对于需要产生命令运行的数据，保持尽量少的数据由外部输入，例如，能传参数的就不要穿命令行。12）以最小权限运行。2.2跨站脚本攻击简介2.2.1跨站脚本攻击漏洞定义用户在浏览网站、使用通讯软件或者是电子邮件的时候，会发现有很多链接存在其中，用户通常都会点击这些链接想看到自己想看的内容。恶意攻击者通过掌握这一习性，会把恶意代码插入到链接中，用户点击链接，恶意代码就能够盗取用户信息。为了避免用户怀疑制作恶意链接的合法性，这些链接编码会被恶意攻击者用十六进制编码。这样一个看似合法的页面就生成了，其实页面里包含了攻击者制造的恶意脚本，用户点击之该链接的同时，私密信息就遭到了泄露。跨站脚本攻击是一种网站应用程序的安全漏洞攻击，是脚本代码注入的一种。它允许恶意用户将恶意脚本代码注入到网页上，其他用户在观看网页时，恶意脚本就会执行。这类攻击通常通过注入HTML或者JavaScript/VBScript脚本发动攻击。攻击成功后，攻击者可以得到私密网页内容和Cookie等各种内容。很多知名网站都曾经受到过这种攻击，如Twitter、Facebook、MySpace、Yahoo、新浪微博等。最近几年XSS攻击已经超过了缓冲区溢出攻击，成为最流行的攻击方式[4]。2.2.2跨站脚本攻击漏洞的分类及原理到目前为止，XSS(Cross-SiteScripting,跨站脚本攻击)漏洞主要分成3类：反射式跨站脚本攻击、存储式跨站脚本攻击和基于DOM的跨站脚本攻击。下面介绍每种类型的特征以及原理：（1）反射式XSS也称为非永久性XSS，是目前最流行的一种XSS攻击。它经常出现在服务器直接使用客户端提供的数据（包括URL中的数据、HTTP协议头的数据和HTML表单中提交的数据），而且没有对数据进行无害化处理。由于HTML文档是一个扁平的连续结构，同时其中还有一些控制语句，那么如果客户提交的数据没有经过正确的HTML编码而直接使用，就可能导致脚本注入。如果查询的字符串中含有HTML而且没有被正确处理，一个XSS攻击就会发生。典型的反射式攻击可以通过邮件或者一个中间的网站，诱饵是一个看起来没有危害的指向一个信任站点的链接，其中包含有XSS攻击向量。如果信任的网站没有处理这个向量，客户点击这个链接就会导致浏览器执行注入的脚本[5]。如图2-3所示：图2-3反射式XSS过程1）A访问网站这个网站比较频繁，A有登录的登录用户名及登录密码并且还在这个网站上存储了敏感数据，比如支付账户、支付密码、收货地址等信息。2）B发现这个网站上存在有反射式跨站脚本攻击漏洞，他就通过这个网站存在反射式跨站脚本攻击漏洞构造了一个URL，然后通过邮件的方式发送给A，让A通过点击他构造的URL来访问3）A访问B提供的URL并且登录到。4）把含有嵌入的恶意攻击的JavaSprint代码返回结果发送给A。5）A接收到返回结果后，含有恶意攻击的代码在A的浏览器中被执行，这个恶意代码可以将A的会话Cookie在A不知情情况下发送给B控制的站点www.B。6）B可以从他控制的网站www.B中获取A的会话Cookie。7）B使用他获取的会话Cookie盗取A的个人信息，此时A还不知道自己的信息被窃取。（2）存储式XSS也称为永久性的XSS，它的危害更大。典型的例子就是在交友网站上，如果一个人在自己的信息上写上一段脚本，如“自我介绍<script>windows.open(?yourcookie=document.cookie)</script>”，这个网站没有对自我介绍的内容进行正确的编码。当网站的其他用户看这个用户的信息时，这个用户将会得到所有看他的自我介绍的用户会话Cookie。更严重的是，如果攻击者的恶意代码可以自我扩散，特别是在社交网络上，就会形成蠕虫。早期的Samyworm就是一个典型的例子[6]。如图2-4所示。图2-4存储式XSS过程1）B发现这个网站上存在存储式跨站脚本攻击漏洞，B向这个网站发送一条含有恶意的消息。2）接收消息并且存储消息。3）A在浏览过程中发现这条消息，由于对这条消息好奇就点击链接对这条消息的内容进行读取。4）会把这条消息从原本存储的地方提取出来给A查看。5）当A读取到这条消息后，消息中包含的恶意代码就会在A当前使用的浏览器上悄悄执行。6）然后A的Cookie会被执行的恶意代码全部发送到B控制的网站上。7）B从他控制www.B这个网站上面获取A的会话Cookie。8）这个时候，B就可以借助他获取的A的Cookie劫持A的会话，冒充A。（3）基于DOM的XSS传统意义上，XSS漏洞发生在由服务器产生并且发回到客户端的页面上。随着Web2.0的出现，一种新型的XSS漏洞也浮出水面，它就是基于DOM的XSS。基于DOM的XSS发生在客户端处理内容的阶段，发生在客户端控制。基于DOM的XSS利用场景和反射式的XSS的原理基本一样，不同的是：基于DOM的XSS在服务器端没有办法控制，必须在客户端控制。2.2.3跨站脚本漏洞经典案例及修改方法经实例代码：本次例子中都以输入字符串是“XSSTest<&’/”>”<html><head><title>ForTest4.2.3HTMLbasedinjection</title><metahttp-equiv=”content-type”content=”text/html;charset=utf-8”></head><script>varsearchValue=<%=searchValue%>;</script><body><formname=”myForm”>您搜索的内容是：<%=searchValue%>结果如下：<table><tr><td>Name</td><td>Address</td></tr><tr><tdid=”td1”><%=name%></script></td><tdid=”td2”><%=Address%></td></tr></table></form></body></html>在搜索“XSSTest<&’”>”之后，即使我们不知道这个源码，也可以通过浏览器的查看源代码菜单，猜测页面的源代码可能为：<html><head><title>ForTest4.2.3HTMLbasedinjection</title><metahttp-equiv=”content-type”content=”text/html;charset=utf-8”></head><script>varsearchValue=XSSTestxxxx;</script><body><formname=”myForm”>您搜索的内容是：XSSTestxxxx结果如下：<table><tr><td>Name</td><td>Address</td></tr><tr><tdid=”td1”><%=name%></script></td><tdid=”td2”><%=Address%></td></tr></table></form></body></html>在页面源码中，搜索“XSSTest”，然后在看“<&’”>”这几个字符的编码是不是正确，如果不正确，再根据一些页面源代码结构，构造一些可能导致攻击的字符串，进行尝试攻击。常用的测试字符串如下：（1）：JavaSprint注入的代码:“><script>alert(document.cookie)</script></script><script>alert(document.cookie)</script>（2）：HTML常用的注入代码：<aherf=javascript:alert(1)>DEF</a><imgsrc=asdfonerror=alert(document.cookie)>更多测试字符串可以参考：/xss.html2.2.4跨站脚本漏洞的检测方法以及检测工具（1）手动检测手动检测，就是依靠手工输入来检测网页是否有错误，这种检测主要是手工修改文本框（包括被隐藏的）或者URL中的参数，提交请求后，再在网页中查找是否有修改自己的参数显示，包括HTML和JavaSprint中，如果在HTML和JavaSprint中有，则看看编码是不是正确，如果编码不正确，那么就有可能有XSS问题。输入的字符串也不能随便选择，需要选择一些有特殊意义的字符，例如：<、>、&、’、”，输入的字符串最好包括所有这些特殊字符，这样才能看到每个字符的编码是否正确。为了方便在页面中查找，建议输入一些容易查找的字符，例如使用“XSSTest<&’/”>“进行测试，输入“XSSTest<&’/”>“之后，在结果页面上，查询”XSSTest“，然后再看看每一个显示“XSSTest<&’/”>“的地方是不是编码正确。例如：在HTML标签中，如果</>编码不正确，可能导致HTML注入类型的XSS；如果双引号（”）编码不正确，可能导致HTML的属性被注入，也可能导致JavaSprint注入。（2）半自动检测手工测试虽然简单，即不停地尝试各种参数，看看哪一个参数可能会引入问题。但是效率却不是很高。因为一个网页可能有很多输入项和输出项，还有内容是存储在DB中的，素以测试量是很大的，而且页面上还做了限制输出框，也会导致一些测试用例无法使用。为了提高效率和测试覆盖度，必须借助一些工具。半自动检测主要借助一些检测工具，这些检测工具的基本原理是在本地启动一个默认端口是8080的代理服务器，把http://localhost:8080这个地址设置为浏览器的代理地址，然后通过配置工具的一些脚本，工具就可以完成自动测试，也可以通过捕捉请求和修改请求，来测试一些不可以直接测试的用例，特别是Post的一些请求，测试结果出来之后，还需要进一步分析，排除错误的用例。（3）全自动检测全自动检测，也是需要用户参与分析的。全自动检测根据是否需要运行程序，不运行程序的是静态检测，运行程序的是动态检测。1）静态检测:工具会根据事先制定的规则在不运行程序的情况下自动分析源代码，通过对比制定的规则来分析程序是否存在有威胁的源代码。2）动态检测：运行程序模拟发送出请求，分析返回的响应消息，查看有威胁的字符串有没有出现在响应消息中。2.2.5跨站脚本的预防措施（1）消除漏洞任何有关用户的输入信息都不要再输出页面上提供出来。（2）抵御漏洞1）所有的在页面上的输出都要编码。2）使用一个统一的规则和库做输出编码。3）只在输入的地方做验证是不够的，要在显示的地方做输出编码。4）如果一个内容要在多个地方输出，需要在每一个地方便吗，而且具体的编码要根据环境的不同而不同。5）根据输出的背景环境正确地做复合编码。6）对于富文本框，使用白名单控制输入而不是黑名单。2.3不正确的直接对象引用漏洞简介2.3.1不正确的直接对象引用漏洞定义DOR(DirectObjectReference,直接对象引用)是指开发者将文件、路径、数据库记录或者Key作为URL或表单的一部分，暴露给用户的一个引用。攻击者能够操作直接对象引用去访问一些他没有权限的其他对象，除非访问控制被恰如其分的检查。所谓的不安全的直接对象引用，就是说，在引用对象时，访问控制没有做好，以至于某些用户可以越过限制，访问他不应该访问的信息。2.3.2不正确的直接对象引用漏洞原因一些在内部实施的对象，比如文件、目录、数据库记录等，这些对象都是不正确的对象引用中的“对象”。如果这些对象之一发现应用程序URL（或表单参数）中一个引用被暴露出来,这时安全问题就会被触发。因为这些直接引用的对象可以被黑客用来修改达到攻击的目的，例如，在一个URL被提交之前，URL中的一个引用被黑客进行参数修改，黑客修改参数的企图是访问一个未获得授权的文件、目录、或数据库中的条目。在这种情况下如果网站的其他的授权检查不被加强，黑客的企图会成功。2.3.3不正确的直接对象引用漏洞经典案例及修改方法经典案例：举一个访问用户信息的例子，通过UserID可以得到用户的所有信息：http://www//userfo.do?ID=3。使用AccessReferenceMap，需要在处理的Action中添加代码处理直接引用到非直接引用的匹配的操作。代码如下：当获取用户列表时，需要使用AccessReferenceMap产生非直接引用并且将其保护到对象中，同事也要保存在AccessReferenceMap中。<Userfouser;Collectioncoll;//保存显示在UI中的非直接饮用//使用随机访问的引用mapAccessReferenceMapmap=newRandomAccessReferenceMap();//通过用户的ID获得非直接引用StringindirectReference=map.addDirectReference(user.getId());//将非直接引用保存到对象中，这需要对象的支持User.setIndirectReference(indirectReference);//增加对象到显示的集合中coll.add(user);//存储coll到对象request或者session中，然后发给UI当获取具体的用户信息时，需要根据非直接引用获得直接引用，然后去获取具体的用户信息：UserInfouser=null;StringindirectRef=request.GetIndirectRef();user=map.GetDirectReference(indirectRef);//这里需要处理抛出异常AccessControlException的情况//根据directRef也就是用户ID去DB获取具体的用户的信息。如果一个用户有很多文件，想一下添加一个结合的非直接引用到AccessReferenceMap中，可以使用AccessReferenceMap的update函数：setfileSet=newHashSet();fileSet.addAll(…);//添加引用（例如id、File）AccessReferenceMapmap=newAccessReferenceMap(fileSet);//将map存储在安全的地方——例如sessionStringindRef=map.getIndirectReference(file1);Stringhref=”/esapi?file=”+indRef)从例子可以看出使用AccessReferenceMap需要在session中保存匹配的AccessReferenceMap的一个实例，保存在session中的好处就是不会有线程安全问题，并且很容易就可以获得信息。如果map中保存的对象不多，可以确保session不会保存太多信息，如果map中的对象太多，会导致session比较臃肿、占用的内存比较多，这个时候采用线程安全的map，保存在一个全局变量中，map的Key值可以使session的id，这样做虽然解决了session臃肿的问题却可能也带来了性能上的问题。总之如果存储的对象不多的话，放在session中是一个很好的选择。2.3.4不正确的直接对象引用漏洞的检测方法以及检测工具不正确的对象引用对于网站来说不是什么异常行为，这个过程很难被检测到，除非查看或者检测日记。由于访问信息对于系统来说并不是有害的操作，有的产品甚至还没有对修改或删除操作的记录日志，这也就大大加大了检测难度。与此同时，漏洞扫描器对这不正确的直接对象引用漏洞也不是很高效。最佳的方法只能是以下两种：1）仔细检查代码中重要的参数，反复确认其是否存在易于遭到利用和操纵的可能性。2）专业的渗透测试需要定期实施，来排除漏洞的存在。2.3.5不正确的直接对象引用漏洞的预防措施对于不正确的直接对象引用漏洞的防御措施主要有以下几种：1）一些私密的对象引用做好防范措施，比如重要的关键字或者文件名，不要将其暴露给用户查看。2）在允许访问直接引用的对象之前做好授权验证。3）使用用户级别或者Session级别的间接对象引用（比如用户界面上下拉框中选项对应简单数字而不是对象的数据库键值，界面数字与对象键值之间的对应关系在用户级别或session级别维护。）2.4伪造跨站请求漏洞简介2.4.1伪造跨站请求漏洞定义伪造跨站请求通常缩写为CSRF(Cross-siteRequestForgery，伪造跨站请求)，也被称为“oneclickattack”或者sessionriding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSSS），但是它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户（受害者），而CSRF通过伪装来自受信任的用户的请求来利用受信任网站[7]。通过社会工程学的手段（如通过电子邮件发送一个链接）来蛊惑受害者进行一些敏感性的操作，如修改密码、修改E-mail、转账等，而受害者还不知道他已经上当。CSRF的破坏力依赖于受害者的权限。如果受害者只是个普通用户，则一个成功的CSRF攻击会危害用户的数据以及一些功能；如果受害者是具有管理员权限，则一个成功的CSRF攻击甚至会威胁到整个网站的安全。2.4.2伪造跨站请求漏洞产生的原因及过程举例解释攻击原理如图2-5所示。图2-5CSRF攻击过程1）A登录一个金融网站XXX准备进行网上支付。2）B知道这个金融网站XXX，并且意识到这个站点的转账功能有CSRF漏洞，B在发表一个blog，这个blog支持img自定义功能，B插入这么一行HTML代码：<imgsrc=”http://XXX/transferMoney.jsp?to=B&cash=5000”.。width=”1”height=”1”border=”0”>。3）A在自己的浏览器上打开了另一个标签页读到了这个blog。4）于是A的账户就向B的账户转账5000元，但是A却丝毫不知道。2.4.3伪造跨站请求漏洞经典案例及修改方法经典案例：案例中B先自己访问XXX中的转账功能，发送HTTP请求如下：POST/transferMoney.jspHttp/1.1Host:XXX:80User-Agent:Mozilla/5.0(WindowsNT5.1;rv:9.0.1)Gecko/20100101Firefox/9.0.1Accept:Text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:en-us,en;q=0.7,zh-cn;q=0.3Accept-Encoding:gzip,deflateAccept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection:keep-aliveReferer:http://localhost:80/transferMoney.jspCookie:JSESSIONID=17FA8B1D4C071101B6B11D7F8CD22566Content-Type:application/x-www-form-urlencodedContent-Length:16To=B&cash=5000这个请求的返回如下：Http/1.1200okContent-Type:Text/html;charset=ISO-8859-1Content-Length:238Date:sun,05Feb201212:01:37GMTServer:hahafakeserverTransfertoBcash:5000然而B发现如果向同一个网址发送GET请求也能成功，如下所示：GET/transferMoney.jsp?to=B&&cash=5000HTTP/1.1User-Agent:Mozilla/5.0(WindowsNT5.1;rv:9.0.1)Gecko/20100101Firefox/9.0.1Accept:Text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:en-us,en;q=0.7,zh-cn;q=0.3Accept-Encoding:gzip,deflateAccept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection:keep-aliveCookie:JSESSIONID=17FA8B1D4C071101B6B11D7F8CD22566这个GET请求的返回与POST请求的返回一样：Content-Type:Text/html;charset=ISO-8859-1Content-Length:238Date:sun,05Feb201212:01:37GMTServer:hahafakeserverTransfertoBcash:5000B决定利用网站的这个漏洞来攻击A。于是B构造了下面的这个URL，准备从A的账户中转走5000元到他的账户：http://XXX/transferMoney.jsp?to=B&cash=5000。为了使得上面的URL生效，B必须诱导A点击这个链接。最常见的方法就是给A发送一个邮件然后引诱A访问这个blog并且访问这个链接。采用这种方法就是转账成功，A也会发现，于是修改了原来的脚本：<imgsrc=”http://XXX/transferMoney.jsp?to=B&cash=5000”.。width=”1”height=”1”border=”0”>2.4.4伪造跨站请求的检测方法以及检测工具（1）手工检测1）用受害者身份登录，然后进行某个重要功能的操作，假设是增加一个新用户test1，它具有admin角色，URL是：http://localhost.adduser?username=test1&r-ole=administator。2）攻击者构造这个重要操作的URL，比如写成<imgsrc=http://localhost/addu-ser?username=test1&role=administatorwidth=”1”height=”1”border=”0”/>。如果该操作是POST请求，可以利用CSRFRedirector来模拟一个GET请求。3）在确保受害者登录的情况下，让受害者点击攻击攻击者构造的URL。4）检查结果：服务器是否执行了你的请求，如果执行了，则说明那个重要功能存在着CSRF漏洞。（2）半自动检测CSRFTester是一款CSRF检测工具，可以从/imag-es/0/08/CSRFTester-1.0zip进行下载。2.4.5伪造跨站请求的预防措施防止CSRF通常需要列入每个HTTP请求中的一个不可预知的令牌。这些令牌，至少，每个用户会话应该是唯一的。主要措施如下所示：1）最佳选择是独有的令牌包含在一个隐藏字段中，这将使得这些值放在要发送的HTTP报体的请求的值中，避免包含在URL中，因为这样就直接暴露了。2）独特的令牌也可以包含在URL中，或URL参数中，然而这种安排的URL有暴露给攻击者的风险，从而损害秘密令牌。3）OWASP的CSRF防护令牌可以自动包括在JavaEE、.NET或PHP应用程序中。OWASP的ESAPI包括CSRF的方法，开发人员可以使用它来防止这种漏洞。4）要求用户重新进行身份验证，证明他们是一个合法用户（例如，通过一个CAPTCHA），也可以防止CSRF。2.5未验证的重定向和转发漏洞简介2.5.1未验证的重定向和转发漏洞定义URL重定向和转发，是通过一些存在于服务器上面的特殊设置，访问当前域名的用户被引导，页面跳转到另一个提前制定好的网络地址，即将一个域名指向另一个已经存在的站点，或者讲一个页面引导到另一个页面。这种页面之间的转换方式有两种方式：隐藏路径和不隐藏路径.URL转发通常都采用隐藏路径的方式，URL重定向一般都采用不隐藏路径的方式。2.5.2未验证的重定向和转发产生的原因及过程URL转发这个过程就和三角借贷一样，浏览器没有钱，就写信找A.jsp借钱，但是A.jsp没有钱，于是A.jsp找B.jsp说自己钱不够，让B.jsp来处理这件事情，B.jsp将所有的钱凑够，然后再将这笔钱“邮寄”给浏览器。可以看出，浏览器发信向A.jsp借钱，结果从B.jsp拿到了这笔钱。而且对于浏览器来说，它也不知道是从哪里拿到的钱，但结果如浏览器想的那样，它借到钱了。浏览器感觉A.jsp是一个好人，借钱总是能借到。对于浏览器来说，写了一封信，就可以得到答复和借到钱。具体过程如图2-6所示：图2-6URL转发过程重定向是服务器对于浏览器的请求直接做出响应，响应的结果就是告诉浏览器去另外一个地址请求所需要的信息，然后，浏览器在访问另一个URL得到具体的信息。还以上面的借钱例子来说，这个过程就变成：浏览器写信向借钱，说自己没有钱，请找借钱，浏览器又写信向借钱，把钱汇给了浏览器，在本次借钱的过程中，虽然没从那借到钱，但是给它说了一个可以借到钱的地方。具体流程如图2-7所示。图2-7重定向流程图2.5.3未验证的重定向和转发漏洞经典案例及修改方法经典案例：用户想要访问的URL如下：/redirect.html?url=/external_page.html用户看到这个URL是访问的一个URL，是一个知名的站点，用户人为这个URL肯定是访问的。攻击者利用这一点，修改URL为：/redirect.html?url=/external_page.ht-ml用户看不到这个URL的域名是，他经常访问这个网站，所以相信这个URL应该没有恶意。其实他访问的是一个攻击者事先准备的恶意网站。这种URL是很简单的，可以通过查看整个URL是否跳转到其他的危险站点。攻击者想到一些方法使得跳转的URL比较模糊，可以通过十六进制编码将域名编码如下：%77%77%77%2e%65%76%69%6c%65%78%61%6d%70%6c%65%2e%63%6f%6d对于这个URL一般人很难看出它到底是一个怎样的URL。如果挑战到登录页面的URL被攻击者修改，然后发送给一个用户去访问，那么，攻击者就可以得到用户的用户名和密码。同样以前面的登录案例为例：/login.do?return_url=/userinfo.jsp?u=1一个恶意的攻击者可能将URL修改为：/login.do?return_url=/login.do。用户登录成功之后，仍然会显示一个登录页面，只不过这次是/的登录页面，而且页面的整体风格都一样，并且提示用户输入的用户名或者密码错误，用户以为登录失败就会重新输入一次，这次用户名和密码就会被提交到/而不是，攻击者控制着/这个网站，也就可以得到用户名和密码。如果攻击者修改的URL是下面的URL：/login.do?return_url=/manageruser.jsp，就有可能直接跳转到管理用户的界面。即使使用相对路径/lo-gin.do?return_url=/userinfo.jsp，也可以将其修改为：/login.do?return_url=admin.jsp绕过认证。2.5.4未验证的重定向和转发的检测方法以及检测工具可以通过spider工具访问站点，查看响应消息中是否有以300~307开头的响应消息，特别是301和302。如果存在，就说明有重定向存在，然后再检查是否有参数用作重定向的目标或者作为重定向目标的一部分。如果有，修改参数的目标URL，再观察这个请求是否被重定向到新的目标，如果重定向到这个修改之后的目标，说明服务器端没有对重定向之后的目标进行验证，可能存在问题。如果不能跳转到其他网站，尝试跳转网站内部其他的页面，特别是一些管理页面，防止通过修改URL参数绕过访问控制。2.5.5未验证的重定向和转发漏洞的预防措施在如下方式中可以做到安全使用重定向和转发：1）仅仅避免使用重定向和转发。2）如果使用，不涉及用户参数计算目标，这样通常是可以的。3）如果不能避免目标参数，确保所提供的价值是有效的、授权的用户。建议任何此类目标参数映射值，而不是实际的URL或者URL的一部分，并且该服务器端代码可以翻译这种映射到目标URL。应用程序可以使用ESAPI覆盖的sendRedirect（）方法，以确保所有重定向目的地是安全的。避免这种缺陷是极为重要的，因为它们是网络钓鱼者通过调到用户最喜爱的目标来试图获得用户的信任。2.6安全配置错误漏洞简介2.6.1安全配置错误漏洞定义攻击者访问默认的账户、没有用过的页、未打补丁的漏洞、不受保护的文件和目录等，来得到未经授权的访问权限或者系统的信息。这种漏洞可以发生在任何级别的应用程序堆栈。2.6.2安全配置错误漏洞的威胁和后果1）为攻击者提供一些系统数据或功能未经授予的访问权限。2）有时候会导致整个系统的损坏。2.6.3安全配置错误的检测方法以及检测工具（1）Tomcat/Apache1）Tomcat必须以专用的没有特权的用户账号和组运行。2）账号不能允许执行交互式Shell命令或者直接登录，但可以通过sudo切换。3）用户和组的名字包含有服务或者组件的名字，如tomcat/tomcat。4）Tomcat的目录树必须被Tomcat服务的账号拥有。5）应用程序的目录树必须配置限制的文件访问权限，如配置文件可以设置权限400只读、日志可以设置为300可写。6）Tomact运行的版本必须是打了所有安全补丁的版本。7）SHUTDOWN命令和端口必须被修改。8）Tomcat提供的默认的例子相关的路径和文件必须被删除。9）Tomcat管理员的默认密码必须被修改。10）响应消息的Server头和出错信息不能显示Tomcat的版本信息和系统信息。11）关闭Tomcat的路径列举功能。12）Tomcat的默认错误页面必须被替换。13）在Tomcat配置文件中禁用不安全的HTTP方法，如TRACE、OPTIONS。只启用安全的HTTP方法，如GET、POST。14）Apache的欢迎页面（/etc/httpd/conf.d/welcome.conf）必须被删除。15）etc/httpd/conf.d/ssl.conf必须被删除。16）应用程序和管理程序使用不同的端口。17）管理的控制台必须使用SSL协议。18）管理控制台服务必须被限定在管理的区域才能访问。（2）数据库1）默认的用户名和密码必须修改。2）访问数据库用户的密码必须符合一定复杂度。3）访问数据库的用户要赋予所需要的最少权限，如增加表、删除表、修改表等权限不是必要的权限，就不需要给访问数据库的用户。（3）应用程序1）启动应用程序的系统用户必须是专用的、没有系统级别特权的用户和组。2）没有用的文件必须从应用程序上删除，如备份文件、临时文件等。3）在部署之前，删除没有用的功能和测试代码。4）配置文件中没有默认的用户名和密码。5）配置文件中没有明文的密码和密钥。6）应用程序不能再产品环境上以Debug或者开发模式运行。7）应用程序必须使用JRE的JDK运行，而不是JavaSDK。8）不要在robot.txt中泄露目录结构。（4）操作系统1）系统所有用户的密码都必须符合一定的复杂度。2）当前在用的操作系统没有已知的漏洞。3）禁止启用不用的服务，例如，FTP、Telnet、SMTP等。4）要启用ASLR和DEP的选项。（5）编译器1）使用的编译器已经更新了所有的安全补丁。2）开启所有的编译告警。3）启用堆栈执行保护编译选项。4）启用堆栈溢出检测编译选项。5）启动动态地址载入编译选项。2.6.4安全配置错误漏洞的预防措施安全配置可能在各个级别(platform/webserver/applicationserver/database/framework/customcode)出错，开发人员需要同网络管理人员共同合作来确保合理配置，具体措施如下所示：1）系统的安全配置必须定期进行验证。2）对所有组件都必须保证安装了最新的补丁。3）对所有你做的安全配置进行记录。4）使用专业自动化扫描工具定期检查安全漏洞。2.7敏感数据暴露漏洞简介2.7.1敏感数据暴露漏洞定义许多Web应用没有正确地保护敏感数据，例如信用卡卡号、税号、身份认证证书等。攻击者可以通过偷窃、更改这种弱保护的数据，以进行信用卡诈骗、身份窃取、或者其他犯罪活动。2.7.2敏感数据暴露漏洞的成因及威胁后果考虑谁会获得你的敏感数据或者敏感数据备份的可能性,这些包括敏感数据源，传输中的数据甚至在你的顾客的浏览器中。包括外部和内部的威胁敏感数据。例如：银行卡卡号、用户地址、登录密码等，这些敏感的信息都应该进行保护，对于这些敏感数据，以下几点做不到就会引起数据的暴露：1）这些信息和这些信息的备份不管在什么地方长期存储都需要进行加密。2）这些数据在传输时要加密，理想状况下，内部传输和外部传输都需要加密。3）所有的加密都应该使用复杂的加密方式，防止信息的暴露。4）正确的浏览器指令和头部信息保护敏感信息或者是发送到浏览器。2.7.3敏感数据暴露攻击举例情形1：一个应用程序使用一个自动的数据库加密技术对信用卡号在数据库中进行加密。然而这意味着在取回的时候会自动的解密，允许一个SQL注入的缺陷在明文中去取回信用卡号。此类系统应该使用公共密钥加密的信用卡号码，并只允许后端应用程序对其进行解密用私钥。情形2：一个简单的站点不会对所有的已经验证过的页面使用SSL。攻击者仅仅监视网络中的传输（例如一个开放的无线网络），窃取用户的会话Cookie。攻击者然后，攻击者重放这个cookie劫持用户的会话，访问他们的私人数据。情形3：密码数据库采用未加料的哈希存储每个人的密码。一个文件的上传缺陷允许攻击者去取回密码文件。未加料的哈希可以暴露预先计算好的哈希的彩虹表。2.7.4敏感数据暴露漏洞的预防措施不安全的加密，SSL使用和数据保护的完整的危险远远超出了前10名。这就是说，所有敏感数据，至少要做到以下几点：1）考虑你要保护的数据的威胁来自哪里（是内部人员的攻击还是外部使用者），确保加密所有的敏感数据源和传输中的数据来抵抗这些威胁。2）不要存储不必要的敏感数据并且尽快丢弃，你没有的数据就不会被窃取。3）确保使用强大标准的加密算法和密钥，并且恰当到位的管理密钥。4）确保密码在存储时已经被专门设计的密码保护算法加密，例如bcrypt、PBKDF2、scrypt。5）禁用“自动完成”的形式，收集敏感数据，并禁用缓存页面显示敏感数据。/html/itweb/20130921/128881_128884_128882.htm2.8使用已知易受攻击的组件漏洞简介2.8.1使用已知易受攻击的组件漏洞定义许脆弱的组件是常见的，一些脆弱的组件(如。框架库)可以利用自动化工具被识别。攻击者可以识别出脆弱的组件借助扫描工具或者是手工分析。根据他们识别出的脆弱的组件从而定义了需要以及执行攻击的漏洞。2.8.2使用已知易受攻击的组件漏洞的成因及威胁后果一些脆弱部件（例如，框架库）可以利用自动化工具被识别，扩大的威胁超越代理池中有针对性的攻击，包括混乱的参与者。成因：1）没有经过授权的功能的的导航没能够在UI中显示出来。2）进行了错误的授权和对授权检查的忽略。3）服务器上是否存在被攻击者依赖信息没有被检查出来，给攻击者提供攻击的机会。2.8.3使用已知易受攻击的组件漏洞攻击举例组件几乎始终运行应用程序的全部特权，所以在任何组件中的缺陷可以是严重的，下面的两个易损组件在2011年被下载220万次。1）ApacheCXFAuthenticationBypass--未能通过提供身份令牌，攻击者可以调用任何Web服务的完整权限。2）SpringRemoteCodeExecution--在Spring表达式语言的滥用允许攻击者执行任意代码、有效地接管服务器。当这两个组件被应用程序的用户直接的访问时，每个应用程序使用这些脆弱的库是容易受到攻击。其它脆弱的库，在应用程序中更深，可能难以利用。2.8.4使用已知易受攻击的组件漏洞的预防措施其中一个选项是不使用你没有写的组件。但实际上，处理这种漏洞的最佳方式是让组件都更新到最新的状态。软件项目中应该有地方做如下事情：1）正在使用的组件、版本、依赖能够被正确地被识别出来。2）公共数据库中、项目的邮件列表、安全邮件列表的组件需要更新到最新的状态，并且监视它们的安全性是否出现差错。3）管理组件的使用需要制定一份安全的策略用来规范，如需要一定的软件开发实践，通过安全测试，和可接受的许可证。2.9缺少功能层面的访问控制漏洞简介2.9.1缺少功能层面的访问控制漏洞定义功能级别权限控制一般是卸载代码中或者通过程序的配置文件夹完成，但是开发者经常忘记添加一些功能权限控制代码，所以导致了缺少功能层面的访问控制。授权系统的用户的攻击者仅仅改变URL或者是一个特殊函数的参数就可以攻击。2.9.2缺少功能层面的访问控制漏洞攻击过程缺少功能层面的访问控制漏洞是攻击者强制浏览到目标URL上，一个未经授权的用户可以访问用户界面以及管理界面，这就是一种缺陷，这种缺陷可能指引攻击者去非法攻击更多的管理员页面来获取他们想要的利益。其攻击过程如图2-8所示。图2-8缺少功能层面访问控制攻击过程1）攻击者注意到URL表明他的角色/user/getAccounts2）他修改它到另一个目录(角色)/admin/getAccounts,或/manager/getAccounts3）攻击者可以看到不只是他们自己的帐户2.9.3缺少功能层面的访问控制攻击举例情形1：简单的攻击仅仅强制浏览到目标URLs。下列的URLs需要授权，管理员的权利也需要访问“admin_getappinfo”页面。/app/getappInfo/app/admin_getappInfo如果一个未授权的用户能够访问这两个的任意一个页面，这就是一个缺陷。如果一个授权的用户但是不是管理员也能够访问“admin_getappinfo”页面，这也是一个缺陷，这些缺陷可能指引攻击者去非法攻击更多的管理员页面。情形2：一个页面提供一个action的参数来指定被调用函数，不同的actions需要不同的角色，如果不执行这些角色，那就是一个缺陷。2.9.4缺少功能层面的访问控制漏洞的预防措施针对缺少功能层面的访问控制漏洞的预防主要有以下几点：1）不要hardcode权限控制，需要建立一种可以比较容易更新和监测权限控制的机制。2）默认拒绝所有访问，访问任何功能都需要被赋予特定的权限。3）如果某功能在一个workflow中，需要确认所有的前提条件都在正确的状态，然后允许访问该功能。/html/itweb/20130921/128881_128884_128882.htm(har-dcode意思是在代码中写死)/leonhughes/article/details/4712792你的应用程序应该有一致的、易于分析的、能被所有的业务功能调用的授权模块，通常情况下，这种保护是由外部应用程序代码的一个或多个组件提供：1）考虑配额管理的过程，并确保您可以轻松地更新和审核。不要硬编码。2）应当拒绝所有访问默认情况下的强制执行机制，需要明确授予特定角色访问每个函数。3）如果是参与工作流中的检查的功能，确保所有允许访问的条件都处于正常状态。2.10错误的会话认证和会话管理漏洞简介2.10.1错误的会话认证和会话管理漏洞定义错误的认证和会话管理，简单来说，就是我们访问HTTP时的用户名和密码被恶意攻击者窃听了，也可能是我们的会话，攻击者获取sessionID，然后攻击者冒充我们访问HTTP[8]。因为无状态这一特性是HTTP本身的属性，所以HTTP每次访问都是带有个人凭证来进行访问请求的，身份认证的结果往往是获得一个令牌，通常放在cookie中，之后对用户的识别根据这个授权的令牌进行识别，而不需要每次都要登录。SessionID的作用是用来跟踪状态，但是在网络上监听sessionID又是一件很容易的事情，结果就造成攻击者通过监听sessionID来达到他们想要进行的攻击[8]。2.10.2错误的会话认证和会话管理的成因及威胁后果错误的会话认证和会话管理漏洞的攻击过程如图2-9所示。图2-9会话攻击过程1）攻击者B用一个合法的用户身份登录。2）服务器与B建立了一个会话，sessionid为1234567。3）B构造了一个URL：/login.jsp?sessionid=1234567，发给了受害者A。4）A不小心打开链接登录。5）A输入了她的用户名和密码，此时，sessionid被B设置为1234567。6）B只需要输入/login.jsp?sessionid=1234567，就可以看到A的个人信息了，因为此时sessionid就代表了A。漏洞成因：在用户进入登录页面，但还未登陆时，就已经产生了一个session，用户输入信息，登录以后，session的ID不会改变，也就是说还是以前的那个session（事实上session也确实不会改变，因为没有建立新的session，原来的session也没有被销毁）。很多人只是让会话的Invalidate没有用（request.getSession().invalidate();），是因为invalidate方法不是真正的将session销毁，只是将session中的内容清空，所以当invalidate以后再新建session，新建的session其实不是新的，只是将之前的session重新启用了。于是session的ID不变就不奇怪了。只有Cookie失效掉，才能换成新的sessionid。2.10.3错误的会话认证和会话管理攻击举例假设URL重写被机票预订应用程序所支持，并且可以把会话ID写在URL中：/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?d-est=Hawaii一个在此站点验证通过的用户想让他的朋友知道这笔交易。他将上面的链接通过邮件发送给他的朋友，但是不知道他会泄露自己的会话ID。当他的朋友使用这个链接时，会使用他的会话和信用卡。应用的超时事件没有被适当的设置。用户使用一个公共电脑访问站点。在没有点击注销登录的情况下，仅仅管理了浏览器并且离开。攻击者在一个小时后使用同样的浏览器，这个浏览器认证通过。解决方法：在登录页面上加上一段代码：request.getSession().invalidate();//清空sessionif(request.getCookies()!=null){Cookiecookie=request.getCookies()[0];//获取cookiecookie.setMaxAge(0);//让cookie过期}2.10.4错误的会话认证和会话管理漏洞的预防措施（1）我们要整体审视我们的架构1）认证机制本身必须是简单、集中和标准化的；2）使用容器提供给我们的标准sessionid；3）确保在任何时候用SSL来保护我们的密码和sessionid。（2）验证认证的实现机制1）检查SSL的实现方法；2）验证所有与认证相关的函数；3）确保“注销登录”的动作能够关闭所有对话；4）使用OWASP和WebScrab来测试你的应用。3Web应用程序安全漏洞知识库设计与实现3.1需求分析3.1.1项目背景 由于互联网的飞速发展，人们的生活已经离不开互联网。当今Web许多安全方面频频遭受攻击，Web漏洞解决问题已经迫在眉睫。为了人们的上网安全，整理分析OWASPTOP10漏洞进行分析整理。分析这些经典的漏洞，旨在帮助程序员提升他们的编码安全意识，加强Web应用程序的安全性。3.1.2系统开发环境以及运行环境 开发环境：操作系