Easy Ways to Break Websites

Most websites are put together with bugs all over, and it is only a matter of finding them so they can be fixed. At the end of the day, it is more important to find the bugs in house before a client/customer or malicious user gets ahold of them.

I present here some very simple things to do to find flaws or problems with your website, and some ways to fix them. This list is ordered by ease of attack.

1. Broken links and resources

Many websites have broken links hidden deep inside of pages or within CSS files. If your website is not publicly available, you can download a tool like Web Link Validator. If it is publicly available, then the W3C Link Checker will allow a quick and download-free way to test all your links. This tool can check all the links on your site in a few seconds and let you know of any broken resources.

This is probably the easiest and quickest thing that can be done.

2. No limit on form field length

Almost all interactive websites have some form of user input. The text fields found on these forms may not have a client-side limit of the amount of text that is allowed to be entered. Sometimes these form fields, when filled with a vast amount of information, can make forms break and websites crash if too much text is entered. To test this, go over to Project Gutenberg, grab a free book in a text format, copy its contents, and paste in to the forms fields. Submit the form and watch the website crumble.

To fix this, your website should block requests over a given size and should truncate strings that are unreasonably large.

3. Unicode strings in form fields

There are some really strange Unicode characters (such as this airplane: ✈). Some sites just can’t handle Unicode characters. Enter a bunch in to text fields and see if there are any issues. Also, try a BiDi language as another use of Unicode strings.

Some ways that these problems can enter a system is if you are not using Unicode strings in the backend or are assuming each character is only one byte in size.

4. Broken email address validation

It is near impossible to validate an email address the proper way, and a lot of websites use poor regular expressions to validate an email address. Here are a just a sample of valid email addresses that are often refused (quoted from RFC 3696: Application Techniques for Checking and Transformation of Names):

“Abc\@def”@example.com

“Fred Bloggs”@example.com

“Joe\\Blow”@example.com

“Abc@def”@example.com

There is a really good post by Phil Haack about how he thought he knew how to validate an email address until he read the RFC.

I recommend checking for an @ sign and a period following the @ sign. After that, you can require users to verify their email address. It’s about all we can do.

5. Cross-site Scripting

If anything that is user-submitted will end up being written back out to a webpage, there is potential that it is open to cross-site scripting (XSS). Cross-site scripting has been responsible for taking down MySpace, Twitter, and other major websites. Try pasting some of the examples from ha.ckers.org to see if your site is susceptible.

If it has vulnerabilities, there will have to be server-side scrubbing of these fields. It is best practice to scrub data when it is coming in to the system and when it is going out of the system (in case there is some unknown way that it can enter the system, you will be protected).

6. SQL Injection

Just like XSS, this can cause major issues. Worst of all could be giving out credit card information from customers or an entire loss of your database. Try the examples given at mavituna.com to see if your website will break or go down. You might want to make a backup of your database before trying this :).

To fix this, there will have to be server-side scrubbing of the fields (see a trend here?).

7. Client-side modification of form variables

Ever set a maxlength attribute on one of your form fields. I hope this isn’t the only place that the data size is being restricted, but it might be. Client-side tools like this are really helpful for usability but that is about as far as they can go. Use a browser like Google Chrome or Mozilla Firefox (with Firebug), right click on an element, choose “Inspect Element”, and remove that maxlength attribute on the input element. Another thing you can try is to change the values of an option element. For example, if there is a field that asks for an integer quantity and the maxlength is set to three, remove the attribute, and enter in 15 digits. This may cause an integer overflow error (probably not something you wanted to happen 🙂 ).

To fix the integer overflow problem, the string should be truncated or rejected if it is too long before it is converted to an integer.

I hope this list will help someone test their website. Remember, it’s always better for you to find your errors before someone else does. Any problems you find can be a lesson to not make the same mistake in the future.

Stepping in to .Net source code with VS2008 SP1

With the release of Visual Studio 2008 SP1, a new feature was introduced and touted, but not turned on by default. This feature allows you to step in the .Net source code while debugging in Visual Studio. If at any point within your code, you can look at the callstack and traverse all the way down to the creation of the current running thread. Very cool!

To do this, you just have to change a couple default options.

First, go to Tools -> Options. Choose “Debugging” from the left-hand side menu, and uncheck the Just-my-code option. Next you’ll want to check “Enable .Net framework source stepping”.

Hit OK, and the symbols should* start to download from Microsoft’s servers, complete with developer comments.

The first time view the code you will be prompted to accept their license agreement.

*If the symbols didn’t download when you hit OK, you can go to the Symbols submenu and choose to download the symbols explicitly from the Microsoft servers. I’ve noticed this happening on a coworker’s machine once already.