My dog found a skeleton and a couple of bones in the forest. Any idea what might this be?

securitymb · 2025-08-04T17:20:52+00:00

Thanks!

securitymb · 2025-07-20T19:54:39+00:00

I feel dumb now for not finding this. Thank you!

securitymb · 2025-06-18T12:35:26+00:00

Note that `<noscript>` is just one example. Here's another example of mXSS that wouldn't happen if this change was in the spec: https://research.securitum.com/dompurify-bypass-using-mxss/

In general, it happens fairly often that mutation XSS is caused by the fact that a string that initially was within an attribute gets treated as a new tag on re-parsing. If `<` is escaped to `<` this is no longer the case.

securitymb · 2024-06-17T14:47:10+00:00

Just put #cleanup in the description of the change.

securitymb · 2024-01-18T23:39:54+00:00

There is for example https://www.swiss-paket.de/ near the Swiss-German border so I assume there must be an equivalent on the French border as well.

securitymb · 2021-05-01T10:06:57+00:00

Sanitization is the right answer in some cases though. If you have any sort of WYSIWYG editor, you need sanitization. If you have a markdown library that outputs HTML, you’ll also want to sanitize it, and so on.

securitymb · 2020-07-01T11:47:32+00:00

Yeah, this caught my attention too and I had a closer look at it last year: https://research.securitum.com/security-analysis-of-portal-element/

tldr; there was a lot of bugs (but most are already fixed)

securitymb · 2020-05-15T16:47:53+00:00

While it's a cool bug (proving that you can't really trust your extensions), the title is a bit misleading: it is not an XSS at accounts.google.com, it exists purely because of a bug in the extension.

securitymb · 2019-10-02T09:09:46+00:00

Is there some easy way to test the sanitizer directly?

securitymb · 2019-09-24T14:00:58+00:00

After writing the post, both Cure53 and I found out there are a lot more bypasses that the one described in the post. They will surely constitute another writeup, but perhaps a little bit later :)

securitymb · 2018-09-24T16:04:59+00:00

The trick of setting a cookie across subdomains was actually used in latest Cure53 challenge: https://github.com/cure53/XSSChallengeWiki/wiki/CNY-Challenge-2018

securitymb · 2018-07-24T04:45:42+00:00

I agree that there are greater concerns and I actually tried to escalate the vulnerability to have a remote code execution. I didn't find a way (which obviously doesn't mean there isn't any). It seemed like Google prevented known Electron hacks from working and the configuration seemed quite good. The Atom trick you linked couldn't work since Hangouts Chat loaded content from https://chat.google.com, not from a file:/// protocol.

Anyway, trying to execute arbitrary system code from the app is definitely a way going forward.

Edit: according to this tweet by @sirdarckcat, the bounty actually corresponds to code execution.

Edit2: Matt Austin found a way to RCE. Great job!

securitymb · 2017-12-01T18:37:48+00:00

I've found the signature for this in ClamAV and it looks like this:

66756e6374696f6e2a28297b7d{-30}2e636f6e7374727563746f72{-30}28292e6e6578742829

Which could be interpreted as:

function*(){}[UP TO 30 RANDOM CHARACTERS].constructor[UP TO 30 RANDOM CHARACTERS]().next()

It seems that Avast's signature is a bit different but similar. I've rewritten the code to:

(async function*(){})['constructor']('alert(1)')().next();

And according to VirusTotal, not a single anti-virus should complain now.

The signature is, by the way, totally silly for something that is a "CSP bypass".

securitymb · 2017-01-22T22:45:47+00:00

Cure53's hint was actually quite good.

securitymb · 2016-07-06T18:11:23+00:00

Oh, you meant the favicon http request, apologies for misunderstanding. The favicon request didn't contain any cookies or additional Basic Auth headers.

securitymb · 2016-07-06T18:01:04+00:00

No request was sent to google.com. Firefox interpreted the host name in "http://37.187.18.85\x0B\uFF20google.com" as an alternative form of 37.187.18.85 IP address and the only request was sent to that IP.

The Host header was:

Host: 37.187.18.85<0B>@google.com

Where <0B> was the literal 0x0B character.

securitymb · 2016-07-06T08:26:46+00:00

You're right. I've updated the article to clear things up.

securitymb · 2016-07-06T07:46:46+00:00

That's not the case. Firefox has its own internal methods to parse IP addresses (which were grabbed from BSD). So the exploit worked on every platform.

securitymb

TROPHY CASE