Not at all, I continued writing a lot on Twitter and still love the product. I don’t like the way they’re handling this situation though, more in this vid from a few days ago: https://www.troyhunt.com/weekly-update-289/
Looking forward to it! The raising of awareness about security is alone pretty awe-inspiring, so the fact that I'm equally piqued by such technical details as the site's backend is really saying something about the impressiveness of the execution
Oh, pish posh. You could've just as easily said, "The viable alternative is to make password resets secure" and said the same thing. It's doublespeak. It's basically an easy way to say, "There are a lot of different things you can do but I don't feel like taking the time to list each of the options right now."
Hey, thanks for pointing that out, that's the second time I've heard that recently. I think Ghoetery is getting a little over-excited and hiding the parent element containing Disqus which also contains the body of the post. I'm going to take a look at how to rejig the markup so that this doesn't happen in future.
It's harder to detect the framework when ASP.NET MVC is used. No view state in the source code, no .aspx extensions and the server response headers identifying IIS and ASP.NET can be removed. There's always HTTP server fingerprinting but you're moving on past the low-hanging fruit now.
Well, after removing all the default headers, there's the CSRF token, certain paths that will bypass a regular 404 detection, and so on... There are ways.
What it shows is that the server is not configured to return a custom error page when an exception occurs. Beyond the obvious usability issue, this may be used by an attacker to identify sites that leak internal information. It's not a vulnerability per se, but it's a gateway to helping find them.
this may be used by an attacker to identify sites that leak internal information
But what does that even mean? We've already discussed below that thinking you can hide an ASP.Net MVC site is wishful thinking unless you totally strip out every identifying part of the framework client-side, there are so many ways I can think of, including the ones below, like the js libraries, the CSRF style, the CSS style the validation uses, the wrapping of JSON responses in a object named d, etc. etc.
I even have vague recollections of coming across odd behaviours in IIS when it sends the allow-continue header in certain scenarios that no other webserver does. Though I can't remember the details now so might be wrong there.
I think you should stop classifying this as a vulnerability and just call it what it actually is, a misconfiguration.
Because rightly or wrongly, there's evidence that it increases consumer confidence and results in more purchases / subscribers / customer love. It's an empty promise, but people buy it anyway.
If there was something worth protecting on a personal blog site, it might be a different story.
1 is very on-topic - there's no way that data should be sent in the clear.
HSTS is good, but unfortunately only partially supported. Agree on the secure cookie, but of course you need to drop the dependency on accessing it over HTTP before you do that.
> This blog isn’t terribly controversial. But if only the "controversial" stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.
HTTPS is not really that effective for privacy. An attacker can still see what site you visited (Well, the IP, but it would be fairly trivial to get the domain as well) and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
>> ...and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
Could you elaborate on this? I would have assumed that with the request URI being encrypted that this would be extremely difficult (load times/payload size maybe?) for all but the simplest of sites.
Yeah, essentially it comes down to timings/measuring payload lengths. Even for complex websites it may still be possible to attempt to infer what you're viewing. For example, if you are interested, take a look at this research paper which explains how to capture what a user is typing in an auto complete (i.e sends a request every time you type a character) box even over an encrypted connection:
Which could leak information about what you're looking at or looking for. The site is not mentioned specifically in the paper but Amazon uses a autocomplete for it's search which exhibits similar behaviour to what is discussed in the paper. So even on a site like Amazon if you visited it over a secure connection an attacker could most likely find out what you are searching for or looking at on Amazon.
