javaWeb安全验证漏洞修复总结_第1页
javaWeb安全验证漏洞修复总结_第2页
javaWeb安全验证漏洞修复总结_第3页
javaWeb安全验证漏洞修复总结_第4页
javaWeb安全验证漏洞修复总结_第5页
已阅读5页,还剩24页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

26/29EMA服务管理平台二期扩容平安验收漏洞修复总结2011年5月目录1 Web平安介绍 12 SQL注入、盲注 12.1 SQL注入、盲注概述 12.2 平安风险及缘由 22.3 AppScan扫描建议 22.4 应用程序解决方案 43 会话标识未更新 73.1 会话标识未更新概述 73.2 平安风险及缘由分析 73.3 AppScan扫描建议 83.4 应用程序解决方案 84 已解密登录恳求 84.1 已解密登录恳求概述 84.2 平安风险及缘由分析 84.3 AppScan扫描建议 94.4 应用程序解决方案 95 跨站点恳求伪造 115.1 跨站点恳求伪造概述 115.2 平安风险及缘由分析 125.3 AppScan扫描建议 125.4 应用程序解决方案 126 不充分账户封锁 136.1 不充分账户封锁概述 136.2 平安风险及缘由分析 136.3 AppScan扫描建议 136.4 应用程序解决方案 137 启用担心全HTTP方法 147.1 启用担心全HTTP方法概述 147.2 平安风险及缘由分析 147.3 AppScan扫描建议 157.4 应用程序解决方案 158 HTTP注释敏感信息 168.1 HTTP注释敏感信息概述 168.2 平安风险及缘由分析 168.3 AppScan扫描建议 168.4 应用程序解决方案 169 发现电子邮件地址模式 169.1 发现电子邮件地址模式概述 169.2 平安风险及缘由分析 179.3 AppScan扫描建议 179.4 应用程序解决方案 1710 通过框架钓鱼 2010.1 通过框架钓鱼概述 2010.2 平安风险及缘由分析 2010.3 AppScan扫描建议 2010.4 应用程序解决方案 2311 检查到文件替代版本 2511.1 检查到文件替代版本概述 2511.2 平安风险及缘由分析 2511.3 AppScan扫描建议 2511.4 应用程序解决方案 26Web平安介绍目前很多业务都依靠于互联网,例如说网上银行、网络购物、网游等,很多恶意攻击者出于不良的目的对Web服务器进行攻击,想方设法通过各种手段猎取他人的个人账户信息谋取利益。正是由于这样,Web业务平台最容易患病攻击。同时,对Web服务器的攻击也可以说是形形色色、种类繁多,常见的有挂马、SQL注入、缓冲区溢出、嗅探、利用IIS等针对Webserver漏洞进行攻击。一方面,由于TCP/IP的设计是没有考虑平安问题的,这使得在网络上传输的数据是没有任何平安防护的。攻击者可以利用系统漏洞造成系统进程缓冲区溢出,攻击者可能获得或者提升自己在有漏洞的系统上的用户权限来运行任意程序,甚至安装和运行恶意代码,窃取机密数据。而应用层面的软件在开发过程中也没有过多考虑到平安的问题,这使得程序本身存在很多漏洞,诸如缓冲区溢出、SQL注入等等流行的应用层攻击,这些均属于在软件研发过程中疏忽了对平安的考虑所致。另一方面,用户对某些隐秘的东西带有强烈的奇怪心,一些利用木马或病毒程序进行攻击的攻击者,往往就利用了用户的这种奇怪心理,将木马或病毒程序捆绑在一些明丽的图片、音视频及免费软件等文件中,然后把这些文件置于某些网站当中,再引诱用户去单击或下载运行。或者通过电子邮件附件和QQ、MSN等即时谈天软件,将这些捆绑了木马或病毒的文件发送给用户,利用用户的奇怪心理引诱用户打开或运行这些文件、SQL注入、盲注SQL注入、盲注概述Web应用程序通常在后端使用数据库,以与企业数据仓库交互。查询数据库事实上的标准语言是SQL(各大数据库供应商都有自己的不同版本)。Web应用程序通常会猎取用户输入(取自HTTP恳求),将它并入SQL查询中,然后发送到后端数据库。接着应用程序便处理查询结果,有时会向用户显示结果。

如果应用程序对用户(攻击者)的输入处理不够当心,攻击者便可以利用这种操作方式。在此情况下,攻击者可以注入恶意的数据,当该数据并入SQL查询中时,就将查询的原始语法更改得面目全非。例如,如果应用程序使用用户的输入(如用户名和密码)来查询用户帐户的数据库表,以认证用户,而攻击者能够将恶意数据注入查询的用户名部分(和/或密码部分),查询便可能更改成完全不同的数据复制查询,可能是修改数据库的查询,或在数据库服务器上运行Shell命令的查询。平安风险及缘由高风险漏洞,攻击者可能会查看、修改或删除数据库条目和表缘由:未对用户输入正确执行危险字符清理AppScan扫描建议若干问题的补救方法在于对用户输入进行清理。

通过验证用户输入未包含危险字符,便可能防止恶意的用户导致应用程序执行计划外的任务,例如:启动任意SQL查询、嵌入将在客户端执行的Javascript代码、运行各种操作系统命令,等等。

建议过滤出全部以下字符:[1]|(竖线符号)[2]&(&符号)[3];(分号)[4]$(美元符号)[5]%(百分比符号)[6]@(at符号)[7]'(单引号)[8]"(引号)[9]\'(反斜杠转义单引号)[10]\"(反斜杠转义引号)[11]<>(尖括号)[12]()(括号)[13]+(加号)[14]CR(回车符,ASCII0x0d)[15]LF(换行,ASCII0x0a)[16],(逗号)[17]\(反斜杠)以下部分描述各种问题、问题的修订建议以及可能触发这些问题的危险字符:

SQL注入和SQL盲注:

A.确保用户输入的值和类型(如Integer、Date等)有效,且符合应用程序预期。

B.利用存储过程,将数据访问抽象化,让用户不直接访问表或视图。当使用存储过程时,请利用ADO命令对象来实施它们,以强化变量类型。

C.清理输入以排解上下文更改符号,例如:[1]'(单引号)[2]"(引号)[3]\'(反斜线转义单引号)[4]\"(反斜杠转义引号)[5])(结束括号)[6];(分号)跨站点脚本编制:

A.清理用户输入,并过滤出JavaScript代码。我们建议您过滤下列字符:[1]<>(尖括号)[2]"(引号)[3]'(单引号)[4]%(百分比符号)[5];(分号)[6]()(括号)[7]&(&符号)[8]+(加号)B.如果要修订<%00script>变体,请参阅MS文章821349

C.对于UTF-7攻击:[-]可能的话,建议您施行特定字符集编码(使用'Content-Type'头或<meta>标记)。

HTTP响应分割:清理用户输入(至少是稍后嵌入在HTTP响应中的输入)。

请确保输入未包含恶意的字符,例如:[1]CR(回车符,ASCII0x0d)[2]LF(换行,ASCII0x0a)远程命令执行:清理输入以排解对执行操作系统命令有意义的符号,例如:[1]|(竖线符号)[2]&(&符号)[3];(分号)执行shell命令:

A.绝不将未检查的用户输入传递给eval()、open()、sysopen()、system()之类的Perl命令。

B.确保输入未包含恶意的字符,例如:[1]$(美元符号)[2]%(百分比符号)[3]@(at符号)XPath注入:清理输入以排解上下文更改符号,例如:[1]'(单引号)[2]"(引号)等LDAP注入:

A.使用正面验证。字母数字过滤(A..Z,a..z,0..9)适合大部分LDAP查询。

B.应该过滤出或进行转义的特别LDAP字符:[1]在字符串开头的空格或“#”字符[2]在字符串结尾的空格字符[3],(逗号)[4]+(加号)[5]"(引号)[6]\(反斜杠)[7]<>(尖括号)[8];(分号)[9]()(括号)MX注入:

应该过滤出特别MX字符:[1]CR(回车符,ASCII0x0d)[2]LF(换行,ASCII0x0a)记录伪造:应该过滤出特别记录字符:[1]CR(回车符,ASCII0x0d)[2]LF(换行,ASCII0x0a)[3]BS(退格,ASCII0x08)ORM注入:

A.确保用户输入的值和类型(如Integer、Date等)有效,且符合应用程序预期。

B.利用存储过程,将数据访问抽象化,让用户不直接访问表或视图。

C.使用参数化查询API

D.清理输入以排解上下文更改符号,例如:(*):[1]'(单引号)[2]"(引号)[3]\'(反斜线转义单引号)[4]\"(反斜杠转义引号)[5])(结束括号)[6];(分号)应用程序解决方案1、我们为了调试便利,在页面上会抛出数据库异常信息,如果入侵工具猎取了这些信息,就可以猎取系统的一些配置信息,如web系统框架、接受的数据库等,从而找出系统漏洞。所以不要在页面上抛出异常的简略信息,这些信息对客户并没有用,只是便利技术人员调试罢了,处理方法是在异常处理页面把打印异常代码删除即可;2、新建一个过滤器,通过过滤器过滤SQL注入特别字符,配置成功后,重启服务,用Appsan工具扫描,漏洞得到解决,通过过滤器可以解决SQL注入、跨站点脚本编制及通过框架钓鱼等问题,简略实现方式如下:1、在web.xml文件中配置过滤器 <filter-mapping> <filter-name>requestEncodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping><filter> <filter-name>InjectFilter</filter-name> <filter-class>com.sitech.ismp.util.context.InjectFilter</filter-class> </filter>2、过滤器过滤代码publicclassInjectFilterextendsIsmpServletFilter{privateStringfailPage="/loginout.jsp";//发生注入时,跳转页面publicvoiddoFilter(ServletRequestrequest,ServletResponseresponse, FilterChainfilterchain)throwsIOException,ServletException{ //推断是否有注入攻击字符 HttpServletRequestreq=(HttpServletRequest)request; Stringinj=injectInput(req); if(!inj.equals("")){ request.getRequestDispatcher(failPage).forward(request,response); return; }else{ //传递掌握到下一个过滤器 filterchain.doFilter(request,response); }}/***推断request中是否含有注入攻击字符*@paramrequest*@return*/publicStringinjectInput(ServletRequestrequest){ Enumeratione=request.getParameterNames(); StringattributeName; StringattributeValues[]; Stringinj=""; while(e.hasMoreElements()){ attributeName=(String)e.nextElement(); //不对密码信息进行过滤,一般密码中可以包含特别字符 if(attributeName.equals("userPassword")||attributeName.equals("confirmPassword")||attributeName.equals("PASSWORD") ||attributeName.equals("password")||attributeName.equals("PASSWORD2")||attributeName.equals("valiPassword")){ continue; } attributeValues=request.getParameterValues(attributeName); for(inti=0;i<attributeValues.length;i++){ if(attributeValues[i]==null||attributeValues[i].equals("")) continue; inj=injectChar(attributeValues[i]); if(!inj.equals("")){ returninj; } } } returninj;}/***推断字符串中是否含有注入攻击字符*@paramstr*@return*/publicStringinjectChar(Stringstr){ Stringinj_str="\")\'*%";Stringinj_stra[]=inj_str.split(""); for(inti=0;i<inj_stra.length;i++){if(str.indexOf(inj_stra[i])>=0){returninj_stra[i];}}return"";}}会话标识未更新会话标识未更新概述“会话固定”是一种攻击技术,会强制用户的会话标识变成显式值。固定会话标识值的技术有很多种,会随着目标Web站点的功能而不同。从利用“跨站点脚本编制”到向Web站点密集发出先前生成的HTTP恳求,都在这些技术范围内。用户的会话标识固定之后,攻击者会等待用户登录,然后利用预定义的会话标识值来假定用户的联机身份。

一般而言,对于标识值的会话管理系统有两种类型。第一种类型是“宽容”系统,可让Web扫瞄器指定任何标识。其次种类型是“严格”系统,只接受服务器端生成的值。当使用宽容系统时,不需要联系Web站点,便可以维护任何会话标识。在严格系统中,攻击者需要维护“陷阱会话”并且必须定期联系Web站点,才能防止闲置超时。对于会话固定,倘若没有活动保护,使用会话来识别已认证的用户的任何Web站点都可能受到攻击。使用会话标识的Web站点通常都是基于cookie的站点,但也会使用URL和隐藏的表单字段。不幸的是,基于cookie的会话最容易受到攻击。目前已识别的大多数攻击方法都是针对cookie的固定。相对于在用户登录Web站点之后,再窃取用户的会话标识,会话固定供应的机会多得多。

在用户登录之前,攻击的活动部分便已启动。

会话固定攻击过程通常由三个步骤组成:

1)安装会话

攻击者针对目标Web站点设下“陷阱会话”,并猎取这个会话的标识,攻击者也可以选择攻击中所用的任意会话标识。在某些情况下,必须反复联系Web站点,才能维护确定好的陷阱会话值。

2)固定会话

攻击者将陷阱会话值引进用户的扫瞄器中,固定用户的会话标识。

3)进入会话

用户登录目标Web站点之后,当使用固定会话标识值时,攻击者便可加以接管。”修改 对于这类问题解决方案为在用户进入登录页面时清空session让cookie过期request.getSession(true).invalidate();//清空session Cookiecookie=request.getCookies()[0];//猎取cookie cookie.setMaxAge(0);//让cookie过期另外一种方式利用JSP的一些特性,不让登录页面产生Session<%pagesession=”false”%>平安风险及缘由分析高风险漏洞,可能会窃取或操纵客户会话和cookie,它们可能用于仿照合法用户,从而使黑客能够以该用户身份查看或变更用户记录以及执行事务缘由:Web应用程序编程或配置担心全AppScan扫描建议始终生成新的会话,供用户成功认证时登录。防止用户操纵会话标识。

请勿接受用户扫瞄器登录时所供应的会话标识应用程序解决方案

会话标识未更新,Appscan给出的描述是建议用户每次登录时需使用新的会话标识。应用程序实现上就是在登录模块,添加以下代码,即用户登录后,重新生成会话。HttpSessionsession=request.getSession(false);if(session!=null){//让cookie过期 session.invalidate(); Cookiecookie=request.getCookies()[0];//猎取cookie cookie.setMaxAge(0);//让cookie过期}request.getSession(true);//生成新会话经过测试,这段代码只在weblogic和tomcat下才有效,在公司中间件webspeed及jboss6.0下问题都依然存在,但从扫描的结果信息分析看,漏洞已经解决,分析推断应该只是session处理机制不同,AppScan工具仍认为存在漏洞风险。在与电信沟通中我们存在一个阅历教训大家肯定要吸取,不能过渡迷信流行的自动化测试工具,尤其是对于Appscan这种推断防御行为的简单软件,仅靠有限的规章设置就当做是web平安的唯一标准这显然不太合理,这种情况肯定要与测试方沟通解释。另一方面,对于公司的产品webspeed,也想提点建议,商务项目接受公司的产品为公司节省了不少成本,但是我们产品后续升级维护也必须重视起来,当确认出是webspeed本身问题后,联系vasg相关人员进行协调解决,根本没有特别了解该产品技术人员支持,只是一个刚入职的同事在协作测试。调试了一周时间仍不能解决,最后只能作为一个遗留问题搁置。公司始终在向产品化转变,但是自身的产品维护、升级、管理仍然需要改进。已解密登录恳求已解密登录恳求概述在应用程序测试过程中,检测到将未加密的登录恳求发送到服务器。由于登录过程所用的部分输入字段(例如:用户名、密码、电子邮件地址、社会保险号码,等等)是个人敏感信息,建议通过加密连接(如SSL)将其发送到服务器。任何以明文传给服务器的信息都可能被窃,稍后可用来电子欺骗身份或伪装用户。此外,若干隐私权法规指出,用户凭证之类的敏感信息一律以加密方式传给网站。平安风险及缘由分析平安风险中,可能会窃取诸如用户名和密码等未经加密即发送了的用户登录信息缘由:诸如用户名、密码和信用卡号之类的敏感输入字段未经加密即进行了传递AppScan扫描建议1.确保全部登录恳求都以加密方式发送到服务器。

2.请确保敏感信息,例如:-用户名-密码-社会保险号码-信用卡号码-驾照号码-电子邮件地址-电话号码-邮政编码

一律以加密方式传给服务器。应用程序解决方案

已解密的登录恳求,要求就是数据要加密传输。最简洁有效的解决方式接受SSL加密协议传输,但是由于EMA服务管理平台业务的特别性,接受SSL加密方式对现有的业务影响太大,所以最终没有接受此种方式解决该问题,但个人在进行测试过程中也尝试在tomcat和jboss下SSL方式配置,写下来供参考。Jboss内核也是tomcat,所以两者配置基本都是一样,都是在生成证书文件后,在service.xml进行配置:进入到cmd进入到jdkbin名目下执行keytool-genkey-aliastomcat-keyalgRSA-keystorewebspeed.keystore生成证书在service.xml配置SSL<Connectorport="8443"maxHttpHeaderSize="8192"maxThreads="150"minSpareThreads="25"maxSpareThreads="75"enableLookups="false"disableUploadTimeout="true"acceptCount="100"scheme="https"secure="true"clientAuth="false"sslProtocol="TLS"keystoreFile="C:\tomcat-5.5.26\conf\webspeed.keystore"keystorePass="1111aaaa"/>这样配置后虽然可以通过https访问,但仍然还可以通过8080使用一般的http访问,所以还必须禁止一般模式登录。所以还得在web.xml添加配置。01020304050607080910111213141516171819202122232425262728293031<security-constraint>

<!--AuthorizationsettingforSSL-->

<web-resource-collection>

<web-resource-name>SSL</web-resource-name>

<url-pattern>*.jsp</url-pattern>

<url-pattern>*.action</url-pattern>

</web-resource-collection>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

<login-config>

<!--AuthorizationsettingforSSL-->

<auth-method>CLIENT-CERT</auth-method>

<realm-name>ClientCertUsers-onlyArea</realm-name>

</login-config>

应注意,由于项目的一些组件无法通过https,因此url-pattern字段只对.jsp和.action进行了限制,如果不做特定限制,则系统默认是全部使用https传输。而且上述设置一旦在某个工程中消失,那么当前tomcat将全局接受这一配置。跨站点恳求伪造跨站点恳求伪造概述“跨站点伪造恳求(CSRF)”攻击可让黑客以受害者的名义在易受攻击的站点上运行操作。当易受攻击的站点未适当验证恳求来源时,便可能消失这个攻击。这个漏洞的严峻性取决于受影响的应用程序的功能,例如,对搜寻页面的CSRF攻击,严峻性低于对转帐页面或概要更新页面的CSRF攻击。

这项攻击的执行方式,是强迫受害者的扫瞄器向易受攻击的站点发出HTTP恳求。如果用户目前已登录受害者站点,恳求会自动使用用户的凭证(如会话Cookie、用户的IP地址,以及其他扫瞄器认证方法)。攻击者利用这个方法来伪造受害者的身份,再代替他来提交操作。换句话来说,易受攻击的站点未实行适当措施来验证用户实际是否想执行特定操作。

强迫受害者发送非预期的恳求,方法有很多种:

-通过电子邮件向受害者发送易受攻击应用程序的恶意链接。-在黑客的Web页面上,放置一个易受攻击的Web站点的热链接(如图像或帧)。-在公共论坛中,张贴易受攻击站点的链接。

-利用站点(或另一个站点)的“跨站点脚本编制”或“链接注入”漏洞,将扫瞄器自动重定向到易受攻击的站点。

如果攻击者利用易受攻击的站点本身的“链接注入”漏洞,可以增加用户通过站点认证的可能性,进而增加攻击成功的可能性。

例如,攻击者可以利用上述任何选项来诱惑受害者查看含有下列条目的页面:

<imgsrc=""style='visibility:hidden'>

这会使受害者的扫瞄器自动恳求URL及扫瞄器的当前凭证。如果这个银行业站点易受到CSRF攻击,它会依据应用程序规律,从受害者的帐户中,将1000美元转账到John的银行帐户。“跨站点伪造恳求”攻击也称为CSRF(发音为C-Serf)、XSRF、“跨站点伪造引用”、“单键攻击”以及“会话骑乘”。

您可以利用下列方式来验证您的应用程序是否易受到CSRF攻击:

[1]检查易受攻击的链接/恳求是否未包括攻击者难以猜中的参数

[2]检查易受攻击的链接/恳求是否会执行只应自愿执行的操作

含有用户在不知不觉中提交的恳求所能直接访问的敏感操作的应用程序,被视为很容易患病CSRF攻击。CSRF也可能消失在登录页面和注销页面上。由于攻击者可以伪造来自受害者的连续注销恳求,因此CSRF可能导致服务拒绝。在登录页面上,CSRF可以允许攻击者使用包含攻击者用户名和密码的伪造恳求来将客户机登录到攻击者的账户中。登录CSRF攻击会带有严峻的后果,这取决于其他站点行为。例如,如果站点保留了用户操作的历史记录(例如搜寻历史记录),那么攻击者将能够在易受攻击的站点上查看受害者之前执行的操作。平安风险及缘由分析平安风险中,可能会窃取或操纵客户会话和cookie,它们可能用于仿照合法用户,从而使黑客能够以该用户身份查看或变更用户记录以及执行事务缘由:应用程序使用的认证方法不充分AppScan扫描建议如果要避开CSRF攻击,每个恳求都应该包含唯一标识,它是攻击者所无法猜想的参数。建议的选项之一是添加取自会话cookie的会话标识,使它成为一个参数。服务器必须检查这个参数是否符合会话cookie,若不符合,便废弃恳求。攻击者无法猜想这个参数的缘由是应用于cookie的“同源策略”,因此,攻击者无法伪造一个虚假的恳求,让服务器误以为真。攻击者难以猜想且无法访问的任何隐秘(也就是无法从其他域访问),都可用来替换会话标识。这可以防止攻击者设计看似有效的恳求。应用程序解决方案

已解密的登录恳求,要求就是数据要加密传输。最简洁有效的解决方式接受SSL加密协议传输,但是由于EMA服务管理平台业务的特别性,接受SSL加密方式对现有的业务影响太大,所以最终没有接受此种方式解决该问题,但个人在进行测试过程中也尝试在tomcat和jboss下SSL方式配置,写下来供参考。不充分账户封锁不充分账户封锁概述蛮力攻击是指恶意用户发送大量可能的密码和/或用户名以访问应用程序的尝试。由于该技术包含大量登录尝试,未限制允许的错误登录恳求次数的应用程序很容易遭到这类攻击。因此,强烈建议您对帐户限制允许的错误登录尝试次数,超过该次数,便锁定该帐户。样本利用:

下列恳求说明密码猜想恳求:如果站点在若干次错误尝试之后并不锁定测试的帐户,攻击者最终可能会发现帐户密码,并使用它来假冒帐户的合法用户。平安风险及缘由分析平安风险高,可能会升级用户特权并通过Web应用程序猎取管理许可权缘由:Web应用程序编程或配置担心全AppScan扫描建议请确定允许的登录尝试次数(通常是3-5次),确保超出允许的尝试次数之后,便锁定帐户。为了避开真正的用户因帐户被锁定而致电支持人员的麻烦,可以仅临时性暂挂帐户活动,并在特定时间段之后启用帐户。帐户锁定大约10分钟,通常便足以阻止蛮力攻击。应用程序解决方案

依据扫描建议,web应用程序设定允许登录尝试次数,登录连续失败超过设定次数,就锁定用户,失败次数敏捷配置。在用户登录时进行验证: if(!encrypter.encrypt(userPassword).equalsIgnoreCase( user.getLOGIN_PASSWD()==null?"":user.getLOGIN_PASSWD())){ //更新此用户登录失败次数 this.updateLoginFailTimes(userCode); //如果用户连续登录失败次数超过配置值则将其锁定 intloginLockTimes=this.getLoginLockTimes(); if(this.getLoginFailTimes(userCode)>=loginLockTimes){ this.lockUser(userCode); } thrownewMySecurityException("密码不正确!用户:"+userCode); }启用担心全HTTP方法启用担心全HTTP方法概述似乎Web服务器配置成允许下列其中一个(或多个)HTTP方法(动词):

-DELETE

-SEARCH

-COPY

-MOVE

-PROPFIND

-PROPPATCH

-MKCOL

-LOCK

-UNLOCK

这些方法可能表示在服务器上启用了WebDAV,可能允许未授权的用户对其进行利用。平安风险及缘由分析平安风险中,可能会在Web服务器上上载、修改或删除Web页面、脚本和文件缘由:Web服务器或应用程序服务器是以担心全的方式配置的AppScan扫描建议如果服务器不需要支持WebDAV,请务必禁用它,或禁止不必要的HTTP方法(动词)。应用程序解决方案修改web工程中web.xml,增加平安配置信息,禁用不必要HTTP方法

<security-constraint><web-resource-collection> <web-resource-name>HtmlAdaptor</web-resource-name> <description>test</description> <url-pattern>*.jsp</url-pattern> <url-pattern>*.do</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> <http-method>PUT</http-method> <http-method>DELETE</http-method> <http-method>HEAD</http-method> <http-method>OPTIONS</http-method> <http-method>TRACE</http-method></web-resource-collection><!--<auth-constraint> <role-name>JBossAdmin</role-name></auth-constraint>--></security-constraint>。HTTP注释敏感信息HTTP注释敏感信息概述很多Web应用程序程序员使用HTML注释,以在需要时帮助调试应用程序。尽管添加常规注释有助于调试应用程序,但一些程序员往往会遗留重要数据(例如:与Web应用程序相关的文件名、旧的链接或原非供用户扫瞄的链接、旧的代码片段等)。平安风险及缘由分析平安风险低,能会收集有关Web应用程序的敏感信息,如用户名、密码、机器名和/或敏感文件位置缘由:程序员在Web页面上留下调试信息AppScan扫描建议[1]请勿在HTML注释中遗留任何重要信息(如文件名或文件路径)。

[2]从生产站点注释中除去以前(或将来)站点链接的跟踪信息。

[3]避开在HTML注释中放置敏感信息。

[4]确保HTML注释不包括源代码片段。

[5]确保程序员没有遗留重要信息。。应用程序解决方案

虽然这个漏洞为低级别漏洞,但电信方也是要求必须修复,要修改此漏洞需要检查工程中的每一个jsp页面,工作量还是挺大。所以在后续开发过程中注释尽量写英文注释,尽量不要遗留敏感注释信息在jsp代码中,养成良好的编码习惯才是解决问题根本。发现电子邮件地址模式发现电子邮件地址模式概述Spambot搜寻因特网站点,开头查找电子邮件地址来构建发送自发电子邮件(垃圾邮件)的邮件列表。AppScan检测到含有一或多个电子邮件地址的响应,可供利用以发送垃圾邮件。而且,找到的电子邮件地址也可能是专用电子邮件地址,对于一般大众应是不行访问的。平安风险及缘由分析平安风险低,能会收集有关Web应用程序的敏感信息,如用户名、密码、机器名和/或敏感文件位置缘由:Web应用程序编程或配置担心全AppScan扫描建议从Web站点中除去任何电子邮件地址,使恶意的用户无从利用。应用程序解决方案

依据扫描建议删除注释中消失email地址信息,如果页面中要显示mail地址转为图片形式展现。如:ema服务管理平台首页需要展现客户联系方式,并且联系方式、email等信息,这些信息用户都是可以自行修改的,由于包含了email地址,所以联系方式就转为图片形式:<%@pagelanguage="java"contentType="text/html;charset=gb2312"%><%@includefile="/common/taglib.jsp"%><%@includefile="/common/chart.jsp"%><%@pageimport="java.util.List,java.util.*,java.awt.*,java.awt.image.*,com.sun.image.codec.jpeg.*,java.util.*"%><%@pageimport="rmationService.publish.dao.TB_SYS_SUPPORT_STAFFDao"%><html:htmllocale="true"><head><%@includefile="/common/link.jsp"%><%@pageimport="com.sitech.ismp.util.context.CommUtil"%></head><linkhref="/css/style.css"rel="stylesheet"type="text/css"><scripttype="text/javascript"src="/js/pub.js"></script><linkrel="stylesheet"type="text/css"media="all"href="/css/calendar-win2k-cold-1.css"title="win2k-cold-1"/><body><html:formaction="/homeContactShow"method="post"styleId="theForm"><bean:defineid="theForm"name="supportStaffForm"/><DIVclass=bgid=left><div><tablewidth="100%"border="0"cellpadding="0"cellspacing="0"class="tablebg"><TBODY> <tr><tdclass="tableheadbg">运营中心联系方式</td></tr><tr><tdclass="tablewhitebg"> <% ListtypeList=(List)request.getAttribute("typeList"); out.clear(); out=pageContext.pushBody(); response.setContentType("image/jpeg"); response.addHeader("pragma","NO-cache"); response.addHeader("Cache-Control","no-cache"); response.addDateHeader("Expries",0); introwheight=20; intwidth=135,height=rowheight*typeList.size(); TB_SYS_SUPPORT_STAFFDaodao=newTB_SYS_SUPPORT_STAFFDao(); Stringty=""; Stringmob=""; for(inti=0;i<typeList.size();i++){ HashMaphm=(HashMap)typeList.get(i); ty=(String)hm.get("TYPE_ID"); Liststa=(List)dao.findSupportStaffByTypeId(ty); for(intk=0;k<sta.size();k++){ HashMapmap=(HashMap)sta.get(k); mob=(String)map.get("MOBILE"); height+=3*rowheight; if(mob!=null)height+=rowheight; } } BufferedImageimage=newBufferedImage(width,height,BufferedImage.TYPE_INT_RGB); Graphicsg=image.getGraphics(); g.setColor(Color.white); g.fillRect(0,0,width,height); g.setColor(Color.BLUE); Fontfont=newFont("宋体",Font.PLAIN,13); g.setFont(font); introw=0; Stringtypeid=""; Stringtypename=""; Stringname=""; Stringtel=""; Stringmail=""; Stringmobile=""; for(inti=0;i<typeList.size();i++){ HashMaphm=(HashMap)typeList.get(i); typeid=(String)hm.get("TYPE_ID"); typename=(String)hm.get("TYPE_NAME"); row++; g.drawString(typename,0,(row-1)*rowheight+10); Liststaffs=(List)dao.findSupportStaffByTypeId(typeid); for(intk=0;k<staffs.size();k++){ HashMapmap=(HashMap)staffs.get(k); name=(String)map.get("NAME"); tel=(String)map.get("TEL"); mail=(String)map.get("MAIL"); mobile=(String)map.get("MOBILE"); row++; g.drawString(name+":"+tel,0,(row-1)*rowheight+10); row++; g.drawString(mail,0,(row-1)*rowheight+10); if(mobile!=null){ row++; g.drawString(mail,0,(row-1)*rowheight+10); } }}g.dispose();ServletOutputStreamoutStream=response.getOutputStream(); JPEGImageEncoderencoder=JPEGCodec.createJPEGEncoder(outStream); encoder.encode(image); outStream.close();%></td></tr></TBODY></table></div></DIV></html:form></body></html:html>通过框架钓鱼通过框架钓鱼概述网络钓鱼是一个通称,代表试图欺骗用户交出私人信息,以便电子欺骗身份。

攻击者有可能注入frame或iframe标记,其中含有类似受攻击之网站的恶意属性。不当心的用户有可能扫瞄它,但并不知道他正在离开原始网站,冲浪到恶意的网站。之后,攻击者便可以诱惑用户重新登录,然后猎取他的登录凭证。

伪造的网站嵌入在原始网站中,这个情况对攻击者有帮助,由于他的网络钓鱼企图会披上更可信赖的外表。

样本利用:

如果参数值未经适当清理,便反映在响应中,下列恳求:http://[SERVER]/script.aspx?parameter=<framename="evil"src="">

会使响应含有通往这个邪恶站点的框架。平安风险及缘由分析平安风险中,可能会劝告初级用户供应诸如用户名、密码、信用卡号、社会保险号等敏感信息缘由:对用户输入正确执行危险字符清理AppScan扫描建议若干问题的补救方法在于对用户输入进行清理。

通过验证用户输入未包含危险字符,便可能防止恶意的用户导致应用程序执行计划外的任务,例如:启动任意SQL查询、嵌入将在客户端执行的Javascript代码、运行各种操作系统命令,等等。

建议过滤出全部以下字符:[1]|(竖线符号)[2]&(&符号)[3];(分号)[4]$(美元符号)[5]%(百分比符号)[6]@(at符号)[7]'(单引号)[8]"(引号)[9]\'(反斜杠转义单引号)[10]\"(反斜杠转义引号)[11]<>(尖括号)[12]()(括号)[13]+(加号)[14]CR(回车符,ASCII0x0d)[15]LF(换行,ASCII0x0a)[16],(逗号)[17]\(反斜杠)以下部分描述各种问题、问题的修订建议以及可能触发这些问题的危险字符:

SQL注入和SQL盲注:

A.确保用户输入的值和类型(如Integer、Date等)有效,且符合应用程序预期。

B.利用存储过程,将数据访问抽象化,让用户不直接访问表或视图。当使用存储过程时,请利用ADO命令对象来实施它们,以强化变量类型。

C.清理输入以排解上下文更改符号,例如:[1]'(单引号)[2]"(引号)[3]\'(反斜线转义单引号)[4]\"(反斜杠转义引号)[5])(结束括号)[6];(分号)跨站点脚本编制:

A.清理用户输入,并过滤出JavaScript代码。我们建议您过滤下列字符:[1]<>(尖括号)[2]"(引号)[3]'(单引号)[4]%(百分比符号)[5];(分号)[6]()(括号)[7]&(&符号)[8]+(加号)B.如果要修订<%00script>变体,请参阅MS文章821349

C.对于UTF-7攻击:[-]可能的话,建议您施行特定字符集编码(使用'Content-Type'头或<meta>标记)。

HTTP响应分割:清理用户输入(至少是稍后嵌入在HTTP响应中的输入)。

请确保输入未包含恶意的字符,例如:[1]CR(回车符,ASCII0x0d)[2]LF(换行,ASCII0x0a)远程命令执行:清理输入以排解对执行操作系统命令有意义的符号,例如:[1]|(竖线符号)[2]&(&符号)[3];(分号)执行shell命令:

A.绝不将未检查的用户输入传递给eval()、open()、sysopen()、system()之类的Perl命令。

B.确保输入未包含恶意的字符,例如:[1]$(美元符号)[2]%(百分比符号)[3]@(at符号)XPath注入:清理输入以排解上下文更改符号,例如:[1]'(单引号)[2]"(引号)等LDAP注入:

A.使用正面验证。字母数字过滤(A..Z,a..z,0..9)适合大部分LDAP查询。

B.应该过滤出或进行转义的特别LDAP字符:[1]在字符串开头的空格或“#”字符[2]在字符串结尾的空格字符[3],(逗号)[4]+(加号)[5]"(引号)[6]\(反斜杠)[7]<>(尖括号)[8];(分号)[9]()(括号)MX注入:

应该过滤出特别MX字符:[1]CR(回车符,ASCII0x0d)[2]LF(换行,ASCII0x0a)记录伪造:应该过滤出特别记录字符:[1]CR(回车符,ASCII0x0d)[2]LF(换行,ASCII0x0a)[3]BS(退格,ASCII0x08)ORM注入:

A.确保用户输入的值和类型(如Integer、Date等)有效,且符合应用程序预期。

B.利用存储过程,将数据访问抽象化,让用户不直接访问表或视图。

C.使用参数化查询API

D.清理输入以排解上下文更改符号,例如:(*):[1]'(单引号)[2]"(引号)[3]\'(反斜线转义单引号)[4]\"(反斜杠转义引号)[5])(结束括号)[6];(分号)(*)这适用于SQL。高级查询语言可能需要不同的清理机制。。应用程序解决方案

新建一个过滤器,通过过滤器过滤SQL注入特别字符,配置成功后,重启服务,用Appsan工具扫描,漏洞得到解决,简略实现方式如下:1、在web.xml文件中配置过滤器 <filter-mapping> <filter-name>requestEncodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping><filter> <filter-name>InjectFilter</filter-name> <filter-cla

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论