Stylus: [Feature Request] Check for presence of UserCSS header in styles installed from UserStyles.Org and parse it if present

[lainverse]

• Browser: Google Chrome 86.0.4240.198 (doesn't matter)
• Operating System: Windows 10 (doesn't matter)
• Stylus Version: 1.5.13
• Screenshot: none

I have a style on USO used by over 260k users. Recently decided to move it on GitHub, but apparently Stylus ignores UserCSS header in styles installed from USO. As the result I can't use @updateURL to point users with existing installations to a new location and the only option I have is to make them remove existing one and install manually from a new location.
Style in question: https://userstyles.org/styles/101141/ru-adlist-css-fixes

Is it possible to implement UserCSS header parsing for styles installed from USO and use it when it's present and valid?

[tophf]

Sounds very useful given how bad USO is nowadays.

[tophf]

Summoning usercss people @eight04 @silverwind - any thoughts on the feature? Should the automatic and manual updaters silently upgrade/redirect such styles no questions asked or should it skip them and show a special icon in the manager/popup maybe?

[silverwind]

I guess you could switch over to full usercss parsing if a valid header is detected, including updating from the URL therein. I take it as consent from the author if they add such a header, they'd expect it to work in precedence to USO.

[tophf]

What would be the worst possible abuse/attack vector here? Just in case.

[silverwind]

Hmm, if someone manages to compromise USO, they could inject CSS into any site via the update, possibly running CSS exfiltration attacks. Thought, the same would apply currently, but it would be more visible because they'd need to change all style content to include the attack code, as compared to here where they'd only need to insert the header with a updateUrl.

[narcolepticinsomniac]

the same would apply currently

Yep.

but it would be more visible

Not really, if we're talking auto-updates. Even if you showed a diff, most people will either ignore it, or not know what they're looking at. In most cases, probably both.

CSS exfiltration attacks

There might be slight variations, but they're all basically the same code, with very obvious patterns which would be simple to check for. We should either nuke any existing malicious styles, and prevent any future installations, or just check for malicious code immediately after injection, and remove it surgically, leaving the rest of the style code, since theoretically, you'd hide it in a style which works, and is useful.

Other than the password attack, any real risk is practically non-existent. Tracking isn't ideal, of course, but it's a 1 on a scale of 10.

[eight04]

Usually, I prefer to make it explicit instead of changing the source quietly. Like a Do you want to switch to usercss? prompt can work. Though I guess we shouldn't treat USO as a usual case.

What would be the worst possible abuse/attack vector here? Just in case.

This feature gives the server the ability to send requests through user PC daily. It should be fine as long as we don't send any info back to the server.

[tophf]

We are sending cookies though. Should we set anonymous mode on updater? OTOH this could break updates for someone who's using a private server with sign-in.

[eight04]

I thought it is impossible to send one site's cookie to another site. Can you elaborate?

[tophf]

I meant it can be used for tracking, not stealing.

[eight04]

Sounds cool. Maybe we can add an option for this and make anonymous as the default? It's a little off topic let's make a new issue for it.