60

Let's say a user can store some data in a web app. I'm now only talking about that sort of data the user can THEMSELVES view, not that is intended to be viewed by other users of the webapp. (Or if other users may view this data then it is handled to them in a more secure way.)

How horrible would it be to allow some XSS vulnerability in this data?

Of course, a purist's answer would clearly be: "No vulnerabilities are allowed". But honestly - why?

Everything that is allowed is the user XSSing THEMSELVES. What's the harm here? Other users are protected. And I can't see a reason why would someone mount an attack against themselves (except if it is a harmless one, in which case - again - no harm is done).

My gut feelings are that the above reasoning will raise some eyebrows... OK, then what am I failing to see?

Improve this question
7
  • 9
    How can you limit the scope of an XSS vuln to just some data? This is asking to open the door to everything getting compromised. Don't be lazy with it
    – Crumblez
    Apr 1, 2019 at 20:21
  • 19
    Can you be absolutely certain that the data will never be shown to any other user, especially including site admins?
    – pjc50
    Apr 2, 2019 at 8:20
  • 10
    Also: You write "How badly should I try" - that looks like you believe preventing XSS will be difficult. Why is that? Normally, properly escaping everything on output shoudl be enough.
    – sleske
    Apr 2, 2019 at 8:24
  • 13
    How often do you think people randomly copy&paste stuff from the internet? Ever heard of social engineering? Allowing self XSS is equivalent to allowing full XSS, IMHO.
    – Giacomo Alzetta
    Apr 2, 2019 at 12:31
  • 1
    @pjc50 - This exactly! The problem with programming something insecure/risky with the thought "well, it's not technically a problem because of XYZ" - is that you have to remember XYZ for perpetuity. "We got a new request - users want to be able to browse the formerly-private profile pages of each other." "We got a new request - admins need to be able to browse user content pages." "We got a new request - each day we want to grab the 'Inspirational Quote' from a random user and put it below our main banner". Etc.
    – Kevin
    Apr 4, 2019 at 15:00

9 Answers 9

Reset to default
107

This is actually a real concept, "Self XSS" which is sufficiently common that if you open https://facebook.com and then open the developer tools, they warn you about it as shown here

Obviously Facebook is a specific type of target and whether this issue matters to you or not, would depend on the exact nature of your site, but you may not be able to discount the idea of one user using social engineering techniques to get another user to attack themselves.

Improve this answer
12
  • 7
    I believe the Discord app (program, not the browser version) has the same type of message if you open the console with the shortcut Ctrl + Shift + I.
    – user7393973
    Apr 2, 2019 at 8:17
  • 36
    It's worth noting that this is a social engineering issue that would still exist even if the OP fixed all the vulnerabilities on their website. The user executes code in the console. In fact, IMO "self XSS" is a misnomer. Maybe we should call it "javascript scam" or something.
    – reed
    Apr 2, 2019 at 9:54
  • 19
    @MasonWheeler Why would you be disturbed by that specific thing?
    – Sumurai8
    Apr 2, 2019 at 15:24
  • 42
    @MasonWheeler any JS from any website can output to the debug console with console.log and it's sister functions - they can't actually manipulate the devtools in any way
    – Alex
    Apr 2, 2019 at 15:49
  • 6
    @MasonWheeler although you were a little off-base with your assumptions about some simple console-logging, your concern regarding Facebook messing with developer tools more than they need t is pretty reasonable. See this question regarding Facebook using a Chrome bug to disable the console, in order to combat scams: stackoverflow.com/questions/21692646/…
    – fwr nr
    Apr 3, 2019 at 8:27
39

Although you are right in that it might not matter so much from an attack point of view. From a usability point of view, the user might come across some 'unexpected behavior'. A while ago I used to have to work with software that had an obvious SQL injection problem (contractors couldn't/wouldn't fix it). This meant that unexpecting users would enter in something seemingly harmless such as their name "O'Brien", which would trigger an SQL injection and for computer illiterate people it was unexpected behavior, that was extremely difficult for them to troubleshoot. It is probably less likely with XSS, however consider the following if a user uses <> instead of () the data might seem to disappear. A proof of concept is below:

<html>
    <head><title>HI</title></head>
    <body>
        <h1>WEBSITE</h1>
        Hey my name is <travis>.
    </body>
</html>

Note that when this website is rendered, the word 'travis', is not rendered.

Improve this answer
7
  • 1
    This is the real issue
    – DreamConspiracy
    Apr 2, 2019 at 7:03
  • 19
    They're both real issues.
    – Lightness Races in Orbit
    Apr 2, 2019 at 12:34
  • 29
    Being able to break an application by putting strange symbols into input-fields is unexpected behavior regardless of the user's computer-literacy; plenty of programmers named O'Brien probably expect that their name isn't some kind of impossible problem for a decent site to handle.
    – Seldom 'Where's Monica' Needy
    Apr 2, 2019 at 22:01
  • 6
    Poor little Bobby Tables
    – Wayne Werner
    Apr 3, 2019 at 11:31
  • 4
    @WayneWerner lol yes, the contractors reasoning for not fixing the issue was because only trusted people could use the application, and they had logs of who did what on the system, so thy would know who SQL injected them... even though the logs where stored in the database... sigh.
    – meowcat
    Apr 3, 2019 at 21:18
18

If the only way to insert malicious code is to literally type it on your webpage, then the attack vector would be "self xss", which was mentioned in another answer, and which is a social engineering attack you can't really prevent.

But if malicious code can also be loaded in other ways on your page, then you have a bigger problem. For example, if your website is vulnerable to reflected XSS or CSRF, an attacker can use those to make the user load malicious code.

Example of reflected XSS: if the data parameter is printed on the page without sanitizing it, an attacker can make the victim browse to the following URL to make them load malicious code.

https://www.example.com/search?data=<script src="..."></script>

Example of CSRF: if the submitted data is then printed on the page without sanitizing it and there's also no protection against CSRF, an attacker can make the victim post malicious data. 

<form method="post" action="submit">
    <input type="text" name="title">
    <input type="text" name="note">
    <input type="submit" value="submit">
    <!-- NO TOKEN TO PREVENT CSRF HERE!!! -->
</form>

As you can see the problem is not only "who can see the data", but also "who can enter the data". But even if you were sure that the above examples don't apply to your situation, why should you still try to avoid XSS and always try to sanitize the data? Because sanitization should become a habit even if in some situations it might not seem really useful. If sanitization is not a habit, sooner or later you will forget to sanitize something that eventually leads to XSS.

Improve this answer
13

XSS is still bad, even if it the payload is tied to the account that created it. Sure, it's not as bad as "ordinary" XSS, but it's still not harmless.

Here's an example of an attack: First, I need to get the victim to login as me. This can done through social engineering or login CSRF if there is no protection against that. Second, I have the victim visit the affected page logged in as me. The script then adds a keylogger to the site, so when the victim logs out and tries to login as themself, I get sent their password.

There are many reasons an attack like this would fail, but it might just work. You should plug any and all XSS holes, no matter where they are.

Improve this answer
1
  • 1
    I like this answer because someone offering "oh just log in as me and fix it real quick" is a very counter-intuitive way for them to attack you. I can imagine this working on even security-conscious people and it nicely addresses OP's constraints.
    – JounceCracklePop
    Apr 4, 2019 at 8:21
6

I think there is another use case that may not be listed in the answers so far which is the accidental self XSS. Some users may run into an issue that they encounter on a site and may start googling for drop-in solutions that they copy and paste. Carefully crafted "solutions" could cause trouble.

The scope of the attack is for the user to accidentally self-harm, but would be unlikely to harm other users. This is similar to how it can be dangerous to copy and paste bash commands that you find on the internet. A malicious site might offer linux help, but subtely include some command that might exfiltrate user data in some way.

Improve this answer
5

Allowing ostensibly "self-XSS" attacks may have secondary ramifications.

As an example, I recently saw an issue where a text field would, according the the bug report, remove all text after a Less-Than Sign. The browser was interpreting the Less-Than Sign as the start of an HTML tag.

Another issue that I've seen is that such "self-XSS" fields do not allow any arbitrary valid input. For instance, consider a "notes" field, in which the user may wish to store something that they learned:

One can make bold text by surrounding it with these tags: <b>Hello, bold world!</b>

If your application allows "self-XSS" attacks, then the user will have difficulty adding such a note.

Improve this answer
2

Something not mentioned in other answers, is the potential secondary security issues that can arise from a self-XSS.

Suppose your app has some really powerful/dangerous functionality that requires the user to enter their password again, such as changing an old password, or allowing a third-party to access their account. An attacker might gain access to the account temporarily via an attack like cookie-jacking, idle session (user away from their desk), or a cross-site-request-forgery (CSRF). In any of these cases the attacker wouldn't be able to directly perform these powerful actions because they wouldn't know the users password. However, they could take advantage of the self-XSS vulnerability to perform a very convincing social-engineering attack to get the users credentials or setup an XSS payload to give them persistent access to the user's account (every time the user logs in).

In the case of CSRF, a relatively harmless action might be transformed into a powerful attack by using the CSRF to cause a stored self-XSS that then gives the attacker access to the user's cookies, or browser session. I've actually used this attack chain technique several times when demonstrating vulnerabilities to developers.

Improve this answer
2

There are some great answers here from a pure security perspective. The self-XSS angle is absolutely correct, even if the top one related to that didn't explicitly make the connection it implies.

Being, essentially, that if people can get tricked into dropping self-XSS code into the dev console, why would you expect them not to not get tricked into dropping into some input element in your UI?

Some other answers tie that together into how this can create broader issues when it (imo, inevitably, if someone gets tricked into self-XSSing) leads to account compromises.

I think those are probably the top, immediate reasons. But I'd still like to address this from another angle:

Development Practices: Implications of Allowing Self-XSS

Let's say a user can store some data in a web app. I'm now only talking about that sort of data the user can THEMSELVES view, not that is intended to be viewed by other users of the webapp.

The problem with your supposition here is that it assumes that you don't prevent XSS on all output of user provided data as a default practice: ideally as the default output mechanism of the class or function used to retrieve and output data, with any deviation requiring a specific parameter to select the different output filtering method.

If you don't have your application coded in such a way that the default method of output prevents XSS (and different output targets such as attributes versus elements require different methodologies for what is and isn't allowed, hence 'default'), and it requires more effort (not less) to target output to allow (hopefully whitelisted, "purified") something to go through as native HTML/etc...

How sure are you that you aren't going to have an accident where some reflection of user data back to the web doesn't allow XSS outside of just "data the user can THEMSELVES view"?

Because mistakes happen. People forget steps when writing code. Failures occur in training where key points or even topics get missed. Some people do not "RTFM": even developers. Your application architecture/framework should be all about making sure that the path of least resistance when writing code is always the safest outcome, not the least safe outcome.

Allowing XSS to potentially occur based on user input should require a positive action, an explicit choice by the developer in relation to each place this might occur, not simply be the basic, default outcome of pulling stored user data and reflecting it back out. If your code is not being written like this, where it prevents XSS by default and requires an override parameter of some kind to disable this output purifying, then it's a sign that you need to re-evaluate your process.

Improve this answer
0

Although in this context we focus on the technical consequences of allowing a self-XSS, we should also take into consideration the impact of such a thing as a business: a self-XSS could cause unexpected behaviours (affecting user experience), so how should a user feel/react when running into it?

Furthermore, considering that an XSS vulnerability is easily avoidable, is it really worth not to worry about it? Just think about any possible consequence: opened support tickets, reported bugs, user discontent, ..?

Improve this answer

You must log in to answer this question.

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