OWASP - Who?

Jamie - Sep 19 '18 - - Dev Community

I recently wrote a short post about five recommended podcasts for all developers, regardless of their technology stack; you can read that at the following link:

In the comments for that post, my good friend Sung Kim had this to say:

Wow Jamie, thanks for the list and synopsis of each podcast 💃.

First of all, it's amazing that there is a podcast dedicated on Git.
And I totally wasn't aware of Shawn Wildermuth's podcast.

It's amazing how much time & effort you are putting in for your podcasts and helping others to become concerned with security with OWASP with your OwaspHeaders.Core library.

It seems like both you and Martin have a great interest in security.
He has a whole section of podcasts for InfoSec

I'd love to see if you can later post about what OWASP is and why we should be concerned about security more 😉

Based on that, I thought I'd throw together a post all about OWASP, what it is, and what their goal is.

OWASP

You've heard of NIST, right? How about the UK's National Cyber Security Centre? These are organisations whose goals are to outline best practises and advice for increasing the security of your applications.

However, most of the advice they give is usually vague enough to apply to most services, or about a specific service.

But what about all of us developers who want to increase the security of their apps? That's where OWASP comes in.

OWASP, or the Open Web Application Security Project, is a non-profit whose goal is best described in their own words:

OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas.

Source

But How Does That Help Me?

We all want to create the most secure apps possible, right? Of course we do, but hacking into your own applications (or those created by your organisation) can be a little of a grey area.

That's one of the reasons that OWASP was created: to collate all of the best security advice for all technology stacks.

I usually work in the .NET suite of technologies (as you can probably tell from some of my projects) and when it came time to submit one of my projects for a code review and pen test, I had no idea where to turn to (quickly) learn how to secure the app.

Luckily, OWASP have a series of cheat sheets to help developers get up to speed with securing their applications, regardless of their technology stack. Most of their advice is pretty self explanatory (avoid SQL injection attacks by either parameterising your SQL inputs, or by using an Object-Relation Manager like Entity Framework), but some things can't easily be implemented in code (such as IIS set up).

Implementing OWASPs Advice

Just like with Unit or Behavioural tests, it's much easier to design security into an app rather than implement it after the fact. That's not to say that it can't be done for a code base which already exists, but it will take a lot more effort and consideration to implement. This is because, by it's very nature, implementing security best practises will break your current code - especially if you've built your application in a rush and not thought about things correctly.

As such, it's much better to get a handle on their advice and implement it into the code base as early as possible. The same can be said about physical architecture - in that it is easier to make a building more secure before it has been built.

Exactly how you implement the OWASP advice is dependant on the frameworks, technologies, and languages that you use to build your application. I usually work with the .NETs (.NET Framework, .NET Core), so implementing the list of OWASP recommended HTTP headers looks a little like the following:

httpContext.Response.Headers.Add("X-XSS-Protection", "1; mode=block");
Enter fullscreen mode Exit fullscreen mode

In fact, the above block of code adds the X-XSS-Protection header with a value which tells the browser to stop rendering the page when it detects a possible Cross Site Scripting attack.

For HTTP headers, there are two ways to ensure that they are added to all responses generated by your site:

  • in code (like the above)
  • at the web server/reverse proxy level

I prefer to do it in code, that way your application is web server/reverse proxy agnostic. However, let's say that you wanted to implement the same header with nginx. It would look like this:

add_header X-XSS-Protection "1; mode=block";
Enter fullscreen mode Exit fullscreen mode

as a side note: if, like me, do a lot of development with ASP.NET Core, then you might want to check out my OwaspHeaders.Core project, or it's NuGet package

Conclusion

You should now have a better idea of who and what OWASP are, and how their work and advice can help to make your apps a little more secure.

It's out of the scope of this post to show you how to implement all of OWASPs advice and best practises, but hopefully you should now have enough information to get your past the "unknown unknowns" stage.

Let's make the Internet more secure place.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player