ZAP Automation Framework not detecting reflected XSS

[Rafael Figueiredo]

Hi everyone,

I am currently building an authenticated DAST workflow using OWASP ZAP Automation Framework for my MSc thesis.

Through manual pentesting, it is already known that the application contains a reflected XSS vulnerability.

However, I am observing the following behaviour:

• running Active Scan against the application generally does NOT detect the XSS;
• in the ZAP UI, the XSS is only detected if I manually navigate the application first, capture the exact authenticated POST request in History, and launch “Attack -> Active Scan” directly on that specific POST request;
• in the Automation Framework/CLI workflow, the XSS is also not detected.

The current workflow is generic/reusable and includes:

• authenticated scanning;
• AJAX Spider + Spider;
• Active Scan with XSS rules enabled.

My goal is to understand whether this behaviour is expected, and whether it is realistically possible for a generic automated workflow to identify vulnerabilities such as XSS automatically in authenticated applications, without relying on manually captured requests or application specific workflows.

Thanks!

[Simon Bennetts]

Hiya,

ZAP cannot attack end points that it does not know about.

The fact that ZAP finds this vulnerability when you manually explore is good, that shows that the XSS scan rule is working.

Failing to find the XSS in automation is almost certainly because the spiders have not discovered the vulnerable POST request.

You can confirm that by running the spiders in the ZAP UI and checking the Sites Tree.

Is the POST request difficult to navigate to?

Or does it have some validation which will cause it to fail if valid data is not supplied?

FYI ZAP left OWASP nearly 3 years ago. Its now just "ZAP" or "ZAP by Checkmarx" :)

Cheers,

Simon

[Rafael Figueiredo]

Hi Simon,

Thanks, that helped clarify the issue.

After further investigation, the vulnerable endpoint and several POST requests to page where XSS exists are actually being discovered by both the AJAX Spider and the traditional Spider. The Sites Tree contains multiple POST requests with the relevant parameters, including the vulnerable form fields.

•⁠  ⁠node: "POST:ConfigPhonebook.aspx()(__EVENTVALIDATION,__VIEWSTATE,__VIEWSTATEGENERATOR,ctl00$ContentPlaceHolder1$FileUpload1,ctl00$ContentPlaceHolder1$txtFind,ctl00$ContentPlaceHolder1$txtMobile,ctl00$ContentPlaceHolder1$txtUpsertComme...,ctl00$ContentPlaceHolder1$txtUpsertDirec...,ctl00$ContentPlaceHolder1$txtUpsertExten...,ctl00$ContentPlaceHolder1$txtUpsertFirst...,ctl00$ContentPlaceHolder1$txtUpsertLastN...,ctl00$ContentPlaceHolder1$txtUpsertLocat...,ctl00$ContentPlaceHolder1$txtUpsertMailb...,ctl00$ContentPlaceHolder1$txtUpsertTitle,ctl00$btnFeedbackTrigger,ctl00$ddlLanguage)"
        url: .../ConfigPhonebook.aspx
        method: POST
        responseLength: 45608
        statusCode: 200
        data: __VIEWSTATE=&__VIEWSTATEGENERATOR=&__EVENTVALIDATION=&ctl00%24ddlLanguage=&ctl00%24ContentPlaceHolder1%24txtFind=&ctl00%24ContentPlaceHolder1%24txtUpsertExtension=&ctl00%24ContentPlaceHolder1%24txtUpsertDirect=&ctl00%24ContentPlaceHolder1%24txtMobile=&ctl00%24ContentPlaceHolder1%24txtUpsertFirstName=&ctl00%24ContentPlaceHolder1%24txtUpsertLastName=&ctl00%24ContentPlaceHolder1%24txtUpsertTitle=&ctl00%24ContentPlaceHolder1%24txtUpsertMailbox=&ctl00%24ContentPlaceHolder1%24txtUpsertLocation=&ctl00%24ContentPlaceHolder1%24txtUpsertComments=&ctl00%24ContentPlaceHolder1%24FileUpload1=&ctl00%24btnFeedbackTrigger=
     
However, I noticed that the generated requests contain empty ASP.NET state parameters such as __VIEWSTATE, __EVENTVALIDATION, and __VIEWSTATEGENERATOR.

At this point, it seems the issue is not endpoint discovery itself, but that the Active Scan is replaying invalid or incomplete ASP.NET WebForms requests. Because of that, the vulnerable server-side workflow likely does not execute correctly during automation, preventing the reflected XSS from being triggered automatically.

This would also explain why the XSS is detected when performing an Active Scan directly against a real POST request from the History tab after manual navigation in the UI.

In your experience, what would be the best approach to preserve valid WebForms state during automated scanning? Would this typically require a custom script / Selenium flow / authenticated request replay approach?

Thanks again