Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons in website security anti-patterns by Tesco

troyhunt.com

Post reply on HN
Print view View original

101–110 of 120 posts

Re: Lessons in website security anti-patterns by Tesco

#101

Post by troyhunt »

papsosouid wrote: post #92

I'm interested to know what everyone's take on the "use https always for everything" stance is. Does any site actually follow that rule? Even big names like facebook allow you to use http don't they? And what about the "don't put http elements in an https page"? Why not? What benefit is sending the images over https (thus making the page load slower) if they are on a seperate subdomain, so there's no cookies being se…

GMail is a good example of HTTPS everywhere.

When you embed HTTP elements you can no longer trust their authenticity. If, for example, you load JS into your banking app over HTTP it would be possible for a man in the middle attack to substitute it with a script which could re-write the page or siphon off sensitive data.

HTTPS says "We can verify the site you're connecting to and all data transited between it and yourself is encrypted". Embedded HTTP content invalidates that premise.

Re: Lessons in website security anti-patterns by Tesco

#102

Post by troyhunt »

jiggy2011 wrote: post #17

Whilst I agree with the big one about plain text passwords some of the niggles here seem a little odd. Tesco are not advising that everyone goes back to IE 3, they are simply stating this as a lowest common denominator since I'm assuming that was the first browser to support whatever version of TLS they were using etc. Also, is running an old version of ASP.NET and IIS really a problem? Does he advocate going through…

Why rewrite? When there's a new major feature release, take the opportunity to change the target framework. Most servers also have a refresh cycle so update that at the time and roll it into the testing procedure. I'm not saying do this immediately after every new IIS / .NET release, but going 9 years without change is risky.

Re: Lessons in website security anti-patterns by Tesco

#103

Post by troyhunt »

jiggy2011 wrote: post #74
alsothings wrote: post #67

Earlier quoted context omitted.

The post advocates simply staying reasonably up to date, then says that IIS 6 is unreasonably old. relevant bit: This is not necessarily a high-intensity exercise, once every few years you simply make sure you haven’t fallen too far behind the eight ball. Certainly you don’t let key software components get 9 years old and nearly 5 versions out of date. This is quite a bit less intensive then you describe and I think…

IIS 6 is part of Windows 2003 Server, therefor it will be on "Extended Support" until 14/07/2015 http://support.microsoft.com/lifecycle/search/default.aspx?a... This means that if there is some security vulnerability discovered with it then Microsoft will provide a patch, therefor from a security point of view it isn't "out of date". The number of years and versions is fairly irrelevant, there will be plenty of very…

The relevance is that none of the additional protections added to the technologies are available. We're in a very different threat landscape today than what we were in 9 years ago and the technologies provide advances to better protect ourselves. If you're using them!

Re: Lessons in website security anti-patterns by Tesco

#104

Post by papsosouid »

troyhunt wrote: post #100
papsosouid wrote: post #92

I'm interested to know what everyone's take on the "use https always for everything" stance is. Does any site actually follow that rule? Even big names like facebook allow you to use http don't they? And what about the "don't put http elements in an https page"? Why not? What benefit is sending the images over https (thus making the page load slower) if they are on a seperate subdomain, so there's no cookies being se…

GMail is a good example of HTTPS everywhere. When you embed HTTP elements you can no longer trust their authenticity. If, for example, you load JS into your banking app over HTTP it would be possible for a man in the middle attack to substitute it with a script which could re-write the page or siphon off sensitive data. HTTPS says "We can verify the site you're connecting to and all data transited between it and your…

I know what HTTPS is, I am asking why it matters in this specific context. We're not talking about javascript, we're talking about images. Nobody cares if the images are being sent securely, do they? From a random sampling, it sure doesn't look like very many https sites serve up https images. My current plan for our upcoming site launch is also to serve up images over http, not https. Is there an actual reason not to do this, or is it just "its on my list so do it"?

Any idea why so many sites allow http after logging in? I realize a facebook account isn't a high value target, but it seems crazy that a site that size works over http. I imagine they must have some reason to support http (not implying it has to be a good reason).

Re: Lessons in website security anti-patterns by Tesco

#105

Post by praxulus »

papsosouid wrote: post #97
praxulus wrote: post #96

Earlier quoted context omitted.

>(thus making the page load slower) The difference is tiny. If your images are on the same domain as the html, you'll have no extra overhead from the ssl handshake (thanks to http keepalive), and the symmetric encryption used in an existing ssl connection will have a negligible impact on performance. I can think of two reasons you want https, even for just images: 1) Even though modifying an image in flight will prob…

HTTP keepalives just means you only need to negotiate two extra SSL connections instead of n (n being the number of images in the page). The overhead of that is certainly noticeable. If there's no actual benefit, then it shouldn't be in his list of "stuff you have to do (and nobody actually does)".

But for most websites, it is something you have to do. Ruining the layout of your page is about as bad as any other DoS attack for most of the afflicted users.

Re: Lessons in website security anti-patterns by Tesco

#106

Post by dspillett »

SideburnsOfDoom wrote: post #60
dspillett wrote: post #57

Earlier quoted context omitted.

> Tesco are fundamentally in the business of selling meat and potatoes to everyone in the UK That is changing - it is getting to the point where their business angle is more "renting shelf space to brands" as much as selling what we want to buy (that is a general industry thing, not a Tesco specific comment). Even ignoring that cynicism, their business is far more than food and I suspect the food sales are dwarfed wh…

Good answer. The problem is the mismatch between the business that they think they're in and the business that they are becoming. However I am not finding anything about "you may not store passwords in plain text or using reversible encryption" in that PCIDSS wikipedia link. If it is part of the standard (as it should be) then it deserves to be in the wikipedia article.

I may be confusing it with other standards that we had to ensure we were compliant with on a project a couple of years ago.

Even if it isn't in PCIDSS, not storing passwords securely is certainly not industry practice for any company that operates as a bank in any of its parts.

Re: Lessons in website security anti-patterns by Tesco

#107

Post by tripzilch »

Wilya wrote: post #49
chrisacky wrote: post #14

Hey Troy, Thought you might be somewhat interested in this one. Remeber the cool guys over at http://www.realestate.com.au/ Just to refresh your memory.. https://twitter.com/#!/realestate_au/status/2207319148043059... Anyway, "we are aware of this issue and are working on it". Click http://www.realestate.com.au/ then "Register". Then stand in utter amazement at their solution. ----------------------------------------…

Well, let's look at the good side of it. At least it limits the risks of password reuse.

You don't know that for sure. For all we know, they email "DTCNE" to everybody.

Re: Lessons in website security anti-patterns by Tesco

#108

Post by tripzilch »

ZoFreX wrote: post #28
Smerity wrote: post #15

Earlier quoted context omitted.

Google Chrome and the Google search engine warn you if a website contains malware or is suspected of phishing. Poor security is just as dangerous as these, the only thing missing is the malicious intent. Unfortunately, Google would likely open themselves to lawsuits if they warned users away from or penalised websites due to poor security.

It's a sad reflection of the state of things that we worry Google would be subject to lawsuits for trying to guide users away from almost-certain disaster, yet no one is naive enough to believe that a lawsuit could result from storing my password for an online shopping site in plaintext.

> that we worry Google would be subject to lawsuits for trying to guide users

um no, it's Google that would worry. Myself, I don't care if they got a lawsuit. I'd applaud G for trying (and who knows the publicity that such a lawsuit would (hopefully) generate might do some additional good).

I can imagine Google not pursuing such a strategy without a really good reason, though.

Re: Lessons in website security anti-patterns by Tesco

#109

Post by tripzilch »

peterwwillis wrote: post #63

What's really weird to me is how some people can foster an actual anti-security mindset, where they explicitly try to argue against proper security practices. I don't know where it comes from, but i've seen it often. You report that the way a particular type of SSL cert is implemented leaves a MITM attack, and they come back with a dissertation on why MITM is not a concern of ours. (Oh? Then why the fuck are we encry…

Oh yes. Exactly this. It's infuriating!

Re: Lessons in website security anti-patterns by Tesco

#110

Post by blair_strang »

papsosouid wrote: post #92

I'm interested to know what everyone's take on the "use https always for everything" stance is. Does any site actually follow that rule? Even big names like facebook allow you to use http don't they? And what about the "don't put http elements in an https page"? Why not? What benefit is sending the images over https (thus making the page load slower) if they are on a seperate subdomain, so there's no cookies being se…

Re: images over HTTPS; most of the attacks involve an active MITM, so it's a question of how seriously you take that threat. Usually, most people ignore this scenario until it gets automated via "coffee shop network attack tools" like firesheep or sslstrip.

As a practical matter, if you embed http images in your HTTPs page I believe you will get mixed content warnings in some browsers. See e.g: http://stackoverflow.com/questions/3278341/help-with-ssl-vul...

Another strike against non HTTPs images is that if you don't have the 'secure' flag set on your cookies, these may get sent with requests, compromising your users' sessions. I guess you could consider not setting this cookie flag as a separate issue. Note that this is a passive threat, exploitable via sniffing.

Thirdly, an active MITM can return any MIME type in response to your link; you now have to be 100% sure that no browsers will try to process a malicious response of any type when it gets one instead of an image. Probably OK, but are you absolutely 100% sure? What about indefinitely, as browsers implement new features?

Fourthly, think about all the creative ways a malicious user could embed instructions or change the appearance of your site by substituting arbitrary image content. Also note that SVGs can run javascript. One could change an image to be an ad or promotion, for example, to convince the user to carry out an action.

I wouldn't neccesarily follow facebook's lead on security practices.

Modern thinking is that if you care about SSL at all, you should force SSL for everything. For example if your "secure banking site" has an HTTP landing page, an active MITM will just sslstrip the customers and get them to enter their password in the wrong box.

This is why we have HSTS (HTTP Strict Transport Security) header, and why sites that care deeply about security (gmail, paypal, lastpass, etc) use it. (See http://www.chromium.org/sts).

Post reply on HN