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.

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?

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.

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

This week, the Cloud Security Alliance has announced its new repository of security control self -assessments for cloud computing providers.

The CSA Security, Trust and Assurance Registry (STAR) lists providers who have completed and submitted a Consensus Assessments Initiative Questionnaire (CAIQ) or Cloud Controls Matrix (CCM) response to indicate their compliance with CSA best practices.

Currently only two providers are listed, but more are in progress. This will be a very helpful resource for those seeking assurance about controls from suppliers, and potentially standardise the way cloud providers publish information about their security practices, simplifying procurement processes. If you are an IaaS, PaaS or SaaS provider, the existing submissions may help your own controls development or completion of an assessment.

There is more information in the detailed FAQ and LinkedIn forum.

The application security domain (one of twelve) focuses on:

• Secure Software Development Life Cycle (SDLC)
• Authentication, authorisation, compliance — application security architecture in the cloud
• Identity and the consumption of identity as it relates to cloud application security
• Entitlement processes and risk-based access management as it relates to cloud encryption in cloud-based applications
• Application authorization management (policy authoring/update, enforcement)
• Application penetration testing for the cloud (general practices and nuances specific to cloud-based applications)
• Monitoring applications in the cloud
• Application authentication, compliance, and risk management and the repercussions of multi-tenancy and shared infrastructure
• The difference between avoiding malicious software and providing application security.

While on the topic of research papers, I came across another interesting paper on the UC Berkely web site while checking the reference for the effect of development tools on security.

Joel Weinberger, Prateek Saxena, Devdatta Akhawe, Matthew Finifter, Richard Shin and Dawn Song have undertaken an assessment of cross-site scripting (XSS) sanitisation in web application frameworks. A Systematic Analysis of XSS Sanitization in Web Application Frameworks is somewhat heavy on the maths in places, but that shouldn't put off those involved in development who want to learn more about the difficulties of sanitisation and the limitations of the sanitisation methods that are supported in some frameworks.