Automating Mundane Tasks

20 January, 2010 § 2 Comments

A couple days ago I wanted to move all of my work email out of the inbox and into an archive folder, similar to how I use Gmail but I ran in to a problem. I had over 3,000 emails in my inbox and Outlook Web Access only allowed me to move up to 100 emails at a time.

The process to move emails is as follows:

  1. Click the check box in the table header that checks all of the emails.
  2. Click the ‘Move’ button
  3. Choose the folder to move it to
  4. Click the ‘Move’ button to commit the move

Who wants to sit around clicking the same buttons for 20 minutes just to move messages. It sure would be nice if Outlook Web Access had the same feature as Gmail:

So instead of doing the same old, mundane, click-wait, click-wait task, I downloaded and installed Firefox and the Selenium IDE plugin.

Selenium IDE is a free plugin that allows you to record your use of a web page and play it back. I’ve been using it now for some time in creating automated tests of a website I’m working on.

I played the test back and it worked beautifully. I then copied the test steps and pasted them countless times within the same test. Next I hit ‘play’ and was able to watch a recorded lecture while all of my mails were moved over to the archive folder.

Problem solved. All emails were moved in a couple minutes time.

I will be on the lookout for more ways that Selenium IDE can save me time.

Easy Ways to Break Websites

21 November, 2009 § 2 Comments

I hope this image makes you feel a little betterMost 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.

Where Am I?

You are currently browsing entries tagged with testing at JAWS.