The first report on the state of software security has been published by Veracode who provide a cloud-based application risk management service.

The data presented in State of Software Security Report - The Intractable Problem of Insecure Software are interesting, it relates to both web application (40%) and non-web application (60%) software but spans in-house developed, commercial, open source and outsourced, developed in .NET, C/C++ and Java. But don't get bogged down in the data. I'd recommend that everyone responsible for web development, or who commissions or operates a web site, read the executive summary. I was quite surprised that backdoors (a method of bypassing normal authentication) are still a significant issue: "Open Source projects have ... fewer potential backdoors than commercial or outsourced software". This is why "V13 Malicious Code Search Verification Requirements" appears in the Application Security Verification Standard.

There are seven recommendations, which are in summary:

• Implement a comprehensive, risk-based, application security programme.
• Implement security acceptance criteria for third-party suppliers.
• Test code from outsourced, commercial and open source suppliers as rigorously as internally developed code.
• Verification of C/C++ code must not be ignored and it is likely to be present in many applications.
• Implement specific developer training on security.
• Learn from organisations in higher-risk sectors such as finance and government.
• Ensure security requirements are built into outsourced software development.

Some good advice there. The report provides a fuller description and gives the background to these recommendations.

I guess there must be much more detailed data available to Veracode than is presented in this "Volume 1". Perhaps Volume 2 will look at trends over time, but I'd also like to see:

• Breakdown of root causes (e.g. unvalidated user input).
• Breakdown of how the vulnerabilities had been fixed when the software was re-tested (e.g. parameterized queries implemented).
• What proportion of faulty code was identical — found in more than one application (i.e. copied/duplicated from elsewhere).
• Details of any secure development lifecycle in use by suppliers and their level of maturity with these.

Hopefully this type of aggregated data can be shared under Veracode's terms of service and agreements with individual customers. The software suppliers included in Veracode's analysis are likely to exclude customer organisations who do not have the knowledge or resources to have their code analysed. It would be an interesting research project to test a selection of applications developed by other suppliers to see how they compare.

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.

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.

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.

It's that time again when organisations want your opinion on how well they've been performed in the previous year. I'm often quite happy to provide feedback, but sometimes prefer this to be anonymous.

Many of these surveys use third party services to display the form and collect the data, but very few have privacy notices or details you would expect/require on a corporate web site (e.g. the company registration number and registered address). But I can't remember one of these where the option for complete anonymity is provided. The links often include a code in the address URL (an argument name with a value) which I suspect identifies the recipient.

I copied the link and removed the value from the argument and was presented with a horrible error message which gives clues as to what the site is doing. Perhaps a database query that can't find NULL as an identifier?

Then I tried it with the argument completely removed.

So very sloppily put together. At least hide this script error message. Better still, inform me why this code is necessary and give options for anonymity. After all, some feedback is better than none.

If you're going to use third party services, ask them what security verification has been undertaken and to what standard. They should be able to provide details of a recent independent audit if they don't allow their customers to verify security themselves.

Today the Council of Registered Ethical Security Testers (CREST) and CESG, the UK national technical authority for information assurance, are running the first Ethical Security Testers Conference at Royal Holloway, University of London.

I am attending the conference on behalf of the Open Web Application Security Project (OWASP) Global Industry Committee. Apart from the web security related presentations, I am particularly looking forward to hearing about CREST's progress and the future of CREST/CESG certification schemes.

I will update this posting at the end of the day tomorrow.

Update 16th December 2009: There were many familiar faces at the well-attended first conference. CREST and CESG had put on an interesting programme of mainly technical speakers—the demonstration of the Context App Tool was particularly useful for the application testers present, and I'm looking forward to trying the beta 3 version. Infrastructure security testing presentations were given on USB drivers, Windows authentication, CISCO IOS, deployment solutions and full disk encryption products.

CREST and CESG outlined their vision for information assurance professionalism, and it sounds like the CREST scheme is growing in momentum both in the UK and overseas. It seems there may soon be CREST services available in South Africa abd Benelux, and mention was made of some potential partnership with the SANS Institute.

As I prepare to go to OWASP BeNeLux Day 2009 tomorrow to speak about compliance driven vulnerabilities in web applications, the aspect of auditability came to mind.

Audit logs record user-initiated activity (human or otherwise) in a system or application. They are a trail to establish accountability and responsibility for processed transactions i.e. what, when, where and who. Some form of audit trail is often specified in a web site's requirements, but this is often incorrectly seen as independent to other requirements. All software test cases should also identify the expected audit trail outputs and check they are being generated correctly:

• It is not sufficient for the user functionality to match the requirements alone.
• The generated audit trail must match the tests undertaken.
• It must be possible to determine the original actions from the audit trail.
• Mis-use cases should generate appropriate trails as well.

In-built audit hooks (embedding code in applications for the examination of selected transactions) and continuous auditing (near real-time auditing logic) must not introduce their own vulnerabilities:

• The extra complexity of audit code in an application requires additional security verification.
• Identify the trust boundaries around these parts of the application.
• Ensure the audit code cannot be used by malicious users to circumvent other controls such as authentication and authorisation.

Test cases will also need to be prepared to verify the protection and management of the audit trail. Ensure the integrity of the audit trail:

• The trail must be protected from subsequent modification (alteration and deletion).
• Even if the amount of logging is configurable, the default should provide sufficient detail for the business's needs.
• It should not be possible to completely inactivate all audit trail generation.

NIST have a useful document SP 800-92 on management of security logs—many of the considerations are similar for the protection of audit trails.

The extraction and examination of audit trail data must be controlled:

• Audit trails may contain personal and other sensitive information.
• The data may give away information regarding the application's code and logic.
• Consider whether parts of the data may need to be excluded, masked or encrypted.
• The privileges to read audit trails should be restricted and reviewed periodically.
• All access to the audit trail must be recorded and monitored by a separate manager.
• Audit trail data must not be destroyed before the duration of its required data retention period, and not kept beyond this time.

Remember that in some jurisdictions, capture of any personal data or monitoring of employees may need particular approval and safeguards, and some data may not be allowed to be stored at all. Happy verification!

Strange as it might seem, some people publish, usually unwittingly, detailed information about the structure of their databases by revealing SQL (Structured Query Language) code.

I don't mean in error messages (which should of course never be displayed to web site users):

Nor in the generated web page source code (you wouldn't do that would you?):

Nor even when it's in a URL (I won't ask):

No, what I mean is when the code is simply indexed and appears on the site's own web pages (often as search result listings), and which then sometimes subsequently picked up by Google, Bing and so on:

So what's going on here? Without more information, I can only surmise, but I think these web sites are using catalogues (pre-built registers or collections) to index the web pages. However some of the pages have static content and others are dynamically built using database queries. So the indexing tool is recording the text from the scripting language rather than what is generated "at run time" to the web site user. These scripts should not be indexed, and thus leaked, in this way; instead the static results need to be merged and ranked with appropriate links to dynamically-created pages. If I search a dictionary web site for "query", I don't want a link to a page that has this in the code, I want the actual pages that define or reference the word "query".

The danger of automated indexing, is that it can include all types of unforeseen files in its catalogue, including backup and old copies of files, unless the indexing strategy is considered carefully:

Having the SQL displayed in this manner makes it much easier for someone to compromise the data, damage the site or its users.

Sometimes finding all the web applications in an organisation can be the difficult part in trying to assess what risks exist.

Transport for London don't just have web sites and, I suspect, an intranet. They have been gradually moving from whiteboards for live underground travel news at tube stations:

And now have electronic versions:

I don't know what technology is being used here, but other information boards have been seen to display web browser error messages leaking network information:

But, what about elsewhere? I saw this on the live electronic advertisement boards at Bond Street station this weekend:

Sorry it's a bit blurred, but I was going up the escalator at the time. Several, but not all the displays had their system names shown rather than an advertisement. It certainly looks like an IP address, but is there a web application inside? I've previously highlighted other information systems and displays that seem to be IP-enabled.

An investigation of your network, examining what is listening on which ports, and correlating this with the actual network traffic, might reveal more web applications than you thought.