The exposed surface of an application is often called its "attack surface" or "defensive perimeter". I prefer "exposed surface" since the term is a little less judgemental and I think better implies why we need to be careful about it.

Remember that many security weaknesses come about due to unexpected functionality existing, as well as implementation and design flaws. The number of weaknesses is generally proportional to complexity, often measured as lines of code, or in the context of this discussion, this is often proportional to the amount of exposed surface. The exposed surface of a web application would be all the addresses (URLs), methods (e.g. POST, GET, HEAD) and parameters (form, query string, URL path, cookie and other headers) which the application responds to. Quite often this normally means every possible path and combination of parameters you can throw at it, even if the results is just a "not found" error message.

I was reminded to write about this topic, after reading Essential Attack Surface Management recently on Jim Bird's Building Real Software blog. I like his suggested approach of, well at least making a start, even if it is to focus only on the higher risk areas. Things like search engine friendly paths, dynamic URLs and URL rewriting will cause difficulties, but these are not insurmountable, especially if the site's path naming system can be considered, analysed and defined early in the development process. You might also want to focus on the authenticated parts of the application first.

If you can reduce the exposed surface, or even better limit it to only the necessary entry points, this is a huge step forward in defending your application. Your web application will be a combination of the necessary functionality for your business processes, combined with extra functionality (intended or otherwise), but it also needs to be able to handle other types of request gracefully (e.g. site icon, robots.txt file, missing page tests).

The types of things which are commonly exposed, but should not be are:

• Templates, used by other scripts
• Included code, such as modules and libraries, never meant to be an entry point
• Entry points meant for users with a different role or permissions (e.g. system initiated web services, customer-only content)
• Unused, but included, functionality.

The exposed surface might also include the following things, but should really never exist in web-accessible locations:

• Administrative interfaces
• Logs
• Temporary files
• Configuration files such as encryption keys (yes really), and database connection strings
• Backups
• Default installation files, including help documentation
• Old and archived scripts, test versions of a site, and other unused content.

Some entry points may only be meant for different groups of authenticated users, although there may be some overlap with unauthenticated public users. Every application will be different, but the following attempt to illustrate this for a public website with some functionality used exclusively by authenticated customers.

There are choices on where you enforce limitations on the inbound exposed surface. Some typical places are:

• Network firewall
• Traffic management device
• Web application firewall (WAF), guard or other type of filter
• HTTP proxy server
• Web server
• Application code.

No one of these is the best answer, and in many cases it is better to use a combination of more than one. For example on a web-based content management system, you might use a firewall to limit access from only known office IP addresses, use a web application firewall to limit requests to only well-formed HTTP requests and for known URLs and parameters, use the web server or proxy server to enforce the use of TLS, and let the application enforce the parameter type and range checks, before any business layer authorisation checks and input data validation occurs. The decisions might be different here if requests from internal users do not pass through all the same network devices.

You might even enforce the same restriction in more than one place. For example, you may only open port 443 through a network firewall, as well as having the web server listening solely on port 443, and also the application checking TLS is in use and setting the Secure flag on the session cookie.

But do remember, your web applications will probably also receive requests for entry point URLs that are not on your list, and which are not necessarily malicious, you may have forgotten to take into account, or include unexpected extra or missing parameters. You may want to ensure the web application responds in the correct manner for your own context and user base. Just blocking everything else may not be the correct option.

If you are in a situation of being unable to determine the exposed surface, there are approaches to use application profiling to create a good estimate. At its simplest this may be undertaking a web site crawl, but there has been some work in the area of using web application firewalls to build up a model of the site from actual usage. There is some good information on using ModSecurity for this, and I will try to summarise the information sources in a later post.

Another approach is to fingerprint the page content and monitor for changes such as defacement and cross-site scripting injection. Again, I will look out some references I have for this.

Happy new year. Planning your diary already? Looking for the best European conference for information about application security?

Europe's premier application security conference, AppSec EU, is being held in Athens, Greece, from 10th to 13th July 2012. As in Stockholm two years ago, this event has a research theme, but there will be plenty of practical information, advice and application security training.

In May I participated in the OWASP Greece chapter Training Day in Athens and was overwhelmed by the level of attendance from the enthusiastic and knowledgeable development community. I am sure the sponsorship opportunities and tickets will be snapped up quickly.

AppSec EU Research 2012 is being hosted by the Department of Informatics and Telecommunications of the University of Athens.

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

The W3C's Tracking protection Working Group has published two working draft proposals for implementing "Do Not Track" online.

The proposals will allow users to define whether or not data about them can be collected for tracking purposes. Thus the proposals include information on how consumers express their tracking preference, and also how the websites and related systems (e.g. affiliates) will acknowledge those preferences.

Tracking Preference Expression (DNT) (W3C Working Draft 14 November 2011) describes how users express their preference and how websites indicate whether they honour such preferences. The proposal is to utilise a new HTTP request header "DNT", a machine-readable web-accessible file defining the site's tracking policy and an HTTP response header for the site to communicate its compliance with tracking preferences.

Tracking Compliance and Scope (W3C Working Draft 14 November 2011) defines the meaning of a "do not track" preference and will set out practices for websites to comply with this preference.

These are very early drafts, with many unresolved issues. W3C hopes to have adopted standards by June 2012, but in the meantime is inviting review and comment. For websites hoping to adopt and promote compliance with this proposal, now is a good time to start defining a project with a view to firming up the requirements in April 2012 when a candidate recommendation will be published. The broad requirements can be seen from the current documentation.

Tired of digging through page after page of links to find knowledge about a work-related subject? Making information security guidance accessible is a challenge too.

Microsoft has announced a new SDL Industry Talk Wall on the Security Development Lifecycle (SDL) website. It is a live view of news, resources and answers to common questions around SDL, created using HTML5, with the ability to filter by return on investment, progress of the SDL itself, tools, cloud-related aspects and events.

This is a great way to promote secure software development lifecycle processes, and encourages people to browse through the latest information. I wish I had thought of doing this before.

This week I was drafting a penetration test scoping document, and Word's grammar-checker gave me an interesting suggestion.

I had written a rather poorly crafted sentence, and at first Word suggested I add the word "neither" to improve readability. That seemed reasonable, but then it suggested I reword the entire sentence to: "The penetration tester that contravenes neither United Kingdom legislation nor any PCI-DSS requirement shall undertake nothing".

A fascinating insight, but not quite what I had in mind. Althought it might be true, I started my sentence from scratch again.

COBIT defines a range of domains, processes and control objectives relevant to to secure software development lifecycle. ISACA has now published a white paper on web application security risks.

Web Application Security - Business Risk Decisions provides an introduction to the security issues relating to web applications and discusses the risks and common security weaknesses. It references other projects and resources that are relevant to web application security.

The paper recommends a systems-based approach which will be familiar to adopters of COBIT and similar frameworks. It emphasises the governance aspects, especially the need for enterprise support. The paper recommends a programme to drive security throughout the SDLC to include:

• Business/executive support
• Training
• Supply chain
• Policies and standards
• Technical controls
• Ongoing programme of scanning/code review
• Legacy code
• Project management
• Effective incident response capabilities

The approach is welcome. IT Auditors can be your friends! It will be interesting to see if this develops into a more formal initiative by ISACA.

I have been out and about this week at some events in London.

On Tuesday evening I attended another meeting of the London Ajax User Group hosted as usual at the nearby Skills Matters eXchange. The meeting had attracted over 50 developers who had come to listen to the talks — one about using HTML5 Web Sockets, and the other about template-based JavaScript development. Well I shouldn't really have been surprised by the number of attendees, the user group's slogan is "London's largest group of Ajax, JavaScript and HTML5 developers", so the topics were right on target.

Micheil Smith began by describing how HTML5 web sockets can be used to provide near real-time web for interactive content. He explained how web sockets are replacing pseudo real-time techniques like HTTP polling, LiveConnect, forever iFrame, HTTP long polling, and XHR streaming. He described uses for web sockets and some of the issues that can cause problems such as ports blocked by firewalls and different traffic patterns leading to server capacity problems.

Mark Wubben then explained how sites/applications need to work with and without JavaScript. He discussed a method called Eyebrow, based on Mustache templating language and Django Template Language (DTL), which achieves this and harnesses the power of server side generation combined with application execution on the client.

These user groups are a great way to keep in touch with issues developers are having and technology trends. Then on Wednesday and Thursday I attended RSA Conference Europe 2011 which had a more corporate/security type of audience. The two presentations I found most useful were by Bryan Sullivan and Ramon Krikken.

Bryan Sullivan explained security issues related to NoSQL databases — similarities and differences with relational databases, and what extra set of issues need to be considered when designing and developing systems using these data stores. He demonstrated injection techniques against MongoDB and then moved on to compelling examples of server-side JavaScript injection using Node.js as an example. He discussed risky constructs to look for during code review and ways to avoid some typical pitfalls. Lots of things to add to my code review and security testing notes.

Ramon Krikken described usage scenarios for tokenisation of sensitive data and explained that he thought tokenisation is oversold, under-analysed and not well understood. He outlined the issues around choice of algorithm, architectural implementation, input data and business processes which have led him to the conclusion that tokenisation is cryptography, if not actually encryption. This presentation really was an eye-opener and cut right through to the weaknesses and possible attacks on such systems. If Ramon is speaking near you, make sure to go along. There is a summary podcast available.

I also enjoyed the discussion group run by Brian Honan focused on the practicalities and issues of incident response in the cloud.

My own session about attack-aware software application built upon my previous presentations at AppSec EU 2011, the Software Assurance Forum Fall 2011, the training course I gave and AppSensor Summit at AppSec US 2011. It is always good to receive views & feedback, and about ten percent of the audience of 70-80 had questions or comments to make. I will also be talking about this topic at OWASP Leeds on 25th October.

Building Security In Maturity Model (BSIMM) version 3 (BSIMM3) was released on Tuesday by Cigital and Fortify.

Building Security In Maturity Model is an analysis of the results from a detailed surveying process about how companies build security into their software development processes. Its aim is to help all organisations understand, assess and plan software security initiatives. The findings identified are grouped into 12 practices across four domains called governance, intelligence, SSDL touchpoints and deployment in what is called the Software Security Framework. In these practices, a total of 109 activities are defined, spread across three tiers of complexity (levels 1 to 3) to give the appearance of a maturity model.

BSIMM3 includes data from 42 software security initiatives — 12 more than in BSIMM2. Although the data is primarily collected from organisations in the financial services, independent software vendor and technology sectors, other sectors are represented too. Many of the programmes are large, with the average number of developers being over 5,000 — but it ranges from just 10 to 30,000. No organisation survey does all 109 activities.

With the increase in source data, there has not been any significant change the the general findings, and the structure of domains, practices and activities has virtually not changed at all. The descriptions for most of the activities have been extended to clarify the meaning and provide further examples; in a small number of cases minor corrections have been made. But the total number of activities in unchanged, and their titles are the same. The following activities have been demoted from level 2 to level 1:

• Strategy & Metrics (SM) 2.4 "Require security sign-off" is now SM 1.6
• Attack Models (AM) 2.3 "Gather attack intelligence" is now AM 1.5
• Security Testing (ST) 2.2 "Allow declarative security/security features to drive tests" is now ST 1.3
• Penetration testing (PT) 2.1 "Use pen testing tools internally" is now PT 1.3

One activity has been promoted from level 1 to level 2:

• SM 1.5 "Identify metrics and drive initiative budgets with them" is now SM 2.5

So, previous scoring under BSIMM2 will need to be re-calculated, but there is a one-to-one mapping, and the numbering of all other activities remains unchanged.

The new scorecard presentation format demonstrate how to do a comparison of your own initiatives at a glance, and since some of the data sources have now been assessed more than once, BSIMM3 provides some comparison of changes over time.

So, some useful information for organisation wanting to assess and build out software security initiatives. Also take a look at Building Security In, Microsoft SDL, Open SAMM.

After an exciting trip to the United States, the very encouraging interest in OWASP AppSensor, and the productive AppSensor Summit, I'm back in the UK and catching up on a few things.

While I was away, a podcast interview has been published in advance of RSA Conference Europe 2011 where I am speaking about application-specific defences. In the podcast I explained the concepts but during my presentation will discuss specifications, requirements for procurement as well as building application-specific defences into your own development practices.

If you want to find out more, please come along to the Windsor Suite at RSA Conference Europe on 13th October at 13:00 hrs.