XSS Security Vulnerability #27

Open
yewang opened this Issue Jun 14, 2015 · 7 comments

Projects

None yet

4 participants

@yewang
yewang commented Jun 14, 2015

EidoGo is susceptible to Cross-Site Scripting (XSS) attacks via maliciously crafted SGF input.

There are actually two separate XSS vulnerabilities:

  1. Text from comments and game info are unsafely added into the DOM directly via innerHTML.
  2. Any file loaded from URL that begins with a left-curly bracket "{" is assumed to be JSON and unsafely parsed with eval.

Here are examples exploiting each vulnerability:
http://eidogo.com/#xqRLkZhw
http://eidogo.com/#AKilSuG4

A patch attempting to mitigate these security vulnerabilities was submitted in this pull request:
#26
See this pull request for more discussion of the changes.

Note that the pull request does not include an updated minified file. However, a minified file incorporating this patch has been prepared by the OGS developers and is available here:
http://cdn.online-go.com/eidogo.min.js
Compare with:
https://raw.githubusercontent.com/jkk/eidogo/master/player/js/all.compressed.js

The identifier "CVE-2015-3172" has been assigned to refer to this issue.

Disclosure timeline:
April 7, 2015: Privately notified developer of security vulnerability
April 13: Developer acknowledged notification
May 12: Pull request submitted (as requested by developer)
May 14: Webmasters of several affected sites notified in advance
June 14: Public disclosure (having not heard back from developer since before the pull request)

@yewang yewang referenced this issue Jun 14, 2015
Open

Security Patch #26

@mounty1
mounty1 commented Feb 9, 2016

Just for the record, and not to detract from the significance of this vulnerability: this is a reflected JS vulnerability in that the malicious game data are uploaded to the server and then re-sent to the browser.

@yewang
yewang commented Feb 9, 2016

Are you sure that "reflected" is the correct terminology? It seems that "reflected" applies specifically to "non-persistent" attacks that originate from malicious payload that is somehow placed in the victim's request. I believe this security vulnerability should be categorized as "persistent" or "stored", since an attacker can upload a malicious SGF file to eidogo.com which will then threaten any victim that later visits the particular page for that file. On various forums using eidogo as an embedded SGF viewer, an attacker can upload a malicious SGF file that will then threaten any victim that later visits that particular forum post.

http://excess-xss.com/#xss-attacks
https://en.wikipedia.org/wiki/Cross-site_scripting#Types

@mounty1
mounty1 commented Feb 9, 2016

Sorry; you are correct. It is reflected in that it goes to the server and back again, but the fact that it is stored and can be retrieved by anyone, later, makes it stored.

@dwt
dwt commented Mar 24, 2016

@developers: ping?

Is this project still alive?

Are you searching for new maintainers?

@yewang
yewang commented Mar 25, 2016

Unfortunately, this project appears to be abandoned.

The last I heard from the developer was via an email on May 5, 2015, which simply stated

A pull request on github would be much appreciated

in response to my offer to help resolve the bug. The only other communication I have had from the developer was an earlier email on April 13, 2015 in response to my initial disclosure:

I appreciate you uncovering this issue and sharing it with me responsibly. I am swamped with work right now, and the EidoGo code base is old and somewhat neglected, so unfortunately I can't make fixing this a priority right away. I'll try to get a fix out as soon as I'm able."

The code is quite stale and neglected. Note that:

  • several old issues and pull requests remain open and unacknowledged.
  • the last commit to the entire project was nearly 3 years ago (Apr 2013).
  • the core javascript code for the front-end/embeddable player (eidogo/player/js) has not seen a commit since Sept 2008.
@nerai
nerai commented Apr 5, 2016

Am I mistaken or was CVE-2015-3172 not published yet, even though its content is pretty much here (and in public)? It would make sense to keep the information consistent there. And thank you for your discovery and disclosure!

@yewang
yewang commented Apr 6, 2016

@nerai good point. I forgot to follow up on that, but I just now sent an email to the CVE ID assignment body with a link to this public disclosure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment