EidoGo Security Vulnerability Alert

Announcements
1

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.

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 OGS) were notified to allow them to address this security issue in advance of wider public disclosure.

6 Likes
2

I hope that L19 is aware of this … are you posting this there, too?

3

I notified their admins via PM a month ago along with the other webmasters.

I just copied this public announcement to that forum.

1 Like
4

Wow, I can’t believe it’s been over a decade since I disclosed this security vulnerability. Amazingly, the EidoGo website is still running the vulnerable code, as can be tested via these two examples that I included in the original bug report

3 Likes
5

To celebrate this 10th anniversary, here is another example:

7 Likes
6

Isn’t EidoGo a completely abandoned site (i.e., no one is in charge of it anymore)?

2 Likes
7

I believe that the code development is essentially abandoned. There have been no updates to the public code repo in over 12 years, and apparently no updates to the website in that duration, as well.

However, the website is still operating, so someone must still be paying for the hosting / domain registration fees. Ostensibly, the developer, Justin Kramer, is in charge of this website, even though he seems to have taken an entirely passive approach.

Here’s another security issue, disclosed a few years ago, that also remains unmitigated

4 Likes
8

Stupid question: is there an html tag that makes it so its entire content is treated as text (rather than, for example, more html code).

If such a thing exists, it could be used to “sanitize” user input.

But now that I think about it, I can see the difficulties, since how can an html parser know where the corresponding end tag is supposed to be …

5 Likes
9

For JavaScript that generates HTML based on user content, setting the element contents via innerText or textContent would be a safe way to handle things.

However, the trouble with EidoGo is that the JavaScript code is very messily and widely relying upon innerHTML to construct the interface, and it would require major refactoring effort to properly address this unsafe programming practice that is pervasive throughout the code. Further, it seems to be a design decision to specifically support HTML content within SGF comments / game info fields, which makes the assumption that it would be safe to do so. Of course, this assumption is not true in places where users may give arbitrary SGF files (such as on the EidoGo site and several end users that employed EidoGo as a tool to display user-uploaded SGF files).

My patch only puts a band-aid on this problem, by manually escaping special HTML characters (“<”, “>”, and “&”) during SGF loading, which disables HTML content within SGF files. However, my patch does not fix the underlying unsafe overuse of innerHTML throughout EidoGo. In fact, EidoGo is still susceptible to reflected XSS attacks, where a malicious actor convinces a victim user to copy-paste malicious HTML code into a comment or game info field of the EidoGo interface.

Note that the disclosure also mentions a completely separate XSS vulnerability caused by the unsafe parsing of JSON content via eval. I believe that it is quite likely that there are still other security vulnerabilities that have not yet been discovered and/or disclosed.

4 Likes