Robustness issues
floyd-fuh opened this issue · comments
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"]);
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