Like the SSL Certificate Validation Issues mentioned before, otherwise benign Android apps can be vulnerable to attacks against SSL/TLS misuse.

Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith, Lars Baumgärtner, and Bernd Freisleben's paper Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security have developed a tool to help them assess man-in-the-middle (MITM) attacks. They used this to asses 13,500 popular free apps and discovered that over a thousand of them were susceptible to this type of attack.

Misuse cases covering trusting all certificates, allowing all hostnames, trusting many Certificate Authorities (CA) and mixed-mode/no SSL are discussed. The paper has many useful references, and pointers to some tools that can be used to assess the use of SSL/TLS in Android applications.

In October Securosis published a free paper concerning the security of "big data" systems.

Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments focuses on the security aspects relating to the specifics of "big data" that are different architecturally and operationally to other environments rather than the, also important, security of the applications themselves. Thus, consideration of how nodes and client applications are vetted before joining the cluster, how data at rest is protected from unwanted inspection, the privacy of network communications, and how nodes are managed are covered.

The paper discusses what "big data" means, and the particular architectural and operational security issues that arise. It then presents six recommendations.

SSL certificate validation is an essential aspect of creating trusted, secure links between client devices and servers. This is often undertaken between a web browser and secure web server using Secure Sockets Layer (SSL)/Transport Layer Security (TLS).

In this situation any certificate error warnings are visible to users to an extent, and result in changes to web browser chrome (such as colour changes) and in some cases warning messages. However, users are not generally aware of server-to-server SSL connections, and these too need to check the validity of the public key SSL certificate.

In the paper The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software by M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh and V. Shmatikov describe their research into application software and code libraries which set up and use SSL connections. The authors describe how many checks (host name, period of validity, intermediate & root certificate authorities and revocation) are not always being performed. It would appear to be a combination of unimplemented functionality or the alteration/selection of insecure code library options instead of using secure defaults. Some of the latter is attributed to confusing, missing or hard to find documentation.

While I think some of the headline quotations from the paper are somewhat sensationalist, and to an extent, unfair on some of the code libraries mentioned, the authors are correct in their recommendations for application developers and SSL library developers. The recommendations identified for application developers are:

• Use fuzzing and adversarial testing to check the response to abnormal certificates
• Check SSL library default configuration settings and explicitly set the necessary options
• Do not modify application code relating to certificate validation for the purposes of testing
• Do not disable certificate validation during testing with self-signed or untrusted certificates

These items should be reviewed in software development implementation, testing and deployment practices.

The next OWASP London will be at Royal Holloway (University of London) on Thursday 8th March starting at18:30 hrs.

Tobias Gondrom will be speaking about "Securing the SSL Channel Against Man-in-the-Middle Attacks: Future Technologies - HTTP Strict Transport Security and and Pinning of Certs", and Viet Pham about "Implementing Cryptography: Good Theory vs. Bad Practice".

There is a also central-London meeting planned for Thursday 29th March. Both meeting are free to attend.

Transport layer security (TLS), also referred to by its predecessor's name secure sockets layer (SSL), cannot be implemented easily "out the box" in a robust manner. A new guide was published last week.

SSL/TLS Deployment Best Practices, from Qualys SSL Labs, provides clear concise instructions to obtain a correctly configured site or web application that uses transport layer security. This may "sacrifice completeness", but in seven largish-print pages describes all the important issues to get right. It is not a guide for beginners though — it is aimed at systems administrators and programmers who already understand the basic concepts and terminology.

References are provided for those who want to learn more, or want to look at more advanced topics. It will be a very useful document to refer to in requirements documents and configuration standards.

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?

Chris Weber has posted a summary of how eight modern web browsers display valid, error-free standard SSL connections and those using extended validation (EV) SSL certificates.

The informational summary may be of use for anyone providing up-to-date guidance to their users about identifying the correct web site, or want to take the browser chrome into consideration in site designs.

It's good to see different groups working together to improve security. This week another browser manufacturer announced future support for an initiative relating to Transport Layer Security (TLS, the successor to SSL).

HTTP Strict Transport Security (HSTS) describes a method for a web site to tell client browsers that they should only interact with it over secure transport, i.e. TLS Whilst there have been browser plugins which support this draft specification, support for HSTS was announced for v4 of Google Chrome in January, and last week for v4 of Mozilla Firefox. Hopefully Microsoft Internet Explorer 9 and ,a href="http://www.opera.com/">Opera will also adopt this.

Why is it important? Some attacks mean that TLS is vulnerable if there are redirects from non-TLS (e.g. http://www.example.com) to TLS (https://www.example.com) content. And if part, or all, of your web site is only meant to be accessed over SSL, HSTS should be implemented now, ready for mainstream adoption.

Further details are provided on the W3C page at Strict Transport Security (STS) and the draft IETF specification is at HTTP Strict Transport Security (HSTS).

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?

Continuing on the theme of confusing users, Security Dialogs and Graphics discussed the multitude of inconsistent styles for security warnings on web sites, mobile applications and in email.

This is usability hell. Why should each device, browser and application choose how these messages are worded and displayed? I mentioned previously the contributing factor of tab colouring in IE8 and a recent post Tabnabbing: A New Type of Phishing Attack demonstrates how users can be tricked into providing sensitive information to the wrong web site. But it's not just inconsistent technical implementation that matters; the humans in the process matter too.

Last week I came across two web sites in my normal business usage that gave me invalid SSL/TLS secure certificate warnings, and these weren't little businesses that might not know any better—both are multinational enterprises—one a UK bank, and the other a UK mobile phone company.

1. In one case a registration process used a domain www.[subdomain].[company].co.uk whereas the certificate was for [subdomain].[company].co.uk
2. In the other, the company had recently been taken over and the site was using www.[oldcompanyname].com whereas the certificate was for www.[newcompanyname].co.uk

But what surprised me most was the response I received when reporting these problems to the respective site owners. Neither organisation had a clear process for sending details of possible security problems and therefore the responses seem to have been directed through customer support channels.

One provided the initial response:

and:

and even though I re-explained the problem, and that it hadn't stopped me from doing what I wanted:

and then:

and the rather indefinite:

and then back to asking me to supply screenshots, my username and details of my browser:

Mmm.. and still no idea about the issue:

My issue? Their issue I believe.

The other company suggested it was the date/time on my own computer which was the fault:

and some advice about security:

at which point I rang them up, and stumped them by quoting their own tracking number. No further call back from them yet.

I found this all rather depressing. How can we expect customers (end users) to take care with security if the understanding and processes are not in place within the organisation, especially with customer-facing staff? Organisations like Get Safe Online and Card Watch are trying their best to educate people, but the web site owners need to play along too. So here's a quick checklist, including a couple of new items:

1. Obtain your own domain like example.com or example.co.uk (not a sub-domain of someone other company e.g. example.uk.com)
2. Provide security training to web site architects and developers
3. Determine how SSL/TLS will be applied on the site
4. Buy a certificate and apply SSL usage appropriately through the site
5. Verify the proper usage of SSL and session management
6. Verify the correct SSL configuration
7. Include SSL/TLS certificate management in change control processes
8. Provide awareness training to customer support staff about what "secure web site" means and the types of enquiries customers may have
9. Give some basis security advice to customers and direct them to other resources for more information
10. Ensure there is a simple way for people to inform you of security concerns and possible incidents such as phishing, browser security warnings, compromised credentials, account mis-use, etc.

Please—I don't want to have to go through customer support again! At the time of publishing this post, the certificate problems still exist.