aspose file tools*
The moose likes Security and the fly likes Application level security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Application level security " Watch "Application level security " New topic
Author

Application level security

naga eswar
Ranch Hand

Joined: Jan 25, 2012
Posts: 120
Hi all,

Recently application security audit has done by my client to our application and suggested some changes for improving application level security .
He mentioned below problems. Now we have to handle.
I am new to this security problems. Can any body help me.

We are using EJB 2.0, Webshpere 6.1, Oracle 10G, Java 1.4


Malicious File upload
Cross Site Scripting
Privilege Escalation
Password complexity not followed
Auto complete password
Non-secure cookie attributes

Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

Cannot answer this because you give no details and each of those things you have listed is a large subject in itself. Starting with Malicious file upload, you will have to give more details:

what are the file upload requirements?
what is the functionality you delivered? How did you implement file upload?
what specifically did the security audit say about what was wrong with it?
After reading about malicious file uploads, (https://www.owasp.org/index.php/Unrestricted_File_Upload) what don't you understand?
what have you tried so far to fix it and what specifically do you need help with?
naga eswar
Ranch Hand

Joined: Jan 25, 2012
Posts: 120
Thanks Tim,

nice questions you raised. Once I analys and get back to you.


naga eswar
Ranch Hand

Joined: Jan 25, 2012
Posts: 120

Let me explain one by one given audit team.

Malicious File upload : A malicious user (authenticated) might try to upload an executable and gain access to application‟s underlying operating system. Then, he might perform actions like accessing the sensitive business data, web config files, other user‟s profile data etc.

Cross Site Scripting : It was found that sensitive information (like credit card number, bank account number etc.) could be browsed by directly accessing affected URLs without authentication. These URLs could be easily located by using well known open source utilities. Once discovered, these URLs could be browsed to access sensitive data.

Privilege Escalation : It was observed that application does not implement proper authorization of various user roles. It was possible to manipulate certain parameters and perform administrative functions through normal user session.


Non-secure cookie attributes : It was observed that most of applications do not enforce setting of security of authentication and session cookie. The same can be implemented by setting „HTTPonly‟ and „secure‟ cookie flags during authentication.




Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39548
    
  27
Using Java 1.4 is also a problem - it hasn't received security updates for years. You should update to (at least) Java 6 ASAP.

Also -with all due respect- if you're new to security issues, then you may not be the best person to implement this. Security is notoriously easy to get wrong (and thus end up with an insecure system). Here's some more stuff to look into while you're at it: https://www.coderanch.com/how-to/java/SecurityFaq#web-apps


Ping & DNS - updated with new look and Ping home screen widget
naga eswar
Ranch Hand

Joined: Jan 25, 2012
Posts: 120

Thank you very much Ulf Dittmer


Ulf Dittmer wrote:Using Java 1.4 is also a problem - it hasn't received security updates for years. You should update to (at least) Java 6 ASAP.


This version was provided by client. Its under the control of client. Business wont accept.

Here's some more stuff to look into while you're at it: https://www.coderanch.com/how-to/java/SecurityFaq#web-apps


Once gain thank you for giving this stuff. I will go through this.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39548
    
  27
Using Java 1.4 is also a problem - it hasn't received security updates for years. You should update to (at least) Java 6 ASAP.
This version was provided by client. Its under the control of client. Business wont accept.

OK, these things happen. But you need to make it clear to the customer that that is a big security risk in itself, possibly larger than some of the ones you're trying to address.
naga eswar
Ranch Hand

Joined: Jan 25, 2012
Posts: 120
We are working as per below. Please help me if I am doing any wrong


Malicious File upload : A malicious user (authenticated) might try to upload an executable and gain access to application‟s underlying operating system. Then, he might perform actions like accessing the sensitive business data, web config files, other user‟s profile data etc.

Solution: After uploading every file, we will check the extensions of file then only, we will allow to upload because .exe files are main concer to explore virus.


Cross Site Scripting : It was found that sensitive information (like credit card number, bank account number etc.) could be browsed by directly accessing affected URLs without authentication. These URLs could be easily located by using well known open source utilities. Once discovered, these URLs could be browsed to access sensitive data.

Solution: handling special characters at client side done. Now we are integrating server side validations also.

Privilege Escalation : It was observed that application does not implement proper authorization of various user roles. It was possible to manipulate certain parameters and perform administrative functions through normal user session.

Solution: handling the authorization of various user roles for every screen .


Non-secure cookie attributes : It was observed that most of applications do not enforce setting of security of authentication and session cookie. The same can be implemented by setting "HTTPonly‟ and „secure‟ cookie flags during authentication.

Solution: We are using "HTTPonly‟ as per https://www.owasp.org/index.php/HttpOnly

Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

naga eswar wrote:We are working as per below. Please help me if I am doing any wrong


Non-secure cookie attributes : It was observed that most of applications do not enforce setting of security of authentication and session cookie. The same can be implemented by setting "HTTPonly‟ and „secure‟ cookie flags during authentication.

Solution: We are using "HTTPonly‟ as per https://www.owasp.org/index.php/HttpOnly



the advice says "HTTPonly" AND "secure" HTTPonly only protects the cookie from being accessed and stolen by a script in the client. I don't know the requirements of the application and I don't know if you are using https (if the data is sensitive, you should be). by setting the "secure" flag, you only allow that cookie to be sent in a secure channel (https) so that it cannot be read by a third party via side-jacking, man-in-the-middle, etc.

If you are not using https, can you explain why not?
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

naga eswar wrote:We are working as per below. Please help me if I am doing any wrong


Malicious File upload : A malicious user (authenticated) might try to upload an executable and gain access to application‟s underlying operating system. Then, he might perform actions like accessing the sensitive business data, web config files, other user‟s profile data etc.

Solution: After uploading every file, we will check the extensions of file then only, we will allow to upload because .exe files are main concer to explore virus.



NO! NO! checking the extension cannot prove that the file is not malicous. There are many ways to bypass this. Same goes for content header. (and you should be concerned with more than just .exe)

please read this for a start to understanding:
https://www.owasp.org/index.php/Unrestricted_File_Upload
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

naga eswar wrote:We are working as per below. Please help me if I am doing any wrong

Cross Site Scripting : It was found that sensitive information (like credit card number, bank account number etc.) could be browsed by directly accessing affected URLs without authentication. These URLs could be easily located by using well known open source utilities. Once discovered, these URLs could be browsed to access sensitive data.

Solution: handling special characters at client side done. Now we are integrating server side validations also.



You should ask them to clarify this because it appears that two different security issues are being confused here. "could be browsed by directly accessing affected URLs without authentication " means the application is vulnerable to forced browsing and this does not have much to do with handling special characters. It means that you can type a URL directly into the browser address bar and get to a web page that you should not be able to get to. You have to implement some kind of site-wide protection against access to these URLs

Cross Site Scripting is a different issue that must be addressed by filtering request parameters. I need to ask exactly how are you handling special characters?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18135
    
    8

Tim McGuire wrote:I need to ask exactly how are you handling special characters?


I often find that when somebody uses the phrase "special characters", that's a tip-off that they don't know the actual terminology for the field they are talking about, or they don't understand the issue being addressed.
naga eswar
Ranch Hand

Joined: Jan 25, 2012
Posts: 120
Thank you Tim and paul


Tim McGuire wrote: the advice says "HTTPonly" AND "secure" HTTPonly only protects the cookie from being accessed and stolen by a script in the client.


Can you please explain regarding "secure" flag. As per audit suggestion, setting the session header as "HTTPonly" is enough.



Tim McGuire wrote:NO! NO! checking the extension cannot prove that the file is not malicous. There are many ways to bypass this. Same goes for content header. (and you should be concerned with more than just .exe)


Its the basic thing to check the extension while uploading a file. thanks for your link we will check and follow accordingly.



Tim McGuire wrote:Cross Site Scripting is a different issue that must be addressed by filtering request parameters. I need to ask exactly how are you handling special characters?


As per audit, we are validating the attributes at client side but not at server side. The hacker may come in the middle of client and server side and run the script. So if we validate at server side also (same validation done at client side) then we can restrict some special characters (if a sql query is executed in the script) at server side also. Regarding the filters below is the code to stop browsing by directly accessing. Please let me know is anything wrong.







Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18135
    
    8

Are you sure you posted the correct filter? Because the filter you posted only makes sure that the encoding for requests and responses will default to UTF-8. It doesn't validate anything and it doesn't prevent any characters, "special" or otherwise, from being in a request or a response. Perhaps you actually have another filter which does those things, and you accidentally chose the wrong one to post?
naga eswar
Ranch Hand

Joined: Jan 25, 2012
Posts: 120
Thank you paul,

this filter only encodes requests and responses. We are thinking to vaidate separately for special character at server side.
Now my question is that, is encoding the request and response helps in security point of view ?

Some where I have studied that we can use regular expression in filters to validate inputs. Can you please tell me about regular expression.
I dont know at all regarding regular expression.

Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

naga eswar wrote:Thank you paul,

this filter only encodes requests and responses. We are thinking to vaidate separately for special character at server side.
Now my question is that, is encoding the request and response helps in security point of view ?

Some where I have studied that we can use regular expression in filters to validate inputs. Can you please tell me about regular expression.
I dont know at all regarding regular expression.



I recommend against trying to do it yourself. This problem has been solved by third party libraries such as OWASPs Enterprise Security API (ESAPI). It would be difficult to do it as well as they did.

https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

naga eswar wrote:
Tim McGuire wrote: the advice says "HTTPonly" AND "secure" HTTPonly only protects the cookie from being accessed and stolen by a script in the client.


Can you please explain regarding "secure" flag. As per audit suggestion, setting the session header as "HTTPonly" is enough.



the audit suggestion you posted here,


Non-secure cookie attributes : It was observed that most of applications do not enforce setting of security of authentication and session cookie. The same can be implemented by setting "HTTPonly‟ and „secure‟ cookie flags during authentication.
The way I read that, it is saying please do both HttpOnly AND Secure. it says "and" instead of "or". I think if they care about capturing the authentication and session cookie on the client, then they probably care about capturing it via Man-in-the-middle or side-jacking attacks as well.

If you do not set the secure flag, then session cookie might get sent unencrypted.
If cookie is sent unencrypted, it may be captured by a man-in-the-middle
if cookie is captured, it can be used to impersonate user.

Further Reading: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
Kancharla Madhu
Ranch Hand

Joined: May 06, 2012
Posts: 109

There is one more issue if you guys still stick to Java 1.4 - DOS(Denial Of Service)!,If you don't use JDK1.6U24 or later and Your using code like this then your application is subjected to DOS or


Champions aren´t made in the gyms. Champions are made from something they have deep inside them - a DESIRE, a DREAM, a VISION
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Application level security
 
Similar Threads
encryption software
security Implementation
Security and Performance
Security - Screen level vs Data element level
Securing Web Services