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.

Happy new year. In a recent edition of a mobile phone provider's newsletter for business customers, it heralded the growth of mobile applications.

Regarding Nokia's purchase of the Symbian mobile operating system and making it free to other mobile manufacturers in an attempt to combat Google's Android mobile phone operating system. The newsletter mentions that an advantage of Android being an open source platform:

Armageddon perhaps?

I'm thinking about whether to write some posts on my recommendations for logging, monitoring and alerting.

Much as I hate to suggest you need more monitoring, web sites and web applications shouldn't be left alone. So I'll write more about this in the new year.

In the meantime, here's my seasonal card—even Christmas trees have CCTV cameras in them now:

Seen in a London shopping centre, early December 2008.

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.

Chris Hayes has posted an important reminder of the difference between the risk of non-compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) and the risk of the defects themselves.

Read his Risk and PCI-DSS posting on Risktical Ramblings.

Cotton Traders survived a payment card data breach earlier this year and has gone on to implement tighter controls. It was not clear at the time of the breach whether they were PCI DSS compliant or not.

Chris mentions non-compliance with PCI DSS. Not many merchants should seriously consider remaining out of compliance—micro, small and medium sized enterprises in particular may not survive the consequences of a security breach followed by the effects of being found to be non-compliant.

He also refers to the Common Vulnerability Scoring System (CVSS) in his posting. It is quite a complex standardised method for rating information technology (IT) vulnerabilities and you can read his thoughts on CVSS starting at Risk and CVSS (Post 1) which highlights the dangers of applying methodologies and metrics without a full understanding of them and what aspects are being included/excluded.

For those of you planning new web projects in the new year, here are some pointers for accessibility resources to keep in mind. Accessibility is not a marginal issue—by enabling web site users to interact with your web application without hindrance increases trust, improves the accuracy of information submitted and reduces errors. These are all aspects of software quality.

Accessibility sometimes get lumped in solely with talk of disability. But lack of special aids or adaptions haven't been a significant barrier to internet usage by disabled people. Like everyone else it's cost, lack of skills and confidence. So what should we be doing for all users?

BSI British Standards is now inviting comments on a new Draft for Public Comment (DPC) BS 8878:2009, the draft standard on accessible websites (registration required). Based on the Publicly Available Specification (PAS) PAS 78:2006 Guide to Good Practice in Commissioning Accessible Websites which will ultimately be withdrawn, the final date for submissions is the end of January 2009 with an aim for the standard to be published in summer 2009. Thankfully, BSI have now published the complete documents in PDF and Word format (no registration required), since the mechanism for reading and providing feedback is an excellent example of an unusable application! The draft standard is summarised by the document's statement:

I'd add "safe" to the list.

Last week saw the Web Content Accessibility Guidelines 2.0 (WCAG) becoming a full W3C Recommendation. Key reference WCAG 2.0 Documents are:

• WCAG 2.0 at a Glance
• How to Meet WCAG 2.0: A Customizable Quick Reference
• Understanding WCAG 2.0
• Techniques for WCAG 2.0
• How to Update Your Web Site to WCAG 2.0
• Essential Components of Web Accessibility

These aspects are increasingly being highlighted in web project contracts and specifications - and system architects, designers, developers and testers need to know how to build compliant applications. It is important to understand that users won't just be using popular modern web browsers; all sorts of devices will be utilised. The information security shouldn't be less for anyone—regardless of their access method.

One aspect of WCAG 2.0 is maximising compatibility with current and future user agents, including assistive technologies. A related project from the Accessibility Interoperability Alliance (AIA) worth monitoring is concerning Common Keyboard Shortcuts for Accessible Technology (AT) Products Used with Web Browsers along with the Open Web Application Security Project (OWASP) Intrinsic Security Working Group's efforts on introducing more useful security into all web browsers.

There's a new resource for web application architects, developers and testers who want to find out more about the security properties of the most common web browsers.

A message was posted to the The Web Security Mailing List today highlighting the Browser Security Handbook. I've yet to digest all the information but it seems to be very comprehensive. The web browsers recently tested and reported on are:

• Microsoft Internet Explorer 6 & 7
• Mozilla Firefox 2 & 3
• Apple Safari 3
• Opera 9
• Google Chrome
• Android

The inclusion of test cases in the download is especially helpful. We should thank all the contributors for this excellent live document.

Last Thursday I attended the latest OWASP London meeting to hear two excellent speakers.

Justin and Adam from Gotham Digital Science presented demonstrations of a potential SQL injection worm and their Secure Parameter Filter (SPF) for IIS either side of a round-up from Dinis of the OWASP EU Summit 2008 outcomes.

SPF looks like a promising quick-patch tool for vulnerable web sites (written in any programming language) that are served by Microsoft Internet Information Server version 7 (IIS7) or could be served via an IIS7 proxy - if the site's written in ASP.NET, it's definitely worth serious consideration, even on IIS6. The main benefit is protection from tampering of parameter values, URL manipulation and replay attacks, combined with some blacklisting of cross-site attack code in user-supplied input. There are potentially some usability issues relating to restricting application entry points and having token time outs, but the tool of course needs to be configured to suit each site. Do take a look.

There are a pair of identical trial web sites available (from the page linked above) with and without the SPF tool installed - having seen the demo I'm looking forward to trying this on some test sites.

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.