Owasp Zap's active scan harming the database

Question

I want to integrate OWASP Zap security tests in my continuous integration chain using the official Jenkins plugin.

However, since it injects harmful payloads in database, I don't want the database to become corrupted! And it's a huge database. I was wondering how to implement it correctly without corrupting the DB.

Did you think about setting up a test environment with a database of test data of which can be corrupted? — Bob Ortiz, Jul 11 '17 at 07:23

SecretSasquatch · Answer 1 · 2017-07-11T18:52:50.870

Run the active scans against a non-production environment (replica of production). Have a process/script to easily restore a fresh copy of the live database if you break your non-production database during the active scanning.

It is best practice to avoid unnecessary risk on the production site. Also, you can be much more aggressive with your penetration testing against a non-production environment.

You mentioned that your database is "huge". If it is way too large to feasibly copy to non-production in a reasonable amount of time, you could look into decreasing the size of the production database when you copy it into your non-production environment. This might include trimming the tables that have an excessive number of records that are not required for non-production testing purposes.

score 5 · Answer 2 · answered Jul 11 '17 at 09:03

5

You shouldn't be running any tests against a live database, You should be using a segregated testing environment

answered Jul 11 '17 at 09:03

user6858980

99
2

This does not provide an answer to the question. Once you have sufficient [reputation](https://security.stackexchange.com/help/whats-reputation) you will be able to [comment on any post](https://security.stackexchange.com/help/privileges/comment); instead, [provide answers that don't require clarification from the asker](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead). - [From Review](/review/low-quality-posts/103720) – MiaoHatola Jul 11 '17 at 09:54
Although CI presents challenges to implementing test environments, this is actually a valid reminder that destructive testing should not be done on production. – schroeder Jul 11 '17 at 10:22
@MiaoHatola how is this answer any different to the one posted above except worded differently? The fact is the answer to this problem is not to run the test against a live environment but a testing environment which can be destroyed and rebuilt per test – user6858980 Jul 11 '17 at 13:15
@JamesKirkby the OP asks how to do something, you are saying how not to, which to me feels not enough for an answer. My previous comment is an automated one, and might seem aggressive, sorry about that :) – MiaoHatola Jul 11 '17 at 13:23

score 0 · Answer 3 · answered Jul 11 '17 at 13:05

Always maintain a non-production environment of your application which is a replica of your production application. Always Maintain secure backup of your application to rebuild the application in non-production if required. All security tests & patching should be first completed on this non-production environment & only after it's success/failure should they be implemented on production environment.

Owasp Zap's active scan harming the database

3 Answers3