OWASP

How much really changes in only three short years in the world of application security? Ok, a few sites get owned and some nasty hackers come up with some new ways of making some poor developers lives a misery but that’s about the extent of it, right? Yeah, turns out it’s a lot more complex than that. The very first course I wrote for Pluralsight and the one that continues to be the most popular is the OWASP Top 10 Web Application Security Risks for ASP.NET. This course is now an integral part of the security training for many organisations who have recognised that it kinda makes sense that their .NET developers know a thing...

And now for my fourth Pluralsight instalment: more OWASP! Wait – hasn’t this been done already?! Yes and no. My first course from April last year was OWASP Top 10 Web Application Security Risks for ASP.NET and as the title suggests, it contains a heap of stuff on how OWASP applies to ASP.NET. In fact it contains so much stuff that it’s over 8 hours of in-depth training for developers on (almost) everything they need to know to protect their .NET web apps. By all accounts, the course has been extremely popular and has formed the basis for many an organisation’s default set of developer training resources. It’s also rated...

I’ve been a little bit busy the last few months and here’s why – my first Pluralsight course, the OWASP Top 10 Web Application Security Risks for ASP.NET. Actually, if I’m honest, it’s been a lot longer than that in the making as my writing about the OWASP Top 10 goes all the way back to right on three years ago now. It begin with the blog series followed by the free eBook then last year the instructor lead training for QA and now finally, a complete online video course via Pluralsight. For the uninitiated, Pluralsight is what they call “hardcore developer training” and it’s predominantly produced...

This entire series is now available as a Pluralsight course! Writing this series was an epic adventure in all senses of the word: Duration – 19 months to complete a blog series, for crying out loud! Content – approaching 50,000 words, not including all the discussion in comments. Effort – some of the posts, such as transport layer security, probably approached 100 hours of reading, trialling, experimenting and finally, writing and proofing. This is why there was a four month “hiatus” before that post! But most of all, it was an epic learning adventure for me. Writing the series forced me to know this content in depth, not just the depth that facilitates casual conversation and allows...

This content is now available in the Pluralsight course "OWASP Top 10 Web Application Security Risks for ASP.NET" In the final part of this series we’ll look at the risk of an unvalidated redirect or forward. As this is the last risk in the Top 10, it’s also the lowest risk. Whilst by no means innocuous, the OWASP Risk Rating Methodology has determined that it takes last place in the order. The practice of unvalidated redirects and forwards, also often referred to as an “open redirect”, appears fairly benign on the surface. However, it can readily be employed in conjunction with a combination of social engineering and other malicious activity such...

This content is now available in the Pluralsight course "OWASP Top 10 Web Application Security Risks for ASP.NET" When it comes to website security, the most ubiquitous indication that the site is “secure” is the presence of transport layer protection. The assurance provided by the site differs between browsers, but the message is always the same; you know who you’re talking to, you know your communication is encrypted over the network and you know it hasn’t been manipulated in transit: HTTPS, SSL and TLS (we’ll go into the differences between these shortly), are essential staples of website security. Without this assurance we have no confidence of who we’...

This content is now available in the Pluralsight course "OWASP Top 10 Web Application Security Risks for ASP.NET" As we begin to look at the final few entries in the Top 10, we’re getting into the less prevalent web application security risks, but in no way does that diminish the potential impact that can be had. In fact what makes this particular risk so dangerous is that not only can it be used to very, very easily exploit an application, it can be done so by someone with no application security competency – it’s simply about accessing a URL they shouldn’t be. On the positive side, this is also a fundamentally...

So my conference presentation on the tyranny of evil is now done and dusted at DDD Sydney. Given I’m writing this in advance with the intention of making the material available immediately afterwards, I’ll need to rely on others to comment on how it all went. The important bit is that the slides are now available here and all the code used in the examples is here.Note – so as to save myself from the tyranny of potential litigation, the evil dudes on each attack slide have been removed. Use your imagination :)...

This content is now available in the Pluralsight course "OWASP Top 10 Web Application Security Risks for ASP.NET" Cryptography is a fascinating component of computer systems. It’s one of those things which appears frequently (or at least should appear frequently), yet is often poorly understood and as a result, implemented badly.Take a couple of recent high profile examples in the form of Gawker and rootkit.com. In both of these cases, data was encrypted yet it was ultimately exposed with what in retrospect, appears to be great ease.The thing with both these cases is that their encryption implementations were done poorly. Yes, they could stand up and say “We encrypt our data&...

This content is now available in the Pluralsight course "OWASP Top 10 Web Application Security Risks for ASP.NET" If your app uses a web server, a framework, an app platform, a database, a network or contains any code, you’re at risk of security misconfiguration. So that would be all of us then.The truth is, software is complex business. It’s not so much that the practice of writing code is tricky (in fact I’d argue it’s never been easier), but that software applications have so many potential points of vulnerability. Much of this is abstracted away from the software developer either by virtue of it being the domain of...