EidoGo Security Vulnerability Alert

[YeGO]

Public Security Announcement to WebMasters using EidoGo

EidoGo contains cross-site scripting (XSS) security vulnerabilities

If you are using EidoGo as an embedded SGF player on your website, your site may be susceptible to these security vulnerabilities, particularly if your site supports uploading SGF files that are then displayed to other users via EidoGo. You can read more about this issue in the below GitHub issue report.

https://github.com/jkk/eidogo/issues/27

You can also read more about what cross-site scripting is on this website: http://excess-xss.com

Note: this is the public disclosure following a two-month period after the developer was first privately notified of this issue. One month ago, the webmasters of several websites (including L19x19) were notified to allow them to address this security issue in advance of wider public disclosure.

[Bonobo]

Since I see links to EidoGo all the time … is there any news about this?

[Javaness2]

No

[Uberdude]

It appears the eidogo plugin on L19 has patched this vulnerability:

(;CA[Windows-1252]SZ[19]
;B[pd]C[Does L19x19 eidogo have <b>XSS</b> vulnerability?];W[qc]C[<script>alert('Yes through script tag!');</script>];B[qd]C[<img src="/" onerror="alert('Yes through inline events!')">])

[Jhyn]

Public Security Announcement to WebMasters using EidoGo

Thank you for the time and efforts you spent for our benefit and your responsible approach to disclosure.

[fanfan]

I am the author of maxiGos (http://jeudego.org/maxiGos/index.php?lang=en) which is a sgf web player similar to eidogo.

MaxiGos has not this vulnerability.

Maybe this can help people that cannot patch eidogo easily themselves.

[RobertJasiek]

How to avoid the vulnerability as the programmer?

[uPWarrior]

Are you asking from the point of view of someone who develops eidogo-like applications, or from the perspective of someone who includes eidogo in their own website? I.e., is this about preventing XSS or about going around it in a case like this?

[Uberdude]

How to avoid the vulnerability as the programmer?

There's a lot of details and quirks, but it basically comes down to encoding things properly: if the user gives you some text don't give it verbatim to a browser which will interpret it as html.
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

[fanfan]

As a programmer, here are a couple of relatively simple things you can do:

1st possibility:
When parsing sgf data, remove html tag if any. The drawback is that some information will be lost. Some strings like <a> will be erased during the process even if they were not actually html tags (in the author mind).

Note that removing <script> tags only is not enough since some javascript can be inserted as value of event attributes in other tags such as img (but not only).

Note that some authors included such (non malicious) tags in sgf properties especially in C property to format the text or to display a link. But in theory, there is nothing in sgf specs that mention that sgf players have to render such html code as html. If you want to keep these tags, you have to use more sophisticated parsing methods.

2nd possibility:
Before displaying sgf data (i.e. when using document.write() or document.getElementById(id).innerHTML=... or any other methods that render html in a page), replace html entities by their html equivalent (i.e < replaced by &lt;, > replaced by &gt;, & replaced by &amp;, ...).

In practice, replacing only < and > probably could do the job. The drawback is that the tags will be displayed as is, and sometimes, this can be unwanted. For instance, if an author used a <b>...</b> tag to add a bold effect on a text, the <b> and </b> will be visible in the text by the end user.

There are many other possibilities. Everything is possible.

EDIT: and of course, never use eval() javascript function on sgf data as is, and remove any data in sgf that does nothing (such as characters before the first parenthesis).

[RobertJasiek]

Uberdude, fanfan, thank you.

uPWarrior, I ask to better understand surfing risks, webpage management, responsibility of webpage managers and as a potential programmer.

[YeGO]

Since I see links to EidoGo all the time … is there any news about this?

EidoGo appears to be an abandoned project. My issue report and pull request (patch submission) still remain open and unacknowledged by the developer.

The last I heard from the developer was on May 5, 2015, where he simply said via email "A pull request on github would be much appreciated. Thanks".

EidoGo.com remains vulnerable.
http://eidogo.com/#AKilSuG4

Several websites (including LifeIn19x19.com) were notified prior to the public disclosure.
The following sites have incorporated the patch to fix the vulnerability:
https://forums.online-go.com/
https://gtl.xmp.net/
http://gokifu.com/

LifeIn19x19.com continues to use the vulnerable version of EidoGo.

http://eidogo.com/backend/download.php?id=F7un2fo6

[DrStraw]

Does this just affect material read on the site or does it have potential to corrupt the users machine?

[uPWarrior]

It has the potential to corrupt the users machine, but I would think that unlikely. The potential exists.

A XSS vulnerability allows an attacker to run arbitrary javascript code on the user's browser. This implies that any information on the website can be modified/accessed (e.g. authentication tokens that could allow an attacker to pose as the user on that website), but in principle it shouldn't affect the user's machine itself.

However, vulnerabilities on web browsers sometimes allow permissions to escalate and arbitrary machine code to be executed (e.g., Remote code execution in IE10, Execute Code-vulnerabilities in Chrome, etc.).
While these remote-code executions typically require an user to view a specifically crafted webpage, if an attacker is able to run scripts on a remote host (e.g., lifein19x19), then no amount of common sense can protect the end user.

I think this is unlikely because it would require a) a random attacker to target eidogo, b) a knowledgeable attacker to target a site where XSS is possible (e.g., this site), c) unpatched browsers. I don't think this is a tempting enough target given the amount of work required, but is it possible? I would say definitely.

[Bonobo]

Thanks for your efforts, YeGo!

EidoGo appears to be an abandoned project. My issue report and pull request (patch submission) still remain open and unacknowledged by the developer.

The last I heard from the developer was on May 5, 2015, where he simply said via email "A pull request on github would be much appreciated. Thanks".

If it has been abandoned, couldn’t you then just grab it and make “ZweidoGo” out of it?
(“eins” is German for “one”, “zwei” is German for “two” )
Would there be moral objections? Or would it rather be technical problems? (I understand nothing of these things.)

EidoGo.com remains vulnerable.
http://eidogo.com/#AKilSuG4

Several websites (including LifeIn19x19.com) were notified prior to the public disclosure.
The following sites have incorporated the patch to fix the vulnerability:
https://forums.online-go.com/
https://gtl.xmp.net/
http://gokifu.com/

LifeIn19x19.com continues to use the vulnerable version of EidoGo.

[sgf … /sgf]

Nicely done

trusting you, I clicked …

Screen Shot 2016-04-05 at 22.49.18.png (16.97 KiB) Viewed 18603 times

So, if I understand correctly, this is executable HTML code within the SGF, right?

Code: Select all

<a onclick="alert('vulnerable')">CLICK</a>

For our L19 admins demigods: couldn’t perhaps Ilya Kirillov’s wonderful HTML5 Web Go Board extension/code be something to integrate here? I use it all the time and I LOVE it, and BTW it was there where I found the code (clicked the SGF link, another tab opened with the Web Go Board—and the code as comment at the beginning.

Screen Shot 2016-04-05 at 22.59.46.png (15.28 KiB) Viewed 18603 times

Thanks for the edutainment (if it weren‘t so sad)