I was doing some pentesting on my little forum project. I found out, that it is possible to inject a javascript file through a little security hole. So basicly, the hacker can inject any javascript code he wants. Now, on the contrary to well known security issues, this hack is only working on the hackers side, because there is no data shown to other users, except the hacker himself.

The hack works in the user settings page where each user has access to his own settings only. So an alert would be shown only at the hackers computer.

I have fixed this already, but:

I am still curious about if this hack still could be dangerous for the project itself. Can a hacker do more damage with it than I think?

  • 2
    This is typically called "self-XSS". Commented Apr 22, 2018 at 20:48
  • Is it stored or reflected XSS?
    – Anders
    Commented Apr 23, 2018 at 8:36

2 Answers 2


Do you have CSRF protection on your logins? If not, I'd propose the following:

  • Create an account and store the XSS payload there.
  • Trick the victim to click a link that:
    • Logs them in to the above account using CSRF.
    • Redirects to the page with the stored XSS.
  • The payload logs the victim out with an AJAX request, and can modify the page as you see fit, e.g. display a login form.
  • Voila, you are running arbitrary JavaScript and can keylog passwords or whatever.

Granted, this requires a lot of user interaction and another vulnerability to work. But in my experiences, if there is an XSS vulnerability, it can be exploited no matter where it is.


If you are really sure that the injected code can only be executed by the same person who injected it, then it could indeed be classified as "self-XSS", as mentioned in a comment to your question. Apparently to exploit that an attacker needs to rely on social engineering, trying to trick other users into injecting the code themselves and execute it.


Anders's answer suggests a CSRF scenario but I don't agree with that (and I don't have enough reputation to comment there yet). However I just realized that a CSRF vulnerability can actually help the attacker to exploit your XSS. Anders's suggested using CSRF to log you in as the attacker and redirect to their page that had been previously infected. This way you'll find yourself executing arbitrary js, but you are logged in as the attacker and executing js on the attacker's private page. That seems pointless to me. The supposedly right option would be to use CSRF to inject the malicious code directly in the victim's page. It would work this way:

  1. the victim is currently logged in on your website
  2. the victim visits a malicious website that uses CSRF to inject the XSS in their own private page (for example a POST request to a form that changes their profile settings and put js in the vulnerable field)
  3. the victim visits their own private page and... now there's injected js there

This of course requires that the form on your website used to inject js is vulnerable to CSRF (for example because the form doesn't require a hidden secret token), so an attacker can force the victim to make a request to your website with serious consequences without the victim's consent, for example changing settings, passwords, or in this specific case injecting js. Read up on CSRF if you need to understand more.

  • Thank you for the answer. So basicly, the answer to my question is, no the hacker can't do more damage than I thought?
    – dkb
    Commented Apr 23, 2018 at 10:23
  • Not directly, but if they use social engineering to trick another user into injecting code (in their own settings?) and then execute it (by visiting their own settings?) then the attacker will make the other user execute arbitrary js in your website. How easily this can be achieved depends on lots of details, including gullibility. Some people will even copy-paste-execute code if you tell them "cute kittens will appear in your browser, try it!". It depends.
    – reed
    Commented Apr 23, 2018 at 10:33
  • I know but that's the point: There is no way to send victims to your own (or the hackers) settings.php. Imagine entering the code malicious code into the email-field. When loading settings.php, the code will run on your page only, because everyone has an other email (settings.php is dynamic).
    – dkb
    Commented Apr 24, 2018 at 8:06
  • @dkb I edited my answer to include a CSRF scenario after seeing Anders's answer and your discussion with him
    – reed
    Commented Apr 24, 2018 at 11:11
  • I think that this is bit OOT. Because I wanted info about the self-XSS that I previously detected. I am fully aware, that with XSS a hacker has way more options. But XSS requires the mailicious code runned by the victim. In my case, there is no option to let the malicious code run by someone else except by the hacker himself. That was the only reason why I asked, because for XSS the consequences would be sure, but I was not sure about self-xss possibilities. As what I found out so far, self-xss is not very dangerous.
    – dkb
    Commented Apr 24, 2018 at 11:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .