3

Orginal Post IBM AppScan

We recently received result from IBM AppScan DAST and some of the result don't make much senses.

High -- Blind SQL Injection (Time Based)

Parameter: form:propertyTree:0:j_idt126
Risk(s): It is possible to view, modify or delete database entries and tables
Fix: Review possible solutions for hazardous character injection

Image

2nd case for Blind SQL Injection (Time Based)

URL: https://***/javax.faces.resource/components.js.xhtml
Parameter: v
Risk(s): It is possible to view, modify or delete database entries and tables
Fix: Review possible solutions for hazardous character injection

The following changes were applied to the original request:
- Set the value of the parameter 'v' to '7.0.9%27+where+sleep%280%29%3D0+--+'
- Set the value of the parameter 'v' to '7.0.9%27+where+sleep%28181%29%3D0+limit+1+--+'
- Set the value of the parameter 'v' to '7.0.9%27+where+sleep%280%29%3D0+--+'

Reasoning:
The first and third test responses were timed out and the second test response was received
normally

Reasoning: The first and third test responses were timed out and the second test response was received normally

3rd case for Blind SQL Injection (Time Based)

URL: https:/**/externalcasestart.xhtml
Parameter: javax.faces.source
Risk(s): It is possible to view, modify or delete database entries and tables
Fix: Review possible solutions for hazardous character injection

The following changes were applied to the original request:
- Set the value of the parameter 'javax.faces.source' to
'form%3AmainGridBodyTable+and+sleep%280%29'
- Set the value of the parameter 'javax.faces.source' to
'form%3AmainGridBodyTable+and+1%3D2+or+sleep%28181%29%3D0+limit+1+--+'
- Set the value of the parameter 'javax.faces.source' to
'form%3AmainGridBodyTable+and+sleep%280%29'
Reasoning:
The first and third test responses were timed out and the second test response was received
normally
Request/Response:

Request/Response:
POST /***/externalcasestart.xhtml HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Win32)
Connection: keep-alive
Faces-Request: partial/ajax
X-Requested-With: XMLHttpRequest
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: en-US,en;q=0.9
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
javax.faces.partial.ajax=true& javax.faces.source=form%3AmainGridBodyTable+and+sleep%280%29 &javax
.faces .parti al.exe cute=f orm%3A mainGr idBody Table& javax. faces. partia l.rend er=for m%3Ama
inGrid BodyTa ble&fo rm%3Am ainGri dBodyT able=f orm%3A mainGr idBody Table& form%3 AmainG ridBod
yTable _pagin ation= true&f orm%3A mainGr idBody Table_ first= 0&form %3Amai nGridB odyTab le_r

Looking for feedback and some insight.

9
  • We have our application Pen tested by our end clients with different vendors but this is the first time we have come across a AppScan report. We do not have an ORM , but our core module for Data access has been Pen Test for over 12 years without any issue. We are still not ruling out the first case and are trying to ensure we have evidence to report it as false positive , but the second one is completely wrong.
    – Ravi
    May 10, 2020 at 14:16
  • 1
    The URL after the v= in primefaces is just a version flag to make the URL unqiue so as new versions come out your browser loads the new JS or CSS. forum.primefaces.org/viewtopic.php?f=3&t=61941 . It is not an application parameter.
    – Ravi
    May 10, 2020 at 17:45
  • 1
    @Ravi is right the v is just a version parameter that makes the URL unique so the browser forces a refresh of CSS/JS when PF 7.0 i updated to 8.0. CHanging that V parameter has absolutely no effect on PrimeFaces.
    – Melloware
    May 11, 2020 at 11:31
  • 1
    @Melloware modifying the javax.faces.source - another case of false positive .
    – Ravi
    May 11, 2020 at 12:52
  • 1
    Sounds like a false positive too. And again in an ajax call... So maybe here too a 200 response is not expected (btw, I added the bluemix-app-scan tag to this question. Maybe add it to the others too
    – Kukeltje
    May 11, 2020 at 13:50

1 Answer 1

0

I can't say whether this specific finding is a false positive, but we see a lot of false positives like this - when the scan is run at rates which overload the system then it creates a lot of variety in responses. For some parameters the correct injections will time out so that it looks like a SQL injection to the tester.

This type of result should be followed up by a manual check, a separate tool (e.g. SQLmap), or at least a second run with the same tool to see if it replicates. If that's not possible, validate it with a code review and move on with your life.

1
  • 1
    Problem here is that the test is done by a customer and the customer 'needs', a clean test report. So OP cannot simply do a manual check (customer is not going to believe this, but they do thrust weird tools). So just 'moving on' is sort of hard.
    – Kukeltje
    May 20, 2020 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.