enisaeu / ecsc-gameboard

European Cyber Security Challenge Gameboard

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Robustness issues

floyd-fuh opened this issue · comments

commented

This looks suspicious:

https://github.com/enisaeu/ecsc-gameboard/blob/master/html/index.php#L165

With a request like

POST /contracts/ HTTP/1.1
Host: board.ecsc.eu
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://board.ecsc.eu/contracts/
Content-Type: application/x-www-form-urlencoded
Content-Length: 86
Connection: close
Cookie: PHPSESSID=<REDACTED>
Upgrade-Insecure-Requests: 1

token=<REDACTED>&task_id=2%22]);
alert(123);&answer=a

We get:

<script>
            $(document).ready(function() {
                var element = $("[name=task_id][value=2&quot;]);
alert(123);]");

                $([document.documentElement]).animate({scrollTop: $(element.closest(".card")).offset().top}, "fast", function() {
                    wrongValueEffect($(element).closest(".card-body"));
                });
            });
        </script>

in the response. htmlspecialchars is not enough usually to protect against XSS in JavaScript context, but I wasn't able to exploit this (and even then it would be a self-XSS at first) while trying for a couple of minutes because I can't seem to be able to inject double quote, but again, there might be JavaScript engines that treat it differently or whatever... Being able to inject a newline seems not too good.

Moreover, an independent issue from the above, this is also problematic:

https://github.com/enisaeu/ecsc-gameboard/blob/master/html/index.php#L326

As openInNewTab('<?php echo joinPaths(PATHDIR, '/chat');?> will use define("PATHDIR", dirname(htmlspecialchars($_SERVER["PHP_SELF"], ENT_QUOTES, "utf-8"))); and PHP_SELF might be exploitable with URL paths and again, this is a JavaScript context where htmlspecialchars might not be sufficient... Again, in my tests PHP_SELF was set fine and this might be because of the mod_rewrite conditions.

Anyway, I think if we could get some more robust filtering in these places, this would all be more robust.

And if you are touching the code, you might as well want to get rid of the login_name stored XSS that would arise if teams would be able to change their names or signup with an arbitrary team name.

Can you please do your best and try to provide an useful payload? there might be or might not be sufficient do not seem to be good arguments in this kind of reports.

@floyd-fuh with the latest revision, both newline and funky PHP_SELF are addressed