Cross site css injection possible

[flovo]

Describe the bug This user injected css in the about field on the profile page. https://online-go.com/player/740904/

<link href="https://u.teknik.io/q6cFX.css" rel="stylesheet" />
<link href="https://fonts.googleapis.com/css?family=Press+Start+2P" rel="stylesheet">
<link href="https://unpkg.com/nes.css/css/nes-core.min.css" rel="stylesheet" />
<p class="marquee">.<br><br><br><br><br><hr/></p>

Screenshots

[anoek]

That's known, I don't think it's particularly harmful though? I left it because I thought it was neat and pretty harmless

[runarberg]

Here is an SO answer about the risks of CSS injection.

I think the main risk on OGS is from social hacking, and even then, an attacker would have to fool a victim twice—first by providing them with a link to malicious stylesheet, and then trick the user to perform an unwanted action with altered styles. Such an attack would be very difficult to pull off, and I have a hard time seeing what an attacker could possible benefit from such an attack.

The worst thing that I can think of is some joker uses this vulnerability to add to their trophies, put an easter egg in their game history, or moves the player card and the challenge button to a phony back button so that a visitor will always send a challenge when they click it twice.

[kevincoleman]

I just found this by chance. While I agree that it seems harmless, remember that it’s the vectors that we ignore that can be made malicious. Also, while we tend to think of CSS as being pretty benign it can actually be used to write full-on responsive logic (people write full games in just CSS). Especially since this site does accept donations (and therefore there are some views relating to payments), I’d suggest that this might be a good thing to fix.

A couple things I can imagine:

• user creating a fake dialog that prompts users to re-enter their passwords (“you’ve been logged out due to inactivity” or something), but the passwords are actually being entered into a private chat field.
• user injects CSS to modify their rating to appear lower than they actually are, so they can get more games with people they can easily beat, thus improving their rating unfairly.

And I’m no red-teamer.

While I know that every security issue is always a balance of available means vs attack risk, I thought playing devil’s advocate here might be of some value.

[BHydden]

CSS can only be edited for your own profile page, it does not reach the rest of the site, so there is no possibility to change ranking, but your example of being able to create a password prompt could be a possible vector worth considering.

[runarberg]

I think an attacker can pretty easily distribute a malicious stylesheet though the chat rooms and forums (e.g. with a thread called “pimp up your profile page”), and a phony password prompt would be pretty easy. However disguising an element as the prompt which would deliver the user input to the attacker is harder, as it would require a few clicks: The simplest way I can think of is the following:

1. Disguise the friends dropdown indicator as an alert notification, and perhaps place it somewhere prominently displayed on the profile page. (This will fool the victim into expanding the friends list.)
2. Target your the link to your own attacker account using the attribute selector and put a phony but important sounding message as the content of a pseudo-element:

   .friend-entry .Player[data-player-id="321307"]::before {
    content: "Important message: Urgent action required!"
    /* ... */
   }

   (This will fool the victim into opening the player card of the attacker’s account.)

3. Do something similar to the ‘message’ button of the player card. (This will fool the victim into opening up a private message chat with the attacker).
4. Disguise the chat window as a password prompt with the input as the password field

Now for this to work the attacker needs to have added the victim as a friend. To do that they might simply send a request to everyone that responded on the thread where they first distributed the malicious stylesheet.

[ph1234k]

Need this re-evaluated.

You can inject both CSS and HTML (such as linking to any resource on the Internet). This leaves the users open to being attacked by visiting an OGS profile. The attack is not that difficult, and you don't have to do much to trick them since you can create links that don't look like links and they may simply click the page not thinking.

It can also be used much more actively to lure people into such clicks.

To be clear, having the position that you will just ban people who act maliciously is not sufficient to protect users. If users get attacked, then the ban won't make the consequences go away and you won't be any less responsible for exposing them to this.

The novelty of such a feature should not outweigh the risks. Sure it's cool to style a page, but it's very much not cool to get malware from a misclick on a fairly trusted site. This should be removed in my opinion, until scrubbed to the point of not being attack-able. Though it would probably just be better to offer theme based features that don't require interacting with HTML or CSS by the user.

Do not underestimate the security risk here, this is a severe issue and needs to be addressed ASAP. Please don't wait until users on OGS are attacked (keeping in mind that due to the specificity of this type of service, there are many other software assumptions one can make about the users which means these attacks can get very intense very quickly, utilizing multiple pieces of Go software if needed. A basic example of that type of exploitation being to gets users to download crafted SGF files meant to take advantage of another software such as Sabaki, cGoban, KaTrain, etc -- using OGS to get the file on their system and then the additional software to compromise the system itself. Not that such interactions are needed to make a dangerous attack, but they are easier to identify here). It is not sufficient to simply ban people who have already attacked users, and it is not sufficient to wait until someone gets hurt to fix the issue.

Until this is fixed, it cannot be considered safe to visit an OGS profile.

[github-actions[bot]]

This issue has been marked stale and will be closed soon without further activity. To keep the issue open, please respond to the comment to keep the discussion going.

[flovo]

I'm still convinced that it's possible to the buttons on the profile page to trick users to a fake login form etc.

[kevincoleman]

I saw this notification hit my inbox and I thought, “oh yeah, that lingering low-threat issue.”

Then I got here and re-read it and it reminded me that this is a little ridiculous. The risk is not huge. To say:

@ph1234k: Until this is fixed, it cannot be considered safe to visit an OGS profile.

is a bit overly dramatic, and ignores the fact that all security is imperfect, but then when I re-read:

@anoek: I don't think it's particularly harmful though? I left it because I thought it was neat and pretty harmless

I had to cringe a little. Ostensibly, yeah, it’s kinda neat and probably not harmful—but that should definitely not be the end reasoning here.

That said, this is an open-source repo, and commenting on an issue expecting someone else to fix it is not how open source works. If you (anyone here) believe this to be a threat then open a PR with a fix. If it’s just too much of a threat for you then you can choose not to use OGS. IIRC there’s a bit in the documentation about how this is all free and you shouldn’t get all in a huff if you don’t like something. Knowing how the main active devs are already really busy fixing/building great things, I think it’s only fair to let this issue sit until someone feels like making a PR.

Change my mind. ;)

[ChrisMoutsos]

I believe this issue was fixed with this commit on March 19, 2020:

https://github.com/online-go/online-go.com/commit/f2b073d628f338d43e694f87ade15565ddd5bd4a

[anoek]

Thanks for letting us know!