I think the name “cross site” is confusing. It’s easy to hear that and think it involves code on one website attacking code on another website. That’s not what it is. Not to mention its unfortunate “true” acronym.
It simply means: executing abritrary JavaScript code on the page.
This could be JavaScript that is inserted into the URL or through form submissions. If either of those ways of accepting information doesn’t “clean” the information it is getting before outputting it again on the page, then arbitrary JavaScript can run on that page and that’s an XSS vulnerability.
If JavaScript can run on the page, then it can access cookies.
If it can access cookies, then it can access active sessions.
If it can access active sessions, it can log in as you to websites you are logged in to, at least long enough to change passwords or other havoc.
Symantec has said that 80% of internet vulnerabilities are due to XSS.
XSS is different from, but similar in spirit to SQL injection. SQL injection is where SQL commands are not cleaned from inputs and thus able to do malicious things to a database. Using HTTPS cannot help with either XSS or SQL injection. HTTPS only protects data in transit over networks.
I’m not a security expert, I’m just helping spread the word: let’s scrub those inputs people! Here’s a start.
If you have more to add, or think I have it all wrong, let’s have it!
Here is desc and example of XSS attack
Really appreciate having this boiled down! I definitely found the term confusing and fell into the camp thinking that XSS was some sort of evil site sending data to another site or something.
Yay, I learned something! :)
This was a good intro for me
Very informative, thanks Chris!
This is the main reason I use a PHP Framework rather than creating ( hard work! :| ) a one for myself. They provide extra security to clean the data to prevent XSS and SQL Injection attacks.
you still need to be careful about which one you choose – just because it’s published (or even purchased) doesn’t mean it’s secure.
Not being a php developer I am interested in this statement. Surely this is down to how methods are created and how html inputs/hidden values/querystrings are handled by the developer and not the php framework itself?
In the end, the developer’s code will “make or break” things, yes.
But the framework was developed by someone, too. Some were designed by people who really know what they’re doing, and some were written by people who just thought they did.
Many people who use them don’t know enough about security concerns, or to really examine the code, to determine for themselves how “foolproof” the framework is. My point is that you can’t just assume that something is workable just because it’s available for download and seems to do what you want.
@Traq: Yes, I totally agree with you. From my comment, I didn’t mean that one should blindly trust in the existing php frameworks. My point was that at my current experience level, it would be better for me to use a framework because it will provide me with ‘better’ security rather than starting from the scratch.
@Philp: It all comes down to methods and the way you manipulate the objects. But php frameworks provide pre-built methods which help you sterilize an input. If you started from scratch, you did have to write all that and also have an immense knowledge about web security to even begin with. But as said by Traq, one should not blindly trust frameworks and should learn about web security. :)
I also believe that if one starts from scratch, on a personal project, then one can learn a lot in the whole process.
Simple string replacement isn’t nearly good enough, it’s pretty easy to get around. My favorite input cleaner is htmlpurifier: http://htmlpurifier.org/ A good reference for the types of things people might try is http://ha.ckers.org/xss.html
Thanks Chris. That was a really good heads-up!
Hi,
You are mostly right on the nail and it is great to see this kind of thing on a non-security website.
However, as you mention, XSS is a way of embedding any code on a site. It could be ANY code to be classified as XSS. It could be as harmless as changing the background to something that the original owner doesn’t necessarily want to anything. A lot of XSS code is used to create fake clicks on advertising, redirects and even “malicious” search engine optimisation (SEO).
The second part of your article is actually a specific type of XSS called Cross Site Request Forgery (CSRF) which is another stupid name and is just basically using injected Javascript (or in rare cases some other malicious method) to steal cookies and hijack sessions.
Basically, not allowing a third party to put code on your page stops the first attack and limits the second.
Hey Allen, CSRF is not exactly related to XSS. You can still be vulnerable to CSRF even if you have no XSS vulnerabilities. And it doesn’t require JavaScript either. If the vulnerability is exposed via HTTP GET, a simple image/css/iframe request (or series of) can exploit it.
CSRF basically takes advantage of the likelihood of a user already being authorised with a target site, and performing actions on that site against the user’s knowledge. I think twitter got hit on this recently (google: csrf twitter goats).
—
WRT to XSS, you should ideally validate your input (but not ‘cleanse’ – invalid input should not be accepted at all). Instead, all data (user-generated or otherwise) should be escaped whenever it is output.
I don’t like cleansing input because that’s distorting data, besides, a well-developed system supporting free-text entry should be capable of supporting any input.
@Lee…
That is actually my point. The article (which is damn fine) errs in lumping the two together. They usually go hand-in-hand but, as you mention, CSRF can be achieved without Javascript or XSS at all.
Escaping is one defense but you have to be sure that somewhere down the line the input is not “un-escaped”.
Thank you so much for covering this aspect of security! What’s about AJAX requests in WordPress? I mean, the requests from the frontend? I recently developed a slim plugin where users can add an item to a cart using the AJAX-method to write to a session. Does anyone knows something about those security issues?
I would imagine you could use some sort of “tokens” (much as you would with form submissions) to verify that the ajax request is coming from a valid (and current) session.
I don’t know about WP specifically, but I’m developing a site now that will use lots a ajax to access php function calls, so that’s an issue that I’ll need to address.
Before couple of months, i do research for fix SQL and XSS injection and found this simple metod with .htaccess:
I think it’s work, or not?
I would recommend a read of the following article and having a look around the site Open Web Application Security Project.
http://owasp.blogspot.com/2010/11/preventing-xss-with-content-security.html
:)
Nice explanation, and always good to clean the code as much as possible especially if it will enhance website security. LT
is XSS also the part of HTML5 ?
it’s still a risk, yes.
In the end, the risk comes mostly from users (coders) rather than the language (code) itself. it’s fairly easy to make something that “works,” but harder to make sure it isn’t misused. sometimes folks forget about the second part
Thanks for the post, but do Web Designers really need to learn this? Assuming they dont know PHP ?
(P.S – I am a PHP Developer learning to design and thats why im here)
Nice post. Web designers should consider this one when they design web application.
Learn SQL injection with example.