Risk of running active scans

[JR]

Hello,

If this isn't the right place to ask, please let me know where I
should be asking.

Is there any danger in running a ZAP active scan against a live site
(that you own, of course). In other words, is the probing for
vulnerabilities harmless or destructive? Is there a chance the scan
could create/delete/update/corrupt data?

Thanks.

[Adam Muntner]

Sure. Imagine, it hits some kind of feedback or mail form, and you get
1000 feedback emails. Or, if if the spider enters a bunch of garbage
records into a form. If you are authenticated and scan some kind of
administration or profile page, all kinds of exciting values can get
set. You could accidentally change your password. Users could get
locked out. The possible bad things that could happen are endless. So,
for example, don't scan the tomcat manager interface for your
employer's production webserver, or something like that.

> --
> You received this message because you are subscribed to the Google Groups "zaproxy-develop" group.
> To post to this group, send email to zaproxy...@googlegroups.com.
> To unsubscribe from this group, send email to zaproxy-devel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/zaproxy-develop?hl=en.
>
>

[Axel Neumann]

Hi there,

the active scans are not destructive. For example, if you're testing
for SQL injection, there's of course no such thing like deleting data.

The main risk in using some kind of automatisation is crawling a
website. Especially if you are logged into a web-application that has
the capability of creating or deleting some data. For example, if you
are using ZAP within a administration interface of a web-application
which is used for creating or deleting users, those users might get
deleted or random data might get filled into the database while
crawling...

Do you need more information?

Cheers,
Axel

[JR]

That makes sense. Thanks both.

[Ryan]

Something you can do to prevent that is actually stop the spider from
doing POST requests (which I figured out after sending about 10,000
emails one night).

In the xml/config.xml file there's an option (line 47) in the spider
section:

<spider>
<thread>2</thread>
<maxDepth>5</maxDepth>
<scope></scope>
<postform>0</postform>
<skipurl></skipurl>
</spider>

Usually its <postform>1</postform>, but set it to 0 to disable the crawling.

There used to be an option for it in Paros and earlier versions of ZAP I
believe, but it seems to have disappeared lol.

Anyway, you're obviously not going to find as many things without
posting stuff, but I do that sort of analysis manually, because GETing
stuff automatically takes down the bulk of the work to find stuff usually.

Hope it helps!
Ryan

[psiinon]

I usually try to explain it this way:

Proxying (and therefore passive scanning) requests via ZAP is completely safe and legal, it just allows you to see whats going on.

Spidering is a bit more dangerous. Is could cause problems depending on how your application works (and we should make the 'no post' option visible!).

Active scanning is dangerous and depending on your app may create/modify/delete data.

So the only really safe thing is proxying and passive scanning, the other 2 could cause problems and could be considered illegal if you perform them on apps you dont have permission to test.

I have wondered about adding a 'safe' mode to ZAP which will only allow you to do safe things. Thoughts anyone? I know its not something pentesters would use;)

Hope that helps,

Psiinon

[Adam Muntner]

Good explanation!

GET isn't always safer than post, because even thought the HTTP RFC
defines how idempotency is supposed to work, in practice, many apps
use GET requests to change data server-side. Posts get (improperly)
used where nothing changes at all on the server side state.

> --
> You received this message because you are subscribed to the Google Groups
> "zaproxy-develop" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/zaproxy-develop/-/vmMtZzoB-6MJ.