Even though you did manage to get that far. It doesn't seem that you can actually make it persist or anything like that on his site so it is probably about as useful of an XSS as typing directly into the console on your browser.
You should add some sort of About Us section because for this type of lessons I really need to know who is behind the site, what are his/her references & experience. Bad advice is often worse than no advice at all, and to be a trustful source of security info we need at least to have some basic info on authors. And these obviously fake "What People Are Saying" are not helping with the trust issue either.
The bit on unencrypted communication should really mention HSTS. If you're connected to a network controlled by an attacker, using TLS on its own doesn't help you. HSTS doesn't necessarily help you either, but it's a lot more likely to solve the problem in the given scenario.
Slick and a nice UI, but the security advice in this is just plain terrible.
Blacklist input validation as defense against XSS? Are you kidding me? And then over to session fixation, where I see the exact same ?jessionid=blah example that has been in any Web Security book for the last 10-15 years? Come on!
> Imagine if a user has their email account hacked - the first thing an attacker will do is try to compromise their other online accounts, and long-lived password reset links make this easy.
I don't see how the length of time the reset link is valid really has any bearing here. I'm assuming the implication is that an attack could search for old password reset emails but if they have access to the email account, why not just request another reset?
Well spotted - I kind of mangled that explanation. The risk being mitigated is if somebody gets a dump of your old emails. Short-lived reset tokens don't help if they have full access to you email account.
Give it a try, it's free! We don't cover mobile specifically, but if you are building APIs, much of the advise is useful. And thinks like password management are useful for every developer to know. :-)
I'm enjoying this a lot. The explanations are straightforward and the writing and animation style is entertaining. I'm liking the website parodies and the puns in the alt texts. I'm learning new things and the linked resources are good for going in-depth. I'd probably pay for advanced lessons in this style. I'll be recommending to friends!
@malcolmhere keep up the great work. I have always found the current resources to be lacking especially in terms of implementation examples. One suggestion would be to remove the Chase logo in your SQL injection examples. It is just begging for a cease and desist letter.
I like Troy Hunt's web security stuff - I'd gotten into it on Pluralsight, but then moved jobs and don't have access. I did find a free course (With SQL Injection, etc.) of his here: https://info.varonis.com/web-security-fundamentals
Regarding the customer references, I'm always highly suspicious of anonymous praise. Do you not have permission from the authors or companies to use their name?
Author here! I put this together because I was bit frustrated with the quality of teaching resources for my development team. (And I find the OWASP wiki a bit of a mess.)
Not sure about the business model yet, though it's peaked some interest here and on /r/programming, so I figure there's an appetite for good training material.
EDIT:
Joined with Github, went through the password handling section, then saw this:
http://i.imgur.com/H4h5FUY.png
No no no no NO! Do NOT use SHA256 for passwords.
https://paragonie.com/blog/2016/02/how-safely-store-password...
https://codahale.com/how-to-safely-store-a-password/
PBKDF2-SHA256 with 100k or more iterations? Okay, fine.
SHA256 the cryptographic hash function not designed for password storage? Bad advice.