From: nmonkee (b0bca7@bluebottle.com)
Date: Thu Oct 04 2007 - 14:07:45 EDT
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:
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
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:08 EDT