Cross handling Cookies in Zest
During the test, I found that POST-based scanning(active-scan / quick-scan) was not working in zap-cli ๐ฑ This problem is zap-cli issue, and it has already been reported as an issue below.
https://github.com/Grunny/zap-cli/issues/73
So while testing this, finally I find a way to solve it and share it. This is a trick using ZAPโs Attack mode. When Attack mode is activated, active-scan basically operates for targets corresponding to scope through Context.
Now result is accumulated in the ZAP, and if only the GET is scanned through the zap-cli, the result of the POST may be added.
TL;DR
- Start ZAP
- Change mode to attack mode with ZAP API
- /JSON/core/action/setMode/?mode=attack
- Add scope target URL
- Include POST URL in sitetree (At this point, the scan already starts.)
- Waiting Attack Mode Queue and Run quick-scan or active-scan
Step by Step
Starting ZAP
Prepare a ZAP! Open ZAP GUI or zap.sh, zap-cli
zap-cli start
Call this API for change attack mode
Canโt change the mode directly in zap-cli. So call the ZAP API for change attack mode.
{ZAP-API-HOST}/JSON/core/action/setMode/?mode=attack
// refer: http://localhost:8090/UI/core/action/setMode/
// API: http://localhost:8090/JSON/core/action/setMode/?mode=attack
Add scope target URL (using context)
zap-cli context new NAME
zap-cli context include -n NAME -p your_target_url.*
Include POST URL in sitetree
curl -i -k http://your_target_url -X POST -d "blah=1234" --proxy http://your_zap_api_port
Run quick-scan or active-scan. (and waiting attack mode)
when scan is completed, the result of POST has already been scanned in attack mode and the result appears together.
And if the attack mode scan ends faster than quick-scan/active-scan, the results may not come out properly. In this case, you can check the status of the scan of attack mode through the attack mode queue API ๐
{ZAP-API-HOST}/JSON/ascan/view/attackModeQueue
| Status | Response |
|---|---|
| Success or None | {"attackModeQueue":"-1"} |
| Scanning | {"attackModeQueue":"0"} |
