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

Difference between revisions of "Talk:Query Parameterization Cheat Sheet"

From OWASP
Jump to: navigation, search
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
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.
 +
 +
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.
 +
 +
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
 
Hi Jim
  
−
I don't know "bind" my variables  
+
I don't know the meaning of "bind" my variables  
  
 
I have query very long.
 
I have query very long.
  
 
Ex.
 
Ex.
−
 
−
try{
 
  
 
StringBuffer buf = new StringBuffer();
 
StringBuffer buf = new StringBuffer();
Line 16: Line 85:
  
 
buf.append("WHERE ID = ? ");
 
buf.append("WHERE ID = ? ");
−
+
 
 
PreparedStatement ps = null;
 
PreparedStatement ps = null;
 +
 
ResultSet rs = null;
 
ResultSet rs = null;
−
+
 
 
try {
 
try {
 
   ps = conn.prepareStatement(buf.toString());
 
   ps = conn.prepareStatement(buf.toString());

Latest revision as of 16:44, 24 November 2014

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.

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.

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.

Ex.

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

the request

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

command=search&parameter1=&parameter2=&parameter3=&parameter4=&parameter5=&parameter6=&parameter7=


The test signalize the security bug.

I used to solve the problem with a filter

http://antisqlfilter.sourceforge.net/howto.html

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.

http://ricardozuasti.com/2012/stronger-anti-cross-site-scripting-xss-filter-for-java-web-apps/

And when repeat the pen test I haven't the XSS problem.

HTTP Response Splitting

For fix this problem I use this filter: HttpResponseSplittingPreventionFilter

http://mail-archives.apache.org/mod_mbox/tomcat-users/201104.mbox/%[email protected]%3E


Path Manipulation

For fix this problem I write a filter inspired by this article:

http://stackoverflow.com/questions/9745896/fixing-path-manipulation-error

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

Retrieved from "https://wiki.owasp.org/index.php?title=Talk:Query_Parameterization_Cheat_Sheet&oldid=185827"