We help IT Professionals succeed at work.

How do I prevent access to JBoss configuration files?

795 Views
Last Modified: 2012-06-21
The company I work for has an application that allows users to view files (PDF's etc).  There is a bug in it that our security audit discovered that allows someone to enter something like ../../datasource-ds.xml   and view the contents of the config files.

This is being fixed by our developers, but I'd like to make sure that the vulnerability doesn't exist in some other way.  How can I lock down the conf and deploy directories so that no one else can do this?  I'm still relatively new to JBoss and could use some help locking things down.

Would putting an .htaccess file in the conf and deploy directories be enough to keep people out of them without impacting application functionality?  

Any suggestions would be appreciated.
Comment
Watch Question

btanExec Consultant
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
I see it as protecting SOA type. See this article that sums up in general security approach
@ http://soa.sys-con.com/node/232071

For example, this is one real vulnerability due to no authentication, no password or default password in console and mgmt. Actually applicable for other domain in network and web services
@ http://www.articlesbase.com/security-articles/exploitation-and-remediation-of-jboss-application-server-default-configuration-vulnerability-1889469.html

For .htaccess file, I understand that only the lowest .htaccess file along the path affects access; clients can skip over protected directories if they know the URL to lesser protected directories below there. But it is better than direct access w/o authentication. Need to plan for segregation based on the risk appetite of the files or document. In general top level directories are left public and have no ".htaccess" file, while some lower directories might be restricted. Two level of protection might be employed, for example there might be a set of documents that is protected for specific group of hosts only, with one subdirectory inside that also requiring a password to be supplied, to further limit access.

Not full proof though but layer of defense should be in place to secure the appl server as in the article shared above.

Application wise, if possible, should relook at establishing deployment roles to define the logical security view of an application. Only authenticated groups should have access and have audit enabled to track. See 8.1.3 (ref link
Ref: http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch8.chapter.html) for a start.
btanExec Consultant
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
This link would be of interest, related to the roles and authentication/authorisation mentioned
@ http://www.packtpub.com/article/user-security-access-control-in-jboss-portals

Author

Commented:
The authentication, and default passwords have already been changed.  This was primarily a concern about protecting the JBoss config files from being accessible.  

The primary cause of their accessibility was a lack of security logic in the servlet, but it started me thinking about someone being able to gain access to the config files in other ways.  I wanted to lock things down as best I could.  

It wasn't exactly the answer I was looking for, but thank you for the articles.  They were helpful in verifying what I'd already done. :)
Exec Consultant
CERTIFIED EXPERT
Distinguished Expert 2019
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Author

Commented:
Wasn't really the solution I was looking for, but you get the points for the effort. :)

Author

Commented:
Wasn't exactly the solution I was looking for.
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.