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've just completed one of those web forms people put in front of useful information before giving you access to gather market research data.

This was published by an information security organisation:

I'm afraid I couldn't "check all that apply" since the nice form only had radio buttons and I didn't feel inclined to edit the HTML myself. Would that have been hacking? Other questions on the same form had the same problem. It didn't instil any confidence in me about their design and testing processes.

Data quality is important. Junk data in will lead to junk answers out.

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.

The inclusion of other people's code in your own web pages increases the potential number of vulnerabilities and it can have an effect on compliance.

Seemingly harmless code from third party sites is often included to provide:

• advertisements (e.g. Google AdSense, DoubleClick, Amazon Associates)
• widgets (e.g. bookmarking and social networking tools)
• web analytics (e.g. Google Analytics, Omniture, Hitbox).

But these normally come with their own terms of service. Like any other component of your site you need to ensure your own privacy policy and, if there is personally identifiable information, your data protection act registration include the purposes (collection, use, retention, transfer) that the third party code requires.

Then the terms of service need to be actively monitored, since they can change unannounced. A recent example of this was the purchase of AddThis, a popular bookmarking widget provider, by Clearspring Technologies Inc at the end of September 2008.

The AddThis terms of service were updated and their widget code changed to include tracking cookies. This meant the widget created cookies on the host web site's domain, as if the host had set them themselves. This is because the widget's code is running in the context of the hosted page. See John Haller's write up for further information. Here's one snippet from the new terms of service:

If you have AddThis on your web site, are your users aware of these terms? A more common issue for web site owners than widgets is the use of web analytics services that have client-side code - typically JavaScript - embedded on each page.

Try to keep third party hosted code off your site, and certainly never have it in more sensitive areas such as registration, log in, password recovery, payments and restricted-access pages. If possible use server-side web analytics rather than adding client-side code.