How to fail at website

The internet has been in heavy use for a long time now. Browser wars have come and gone. There is now two dominant browsers in North America and has been for the past 4 or so years, yet there are still companies specifically targeting their websites towards a specific browser.

Point in case: Microsoft Outlook Web Access.

In order to get the really nice version, you have to use Internet Explorer. This means that I have to stop using Chrome, and fire up another browser just to check my email if I want to send an HTML formatted mail message.

So today after sending an email through IE, I decided to see if the only thing blocking Chrome was the browser sniffing done by Microsoft.

And the verdict is: ……………… Nope, the browser sniffing isn’t the only thing stopping Chrome from replacing Internet Explorer.

The Outlook interface is completely, I mean completely, unusable in Chrome. Messages can’t be read, folders can’t be switched. The full, unsliced CSS sprites are displayed everywhere.

If you’re curious to test this out, all you have to do is run Chrome with the –user-agent command line argument like so:

chrome.exe --user-agent="Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"

Guess I’m stuck with either using the “Web Access Light” on Chrome or the full-feature switch to IE.

*I will continue to hope that Microsoft will start to care more about end-user experience*

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.

Bad Programming Examples in C#

I’m starting to compile a list of constructs I’ve seen in production C# code that needs to be modified. Code Analysis will flag most of these. Here is the first of them, with more to be added later:

1. Never leave a blank catch statement or use catch(Exception)

In C#, if you write catch(Exception) or a blank catch, the exception will be casted to a System.Object. This will also catch non-CLS compliant exceptions. If you can’t do anything to remedy the exceptional situation, you shouldn’t be catching the exception. Usually when you see a code construct like this, the exception is rethrown. Not only is this unnecessary and bad programming, it ruins the stack trace and any other important information that Windows Error Reporting can provide for you.

If you are unsure what type of exception can be thrown, you should check the documentation. If you are catching the exception so that you can perform some cleanup before exiting, then you should move that cleanup code to a finally block. If the latter is the case, then you probably don’t need the catch block there in the first place.

If you run Code Analysis on your code, you will receive a CatchNonClsCompliantExceptionsInGeneralHandlers warning.

More information can be found about why not to have empty catches in your code at the CLR Team Blog.