1

Is it possible to perform an XSS on the following:

<script> var name = "USER_INPUT";</script>

where USER_INPUT is given by the user. I have a filter for USER_INPUT which doesn’t accept < and " characters but accepts &quot. I do not use the variable name in the html and use it only for processing inside the script.

Sha
  • 29
  • 1
  • 6
  • How is the input given? How is it processed? – Sebastian Simon Apr 20 '18 at 03:49
  • Use a proven library that sanitizes user input. – Darkrum Apr 20 '18 at 03:49
  • @Xufox The input is given by the user. I use the variable to do some logic in the javascript. – Sha Apr 20 '18 at 03:53
  • @Darkrum Can you share me the payload? If XSS is possible. – Sha Apr 20 '18 at 03:53
  • @epascarello If it is possible, can you share me the payload? – Sha Apr 20 '18 at 03:53
  • https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet – epascarello Apr 20 '18 at 03:55
  • @ShatabdaMajumdar http://www.jsfuck.com – Darkrum Apr 20 '18 at 03:55
  • @epascarello Thanks. Since, " and < are not accepted by the filter. I could not find any payload that would work on this. – Sha Apr 20 '18 at 03:57
  • @Sha And again: _How_ is it given by the user? _What kind_ of logic are you doing with JavaScript? The answer entirely depends on how _precisely_ the input gets created and used. – Sebastian Simon Apr 20 '18 at 03:58
  • @Xufox I use it to do some validation based on the name. For example: If the name starts with A --> Some action. If it starts with B --> Some action. The input is given by the user in the form that loads. – Sha Apr 20 '18 at 04:02
  • read more at https://www.acunetix.com/websitesecurity/cross-site-scripting/ – v8-E Apr 20 '18 at 04:03
  • @Sha So then the answer is no. Getting an input from a form just produces a string, nothing more. Testing the string doesn’t make an attack possible. At least, if everything is done right, and if the browser doesn’t have any weird bugs, like JSON hijacking. – Sebastian Simon Apr 20 '18 at 04:04
  • @Xufox OP's a lost cause. Wait till he finds out Sanitation client side is pointless as you can open up the console and do whatever you want and that sanitation needs to be done server side before storing. One might argue that sanitation client side is good just in case the server doesn't do it's job right... But at that point you have a major issue. – Darkrum Apr 20 '18 at 04:04
  • to be honest, I think the OP is not asking how to prevent XSS, he twice asked for possible XSS payload ... smells like script kiddie – Jaromanda X Apr 20 '18 at 04:07
  • @JaromandaX I am actually testing out if it is possible to break this. – Sha Apr 20 '18 at 04:11
  • yeah, I know, but the code you presented is just an input - surely any XSS issues come from what you do with the text that is input. And since you've shown zero actual code (html isn't code) can't see how you could get any worthwhile help at all – Jaromanda X Apr 20 '18 at 04:24

5 Answers5

0

I think it is important to check the best practices for sanitizing user input for the programming language that you are using.

For example for php you can check this question: What's the best method for sanitizing user input with PHP?

enesn
  • 2,063
  • 1
  • 10
  • 13
  • I am sanitizing the input by filtering < and " characters. Is it still possible to perform XSS? Is there any payload for that? – Sha Apr 20 '18 at 03:59
  • Not on top of my head but I also came across a lot of other XSS types that I couldn't think of directly on https://xss-game.appspot.com/ So I cannot think something does not always mean there is no way. – enesn Apr 20 '18 at 04:11
0

Under the restrictions you have mentioned there is no immediate risk of XSS. Make sure that any user input with " or < is denied (not just replaced) even better only accept whitelisted characters (e.g [a-zA-Z0-9_ ]). To make sure the variable name is not used for any dangerous processing (like db query) in the future better give it a recognizable name like UNSAFE_name or something.

Moti Korets
  • 3,738
  • 2
  • 26
  • 35
0

If characters like backslashes, newlines, or html comment end tags are allowed, then they can at least break the formatting of the page or cause errors to be thrown, stopping the rest of the script from running.

There is also the risk of it easily becoming vulnerable if an extra variable is added. Like:

<script>var name = "USER_INPUT", name2 = "USER_INPUT2";</script>

Then, if USER_INPUT is \, and USER_INPUT2 is +alert(1)// then this will run a script.

fgb
  • 18,439
  • 2
  • 38
  • 52
0

You can test this payload: &qout; -alert(document.domain)- &quot;

famdude
  • 79
  • 1
  • 6
-1

It depends on what you do with the variable name. If you are going to eval it, than the XSS is possible.

Supportingly, If the user input is alert(1) and you are going to eval it without curing its value. i.e.

eval(name);

Or if you are going to inject the name into the DOM the XSS is possible as well.

Have a look at the below example.

const first = 'Wes';
const User_input = `I love to do evil <img src="http://unsplash.it/100/100?random" onload="alert('you got hacked');" />`;

const html = `
    <h3>${first}</h3>
    <p>${User_input}</p>
`;

const bio = document.body;
bio.innerHTML = html;

But if you are properly sanitizing the user_input you can reduce the chances to XSS attack.

There are ways to sanitize the user_input. How are you sanitizing? Can you Show?

Aefits
  • 3,399
  • 6
  • 28
  • 46