Input validation and output encoding are key aspects of web application security. This morning I've just been using a data search on a website and came across this when no results were found:

I imagine "escape(escape())" is some attempt at preventing cross-site scripting (XSS), but implemented correctly. Interestingly, when search results are found there are several "-->" appearing. Another indicator of output encoding problems.

It doesn't have to be difficult - read the OWASP XSS Prevention Cheat Sheet.

Testing a web site is important, and smoke/regression testing would normally be undertaken each time the web site's code is updated or extended. But what about third party code and data on your web site? I was using a shop's store locator and it wrongly identified the two closest store locations to Farringdon Station in Clerkenwell, EC1M. Both Euston Station NW1 and Canary Wharf E14 are further away than the third result, Cheapside.

Intrigued, I zoomed in on the map and the ordering of the first two results swapped. And the data point for Canary Wharf seems to be located in the centre of the City of London, instead of its actual location downriver on the Isle of Dogs. The data point for the first result wasn't even displayed.

So is this a third party problem, or something else? Well, without investigating further you can't really tell, but it's the concept that matters.

This inaccuracy is worrying for a number of reasons:

• Customers may have difficulty locating shops.
• It undermines customer confidence and therefore trust in the brand.
• It indicates a lack of care in the web site's development and may put off online shoppers.
• It could indicate the presence of a security vulnerability which could be exploited to damage the site, its data or its users.
• The same geo-location code may be used for other internal calculations such as marketing data processing that affect business decisions.

If you are including functionality or data from third parties, you need to know when that system or service is updated. This notification requirement should be built into contracts. In this case, the data being returned may be inaccurate, formatted in an unxpected manner or be exposing a fault in your own processing of the data. Undertaking input validation on the data provided by the third party and output validation on what you are about to send back to the web site user need to test for reasonableness as well as more technical checks. Why not cross-check that the first result's postcode is closer than the second and the third?

It may just be a problem with the company's own data, but that's even more worrying.

The review of safety at BP's Texas Refinery following investigation and report on the explosion in 2005 which killed 15 people, injured 180 and caused substantial property damage, included a recommendation to use pre-startup safety reviews (PSSRs).

We can all learn lessons from unfortunate incidents like this in other disciplines (e.g. also the sinking of the MV Herald of Free Enterprise in 1987). Do web site developers and designers have an equivalent pre-launch security review (PLSR)?

I remember once reading an email press release about a new web site, only to visit it and find out that within a few link clicks you ended up in some sort of CMS admin area; we stopped browsing immediately and contacted the site's owner. In the past I have also been asked to make a web site live on Friday afternoon at 4pm; the answer has to be "no".

What should a PLSR include for a new or revised web site? If you don't already have a security policy, standards and procedures, here is a checklist of suggestions:

Not all these checks will be needed for your project but the order in which they are done is important. For a small web site with little functionality, this doesn't have to be complicated. For example, the build documentation and disaster recovery plan could mean having a full set of source files (pages, scripts, images, etc), each night's full backup of any changing data (e.g. database and generated files), login credentials, some notes on the server's configuration and contact details for the domain name registrar, design agency and hosting company.

For any project, try to discuss launch as early as possible in its lifecycle—preferably at the bidding/tender stage, but if not, immediately on project initiation. Define the launch/release criteria well in advance. Find out what the client and project owner's expectations are and who will be responsible for what. A good launch takes time, so make sure the team have enough time to complete the launch and subsequent checks without it running into abnormal hours of the day. Your web site project's failings might not lead to people's deaths, but that doesn't mean sloppy configuration, launch and operation are acceptable. What standards do you have?

Please let me know if you think anything should be added to or altered in this launch checklist.

PS if you are looking for a launch checklist that addresses wider website issues, I'd recommend the The Ultimate Website Launch Checklist.

The Ponemon Institute has realeased its latest survey of UK data losses.

The findings of the 2009 Annual Study: Cost of a UK Data Breach indicate that personal data losses ("breaches") are still increasing in cost (per record). The report discusses the growth of data breaches due to malicious attacks and botnets, how prevalent these are compared with other losses and the relative costs. The report also presents comparitive data for losses involving third parties, and for organisations who have experienced their first data loss.

Although we hear a lot about lost or stolen devices (laptops, USB sticks, mobile phones, etc) and malicious/criminal attacks, the most common primary cause for the losses was negligence.

The recent news that the German government is considering buying stolen personal data of its citizens who it suspects of tax evasion is worrying. This sort of activity may fuel personal data theft by leavers and disgruntled employees.

The report is available in PDF format.

Today I thought I'd share some of my favourite blog posts about building software securely by implementing web application security programmes.

The excellent blog posts about building a software security assurance programme are:

• Rafal Los on Enterprise Web Application Security and Building a Web Application Security Program Without a Budget
• Justin Clarke on The Fallacy of Secure Software
• Adrian Lane on Agile Development and Security

Can you recommend any others?

As a reminder, the main software security maturity models and process models are:

• Building Security In Maturity Model (BSIMM)
• Microsoft Security Development Lifecycle (SDL)
• National Institute of Standards and Technology (NIST) SP 800-64 Rev2 Security Considerations in the Information System Development Life Cycle
• Software Assurance Maturity Model (SAMM)

Last week Microsoft also released a short document describing how to implement a simplified version of their SDL.

Which should you choose? It's what works in your own organisation that matters. Ask your software suppliers (e.g. web developers) what they use before you buy.

This weekend I'm going to a fancy dress party with a theme of film actors and characters, and was looking for Toy Story Buzz Lightyear gear.

One price comparison website listed a Buzz Lightyear toy at £999999.00 which seems rather high. It was either made from something very valuable, or an error.

How do you validate pricing information being added and also when displayed? Who/what can alter pricing, discounts, additional charges, tax rates, etc on your e-commerce web site? What approval processes are in place? Who is accountable? All data should be checked for reasonableness, type, format, characters, length, encoding, etc. Reporting/alerting on changes might also help detect this type of issue.

And, make sure your terms state what happens if a price is "incorrect" and exactly when a contract is formed.

The next Open Web Application Security Project (OWASP) London meeting is this week.

The London chapter meeting is on Thursday 14 January 2010 in EC1. Everyone is welcome, but you need to register first (free).

There will be talks on Top Ten Deployment Mistakes That Render SSL Useless by Ivan Ristić and Using Selenium to Hold State for Web Application Penetration Testing by Yiannis Pavlosoglou, who recently joined the OWASP Global Industry Committee.

Unfortunately I am unable to attend the meeting but hope to read the presentations afterwards.

Web sites are being published "in the cloud", but what are the cloud computing security risks?

I have mentioned previously the excellent Cloud Computing Benefits, Risks and Recommendations from ENISA. Yesterday the Cloud Security Alliance (CSA) published their updated document Security Guidance for Critical Areas of Focus in Cloud Computing V2.1 (December 2009), which was previewed at last month's OWASP AppSec DC 2009.

The operational domain (the term used for a category in this guidance document) of Application Security will be of most interest to web folk, but the remaining architectural, operational and governance domains provide full coverage of the cloud computing risks. After all, there's no point securing your web application if the server's wide open to abuse, or you don't have the clear responsibilities defined, or you don't have access to the data in the event of a disaster.

The recent Amazon EC2 Botnet is a timely reminder of the issues that can occur.

In April I described some issues with Web Application Security in the Cloud - Part 1 and in Part 2. The CSA's Domain 10 (Application Security) describes five aspects to consider:

• application security architecture
• software development life cycle (SDLC)
• compliance
• tools and services
• vulnerabilities

and provides a number of key security recommendations. The same pattern is used for the other domains.

Alternatively, if you are looking for a broader introduction to the subject, I'd recommend the book Cloud Application Architectures by George Reese and published by O'Reilly (ISBN 978-0-596-15636-7). This also has a chapter about security, but the ENISA and CSA documents provide much wider coverage and greater detail.

Examples of content aggregation often refer to the use of web services and XML data such as RSS feeds. But today's world of web 2.0 in creating more and more data in a wide variety of formats including JSON (JavaScript Object Notation); and web applications are being used as a concentrator to combine these together.

With the growth of layered communications, multiple communication channels such as text, video and audio are merged into one event. If the content is recorded it can be republished via a web site. But what are the specific security risks of this?

Web services and XML data can include invalid or malicious data. The format/schema may be incorrect. But with the increase in layered communications, content from many different devices in many media may need to be aggregated into a single resource; and these often don't have any formal syntactical structure. The data might even include active content such as embedded rich applications.

If these need to be stored and replayed such content at a later date, how might they affect a web page? The content could contain, or link to, malicious content that steals user data such as session cookies, modifies the page's content or installs malware onto user's computers.

• Identify all the data streams.
• Determine their formats and encoding where appropriate.
• Ruthlessly limit what active (script) content is allowed and what ability it has to interact with the parent web site and its domain.
• Analyse the data streams to validate they contain what is intended and scan for malware.
• Sanitise content where applicable.
• Limit file size/length/number of nodes.
• Avoid merging trusted and untrusted content in data fields.
• Encode the output correctly for your own application.
• Monitor activity and look out for unusual events.

And beware embedding rich internet applications (RIAs) such as Adobe Flash or Microsoft Silverlight, which may be doing this aggregation themselves.

After all, you don't want your web site to be a concentrator multiplexing malware.

After yesterday's long day (Thursday) at Open Web Application Security Project (OWASP) AppSec DC 2009, the second day (Friday) began promptly again at the Washington Conference Centre.

The second day had four different streams:

• Process
• Attack and defend
• Metrics
• Compliance

My own programme comprised:

• The Big Picture: Web Risks and Assessments Beyond Scanning, Matt Fisher
  A description of why automated security scanner are not sufficient to cover an entire application or detect most vulnerabilities.
• SCAP: Automating Our Way Out Of the Vulnerability Wheel of Pain, Ed Bellis
  A description of how SCAP standards can be used to combine various vulnerability feed data into a single organisation-wide repository that can be used to normalise and correlate data.
• OWASP Top 10 2010, Dave Whichers
  First look at RC1 of the new OWASP Top 10, planned for release in early 2010.
• The 10 Leasr-Likely and Most Dangerous People on the Internet, Robert Hansen
  Key people/roles in named organisations who, if compromised, could have significant adverse effect on the secure operation of the internet.
• Deploying Secure Web Applications with OWASP Resources, Sebastien Deleersnyder and Fabio Cerullo
  Case studies in the education, financial and telecommunication sectors.
• Injectable Exploits: Two New Tools for Pwning Web Apps, Frank DiMaggio
  Two new utilities to assist with injection and fingerprinting and a brief introduction to the Samurai web testing framework.
• Techniques in Attacking and Defending XML/Web Services, Jason Macy and Mamoon Yunus
  A description of three types of attack and methods to defend against them.

The presentations will be available on the conference web site.

At the end of the day, prizes for the capture the flag event were given out, vendor draws undertaken and a selection of prizes given to OWASP members who were present, selected at random.

It was a well organised event and the conference team and helpers deserved the praise and thanks.