ssl/ezXSS

Bug: Duplicate report setting isn't respected by Discord setting

geeknik opened this issue · 4 comments

Hello, I have the latest 4.2 code installed and I have the duplicate report setting set to just make a report, not to send an alert, however, the Discord web hook is still receiving dozens of report alerts.

image

Would it be possible to have an option to further limit Discord alerts to 1 per unique domain or IP?

ssl commented

Does the report get saved when you don't save or alert at all?

I don't think this is a issue with alerts, especially Discord, since (if coded corrected) it should skip all alerts when it is flagged as duplicate.

I think the issue is more that ezXSS doesn't flag the reports as duplicate. In order to flag a report as duplicate, the following rows need to be 100% the same:

$cookies, $origin, $referer, $uri, $userAgent, $dom, $ip

(This was implemented as sometimes a payload would be added to the same page multiple times, which sends a callback for each payload, which can be annoying since it is all the same trigger moment on the same page. It was not implemented to prevent a trigger when user visiting a page multiple times with possibly small changes in dom or cookies)

If any of these rows are different, for example a cookie that updates on each request, or a timestamp in the html dom, the report is already not flagged as duplicate.

Can you check for me and make sure all these reports are actually the same? Big chance there is a small change in cookies or dom. which ezXSS does not flag as duplicate.

Thank you for the explanation. It appears as though it's the DOM that is slightly changing, but not enough to warrant another alert IMO everything else looks the same..

ssl commented

I understand it might be confusing when you get reports which look 99,9% the same that still saves/alerts.

It would also be hard to just check parts, or don't save/alert when most is the same. What if some crucial information is stored in this part that is changing? There is no real way to find this out.

That's why it only counts when it is 100% duplicate, and not 99%. It's just there to not get overloaded with reports because some payload is injected 10 times per page and triggers on every single one (because the browser actually will post to /callback all 10 times with the same data).

If you agree the dom is slightly changed and the code works as intended, please let me know and close this issue. If not and there is some bug, I could check it out.

If you believe the reports should not report when 99% is the same, also let me know. But this would need some serious consederation, as you would not want to lose reports with crucial data that is changed in that 1%, and I don't see a quick way how to implement this without possibly losing data. If you think differently, also please let me know :)

All good on my end, thank you for your time and explanations. 👍🏻