Article: XSS and web form security

XSS and web form security

Author: Abe

XSS and web form security are very important factors to consider when designing a website.

There are many instances when user input is needed. But allowing just any code to be passed can cause severe problems and lead to even the most annoying 10 year old script kiddie writing “PWND” all over website!

There a are some simple steps which you can take to prevent most of these.
This article will go over some of the fundamental XSS attacks and how to stop them.



Cross-site scripting (XSS) is, in short, a way of injecting code by a malicious web user. The code can be used for anything from displaying a persistent pop-up or crashing the browser, to including remote files to run scripts and steal cookies!

What code do I need to sanitize?

What will this magical code look like?
That’s an easy question to avoid as there are many ways to mess with a website that gives permission to post raw code! Not all XSS attacks will work on all websites or even all broswers. So you may see someone testing with strange looking code before you see some, if any, form of attack.

For this reason, I think it’s best to implement some form of BBCode system.
But more on that later…

A few common XSS codes could include…



Most of these examples will just show an annoying pop-up saying “XSS”, but could be used for more malicious purposes.

If any of the above XSS examples are allowed to be displayed as output from your page, you have could have serious problems!

As mentioned above, there are MANY ways to abuse a website that doesn’t check what your posting or submitting.
It may seem like a good idea to ask for visitors comments or asking for an email address for news subscriptions, but it’s worth checking what content will be displayed when the form is submitted.

How can I prevent XSS attacks?

Any code that can be submitted by a user should be validated or filtered in someway. Steps need to be taken to ensure malicious code can’t be executed on output.

Non-crucial pages like a confirmation page don’t need full validation. But, if a feedback form is allowed to go unchecked it could mean a cookie stealer gets injected and your customers details get stolen!

Generally speaking, it’s best to validate of any forms or inputted data submitted to your web site. Validating the data on input (rather than output) not only helps prevent possible attacks more effectively, but also makes sure only clean code gets entered into the database.

There are other benefits to cleaning up the code before it gets entered into the database. One great advantage is clean output to an administration section.

Let’s take my Free Online Arcade as an example:
If I decided to ask for visitors to submit games to the website, I could just use a simple textbox to ask for the embeddable code to be entered. If the submitted content wasn’t validated in some way an attacker could inject a cookie stealer to hijack the administrators session! Flash code would not even be required if no form of validation is used, so I could just use embed a cookie stealer and a game together.

In an idea world, ever input field would be validated to ensure clean output. But that can be very time consuming.







Denham Coote’s Blog has a great article on Stripping out malicious code for PHP, which is easy to implement and very effective.



Whenever you make a form you should not leave it alone without any form validation. Why? Because there is no guarantee that the input is correct and processing incorrect input values can make your application give unpredictable result.

Form Validation With PHP covers the subject in a little more detail. The article includes full source code and examples.

Closing Notes

To sum it all up… Trust No One!
Try to validate any code that will be submitted to the database or displayed on the website, even if only to remove the script tag.

In my opinion it’s a good idea to try and think like a hacker. Spam test your site before putting any changes in place. Try to execute some annoying javascript. Could you include remote javascript files? Will malformed tags allow injection?

If you can do it, the hackers can generally do worse!

---

---

Reader Comments

Post Your Comment

Please keep your comments relevant to this article entry: inappropriate or purely promotional comments may be removed. Email addresses are never displayed, but they are required to confirm your comments.