The next Open Web Application Security Project (OWASP) London meeting is this week.

The London chapter meeting is on Thursday 14 January 2010 in EC1. Everyone is welcome, but you need to register first (free).

There will be talks on Top Ten Deployment Mistakes That Render SSL Useless by Ivan Ristić and Using Selenium to Hold State for Web Application Penetration Testing by Yiannis Pavlosoglou, who recently joined the OWASP Global Industry Committee.

Unfortunately I am unable to attend the meeting but hope to read the presentations afterwards.

Many organisations like to do land grab with domain names by purchasing the same name with different generic top-level domains (e.g. .com, .net, .info), country code top-level domains (e.g. .uk, .es, .fr), and multiple second-level domains (e.g. .co.uk, .org.uk). Then of course there are mis-spellings, similar sounding words, brand names and trademarks.

Well all that leads to complexity, and it's not uncommon for many domains to be aliased to the same site in a way that any of them can be used to access the complete web site.

But it can get especially messy when SSL is enabled on some or all of the site too. Inevitably there end up being certificate warnings. Some organisations should know better. So when I was searching for providers of online and business privacy "seals",

I was very surprised to click on the link to an SSL page which was reported as using an invalid certificate.

Actually the certificate was fine, it just wasn't valid for the .ORG domain. Perhaps they had hoped the wildcard SSL certificate *.trust.com would somehow cater for *.truste.* - no.

Identity theft? Privacy? But apart from these configuration issues, isn't it just very confusing to have many different domains appearing in search engine results? How does this duplicate content affect their search engine ranking? Does it undermine trust in the brand? Should the SSL part of the site be indexed at all? Perhaps. Who makes these decisions? Is it the developers, the person who configured the site or does the business have a viewpoint?

I overheard a (loud) mobile telephone conversation this week in which a marketing manager* was apologising for a problem but they "did not know any of the technicalities". Mmmm, who is accountable? Make it your business to know.

[* Security and technology managers should also understand their organisation's business objectives.]

Phishing attacks are often targeted at organisations where login credentials can be used to gain financial reward, and these web sites almost always use SSL to allow users to authenticate the identity of the site and to protect data in transit from alteration or copying.

A recent paper Crying Wolf: An Empirical Study of SSL Warning Effectiveness from Carnegie Mellon University discussed the results of a survey of over 400 internet uses. The conclusion - users ignore warnings about invalid SSL certificates.

The subject of trust user experience (TUX) was discussed during the Workshop on Security and Human Behaviour (SHB 2009) at Cambridge University this summer, and summarised here. This included a discussion on how users, who are trained to be sensitive to warnings, become more susceptible to picture-in-picture attacks. These are where an image of a (fake) browser, perhaps with a graphical representation of a green extended validation address bar is displayed inside the user's real browser window, such as in the example mock-up below. This is most effective when the real browser is displayed at the full screen resolution.

Therefore I was interested to read about how web designers can use CSS to access operating system style settings (the "chrome" of Linux, Windows, Mac, etc) and use these to apply matching fonts and colours to web design elements. This means if users have a customised desktop colour scheme, the fake browser in the picture-in-picture attack doesn't need to be in standard desktop colours, but could pick up on the user's own settings, to confuse them further.

See also my comments about Colour Overload with IE8 Tab Grouping.

Do You Have SSL Configured Correctly? Let me start by saying that "correctly" means "best for you". There isn't a single correct answer, although there are certainly some "don'ts" that apply in every situation.

This information is not about whether to use SSL, and is mainly for your systems folk (or hosting company), but do read on and perhaps gain a better understanding.

Ivan Ristić recently announced the SSL Server Rating Guide (draft 10, 21 July 2009) and an associated online assessment tool called the Public SSL Server Database. These had reminded me to post my comments last Tuesday about the slightly related Colour Overload with IE8 Tab Grouping.

The SSL Labs' resources describe, and allow you to check, the SSL configuration of your own, or any other public site that has SSL enabled. The checks span the certificate and three categories of web server configuration settings. Previously, it needed more specialist tools that most people wouldn't have the time or inclination to use.

The rating guide contains much useful information, but will be too detailed for many people. However, do read the "Minimal Configuration Requirements" and pass these on to appropriate person responsible for the configuration and operation of your own web sites. Not every site needs an overall rating of 73 or 85 or whatever. You'll see in Table 6 of the guide, an idea of what might be suitable for a range of web site types.

After all, your competitors, and some customers, have probably already checked your site.

Do people understand tab grouping in Internet Explorer version 8 (IE8)? This was a new idea introduced to collect together and identify tabs originating from the same source.

Note this isn't grouping based on the web site (domain name)—it's grouping from which other tab you clicked. The group colour is selected randomly, so yesterday's blue might be today's yellow.

My concern with tab grouping is not the concept, but the use of colour. Not because of the accessibility difficulty that some people may have distinguishing between colours, which is partially addressed by Microsoft in a tab naming convention, but because the colours can lead to confusion about SSL certificates. Take this example with four tabs open, the first tab selected and a current Extended Validation (EV) SSL certificate in use:

1. Bank No X online banking login (domain A / SSL)
2. Bank No X information page (domain B / non-SSL) opened using a link on page 1
3. Bank No Y home page (domain C / non-SSL)
4. Bank No Y business banking login (domain D / SSL) opened using a link on page 2

What does green mean? How about if we have an invalid SSL certificate and the tab group is green:

Confusing? Yes. It can lead to this type of misunderstanding:

Helping people to identify and reject invalid SSL certificates is important—IE8 users are being put at a disadvantage by Microsoft. I'd like to see tab grouping turned off by default for now, and some other indicator of tab groups used instead of distracting colour-coding. Perhaps, since new tabs are always opened adjacent to their 'parent', even something as simple as this mock-up might suffice:

Is this easier to understand? What do you think?

Since I've been writing about SSL Certificates recently, I thought I'd share a screen capture I took a year or so ago of an expired certificate warning.

This time it wasn't the site I was on, but some embedded code from a third party:

Yes my computer's time was correct. So, even large organisations can get this wrong. Having a schedule of all certificates, domain names, software licences and other agreements for your website helpd keep track of time dependent renewals.

And, I wonder just why did AlertSite feel the need to have code from the Google Advertising on their login page?

I recently discussed organisation names on SSL certificates. The padlock has become an overused visual indicator to indicate use of SSL certificates or broader protection measures.

Padlock icons have never been the exclusive browser indicator of a site using a valid, trusted SSL (more correctly now called Transport Layer Security [TLS], SSL's successor) certificate, and the position in the browser has varied considerably.

Here are a couple of mis-uses of the padlock symbol—neither are related to SSL certificates. They simply add to confusion about what is a secure website.

How do we expect users to understand what "secure server", "security certificate" and "security" mean in the web world? Maybe we should ensure our designers understand first.

Perhaps encourage them to read trusted resources like Learn About Secure Web Pages from Get Safe Online.

Then we can avoid pages like this:

which links to a restricted access area, but not on a secure server!

Version 3 of the Open Web Application Security Project (OWASP) Testing Guide has been released after a 6-month period of addition, enhancement and review.

The OWASP Testing Guide is an ideal reference for both developers and testers—version 2 was fantastic, and this new version is even better. The testing framework now covers 66 controls and, like in the previous version, each control has a brief summary and is described in detail followed by black box (no additional knowledge) and grey/gray box (partial knowledge) testing methods and examples where appropriate.

The controls and testing methods are fully referenced to provide additional guidance and explanation.

The controls are grouped into ten categories, including new separate categories "Authorization" and "Configuration Management". I'm especially pleased to see the latter broken out on its own, since even a perfectly coded application can have vulnerabilities introduced during deployment and changes to the application.

The OWASP Testing Guide now also includes a "best practice" penetration testing framework and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues. More information is available on the Testing Project pages.