Understanding the security risks that threatens a Node.js web application is crucial to its success. This course aims at providing functional mitigations to apply to your application against those vulnerabilities.
Since its creation in 2009, Node.js has seen exponential growth in its community of users and the applications they are building. With the drive towards a connected society, the need for web applications has never been greater. Yet, despite the push to connect the world as we know it, businesses of all sizes fall victim to data breaches everyday. The security risks that a Node.js based web application face are no different than any other web application. This course, Securing Your Node.js Web App, will empower you with both the understanding of various web based security risks and how to apply the proper mitigation in your Node.js web application. First, you'll learn about implementing proper authentication and session management. Next, you'll explore how to protect your MongoDB database from injection attacks and how to handle untrusted data - a key player in many of the risks you'll look at. Finally, you'll wrap up by learning how to control application and user authorization to key access areas and the benefits of serving our application over HTTPS. By the end of this course, you'll be on your way to building a significantly more secure Node.js web application.
Max McCarty is the founder and owner of the software security site LockMeDown.com and hosts the popular Lock Me Down Podcast. As a senior software engineer, Max’s focus is on software security and empowering the everyday developer with the information to write more secure software.
Course Overview Hi everyone. My name is Max McCarty, and welcome to my course, Securing Your Node. js Application. I'm a software engineer in Pittsburgh, Pennsylvania, and host of the Lock Me Down Podcast. Since its creation in 2009, Node. js has seen exponential growth in its community of users and the applications they are building. In the drive towards a connected society, the need for web applications has never been greater. Even companies such as Wall Street Journal, eBay, GoDaddy, Microsoft, and Ancestry. com have embraced Node for various needs. Yet despite the push to connect the world as we know it, businesses of all sizes fall victim to data breaches every day. With over 5000 data breaches reported since 2005, we clearly still have a problem, which brings us to why we are here. Web application security isn't going anywhere, and it isn't getting any easier to securely host user personal and financial information. In this course, not only will we implement the code to mitigate major security threats our web application will face, but also introduce you to a number of security testing tools along the way. We'll be tackling areas such as implementing proper authentication and session management, protecting our MongoDB database from injection attacks, and how to handle untrusted data, a key player in many of the risks we'll be looking at. Also, how to control application user authorization to key access areas, and the benefits of serving our application over HTTPS. By the end of this course, you'll be on your way to building a significantly more secure Node. js web application, because someone or some company's application will be the next victim of a data breach. The question is, will it be yours? I really enjoyed building this course, and I hope you'll enjoy watching it.
Introduction to Hackers Hall Hi, this is Max McCarty, and I wanted to take the opportunity to introduce you to the application we're going to be using extensively over this entire course. Hacker's Hall is a site dedicated to an interactive timeline of company data breaches and infamous hackers of the digital age. It's a site that I am currently running locally, and you will be able to as well with the demos provided with each module. The timeline provides a number of ways that we can interact with the events and hackers that have plagued history over the years. Navigating the timeline, we can view the details on items or related items. We can even filter the timeline by date, or through the search feature. Its other feature is the ability to allow authenticated users to cast their vote for most catastrophic data breach or infamous hacker, and view the results of those that have voted. We can also perform some of the standard authentication actions such as registering as a new user and logging in. And later in this course, we'll see some additional features come to life with user profile updates and administration features such as viewing the site users and deletion of a user. But the biggest feature the site provides is what isn't seen, and that is the extensive security holes and weaknesses that abound, and it's through these security deficiencies that we will use to exploit, test, and mitigate with the tools and techniques in this course.
Proper User Authentication Hi, this is Max, and in this module, we're going to look at one of the most popular web application features, which is authentication. It's almost impossible to go to any web application and not find some feature that requires authentication. Even Johnny Apple Cider Recipes requires you to login just to rate their recipes. But despite our technological advances and the monolithic library of different frameworks and strategies for building web applications, there is still a huge knowledge gap in understanding how to implement proper and secure authentication measures. We witness this knowledge gap every year when we see data breaches that show companies and developers are still using broken authentication measures, whether it's storing passwords in plain text or using insecure hashing algorithms. There is even further evidence of this fact that OWASP top ten list of web application security risks has broken authentication at the number 2 spot. We're going to implement a number of security measures that layer on top of each other, a security in depth approach for implementing a proper authentication system, starting with proper password storage, and also the missing ingredient, which is password strength requirements, and finally, brute-force safeguards. So let's get started.
Handling Untrusted Data Throughout this course, we have come across the terms untrusted data, but what does it actually mean? Is it only input that users submit on a form from your web application? And at what point does data actually become untrusted, and how do we identify it? Once you've identified it, how should you handle it? We'll answer all of these questions in this module, which has been set aside as a specific module to look at what actually constitute as untrusted data. Most developers have a reasonable idea of what is untrusted data, but don't always know how to identify it, besides the most blatant forms of it. Specifically, we'll look at Fuzzing input with OWASP Zed Attack Proxy, and rules that we can apply to identify untrusted data. You've identified untrusted data, but when and where is the most logical place to handle it. We'll also look at the difference between two common approaches when it comes to handling untrusted data, whitelist versus blacklist. Also, we'll look at a few different methods to use for processing the untrusted data we have identified, to either stop it from moving forward or defang any malicious element of the data. Finally, why sanitizing may not be such a sanitary solution. So let's get started.
Defending Against Cross-site Scripting (XSS) Welcome back. This is Max, and earlier in this course we took a heavy look at the concept of untrusted data, rules to help evaluate whether data is untrusted, and steps we can take to protect our application. In this module, we are going to look at an application security risk listed as the number 3 most serious risk by OWASP in their top ten list of application security risks, a threat to web applications whose foundation is based on the impact of untrusted data. Cross-site scripting is a risk that has threatened web applications for a long time, mainly because it is one of the more complicated and complex risks to mitigate. Furthermore, depending on your application's client-side architecture and the prevalence of DOM manipulation, it can be challenging to try and mitigate after the vulnerability already exists. If you watched the module on untrusted data, there will be some familiar concepts and mitigation approaches, but we'll specifically be looking at what a native cross-site scripting vulnerability in our application looks like, and how we can leverage tools such as Netsparker to help discover them, and also the anatomy of cross-site scripting attacks. We'll also look at three different types of cross-site scripting attacks, and how we can use a number of application configurations to help mitigate the threat of cross-site scripting attacks. And finally, a look at a number of different approaches we can use to handle untrusted data when it comes to cross-site scripting vulnerabilities.
Securing Your Connection Hi, this is Max, and in this module we'll be looking at how to keep your secrets secret. Encrypted communications is one way that a number of web-related risks can be mitigated. Transport Layer Security is just the answer to implementing a secure and encrypted communication between clients and your server. Specifically, we'll be looking at what is better known as acronym soup, of TLS, SSL, and HTTPS, acronyms that cause much confusion. Also, the benefits of Transport Layer Security, and how we can implement and establish a secure server in our application. We'll also look at a common misnomer about TLS configuration and login forms. In addition, we'll look at some supportive security measures with the use of a couple HTTP headers, such as HTTP Strict Transport Security and Content Security Policies. So let's get started.