Understanding XSS attacks ...

[pepe_lepew1962]

Hello:

I am really trying to understand XSS attacks and can't seem to wrap my head around it, I would rather seem like a fool than program like one with holes in it. My problem is understanding how an attack occurs. Let's say Mary logs into the system and creates a record in the table via an html form. I have php filters and validation for the data before it actually goes into mysql table. My question is how does John attack my website? Or more important, how does he actually change files? If he were to have a log in
and gains access because it doesn't take much to register, how? Is it a matter of the filter being bad and his XSS scipt is in a record and when someone open/views that record (field) the script is launched? I have read lots on how the javascript, for example, is placed in the url or form fields but nothing explains whether the information is saved and launched via the record stored in the database.

[djr33]

Well, I'm a little hesitant to post attack methods here (for obvious reasons), but it's not really that hard to figure out (and I'm sure you can google it and find the info somewhere). So, with the details left out and for the purpose of preventing such attacks, here's a brief explanation of how it works:

An XSS attack is fairly straightforward: get some code onto one site and then steal information and send it to another site.

The way to prevent it is equally straightforward: don't allow users to put that kind of code on your site.


Ok, so what kind of code is it? How can it be blocked? And what kind of information can they steal?

Although I suppose it could be any client side language, of course Javascript is the most common. (You might also want to watch out for Flash or other objects.)
Unfortunately there isn't a 100% reliable way to filter out the "good" JS from the "bad" JS, so the simple answer for security is to stop your users from ever using Javascript. In fact, it's best to not let them use HTML at all. There's another benefit to that as well: if they can't edit the HTML (or JS) directly, then they can't create errors in your page (like leaving a tag open).

So that's why BB code (like the markup allowed in posts here) is so common. It's a way to allow users to indirectly use some styling from HTML but not have full access. A less common alternative is to allow some HTML codes but not others-- that's a little harder to program, and perhaps even a little harder for the users.
And in no circumstances should you allow them to post Javascript. (You could have a specific BB code tag that ends up adding some Javascript, maybe a label when you hover on an object, but not user-defined JS.)

The information they can steal is potentially private information intended to be sent from the user's computer to your website (based on the domain name). The most common case is cookies.
Cookies are bits of information that store anything from page counts or color preferences to usernames and passwords.
Cookies are "secure" only in the sense that they are only sent to the matching domain name-- a cookie for google won't ever be sent to the yahoo server.

Likewise, the cookies are available to Javascript that is operating on a certain domain, but not available for Javascript operating on another domain.

Now we get to how the attacks occur: malicious Javascript that was inserted into the page has access to the cookie information just like any other Javascript on the page. Then (through a few tricks) the Javascript then sends this information back to a different server. (There are security restrictions against many methods for this; but there are still some holes, such as images that can be loaded from any domain via JS and in fact in the request for that image data can be sent to the server-- it's complicated, but possible.)


The end result is that the "private" communication between the user and your computer has now been overheard (and potentially copied) by the XSS Javascript and sent to some other server.

Cookies are the most common problem, but it could be any information on the website. It needs to be private information to be relevant, so obviously the standard HTML that everyone sees isn't a problem. But here's a short list:
1) Cookies-- if your cookie contains your username, an XSS attack can steal that. Or anything else in the cookies.
2) User-specific HTML content. If you have information coming from a database for example, then Javascript could see the HTML on the page. If this is your bank's website, then the Javascript could grab the "account balance" value and send that off to some other server. Or worse.
3) When you're typing in a form, Javascript can be "listening"-- then steal that information. So your password can be stolen this way, or even your credit card number if you enter it this way.



Getting back to what you can do about it, here are some methods:
1) Don't let users enter custom HTML or Javascript. Filter everything.
2) Don't store especially private information on the client's computer-- for example, use PHP sessions instead of HTML cookies-- stored on the server, but basically work the same way.
3) Use HTTPS (a secure connection)-- this solves most of the problems, and that's why all financial transactions (or at least all of the ones you should trust) do it this way. If you see "http://" and it asks for your credit card, your information could be stolen-- don't trust it.


Of course if there's nothing to steal, then you don't need to worry about it. If you don't have any private information, you don't need HTTPS either. But if you do, it's worth setting that up, or at least going about it all in a safe way. Just like in real life, the security you set up for these things should be relative to how important it is that they aren't stolen.

[pepe_lepew1962]

Thank you for your response. The net has lots of examples and it is nice to see some for a better understanding. You mention that the attack is inserted into the page. THAT is what puzzles me. So it is primarily via a form into my database that the attack code is entered? Is it also correct that it can be via the URL? My site does not have anythig special or important. All I am trying to do is understand and prevent problems.

[djr33]

When you type your posts for this forum then press submit, that content becomes part of the page here. That's how this type of attack can occur. If there is no way to submit/store information and add it to the pages on a website, then the site can't be attacked with XSS.

So, basically, yes, it's with a form. Of course if you allow everyone access to your FTP account, they could do the same thing. If users can (even indirectly) modify the contents of your HTML pages, then they can add bad code-- unless you filter it.


As for the URL, I'm not really sure what you mean. I don't believe there is any way to embed Javascript at the end of a URL, like /directory/page/alert('Hello world');, so, no, I don't think this is possible.
However, if you allow users to add links, it is important to check the HREF (eg, URL) of those links. In that case (an <a> tag on your page), they can add JS in the following format:
<a href="Javascript:......">
So just like filtering everything else they submit, you should check that the HREF of all links is a real URL, not Javascript.

[traq]

depending on the browser, many,many other elements (sometimes any element) can have javascript attributes. anything that can legally have a "onmouseover" attribute, for example. That's why it's preferable to use BBCode instead of a limited subset of html tags.

[djr33]

Right, but to clarify, in the specific case of "URLs", the only danger is in an <a> tag (in fact, just another HTML tag, like you're describing). And technically, that's not a URL anyway, that's just JS embedded instead of a URL.

I think the concern was that a URL (for example, on an external site linking to yours) could be an attack.

Actually, I guess I should add an exception to what I said: a URL can be an XSS attack, but only for the site that it is on. So if you, as a user, are suspicious of a potentially dangerous link on a site where you have private information stored, don't click that link (although in that case it might have already executed the same JS in another way).
But as a cross-site (as in external site linking to yours) attack, then your site isn't vulnerable to external URLs, just whatever HTML is actually on the page.