No really, that’s the whole idea and it goes back to my post from a couple of days ago about my new Pluralsight course. You see what normally happens when you create a course is that you hand over all the code used in the videos and then if you’re a plus subscriber you get to download it and have a play. That’s just great, but the thing with my Hack Yourself First course is that it’s aimed at everyone – if you’re a PHP developer then this course is equally relevant to your ASP.NET brethren because it’s entirely focussed on common risks you can identify in the browser. The only problem is that if you want to actually run the code yourself then you need .NET. And IIS. And SQL Server. And you need to know how to make them all work!
As I described in that post to launch the course, I’ve actually wrapped everything up into a single site, thing is that it’s a single site absolutely chock full of lousy security practices. So how do we make this useful to people taking the course? I had a good chat with the Pluralsight guys and what we decided to do was just stand the site up so it’s public. You don’t need to be a plus subscriber in fact you don’t need to be a subscriber at all – when I say “public” I mean really public. It’s right here:
hackyourselffirst.troyhunt.com
I’m excited about this approach because it makes a very valuable component of the course accessible to everyone. For many readers there will be some very common risks you're aware of already either from my own writing or just because, well, some of them are pretty damn obvious. For others there will be a heap of new stuff in there and the reality of it is that a significant swathe of the Dark Matter Developers won’t be aware of the breadth and depth of risks staring them in the face. And that’s the whole point of the course.
There are 50 vulnerabilities
Yep, fifty. 50. Half a hundred really shoddy practices that you can go and find in the browser right now. Many of them are just hanging out there a couple of clicks away, others reveal themselves as you delve into risks a bit earlier in the pipeline. It’s like a little “choose your own adventure” story; depending on the path you take you’ll discover new things. Broken things.
Those 50 vulns are spread across the eight modules I described in the launch post so that means you’re going to see areas that are at risk of SQL injection, XSS, MitM attacks, clickjacking, CSRF, dodgy cookies (my technical description), sloppy password practices and much, much more. Sometimes you’ll find the same risk in multiple places and each individual instance goes towards that 50 count.
Find vulns – get free Pluralsight passes!
I’m writing this whilst at TechEd Australia and I managed to spend a bit of time with the Pluralsight guys who’ve very kindly given me a bunch of free passes that’ll get you a whole heap more viewing time than the free trial available online. If you can find vulns on the site above and leave it in the comments below, you get a free pass. Of course I’d love you to use those passes to watch the Hack Yourself First course but there’s around 700 other courses of awesome content that these passes will also get you into.
A few guidelines:
- You can name as many vulns as you like – but you only get one pass (plus of course the adulation of your peers for your lee7 haX0r skills)
- You need to explain where the risk is (page, field, etc.) and how it could be exploited by an attacker
- Once someone leaves a vuln in the comments, that’s it – someone else can’t call it out (unless it’s in a different part of the app)
- I’ll ping successful candidates via the comments below and get them to email me for a free pass
- Be nice in your pwning of the app - I'll be regularly (and automatically) returning the app to a default state, please be conscious this is a public site designed to help people understand web app security so don't do anything too nasty (please)!
That’s it – let the hacking of myself begin!
Spoiler warning: I’ve got an update below with a list of discovered risks, if you actually want to search for vulns yourself, don’t read beyond here!
Update – winners and how to get their prize
Here’s the folks who bravely ventured into the bowels of the app and found vuln upon vuln. They’re listed by name and were the first to discover each particular risk. I’ll continue to update this list as more are found but for the folks below, email me at troyhunt@hotmail.com and I’ll get back to you with your pass (also tell me your name below if it’s not immediately obvious).
- cyberprune – login and registration over HTTP even though they’re handling sensitive data (actually, the login posts to HTTPS but of course the page could already have been compromised pre-post)
- Ricardo Rodrigues – unhandled internal exceptions are exposed to the end user (these can then be used to fund subsequent vulns)
- Scott – password field is limited to 10 chars and restricts the use of “special” characters, credentials are sent via email on signup, there’s no sanitisation of user input on the voting firm, the password change field pre-populates the fields with the current password plus there’s an account enumeration risk in the password reset feature and it also has a denial of service risk (you can immediately lock someone out of their account by resetting their password), the “remember me” feature stores the base64 encoded password in a cookie plus the auth cookie isn’t marked with the HttpOnly flag (it subsequently be accessed via client script in an XSS attack)
- Dan Puzey – password resets emails a new password, the vote API doesn’t validate the user ID (you can vote on behalf of another user) plus it allows multiple votes from the same user (the web page tries to prohibit this by hiding the vote button)
- Magnus Kragelund – response headers are disclosing the internal framework (easily allows remote detection of profiling of the underlying technology) including server, X-Powered-By, X-AspNet-Version and X-AspNetMvc-Version plus the ELMAH log is exposed
- Stuart Bronk – the auth cookie is not flagged as secure so will be passed over insecure connections
- FunkyMrMagic – the robots.txt file is disclosing the presence of the /secret/admin path
- Dan – the HTML comment in the /secret/admin path links to a database backup
- ianoxley – XSS protection in Internet Explorer has been disabled by the presence of the X-XSS-Protection header
- Atarii – the search page has a reflected XSS vulnerability in the JavaScript context plus the “remember me” feature permanently remembers the user (you can’t login as someone else any more)
- chaoaretasty – there’s a SQL injection risk in the comments box of the voting feature, the SQL account used by the web app has excessive rights (shouldn’t be able to do things like delete cars and makes) plus there’s a persistent XSS risk in the vote comments
- 7sharp9 – the leader board page has a SQL injection risk via the orderBy parameter in the URL
- JoKerTheFirst – the auth cookie can still be used even after the user logs out
- Michael Ridland – the “change password” page doesn’t have any XSRF protection
- Thomas Smets – there’s a SQL injection risk in the orderBy parameter in the makes page (need to use a non-existent make ID to discover it)
- JasonWhitehurst – autocomplete is enabled on the password field allowing the browser to pre-populate it
- SeNetInt – no minimum password criteria (password can be a single character) plus no X-Frame-Options header to prevent clickjacking
- DGibbs – you don’t need to confirm your password before changing it (easy persistent account hijacking)
- Jonathon Bolster – there’s a mass assignment risk on the “edit profile” page that allows you to elevate privileges by sending an IsAdmin value plus there is no access control on the /secret/users page
- Jake Maclean – registration form only has client-side validation and missing it altogether on the server plus there’s missing CSRF protection on the log out link
- Simon moans – no brute force protection on the account login plus no CSRF protection on the vote API
- brad russell – lack of a CAPTCHA allows someone to game the voting through automated account creation plus passwords are not stored as cryptographically secure hashes
- Tony McGee – far reaching expiration on the auth cookie (one year)
- Dan 2 – hard-coded HTTP scheme on the manufacturer images on the front page of the site cause mixed-mode warnings when the page is loaded over HTTPS
- Ravi Patel – there's no anti-forgery token on the edit profile page to protect against an XSRF attack
- Matt Barnes – there's a mass assignment risk on the email attribute when changing the user profile (first and last names)
- Dan 3 – no anti-caching response headers or meta tags on pages that store sensitive data, TRACE and OPTIONS verbs are enabled