Resources Referenced

OWASP Website

Web Application Firewall (WAF) Course

Transcript

Hello and welcome to this lecture focusing more on application security within a serverless environment which extends on from the last couple of points that were made in the previous lecture. 

As I explained, FaaS solutions incur the same security threats and exposures for application security when compared to Infrastructure as a Service solutions. Many of these attack vectors are outlined in the OWASP, which is the Open Web Application Security Project top 10 list. This list represents 10 of the most critical web application security risks that exist. As a quick review, the top 10 list defined in 2017 is as follows: injection, broken authentication, sensitive data exposure, XML External Entities, broken access control, security misconfiguration, cross-site scripting, insecure deserialization, using components with known vulnerabilities, and insufficient logging and monitoring. More information on OWASP can be found using the link on screen. 

Despite not having a server to maintain, manage and monitor for security threats when using serverless infrastructure, this list of 10 vulnerabilities still apply to your web applications. FaaS solutions do not prevent application level threats, they are still very real and need to be addressed within your deployment. Expanded on this list, I just want to highlight where a couple of these points could occur within your serverless solution. I will also explain how many of these potential security threats and exposures can be significantly reduced by encompassing a number of other managed services offered by AWS. 

Injection. This attack vector covers different injection flaws such as SQL, NoSQL, LDAP queries and SMTP headers. These attacks happen when untrusted data is received by an interpreter as a part of a command or query. The attacking data is then executed carrying out different commands that have not been properly authorized. Unfortunately, these attacks often result in data corruption or even worse the loss of data. Injection attacks can even prevent you from accessing your data all together and depending on what this data is, it could have significant impact on your business and customers. 

By incorporating services such as Amazon API Gateway and Amazon Cognito it can provide you with a level of verification and authorization to access and use specific APIs. API Gateway allows you to manage and maintain a greater level of security with your APIs and when combined with Amazon Cognito or even IAM, you could implement controls to verify authorization to your APIs. AWS WAF, the web application firewall could also be used to help prevent your application layer being exposed to such injection attacks. More information on WAF can be found in our existing course found here. 

Broken Authentication. This looks at how attackers try and gain access to systems and applications through the use of millions of username and password attempts. Attackers will use a number of different methods such as automated brute force and dictionary attacks. Should an attacker gain access to a system, they could perform untold damage depending on the permissions of that identity. Through the use of harder authentication and specialized access control services used by Amazon Cognito which supports SAML 2.0 and OpenID Connect, you can enforce stricter and tougher access control methods. In addition to this, it's best practice to enforce strict password complexity policies using a minimum character length in addition to requiring multiple character types. Where possible, it's also recommended you implement multi-factor authentication, MFA, which Amazon Cognito also supports. 

Using components with known vulnerabilities. This focuses on how attackers use known vulnerabilities to penetrate and breach access into applications. This closely relates to a section I covered in lecture four, Common FaaS and IaaS Security Concerns, where I explained that developers use libraries and code from other third party sources to save time as a part of the application development process. However, these libraries and code are written by someone else therefore it's critical to ensure that you move any unused dependencies and components within your code. When sourcing your libraries, use official sources across a secure connection. So although your serverless applications are still prone to application specific attack vectors, there are a number of services out there to help you reduce the chances of these attacks occurring. Understand what security services are available to help you architect and implement a safer secure FaaS solution. As a part of your application security, you should perform code review in addition to using static analysis tools. These tools look at your code to detect flaws and bad code against common best practices to ensure there is nothing glaringly obviously wrong with your code. As a part of the code review, you need to make sure that the code is only doing what it is set out to achieve. Where there are external dependencies, these need to be verified and sanitized. 

Speaking of sanitization, this is something else that should be incorporated into your serverless applications and FaaS solutions. Sanitization essentially means removing any data from the user input that isn't required. By sanitizing or cleaning the inputs into your application, it helps to avoid conflicts of code and helps to prevent security issues that relate to the OWASP top 10 list. There are a number of sanitization tools available that are free and many of these can be found directly from the OWASP website. 

That now brings me to the end of this lecture. Coming up next, I will provide a summary overview of the main points covered in the previous lectures.