ZAP and DB2 for i on the IBM i Midrange System

[Mitch Hall]

I do not see either a SQL Injection - IBM DB2 or a SQL Injection - IBM DB2 for i Test Name on the Injection Default Scan Policy.

Db2 for i is the backend database on the IBM i platform, IBM's midrange system.

Is there a Injection Scan Policy Test for IBM DB2 for i out there somewhere that I can import?

I know that there are SQL Injection vulnerabilities in my PHP Web App, but none are reported when running a 'passive' ZAP Spider or AJAX Spider scan.

Does ZAP require you to run a Active Scan to be able to detect and report SQL Injection alerts?

I ran IBM's AppScan Web App Vulnerability Scanner against the same PHP Web App running in a Zend Application server on our IBM i system and it successfully detected and reported the know SQL Injection vulnerabilities in the application.   

Why aren't either the Zap passive Spider or AJAX Spider scans picking up on the SQL Injection  vulnerability in my PHP Web Application? 

[Simon Bennetts]

The ZAP spiders and passive scanners do not detect SQL injection vulnerabilities. You have to use the active scanner for that.

We deliberately split the exploring of an application from the attacking of it so that you get more flexibility.

By running the spiders you have just explored (and passively scanned) your app, you have not yet attacked it.

I'm guessing that AppScan did attack your app so you are not comparing like with like.

[Mitch Hall]

When running an Active scanner against my 'test' Web App Environment is it possible for a SQL Injection attack to alter tables in schemas other than the ones used with the DB connection object defined in the Web App itself?

If yes, my concern would be that a ZAP Active Scan could alter our production schemas on our IBM i midrange system.

Looking at the Default Scan Policy and the Injection Tests what Threshold and Strength settings would you recommend for the SQL Injection and XSS Active Scan Attack?

The IBM i  uses a Library/Schema List to create a container that a job runs in. 

 It's a top down approach where when a job requests to access an object the Library/Schema List is searched top-down until the first occurrence of the object is found and used.

This limits the scope of the job to only be able to access objects within the job's Library/Schema list.

Will the ZAP SQL Injection Test be confined to only attack database Files/Tables within the Libraries/Schemas used in the DB Connection routine?

Same goes for XSS.  If the ZAP active scan does inject a malicious script within one of the 'Test' Web App *.JS scripts will that be confined to the  JS Script source under the www/htdocs/…

Below is the Virtual Host entry from the Apache Web Server spraying the Zend App Server:

Could XSS attacks alter the existing JS scripts in my Web App or would they only potentially be added - stored on our IBM i server ( Stored XSS Attacks)

Listen *:199999
NameVirtualHost *:199999
<VirtualHost *:10089>
  # RedirectMatch ^/$ /ZendServer/
  ServerName plinktst.polarbev.com
  DocumentRoot /usr/local/MyWebApp_test_php7/public/
  <Directory /usr/local/polarlink_test_php7>
     Options FollowSymLinks
     AllowOverride None
     order allow,deny
     Allow from all
  </Directory>
  <Directory "/usr/local/MyWebApp_test_php7/public">
      AllowOverride All
      order allow,deny
      Allow from all
  </Directory>
</VirtualHost>

The data in the Libraries/Schemas used by this 'test' Web App environment are rebuilt/refreshed weekly so a SQL Injection Attack altering them is not a concern.

Could a SQL Injection attack potentially drop a File/Table within the 'Test' Libraries/Schemas that the test Web App is pointed at?

If yes, then that is ok if the SQL Injection Attack is confined to the test libraries/schemas that the Test Web App environment is pointed at.

Could you please suggest what precautions I should take prior to running a ZAP Active Scan on my 'Test Environment' PHP Web App.

[Simon Bennetts]

Replies inline:

On Wednesday, 17 March 2021 at 15:48:36 UTC mha...@gmail.com wrote:

When running an Active scanner against my 'test' Web App Environment is it possible for a SQL Injection attack to alter tables in schemas other than the ones used with the DB connection object defined in the Web App itself?

If yes, my concern would be that a ZAP Active Scan could alter our production schemas on our IBM i midrange system.

We do our best to ensure that ZAP is not destructive, but we cannot provide any cast iron guarentees.

ZAP attacks the web app rather than the db directly, so I can't see how ZAP could change any tables in other schemas which the web app does not have access to.

If you filter the rules on https://www.zaproxy.org/docs/alerts/ using "sql" in the alert field you will see theres only 1 release quality SQL rule.

The source code for that is: https://github.com/zaproxy/zap-extensions/blob/master/addOns/ascanrules/src/main/java/org/zaproxy/zap/extension/ascanrules/SqlInjectionScanRule.java

As you will see the attacks are 'boolean' based - we are just trying to detect SQL injection rather than actually take advantage of it.

 

Looking at the Default Scan Policy and the Injection Tests what Threshold and Strength settings would you recommend for the SQL Injection and XSS Active Scan Attack?

The default is always Medium, and thats what we recommend. If we find any other settings are better for most people then they become the new Medium :)

 

The IBM i  uses a Library/Schema List to create a container that a job runs in. 

 It's a top down approach where when a job requests to access an object the Library/Schema List is searched top-down until the first occurrence of the object is found and used.

This limits the scope of the job to only be able to access objects within the job's Library/Schema list.

Will the ZAP SQL Injection Test be confined to only attack database Files/Tables within the Libraries/Schemas used in the DB Connection routine?

As stated above ZAP does not attack dbs directly, it doesnt not understand the concepts of tables or schema. It will only be able to do what your web app can do.

 

Same goes for XSS.  If the ZAP active scan does inject a malicious script within one of the 'Test' Web App *.JS scripts will that be confined to the  JS Script source under the www/htdocs/…

ZAP will only actively scan URLs that you tell it to.

If you tell it to actively scan everything under https://www.example1.com then it will not attack https://www.example2.com

 

Below is the Virtual Host entry from the Apache Web Server spraying the Zend App Server:

Could XSS attacks alter the existing JS scripts in my Web App or would they only potentially be added - stored on our IBM i server ( Stored XSS Attacks)

Not unless thats a side effect of your application.

But yes, ZAP XSS attacks could be stored in a db or similar.

 

Listen *:199999
NameVirtualHost *:199999
<VirtualHost *:10089>
  # RedirectMatch ^/$ /ZendServer/
  ServerName plinktst.polarbev.com
  DocumentRoot /usr/local/MyWebApp_test_php7/public/
  <Directory /usr/local/polarlink_test_php7>
     Options FollowSymLinks
     AllowOverride None
     order allow,deny
     Allow from all
  </Directory>
  <Directory "/usr/local/MyWebApp_test_php7/public">
      AllowOverride All
      order allow,deny
      Allow from all
  </Directory>
</VirtualHost>

The data in the Libraries/Schemas used by this 'test' Web App environment are rebuilt/refreshed weekly so a SQL Injection Attack altering them is not a concern.

Good :)

Could a SQL Injection attack potentially drop a File/Table within the 'Test' Libraries/Schemas that the test Web App is pointed at?

If yes, then that is ok if the SQL Injection Attack is confined to the test libraries/schemas that the Test Web App environment is pointed at.

Only if thats a side effect of functionality in your app.

ZAP does not try to perform any destructive SQL attacks as per above.

 

Could you please suggest what precautions I should take prior to running a ZAP Active Scan on my 'Test Environment' PHP Web App.

If it really is an isolated test app then you should be fine.

But do note that if you have 'contact us' or similar forms then see this FAQ: https://www.zaproxy.org/faq/how-can-i-prevent-zap-from-sending-me-1000s-of-emails-via-a-contact-us-form/

If it is connected to other systems then there is obviously potential for those systems to be affected.

Cheers,

Simon