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.

The proposed new European Data Protection Directive will be announced tomorrow.

Apart from the leaked draft document, there has been plenty of comment (e.g. here, here and here), Viviane Reding, Vice-President of the European Commission, has also been speaking up.

Meanwhile IAB Europe has been busy behind the scenes discussing online behavioural advertising (OBA) and IAB USA has been blogging about its self-regulatory programme. Lots happening then with privacy, advertising and online marketing.

We will find out tomorrow if the leaked document was representative of the final proposals.

After attending the London Web Performance Testing Group on Wednesday evening, I went along to the London Android Group (londroid) at Skills Matter.

Mixing Native and Web Technologies, Oh My included three presentations/demonstrations. Great stuff.

Dave Springgay spoke about his experiences at News International developing highly crafted news apps which provide high quality and high performance on native mobile operating systems. He explained their use of HTML5, Android WebView and Java bridging to use JavaScript to inject content (mainly JSON) directly into pre-built HTML templates which are customised for each device, and which can be updated without re-deploying the app.

Jonathan Anthony provided an overview of the advantages of building mobile applications as webapps, using PhoneGap, using Titanium, and finally as native apps. He explained the latter of course give the best performance, better graphics and access to all the hardware APIs (with geo-location and camera being the most popular) along with the ability to have an icon on the desktop, but come at a cost due to the higher rates for developers, and the need to develop for at least two operating systems (i.e Android and the other one). He thought that for many apps, a webapp should be considered, due to speed of development and the cross-platform capability making them perhaps a quarter of the price.

Finally, Doug Chisholm and Clinton Smith described the capabilities of appsplash to develop cross-platform applications using their custom development platform.

So that's the technologies presented, but jQuery Mobile and jQTouch were also mentioned. Plenty to keep tabs on.

Gartner published its report Magic Quadrant for Dynamic Application Security Testing (DAST) at the end of December.

The report is currently available to download free of charge if you register on Veracode's website. But it looks like if your turnover is less than $500 million, or say it is, the sales folk may be less likely to bother you.

The report is a useful summary, but I don't think it does enough to highlight the need for DAST to be just one part of a mix of activities contributing to a secure software development lifecycle, and therefore more secure applications. There's plenty of activity out there combining developer training, secure coding guidelines, vulnerability management, web application firewall dynamic patching and static analysis techniques too.

Veracode has previously published significant data about software security in volumes 1, 2 and 3 of their State of Software Security Report.

In Volume 4 of State of Software Security Report additional analysis has been possible due to the larger data set available. In this volume emphasis is given to the analysis of the (primarily US?) governmental sector, as well as more data on the effect of developer training and education on software security. On this Veracode report that a "high level of application security knowledge also delivered higher security quality applications". That's encouraging since developer training is one of the first areas where effort should be expended in creating a secure software development lifecycle programme.

On of the other interesting conclusions was the potential fast turnaround for remediation and re-testing to solve problems suggesting that "development agility and application security are not mutually exclusive".

Cross-site scripting continues to be the most prevalent vulnerability overall — there was an interesting discussion last week about what this means in terms of business impact on the Web Application Security - From the Start blog.

Volume 4 also includes some initial results on static code analysis of Android applications. If you are developing mobile applications, do read the OWASP Mobile Security Project's Top 10 Mobile Controls and Design Principles.

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.

Another report from the European Network and Information Security Agency (ENISA) highlights deficiencies in the maritime sector.

The study's report Cyber Security Aspects in the Maritime Sector discusses that while there is increasing knowledge concerning physical security and crew safety, maritime cyber security awareness is low to non-existent. The situation is made worse by fragmented responsibilities, lack of incident information, and missing legislation in this area.

A relatively quick read if you are active in the sector.

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?

Didn't 2011 go fast? Still a couple of days until Christmas day, but this will be my last post before then.

Season's greetings to you all. I have a couple of final posts before the end of the year, about two more documents worth reading. One is rather long and detailed...

Last week, the European Network and Information Security Agency (ENISA) announced the publication of two guidance documents relating to Article 13a of the new telecommunications legislation (Directive 2009/140/EC) regarding security incidents and security controls.

I don't often quote legislation here, but I thought it was relatively short and provides the intent behind ENISA's guidance. ENISA has published two documents.

Technical Guideline on Incident Reporting provides guidance on the annual summary of significant issues and the notification of cross-border incidents. While most (all?) readers of this blog won't necessarily work in the telecommunications sector, I think the document is useful more widely for two aspects. It demonstrates the type of reporting which could be required if breach notification becomes a requirement for other sector or types of data (e.g. personal data)in the future. Also, the Section 5 on impact parameters and thresholds provides some insight into the continental and national viewpoint on the effects of security incidents.

The second document Technical Guideline on Minimum Security Measures defines the security controls national regulators need to consider when evaluating public communications networks. These are relatively high-level and are grouped into governance/risk management, human resources security, security of systems and facilities, operations management, incident management, business continuity management, and monitoring, auditing and testing. So a clear mapping to ISO27001/2/5 for information security and risk management, and BS 25999 for business continuity.