Java代码漏洞检测-常见漏洞与修复建议_java 扫描漏洞 不安全的 http 使用情况

背景：

在工作中，项目交付团队在交付项目时，客户方可能会有项目安全要求，会使用一些第三方工具（奇安信等）对项目代码进行扫描，特别是一些对安全性要求比较高的企业，比如涉及到一些证券公司、银行、金融等。他们会在项目上线前进行代码安全检测，通过了对方才会发布上线。

银保等金融类企业信息安全处的安全扫描一般分为五项，主机漏洞，主机基线漏洞，代码检测漏洞，渗透测试漏洞，WEB扫描漏洞，以下漏洞为代码检漏洞.

代码检测常用工具：奇安信代码卫士

跨站脚本

高危：存储型XSS

存储型XSS是指应用程序通过Web请求获取不可信赖的数据，并且在未检验数据是否存在XSS代码的情况下，将其存入数据库。当程序下一次从数据库中获取该数据时，致使页面再次执行XSS代码。存储型XSS可以持续攻击用户，在用户提交了包含XSS代码的数据存储到数据库后，每当用户在浏览网页查询对应数据库中的数据时，那些包含XSS代码的数据就会在服务器解析并加载，当浏览器读到XSS代码后，会当做正常的HTML和JS解析并执行，于是发生存储型XSS攻击。

例如：下面JSP代码片段的功能是根据一个已知用户雇员ID（id）从数据库中查询出该用户的地址，并显示在JSP页面上。

<%

…

Statement stmt = conn.createStatement();

ResultSet rs = stmt.executeQuery(“select * from users where id =” + id);

String address = null;

if (rs != null) {

rs.next();

address = rs.getString(“address”);

}

%>

家庭地址: <%= address %>

如果address的值是由用户提供的，且存入数据库时没有进行合理的校验，那么攻击者就可以利用上面的代码进行存储型XSS攻击。

修复建议

为了避免存储型XSS攻击，建议采用以下方式进行防御：

1.对从数据库或其它后端数据存储获取不可信赖的数据进行合理验证（如年龄只能是数字），对特殊字符（如<、>、'、"以及<script>、javascript等进行过滤。

2.根据数据将要置于HTML上下文中的不同位置（HTML标签、HTML属性、JavaScript脚本、CSS、URL），对所有不可信数据进行恰当的输出编码。

例如：采用OWASP ESAPI对数据输出HTML上下文中不同位置，编码方法如下。

//HTML encode

ESAPI.encoder().encodeForHTML(inputData);

//HTML attribute encode

ESAPI.encoder().encodeForHTMLAttribute(inputData);

//JavaScript encode

ESAPI.encoder().encodeForJavaScript(inputData);

//CSS encode

ESAPI.encoder().encodeForCSS(inputData);

//URL encode

ESAPI.encoder().encodeForURL(inputData);

3.设置HttpOnly属性，避免攻击者利用跨站脚本漏洞进行Cookie劫持攻击。在Java EE中，给Cookie添加HttpOnly的代码如下：

response.setHeader(“Set-Cookie”,“cookiename=cookievalue; path=/;
Domain=domainvaule; Max-age=seconds; HttpOnly”);

Cookie属性

Name：Cookie名

Value：Cookie值

Domain：Cookie的域。如果设成.test.com，那么子域名a.test.com和b.test.com，都可以使用.test.com的Cookie。

Path：Cookie的路径。如果设成/path/，则只有路径为/path/的页面可以访问该Cookie。如果设为/，则本域名下的所有页面都可以访问该Cookie。

Expires / Max-
Age：Cookie的超时时间。若设置其值为一个时间，那么当到达此时间后，此Cookie失效。不设置的话默认值是Session，意思是Cookie会和Session一起失效。当浏览器关闭（不是浏览器标签页，而是整个浏览器）后，此Cookie失效。

Size：Cookie大小。

HttpOnly：若此属性为true，则只有在http请求头中会带有此Cookie的信息，而不能通过document.cookie来访问此Cookie。

Secure：设置是否只能通过https来传递此条Cookie。

SameSite：用来防止 CSRF 攻击和用户追踪。可以设置三个值：Strict、Lax 和 None。

Strict：Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL
与请求目标一致，才会带上 Cookie。

Lax：Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。

None：关闭SameSite属性，提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

Priority：优先级。定义了三种优先级，Low/Medium/High，当Cookie数量超出时，低优先级的Cookie会被优先清除。

高危：反射型XSS

反射型XSS是指应用程序通过Web请求获取不可信赖的数据，并在未检验数据是否存在恶意代码的情况下，将其发送给用户。反射型XSS一般可以由攻击者构造带有恶意代码参数的URL来实现，在构造的URL地址被打开后，其中包含的恶意代码参数被浏览器解析和执行。这种攻击的特点是非持久化，必须用户点击包含恶意代码参数的链接时才会触发。

例如：下面JSP代码片段的功能是从HTTP请求中读取输入的用户名(username)并显示到页面。

<%String name= request.getParameter(“username”); %>

姓名: <%= name%>

修复建议

如果name里有包含恶意代码，那么Web浏览器就会像显示HTTP响应那样执行该代码，应用程序将受到反射型XSS攻击。

为了避免反射型XSS攻击，建议采用以下方式进行防御：

1.对用户的输入进行合理验证（如年龄只能是数字），对特殊字符（如<、>、'、"以及<script>、javascript等进行过滤。

2.根据数据将要置于HTML上下文中的不同位置（HTML标签、HTML属性、JavaScript脚本、CSS、URL），对所有不可信数据进行恰当的输出编码。

例如：采用OWASP ESAPI对数据输出HTML上下文中不同位置，编码方法如下。

//HTML encode

ESAPI.encoder().encodeForHTML(inputData);

//HTML attribute encode

ESAPI.encoder().encodeForHTMLAttribute(inputData);

//JavaScript encode

ESAPI.encoder().encodeForJavaScript(inputData);

//CSS encode

ESAPI.encoder().encodeForCSS(inputData);

//URL encode

ESAPI.encoder().encodeForURL(inputData);

3.设置HttpOnly属性，避免攻击者利用跨站脚本漏洞进行Cookie劫持攻击。在Java EE中，给Cookie添加HttpOnly的代码如下：

response.setHeader(“Set-Cookie”,“cookiename=cookievalue; path=/;
Domain=domainvaule; Max-age=seconds; HttpOnly”);

Cookie属性

Name：Cookie名

Value：Cookie值

Domain：Cookie的域。如果设成.test.com，那么子域名a.test.com和b.test.com，都可以使用.test.com的Cookie。

Path：Cookie的路径。如果设成/path/，则只有路径为/path/的页面可以访问该Cookie。如果设为/，则本域名下的所有页面都可以访问该Cookie。

Expires / Max-
Age：Cookie的超时时间。若设置其值为一个时间，那么当到达此时间后，此Cookie失效。不设置的话默认值是Session，意思是Cookie会和Session一起失效。当浏览器关闭（不是浏览器标签页，而是整个浏览器）后，此Cookie失效。

Size：Cookie大小。

HttpOnly：若此属性为true，则只有在http请求头中会带有此Cookie的信息，而不能通过document.cookie来访问此Cookie。

Secure：设置是否只能通过https来传递此条Cookie。

SameSite：用来防止 CSRF 攻击和用户追踪。可以设置三个值：Strict、Lax 和 None。

Strict：Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL
与请求目标一致，才会带上 Cookie。

Lax：Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。

None：关闭SameSite属性，提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

Priority：优先级。定义了三种优先级，Low/Medium/High，当Cookie数量超出时，低优先级的Cookie会被优先清除。

输入验证

高危：路径遍历

应用程序对用户可控制的输入未经合理校验，就传送给一个文件API。攻击者可能会使用一些特殊的字符（如..和/）摆脱受保护的限制，访问一些受保护的文件或目录。

例如：下面代码片段通过验证输入路径是否以/safe_dir/为开头，来判断是否进行创建、删除操作。

String path = getInputPath();

if (path.startsWith(“/safe_dir/”)){

File f = new File(path);

f.delete()

}

攻击者可能提供类似下面的输入：

/safe_dir/../important.dat

程序假定路径是有效的，因为它是以/safe_dir/开头的，但是../将导致程序删除important.dat文件的父目录。

修复建议

预防路径遍历的威胁，有以下三种方法：

1. 程序对非受信的用户输入做过滤和验证，对网站用户提交的文件路径进行硬编码或统一编码，过滤非法字符。

2. 对文件后缀进行白名单控制，拒绝包含了恶意的符号或空字节。

3. 合理配置Web服务器的目录访问权限。

高危：基于DOM的XSS [NodeJS]

应用程序的客户端代码从

document.location

request.url

document.URL

document.referrer

或其他任何攻击者可以修改的浏览器对象获取数据，如果未验证数据是否存在恶意代码的情况下，就将其动态更新到页面的DOM节点,应用程序将易于受到基于DOM的XSS攻击。

例如：下面的JavaScript代码片段可从URL中读取msg信息，并将其显示给用户。

var url=document.URL;

document.write(url.substring(url.indexOf(“msg=”)+4,url.length);

该段脚本解析URL，读取msg参数的值，并将其写入页面。如果攻击者设计一个恶意的URL，并以JavaScript代码作为msg参数，那么Web浏览器就会像显示HTTP响应那样执行该代码，应用程序将受到基于DOM的XSS攻击。

修复建议

基于DOM的XSS是将用户可控的JavaScript数据输出到HTML页面中而产生的漏洞，为了避免基于DOM的XSS攻击，避免将用户控制的数据直接输出到DOM或脚本中执行。如果不能避免，则应进行严格的过滤。

高危：重定向 [ Java]

重定向漏洞解决方案：Java中的URL重定向漏洞和防范方法-java教程-
PHP中文网

应用程序允许未验证的用户输入控制重定向中的URL,攻击通过构建URL，使用户重定向到任意URL，利用这个漏洞可以诱使用户访问某个页面，挂马、密码记录、下载任意文件等，常被用来钓鱼。

例如：以下Servlet代码会接收前台的url参数，然后Servlet进行一系列业务操作后重定向到该链接，一般情况下这个链接可能是默认的，例如登陆处登陆成功后跳到首页，但是这种情况没有限制用户输入自定义的链接。

public class RedirectServlet extends HttpServlet {

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException,IOException{

...

String query = request.getQueryString();

if (query.contains("url")) {

String url = request.getParameter("url");

response.sendRedirect(url);

}

}

}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

常见的场景是受害者收到一封电子邮件，指示该用户打开http://trusted.example.com/ecommerce/redirect.asp?url=www.wilyhacker.com链接，用户有可能会打开该链接，因为他会认为这个链接将转到可信赖的站点。然而，一旦用户打开该链接，上面的代码会将浏览器重定向至http://www.wilyhacker.com。很多用户都被告知，要始终监视通过电子邮件收到的URL，以确保链接指向一个他们所熟知的可信赖站点。尽管如此，如果攻击者对目标URL进行16进制编码：http://trusted.example.com/ecommerce/redirect.asp?url=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D以提高用户辨别URL的难度。更糟糕的是像这样的url通过例如QQ等程序进行传输的时候，这些程序的安全机制是不能识别url参数中的危险链接的。

修复建议

防止重定向漏洞的方法是创建一份合法URL列表，用户只能从中进行选择，进行重定向操作。

例如：以下Servlet代码先对url进行判断，再决定是否重定向到该链接。

public class RedirectServlet extends HttpServlet {

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException,IOException{

...

String query = request.getQueryString();

if (query.contains("url")) {

String url = request.getParameter("url");

if(safeUrls.contains(url)){

response.sendRedirect(url);

}

...

}

}

}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

高危：重定向 [NodeJS]

应用程序允许未验证的用户输入控制重定向中的URL,可能会导致攻击者发动钓鱼攻击。

例1：以下JavaScript代码从用户输入表单的dest参数中读取目的URL，然后在新窗口中打开。

dsturl = myForm.dsturl.value;

window.open(dsturl,“newwin”);

假如攻击者可以控制这个表单，那么用户就有可能打开一个恶意站点。

例2：以下是Node.js可能出现的。

var express = require(‘express’);

var app = express();

app.get(‘/’, function (req, res) {

res.redirect(req.url);

});

与例1一样假如攻击者控制了这个url，那么就会导致用户可能打开恶意站点。

修复建议

js和Node.js都要避免采用不可信数据源的数据来构造重定向的URL，如果业务逻辑需要涉及到用户输入，那么就创建一份合法URL列表，用户只能从中进行选择，进行重定向操作。

例如：以下代码中，用户只能输入数字来选择URL。

dst = myForm.dst.value;

if(dst == “1”){

dsturl = “http://www.1.com”

}else if(dst == “2”){

dsturl = “http://www.2.com”

}else{

dsturl = “http://www.3.com”

}

window.open(dsturl,“newwin”);

中危： HTTP参数污染[Java]

HTTP参数污染(HPP)攻击根据HTTP协议中允许同名参数出现多次，如果程序没有正确地检查用户输入，攻击者可以在传输参数的时候传输key相同而value不同的参数，从而达到绕过某些防护与参数校验。

如果向Web应用程序提交参数，并且如果这些参数与现有参数的名称相同，Web应用程序可能会有下列一种反应：Web程序可能从第一个参数或最后一个参数提取数据，也可能从所有参数中获取数据并连接起来。

下面这个表格列举了一些常见的Web服务器对同样名称的参数出现多次的处理方式：

|Web服务器|获取的参数|

|:-