7 ways that input can break a web page

Since this blog is supposed to be about testing I thought I would share some of the things I have learned about breaking a web site. The following are 7 areas I always test on a new input field in a product. All of them are things that a developer should have known better than to do but every product I have worked with gets at least one of them wrong.

Query String special charters

If you have a forum that pass values using get rather then post. The & can cause several problems. If a man was to enter in their name and their wife’s name in to a field named fName. An Example of this would be Tom & Jennie. The information passed on the query string would then look like …&fName=Tom+&+Jennie&lName… in the query string. The fName attribute would only get Tom in this case and depending on what system was parsing the backend lName might be broken as well.

An unencoded = and ? also have the potential to cause the same problem but are much less prevalent in usage. Still they should be tested but are not as critical as the &.

Another charters that can cause a problem when using a query string rather then a post on a web forum is the +. The + sign is a marker for a literal space in the string. If you try to pass it unencoded in a query sting it will go away. Which can cause some problems but it doesn’t usually break the processing of the rest of the forum like the other 3 have the potential to do.

Terminating html where it shouldn’t be.

One of the more entertaining things you can do to a web page is to break the page by closing html tags before they are supposed to. The way you do this is by passing in a >, ‘>, or “> depending on how values are encapsulated in the tag. This error usually shows up in cases where the user data is redisplayed to the user in the same format. A good example of this is when you forget to enter a value in a forum and the page is redisplayed to you. When it happens you will see > displayed in the html after the input field. Another case is when the data you pass in is stored on the next page as a hidden input field. This is one of those things that doesn’t kill the use ability of the page as much as it makes you look stupid when it happens.

Cross site scripting

When I was a wee little brat well truth be told last year. I took great joy in posting java script and images to the main page of a friend’s web site through the title of the post I was making. I also made the entire page blink using the blink tag. These things are all lumped under cross site scripting. The annoyances that can be caused by this can range from the simple annoyances like what I was to doing to very dangerous things like a person collection your users login and password. The solution to this problem is actually the same one you would use to fix Terminating html you either don’t allow <> in your input fields or you encode them so that the browser will not think of them as html.

Over loading the buffer

First thing you might ask is what buffer are you talking about? Simple answer to this is yes. I am talking about any buffer you can think of. Some times the database that stores the data limits the number of chars you can pass into it. Other times it is the buffer of the web server for processing the query string. This buffer is very large and takes a bit of effort to over load but always is fun to watch the results after words. The way you test this is you pass in the maximum number of chanters you can into the field. Good developers usually limit this but some times they forget.

SQL commands through input.

Most times text is entered on a web page it passes through a database. So one of the things you need to watch for is if you enter a SQL command in the text field it doesn’t get executed in the product. This is a test that is a little harder to test. One of the ways you can test this is by putting SQL string terminators in after some text then a SQL command. I will discuss this more in the next section.

The mighty ‘ and “ how they can mess up a page.

Two charters that can cause more trouble then any other for web sites. They reason for this is they can reek havoc from the html level all the way down to the database. One of the is always used to denote test with. We mentioned them in conjunction with the > in the section of terminating html. You can also place them with other text and sometimes watch the text after it disappear when it is displayed in an input field again. A unecnoded ‘ is one of easiest ways to cause a SQL statement to get executed when it wasn’t supposed to be.

HTML escapes and how they can make all other problems possible.

Now we get to talk about HTML escape charters. These are things like &nbsp; and &#44; and the like. These can be used to display text that should not be displayed in on a page. In some cases I have seen them used to do cross site scripting. The program decoded them before it displayed the html on the page and it executed the JavaScript commands. This is one of those places where you have to decide if it is ok or not to allow them in the product. Some places don’t think it is worth it, and have JavaScript that will always force a space after the & before posing it back to the server.

Well I hope this helps you in you endeavors to create better software. If not at least it might have showed you a way you can mess with a web master out there and have a little fun.