Talk:Query Parameterization Cheat Sheet
Mario 24/11/2014 14:40:00 ( dd/mm/yyyy HH:mm:ss ):
Sorry Jim, but also Firebugs signalize false positive for SQL Injection
Mario 24/11/2014 10:10:00 ( dd/mm/yyyy HH:mm:ss ):
I test my web app with Findbugs Gui and work fine. It report no bugs vulnerability with PreparedStatement and binding parameter and report bugs vulnerability with PreparedStatement without binding parameter.
Findbugs comment for PreparedStatement without binding parameter
Nonconstant string passed to execute method on an SQL statement The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.
Bug kind and pattern: SQL - SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE
Though Findbugs report to me unless error comparison of CodePro Analytics and OWASP Lapse+.
Findbugs don't report the bug vulnerability signalize from PenTester.
Though I fixed all bugs reported by findbugs.
For the "false-positive", I don't know as report this bug to the LAPSE project directly. I'm going in the page signalize by you. But don't found nothing to signalize bug. If you want to tell him you.
Thank Jim Have a nice day
JIM 11/21/14 :
All tools make mistake. This might be a "false-positive". You might want to report this potential bug to the LAPSE project directly. https://www.owasp.org/index.php/OWASP_LAPSE_Project
Also, try http://findbugs.sourceforge.net/ and let me know if you get the same problem.
OWASP Lapse+ signalize this as SQL Injection, unfortunately
in this row: ps = conn.prepareStatement(buf.toString());
I don't understand
JIM 11/21/14 :
Yes, the ? and the setLong functions are the variable binding. That is what gives you the security in preventing SQL Injection.
These two functions....
buf.append("WHERE ID = ? "); ps.setLong(1, id);
I don't know the meaning of "bind" my variables
I have query very long.
StringBuffer buf = new StringBuffer();
buf.append("SELECT * ");
buf.append("FROM TABLE ");
buf.append("WHERE ID = ? ");
PreparedStatement ps = null;
ResultSet rs = null;
ps = conn.prepareStatement(buf.toString()); ps.setLong(1, id); rs = ps.executeQuery();
JIM 11/21/14 : It's not just a matter of using the PreparedStatement class, you also need to "bind" all your variables.
I use OWASP Lapse+ and CodePro Analitycs for code audit my Java Web App.
In the audit signalize
1) SQL Injection
2) Cross Site Scripting
3) Avoid Building Queries From User Input
4) HTTP Response Splitting
5) Path Manipulation
6) Request Parameters In Session
(1) SQL Injection - (3) Avoid Building Queries From User Input
For this bugs I have remove Statement class and put PreparedStatement Class as you indicated, but OWASP Lapse+ continue signalize bug security SQL Injection whereas Code Pro Analytics not signalize bug.
Indeed when I did the pen test went wrong.
I did pen test with SQLMAP and Burp Suite.
With Burp Suite I have take the request and I have execute SQLMAP on windows as:
python ./sqlmap.py -r test.txt -p parameter3 --dbms=oracle --users x y z t
POST /SoftwareComposer/SoftwareComposerSearchServlet HTTP/1.1 Host: myapp.mydomain.com:9080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Referer: http://myapp.mydomain.com:9080/SoftwareComposer/SoftwareComposerSearchServlet Cookie: JSESSIONID=0000lIqbat_ue4tPrUpzPv_pp7m:-1 Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 410
The test signalize the security bug.
I used to solve the problem with a filter
I configured AntiSQLFilter in my WebApp and I have repeat the penetration test overcoming.
The filter validate all my input parameter and if they aren't right signalize the bug.
Cross Site Scripting
My Web App suffers of XSS bug as signalize OWASP Laspe+ and CodePro Analytics
For to fix the problem I use this filter XSSFilter.
And when repeat the pen test I haven't the XSS problem.
HTTP Response Splitting
For fix this problem I use this filter: HttpResponseSplittingPreventionFilter
For fix this problem I write a filter inspired by this article:
Request Parameters In Session
I have not solved this bug
I have removed the information from the session
help me to improve the safety of my web app