False positive SQL injection by adding %-char to URL?

[code...@gmail.com]

I can't understand some of the SQL injection tests, that my OWASP ZAP 2.7.0 is constantly alerting about. It looks like ZAP adds URL encoded %-char to my URL. Excerpt from report:

High (Medium)	SQL Injection
Description	SQL injection may be possible.
URL	https://test-target.domain.com/exx/javax.faces.resource%25/components.css.jsf?ln=primefaces&v=6.1
Method	GET
Parameter	javax.faces.resource
Attack	javax.faces.resource%

...

Other information

The page results were successfully manipulated using the boolean conditions [javax.faces.resource%] and [javax.faces.resourceXYZABCDEFGHIJ] The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison Data was returned for the original parameter. The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter

I would understand, that if you inject a %-char at the end of a parameter, which is used in SQL-query, you could modify query results. Is this what ZAP is trying to accomplish? However in this case:

• % -char is added to a server directory path in URL, not to any SQL query parameter.
• What is the boolean conditions, ZAP is telling about (firs line of the above other information)?
• If I try to access above URL with or without %-char on my browser, I get exactly same results. 
• If I access https://test-target.domain.com/exx/javax.faces.resourceXYZABCDEFGHIJ/components.css.jsf?ln=primefaces&v=6.1, I get empty page, as expected.

To me, nothing here looks like any SQL injection vulnerability or even anything related to testing SQL-queries.

Could someone please explain what ZAP is doing here, thank you!

[kingthorin+owaspzap]

Could be a few things going in here. Likely part of the path was built based on an injected parameter, or in your scan you had URL path selected as one of the injection points (variants).

It’s possible that it’s a false positive, you can always mark it as such manually or setup a Context Alert Filter for future occurrences, if you’ve validated it’s an FP.

As for explaining ZAP’s exact behaviour, without access to the system/finding all we can really offer is for you to look at the code of the particular scan rule. (I can dig up the github link if you like.)

[code...@gmail.com]

I have certainly selected URL path as one of the injection points. However, I would have expected only relevant injections to the URL. I could take a look of the code, if you provide the link. although it may be difficult to understand logic and purpose of the scan just from the code.

[kingthorin+owaspzap]

Some apps do parse URL path components for param values. Consider a path such as /some/catalog/4/item/53/

Code Linkage:

https://github.com/zaproxy/zap-extensions/blob/master/src/org/zaproxy/zap/extension/ascanrules/TestSQLInjection.java

[code...@gmail.com]

Thank's for the code link. I think the logic is failing how %-char injection is tested.

Fundamental failure is to include %-char injection strings (//attack for SQL LIKE statements) (lines 347-349 and  362-364) to the same SQL_LOGIC_AND_TRUE array of Strings than SQL boolean logic conditions injection strings. Test for SQL LIKE statement should be written differently than test for SQL boolean logic conditions, so the injection strings should be defined in different variables.

Test concludes that, if injecting logical true gives the same result with original page (line 840) and injecting logical false gives different result (line 869), there is a vulnerability. This is valid reasoning for logical conditions, but not for SQL like statements. In my case adding %-sign gave same result with original value, beacause %-sign was ignored and injecting XYZABCDEFGHIJ resulted to empty page, because server didn't have such a directory. 

If the injected string had been added to a variable,  which is used in SQL where statement, what could be valid test logic? I think basic scenario is such, that injecting % should give bigger result (more matching rows) than the original query. Injecting XYZABCDEFGHIJ should give smaller result, less (0) matching rows. Of course this is not always true. For example if 'not' is used is where-statement.

[Simon Bennetts]

PRs always appreciated, especially with improved tests :)