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.

As of 2007, cross-site scripting carried out on websites were roughly 80% of all documented security vulnerabilities. Often during an attack “everything looks fine” to the end-user who may be subject to unauthorized access, theft of sensitive data, and financial loss.

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.

When accepting data from a user, any data at all, it should be sanitized before making its way to your database.
…..
We’ll scan through the input, searching for anything that shouldn’t be there, like html code, <script> tags, etc
…..
To use, we simply pass any input to the function. The function works on single strings, as well as deep arrays.

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!

Very easy to customize and would fit well into a website providing a variable rate service and suchlike.

It would be better to use css for all the styling and layout information, but it’s easier to copy and paste the source code below as one file.

I’m going to start off with some simple tricks, before introducing the interesting stuff later on. If the material seems too simple for you, feel free to skip ahead.

It’s the Little Things that Count.

You will certainly have encountered our first trick before; it’s used by Google, the world’s most popular search engine. Whenever you load up www.google.com, your cursor jumps straight to the search box, ready for you to enter your query.

It happens so fast you may not even have thought about it, but, in fact, it works equally well in any situation in which the primary purpose of a page is to fill in a form. It can be done in a number of different ways, each of which assumes that the form element you want to focus on has an id attribute set to “myfield”:

This is, more or less, the method used by Google. It’s short and to the point. It does, however, require the addition of an onload to your body element, which some people find unsightly.

This can be added to any point in your HTML file, or hidden away in an external script. If you’re going to be using a lot of JavaScript on a page, it can make sense to move it all in to an external script file in order to keep the JavaScript code separate from your HTML. This method has the disadvantage that you can only assign one thing to the window.onload event at a time.

This uses Scott Andrew’s addEvent function. This is probably the best approach to take if you’re keeping your code in a separate file, as it will allow other functions to be attached to the onload event as well.

The above will only work if it is placed in the HTML source code some point after the input field. This can be useful if you are working with a server side templating system that makes it difficult to add code directly to the top of a document — for example, if you are including the top part of the page using a server side include.

The above four options are available for most of the tricks I’ll demonstrate in this article. For future tricks, I’ll demonstrate the method using inline attributes such as onload and onclick only, but you should be aware that there are several ways to skin this particular cat.

Labels

The quickest way to enhance your form usability is to add labels, if you’re not using them already. The element has been part of HTML since 1998, but many developers remain unaware of its existence. It allows you to logically relate the text describing a form field to the form field itself. When the user clicks on the label, the browser will move the focus to the related form field, or toggle its state in the case of radio boxes and check buttons. Before you add a label, the form field must have an ID attribute set. In fact, the tips in this article almost all require an ID attribute be set on the form field, as this provides a useful means of targeting that field from JavaScript.

Here’s the simplest example of a label in action:

Clicking on the word “Username” will focus the cursor in the text box. This may not seem like a particularly useful effect, but it gives us a useful hook for styling and potentially adding extra JavaScript behaviour. It also dramatically improves the accessibility of the form for users of assistive software.

Where labels really come in to their own is with checkboxes and radio boxes. Both these widgets are plagued by a tiny active area, sometimes called a “hotspot”, which you need to hit dead on with your mouse to cause them to toggle. Adding a label increases the hotspot to cover the text associated with the widget as well:

Of course, labels aren’t much good if people don’t know they’re there. One simple but effective trick for increasing the visibility of labels is to use CSS to change the cursor over them:

Why the two cursor declarations? The CSS standard dictates “pointer” as the value for a “pointer that indicates a link”. Unfortunately, IE 5 and IE 5.5 for Windows don’t understand this value, using “hand” to mean the same thing. By placing pointer first misbehaving Microsoft browsers ignore it and use the hand value, while better behaved browsers take pointer and ignore hand.

Visual Hints

In a large form, it can be easy to lose track of the form field you’re currently filling in. A great trick for helping out is the following:

This causes all input fields to have a 2 pixel wide gray border, while the input field on which the user is currently focused gets a black border to make it stand out from the others. There’s one caveat: IE on Windows doesn’t support the :focus pseudo-class! Thankfully, it’s possible to replicate the effect using java script:

This brings the effect to IE, at the expense of a lot of extra typing. If you’ve got a lot of form fields on the page, it makes sense to do this instead, again making use of the addEvent function introduced above:

The cookie-cutter code in the above deals with some cross-browser compatibility annoyances.

Enhancing Text Entry Fields

The most common form field is …

We’ve already seen how auto-focusing on this when the page loads can make a nice enhancement. A useful trick for fields containing a default value that needs to be changed is the following:

When the field receives the focus, the text inside it will be instantly selected; it will be over-written the moment the user starts to enter their own text. This is also useful if the user is likely to copy and paste the text from the widget, as it saves them from having to first select it.

Here’s a nice trick for forms that are being used to create something that has an obvious title — for example, an email, or an article on a Website:

This creates an effect similar to many popular email programs, where the text in the title bar of the document changes as the subject of the email is typed. This could be particularly useful in an environment where multiple windows are likely to be open at once — a Webmail client, for example.

On a related note, sometimes the value of one form field can by initially guessed by looking at the value of another. A classic example is a content management system where each entry has a human readable title and a unique URL. The URL can default to matching the title, but with punctuation removed and spaces converted to underscores. Here’s the code to do that:

The critical thing here is that the user can still over-ride the guessed value for the URL if they want to by entering text directly in the field. If you just want to create a URL from a title without any intervention from the user, it’s best to do so in the server side code that processes the form.

Validation

Client side form validation is one of the most popular uses of JavaScript. Before we go on, I’d like to point out that if you’re building a server side application you should always check that data is valid in your server side code, whether or not you have used client side validation. Not doing this can leave your application wide open to all manner of unpleasant security problems — remember, malicious attackers know how to disable JavaScript in their browser. This point cannot be stressed enough. We now return to our regular scheduled programming…

Validation is a big topic, and one that has been covered extensively in tutorials all over the Web. Rather than rehash old ideas, I’m going to focus on a more usable way of validating user input. For instant feedback to the user, how about displaying an icon next to each form field that indicates whether or not that field has been correctly completed? Such an icon can be hooked straight in to the label elements we added earlier, and changed by using JavaScript to alter the label element’s class attribute.

Here’s a simple example for a required form field, broken down in to the CSS, the JavaScript and the HTML:

This is simple enough. The label element starts off with a class of “required” to visually indicate that the field is a required field. The JavaScript function checkRequired(‘subject’) is called onblur, which refers to the point at which the focus moves away from the field.

The CSS gives each label a left padding of 22 pixels. The icons we’ll use will each be 15×15, which gives us a little room to spare. Special classes of required, problem and completed are defined, each with their own background icon positioned to appear in the padding to the left of the form text.

Here, we define two JavaScript functions: one to find the label associated with a specific ID, and another, which checks that a specified form field has something in it, and sets the associated label’s class accordingly. This is the simplest possible case for validation; additional functions can be written to cope with problems such as checking that email addresses are in a useful format. This technique could be taken even further by disabling the submit button until all the form fields have been correctly completed; however, if this is done, it is vital that the initial disabling of the submit button take place in the JavaScript, to ensure that non-JavaScript enabled browsers can still use the form.

The last trick I will introduce revolves around data that has a very specific format. Rather than reject a user’s input if it doesn’t match the format rules perfectly, it is sometimes possible to reformat the user’s data once they have entered it. A classic example is a form field for accepting US phone numbers. US phone numbers, when the area code is included, are exactly 10 digits long. The traditional way of displaying them is (785) 555-5555. Using JavaScript, we can take the user’s input, strip out all non-digit characters and, provided we are left with 10 digits, reformat them to look like the above example:

This technique can be taken even further to allow multiple ways of entering structured data, such as a date, with any recognised values being converted to a standard format.

The page contains 100 examples suitable for any level of programmer.
Each example has a live demo and source code available for download.

The web is changing and so is the way we posting data. If you take a look at Google, Facebook, and almost every new start up, simply posting form data is a thing of the past. You can now validate without posting, upload multiple files, change the way form elements work and much, much more. We gathered 100 of the web’s top AJAX/form related scripts. Use them to enhance your forms and impress your clients (Clients like fancy, pretty things).

[ View The Full Post at NoBoxMedia ]

JavaScript has its own security model, but this is not designed to protect the Web site owner or the data passed between the browser and the server. The security model is designed to protect the user from malicious Web sites, and as a result, it enforces strict limits on what the page author is allowed to do. They may have control over their own page inside the browser, but that is where their abilities end.

• JavaScripts cannot read or write files on users’ computers. They cannot create files on the server (except by communicating with a server side script that creates files for them). The only thing they can store on the user’s computer are cookies.
• They are allowed to interact with other pages in a frameset, if those frames originate from the same Web site, but not if they originate from another Web site (the postMessage method from HTML 5 does safely extend this capability, but I will not cover that here). Some browsers will even treat different port numbers on the same server as a different Web site.
• JavaScript cannot be used to set the value attribute of a file input, and will not be allowed to use them to upload files without permission.
• JavaScript cannot read what locations a user has visited by reading them from the location object, although it can tell the browser to jump back or forward any number of steps through the browser history. It cannot see what other Web pages the user has open.
• JavaScript cannot access the cookies or variables from other sites.
• It cannot see when the user interacts with other programs, or other parts of the browser window.
• It cannot open windows out of sight from the user or too small for the user to see, and in most browsers, it cannot close windows that it did not open.

Most people who want to know about security with JavaScript are interested in producing password protected pages or sending encrypted data to or from the user’s computer. For true security, use SSL/TLS (HTTPS) and put all of your checks on the server. You could also use a security lockout if too many false attempts are made, preventing brute force cracks. JavaScript cannot replace this functionality. The problem lies in the fact that if a person can read what you are sending over the internet, they can also rewrite it. So when you think you are filling in a password to access a protected page, they have changed it so that you are actually filling in a password that will be sent to them. This requires SSL to be sure that you are protected. Still, this tutorial is about JavaScript, so I will now show you what can and cannot be done with JavaScript.

Protecting the source of your scripts

Oh dear. This is just not possible. Many people make futile attempts to do so, but to be honest, there is no point in trying. In fact, in many developers’ opinions, there is no such thing as copyright with JavaScript, although it is theoretically possible. The point with copyright and patents is that you can only copyright or patent something completely new, a new innovation, something that has not been done or written before. You can almost guarantee that nothing you do with JavaScript will be a new innovation or even newly written. Someone will have done it before, almost certainly using the exact same algorithm with just a few variable names changed. JavaScript is just not designed for innovative programming since it just uses APIs designed by someone else to do what you are doing, and they already came up with it before you in order to invent the API. Even if you write something in a ‘new’ way, it will still be doing something that has already been done, and if you did attempt to take things too far and take the matter to court, you would just be laughed back out of it again.

As for protecting what you send, JavaScript is passed in text, not compiled to a binary first, so the code is always visible. How can you stop people seeing the source when you are sending the source to each viewer? Let me walk through the problem.

If the source of the JavaScript is held in the page you are viewing, a simple ‘view source’ will show you the script. Looking in the browser’s cache will show the scripts that are in header files. Of course you need to check the source first to find the name of the header file.

Many developers have spotted the fact that both of these methods require the ‘view source’ to be available, so they prevent the viewer from viewing the source. They do this by preventing the context menu from appearing when the user right clicks and by removing menus by using window.open etc. Believe me, both of these are useless. You cannot stop right clicks in Opera, Safari, OmniWeb or iCab like you can in other browsers. So some people try to prevent these browsers from viewing the page by using browser sniffing. This is equally uneffective. All the viewer has to do is swich off script when they get to the page, or view the source of previous pages to find the location of the protected page. In adition, Opera, Mozilla/Firefox and Internet Explorer are all capable of running user scripts that allow the user to override restrictions made by the page.

Some people even try to make sure that the page is only delivered if a referrer header is sent to make sure that the user came from the right page, and is not attempting to type in a location manually. So the user can use Curl, a program that allows them to request a page with referrer header, cookies, form fields etc., and save the download to a text file.

Some people try to encode the script using charCodeAt or escape, but as the decoding technique is provided in the page, only simple modifications are required to make the script appear in text, not as embedded script. I have seen one set of scripts that have been ‘protected’ by changing their variable names to completely incomprehensible names, and adding several redundant lines of incompressible code and removing all redundant spaces and linebreaks. It does not take too much work to turn this back into understandable code.

You may want to protect your code, but it simply is not possible. Someone who is determined will be able to find it out.

Password protecting a file

It is best to do this with a server side script, and an encrypted connection. But since this is JavaScript …

Take the following for example. I want to only allow someone to access my page if they put in the correct password. I want to provide a box for them to write it, and then I want to test if it is correct. If it is, I let them view the page. The problem is that in the source of the page, I have to write the password in the script to test what they have written. For example:

As described in the above section, you cannot protect the source of a page, especially from someone who is really determined. There is no point in trying. Once a user managed to see the source, they could see the password or the URL in plain text, or encoded, but again, that is easy to break.

For simple security, try this technique. Name the file to be protected whateverYourPasswordIs.html and make sure there is an index.html file in the same directory. Now use the following:

The problem with this technique is that the page is still passed in plain text across the Internet, as is the name of the page that you send. If anyone is snooping at data packets on the Internet, they can retrieve the page’s contents. In many places, packet snooping is illegal, but that does not mean that no-one does it.

This protection technique is known as security by obscurity, in other words, it is only secure because no-one knows it is there. If someone was determined, they would find it.

As a more complicated solution, try creating your own encryption technique that uses a password as an encryption key. Encrypt the contents of the file. As the page loads, use window.prompt to ask the user for a key. Try decrypting the page with their key, using document.write to write the page. If your technique is good enough, wrong passwords would only produce an incomprehensible output. With this technique, the password is never transmitted over the internet in plain text, and neither is the content. This technique could be cracked by brute force, trying every possible password until something works. Better passwords and encryption algorithms will help, but if someone was determined, they would break it. One of my readers has submitted a script to do this based on RC4 and Base64.

I have used both of these techniques.

Encrypting data before it is sent to you

Normally, this cannot be done with JavaScript using the Internet alone. You can encrypt text at the user’s end and unencrypt it at your end. The problem is that the user has to encrypt it with a password that you know so that you can unencrypt it. They would have to tell you by telephone or post. Alternatively, you could put the password in the source of the page and get the function to encrypt using that key. But this password would have to be sent over the internet in plain text. Even if you did encode it, it would not be too much work for a snooper to crack it. In fact, the encryption could even be broken with brute force techniques. So what do you do?

The best possible technique would be to create a symmetric encryption key using a twin public/private key pair as with techniques such as Diffie-Hellman or SSL, or use an asymetric public/private key pair and encryption technique as with PGP or RSA. The problem is that in order to prevent brute force cracking techniques, these require the browser to handle numbers as high as 2×10600 or higher. JavaScript is just not natively capable of working with numbers as high as this. As yet, I have found no solution to this, although on http://shop-js.sourceforge.net/ there is an algorithm for emulating large number handling, and an example of JavaScript powered RSA. The technique seems to work and takes only a few seconds to create keys, by using complex mathematics and algorithms (look at the source of crypto.js) to emulate large number handling.

Even so, if doing the equivalent of RSA (etc.), it is still not possible for the user to verify your identity as with SSL certificates, so it would be possible for a third party to inject their own code and have the information sent to them instead, without the user’s knowledge. For the best security, stick to real SSL.

Protecting your email address

This is one of the very useful things that JavaScript can do. For those that don’t understand the problem, I will summarise. Search engines ‘crawl’ the Internet, following the links in pages and requesting other ones so that they can add the pages to their search databases. Using the same technology, spammers crawl the Internet looking for email addresses, whether in mailto: links or just written on the page. These email harvesters are one of the most annoying uses of otherwise useful technologies.

Simply writing your email address on any web page (through newsgroup postings etc) can leave you flooded with unsolicited emails. Many people fall into the trap of replying to these emails asking to be removed from the mailing list, and succeed only in confirming that their email address is valid. The problem is that you may actually want your email address on the page, or a link that automatically opens up a new email to you. There are a couple of steps you can take to prevent the problems with unsolicited emails:

• Use a throw-away email address like a yahoo or hotmail account when posting to newsgroups, signing online guestbooks, or writing your email address on your Web pages. That way, when you start to get too much spam on that email address, you can just dispose of that email account, and get a new one.
• If you can, tell your email client (program) not to send read-confirmations when you read your emails. This way your email client does not automatically confirm your email address.
• Be careful when setting up auto-replies.
• When you post your email address, change it to read something like myName@REMOVE_THISmydomain.com or myName(replace with @ symbol)mydomain.com and hope that anyone who legitimately replies to it works out what they need to do to turn it back into a proper email address. The problem is that not all of them understand this, and don’t understand why the email adress does not just work. So, you can try the next point as well:
• Use JavaScript. How? Read on!

Using JavaScript to write your email address

I have never heard of an email harvester that is clever enough to interpret JavaScript. All they can do is read the text that makes up the page. So if you write your email address with JavaScript, they will not be able to read it. Remember that if you write the email address as a single word, even in the JavaScript, they may still interpret it as an email address, so it helps to break it up a little:

You can also use a mailto link:

You could even use a combination of both:

There is, however, a problem with this approach. It relies on your viewers having JavaScript enabled. Many of your more web-aware viewers will not. In my case, these are often likely to be people who I want to contact me. Fortunately, these viewers are the ones who are likely to understand what to change if you tell them to as I have showed above (in the bullet points). So, you can use a combination of both approaches: