I own a chat site {https://trixac.com}. It uses BoomChat's code. Recently I banned a troll and now he is back and hes running XSS injections against my site and it's working for some odd reason. I've checked the php code of my site and it seems to filter user-input pretty nicely. Can't seem to find any vulnerabilities, I am not sure what should be done here as to how to prevent him from injecting.

These are the php filters of my site:

    if ($_POST['content'] != null){

        $bold = $mysqli->real_escape_string(trim($_POST['bold']));
        $italic = $mysqli->real_escape_string(trim($_POST['italic']));
        $underline = $mysqli->real_escape_string(trim($_POST['underline']));
        $chigh = $mysqli->real_escape_string(trim($_POST['high']));
        $ccolor = $mysqli->real_escape_string(trim($_POST['color']));
        $content = $mysqli->real_escape_string(trim($_POST['content']));
        $content = htmlspecialchars($content);
        $content = "$content ";

The htmlspecialchars should stop the attacks since it filters out the <, without it script tags won't work. I've tried few examples from the OWASP XSS cheat-sheet yet I can't seem to know how hes still able to inject. I've also tried all the possible user-input fields, all are pretty secure. The hacker uses DOM manipulation to run porn as the background of my site, or redirect users to porn-hub whenever he pleases. Hes also managed to mute us all and much more.

For more detail: His attacks are based purely on JavaScript. I've tried removing the "htmlspecialchars" function and after that anyone can do XSS with JS. So the problem pertains with htmlspecialchars somehow

  • Did you add the htmlspecialchars line yourself, or was it already there in the original code? If the attacks continue then maybe they are exploiting a different bug anyway. If it's XSS, you need to check where the malicious JS code appears in the page, that might help you to understand what unsanitized parameter is used for the injection. – reed Jun 13 '19 at 21:08
  • I had to add the htmlspecialchars myself. The original code is without it. Tbh i think its more of a logic bug, and thanks for the advice. – user210066 Jun 13 '19 at 21:56

Mitigations for XSS attacks are not typically restricted to input filtering as you’re describing and attempting, as you’re experiencing it’s like playing whackamole with possible filter bypasses. That’s why the Filter Evasion cheat sheet from OWASP exists.

Any untrusted input that’s reflected in a browser response needs to be output encoded. For example with html encoding the < char becomes &lt; in the http response and the browser does not treat it as the entry of a tag. Also, setting appropriate content-type headers for the response. Basically, start by understanding this well: OWASP XSS Prevention Cheat Sheet

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy