当前位置:   article > 正文

Java代码漏洞检测-常见漏洞与修复建议

Java代码漏洞检测-常见漏洞与修复建议

背景:

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

银保等金融类企业信息安全处的安全扫描一般分为五项,主机漏洞,主机基线漏洞,代码检测漏洞,渗透测试漏洞,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服务器|获取的参数|

|:-

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/很楠不爱3/article/detail/150611
推荐阅读
相关标签