Greasy Fork

In the latest Chrome (or Brave),

after navigating to the page https://www.youtube.com/,

execute the following code in the DevTools Console.

document.createElement('div').innerHTML = 'Hello World.';

The code cannot be executed due to

TypeError: Failed to set the 'innerHTML' property on 'Element': This document requires 'TrustedHTML' assignment.

However, the same code can be executed in private window mode.

Anyone knows the solution for this issue?

Solution found.

https://greasyfork.org/en/scripts/433051-trusted-types-helper

So these trusted types are just blocking any DOM manipulations? And why this is only latest Chrome if this feature is 4 years old

So these trusted types are just blocking any DOM manipulations? And why this is only latest Chrome if this feature is 4 years old

Sorry. This might be not related to the version of Chrome.

It could be just the new restriction in YouTube.

Anyway, as the solution is found, I don't investigate the root clause.

This is the new restriction in YouTube.

https://support.google.com/youtube/thread/287326123/strengthening-security-for-extensions-on-youtube?hl=en

Sorry. This might be not related to the version of Chrome

It is. I'm using an older version and it seems like I don't have this problem, but the feature itself seems to be available from a 2020 year browser version already.

Anyway, it seems like they really don't like the addon that returns video dislikes. I'm just not sure, this restriction means that everything that tries to modify DOM is not going to work anymore without this workaround?

I was about to create this topic a week-ish ago.
I wish that there was a better solution to this though, seems like it is too much code just to do a simple .innerHTML...

This works, so it's an "okay" bypass.

But what about the unsupported browser types? Any solution to those?
https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API

I got it now, actually, Firefox and Safari are "less" secure so we don't even have to worry about that because it works even without using that.

@Konf

Do any of you know why there are some HTML that work sometimes without bypassing TT, while sometimes it doesn't work unless you bypass TT?

I don't know man, but I'd like to look at exact example like where you're trying this and what code. You're saying that using the same code on the same page you have different outcomes just refreshing the page?

Kinda want to figure it out

@Konf

I am trying on google.com and youtube.com, with my own scripts...

No, I mean that using innerHTML and such sometimes works depending on the script, and sometimes it doesn't... But I bet that TT isn't that specific... Like either it's blocked, or it isn't... The docs I read don't show an option like "block only innerHTML", or "block only injections of style tags" or such specific settings...

Me too, I'm just curious...

I was about to update all my scripts, then I saw that I didn't need to do that...

Yo look at that: https://youtu.be/3RC-I_DKTOU

There is no TT if it is loaded not from a cache or something

Wait now I see on 1:30 there is still a "require-trusted-types" thing below. But it works though.. Why

Oh I get it, it is because it works only for the https://mail.google.com/mail/cspreport URL and not for the others in that case. Makes sense

I think that TT isn't new but it was only recently more broadly implemented on Google Sites, so it is still bugging?
A security policy shouldn't be bypassed that easily, just because the site is not cached..

A security policy shouldn't be bypassed that easily

Idk. It seems in general it's more about design and preventing accidents and not about some strong security

English

https://blog.bitsrc.io/trusted-types-api-for-javascript-dom-security-fcdafa927e73

Japanese (you need to translate by yourself)

https://sbfl.net/blog/2020/04/19/trusted-types/

The restriction is done by the server by using Content-Security-Policy in http response

Then it restricts all the page editing that makes javascript executions

You need to set the policy to make some editing allowed

But youtube does not set any policy for this.

So TT can even block innerText as well? I feel like that's too much... but ok...

That still doesn't explain why sometimes innerHTML works and sometimes it doesn't (same for other functions too)

sometimes innerHTML works and sometimes it doesn't

Maybe it's just because sometimes TT is applied and sometimes not? Like in the video above. Though idk why it's done like that

I don't see the point of TT, since we can just create our own policy, we can still do DOM XSS attacks anyway...

I bet that it was mainly created to prevent DOM XSS attacks instead of being just "more about design".

If TT cleaned our code and removed/disabled stuff, even when we used our own policy, that would make sense, but I bet that I can still use eval() and such if I create it using my own TT policy.

It sounds like TT is just a bad joke and a poorly implemented "API" https://pastebin.ai/zdjqqwq0il

If I create and use my own policy, is there anything that I'll definitely still be unable to do? I don't think so...

https://chatgpt.com/share/dbaba3fa-47b4-43a3-b7ef-26c411ff7f93

Yh I read all that before, and I also had CSP issues a couple of weeks ago, I tried all I could to Google and find ways to bypass it, but in the end, I had to use SVGs instead of images... Which sucks...

1 Controlled Usage: Doesn't make sense and is a dumb reason, although I also heard it in other cases and contexts. I just disagree with it.
2 Centralized Sanitization: This makes sense at least... As long as a dev has a huge and long .js file on their server doing a bunch of stuff...
3 Is the same thing I've been talking about, it still doesn't make any sense since anyone can just bypass it, if intended.

CSP is way better and stronger than TT in most cases, at least when not set using the HTML meta tag, but I doubt that it can also prevent HTML issues like TT does, so that's probably why TT was created and "is related with" CSP.

It was good to learn that 4,5,6,7 can also be blocked, thanks!