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
Line 2: Line 2:
  
 
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
 
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,
 
Aloha,

Revision as of 16:58, 21 November 2014

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