软件安全开发生命周期概述(PPT 73页)

*软件安全开发生命周期** 软件安全开发生命周期（SDL） 基于WEB应用程序的SDL 目录 工贸企业有限空间作业目录特种设备作业人员作业种类与目录特种设备作业人员目录1类医疗器械目录高值医用耗材参考目录 ** 简介 安全需求分析 安全设计 安全编程 安全测试 安全部署及安全响应软件安全开发生命周期** 简介安全开发周期，即SecurityDevelopmentLifecycle(SDL)，是微软提出的从安全角度指导软件开发过程的管理模式。SDL不是一个空想的理论模型。它是微软为了面对现实世界中安全挑战，在实践中的一步步发展起来的软件开发模式。典型的软件开发流程中，如瀑布模型，中心围绕着产品功能，完全没有安全方面的考虑。这样的开发流程可以造就功能上相对完善的软件，但是无法满足在安全上的需要。由于软件开发过程中未进行任何有效的安全控制措施，导致软件开发后由于其固有的安全隐患所引起的安全事件频频发生，给黑客及恶意人员可趁之机，由此导致的经济损失不可估量。软件安全开发生命周期**虽然目前企业和组织已经逐步意识到软件安全的重要性，但是他们把目光更多的聚焦到了软件开发后的漏洞扫描或渗透测试，尽管这个过程能够发现和解决大多数的安全隐患，但是后期的安全评估和安全整改，将带来更大的成本投入和人力投入；甚至由于开发人员的流动导致许多安全漏洞无法得到解决。据美国国家标准局（NIST）早年发 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 的一份调查 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 估计，更好的安全控制措施将为后期安全整改的总体成本节省三分之一以上的费用，且有效规避70%以上由于软件安全隐患所引发的安全事件。软件安全开发生命周期**软件安全开发生命周期** 简介 安全需求分析 安全设计 安全编程 安全测试 安全部署及安全响应软件安全开发生命周期** 安全需求分析——设定安全目标 在需求分析阶段，加入以下的安全考虑产品提供的安全功能产品如何安全的与用户（或其它软件模块）交互特别的，安全方面的考虑对产品开发计划的影响产品的风险评估和威胁模型（threatmodeling）产品的缺省功能配置软件安全开发生命周期** 简介 安全需求分析 安全设计 安全编程 安全测试 安全部署及安全响应软件安全开发生命周期** 安全设计 在安全设计阶段，特别加入以下两方面的考虑减少攻击界面。例如，对一个网络软件的设计，它需要监听那些网络端口，是否可以减少监听端口的数目？那些用户可以与这些端口建立连接，是否要加强身份验证？深层防御。底层模块的设计中，假设上层模块有可能出现安全漏洞。对传递的数据考虑进一步校验软件安全开发生命周期** 简介 安全需求分析 安全设计 安全编程 安全测试 安全部署及安全响应软件安全开发生命周期** 安全编程 独立、完整且集中的输入验证创建并使用了独立的用户输入验证模块以完成对所有用户的输入校验，以此可带来：统一的输入检测策略统一的验证逻辑统一的错误验证处理降低升级和维护成本软件安全开发生命周期** 校验全部的程序输入保证所有变量在使用之前都经过严格的校验，防止被污染的数据进入程序。 校验全部的输入长度通过限制输入长度，可以有效的控制一些攻击使其不给系统带来过大的威胁：SQLInjectXSSFileInclude………软件安全开发生命周期** 校验全部的输入类型不同的程序所接收到的参数类型应严格区分并校验，对于非法的类型应有相关异常进行处理以防止其进入程序。 不使用任何方式验证失败的数据当程序对某个数据校验失败时（如：校验数据类型），相关的异常处理程序应抛弃该数据并中断操作，而不应对数据进行任何的修复尝试。 对HTTP所有内容进行校验除需对传统的HTTPGET、POST等数据进行严格校验外，还应对HTTP内所有可能使用到的字段进行校验，防止字段中包含恶意字符而污染程序，如：RefererHostCookie……软件安全开发生命周期** 校验向用户输出的数据当程序通过查询后台数据库或其他方式从后台获取数据后，在将数据输出给用户前应对该数据进行校验，校验其中是否包含有非法字符、可执行客户端脚本等恶意信息。 使用安全的SQL查询方式在进行SQL查询时，必须使用安全的查询方式，如：PreparedStatement，以避免查询语句中由用户恶意插入SQL语句所带来的风险。 禁止使用JavaScript进行任何校验由于JavaScript为客户端脚本，因此任何试图使用JavaScript对用户数据进行校验的行为都可能被用户构造的本地脚本所绕过，因此，所有校验工作应由服务端程序完成而不是客户端。软件安全开发生命周期** 使用安全、统一的编码或转义方式创建并使用独立、统一的编码或转移方式，而且编码或转移中，至少应包含对以下类别数据的编码或转移：可能造成SQL注入的数据，如：分号、单引号等可能造成XSS的数据，如：script、javascript等 设定有安全的权限边界所有的程序都应清楚的了解到自己能做什么，而在其所能做的范围之外，均属于其权限边界之外，应严格禁止对其权限之外的任何操作。 校验被调用的后台命令若程序需要调用后台可执行程序，则在调用时，应通过使用完整路径或对程序进行HASH校验等方式保证程序的调用正确。软件安全开发生命周期** 校验被调用的文本或配置文件若程序需要调用后台文本或配置文件，则在调用前，应相对文件或配置文件的完整性和有效性进行检查，以确保读入的文本或配置文件是正确可用的。 确保程序所记录的日志可控若程序需要记录额外的操作日志等信息，应保证这些日志中的某些或全部内容不来自用户输入，否则用户可能通过外部恶意提交信息的方式填充日志。软件安全开发生命周期** 简介 安全需求分析 安全设计 安全编程 安全测试 安全部署及安全响应软件安全开发生命周期** 安全测试 安全测试是什么？在产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。 安全测试目标 提升产品安全质量 尽量在发布前兆到安全问题予以修补降低成本 度量安全 当前安全测试方法有 模式匹配方法,将程序看作字符串 状态机模型,将程序看作状态机 黑盒模型,将程序看作黑盒子 白盒模型,将程序看作路径的组合软件安全开发生命周期** 安全测试 当前安全测试的问题 覆盖性 完备性 可度量性 当前安全测试困难 测试理论很难适用于安全领域 安全测试基础理论薄弱,当前测试方法缺少理论指导，也缺乏技术产品工具 测试VS安全测试 BUGVS安全漏洞（并非是BUG的一个子集） 信息泄露，WMF，LNK，SYNFLOOD漏洞是BUG吗？软件安全开发生命周期** 安全测试 假设条件 测试：导致问题的数据是用户不小心构成的(只考虑提供给用户的界面） 安全测试：导致问题的数据是攻击者处心积虑构成的（考虑所有攻击界面，包括可污染/渗透传递的界面） 思考域 测试：功能本身 安全测试：功能，系统机制，外部环境，应用与数据自身安全风险与安全属性 问题发现模式 测试：违反功能定义的输出 安全测试：违反权限，能力与约束 黑盒：状态或行为异常 灰盒：未完备的约束检测 静态白盒：基于规范软件安全开发生命周期** 安全测试 安全测试与渗透测试 出发点与目的 成本 测试对象 覆盖/完备/度量 解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 过程参与软件安全开发生命周期**软件安全开发生命周期 安全自身要素 安全包括了三个层次 安全功能（特性） 安全策略（部署，配置，全局设计准则） 安全实现 安全测试是对以上几个层次的验证和度量 外部防护系统是一种补充保护** 安全测试 安全功能测试 是否足够 是否实现 实现正确性 安全策略测试 是否足够 是否实现 实现正确性 代码自身安全 数据边界检测是否正确足够 体系设计是否正确足够 权限限制与检测是否正确足够 处理逻辑是否正确软件安全开发生命周期** 安全测试 黑盒思路：基于功能与边界值 FUZZ 智能FUZZ 全局数据结构 白盒思路：基于路径 源码审计 二进制静态分析 二进制数据流动态追踪分析软件安全开发生命周期** 简介 安全需求分析 安全设计 安全编程 安全测试 安全部署及安全响应软件安全开发生命周期** 安全部署及安全响应 安全部署软件需提供相应的文档和工具，指导用户如何安全的使用。 安全响应当前任何一个软件开发模式（包括SDL在内），都无法确保发布的软件没有安全漏洞。因此，需要事先制订对应的相应模式，包括： （内部或外部发现的）安全漏洞以何种途径汇报 如何评估安全漏洞的严重级别 开发安全补丁的流程 测试安全补丁的流程 发布安全补丁的流程 如何在以后开发中避免类似的安全漏洞，等等软件安全开发生命周期** 软件安全开发生命周期（SDL） 基于WEB应用程序的SDL目录** 概述在公开提供的SDL文档中，找不到专门针对如何保护Web应用程序或在线服务的指南。诚然，大多数SDL非实现要求同样适用客户端/服务器和Web应用程序。就象威胁模型对Web窗体应用程序与Windows®窗体应用程序同样重要。而对SOAP服务和对Windows服务执行最终安全审查也同样重要。但对于跨站点脚本(XSS)和SQL注入等与Web相关的漏洞会是怎样的情况呢？如果SDL如此注重防御客户端/服务器应用程序的缓冲区溢出，它为什么会忽视针对在线服务发起的XSS攻击这一Web头号公敌的防御呢？下面以JAVA编程安全为例说明。基于WEB应用程序的SDL** 简介 跨站脚本（XSS） 注入漏洞（InjectionFlaws） 恶意文件执行 不安全的直接对象引用 跨站点请求伪造（CSRF） 信息泄露和错误处理不当 残缺的认证和会话管理 不安全的加密储存 不安全的通信 限制URL访问失效JAVA安全编程——OWASPTOP10ANDESAPI**简介 OWASPTOP10OWASP(开放Web应用安全项目-OpenWebApplicationSecurityProject)是一个开放社群、非营利性组织，目前全球有82个分会近万名会员，其主要目标是研议协助解决Web软体安全之标准、工具与技术文件，长期致力于协助政府或企业了解并改善网页应用程式与网页服务的安全性。OWASPTOP10是10个最关键的Web应用安全问题 清单 安全隐患排查清单下载最新工程量清单计量规则下载程序清单下载家私清单下载送货清单下载 。这份名单是每隔数年更新（最近2010年）。名单上都是那些通常很简单的，危险的安全问题。这里是一个以在OWASP十大项目的链接。http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project** ESAPI（EnterpriseSecurityAPI）其实简单一点来说，ESAPI就是为编写出更加安全的代码设计出来的一些API，方便使用者调用，从而方便的编写安全的代码。它本身是开源的，同时提供JAVA版本和.NET版本。代码下载地址：http://code.google.com/p/owasp-esapi-java/下图显示了提供的API与OWASP列出的10个安全问题的涵盖关系：**WhatisanEnterpriseSecurityAPI?TheESAPIFamilyCommunityBreakdown**OWASPWhatisanEnterpriseSecurityAPI?AddressingTheOWASPTopTenOWASPTopTenOWASPESAPIA1:InjectionA2:CrossSiteScripting(XSS)A3:BrokenAuthenticationandSessionManagementA4:InsecureDirectObjectReferenceA5:CrossSiteRequestForgery(CSRF)A6:SecurityMisconfigurationA7:InsecureCryptographicStorageA8:FailuretoRestrictURLAccessA9:InsufficientTransportLayerProtectionA10:UnvalidatedRedirectsandForwardsEncoderEncoder,ValidatorAuthenticator,User,HTTPUtilitiesAccessReferenceMap,AccessControllerUser(CSRFToken)SecurityConfigurationEncryptorAccessControllerHTTPUtilitiesAccessController**OWASPWhatisanEnterpriseSecurityAPI?OWASPESAPIProjectScorecard2.02.0** 下图显示结合ESAPI设计你的程序** 下图简单呈现ESAPI如何运作**跨站脚本（XSS） 定义跨站脚本是最普遍的web应用安全漏洞。当应用程序在发送给浏览器的页面中包含用户提供的数据，但没有经过适当验证或转译那些内容，这就导致跨站脚本漏洞。 危害攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。 种类已知有三种著名跨站漏洞：1）存储式；2）反射式；3）基于DOM。反射式跨站脚本通过测试或代码分析很容易找到。** 解决之道验证输入验证输入很简单-检查每个输入的有效性。这可能意味着很多东西，但在典型的和简单的情况下，这意味着检查输入类型和数据的长度。例如，如果你是从一个文本框接受一个标准的邮政编码，你会知道，唯一有效的类型是一个数字（0-9），而长度应该是6，不能多也不能少。并非所有的案件都如此简单，但很多是相似的。下图显示验证输入的架构。这里的关键是，一切都进行验证，所有的输入，这并不来自于应用程序（包括用户输入，请求头，Cookie，数据库数据...）。****实例getValidInput(java.lang.Stringcontext,java.lang.Stringinput,java.lang.Stringtype,intmaxLength,booleanallowNull,ValidationErrorListerrors)isValidInput(java.lang.Stringcontext,java.lang.Stringinput,java.lang.Stringtype,intmaxLength,booleanallowNull)StringvalidatedFirstName=ESAPI.validator().getValidInput("FirstName",myForm.getFirstName(),"FirstNameRegex",255,false,errorList);booleanisValidFirstName=ESAPI.validator().isValidInput("FirstName",myForm.getFirstName(),"FirstNameRegex",255,false);**编码输出对验证输入的另一面就是编码输出。编码输出，是用来确保字符被视为数据，而不是作为HTML元字符被浏览器解析。这些技术定义一些特殊的“转义”字符。没有正确转义的数据它仍然会在浏览器中正确解析。编码输出只是让浏览器知道数据是不是要被解析，达到攻击无法实现的目的。需要编码的部分：1、HTML实体2、HTML属性3、Javascript4、CSS5、URL下图像显示编码输出的架构。****实例1——HTML实体编码//performinginputvalidationStringcleanComment=ESAPI.validator().getValidInput("comment",request.getParameter("comment"),"CommentRegex",300,false,errorList);//checktheerrorListhere......//performingoutputencodingfortheHTMLcontextStringsafeOutput=ESAPI.encoder().encodeForHTML(cleanComment);实例2——URL编码//performinginputvalidationStringcleanUserName=ESAPI.validator().getValidInput("userName",request.getParameter("userName"),"userNameRegex",50,false,errorList);//checktheerrorListhere......//performingoutputencodingfortheurlcontextStringsafeOutput="/admin/findUser.do?name="+ESAPI.encoder().encodeForURL(cleanUserName);**注入漏洞（InjectionFlaws） 定义简单来说，注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行，注入漏洞十分普遍，通常能在SQL查询、LDAP查询、Xpath查询、OS命令、程序参数等中出现。 危害注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。注入漏洞有时甚至能导致完全接管主机。 种类SQL注入、XPATH注入、LDAP注入、OS命令注入等。** 解决之道SQL注入实例StringsqlString="SELECT*FROMusersWHEREfullname='"+form.getFullName()+"'ANDpassword='"+form.getPassword()+"'";正常：username=tony，password=123456SELECT*FROMusersWHEREusername=tony'ANDpassword='123456'攻击：username=tony，password='OR'1'='1SELECT*FROMusersWHEREusername=tony'ANDpassword=''OR'1'='1'参数化查询预处理**使用PreparedStatement()绑定变量下面的代码示例使用一个PreparedStatement，Java的一个参数化查询的执行情况，执行相同的数据库查询。Stringcustname=request.getParameter("customerName");//ThisshouldREALLYbevalidatedtoo//performinputvalidationtodetectattacksStringquery="SELECTaccount_balanceFROMuser_dataWHEREuser_name= ?";PreparedStatementpstmt=connection.prepareStatement(query);pstmt.setString(1,custname);ResultSetresults=pstmt.executeQuery();使用存储过程**Stringcustname=request.getParameter("customerName");//ThisshouldREALLYbevalidatedtry{CallableStatementcs=connection.prepareCall("{callsp_getAccountBalance(?)}");cs.setString(1,custname);ResultSetresults=cs.executeQuery();//…resultsethandling}catch(SQLExceptionse){//…logginganderrorhandling}**使用ESAPI//ESAPIversionofqueryCodecORACLE_CODEC=newOracleCodec();//we'reusingoracleStringquery="SELECTnameFROMusersWHEREid="+ESAPI.encoder().encodeForSQL(ORACLE_CODEC,validatedUserId)+"ANDdate_created>='"+ESAPI.encoder().encodeForSQL(ORACLE_CODEC,validatedStartDate)+"'";myStmt=conn.createStatement(query);...//executestatementandgetresults**恶意文件执行 定义恶意文件执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入（include）功能程式的参数中修改参数内容，WEB服务器便会引入恶意程序内容从而受到恶意文件执行漏洞攻击。 危害攻击者可利用恶意文件执行漏洞进行攻击取得WEB服务器控制权，进行不法利益或获取经济利益。 解决之道实例1验证输入，使用ESAPI验证上传文件名**if(!ESAPI.validator().isValidFileName("upload",filename,allowedExtensions,false)){thrownewValidationUploadException("Uploadonlysimplefilenameswiththefollowingextensions"+allowedExtensions,"UploadfailedisValidFileNamecheck");}实例2使用ESAPI检查上传文件大小ServletFileUploadupload=newServletFileUpload(factory);upload.setSizeMax(maxBytes);**不安全的直接对象引用 定义所谓“不安全的对象直接引用”，即Insecuredirectobjectreferences，意指一个已经授权的用户，通过更改访问时的一个参数，从而访问到了原本其并没有得到授权的对象。Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的目标对象访问时来检查用户权限，所以这就造成了不安全的对象直接引用的漏洞。我们看如下的一个示例，也许这样就更容易理解什么是不安全的对象直接引用。 攻击者发现他自己的参数是6065，即?acct=6065；他可以直接更改参数为6066，即?acct=6066；这样他就可以直接看到6066用户的账户信息了。**** 危害这种漏洞能损害参数所引用的所有数据。除非名字空间很稀疏，否则攻击者很容易访问该类型的所有数据。 解决之道案例1使用ESAPI的AccessReferenceMap实现使用非直接的对象引用MyObjectobj;//generateyourobjectCollectioncoll;//holdsobjectsfordisplayinUI//createESAPIrandomaccessreferencemapAccessReferenceMapmap=newRandomAccessReferenceMap();//getindirectreferenceusingdirectreferenceasseedinputStringindirectReference=map.addDirectReference(obj.getId());//setindirectreferenceforeachobject-requiresyourappobjecttohavethismethodobj.setIndirectReference(indirectReference);//addobjecttodisplaycollectioncoll.add(obj);//storecollectioninrequest/sessionandforwardtoUI...**案例2检查访问。来自不受信源所使用的所有直接对象引用都必须包含访问控制检测，这样才能确保用户对要求的对象有访问权限。**跨站点请求伪造（CSRF） 定义跨站请求伪造，也被称成为“oneclickattack”或者sessionriding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。 危害攻击者能让受害用户修改可以修改的任何数据，或者是执行允许使用的任何功能。** 解决之道第一步，新建CSRF令牌添加进用户每次登陆以及存储在httpsession里，这种令牌至少对每个用户会话来说应该是唯一的，或者是对每个请求是唯一的。//thiscodeisintheDefaultUserimplementationofESAPI/**Thisuser'sCSRFtoken.*/privateStringcsrfToken=resetCSRFToken();...publicStringresetCSRFToken(){csrfToken=ESAPI.randomizer().getRandomString(8,DefaultEncoder.CHAR_ALPHANUMERICS);returncsrfToken;}**第二步，令牌同样可以包含在URL中或作为一个URL参数标记/隐藏字段。//fromHTTPUtilitilesinterfacefinalstaticStringCSRF_TOKEN_NAME="ctoken";//thiscodeisfromtheDefaultHTTPUtilitiesimplementationinESAPIpublicStringaddCSRFToken(Stringhref){Useruser=ESAPI.authenticator().getCurrentUser();if(user.isAnonymous()){returnhref;}//iftherearealreadyparametersappendwith&,otherwiseappendwith?Stringtoken=CSRF_TOKEN_NAME+"="+user.getCSRFToken();returnhref.indexOf('?')!=-1?href+"&"+token:href+"?"+token;}...publicStringgetCSRFToken(){Useruser=ESAPI.authenticator().getCurrentUser();if(user==null)returnnull;returnuser.getCSRFToken();}**第三步，在服务器端检查提交令牌与用户会话对象令牌是否匹配。//thiscodeisfromtheDefaultHTTPUtilitiesimplementationinESAPIpublicvoidverifyCSRFToken(HttpServletRequestrequest)throwsIntrusionException{Useruser=ESAPI.authenticator().getCurrentUser();//checkifuserauthenticatedwiththisrequest-noCSRFprotectionrequiredif(request.getAttribute(user.getCSRFToken())!=null){return;}Stringtoken=request.getParameter(CSRF_TOKEN_NAME);if(!user.getCSRFToken().equals(token)){thrownewIntrusionException("Authenticationfailed","PossiblyforgedHTTPrequestwithoutproperCSRFtokendetected");}}**第四步，在注销和会话超时，删除用户对象会话和会话销毁。//thiscodeisintheDefaultUserimplementationofESAPIpublicvoidlogout(){ESAPI.httpUtilities().killCookie(ESAPI.currentRequest(),ESAPI.currentResponse(),HTTPUtilities.REMEMBER_TOKEN_COOKIE_NAME);HttpSessionsession=ESAPI.currentRequest().getSession(false);if(session!=null){removeSession(session);session.invalidate();}ESAPI.httpUtilities().killCookie(ESAPI.currentRequest(),ESAPI.currentResponse(),“JSESSIONID”);loggedIn=false;logger.info(Logger.SECURITY_SUCCESS,“Logoutsuccessful”);ESAPI.authenticator().setCurrentUser(User.ANONYMOUS);}**信息泄露和错误处理不当 定义应用程序常常产生错误信息并显示给使用者。很多时候，这些错误信息是非常有用的攻击，因为它们揭示实施细则或有用的开发信息利用的漏洞。 危害泄露太多的细节（如错误堆栈跟踪信息、SQL语句等等）；登录失败后，通知用户是否用户ID或密码出错——登录失败可能是由于ID或密码错误造成的。这为一个对关键资产发动蛮力攻击的攻击者提供重要信息。 解决之道案例1通过web.xml配置文件实现<error-page><exception-type>java.lang.Throwable</exception-type><location>/error.jsp</location></error-page>**案例2针对登录尝试的攻击，可以使用相同的报错信息，比如都是提示“输入的用户名或者密码错误！”。**残缺的认证和会话管理 定义与认证和会话管理相关的应用程序功能往往得不到正确实施，这就导致攻击者破坏密码、密匙、会话令牌或利用实施漏洞冒充其他用户身份。 危害这些漏洞可能导致部分甚至全部帐户遭受攻击。一旦攻击成功，攻击者能执行合法用户的任何操作。因此特权帐户会造成更大的破坏。 解决之道使用内置的会话管理功能。通过认证的问候：使用单一的入口点。确保在一开始登录SSL保护的网页。**获取注销的权利；添加超时；确保你使用的是安全相关的功能；使用强大的认证；不进行默认身份验证//BAD-DON'TUSEpublicbooleanlogin(Stringusername,Stringpassword){booleanisAuthenticated=true;try{//makecallstobackendtoactuallyperformloginagainstdatastoreif(!authenticationSuccess){isAuthenticated=false;}}catch(Exceptione){//handleexc}returnisAuthenticated;}**不安全的加密储存 定义保护与加密敏感数据已经成为网络应用的最重要的组成部分。简单不加密的敏感数据是非常普遍。不加密的应用程序设计不当往往含有密码，或者使用不恰当的密码或密码作出强烈的严重错误使用。这些缺陷可以导致违反披露敏感数据的遵守。 危害攻击者能够取得或是篡改机密的或是私有的信息；攻击者通过这些秘密的窃取从而进行进一步的攻击；造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。 解决之道验证你的结构识别所有的敏感数据；识别这些数据存放的所有位置；确保所应用的威胁模型能够应付这些攻击；使用加密手段来应对威胁**使用一定的机制来进行保护文件加密；数据库加密；数据元素加密。正确的使用这些机制使用标准的强算法；合理的生成，分发和保护密钥；准备密钥的变更。验证实现方法确保使用了标准的强算法；确保所有的证书、密钥和密码都得到了安全的存放；有一个安全的密钥分发和应急处理的方案；**不安全的通信 定义对于不加密的应用程序的网络信息传输，需要保护敏感的通信。加密（通常SSL）的，必须用于所有身份验证的连接，特别是通过Internet访问的网页，以及后端的连接。否则，应用程序将暴露身份验证或会话令牌。 危害攻击者能够取得或是篡改机密的或是私有的信息；攻击者通过这些秘密的窃取从而进行进一步的攻击；造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。 解决之道提供合理的保护机制对于敏感数据的传输，对所有连接都要使用TLS；在传输前对单个数据都要进行加密；（如XML-Encryption）在传输前对信息进行签名；（如XML-Signature）**正确的使用这些机制使用标准的强算法；合理管理密钥和证书；在使用前验证SSL证书**限制URL访问失效 定义这个漏洞事实上也是与认证相关的，与我们前面提到的Top4不安全的直接对象引用也是类似的，不同在于这个漏洞是说系统已经对URL的访问做了限制，但这种限制却实际并没有生效。常见的错误是，我们在用户认证后只显示给用户认证过的页面和菜单选项，而实际上这些仅仅是表示层的访问控制而不能真正生效，攻击者能够很容易的就伪造请求直接访问未被授权的页面。我们举个例子来说明这个过程：1、攻击者发现他自己的访问地址为/user/getAccounts；2、他修改他的目录为/admin/getAccounts或/manager/getAccounts；3、 这样攻击者就能够查看到更多的账户信息了。**** 解决之道对每个URL，我们必须做三件事如果这个URL不是公开的，那么必须限制能够访问他的授权用户；加强基于用户或角色的访问控制；完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等）验证你的构架在每一个层次都使用简单肯定的模型；确保每一层都有一个访问机制验证你的实现不要使用自动化的分析工具；确保每个URL都被外部过滤器或其他机制保护；确保服务器的配置不允许对非授权页面的访问** 实例publicbooleanisAuthorized(Objectkey,ObjectruntimeParameter);publicvoidassertAuthorized(Objectkey,ObjectruntimeParameter)throwsAccessControlException;booleanisAuthorizedForURL(Stringurl);booleanisAuthorizedForFunction(StringfunctionName);booleanisAuthorizedForData(Stringaction,Objectdata);booleanisAuthorizedForFile(Stringfilepath);booleanisAuthorizedForService(StringserviceName);voidassertAuthorizedForURL(Stringurl)throwsAccessControlException;voidassertAuthorizedForFunction(StringfunctionName)throwsAccessControlException;voidassertAuthorizedForData(Stringaction,Objectdata)throwsAccessControlException;voidassertAuthorizedForFile(Stringfilepath)throwsAccessControlException;voidassertAuthorizedForService(StringserviceName)throwsAccessControlException;**实验 现场简单XSS防护实验**************************************************************************