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?

SQL injection is one of those attacks which most developers have heard of, but may not be familiar with.

I stumbled upon some really good guidance on doing some of your own homework on learning about SQL injection. Best Damn Quick Tips for a Total SQL Injection Newbie (Period) quickly describes three steps (reading, setting up a vulnerable web environment and mimicking attackers) to go from little to lots of knowledge. Yes, really do this on your own test vulnerable applications — never start trying things out on applications or systems you are not authorised to examine.

Then for the last step which is to research defensive measures, the best resource is the OWASP SQL Injection Prevention Cheat Sheet. Happy reading!

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

• Introduction to web application security
• General aspects of web application security
• Access handling (authentication, session management and access control)
• Injection flaws
• Application users and security
• Thick client security
• Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

The OWASP AppSec Tutorial Series has been extended with the publication of a new tutorial about cross site scripting (XSS), probably the most common vulnerabilities in web applications.

The tutorial series project develops fast-moving educational videos which are short enough to capture the main concepts and issues in a very accessible manner. The series now comprises the following episodes:

1. Introduction
2. Injection Attacks
3. [Stored] Cross-Site Scripting

Project lead, author, narrator and editor Jerry Hoff has produced these videos with great flair, and I would recommend them as introductions to application security concepts in security awareness training. Watch out for future episodes.

A US survey of has found that 88% of companies spend more money on coffee than on web application security. We (in the UK) seem to legislate more on fruit juice than either coffee or web application security.

Whilst it was encouraging to read the section on security in the ICO's new Data Sharing Code of Practice, we do seem to have rather more detailed legislation on things like fruit juice than information security. The Fruit Juices and Fruit Nectars (England) (Amendment) Regulations 2011, which were laid before Parliament in April and come into force on Monday, define the minimum Brix levels (sugar content) for fruit juices from concentrate. Wouldn't it be great to see some similar highly specific legislation on securing online applications (and labelling) like this across Europe?

But, back to the coffee... Cenzic have issued their Web Application Security Trends Report Q3-Q4, 2010 which provides an analysis of reported vulnerabilities and breaches attributable to web applications. Its results confirm other recent reports that cross site scripting and SQL injection continue to dominate, despite these issues having being know about for a long time, and there being readily available methods to solve them.

But Cenzic and Barracuda Networks also commissioned the Ponemon Institute to survey 600 IT and IT Security professionals in the United States. The report's findings showed that most companies are spending more on coffee than keeping their web sites secure.

I'm sure the findings for tea in the United Kingdom would be similar. After all, there is a British Standard about how to make tea (BS 6008:1980/ISO 3103:1980). I can't find the application security standard from BSI (...just yet).

After arriving in Dublin last night, I walked to Trinity College this morning and had a little time for a coffee and to greet people I knew before we moved into the lecture theatre.

Following the welcome to OWASP Ireland 2010 by Eoin Keary, Fabio Cerullo & Rahim Jina of the OWASP Ireland Board, John Viega delivered a thought-provoking keynote speech on "Application Security in the Real World". John described real-world problems and approaches to application security need to prove their value. He described seven practices: awareness & training, assessments & audits, development & Q&A, vulnerability response, operational security, compliance and security metrics which, when applied appropriately can demonstrate a return on investment.

OWASP Board members Eoin Keary & Dinis Cruz provided an overview of OWASP's current status, its activities including many of its projects and of the global committees. They described how OWASP's mission "is to make application security VISIBLE for buyers and INVISIBLE for developers". Samy Kamkar was given a brief slot to describe how cross site scripting (XSS) can be used against user's routers to eventually gain the MAC address and ultimately a user's geolocation using Google data.

After a short break and opportunity to look at the sponsor booths, the conference split into two streams for the rest of the morning. Fred Donovan spoke on the topic of "Counter Intelligence as a Defense", describing how gathering information and taking approved action can help identify, assess and potentially neutralise threats to an organisation's ability to conduct business, and to enhance the protection of corporate assets and customer data. He also described sources of information including web application firewalls (WAFs), server logs, application logs, the media, list servers, MITRE, honeypots and from the source of the threat itself. some of the impediments and do's and dont's in this pro-active approach.

Ryan Berg gave a lively and fast-paced description on the "Path to a Secure Application". He described what isn't working, and the need to mitigate the damage that attackers can do, rather than assuming you can keep them outside your network, He provided numerous examples of how security can be built into to all stages of the software development process, but made the point that organisations should make efforts to improve their existing application development processes, rather than creating new ones.

Dan Cornell described how Android and iPhone smartphone applications are coded, deployed and, how and when the source code can be reverse engineered. He presented an example Android application and some tools to demonstrate how embedded URLs, file paths and host names can be extracted to help determine its workings. He recommended that, like other applications, smartphone applications should undergo threat modelling, care should be taken on what information is stored and where, and to be careful when consuming any third-party services, and ensure that enterprise web services are approved and deployed securely.

After lunch which was held in the beautiful Dining Hall of Trinity College Dublin, Professor Fred Piper (Royal Holloway College) presented the second keynote on "The changing face of cryptography". Prof Piper described that people do not need to attack algorithms when they can attack the implementation or cryptographic system instead. He provided an engaging and personable talk about algorithms, implementation weaknesses, real-life cryptography and the related political and social issues, clearly demonstrating his wide and deep knowledge.

Tyler Shields' presentation "Application Security Scoreboard in the Sky" described the results from Veracode's State of Software Security, which I have discussed before but is worth remembering as a good source of information when building business cases for secure development processes. The first volume had examined the differences between open source, commercial and out-sourced software. The second volume is due to be released in the next fortnight.

Rory Alsop & Rory McCune (co-chairs of OWASP Scotland) "The 'Real' Application Security Pentest." described why penetration test companies and purchasers of their services need to understand the requirements clearly and to make best use of the budget. They described that penetration testing is increasingly being used but there are inconsistencies in how it is undertaken and customers don't always receive what they want. The speakers described common myths and what buyers should do.

Vinay Bansal and Martin Nystrom jointly presented Cisco's experiences of "How to Defend Fragile Web Applications". Cisco know they are constant attack on their perimeter, but they have to concentrate their resources on defending DMZ & internal systems and minimising the damage from compromises. Cisco use architectural assessments, developer training, secure coding techniques, verification practices and more recently using web application firewalls (WAFs) in a reverse proxy mode using Apache httpd, ModSecurity and ModProxy. They described the problems and benefits of using WAFs in front of Cisco's tens of thousands of applications, and how they are trialling using the WAFs for virtual patching, where the applications cannot be modified.

The final keynote "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking" was presented by Damian Gordon (School of Computing, Dublin Institute of Technology). Damian gave a light-hearted look at "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking". He has researched whether or not movies accurately portray hackers and the implications of that portrayal, based on filtering 200 potential movies down to 50 clearly relating to computer hackers and not just cyberpunk, sci-fi or where hacking is only a peripheral activity. The conclusion? Movies are doing quite well but are missing out on some hacking features such as denial of service, phishing, organisation identuty theft and e-harassment of employees. Maybe next year?

Congratulations for a very successful and informative day to all the organisers, helpers and speakers. A little late, but off to the social event...

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

• Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
  • check backup data can read and restored periodically
  • don't forget to securely delete data from old backups when they are no longer required
• Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
  • keep a record of the firewall configuration up-to-date
  • limit who can make changes to the firewall
• Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
  • remove or disable all unnecessary services and other software
  • delete old, unused and backup files from the host servers
• Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
  • restrict what each account can do as much as possible
  • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
• Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
  • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
  • make note of any renewal dates
• Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
  • verify who legally owns the source code, designs, database, photographs, etc.
  • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

• Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
  • impose security standards and obligations on suppliers and partner organisations
  • keep an eye open for changes to business processes that affect data
• Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
  • include configuration details and information about third-party services required
  • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
• Provide information to the web site's users how to help protect themselves and their data.
  • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
  • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
• Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
  • web server logs are a start, but customised logging is better
  • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

Privileged database accounts should generally not be used by web applications. It is a very common problem but verifying this often requires access to the servers or a copy of the web site's configuration information or database. However, sometimes you are given a big clue—like this order acknowledgement email I received on Tuesday.

Now that's interesting. This makes me wonder if sales orders placed manually, say by telesales staff, have staff names appearing here. But via the e-commerce site "Database Administrator" (DBA) is entered. This could indicate the account name being used by the online system to connect to the database.

It may not be a vulnerability, but it is un-necessary information to give to customers. Even if it is a vulnerability, it may not be exploitable. There may be no technical and business impacts. But let's imagine there is a problem.

There is almost certainly no need for this function, or the rest of the web site, to use what is probably a highly privileged database account. The account may have access to many more fields, tables, views, procedures, schemas, etc than are necessary for the business process. Whilst it would be impossible for most web sites to use different accounts (connection strings) for every use, it is often possible to have a small number of accounts, such as:

• unauthenticated public user
• registration/log-on/log out/password reset
• authenticated users
• content editors
• content publishers
• site administrators
• logging (e.g. usage trends, audit trail, security log)
• scheduled application tasks.

Any people who need direct access to the database (e.g. to extract other data, or alter the schema) should have their own personal account, and mustn't use the above or DBA accounts.

These should then only have access to the appropriate methods and database assets necessary for their role. This would mean for example, a dangerous function could not be used in the database. Or, that even if a public page could be exploited by SQL injection, it would be difficult to obtain access to the database schema or extract data limited to authenticated users (this does NOT prevent SQL injection, but may partly mitigate the effects). Similarly, if the account used by logging only has INSERT permissions to a subset of tables and no other application account has access, it's going to be much harder to modify or delete log entries accidentally or maliciously.

Therefore, build database roles into your web site's design, and enforce permissions appropriately through the code. When combined with server and database hardening, it will help protect the application and your business.

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.

The poor apostrophe gets such bad press. It's implicated in so many SQL Injection problems and now it has been banned by some local councils in the UK.

Yes Birmingham City Council and Wakefield Council have been so concerned about punctuation usage they have banned apostrophes in street names and thus on road signs, according to recent news reports such as in the Daily Mail and Yorkshire Evening Post.

I wasn't able to find confirmation on the councils' own web sites—I was also hoping perhaps the council leader or spokesperson might have had an apostrophe in their own family name. Actually no members from either council have apostrophes, or any other "unusual" characters, in their names. Birmingham's web site search kindly refused to tell me anything about the apostrophe:

This has got many people bothered by the dumbing down, especially those in the Apostrophe Protection Society.

I don't think we'll be able to get away with banning characters in the web application world to prevent issues like SQL injection. Yes there are many web apps that don't allow apostrophes in submitted data rather than tackling the root cause of the weakness. The use of database commands with bound parameters combined with appropriate validation, decoding, encoding and escaping are the answers.

PS It's not just apostrophes (or single quotation marks) you have to worry about.