Re: java source code audit

[nmonkee <b0bca7 () bluebottle com>]

Why would you discard SQL injection vulnerabilities?

It is a common belief that Hibernate will protect 100% from SQL injection.  SQL Injection is still possible even when 
using hibernate as an interpreter if certain conditions are true, for example:

If any of the native SQL queries contain and action directly user entered data and if dynamic queries generated by 
Hibernate are not bound to database parameters.  

In addition there are several API’s that are vulnerable to attack and are depreciated in the latest versions of 
Hibernate; 

(Session.iterate(String,..), Session.delete(String,...) and Session.find () are three examples of such API’s. 

Using these API’s can lead to compromise if there is not sufficient input validation.

You should check to ensure that the developers have implemented data validation routines that contain a default deny 
policy and restrict character classes to known good values. 

Single-quotes should be escaped to prevent interpretation and prepared statements should be used in order to prevent 
variables from being interpreted as SQL commands.

Why discard parameter tampering?

Ensure that the application does not rely solely on client-side validation to ensure the data that is expected from the 
browser is valid.  

Ensure that the developers have implemented data validation routines that contain a default deny policy and restrict 
character classes to known good values.

Is the struts framework in use?

One major benefit of the Struts framework is its built-in interface for performing data validations on incoming form 
data. 

If any validations fail, the application redisplays the form so that the invalid data can be corrected. Otherwise, 
processing continues. 

The developers will still have had to write their own validation conditions; however there are many preset types 
available.

Review and investigate the application logic rules that are incorporated into any authorisation controls. 

Ensure that the business rules are being effectively enforced by the application logic. 

Examine all information being (or to be) processed by the application and ensure that the appropriate protection 
requirements have been developed and met.

Get onto google and start doing some research on the language you are dealing with.

Have a read of this article:
http://www.owasp.org/index.php/Trustworthy_Java

Try taking the JAVA practice test here:

http://www.sans-ssi.org/

You need to do a lot of research before tackling the code review IMHO.  Last thing you want to do is give your client 
the confidence that their application is secure; when you may have missed some obvious issues.

Guillermo Caminer wrote:
> Hi list!
> I'm doing a source code audit of a client-server application developed in Java.
> They're using Hibernate, so I'm discarding SQL injection vulnerabilities.
> Because they developed a client of their own instead of using a Web browser, I'm discarding XSS, Parameter tamping, 
> XST, etc...
> Also, they don't have any 'Bad session store' vulnerabilities.
> Finally, because of Java, Buffer overflows are out of the picture.
> My question is: what kind of vulnerability should I check for?
> Thanks in advance!
>
> ------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Need to secure your web apps NOW?
> Cenzic finds more, "real" vulnerabilities fast.
> Click to try it, buy it or download a solution FREE today!
>
> http://www.cenzic.com/downloads
> ------------------------------------------------------------------------


------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------