Day2 软件安全开发生命周期ppt课件.pptx

《Day2 软件安全开发生命周期ppt课件.pptx》由会员分享，可在线阅读，更多相关《Day2 软件安全开发生命周期ppt课件.pptx（73页珍藏版）》请在三一办公上搜索。

1、软件安全开发生命周期,杭州安恒信息技术有限公司,软件安全开发生命周期（SDL）基于WEB应用程序的SDL,目录,简介安全需求分析安全设计安全编程安全测试安全部署及安全响应,软件安全开发生命周期,简介 安全开发周期，即Security Development Lifecycle (SDL)，是微软提出的从安全角度指导软件开发过程的管理模式。SDL不是一个空想的理论模型。它是微软为了面对现实世界中安全挑战，在实践中的一步步发展起来的软件开发模式。 典型的软件开发流程中，如瀑布模型，中心围绕着产品功能，完全没有安全方面的考虑。这样的开发流程可以造就功能上相对完善的软件，但是无法满足在安全上的需要。由

2、于软件开发过程中未进行任何有效的安全控制措施，导致软件开发后由于其固有的安全隐患所引起的安全事件频频发生，给黑客及恶意人员可趁之机，由此导致的经济损失不可估量。,软件安全开发生命周期,虽然目前企业和组织已经逐步意识到软件安全的重要性，但是他们把目光更多的聚焦到了软件开发后的漏洞扫描或渗透测试，尽管这个过程能够发现和解决大多数的安全隐患，但是后期的安全评估和安全整改，将带来更大的成本投入和人力投入；甚至由于开发人员的流动导致许多安全漏洞无法得到解决。据美国国家标准局（NIST）早年发表的一份调查报告估计，更好的安全控制措施将为后期安全整改的总体成本节省三分之一以上的费用，且有效规避70%以上由于

3、软件安全隐患所引发的安全事件。,软件安全开发生命周期,软件安全开发生命周期,简介安全需求分析安全设计安全编程安全测试安全部署及安全响应,软件安全开发生命周期,安全需求分析设定安全目标 在需求分析阶段，加入以下的安全考虑 产品提供的安全功能产品如何安全的与用户（或其它软件模块）交互特别的，安全方面的考虑对产品开发计划的影响产品的风险评估和威胁模型（threat modeling）产品的缺省功能配置,软件安全开发生命周期,简介安全需求分析安全设计安全编程安全测试安全部署及安全响应,软件安全开发生命周期,安全设计 在安全设计阶段，特别加入以下两方面的考虑 减少攻击界面。例如，对一个网络软件的设计，它

4、需要监听那些网络端口，是否可以减少监听端口的数目？那些用户可以与这些端口建立连接，是否要加强身份验证？深层防御。底层模块的设计中，假设上层模块有可能出现安全漏洞。对传递的数据考虑进一步校验,软件安全开发生命周期,简介安全需求分析安全设计安全编程安全测试安全部署及安全响应,软件安全开发生命周期,安全编程 独立、完整且集中的输入验证 创建并使用了独立的用户输入验证模块以完成对所有用户的输入校验，以此可带来： 统一的输入检测策略统一的验证逻辑统一的错误验证处理降低升级和维护成本,软件安全开发生命周期,校验全部的程序输入 保证所有变量在使用之前都经过严格的校验，防止被污染的数据进入程序。校验全部的输入

5、长度 通过限制输入长度，可以有效的控制一些攻击使其不给系统带来过大的威胁：SQL InjectXSSFile Include,软件安全开发生命周期,校验全部的输入类型 不同的程序所接收到的参数类型应严格区分并校验，对于非法的类型应有相关异常进行处理以防止其进入程序。不使用任何方式验证失败的数据 当程序对某个数据校验失败时（如：校验数据类型），相关的异常处理程序应抛弃该数据并中断操作，而不应对数据进行任何的修复尝试。对HTTP所有内容进行校验 除需对传统的HTTP GET、POST等数据进行严格校验外，还应对HTTP内所有可能使用到的字段进行校验，防止字段中包含恶意字符而污染程序，如：Refer

6、erHostCookie,软件安全开发生命周期,校验向用户输出的数据 当程序通过查询后台数据库或其他方式从后台获取数据后，在将数据输出给用户前应对该数据进行校验，校验其中是否包含有非法字符、可执行客户端脚本等恶意信息。使用安全的SQL查询方式 在进行SQL查询时，必须使用安全的查询方式，如：Prepared Statement，以避免查询语句中由用户恶意插入SQL语句所带来的风险。禁止使用JavaScript进行任何校验 由于JavaScript为客户端脚本，因此任何试图使用JavaScript对用户数据进行校验的行为都可能被用户构造的本地脚本所绕过，因此，所有校验工作应由服务端程序完成而不是

7、客户端。,软件安全开发生命周期,使用安全、统一的编码或转义方式 创建并使用独立、统一的编码或转移方式，而且编码或转移中，至少应包含对以下类别数据的编码或转移：可能造成SQL注入的数据，如：分号、单引号等可能造成XSS的数据，如：script、javascript等设定有安全的权限边界 所有的程序都应清楚的了解到自己能做什么，而在其所能做的范围之外，均属于其权限边界之外，应严格禁止对其权限之外的任何操作。校验被调用的后台命令 若程序需要调用后台可执行程序，则在调用时，应通过使用完整路径或对程序进行HASH校验等方式保证程序的调用正确。,软件安全开发生命周期,校验被调用的文本或配置文件 若程序需要

8、调用后台文本或配置文件，则在调用前，应相对文件或配置文件的完整性和有效性进行检查，以确保读入的文本或配置文件是正确可用的。确保程序所记录的日志可控 若程序需要记录额外的操作日志等信息，应保证这些日志中的某些或全部内容不来自用户输入，否则用户可能通过外部恶意提交信息的方式填充日志。,软件安全开发生命周期,简介安全需求分析安全设计安全编程安全测试安全部署及安全响应,软件安全开发生命周期,安全测试 安全测试是什么？在产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。安全测试目标提升产品安全质量尽量在发布前兆到安全问题予以修补降低成本度量

9、安全当前安全测试方法有模式匹配方法,将程序看作字符串状态机模型,将程序看作状态机黑盒模型,将程序看作黑盒子白盒模型,将程序看作路径的组合,软件安全开发生命周期,安全测试 当前安全测试的问题覆盖性完备性可度量性当前安全测试困难测试理论很难适用于安全领域安全测试基础理论薄弱,当前测试方法缺少理论指导，也缺乏技术产品工具测试 VS 安全测试BUG VS 安全漏洞 （并非是BUG的一个子集）信息泄露，WMF，LNK，SYN FLOOD漏洞是BUG吗？,软件安全开发生命周期,安全测试 假设条件测试：导致问题的数据是用户不小心构成的(只考虑提供给用户的界面）安全测试：导致问题的数据是攻击者处心积虑构成的（

10、考虑所有攻击界面，包括可污染/渗透传递的界面）思考域测试：功能本身安全测试：功能，系统机制，外部环境，应用与数据自身安全风险与安全属性问题发现模式测试：违反功能定义的输出安全测试：违反权限，能力与约束黑盒：状态或行为异常灰盒：未完备的约束检测静态白盒：基于规范,软件安全开发生命周期,安全测试 安全测试与渗透测试出发点与目的成本测试对象覆盖/完备/度量解决方案过程参与,软件安全开发生命周期,软件安全开发生命周期,安全自身要素安全包括了三个层次安全功能（特性）安全策略（部署，配置，全局设计准则）安全实现安全测试是对以上几个层次的验证和度量外部防护系统是一种补充保护,安全测试 安全功能测试是否足够是

11、否实现实现正确性安全策略测试是否足够是否实现实现正确性代码自身安全数据边界检测是否正确足够体系设计是否正确足够权限限制与检测是否正确足够处理逻辑是否正确,软件安全开发生命周期,安全测试 黑盒思路：基于功能与边界值FUZZ智能FUZZ全局数据结构白盒思路：基于路径源码审计二进制静态分析二进制数据流动态追踪分析,软件安全开发生命周期,简介安全需求分析安全设计安全编程安全测试安全部署及安全响应,软件安全开发生命周期,安全部署及安全响应 安全部署软件需提供相应的文档和工具，指导用户如何安全的使用。安全响应当前任何一个软件开发模式（包括SDL在内），都无法确保发布的软件没有安全漏洞。因此，需要事先制订对

12、应的相应模式，包括：（内部或外部发现的）安全漏洞以何种途径汇报如何评估安全漏洞的严重级别开发安全补丁的流程测试安全补丁的流程发布安全补丁的流程如何在以后开发中避免类似的安全漏洞，等等,软件安全开发生命周期,软件安全开发生命周期（SDL）基于WEB应用程序的SDL,目录,概述 在公开提供的 SDL 文档中，找不到专门针对如何保护 Web 应用程序或在线服务的指南。诚然，大多数 SDL 非实现要求同样适用客户端/服务器和 Web 应用程序。就象威胁模型对 Web 窗体应用程序与 Windows 窗体应用程序同样重要。而对 SOAP 服务和对 Windows 服务执行最终安全审查也同样重要。但对于跨

13、站点脚本 (XSS) 和 SQL 注入等与 Web 相关的漏洞会是怎样的情况呢？如果 SDL 如此注重防御客户端/服务器应用程序的缓冲区溢出，它为什么会忽视针对在线服务发起的 XSS 攻击这一 Web 头号公敌的防御呢？下面以JAVA编程安全为例说明。,基于WEB应用程序的SDL,简介跨站脚本（XSS）注入漏洞（Injection Flaws）恶意文件执行不安全的直接对象引用跨站点请求伪造（CSRF）信息泄露和错误处理不当残缺的认证和会话管理不安全的加密储存不安全的通信限制URL访问失效,JAVA安全编程OWASP TOP 10 AND ESAPI,简介,OWASP TOP 10 OWASP(

14、开放Web应用安全项目- Open Web Application Security Project)是一个开放社群、非营利性组织，目前全球有82个分会近万名会员，其主要目标是研议协助解决Web软体安全之标准、工具与技术文件，长期 致力于协助政府或企业了解并改善网页应用程式与网页服务的安全性。 OWASP TOP 10是10个最关键的Web应用安全问题清单。 这份名单是每隔数年更新（最近2010年）。 名单上都是那些通常很简单的，危险的安全问题。 这里是一个以在OWASP十大项目的链接。http:/www.owasp.org/index.php/Category:OWASP_Top_Ten_P

15、roject,ESAPI（Enterprise Security API） 其实简单一点来说，ESAPI就是为编写出更加安全的代码设计出来的一些API，方便使用者 调用，从而方便的编写安全的代码。它本身是开源的，同时提供JAVA版本和.NET版本。 代码下载地址：http:/ 下图显示了提供的API与OWASP列出的10个安全问题的涵盖关系：,What is an Enterprise Security API?The ESAPI Family Community Breakdown,OWASP,What is an Enterprise Security API?Addressing The

16、 OWASP Top Ten,OWASP Top Ten,OWASP ESAPI,A1: Injection,A2: Cross Site Scripting (XSS),A3: Broken Authentication and Session Management,A4: Insecure Direct Object Reference,A5: Cross Site Request Forgery (CSRF),A6: Security Misconfiguration,A7: Insecure Cryptographic Storage,A8: Failure to Restrict U

17、RL Access,A9: Insufficient Transport Layer Protection,A10: Unvalidated Redirects and Forwards,Encoder,Encoder, Validator,Authenticator, User, HTTPUtilities,AccessReferenceMap, AccessController,User (CSRF Token),SecurityConfiguration,Encryptor,AccessController,HTTPUtilities,AccessController,OWASP,Wha

18、t is an Enterprise Security API?OWASP ESAPI Project Scorecard,2.0,2.0,下图显示结合ESAPI设计你的程序,下图简单呈现ESAPI如何运作,跨站脚本（XSS）,定义 跨站脚本是最普遍的web应用安全漏洞。当应用程序在发送给浏览器的页面中包含用户提供的数据，但没有经过适当验证或转译那些内容，这就导致跨站脚本漏洞。危害 攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。种类 已知有三种著名跨站漏洞：1）存储式；2）反射式；3）基于DOM。 反射式跨站脚本通过测试或代

19、码分析很容易找到。,解决之道验证输入 验证输入很简单 - 检查每个输入的有效性。 这可能意味着很多东西，但在典型的和简单的情况下，这意味着检查输入类型和数据的长度。 例如，如果你是从一个文本框接受一个标准的邮政编码，你会知道，唯一有效的类型是一个数字（0-9），而长度应该是6，不能多也不能少。 并非所有 的案件都如此简单，但很多是相似的。 下图显示验证输入的架构。 这里的关键是，一切都进行验证，所有的输入，这并不来自于应用程序（包括用户输入，请求头，Cookie，数据库数据.）。,实例 getValidInput(java.lang.String context, java.lang.Stri

20、ng input, java.lang.String type, int maxLength, boolean allowNull, ValidationErrorList errors) isValidInput(java.lang.String context, java.lang.String input, java.lang.String type, int maxLength, boolean allowNull) String validatedFirstName = ESAPI.validator().getValidInput(FirstName, myForm.getFirs

21、tName(), FirstNameRegex, 255, false, errorList); boolean isValidFirstName = ESAPI.validator().isValidInput(FirstName, myForm.getFirstName(), FirstNameRegex, 255, false);,编码输出 对验证输入的另一面就是编码输出。 编码输出，是用来确保字符 被视为数据，而不是作为HTML元字符被浏览器解析。 这些技术定义一些特殊的“转义”字符。 没有正确转义的数据它仍然会在浏览器中正确解析。 编码输出只是让浏览器知道数据是不是要被解析，达到攻击

22、无法实现的目的。 需要编码的部分： 1、HTML实体 2、HTML属性 3、Javascript 4、CSS 5、URL 下图像显示编码输出的架构。,实例1HTML实体编码/performing input validation String cleanComment = ESAPI.validator().getValidInput(comment, request.getParameter(comment), CommentRegex, 300, false, errorList); /check the errorList here . . /performing output enco

23、ding for the HTML context String safeOutput = ESAPI.encoder().encodeForHTML( cleanComment ); 实例2URL编码/performing input validation String cleanUserName = ESAPI.validator().getValidInput(userName, request.getParameter(userName), userNameRegex, 50, false, errorList); /check the errorList here . . /perf

24、orming output encoding for the url context String safeOutput = /admin/findUser.do?name= + ESAPI.encoder().encodeForURL(cleanUserName);,注入漏洞（Injection Flaws）,定义 简单来说，注入往往是应用程序缺少对输入进行安全性检查 所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行，注入漏洞十分普遍，通常能在SQL查询、LDAP查询、Xpath查询、OS命令、程序参数等中出现。危害 注入能导致数据丢失或数据破坏、缺乏可审

25、计性或是拒绝服务。注入漏洞有时甚至能导致完全接管主机。种类 SQL注入、XPATH注入、LDAP注入、OS命令注入等。,解决之道SQL注入实例String sqlString = SELECT * FROM users WHERE fullname = + form.getFullName() + AND password = + form.getPassword() + ; 正常：username=tony，password=123456SELECT * FROM users WHERE username = tony AND password = 123456 攻击： username=t

26、ony，password= OR 1 = 1SELECT * FROM users WHERE username = tony AND password = OR 1 = 1 参数化查询预处理,使用PreparedStatement()绑定变量 下面的代码示例使用一个PreparedStatement，Java的一个参数化查询的执行情况，执行相同的数据 库查询。 String custname = request.getParameter(customerName); / This should REALLY be validated too / perform input validatio

27、n to detect attacks String query = SELECT account_balance FROM user_data WHERE user_name =? ; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( );使用存储过程,String custname = request.getParameter(customerName); / This s

28、hould REALLY be validated try CallableStatement cs = connection.prepareCall(call sp_getAccountBalance(?); cs.setString(1, custname); ResultSet results = cs.executeQuery(); / result set handling catch (SQLException se) / logging and error handling ,使用ESAPI /ESAPI version of query Codec ORACLE_CODEC =

29、 new OracleCodec(); /were using oracle String query = SELECT name FROM users WHERE id = + ESAPI.encoder().encodeForSQL( ORACLE_CODEC, validatedUserId) + AND date_created = + ESAPI.encoder().encodeForSQL( ORACLE_CODEC, validatedStartDate) +; myStmt = conn.createStatement(query); . /execute statement

30、and get results,恶意文件执行,定义 恶意文件执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入（include）功能程式的参数中修改参数内容，WEB服务器便会引入恶意程序内容从而受到恶意文件执行漏洞攻击。危害 攻击者可利用恶意文件执行漏洞进行攻击取得WEB服务器控制权，进行不法利益或获取经济利益。解决之道实例1验证输入，使用ESAPI验证上传文件名,if (!ESAPI.validator().isValidFileName(upload, filename, allowedExtensions, false) throw new ValidationUploadExc

31、eption(Upload only simple filenames with the following extensions + allowedExtensions, Upload failed isValidFileName check); 实例2使用ESAPI检查上传文件大小 ServletFileUpload upload = new ServletFileUpload(factory); upload.setSizeMax(maxBytes);,不安全的直接对象引用,定义 所谓“不安全的对象直接引用”，即Insecure direct object references，意指一个

32、已经授权的用户，通过更改 访问时的一个参数，从而访问到了原本其并没有得到授权的对象。Web应 用往往在生成Web页面时会用它的真实名字，且并不会对所有的目标对象访问时来检查用户权限，所以这就造成了不安全的 对象直接引用的漏洞。 我们看如下的一个示例，也许这样就更容易理解什么是不安 全的对象直接引用。攻击者发现他自己的参数是6065， 即?acct=6065；他可以直接更改参数为6066， 即?acct=6066；这样他就可以直接看到6066用 户的账户信息了。,危害 这种漏洞能损害参数所引用的所有数据。除非名字空间很稀疏，否则攻击者很容易访问该类型的所有数据。解决之道案例1使用ESAPI的Ac

33、cessReferenceMap实现使用非直接的对象引用 MyObject obj; / generate your object Collection coll; / holds objects for display in UI /create ESAPI random access reference map AccessReferenceMap map = new RandomAccessReferenceMap(); /get indirect reference using direct reference as seed input String indirectReferenc

34、e = map.addDirectReference(obj.getId(); /set indirect reference for each object - requires your app object to have this method obj.setIndirectReference(indirectReference); /add object to display collection coll.add(obj); /store collection in request/session and forward to UI .,案例2 检查访问。 来自不受信源所使用的所有

35、直接对象引用都必须包含访问控制检测，这样才能确保用户对要求的对象有访问权限。,跨站点请求伪造（CSRF）,定义 跨站请求伪造，也被称成为“one click attack” 或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防 范，所以被认为比XSS更具危险性。危害 攻击者能让受害用户修改可以修改的任何数据，或

36、者是执行允许使用的任何功能 。,解决之道 第一步，新建CSRF令牌添加进用户每次登陆以及存储在http session里，这种令牌至少对每个用户会话来说应该是唯一的，或者是对每个请求是唯一的。 /this code is in the DefaultUser implementation of ESAPI /* This users CSRF token. */ private String csrfToken = resetCSRFToken(); . public String resetCSRFToken() csrfToken = ESAPI.randomizer().getRando

37、mString(8, DefaultEncoder.CHAR_ALPHANUMERICS); return csrfToken; ,第二步，令牌同样可以包含在URL中或作为一个URL参数标记/隐藏字段。 /from HTTPUtilitiles interface final static String CSRF_TOKEN_NAME = ctoken; /this code is from the DefaultHTTPUtilities implementation in ESAPI public String addCSRFToken(String href) User user = E

38、SAPI.authenticator().getCurrentUser(); if (user.isAnonymous() return href; / if there are already parameters append with ,第三步，在服务器端检查提交令牌与用户会话对象令牌是否匹配。 /this code is from the DefaultHTTPUtilities implementation in ESAPI public void verifyCSRFToken(HttpServletRequest request) throws IntrusionExceptio

39、n User user = ESAPI.authenticator().getCurrentUser(); / check if user authenticated with this request - no CSRF protection required if( request.getAttribute(user.getCSRFToken() != null ) return; String token = request.getParameter(CSRF_TOKEN_NAME); if ( !user.getCSRFToken().equals( token ) ) throw n

40、ew IntrusionException(Authentication failed, Possibly forged HTTP request without proper CSRF token detected); ,第四步，在注销和会话超时，删除用户对象会话和会话销毁。 /this code is in the DefaultUser implementation of ESAPI public void logout() ESAPI.httpUtilities().killCookie( ESAPI.currentRequest(), ESAPI.currentResponse(),

41、 HTTPUtilities.REMEMBER_TOKEN_COOKIE_NAME ); HttpSession session = ESAPI.currentRequest().getSession(false); if (session != null) removeSession(session); session.invalidate(); ESAPI.httpUtilities().killCookie(ESAPI.currentRequest(), ESAPI.currentResponse(), “JSESSIONID”); loggedIn = false; logger.in

42、fo(Logger.SECURITY_SUCCESS, “Logout successful” ); ESAPI.authenticator().setCurrentUser(User.ANONYMOUS); ,信息泄露和错误处理不当,定义 应用程序常常产生错误信息并显示给使用者。 很多时候，这些错误信息是非常有用的攻击，因为它们揭示实施细则或有用的开发信息利用的漏洞。危害泄露太多的细节（如错误堆栈跟踪信息、SQL语句等等）；登录失败后，通知用户是否用户ID或密码出错登录失败可能是由于ID或密码错 误造成的。这为一个对关键资产发动蛮力攻击的攻击者提供重要信息。解决之道案例1通过web.xml配

43、置文件实现 java.lang.Throwable /error.jsp ,案例2 针对登录尝试的攻击，可以使用相同的报错信息，比如都是提示“输入的用户名或者密码错误！”。,残缺的认证和会话管理,定义 与认证和会话管理相关的应用程序功能往往得不到正确实施，这就导致攻击者破坏密码、密匙、会话令牌或利用实施漏洞冒充其他用户身份。危害 这些漏洞可能导致部分甚至全部帐户遭受攻击。一旦攻击成功，攻击者能执行合法用户的任何操作。因此特权帐户会造成更大的破坏。解决之道使用内置的会话管理功能。通过认证的问候：使用单一的入口点。确保在一开始登录SSL保护的网页。,获取注销的权利；添加超时；确保你使用的是安全相关

44、的功能；使用强大的认证；不进行默认身份验证 /BAD - DONT USE public boolean login(String username, String password) boolean isAuthenticated = true; try /make calls to backend to actually perform login against datastore if (! authenticationSuccess) isAuthenticated = false; catch (Exception e) /handle exc return isAuthentic

45、ated; ,不安全的加密储存,定义 保护与加密敏感数据已经成为网络应用的最重要的组成部分。 简单不加密的敏感数据是非常普遍。 不加密的应用程序设计不当往往含有密码，或者使用不恰当的密码或密码作出强烈的严重错误使用。 这些缺陷可以导致违反披露敏感数据的遵守。危害攻击者能够取得或是篡改机密的或是私有的信息；攻击者通过这些秘密的窃取从而进行进一步的攻击；造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。解决之道验证你的结构识别所有的敏感数据；识别这些数据存放的所有位置；确保所应用的威胁模型能够应付这些攻击；使用加密手段来应对威胁,使用一定的机制来进行保护文件加密；数据库加密；数据元素加密。正确

46、的使用这些机制使用标准的强算法；合理的生成，分发和保护密钥；准备密钥的变更。验证实现方法确保使用了标准的强算法；确保所有的证书、密钥和密码都得到了安全的存放；有一个安全的密钥分发和应急处理的方案；,不安全的通信,定义 对于不加密的应用程序的网络信息传输，需要保护敏感的通信。 加密（通常SSL）的，必须用于所有身份验证的连接，特别是通过Internet访问的网页，以及后端的连接。 否则，应用程序将暴露身份验证或会话令牌。危害攻击者能够取得或是篡改机密的或是私有的信息；攻击者通过这些秘密的窃取从而进行进一步的攻击；造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。解决之道提供合理的保护机制对于

47、敏感数据的传输，对所有连接都要使用TLS；在传输前对单个数据都要进行加密；（如XML-Encryption）在传输前对信息进行签名；（如XML-Signature）,正确的使用这些机制使用标准的强算法；合理管理密钥和证书；在使用前验证SSL证书,限制URL访问失效,定义 这个漏洞事实上也是与认证相关的，与我们前面提到的Top4不安全的直接对象引用也是类似的，不同在于这个漏洞是说系统已经对URL的访问做了限制，但这种限制却实际并没有生效。常见的错误是，我们在用户认证后只显示给用户认证过的页面和菜单选项，而实际上这些仅仅是表示层的访问控制而不能真正生效，攻击者能够很容易的就伪造请求直接访问未被授权

48、的页面。 我们举个例子来说明这个过程：1、攻击者发现他自己的访问地址为/user/getAccounts；2、他修改他的目录为/admin/getAccounts或/manager/getAccounts；3、这样攻击者就能够查看到更多的账户信息了。,解决之道对每个URL，我们必须做三件事如果这个URL不是公开的，那么必须限制能够访问他的授权用户；加强基于用户或角色的访问控制；完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等）验证你的构架在每一个层次都使用简单肯定的模型；确保每一层都有一个访问机制验证你的实现不要使用自动化的分析工具；确保每个URL都被外部过滤器或其他机制保护；确

49、保服务器的配置不允许对非授权页面的访问,实例public boolean isAuthorized(Object key, Object runtimeParameter); public void assertAuthorized(Object key, Object runtimeParameter) throws AccessControlException; boolean isAuthorizedForURL(String url); boolean isAuthorizedForFunction(String functionName); boolean isAuthorizedF

50、orData(String action, Object data); boolean isAuthorizedForFile(String filepath); boolean isAuthorizedForService(String serviceName); void assertAuthorizedForURL(String url) throws AccessControlException; void assertAuthorizedForFunction(String functionName) throws AccessControlException; void asser