javaWeb安全漏洞修复总结
1 Web安全介绍1
2 SQL注⼊、盲注1
2.1 SQL注⼊、盲注概述 1
2.2 安全风险及原因 2
2.3 AppScan扫描建议 2
2.4 应⽤程序解决⽅案 4
3 会话标识未更新7
3.1 会话标识未更新概述 7
3.2 安全风险及原因分析 7
3.3 AppScan扫描建议 8
3.4 应⽤程序解决⽅案 8
4 已解密登录请求8
4.1 已解密登录请求概述 8
4.2 安全风险及原因分析 8
4.3 AppScan扫描建议 9
4.4 应⽤程序解决⽅案 9
5 跨站点请求伪造11
5.1 跨站点请求伪造概述 11
5.2 安全风险及原因分析 12
5.3 AppScan扫描建议 12
5.4 应⽤程序解决⽅案 12
6 不充分账户封锁13
6.1 不充分账户封锁概述 13
6.2 安全风险及原因分析 13
6.3 AppScan扫描建议 13
6.4 应⽤程序解决⽅案 13
7 启⽤不安全HTTP⽅法14
7.1 启⽤不安全HTTP⽅法概述 14
7.2 安全风险及原因分析 14
7.3 AppScan扫描建议 15
7.4 应⽤程序解决⽅案 15
8 HTTP注释敏感信息16
8.1 HTTP注释敏感信息概述 16
8.2 安全风险及原因分析 16
8.3 AppScan扫描建议 16
8.4 应⽤程序解决⽅案 16
9 发现电⼦邮件地址模式16
9.1 发现电⼦邮件地址模式概述 16
9.2 安全风险及原因分析 17xml实体解析xpath注入
9.3 AppScan扫描建议 17
9.4 应⽤程序解决⽅案 17
10 通过框架钓鱼20
10.1 通过框架钓鱼概述 20
10.2 安全风险及原因分析 20
10.3 AppScan扫描建议 20
10.4 应⽤程序解决⽅案 23
11 检查到⽂件替代版本25
11.1 检查到⽂件替代版本概述 25
11.2 安全风险及原因分析 25
11.3 AppScan扫描建议 25
11.4 应⽤程序解决⽅案 26
1 Web安全介绍
　⽬前很多业务都依赖于互联⽹，例如说⽹上银⾏、⽹络购物、⽹游等，很多恶意攻击者出于不良的⽬的对Web 服务器进⾏攻击，想⽅设法通过各种⼿段获取他⼈的个⼈账户信息谋取利益。正是因为这样，Web业务平台最容易遭受攻击。同时，对Web服务器的攻击也可以说是形形⾊⾊、种类繁多，常见的有
挂马、SQL注⼊、缓冲区溢出、嗅探、利⽤IIS等针对Webserver漏洞进⾏攻击。
  ⼀⽅⾯，由于TCP/IP的设计是没有考虑安全问题的，这使得在⽹络上传输的数据是没有任何安全防护的。攻击者可以利⽤系统漏洞造成系统进程缓冲区溢出，攻击者可能获得或者提升⾃⼰在有漏洞的系统上的⽤户权限来运⾏任意程序，甚⾄安装和运⾏恶意代码，窃取机密数据。⽽应⽤层⾯的软件在开发过程中也没有过多考虑到安全的问题，这使得程序本⾝存在很多漏洞，诸如缓冲区溢出、SQL注⼊等等流⾏的应⽤层攻击，这些均属于在软件研发过程中疏忽了对安全的考虑所致。
另⼀⽅⾯，⽤户对某些隐秘的东西带有强烈的好奇⼼，⼀些利⽤⽊马或病毒程序进⾏攻击的攻击者，往往就利⽤了⽤户的这种好奇⼼理，将⽊马或病毒程序捆绑在⼀些艳丽的图⽚、⾳视频及免费软件等⽂件中，然后把这些⽂件置于某些⽹站当中，再引诱⽤户去单击或下载运⾏。或者通过电⼦邮件附件和QQ、MSN等即时聊天软件，将这些捆绑了⽊马或病毒的⽂件发送给⽤户，利⽤⽤户的好奇⼼理引诱⽤户打开或运⾏这些⽂件、
2 SQL注⼊、盲注
2.1 SQL注⼊、盲注概述
Web 应⽤程序通常在后端使⽤数据库，以与企业数据仓库交互。查询数据库事实上的标准语⾔是 SQL
（各⼤数据库供应商都有⾃⼰的不同版本）。Web 应⽤程序通常会获取⽤户输⼊（取⾃ HTTP 请求），将它并⼊ SQL 查询中，然后发送到后端数据库。接着应⽤程序便处理查询结果，有时会向⽤户显⽰结果。
如果应⽤程序对⽤户（攻击者）的输⼊处理不够⼩⼼，攻击者便可以利⽤这种操作⽅式。在此情况下，攻击者可以注⼊恶意的数据，当该数据并⼊ SQL 查询中时，就将查询的原始语法更改得⾯⽬全⾮。例如，如果应⽤程序使⽤⽤户的输⼊（如⽤户名和密码）来查询⽤户帐户的数据库表，以认证⽤户，⽽攻击者能够将恶意数据注⼊查询的⽤户名部分（和/或密码部分），查询便可能更改成完全不同的数据复制查询，可能是修改数据库的查询，或在数据库服务器上运⾏ Shell
命令的查询。
2.2 安全风险及原因
⾼风险漏洞，攻击者可能会查看、修改或删除数据库条⽬和表
原因：未对⽤户输⼊正确执⾏危险字符清理
2.3 AppScan扫描建议
若⼲问题的补救⽅法在于对⽤户输⼊进⾏清理。
通过验证⽤户输⼊未包含危险字符，便可能防⽌恶意的⽤户导致应⽤程序执⾏计划外的任务，例如：启动任意 SQL 查询、嵌⼊将在客户端执⾏的 Javascript 代码、运⾏各种操作系统命令，等等。
建议过滤出所有以下字符：
[1] |（竖线符号）
[2] & （& 符号）
[3];（分号）
[4] $（美元符号）
[5] %（百分⽐符号）
[6] @（at 符号）
[7] '（单引号）
[8] "（引号）
[9] \'（反斜杠转义单引号）
[10] \"（反斜杠转义引号）
[11] <>（尖括号）
[12] ()（括号）
[13] +（加号）
[14] CR（回车符，ASCII 0x0d）
[15] LF（换⾏，ASCII 0x0a）
[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（回车符，ASCII 0x0d）
[2] LF（换⾏，ASCII 0x0a）远程命令执⾏：清理输⼊以排除对执⾏操作系统命令有意义的符号，例如：
[1] |（竖线符号）
[2] & （& 符号）
[3];（分号）
执⾏ shell 命令：
A. 绝不将未检查的⽤户输⼊传递给 eval()、open()、sysopen()、system() 之类的 Perl 命令。
B. 确保输⼊未包含恶意的字符，例如：
[1] $（美元符号）
[2] %（百分⽐符号）
[3] @（at 符号）
XPath 注⼊：清理输⼊以排除上下⽂更改符号，例如：
[1] '（单引号）
[2] "（引号）等
LDAP 注⼊：
A. 使⽤正⾯验证。字母数字过滤（A..,0..9）适合⼤部分 LDAP 查询。
B. 应该过滤出或进⾏转义的特殊 LDAP 字符：
[1] 在字符串开头的空格或“#”字符
[2] 在字符串结尾的空格字符
[3] ,（逗号）
[4] +（加号）
[5] "（引号）
[6] \（反斜杠）
[7] <>（尖括号）
[8] ;（分号）
[9] ()（括号）
MX 注⼊：
应该过滤出特殊 MX 字符：
[1] CR（回车符，ASCII 0x0d）
[2] LF（换⾏，ASCII 0x0a）记录伪造：
应该过滤出特殊记录字符：
[1] CR（回车符，ASCII 0x0d）
[2] LF（换⾏，ASCII 0x0a）
[3] BS（退格，ASCII 0x08）
ORM 注⼊：
A. 确保⽤户输⼊的值和类型（如 Integer、Date 等）有效，且符合应⽤程序预期。
B. 利⽤存储过程，将数据访问抽象化，让⽤户不直接访问表或视图。
C. 使⽤参数化查询 API
D. 清理输⼊以排除上下⽂更改符号，例如： (*)：
[1] '（单引号）
[2] "（引号）
[3] \'（反斜线转义单引号）
[4] \"（反斜杠转义引号）
[5] )（结束括号）
[6] ;（分号）
2.4 应⽤程序解决⽅案
1、我们为了调试⽅便，在页⾯上会抛出数据库异常信息，如果⼊侵⼯具获取了这些信息，就可以获取系统的⼀些配置信息，如web系统框架、采⽤的数据库等，从⽽出系统漏洞。所以不要在页⾯上抛出异常的详细信息，这些信息对客户并没有⽤，只是⽅便技术⼈员调试罢了，处理⽅法是在异常处理页⾯把打印异常代码删除即可；
2、新建⼀个过滤器，通过过滤器过滤SQL注⼊特殊字符，配置成功后，重启服务，⽤Appsan⼯具扫描，漏洞得到解决，通过过滤器可以解决SQL注⼊、跨站点脚本编制及通过框架钓鱼等问题，具体实现⽅式如下：
1、在l⽂件中配置过滤器
<filter-mapping>
<filter-name>requestEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter>
<filter-name>InjectFilter</filter-name>
<filter-class>com.sitech.t.InjectFilter</filter-class>
</filter>
2、过滤器过滤代码
public class InjectFilter extends IsmpServletFilter {
private String failPage = "/loginout.jsp";//发⽣注⼊时，跳转页⾯
public void doFilter(ServletRequest request,ServletResponse response,
FilterChain filterchain)throws IOException, ServletException {
//判断是否有注⼊攻击字符
HttpServletRequest req = (HttpServletRequest) request;
String inj = injectInput(req);
if (!inj.equals("")) {
return;
} else {
// 传递控制到下⼀个过滤器
filterchain.doFilter(request, response);
}
}
/**
* 判断request中是否含有注⼊攻击字符
* @param request
* @return
*/
public String injectInput(ServletRequest request) {
Enumeration e = ParameterNames();
String attributeName;
String attributeValues[];
String inj = "";
while (e.hasMoreElements()) {
attributeName = (Element();
/
/不对密码信息进⾏过滤，⼀般密码中可以包含特殊字符
if(attributeName.equals("userPassword")||attributeName.equals("confirmPassword")||attributeName.equals("PASSWORD")
||attributeName.equals("password")||attributeName.equals("PASSWORD2")||attributeName.equals("valiPassword")){
continue;
}
attributeValues = ParameterValues(attributeName);
for (int i = 0; i < attributeValues.length; i++) {
if(attributeValues[i]==null||attributeValues[i].equals(""))
continue;
inj = injectChar(attributeValues[i]);
if (!inj.equals("")) {
return inj;
}
}
}
return inj;
}
/**
* 判断字符串中是否含有注⼊攻击字符
* @param str
* @return
*/
public String injectChar(String str) {
String inj_str = "\" ) \' * %";
String inj_stra[] = inj_str.split(" ");
for (int i = 0 ; i < inj_stra.length ; i++ )
{
if (str.indexOf(inj_stra[i])>=0)
{
return inj_stra[i];
}
}
return "";
}
}
3 会话标识未更新
3.1 会话标识未更新概述
“会话固定”是⼀种攻击技术，会强制⽤户的会话标识变成显式值。固定会话标识值的技术有许多种，会随着⽬标 Web 站点的功能⽽不同。从利⽤“跨站点脚本编制”到向 Web 站点密集发出先前⽣成的 HTTP 请求，都在这些技术范围内。⽤户的会话标识固定之后，攻击者会等待⽤户登录，然后利⽤预定义的会话标识值来假定⽤户的联机⾝份。
⼀般⽽⾔，对于标识值的会话管理系统有两种类型。第⼀种类型是“宽容”系统，可让 Web 浏览器指定任何标识。第⼆种类型是“严格”系统，只接受服务器端⽣成的值。当使⽤宽容系统时，不需要联系 Web 站点，便可以维护任何会话标识。在严格系统中，攻击者需要维护“陷阱会话”并且必须定期联系 Web 站点，才能防⽌闲置超时。对于会话固定，倘若没有活动保护，使⽤会话来识别已认证的⽤户的任何 Web 站点都可能受到攻击。使⽤会话标识的 Web 站点通常都是基于cookie 的站点，但也会使⽤ URL 和隐藏的表单字段。不幸的是，基于 cookie 的会话最容易受到攻击。⽬前已识别的⼤多数攻击⽅法都是针对 c
ookie 的固定。相对于在⽤户登录 Web 站点之后，再窃取⽤户的会话标识，会话固定提供的机会多得多。
在⽤户登录之前，攻击的活动部分便已启动。
会话固定攻击过程通常由三个步骤组成：
1) 安装会话
攻击者针对⽬标 Web 站点设下“陷阱会话”，并获取这个会话的标识，攻击者也可以选择攻击中所⽤的任意会话标识。在某些情况下，必须反复联系 Web 站点，才能维护确定好的陷阱会话值。
2) 固定会话
攻击者将陷阱会话值引进⽤户的浏览器中，固定⽤户的会话标识。
3) 进⼊会话
⽤户登录⽬标 Web 站点之后，当使⽤固定会话标识值时，攻击者便可加以接管。”
修改
对于这类问题解决⽅案为在⽤户进⼊登录页⾯时清空session让cookie过期
Cookie cookie = Cookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期
另外⼀种⽅式利⽤JSP的⼀些特性，不让登录页⾯产⽣Session
<% page session=”false” %>
3.2 安全风险及原因分析
⾼风险漏洞，可能会窃取或操纵客户会话和 cookie，它们可能⽤于模仿合法⽤户，从⽽使⿊客能够以该⽤户⾝份查看或变更⽤户记录以及执⾏事务
原因：Web 应⽤程序编程或配置不安全
3.3 AppScan扫描建议
始终⽣成新的会话，供⽤户成功认证时登录。防⽌⽤户操纵会话标识。
请勿接受⽤户浏览器登录时所提供的会话标识
3.4 应⽤程序解决⽅案
会话标识未更新，Appscan给出的描述是建议⽤户每次登录时需使⽤新的会话标识。应⽤程序实现上就是在登录模块，添加以下代码，即⽤户登录后，重新⽣成会话。
HttpSession session = Session(false);
if(session!=null){ //让cookie过期
session.invalidate();
Cookie cookie = Cookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期
}
经过测试，这段代码只在weblogic和tomcat下才有效，在公司中间件webspeed及jboss6.0下问题都依然存在，但从扫描的结果信息分析看，漏洞已经解决，分析判断应该只是session处理机制不同，AppScan⼯具仍认为存在漏洞风险。在与电信沟通中我们存在⼀个经验教训⼤家⼀定要吸取，不能过渡迷信流⾏的⾃动化测试⼯具，尤其是对于Appscan这种判断防御⾏为的复杂软件，仅靠有限的规则设置就当做是web安全的唯⼀标准这显然不太合理，这种情况⼀定要与测试⽅
沟通解释。
另⼀⽅⾯，对于公司的产品webspeed，也想提点建议，商务项⽬采⽤公司的产品为公司节约了不少成本，但是我们产品后续升级维护也必须重视起来，当确认出是webspeed本⾝问题后，联系vasg相关⼈员进⾏协调解决，根本没有⾮常了解该产品技术⼈员⽀持，只是⼀个刚⼊职的同事在配合测试。调试了⼀周时间仍不能解决，最后只能作为⼀个遗留问题搁置。公司⼀直在向产品化转变，但是⾃⾝的产品维护、升级、管理仍然需要改进。
4 已解密登录请求
4.1 已解密登录请求概述
在应⽤程序测试过程中，检测到将未加密的登录请求发送到服务器。由于登录过程所⽤的部分输⼊字段
（例如：⽤户名、密码、电⼦邮件地址、社会保险号码，等等）是个⼈敏感信息，建议通过加密连接（如 SSL）将其发送到服务器。任何以明⽂传给服务器的信息都可能被窃，稍后可⽤来电⼦欺骗⾝份或伪装⽤户。此外，若⼲隐私权法规指出，⽤户凭证之类的敏感信息⼀律以加密⽅式传给⽹站。
4.2 安全风险及原因分析
安全风险中，可能会窃取诸如⽤户名和密码等未经加密即发送了的⽤户登录信息
原因：诸如⽤户名、密码和信⽤卡号之类的敏感输⼊字段未经加密即进⾏了传
递
4.3 AppScan扫描建议
1. 确保所有登录请求都以加密⽅式发送到服务器。
2. 请确保敏感信息，例如：
- ⽤户名
- 密码
- 社会保险号码
- 信⽤卡号码
- 驾照号码
- 电⼦邮件地址
- 电话号码
-
⼀律以加密⽅式传给服务器。
4.4 应⽤程序解决⽅案
已解密的登录请求，要求就是数据要加密传输。最简单有效的解决⽅式采⽤SSL加密协议传输，但是由于EMA服务管理平台业务的特殊性，采⽤SSL加密⽅式对现有的业务影响太⼤，所以最终没有采⽤此种⽅式解决该问题，但个⼈在进⾏测试过程中也尝试在tomcat和jboss下SSL⽅式配置，写下来供参考。
Jboss内核也是tomcat，所以两者配置基本都是⼀样，都是在⽣成证书⽂件后，在l 进⾏配置：
进⼊到cmd 进⼊到jdk bin⽬录下执⾏keytool -genkey -alias tomcat -keyalg RSA -keystore webspeed.keystore ⽣成证书
在l配置SSL
<Connector port="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访问，所以还必须禁⽌普通模式登录。所以还得在l添加配置。
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31<security-constraint>
<!-- Authorization setting for SSL -->
<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>
<!-- Authorization setting for SSL -->
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Client Cert Users-only Area</realm-name>
</login-config>
应注意，由于项⽬的⼀些组件⽆法通过https，因此url-pattern字段只对.jsp和.action进⾏了限制，如果不做特定限制，则系统默认是全部使⽤https传输。⽽且上述设置⼀旦在某个⼯程中出现，那么当前tomcat将全局采⽤这⼀配置。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。