This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Talk:Query Parameterization Cheat Sheet

Jump to: navigation, search

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 ):

Hi Jim

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.


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.

Also, try and let me know if you get the same problem.

Aloha, Jim

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);

Aloha, Jim

Hi Jim

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;

try {

 ps = conn.prepareStatement(buf.toString());
 ps.setLong(1, id);
 rs = ps.executeQuery();

It's correct?

JIM 11/21/14 : It's not just a matter of using the PreparedStatement class, you also need to "bind" all your variables.

Aloha, Jim

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 ./ -r test.txt -p parameter3 --dbms=oracle --users x y z t

the request

POST /SoftwareComposer/SoftwareComposerSearchServlet HTTP/1.1 Host: 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: 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

I test the bug with Burp Suite. I send request to Burp Repeater and put <script>alert(XSS)</script> in a parameter and when return on web app signalize to me javascript alert.

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[email protected]%3E

Path Manipulation

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