2

I am using OWASP ZAP to scan my web-application, developed using asp.net framework/C#. I am being tasked by company to ensure NO error reported by OWASP ZAP.

The OWASP ZAP reported this log: Issue: Cross Site Scripting (DOM Based) URL:

http://[WEBSITE]/myapplication/script.aspx#jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

I understand that the fragment (#hex) will not be sent to server for processing, it is more for browser to process.

So what do i suppose to do to ensure it never gets reported again in OWASP ZAP? I've done following actions, but with no luck:

  1. On the page, I embedded the javascript code, to remove the hashtag in the url. (Remove fragment in URL with JavaScript w/out causing page reload). It works, and I can see it being removed on the browser. But OWASP ZAP still reporting it as problem.

  2. Similar to #1, i come out with javascript to detect whether #-fragment-url exists in URL. If exists, then redirect to "error" page. It is working, but ZAP again still report it as problem.

I guess since browser never send the # to the server for validation, i have no way to sanitize it. By the time ZAP/browser receives the response, ZAP will report it as issue.

So, what shall i do? I just want OWASP ZAP never report this issue anymore. Any ideas?

Lonzak
  • 9,334
  • 5
  • 57
  • 88
davidtj
  • 41
  • 4
  • Stop depending on document.location or window.location to build page content? – kingthorin Jan 27 '21 at 20:25
  • Check: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html – kingthorin Jan 27 '21 at 20:27
  • @kingthorin, i went to the document link you provided. I never use any of those DOM-manipulation, such as window.location etc. In fact, i can come out with a simple page with no script, but still OWASP ZAP will complain about this. It sounds to me, it is a false alarm, but i don't think my IT security guy will buy my argument. – davidtj Jan 28 '21 at 00:22
  • 1
    The ZAP DOM XSS rule is usually pretty solid - it uses a real browser and only raises an issue if the browser triggers an alert popup. So my initial assumption would be that this is a valid attack. Try to reproduce the issue in a browser. If you are sure that its a false positive then see if you can create a standalone page based on yours which ZAP still complains about and submit it to us as an issue: https://github.com/zaproxy/zaproxy/issues We'll aim to either show it is a real vulnerability or fix ZAP so that it wont report it – Simon Bennetts Jan 28 '21 at 09:23
  • @davidtj Could you resolve your problem? – Lonzak Feb 01 '21 at 12:08

0 Answers0