- Community Home
- >
- Software
- >
- Enterprise Security
- >
- HP Security Research Blog
- >
- File Disclosure == Intellectual Property Exfiltrat...
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
File Disclosure == Intellectual Property Exfiltration
As you already know from my previous blogs, you can expose sensitive information (web.xml, applicationContext.xml, Manifest.mf, db.properties, etc.) or invoke any web executable file (*.jsp, *.asp, *.jspx, *.aspx, *.cshtml, *.vbhtml, etc.) through a File Disclosure vulnerability. This got me thinking about other files/folders under WEB-INF.
With JEE, the WEB-INF directory not only holds your web application configuration files but also your application binaries as *.jar and *.class files (in the “WEB-INF/lib” and “WEB-INF/classes” folders). I hope you see where I am going with this…
Upon my first test (with GlassFish application server), things did not go well. All of my attempts to remotely download application binaries (re: intellectual property) through a File Disclosure vulnerability failed. I let some time pass and discussed the problem with a friend who informed me that other application servers were not as strict and allowed files to be downloaded from the “WEB-INF/lib” and “WEB-INF/classes” directory.
Sure enough, when I tested it out on Tomcat 6.x it worked.
Just for review: a File Disclosure vulnerability looks like:
//Spring MVC and Groovy on Grails
return new ModelAndView( untrustedPathSegmentVar, …);
//Struts 1
return new ActionForward (untrustedPathVar, …);
//In Struts 2 struts.xml file where url is an Action attribute
<result name="success">${url}</result>
//In Struts 2 Action class annotation where url is an Action attribute
@Result(location="${url}")
//Ruby on Rails
render params[“forwardPath”]
//.NET MVC
return View(untrustedPathVar);
//Zend PHP
this -> _forward($untrustedPathVar, …);
//J2EE
<jsp:include path=”untrustedPathVar” />
<jsp:forward page="${param.forward}"/>
RequestDispatcher rd = new RequestDispatcher(untrustedPathVar);
rd.forward()
Here is what it looks like when an attacker can remotely download your application’s binaries.
//forward.jsp
<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>
<jsp:forward page="${param.forward}"/>
Given a file path as pictured:
You can remotely download jar files using the following URL:
http://localhost:8080/examples/forward.jsp?forward
You can even download class files:
http://localhost:8080/examples/forward.jsp?forward
It is true that you are not getting the source, but it is trivially easy to decompile *.class files. You can also glean information about the available *.jar files from the META-INF directory files. Finally, disgruntled insiders can use knowledge of the application to download known *.jar and *.class application files.
So if you see this vulnerability, don’t take it too lightly.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
Excellent post. I was checking continuously this blogs and I’m impressed! Very helpful information specially the remaining part :) I care for such information much. I was looking for this particular info for a long time. Thanks and best of luck.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
Superb post.
I was looking at regularly this blogs and I’m satisfied! Very valuable info specially the remaining part :-) I care for such information much.
I was looking for this unique info for a long time.
Thanks and best of luck.








