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.

Ravi
  • 391
  • 2
  • 18
  • 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 '20 at 14:16
  • So it is not your report but coming from a customer? – Kukeltje May 10 '20 at 15:38
  • Yes, the client ran the AppScan first and shared the report. they are also doing a pen test and I do not have the result yet. We have a scan from another vendor using another tool which did not have any of these issue. – Ravi May 10 '20 at 15:57
  • @Melloware, I don't agree with your generalization. Every ORM package allows some way of executing raw SQL expressions or full queries. If there's a way for a developer to make any part of the SQL query from a string, then it's a potential for SQL injection if the string is formed by a naive developer. – Bill Karwin May 10 '20 at 17:15
  • @Ravi, the second example at least shows samples of input to use for parameter `v`. You should be able to test this yourself against a development instance of your app. What happens when you do this? – Bill Karwin May 10 '20 at 17:20
  • 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. https://forum.primefaces.org/viewtopic.php?f=3&t=61941 . It is not an application parameter. – Ravi May 10 '20 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 '20 at 11:31
  • 1
    @Melloware modifying the javax.faces.source - another case of false positive . – Ravi May 11 '20 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 '20 at 13:50

1 Answers1

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.

Egret
  • 739
  • 3
  • 8
  • 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 '20 at 07:43