How hard should I try to prevent a user from XSSing themselves?

Question

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?

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 01 '19 at 20:21
Can you be absolutely certain that the data will never be shown to any other user, especially including site admins? — pjc50, Apr 02 '19 at 08:20
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 02 '19 at 08:24
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 02 '19 at 12:31
Is it even possible to ever really prevent users from CSSing themselves? The user is in complete control over the browser and can therefore always inject code (e.g. by using a browser extension). — mastov, Apr 04 '19 at 09:54
@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 04 '19 at 15:00
Rather than ask "why?" I would ask, "Why not?" It's not as though properly escaping fetched data from the database is a lot of effort if you're using a halfway decent templating engine. Many (most?) will escape content automatically unless you explicitly prevent it. — jpmc26, Apr 04 '19 at 15:00

score 107 · Answer 1 · answered Apr 01 '19 at 20:28

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

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.

answered Apr 01 '19 at 20:28

Rory McCune

61,541
14
140
221

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 02 '19 at 08: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 02 '19 at 09:54
@reed good point, although in this scenario it could actually be persistent (i.e. the user stores data in the App which executes every time they view it) rather than the console attacks which are rather more ephemeral (usually). We could have "Console JavaScript Scam" and "Persistent JavaScript Scam"! – Rory McCune Apr 02 '19 at 14:01
2

Am I the only one disturbed that Facebook has access to the debug console and has shown a willingness to use it, even for a seemingly benign purpose? – Mason Wheeler Apr 02 '19 at 14:58
19

@MasonWheeler Why would you be disturbed by that specific thing? – Sumurai8 Apr 02 '19 at 15:24
2

@Sumurai8 In general, because the developer tools is supposed to be sacrosanct. It's one of the user's most important lines of defense against obnoxious or malicious content, and needs to remain completely outside of the sandbox that the webpage itself has access to. In this specific case, *because it's Facebook,* and they have a long history of malicious behavior and acting against the interests of their users. – Mason Wheeler Apr 02 '19 at 15:30
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 02 '19 at 15:49
@Alex Oh, if it's just a console log that's better. Good to hear they can't actually get into the devtools themselves. – Mason Wheeler Apr 02 '19 at 16:27
This isn't going to stop an attacker from using bookmarklets – Beefster Apr 02 '19 at 18:45
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: https://stackoverflow.com/questions/21692646/how-does-facebook-disable-the-browsers-integrated-developer-tools – Felipe Warrener-Iglesias Apr 03 '19 at 08:27
3

@FelipeWarrener-Iglesias Wow. They actually did it at one point. Yeah, that's seriously messed up. – Mason Wheeler Apr 03 '19 at 10:48
1

This very feature (console warning text) was a cause of security hole in one of the Android banking apps in Poland. Under Android there is no Chrome console, so this message was pushed to logcat, along with source URL which was the... SSO (Single Sign On) link. On Android 4.x an earlier other apps could intercept thi URL, which was prone to race condition and actually exploitable. So, be careful. More on that: https://usmile.at/symposium/2017/program/zielinski – tomash Apr 04 '19 at 12:09

meowcat · Answer 2 · 2019-04-03T21:08:11.680

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.

edited Apr 03 '19 at 21:08

answered Apr 01 '19 at 20:51

meowcat

1,349
1
6
16

1

This is the real issue – DreamConspiracy Apr 02 '19 at 07:03
19

They're both real issues. – Lightness Races in Orbit Apr 02 '19 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 02 '19 at 22:01
6

Poor little [Bobby Tables](https://www.xkcd.com/327/) – Wayne Werner Apr 03 '19 at 11:31
@SeldomNeedy I agree 100% with you, I meant to say that it was *Unexpected Behavior* that was difficult/impossible for computer illiterate people to troubleshoot/understand why the application kept crashing on them. I have updated the answer to reflect this. – meowcat Apr 03 '19 at 21:12
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 03 '19 at 21:18
@meowcat Wait... logs in the database so they would know who SQL injected them ?!?! meowcat: related point, text inside angle brackets doesn't show up even on SE posts... – Artemis Apr 04 '19 at 23:35

score 18 · Answer 3 · answered Apr 02 '19 at 10:44

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.

score 13 · Answer 4 · answered Apr 02 '19 at 11:59

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.

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 04 '19 at 08:21

score 6 · Answer 5 · answered Apr 02 '19 at 11:44

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.

dotancohen · Answer 6 · 2019-04-03T15:34:39.650

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.

shellster · Answer 7 · 2019-04-04T13:47:18.887

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.

score 2 · Answer 8 · answered Apr 04 '19 at 19:50

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.

score 0 · Answer 9 · answered Apr 04 '19 at 08:48

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, ..?

How hard should I try to prevent a user from XSSing themselves?

9 Answers9

Development Practices: Implications of Allowing Self-XSS