Email is sometimes discounted or just excluded from the scope of web application code reviews and penetration testing. This isn't always the correct decision.

A web application's boundary can sometimes be difficult to define, and thus it's possible to set the wrong scope of a review, audit or security test. Web applications may be comprised of multiple independent separate systems across many organisations and geographic locations (e.g. a page containing a news feed from a third-party, someone else's widget and web analytics code).

But even the simplest web application usually have some sort of email functionality—this might be simply to raise alerts about unusual conditions such as errors, but often email is used in user authentication mechanisms such as registration forms and password change functions. But marketing emails may also be sent by third-parties and these might include web content drawn from the site or include URLs or redirects to particular resources on the web site.

I was reminded of this by an econsultancy.com blog posting this week UK retailers need to improve their email marketing efforts. Lots of good advice there. I have saved some recent poor quality marketing emails:

It just seems too easy to send these things off. Another one even had some FTP account details embedded in an image address! I spoke to the company's IT helpdesk on that one.

But yes, where the emails include links to the web site, describe functionality, submit data to the web site or include web content, they should normally be considered within scope of a security test. They may also contain useful details for the information gathering phase.

What a pity. Six weeks on and Sage Live, a new on demand Software as a Service (SaaS) web product from business management software providers Sage Group plc, is still offline. It was withdrawn at the end of January after less than a month of operation due to serious security flaws.

An article on ZDnet Sage Shows Why Bigcos Can't be Trusted with SaaS, describes the events leading up to the event which followed the blog posting on Sage Live - Serious SaaS Security Issues by a competitor KashFlow who Sage had previously complained about to Trading Standards. Despite 18 months in development, it took users of the public beta version to identify basic security flaws in Sage Live that have since been confirmed by more expert reviewers.

Developing web applications is not the same as developing conventional software, and Sage got it badly wrong. At least they have taken it offline—but it will take a lot of effort to rebuild the required trust in the service if it re-launches.

Terminology can get in the way of the understanding each other in project teams. Sometimes information security terminology can get particularly foggy. So if you hear "positive security model", what should you be thinking of?

Positive security models are sometimes referred to as a white list (or whitelist) approach. There are good definitions and descriptions on the following sites:

• Wikipedia's definition of White List
• OWASP's definition of Positive Security Model
• Input Validation Strategy - Black vs. White -listing in Following the White Rabbit

For a web site (web application), a positive security model would define a limited number of interactions and data that would be allowed.

As an analogy, if you were having a family get-together, you could be very explicit about who you are inviting—Granny Jones, Uncle Sam, etc. By listing everyone you will let in to your house on a particular day, you'd have a type of positive security model. If they were not invited (or turned up on another day!), they wouldn't be allowed in. But people who are new to having a party tend to do things a bit differently. They'll tend to say "everyone's invited" with some exceptions—Bob, Jinny and Si can't come. That's a negative security model.

In the family get-together it's easy to prevent (known) trouble-makers from attending - just don't invite them (and enforce the door policy) i.e. allow all legitimate guests and deny everyone else. For the party, since everyone's welcome passers-by and friends of friends may turn up who cause trouble.

The positive security model is stricter, but relies on having a full knowledge of what is, and what is not permissible. For a web application, this would be what information (e.g. type, range/length, character set, format, syntax, cardinality) can be sent & received, by who, in what manner, when, in what order, how often and what pre-conditions there are.

The more of these things that can be defined early in a web application project, help guide the design, development and testing. Of course there will be difficulties defining what exactly is allowed or making it specific enough, but by going through the thought process, it helps build security in from the start.

There are some more thoughts in A Techie's Musings about It's Only a Model.

The Web Content Accessibility Guidelines 2.0 (WCAG 2.0) have created some challenges for those who wish to meet the criteria and also develop to high web security standards.

The WCAG 2.0 became a full W3C Recommendation in December 2008 (see Accessibility and Security Roundup). The WCAG 2.0 contain much more related to transactional systems and there are many criteria which existing development frameworks are unlikely to meet. Inflexible generic methods for navigation, data entry and validation will not always be possible—the context is so important in consideration of accessibility.

The four principals (perceivable, operable, understandable and robust) comprise 12 guidelines and associated testable success criteria. The most difficult issues are related to the highest level of conformance. There are still three conformance levels—A (lowest), AA, and AAA (highest).

The Techniques for WCAG 2.0 are worth reading as these give a guide to developers as how some of the success criteria could be achieved and checked.

Session management

The following are of particular interest:

• G5: Allowing users to complete an activity without any time limit
• G105: Saving data so that it can be used after a user re-authenticates
• G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit
• G180: Providing the user with a means to set the time limit to 10 times the default time limit
• G181: Encoding user data as hidden or encrypted data in a re-authorization page
• G198: Providing a way for the user to turn the time limit off
• SCR16: Providing a script that warns the user a time limit is about to expire

Session management where authenticated users are authorised to perform certain actions is a fundamental building block of web application security. There are potential issues here if tokens are not expired on time out and log out. This is a particularly important issue on shared computers.

Data entry

And for data entry and validation, the following techniques have security implications:

• G89: Providing expected data format and example
• G155: Providing a checkbox in addition to a submit button
• G98: Providing the ability for the user to review and correct answers before submitting
• G139: Creating a mechanism that allows users to jump to errors
• G177: Providing suggested correction text
• G99: Providing the ability to recover deleted information
• G75: Providing a mechanism to postpone any updating of content
• G76: Providing a mechanism to request an update of the content instead of updating automatically
• SCR18: Providing client-side validation and alert

Getting data entry, checking, confirmation and validation correct is key, and I like the empahsis being placed on this aspect, but there are dangers in poorly thought-out implementations. More accessible web applications are better for everyone—not just people with less experience, knowledge or ability.

Final thoughts

Overall, WCAG 2.0 increases the complexity of specification, design, development and testing of web applications. Many of the techniques could introduce security vulnerabilities, and the listed techniques could be used to develop misuse test cases.

I'm pleased to see in one of the script examples:

Very true.

Update 19th May 2009: See also What's the Scope for Accessibility Testing? and Can An Accessible Web Application Be Secure? concerning my presentation at OWASP AppSec EU09.

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.

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.