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

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

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?

asked Apr 1 at 20:04

gaazkam

1,59631021

8

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 at 20:21

18

Can you be absolutely certain that the data will never be shown to any other user, especially including site admins?

– pjc50
2 days ago

9

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
2 days ago

12

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
2 days ago

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
14 hours ago

|
show 2 more comments

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?

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

asked Apr 1 at 20:04

gaazkam

1,59631021

8

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 at 20:21

18

Can you be absolutely certain that the data will never be shown to any other user, especially including site admins?

– pjc50
2 days ago

9

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
2 days ago

12

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
2 days ago

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
14 hours ago

|
show 2 more comments

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?

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

asked Apr 1 at 20:04

gaazkam

1,59631021

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?

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

xss attacks

asked Apr 1 at 20:04

gaazkam

1,59631021

asked Apr 1 at 20:04

gaazkam

1,59631021

asked Apr 1 at 20:04

gaazkam

1,59631021

asked Apr 1 at 20:04

gaazkam

1,59631021

asked Apr 1 at 20:04

gaazkam

1,59631021

8

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 at 20:21

18

Can you be absolutely certain that the data will never be shown to any other user, especially including site admins?

– pjc50
2 days ago

9

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
2 days ago

12

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
2 days ago

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
14 hours ago

|
show 2 more comments

8

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 at 20:21

18

Can you be absolutely certain that the data will never be shown to any other user, especially including site admins?

– pjc50
2 days ago

9

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
2 days ago

12

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
2 days ago

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
14 hours ago

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 at 20:21

Can you be absolutely certain that the data will never be shown to any other user, especially including site admins?

– pjc50
2 days ago

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
2 days ago

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
2 days ago

@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
14 hours ago

|
show 2 more comments

9 Answers
9

active

oldest

votes

101

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.

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

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
2 days ago

32

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
2 days ago

19

@MasonWheeler Why would you be disturbed by that specific thing?

– Sumurai8
2 days ago

41

@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
2 days ago

5

@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/…

– Felipe Warrener-Iglesias
yesterday

|
show 7 more comments

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 yesterday

answered Apr 1 at 20:51

meowcat

65018

1

This is the real issue

– DreamConspiracy
2 days ago

19

They're both real issues.

– Lightness Races in Orbit
2 days ago

27

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.

– SeldomNeedy
2 days ago

6

Poor little Bobby Tables

– Wayne Werner
yesterday

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
yesterday

|
show 2 more comments

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.

answered 2 days ago

reed

3,1243826

add a comment |

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.

answered 2 days ago

Anders

49.8k22143165

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.

– Carl Leth
20 hours ago

add a comment |

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.

answered 2 days ago

zero298

21219

add a comment |

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.

edited yesterday

answered 2 days ago

dotancohen

2,47231933

add a comment |

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.

edited 15 hours ago

answered yesterday

shellster

52734

add a comment |

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.

answered 9 hours ago

taswyn

21816

add a comment |

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

answered 20 hours ago

n0idea

1285

New contributor

add a comment |

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206579%2fhow-badly-should-i-try-to-prevent-a-user-from-xssing-themselves%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

9 Answers
9

active

oldest

votes

9 Answers
9

active

oldest

votes

101

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

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

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
2 days ago

32

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
2 days ago

19

@MasonWheeler Why would you be disturbed by that specific thing?

– Sumurai8
2 days ago

41

@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
2 days ago

5

@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/…

– Felipe Warrener-Iglesias
yesterday

|
show 7 more comments

101

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

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

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
2 days ago

32

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
2 days ago

19

@MasonWheeler Why would you be disturbed by that specific thing?

– Sumurai8
2 days ago

41

@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
2 days ago

5

@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/…

– Felipe Warrener-Iglesias
yesterday

|
show 7 more comments

101

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

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

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

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

answered Apr 1 at 20:28

Rоry McCune

53.3k14114189

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
2 days ago

32

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
2 days ago

19

@MasonWheeler Why would you be disturbed by that specific thing?

– Sumurai8
2 days ago

41

@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
2 days ago

5

@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/…

– Felipe Warrener-Iglesias
yesterday

|
show 7 more comments

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
2 days ago

32

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
2 days ago

19

@MasonWheeler Why would you be disturbed by that specific thing?

– Sumurai8
2 days ago

41

@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
2 days ago

5

@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/…

– Felipe Warrener-Iglesias
yesterday

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
2 days ago

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
2 days ago

@MasonWheeler Why would you be disturbed by that specific thing?

– Sumurai8
2 days ago

@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
2 days ago

@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/…

– Felipe Warrener-Iglesias
yesterday

|
show 7 more comments

<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 yesterday

answered Apr 1 at 20:51

meowcat

65018

1

This is the real issue

– DreamConspiracy
2 days ago

19

They're both real issues.

– Lightness Races in Orbit
2 days ago

27

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.

– SeldomNeedy
2 days ago

6

Poor little Bobby Tables

– Wayne Werner
yesterday

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
yesterday

|
show 2 more comments

<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 yesterday

answered Apr 1 at 20:51

meowcat

65018

1

This is the real issue

– DreamConspiracy
2 days ago

19

They're both real issues.

– Lightness Races in Orbit
2 days ago

27

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.

– SeldomNeedy
2 days ago

6

Poor little Bobby Tables

– Wayne Werner
yesterday

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
yesterday

|
show 2 more comments

<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 yesterday

answered Apr 1 at 20:51

meowcat

65018

<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 yesterday

answered Apr 1 at 20:51

meowcat

65018

edited yesterday

answered Apr 1 at 20:51

meowcat

65018

answered Apr 1 at 20:51

meowcat

65018

answered Apr 1 at 20:51

meowcat

65018

1

This is the real issue

– DreamConspiracy
2 days ago

19

They're both real issues.

– Lightness Races in Orbit
2 days ago

27

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.

– SeldomNeedy
2 days ago

6

Poor little Bobby Tables

– Wayne Werner
yesterday

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
yesterday

|
show 2 more comments

1

This is the real issue

– DreamConspiracy
2 days ago

19

They're both real issues.

– Lightness Races in Orbit
2 days ago

27

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.

– SeldomNeedy
2 days ago

6

Poor little Bobby Tables

– Wayne Werner
yesterday

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
yesterday

This is the real issue

– DreamConspiracy
2 days ago

They're both real issues.

– Lightness Races in Orbit
2 days ago

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.

– SeldomNeedy
2 days ago

Poor little Bobby Tables

– Wayne Werner
yesterday

@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
yesterday

|
show 2 more comments

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>

answered 2 days ago

reed

3,1243826

add a comment |

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>

answered 2 days ago

reed

3,1243826

add a comment |

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>

answered 2 days ago

reed

3,1243826

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>

answered 2 days ago

reed

3,1243826

answered 2 days ago

reed

3,1243826

answered 2 days ago

reed

3,1243826

answered 2 days ago

reed

3,1243826

add a comment |

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.

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.

answered 2 days ago

Anders

49.8k22143165

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.

– Carl Leth
20 hours ago

add a comment |

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.

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.

answered 2 days ago

Anders

49.8k22143165

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.

– Carl Leth
20 hours ago

add a comment |

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.

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.

answered 2 days ago

Anders

49.8k22143165

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.

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.

answered 2 days ago

Anders

49.8k22143165

answered 2 days ago

Anders

49.8k22143165

answered 2 days ago

Anders

49.8k22143165

answered 2 days ago

Anders

49.8k22143165

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.

– Carl Leth
20 hours ago

add a comment |

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.

– Carl Leth
20 hours ago

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.

– Carl Leth
20 hours ago

add a comment |

answered 2 days ago

zero298

21219

add a comment |

answered 2 days ago

zero298

21219

add a comment |

answered 2 days ago

zero298

21219

answered 2 days ago

zero298

21219

answered 2 days ago

zero298

21219

answered 2 days ago

zero298

21219

answered 2 days ago

zero298

21219

add a comment |

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

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.

edited yesterday

answered 2 days ago

dotancohen

2,47231933

add a comment |

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

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.

edited yesterday

answered 2 days ago

dotancohen

2,47231933

add a comment |

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

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.

edited yesterday

answered 2 days ago

dotancohen

2,47231933

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

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.

edited yesterday

answered 2 days ago

dotancohen

2,47231933

edited yesterday

answered 2 days ago

dotancohen

2,47231933

answered 2 days ago

dotancohen

2,47231933

answered 2 days ago

dotancohen

2,47231933

add a comment |

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

edited 15 hours ago

answered yesterday

shellster

52734

add a comment |

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

edited 15 hours ago

answered yesterday

shellster

52734

add a comment |

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

edited 15 hours ago

answered yesterday

shellster

52734

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

edited 15 hours ago

answered yesterday

shellster

52734

edited 15 hours ago

answered yesterday

shellster

52734

answered yesterday

shellster

52734

answered yesterday

shellster

52734

add a comment |

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.

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"?

answered 9 hours ago

taswyn

21816

add a comment |

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.

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"?

answered 9 hours ago

taswyn

21816

add a comment |

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.

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"?

answered 9 hours ago

taswyn

21816

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.

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"?

answered 9 hours ago

taswyn

21816

answered 9 hours ago

taswyn

21816

answered 9 hours ago

taswyn

21816

answered 9 hours ago

taswyn

21816

add a comment |

answered 20 hours ago

n0idea

1285

New contributor

add a comment |

answered 20 hours ago

n0idea

1285

New contributor

add a comment |

answered 20 hours ago

n0idea

1285

New contributor

answered 20 hours ago

n0idea

1285

New contributor

answered 20 hours ago

n0idea

1285

New contributor

answered 20 hours ago

n0idea

1285

answered 20 hours ago

n0idea

1285

New contributor

n0idea is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Information Security Stack Exchange!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Cfxtrjtrk