It is very common to find web applications where part of the business process, not just acknowledgements, is undertaken using electronic mail. These processes need to be designed securely and tested as well.

I've mentioned previously in Keep The Emails Coming about testing email alerts used for errors, problems and other unusual conditions, but it's common for email also to be used as a short-cut for developing some parts of business processing.

A recent project I was working on included an link to unsubscribe from marketing emails. Clicking on the link gave a slightly sparse single phrase confirmation—not particularly usable and it didn't validate me in any other way or notify me of the change by anything other than the screen message, but it was probably okay for the type of system.

However, within a few minutes I had received another email - an auto-responder:

Very interesting. What does this tell us?

• There is an administration mailing list
• The unsubscribe process sent a message to the administration list with my email address as the sender
• Posting to the list is restricted to certain people, and thus could be a way to identify administrator's email addresses
• The list may be using Mailman, the GNU Mailing List Manager
• The list administration address begins with /mailman/confirm/admins_******/

And, I suppose the implication is my email address has not been removed from the mailing list yet.

If this were a web application penetration test, it might be that some of the mailing list administrative usernames and perhaps passwords are the same as for the web application. Or, content of messages in the list contains useful information to help access the web application. The email responder is sending too much information, and actually this message shouldn't be being sent to a subscriber at all, and the information leakage then stems from using the subscriber's email address as the sender.

So, remember a web application's security is only as good as its weakest link. The security architecture needs to address the whole business process, not just the web page parts.

Version 3 of the Open Web Application Security Project (OWASP) Testing Guide has been released after a 6-month period of addition, enhancement and review.

The OWASP Testing Guide is an ideal reference for both developers and testers—version 2 was fantastic, and this new version is even better. The testing framework now covers 66 controls and, like in the previous version, each control has a brief summary and is described in detail followed by black box (no additional knowledge) and grey/gray box (partial knowledge) testing methods and examples where appropriate.

The controls and testing methods are fully referenced to provide additional guidance and explanation.

The controls are grouped into ten categories, including new separate categories "Authorization" and "Configuration Management". I'm especially pleased to see the latter broken out on its own, since even a perfectly coded application can have vulnerabilities introduced during deployment and changes to the application.

The OWASP Testing Guide now also includes a "best practice" penetration testing framework and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues. More information is available on the Testing Project pages.

Two articles in particular caught my attention this week relating to designers and developers engaging clients in the development process. Both are worth a read and, I think, consideration in your own web projects.

The first was a great outline of Educating the Client on Information Architecture on A List Apart. The discussion seemed to focus a little too much on static content (data) and probably needs to address data flows and where security boundaries occur in the information architecture. But by using the suggested approach, it makes consideration of security controls much easier.

Secondly, the business case for web application security was discussed on Securosis.com - this was Part 2 of a series of posts about building a web application security program - Part 1 which I had missed was an introduction. The post lists six typical drivers used to justify web application security investments - but I think "User Trust" should be an additional one. Increased trust helps overcome perceptions of risk and insecurity and leads to a greater likelihood of users undertaking, completing and repeating web site processes.

If you are interested in the effect of trust, the multidimensional nature of trust is discussed in detail in McKnight, Choudhury and Kacmar's papers on Developing and Validating Trust Measures for e-Commerce: An Integrative Typology, Information Systems Research, Vol 13, No 3, September 2002, pp 334–359 and Distrust and Trust in B2C E-Commerce: Do They Differ?, Proceedings of the 8th International Conference on Electronic Commerce, 2006, pp 482-491. The reference lists included in these papers provide additional and alternative views on trust.

Functions to unsubscribe, be removed, cancel or opt out from newsletters, mailings and email alerts can be used to undermine web site security.

Many techniques are used to unsubscribe including:

• Email message to a particular address, possibly with a keyword like "unsubscribe" in the subject or body
• One click opt out unsubscribe hyperlinks
• Hyperlink to a form with additional validation
• Log into an account management area to make a change to communication preferences
• Pre-paid response postcard
• Telephone call to a helpdesk.

Some examples from email alerts are shown below:

It is important to make it simple for people to opt-out of such services, but there are a number of problems that can get built into such systems:

• Hyperlinks that only pass an email address as a parameter can be used to find whether particular addresses (such as known individuals) are registered/subscribers - this could be used for user name enumeration if there is a separate log in area and the user names are email addresses
• Hyperlinks with only predictable identifiers can be guessed
• Systems could be used maliciously to unsubscribe other people's accounts
• Hyperlink options could automatically log people in to their accounts - this should not occur since the links could be accidentally forwarded on to other people
• Any validation (authentication) systems must be at least as secure as other functions such as log in to access account details, so that the unsubscribe facility cannot be used to obtain log in credentials (e.g. limit the number of attempts possible, log failed attempts, lock accounts, add delays to failed attempts, etc)
• Unsubscribe by hyperlink or email must have the same level of checks (not more or less) as non-electronic means (telephone call, written, etc) otherwise the weakest method could be used by a malicious person
• Text-only versions either not including or not rendering the unsubscribe hyperlinks correctly (e.g. wrapping the link), so that only rich-text email users can see and use the links
• Anything sent by email is normally not considered secure
• Do not give away any other sensitive information on either successful, or unsuccessful completion (e.g. "Thank you Margot Dyson, we will send a letter to your address in Hastings to confirm this request")
• Clearly distinguish between opting out of particular correspondence, types of contact (e.g. direct marketing), all correspondence and closing accounts altogether - you may have to contact the person for some other valid reason.

In all cases, the completion of unsubscribing should be accompanied by a message to the person informing them of the change of status (by email or some other method). Where this hasn't closed their account, and they can log on to undertake other processes, the event should also be recorded for them to see in a list of recent actions.

If a web site is unavailable, this will affect everyone who tries to use it. Availability is a usability issue.

A web site being "down" can have the same effect as if someone cannot do what they want, it takes them too long, it leaves them frustrated or it is prone to the introduction of errors.

There are sometimes good reasons for downtime. The servers may be having software updates applied (patching). Depending on the requirements, some organisations may close a web application down during backing up, during a data update or during a change to the application.

Unavailability may also be due to excessive server loading, network connectivity problems, equipment failure or due to an attack by malicious users. If you have to take a site down for repair, your users are being denied use of the service.

Where possible try to minimise planned (scheduled) downtime and monitor the uptime semi-continuously (checking for text on some web pages or important transactions every 5 minutes, from more than one external location). For planned outages, I recommend you inform users well in advance and provide a meaningful message screen - not just a default error page.