Re: Malicious CSS

[Laurent Lyaudet]

Hello all,
Le ven. 13 oct. 2023 à 18:02,
<libreplanet-discuss-request@libreplanet.org> a écrit :
>
> Send libreplanet-discuss mailing list submissions to
>         libreplanet-discuss@libreplanet.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss
> or, via email, send a message with subject or body 'help' to
>         libreplanet-discuss-request@libreplanet.org
>
> You can reach the person managing the list at
>         libreplanet-discuss-owner@libreplanet.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of libreplanet-discuss digest..."
>
>
> Today's Topics:
>
>    1. Malicious CSS (Yuchen Guo)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Oct 2023 21:18:57 +0000
> From: Yuchen Guo <yguo@posteo.net>
> To: libreplanet-discuss@libreplanet.org
> Subject: Malicious CSS
> Message-ID: <87y1g7fsji.fsf@lan>
> Content-Type: text/plain
>
> It might be appropriate to consider blocking CSS now.  Sites such as the
> Onion uses CSS to render their photo galleries unviewable without
> JavaScript, and the following site,
>
>    http://cryptobitch.de/
>
> uses CSS to render your whole computer unresponsive.  This might have
> been intended as a joke, but I was not amused by it.
>

Hello Yuchen,

I agree with you.
Thanks for pointing out that problem.
I already knew for some time of this kind of trick
https://www.leemeichin.com/posts/yes-i-can-connect-to-a-db-in-css.html
Now to be considered secure,
a web browser should be written in a memory safe language,
have extensive testing by the community,
do not mix URL bar and search bar to not leak your URL to a search engine,
and use a whitelist for JS and a whitelist for CSS by default.
I think there should be two select inputs next to the search bar or URL bar.
One for JS and one for CSS.
The two simple options in both would be "Deactivated", "All activated".
But clearly, we need to be able to have profiles of whitelisted JS or
CSS as intermediate options.
Unless we have profiles, there will be "The" whitelist profile/choices
of the distributor of the web browser.
But in free software community, every one should be able to edit many profiles,
to add in them fragments of CSS or JS, we analyzed.
The No JS and No CSS is not mandatory.
For example, in a web site, you can display visitors comments
containing tags <b></b> without adding any risk of XSS.
Whitelists are the solution.
A security researcher may use a large whitelist for websites he
already analyzed.
And use a restricted whitelist for sites to analyze.
Here again, the right choice is to give user freedom and to educate
and share knowledge.

Best regards,
     Laurent Lyaudet