Introduction to Application Security PDF

Introduction to Application Security By Christophe Limpalair May 2020 Version 1.1 This ebook is a collection of lessons from our course, Introduction to Application Security. If you’ve already gone through the course, you won’t find new material here. However, it can be a helpful resource to reference from time to time. Some people may even prefer the format of an ebook over a series of lessons online, or of written versus video lessons. In any case, we hope you enjoy it! 1 © 2020 - Cybr Table of Contents 1. Getting Started a. About the Ebook and Author b. About AppSec as a Job c. Exploring the NICE Framework and OWASP 2. Critical Concepts and Resources for Application Security a. Establishing a baseline: ASVS b. Establishing a baseline: SAMM c. A practical approach to application security d. Application security risks and threat modeling e. Cheat Sheets 3. Web Application Security a. The state of web application security b. Common vulnerabilities and attacks c. DoS attacks 4. Mobile Application Security a. The state of mobile application security b. Building a baseline for mobile AppSec: MASVS c. Common vulnerabilities and attacks 5. Cloud Application Security a. The state of cloud security b. IAM: access control and permissions c. Building secure APIs 6. Application Security Testing a. Important concepts of application security testing b. Web pentesting checklist and environment setup - part 1 c. Brute force attacks - parts 2 d. SQL injection attacks - part 3 e. XSS attacks - part 4 f. Components with known vulnerabilities 7. Wrapping Up a. Key takeaways b. How to stay up-to-date with AppSec c. What now? 2 © 2020 - Cybr Preface We live in scary times. I’m not just saying that because I’m in quarantine due to COVID-19, but also because cyberattacks are on the rise. Yet, most applications and organizations are grossly under-prepared. It’s usually not even from a lack of care or interest on the part of the development teams. I’ve worked with a lot of devs, and they all wanted to build great products. Instead, it’s usually the result of two things: 1. Lack of business focus, which results in a lack of resources and time to focus on security 2. Lack of skills, so that even what little time and resources are available to security are not effectively allocated While we can’t directly impact #1 in this ebook, we can start to impact #2. I’m willing to bet that if we can impact #2 even just a little bit, we’ll start to see a change in #1, even if it’s a slow change. So you can think of this as your first step towards being an agent of change for helping make the world a safer place. We will take a practical approach to application security so that you can walk away from what you’ve learned and apply it to your applications and to your organization. With that said, this is an introductory ebook, so we’re going to have to build a strong foundation. So while you’re probably most interested in pentesting, we have to first take a step back and learn fundamental concepts. Then, as we move on, we’ll come to find out that pentesting is actually a tiny fraction of what matters in AppSec. So, go get yourself a fresh batch of coffee and put your learning cap on! About the Ebook and Author My name is Christophe Limpalair, and before we dive into the interesting parts of Application Security, I’d like to spend a few minutes talking about the ebook and who I am so that you have a clear picture of who this ebook is for and what you will walk away with at the end. Let’s start with a little bit about me: who am I? 3 © 2020 - Cybr Who am I? As I mentioned, my name is Christophe, and I was originally born in France but then moved to the U.S. As a result of the move, I did not have a whole lot of friends, and so I turned to computers and spent more time tinkering with them than I care to admit, and so began my long journey of learning how to program. I also ventured in other areas, but it became very clear early on that my interests lied in technology. Fast-forward to a few years ago and I jumped feet-first into the world of cloud services, especially Amazon Web Services, where I taught courses that reached thousands of people around the world, including certification-prep courses for associate and professional levels. Example of students I’ve taught Today, I work with our awesome team at Cybr to build the best cybersecurity training and community that we can with our mission of helping make the world more secure. 4 © 2020 - Cybr I had to learn application security the hard way. After having spent time learning PHP with frameworks, I decided to explore plain PHP without the help of libraries and frameworks to understand how those libraries and frameworks were working behind the scenes. So I built a simple scheduling application to schedule and show rental applications. It worked fine, but the mistake I made was that I uploaded the application to the internet. You can probably guess where I’m going with this. Within a couple of days, my web app and database were compromised. Nothing serious came of it thankfully, but it taught me valuable chapters that I never forgot. One of those chapters was to never use plain PHP again if I could avoid it. For one, it’s extremely inefficient since you are re-inventing the wheel, and second it’s likely to be more insecure. Popular open-source frameworks and libraries have hundreds if not thousands of people looking at them, making improvements, testing for security issues, and so on. That’s not to say that they don’t have issues of their own, which we’ll explore further in this material (in a chapter called “Components with known vulnerabilities”), but you get the idea. So I embarked on a journey to figure out why and how my PHP app was compromised so quickly and easily, and now here I am today sharing what I’ve learned over the years. This is going to be highly conceptual since it is an introductory scope. In the future, we will build more practical AppSec training material so that you can get your hands dirty learning with real-world examples. Pre-Requisites With that, we also assume a few things and consider the following to be pre-requisites: We assume that you have at least a couple of years of programming experience. The language doesn’t matter, at least in regards to this material, but if you don’t have any programming experience this is probably not where you want to start. We also assume that you are familiar with typical software development models, software engineering in general, and just the basics of application development. In order to secure applications, you have to be able to quickly navigate and understand frameworks, languages, and code that you may not be familiar with. You will also need to have some familiarity with the platform that code is running on…so if you’re focusing on web 5 © 2020 - Cybr development, you should know basic Linux. For mobile, you should be familiar with iOS or Android, and so on. We’ll talk more about Application Security jobs and requirements in the next chapter, but at the end of the day, you will be spending the bulk of your time analyzing source code, manipulating requests between your application and backend services, and trying to find holes in the application’s security. If you’ve never touched a line of code before, you won’t be able to do this. Instead, I’d recommend you pause here and enroll in programming courses that pique your interest. Let’s get started! But if you’re still reading, I’m excited to have you here and to get started! By the end of this material, you will walk away with a thorough understanding of Application Security concepts and how they relate to web, mobile, and cloud applications so that you can then dive deeper into those respective areas depending on your interests and/or job requirements. And now, let’s move on to the next chapter where we will talk about Application Security as a job! About AppSec as a job We’ve become so accustomed to seeing reports of high profile hacks that it’s no surprise when a new big one happens. And we’re talking about very public hacks on organizations that have massive budgets compared to small businesses. Most of the small business hacks don’t make it on the news, even if they can have even more severe consequences to the business. And while all of these hacks could have been avoided, the fact of the matter is that this is complicated business. So complicated, in fact, that businesses hire people whose job it is to secure their applications. Sometimes even entire teams or departments are dedicated to this stuff. If you’re here, you’re probably interested in getting a job in application security, or you already have a job in the field and you’re looking to formalize your learning. This chapter is more for the people who are looking to enter this field and this is their starting point. 6 © 2020 - Cybr Let’s answer questions you most likely have So, this chapter aims to answer questions that you most likely have, such as: What kinds of jobs can I get with Application Security skills? What are the requirements for those jobs? What kinds of salaries could I expect? and more Let’s start with the first question since it will help us answer the others: “what kinds of jobs can I get with Application Security skills? What kinds of jobs can I get with AppSec skills? You can do this by using a number of different job search engines. In this chapter, we use the Google one. Job search for Application Security jobs 7 © 2020 - Cybr From there, select your location and any other filters you want. I’ll just select Austin TX for our example. When I did this search, there were a lot of different application security engineer positions — “Application Security Engineer, App Sec Architect, Product Security Engineer, Application Security Manager, etc.” If you see any position that piques your interest in particular, look at those requirements, compare to your current skill set, and then at the end of this material, you will have a better idea of where your knowledge gaps are so that you can focus in that area. Not all of these post the salary range, but you can get an idea of typical pay by looking at the bottom, which pulls from other websites. There are websites like indeed, glassdoor, and salary.com which can give you a better salary range based on your experience level and other factors. So looking at all of these questions, here’s what we can say in general: Salary ranges are always really hard, because they depend on too many factors, but when I looked at positions in Austin, for entry-level, most of them had a starting salary range of just about $80k, so getting to six figures is definitely achievable either right away or as you get more experience under your belt. As an Application / Software Security Engineer, you can expect to: Develop and write new (or modify existing) computer applications, software, or specialized utility programs following software security best practices — so it’s important that you understand those security best practices and that’s a big part of this material You can also be expected to secure new or existing applications that others have developed, which means you need to be able to understand and analyze other people’s code, ensure that this code meets software security best practices and that it aligns with your businesses’ risk appetite. This all means that you also need to put yourself in the shoes of an attacker and identify the potential different paths through your application that attackers can use to do harm to the business. So you need to be able to think through not just the code, but the entire application as a whole. Because that application likely speaks to a database, likely has authentication, sends information over a network, etc…these are all attack vectors that must be kept in mind 8 © 2020 - Cybr That doesn’t mean you need to have a thorough understanding of infrastructure security, or networking security, because maybe you are in a large enough organization that has teams dedicated to that and so you have a more narrow area of focus. But if you’re part of a small business or smaller startup, it very well could be that you’re also entrusted with those areas of responsibility. Regardless, I highly recommend that you aim to understand as much of the entire picture as you can because at the very least you can then speak intelligently about it. As we wrap up this chapter, in the next chapter, we’re going to explore the NICE Framework and the Open Web Application Security Project or OWASP for short to explore this in more detail because they both provide blueprints to better understand specialty areas, work role tasks, and necessary knowledge, skills, and abilities. OWASP has also developed standards that will prove to be incredibly helpful throughout this material and throughout your career in cybersecurity. So with that, let’s move on to the next section and chapter! Exploring the NICE Framework and OWASP In the previous chapter, we talked about Application Security as a job which included some of the requirements for various job postings and also general recommendations. But wouldn’t it be NICE if there were a NICE Framework that could tell us what to focus on? OK I know that was cheesy, but you have to admit that it is a clever acronym. The National Initiative for Cybersecurity Education came up with a Cybersecurity Workforce Framework, but that takes way too long to say, so they’ve abbreviated it to just calling it the NICE Framework. In any case, it was developed in partnerships with NICE, the Office of the Secretary of Defense, and the Department of Homeland Security to “provide educators, students, employers, employees, training providers, and policy makers with a systematic and consistent way to organize the way we think and talk about cybersecurity work, and to identify the knowledge, skills, and abilities needed to perform cybersecurity tasks.” Again, way too much, so in short, let’s just say that it’s a blueprint to categorize, organize, and describe cybersecurity work. 9 © 2020 - Cybr Exploring the NICE Framework Let’s pull up the framework online and see what it looks like. It breaks it all up into: Categories (ie: Securely Provision) Specialty Areas (ie: Software Development) Work Roles (in this case, Software Developer and Secure Software Assessor) Tasks Knowledge, Skills, and Abilities (KSAs) A number of these will be covered, even if at a higher level, in the rest of this material. So if this is the area you are interested in, then you are in the right place. Of course, we won’t be able to cover all of these in the time we have for this material, but you can then take what you’ve learned and fill in your other gaps thanks to this framework. I highly recommend that you spend some time looking over this after you complete this chapter so that you can familiarize yourself with these lists, and so that you can take a good look at where you currently are and what you need to learn to fill in your gaps. Comparing these lists with the job postings we saw in the prior video, you’ll quickly realize that not all job postings require all of these KSAs, so don’t get overwhelmed and think you need to learn all of it in a month. But again, use this as a frame of reference! So that’s the NICE Framework in a nutshell. Now, let’s take a look at OWASP. Exploring the OWASP Organization The Open Web Application Security Project, or OWASP for short, is a nonprofit foundation that aims to improve the security of software, and they do this by being vendor agnostic. They provide a breadth of resources and standards to help developers improve the security of software, and we will be leaning heavily on their work throughout the remainder of this material, that way you can reference their projects during, but also after going through this material when it’s time to apply what you’ve learned on the job or on personal projects. Plus, if you’re in this industry, you will often hear people reference OWASP so that the next time someone mentions it, you know exactly what they are talking about. 10 © 2020 - Cybr Let’s take a quick look at a list of their projects so you can see what I mean. Their flagship projects are a great place to start. For example, we will go over the OWASP Mobile Top 10, the OWASP Top Ten for web security, the OWASP Web and Mobile Security Testing Guides, OWASP Cheat Sheets, Application Security Verification Standards, and more. As you can see, this is a rich library that you will reference over and over again throughout your career. I’d be lying if I said that looking at this list didn’t get me excited. I hope you feel the same way because we’re going to spend some time looking at these! Alright, let’s move on to the next chapter where we start to dive into the critical concepts of application security! 11 © 2020 - Cybr Critical Concepts of Application Security Establishing a baseline with the ASVS To produce a secure web application, you have to first define what secure means for that application. Because if you don’t have this defined, then how can the team possibly know where to aim? It’s also much easier and more cost-effective to design security from the start than to try and retrofit security into existing applications and APIs. Of course, that’s not always possible. Maybe you are inheriting an existing application, or you are dealing with a mature set of APIs that have drifted over time. Regardless of the situation that you find yourself in, start with a baseline and then build on top of that. So that’s what we’re going to do in this section. We’re going to build our baseline with a strong support structure. Building our AppSec baseline Even just building a baseline can seem like such a daunting task because there are so many things to think about. Lucky for us, OWASP, as we saw in the prior chapter, has created a number of projects that can help us with that. 12 © 2020 - Cybr In this chapter, we’re going to explore the OWASP Application Security Verification Standard or ASVS, as a guide for setting our security requirements baseline for our applications. You can find this by going to Projects → Browse All Projects → OWASP AppSec Verification Standard to download it, or you can view it at this URL. As we go through this chapter, keep in mind that OWASP has separated standards for web and mobile application security. While this chapter is focusing more on web and cloud application security baselines, we will also look at the Mobile Application Security Verification Standard in the mobile section of this ebook. As we get familiar with these projects, it will be easier to look at mobile-specific ones, so even if you are primarily interested in mobile application security, this chapter is still relevant. The Application Security Verification Standard (which I’ll refer to as the ASVS from now on) is currently on version 4.0 (from 2019, which is the latest version at the time of this recording in 2020) has these objectives: To provide us with a measurement on how much trust we can place in our web application’s security To provide guidance as to what we should build into our security controls to satisfy security requirements To provide a standard for application security verification requirements in contracts with 3rd parties ASVS Verification Levels Essentially, the ASVS is a catalog of security requirements and verification criteria that we can use for all of our projects. And it does that with 3 different verification levels: ASVS Level 1 is for low assurance levels ASVS Level 2 is for applications that contain sensitive data and is the recommended level for most apps ASVS Level 3 is for the most critical applications Each level has a list of security requirements defined by this standard, and this is what it looks like: 13 © 2020 - Cybr Click image for higher resolution And this will make more sense as we look at the actual requirements, but using these requirements and levels, we can start to create our own secure coding checklist specific to our applications. If we determine that our API or application is at a level 1 because it doesn’t contain or touch any sensitive data whatsoever and that it can get by with the absolute bare minimum, then we will approach it differently than if we deem it to be a level 2 or level 3. Level 1 is also useful as a first step in a multi-phase effort, so it can act as a good starting point but in a lot of cases, it should not be your endpoint. ASVS Level 1 The ASVS summarizes level 1 as having security controls that can be checked automatically by tools or manually without access to the source code. These security measures can thwart the most basic attacks that use simple and low effort techniques to identify easy-to-find and easy-to-exploit vulnerabilities. But they will fall apart with more determined attackers and more sophisticated attacks. The ASVS deems level 1 to be the absolute minimum that all applications should strive for. The unfortunate reality is that so many applications don’t even meet level 1 requirements. If you find yourself in that situation, start with level 1 and work your way up. ASVS Level 2 Level 2 aims to defend against most of the risks associated with software today. This is a level that many businesses should aim to have, especially to protect their business-critical areas. 14 © 2020 - Cybr ASVS Level 3 Level 3 is the highest level defined in this standard and requires an in-depth analysis of architecture and code and in-depth testing that goes far beyond automated tools or online scans. This is a level you should attain if a successful attack would significantly impact your organization’s operations or even survival. This level, of course, requires much more investment, which is why the standard labels level 2 as the recommended level for most applications. But at the end of the day, you are the expert in regards to your applications, so it is up to you to determine which level fits your needs. Now, knowing these 3 different levels, let’s continue exploring the ASVS in order to understand the different security categories and the different requirements that represent best practices for each category. ASVS Categories & Requirements Since the list of categories and requirements is quite lengthy, we won’t have time to explore all of them, but let’s take a look at a few examples so that we can get the hang of it. The ASVS contains categories such as authentication, access control, error handling / logging, web services, and others. Each category contains a collection of requirements that represent the best practices for that category and they are written to be verifiable statements. Let’s take a look at V1.1 Secure Software Development Life Cycle Requirements; Requirement 1.1.1 Do you satisfy that requirement – yes, or no? If yes, check the box, otherwise, you don’t satisfy requirements for L2 or L3. 15 © 2020 - Cybr In the case of V1.1, Level 1 does not require any of these, but both Levels 2 and 3 do. One more observation I’ll make is that, as you read through these, think about the difference in building an application with these requirements in mind from the beginning, versus retrofitting after the fact. It’s much easier to start with these in mind. 16 © 2020 - Cybr There is a lot more to the ASVS than we have time to cover, so please take the time to explore these standards after completing this chapter. In the next chapter, we’re going to explore another framework called the OWASP SAMM – or Software Assurance Maturity Model which was donated to, and now maintained by, OWASP. So mark this chapter as complete, and I’ll see you in the next one! By the way, if you have any questions about this chapter or any other chapter, head over to the forums created specifically for this course, and myself or others will jump in and help! Establishing a baseline with SAMM Helpful links for this chapter: OWASP SAMM Homepage OWASP SAMM Project Page OWASP SAMM PDF SAMM stands for Software Assurance Maturity Model, and it’s a model that helps understand the core building blocks of a secure software program from a macro point of view. It provides a self-assessment model for all types of organizations to use (whether large or small), it is technology and process agnostic, and it supports the complete software lifecycle. SAMM Characteristics SAMM has 3 main characteristics: Measurable – with defined maturity levels, similar to the levels we saw in the ASVS from the prior chapter Actionable – clear paths for improving those maturity levels Versatile – by being technology, process, and organization agnostic This makes SAMM a great tool to help analyze your organization’s current security stance so that you can define iterations to improve, and then show progress towards those iterations with actual measurements. 17 © 2020 - Cybr SAMM Structure Let’s take a look at how SAMM is structured: You can see the structure directly on the website, and they also have a barebones PDF version. SAMM Critical Business Functions Click for higher resolution At the highest level, SAMM defines five critical business functions and those business functions are categories of activities related to software development. They are: Governance ○ Governance focuses on the processes and activities for how an organization manages software development. This includes cross-functional groups involved in development and business processes established at the organization level 18 © 2020 - Cybr Design ○ Concerns the processes and activities related to how an organization defines goals and creates software within development projects. This usually includes requirements gathering, high-level architecture specification and detailed design Implementation ○ Focused on the processes and activities related to how an organization builds and deploys software components and its related defects. Activities in this function have the most impact on the daily life of developers. The joint goal is to ship reliably working software with minimum defects Verification ○ Focuses on the processes and activities related to how an organization checks and tests artifacts produced throughout software development. This typically includes quality assurance work such as testing, but it can also include other review and evaluation activities Operations ○ Encompasses those activities necessary to ensure confidentiality, integrity, and availability are maintained thoughout the lifetime of an application and its data. SAMM Security Practices 19 © 2020 - Cybr Click image for higher resolution For each business function, SAMM defines three security practices each, so: There are 15 security practices that are independent silos for improvement and that map to the five business functions of software development that we just looked at The security practices are: Governance: ○ Strategy and Metrics – forms the basis of your secure software activities by building an overall plan ○ Policy and Compliance – drives the adherence to internal and external standards and regulations ○ Education and Guidance – focuses on increasing the knowledge in the organization regarding secure software Design: ○ Threat Assessment – focuses on identifying potential threats in applications ○ Security Requirements – focuses on defining appropriate security requirements for your software and your software suppliers. ○ Security Architecture – focuses on managing architectural risks for the software solution Implementation: ○ Secure Build – creating a consistently repeatable build process and accounting for the security of application dependencies ○ Secure Deployment – increasing the security of software deployments to the production environment and the supporting secrets. ○ Defect Management – managing security defects in software and their associated metrics. Verification ○ Architecture Assessment – validating the security and compliance of the software and supporting infrastructure architecture ○ Requirements-driven Testing – using both positive (control verification) and negative (misuse/abuse testing) security tests based on requirements (user stories). ○ Security Testing – detection and resolution of basic security issues through automation, allowing manual testing to focus on more complex attack vectors. 20 © 2020 - Cybr Operations ○ Incident Management – addresses activities carried out improve the organization’s detection of, and response to, security incidents ○ Environment Management – describes proactive activities carried out to improve and maintain the security of the environments in which the organization’s applications operate. ○ Operational Management – focuses on operational support activities required to maintain security throughout the product lifecycle SAMM Maturity Levels & Streams Click image for higher resolution For each of those security practices, SAMM defines three maturity levels as objectives: The 3 maturity levels are more sophisticated to implement than the prior one, and they also have more stringent success metrics We saw varying levels of maturity in the ASVS, so this is the same concept. An organization does not have to meet all of the maturity levels since they may not all be relevant or the organization may choose to prioritize some over others, so it’s important to keep that in mind and not feel overwhelmed. 21 © 2020 - Cybr And for each security practice again, SAMM defines two streams: Streams have objectives to be reached, and those objectives are tied to the different levels, so they also increase in complexity For example, for the Strategy & Metrics security practice, there are two streams: Stream A – Create and Promote ○ Level 1 – Identify organization drivers as they relate to the organization’s risk tolerance ○ Level 2 – Publish a unified strategy for application security. ○ Level 3 – Align the application security program to support the organization’s growth. Stream B – Measure and Improve ○ Level 1 – Define metrics with insight into the effectiveness and efficiency of the Application Security Program ○ Level 2 – Set targets and KPI’s for measuring the program effectiveness ○ Level 3 – Influence the strategy based on the metrics and organizational needs SAMM breaks all of this down into even more detail, including assessment questions and quality criteria to measure the progress and whether objectives have been met or not. This is another lengthy document and it’s a lot to chew on, so take a look at it after completing this chapter. Once you feel like you’ve got the hang of it, move on to the next chapter where we explore a list of top 10 proactive controls that should be included in every software development project. A Practical Approach to Application Security Now that we’ve looked at how to create a baseline for our applications with the ASVS and SAMM, it’s time to talk about the practical approaches to implementing some of the most important requirements in our projects. Because all of the knowledge in the world doesn’t matter if we can’t apply it, so to help with this, let’s look at the OWASP Proactive Controls which is a list of security techniques that should be included in every software development project. 22 © 2020 - Cybr OWASP Proactive Controls The OWASP Top Ten Proactive Controls is ordered in terms of importance, so let’s start from the top. C1: Define Security Requirements You may remember in the ASVS chapter that some of the requirements had links with a C and a number (ie: C1). “C1” link in the ASVS requirements Those map directly to these requirements. So when talking about “verifying the use of secure software development lifecycle that addresses security in all stages of development,” they link back to C1 which is the control we are looking at right now. So we can start to see how these are all tied to work together. This control explains how to grab those requirements we’ve looked at in prior chapters and turn them into User Stories and Misuse Cases. User Stories, as long as you’ve been programming for a couple of years, should not be a new concept to you. It takes the perspective of the user, administrator, and describes functionality based on what a user wants the system to do for them. For example, if we look at ASVS requirement 2.1.1 which is to “Verify that user set passwords are at least 12 characters in length” 23 © 2020 - Cybr User stories might be: As a user, I can enter a password that has a minimum of 12 characters As a user, I can enter my username and password to gain access to the application While a misuse case is a story focused on the attacker and their actions: As an attacker, I can find passwords shorter than 12 characters Breaking down the ASVS requirements into these user stories and misuse cases help make them more testable by us or our team. At this point, though, you might say “Christophe, there are SO many requirements in the ASVS. It will literally take me weeks to break them down into user stories and misuse cases.” OWASP is one step ahead of us and they’ve outlined 4 steps to implementation. As we talk about these steps, think of them in terms of how it fits into your existing or future development lifecycle. Implementing Security Requirements Step #1: Discovery and Selection You’re not meant to tackle all of it at one time. Instead, look through the list of requirements from the ASVS and/or any other custom requirements you’ve deemed necessary for your application, and prioritize them. Break them down into a manageable amount per release or sprint, and then continue adding more security functionality in each sprint over time. As we will see in a later chapter on threat modeling, there’s another way of prioritizing the most important threats first, so we will revisit prioritization. Step #2: Investigation and Documentation During the investigation and documentation phase, review the existing application, and compare it against the security requirements that you’ve outlined as necessary. From there, figure out which requirements your application meets, and which requirements still need development. And make sure to document the investigation so that it remains accurate over time. 24 © 2020 - Cybr Step #3: Implementation After you investigated and documented your findings of deficiency, it’s time to turn that into action like we just talked about and either modify the application to add the new security functionality or eliminate the insecure option. Step #4: Test Implementing the changes isn’t enough. As the final step, you have to create test cases in order to confirm whether the modified functionality solves the requirement or not. If it doesn’t, then go back to the implementation phase, and if it does, then it’s time to update documentation and move on to the next requirement! As we wrap up control #1, reflect on the fact that this control, which is deemed the most important out of all 10 by OWASP, isn’t about protecting against a specific type of attack. Instead, it’s about building a process that includes security, from the beginning, so that it’s not an afterthought. Alright, so that’s control 1 of the Proactive Controls. Let’s take a look at C2: Leverage Security Frameworks and Libraries. C2: Leverage Security Frameworks and Libraries This control focuses on 3rd party frameworks and libraries, which provide a ton of value but can also introduce nasty vulnerabilities if not managed properly. We’ll talk more about this later in the material, but go ahead and review this control now or after completing the chapter. C3: Secure Database Access C3 focuses on Secure Database Access. An important sentence to highlight on this page is that “SQL Injection is one of the most dangerous application security risks.” Chances are high that you’ve heard of SQL Injections because they happen way too frequently and they can do serious damage, like exposing entire databases that can contain critical data such as passwords and medical or financial records. This is another important topic that we will revisit in the material – in fact, we will perform SQL injections on a sample web app – and that I recommend you spend more time reading about on this page. C4: Encode and Escape Data C4 is encoding and escaping data. Again, you’ve likely heard of Cross-Site Scripting (XSS) attacks, and encoding/escaping is a defense against these types of attacks. 25 © 2020 - Cybr If you’re not familiar with XSS, spend some time on this page. In a future chapter, we will discuss this type of attack further and perform an XSS attack of our own on a sample web app. C5: Validate All Inputs C5 is about validating all inputs which will also help defend against Cross-Site Scripting, SQL Injection, gaining elevated privileges, or other forms of attacks. Make sure you take the time to review this page. C6: Implement Digital Identity C6 discusses implementing digital identities to provide guidance in terms of authentication and session management. They define digital identity as the unique representation of a user (or other object) as they engage in an online transaction. Authentication is the process of verifying that an individual or entity is who they claim to be, and Session Management is a process by which a server maintains the state of the user’s authentication so that they can continue to use the system without having to re-authenticate. What’s particularly interesting on this page is that we re-visit a level system similar to what we saw in the ASVS. The NIST 800-63b, which is a guideline from the National Institute of Standards and Technology, outlines 3 levels of authentication assurance (or AAL). With level 1 being for lower-risk applications, they only require passwords for authentication, but with other requirements listed below. Level 2 requires Multi-Factor Authentication with a combination of: A password or pin A token or phone, and/or Biometrics Level 3 requires cryptographic based authentication, which is providing proof of possession of a key through a cryptographic protocol — usually done through hardware cryptographic modules. Be sure to read the rest of this page for more information on digital identities. 26 © 2020 - Cybr C7: Enforce Access Controls Moving on, we then have C7 which is enforcing access controls, and this is different from authentication since it looks at processing access for specific requests compared to verifying identity. C8: Protect Data Everywhere C8 looks at Protecting Data Everywhere. Data such as passwords, credit cards, health information, etc…this is where understanding concepts such as encryption in transit, at rest, and in use comes into play. This is a topic we will re-visit in the cloud security section of this material. C9: Implement Security Logging & Monitoring C9 is in regards to implementing security logging and monitoring. Again, we will review this in a little bit more detail in the cloud security section of this ebook. C10: Handle All Errors and Exceptions Finally, at least as far as the proactive control list goes, C10 covers handling all errors and exceptions. If you’ve ever used an application that crashed or gave you en error message and it contained what seemed like sensitive information, then you’ll immediately know why this control is important. If we don’t handle failure gracefully, attackers can use that to their advantage. 27 © 2020 - Cybr Exploring the References and Tools One more observation before we move on is that each of these controls have References and Tools. I highly recommend that you start looking at those or at least bookmark them for when you need to review them. This list is meant to be a solid starting point, but as you go through it, think through any other controls that your application or business may require. Also, if you’re already working on an application or if you’re thinking of building one in the near future, think about how these controls will apply. These are topics that we are going to see again as we explore web, mobile, and cloud security. So while I went through this list rather quickly, please take the time to review it more thoroughly after marking this chapter as complete, and don’t worry, we’ll come back to some of this as we move along. After that, I’ll see you in the next chapter where we take a look at a handy cheat sheet. See you there! Application Security Risks and Threat Modeling Everything we’ve looked at so far has helped us come up with a baseline for what Application Security means and how to approach such a large undertaking in smaller, incremental steps. 28 © 2020 - Cybr But, at the end of the day, every organization and every application will have its own specific requirements. So we’re going to use another project in order to create threat models that fit our specific needs. These threat models are important to consider even before we start any testing. Because if we don’t understand what’s important to spend time on, then we’ll end up wasting time fixing vulnerabilities that may not be the highest risks and highest priorities. Or worse, if you release vulnerabilities into production and they become compromised, how should you respond? Figuring that out in the heat of the moment is not the best approach. Having a Risk and Threat Model will help you prepare. One thing to keep in mind is that, depending on the organization you are a part of, these threat models may be created by a different team – especially if you are part of a large organization. But understanding the concepts behind threat modeling is important, since you will still have to be familiar with the topic when it comes to implementing security features or fixing vulnerabilities. 6 Steps to Risk Analysis Now, the approach for risk analysis that we’re going to cover today is from – surprise surprise – OWASP. It builds on top of the standard risk model of: Risk = Likelihood * impact And it solves this equation using 6 steps. Step #1: Identifying a Risk Step #2: Factors for Estimating Likelihood Step #3: Factors for Estimating Impact Step #4: Determining Severity of the Risk Step #5: Deciding What to Fix Step #6: Customizing Your Risk Rating Model Step #1 With Step #1, a tester needs to think through different scenarios, and we’ll usually want to look at worst-case scenarios. 29 © 2020 - Cybr Once we’ve identified a potential risk, we need to estimate how likely it is to happen by using a low, medium, or high rating. We get to these ratings by ranking different factors. Let’s take a quick look at what this means in Step #2: Step #2 For there to be a threat, there has to be at least one threat agent. How technically skilled is this person, or group of people? What kind of motive might they have? Is there a lot of potential reward? Where rewards are often tied to money What kind of resources and opportunities are required for the threat agent to find and exploit this vulnerability? and how large is the group of threat agents? Is it one person? Is it a team? Each answer comes with a ranking number. As we tally these rankings, we will be able to determine the gravity of the threat. Next, we look at Vulnerability Factors with a goal of estimating how likely it is that a particular vulnerability will be discovered and exploited. We need to look at the Ease of Discovery which is how it easy it is for the threat agent to discover the vulnerability. Rankings suggested here are “practically impossible”, “difficult”, “easy”, and “automated tools available” (meaning that the threat agent could run an automated tool to find the vulnerability) Then there’s the Ease of Exploit. Perhaps a vulnerability is easy to find, but not so easy to exploit. Then, with Awareness, we are ranking how well known the vulnerability is to this threat agent. Finally, how likely is the exploit to be detected – will it be detected by your application, will it be logged and later reviewed, logged without a review, or not logged at all? After going through Step 2, we’ll have the information we need to determine the likelihood, but that by itself is not enough. Even if something is extremely likely to happen but would have virtually no impact, then it may not be something to consider. Step #3 So, with step 3, we’re going to look at estimating the impact. OWASP reminds us that there isn’t just the technical impact on an application that a successful attack brings. Instead, there’s also 30 © 2020 - Cybr the business impact. So when estimating the impact, we have to put both of those factors into the equation. Technical Impact Factors take into account the magnitude of the impact on the system if the vulnerability were to be successfully exploited. There is the: Loss of confidentiality Loss of integrity Loss of availability Loss of accountability The Business Impact Factors instead look at: Financial damage Reputation damage Non-compliance Privacy violation and any others specific to your business Step #4 We’re now at Step 4, where we can look at all of the ratings we’ve worked on to this point and give them a low, medium, or high impact. Low is for 0 to less than 3 Medium is for 3 to less than 6 High is for 6 to 9 This is a fairly simple model, but OWASP outlines a more advanced calculation that they call the “Repeatable Model.” Please take a quick look to get familiar with how it works. But as we move on, let’s say, for the sake of example, that a certain threat that we are evaluating has a medium likelihood of being exploited, with a high technical impact but a low business impact. In that case, OWASP recommends going with the business impact over the technical impact, as long as we can trust the business impact analysis. So even if the technical impact would be high, since the business impact is low, we would set the overall severity as low. We could have an opposite example, where the technical impact is low but the business impact is high, making the overall severity high. 31 © 2020 - Cybr Going through this exercise is important, because it helps us decide what to fix first, which leads to step #5: Step #5 Even if you could fix a bunch of low severity risks within a short period of time, it would have less of a benefit than fixing fewer high severity risks first; even if they take longer to fix. As developers, and I’m guilty of this myself, we can have a tendency to handle the low hanging fruit first, but by having our threat model, we know what’s more important to work on and we can have uniform agreement across the business. It’s also entirely possible that some risks are not worth fixing. No matter how much you want to take care of it, if the cost of fixing the risk is substantially more than the loss from an attack would be, including all factors, then maybe that’s not the best use of company resources. This is an unfortunate reality that we have to keep in mind when going through these exercises. Step #6 Let’s wrap up with Step #6 which is to customize the risk rating model. We’ve talked about this throughout the material, but it bears repeating here especially. If you just grab what you see on this page and you don’t attempt to customize it to your organization, it won’t be effective in convincing leadership, and it won’t be effective in stamping out the biggest threats. Take what’s here, and customize the different factors and options until it makes sense for your organization and your application. As you can see, this page provides many references that go into much more detail for risk and thread modeling. Be sure to save these resources for when you tackle Threat Modeling for your application or organization. With that, let’s move on to the chapter! Cheat sheets to tie it all together One more peg that we are adding to support our baseline is exploring the OWASP Cheat Sheet Series. 32 © 2020 - Cybr Up until this point, we’ve looked at the Application Security Verification Standard, SAMM, Proactive Controls, and Threat Modeling. Just between those projects alone, we could spend weeks and months reviewing everything, only to forget it all when we need it. So the group at OWASP created a series of cheat sheets that we’re going to look at in this chapter because this is something you should bookmark and continuously reference. Navigating the cheatsheets On the left-hand side, we have a convenient table of contents that lets us quickly jump to relevant areas. Let’s start with the Index for ASVS. This should look very familiar but with a twist: the different requirements link to their relevant cheat sheets. So for V1.1, we have 3 different cheat sheets: Threat Modeling Abuse Case Cheat Sheet and Attack Surface Analysis Cheat Sheet So this makes it very easy and convenient to go from the requirement we’re solving for, to the cheat sheet associated with it. The same thing goes for Proactive Controls, which has its own index. You’ll quickly notice that not all cheat sheets may be relevant to you depending on the language your application is coded in. Some of these are PHP specific, Ruby specific,.NET specific, and so on. Let’s take a look at a few of these cheat sheets so we can get the hang of it. Starting with AJAX security, we’ll find a number of strong, straight-to-the-point rules that can help us stay out of trouble: Use.innerText instead of.innerHTML to prevent Cross-Site Scripting problems Never use eval() — eval executes javascript code so if a malicious user manages to slip in bad code that gets executed…well, you get the idea 33 © 2020 - Cybr and there are a few more to look over if you’re using JavaScript and AJAX calls We’ll also take a look at the PHP configuration cheat sheet because it includes a list of important configurations to be aware of and modify since oftentimes the defaults don’t focus on security and instead focus on ease of use. So this is another example of what you will find in these cheat sheets, and I encourage you to mark this chapter as complete and explore relevant ones in more detail. Once you’re ready, I’ll see you in the next chapter. 34 © 2020 - Cybr Web Application Security The State of Web Application Security Would you believe me if I told you that a vast majority of web applications currently in production contain known vulnerabilities? And by known vulnerabilities, I literally mean that they are known and have already been discovered and reported publicly. Well, you don’t have to take my word for it: a Micro Focus 2019 Application Security Risk Report found that nearly all web apps have bugs in their security features. 35 © 2020 - Cybr A Veracode State of Software Security Vol. 10 report shows that 83% of the 85,000 applications they tested had at least one security flaw. Many had much more, as their research found a total of 10 million flaws, and 20% of all apps had at least one high severity flaw. In fact, 2 in 3 apps fail to pass tests based on the OWASP Top 10 list and the SANS Top 25 Most Dangerous Software Errors. ⅔ of apps fail common security tests 36 © 2020 - Cybr These stats only account for known vulnerabilities and to be fair, I’m sure there are a number of false positives — but also these stats don’t even account for zero-day vulnerabilities. A 0-day vulnerability is unknown or unaddressed. So for example, if you’re looking to exploit an application and you find a vulnerability in that application that no one else has found (or at least publicly reported), then you can continue to exploit that vulnerability until it is addressed. As a side note, 0-day vulnerabilities are exploited frequently, and there is a black market for these since they can be sold…depending on the vulnerability, it could be sold for a serious amount of money. In more recent years, organizations have started to offer bug bounty programs in order to reward the findings of 0-day vulnerabilities to help avoid having these sold and exploited, and instead, to give the organization a chance to fix them before they become public knowledge. More on bug bounties here: https://hackerone.com/bug-bounty-programs Going back to the Veracode report, the most common types of flaws found were: Information leakage (64%) Cryptographic issues (62%) CRLF injection (61%) Code quality (56%) Insufficient input validation (48%) Cross-site scripting (47%) Directory traversal (46%) Credentials management (45%) We’re going to explore some of these in a bit more detail in the next chapter, but let’s talk about the top 3. Information Leakage Information leakage refers to an application revealing sensitive data such as technical details of an app, developer comments, environments, or user-specific data. This data can then be used by an attacker to exploit the target application, network, or users. A basic example of this would be if a developer had added HTML or script comments to their code that contained sensitive information, and never removed it before going to production. 37 © 2020 - Cybr Click image for higher resolution Another example would be improper application or server configurations, or differences in page responses for valid versus invalid data. If you’ve ever accessed a broken web page that released information about the database, webservers, or whatever else, then that could be considered information leakage. So information leakage by itself may not be a breach in security, but it can give crucial information to an attacker that can be used to exploit your app or its infrastructure. Cryptographic Issues Cryptographic issues can be problems related to: Encrypting the wrong data, leaving critical data exposed Improperly storing and managing crypto keys Using bad algorithms, or trying to create and use your own algorithms 38 © 2020 - Cybr CRLF Injections CRLF injections were the third most found flaws. They can be very nasty attacks because the HTTP protocol uses what’s called CRLF character sequences to signify where one header ends and another begins. It also signifies where headers end and the website content begins. In our example, these are headers returned by Google.com. Example of headers from Google.com If attackers can insert their own CRLF, they can do all kinds of things including redirecting users to a different website, where they might create an identical version of your webpage and use it for phishing. They could also run unwanted commands on servers, and more. 39 © 2020 - Cybr Visual representation of a phishing attack Something we haven’t talked much about to this point is the idea of chaining attacks together. We’ve talked about Cross-site Scripting (XSS) attacks, but what if an attacker used a CRLF to inject JavaScript code? In this case they are chaining a CRLF injection with Cross-site Scripting. The following simplified example uses CRLF to: http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d% 0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aConten t-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E 1. Add a fake HTTP response header: Content-Length: 0. This causes the web browser to treat this as a terminated response and begin parsing a new response. 2. Add a fake HTTP response: HTTP/1.1 200 OK. This begins the new response. 3. Add another fake HTTP response header: Content-Type: text/html. This is needed for the web browser to properly parse the content. 4. Add yet another fake HTTP response header: Content-Length: 25. This causes the web browser to only parse the next 25 bytes. 5. Add page content with an XSS: alert(1). This content has exactly 25 bytes. 6. Because of the Content-Length header, the web browser ignores the original content that comes from the web server. 40 © 2020 - Cybr Go ahead and research the other flaws that we talked about, and if you can’t find a good explanation or if you’d like clarification, please use our forums and either myself or someone from our community will be able to help! We’re also going to explore more common vulnerabilities and attacks in the next chapter, including looking at examples and prevention methods. Common Vulnerabilities and Attacks Looking at the reports from the prior chapter, we can start to see a pattern in the types of vulnerabilities that can become exploited, and which ones are the most common. Organizations like OWASP, SANS, and others, have created lists of the top web application security risks so that developers and organizations around the world can at least work to minimize these types of risks. We have to understand how our applications can be attacked in order to create defenses. Let’s take a look at the OWASP Top 10 Web Application Security Risks so you can see what I mean. OWASP Top 10 The top 10 are: Injections Broken Authentication Sensitive Data Exposure XML External Entities (XXE) Broken Access Control Security Misconfiguration Cross-Site Scripting (XSS) Insecure Deserialization Using Components with Known Vulnerabilities Insufficient Logging & Monitoring 41 © 2020 - Cybr Some of these should already look familiar because they were covered in the OWASP Proactive Controls list that we reviewed in another chapter, but this list goes into much more detail about each security risk. Keep in mind that the list is from 2017, however, OWASP is planning on collecting data in 2020 to see what has changed since then, and you can see more information on this tab “Data_2020.” So while this is a great starting point for us, we can’t just rely on this list or other lists. As Application Security Engineers, we have to constantly look out for what’s happening in the industry, and we can’t just rely on one or two top 10 lists. Just throwing that out there as a disclaimer: don’t get overwhelmed, but also don’t think it stops here. In any case, clicking on each of these brings up their individual cards. For example, if we click on Injection, here’s what we can see. SQL Injection At the top, we’ll see something familiar to us: Threat Agents & Attack Vectors ratings ○ Including factors specific to our application that only us can determine, and ○ Exploitability Security Weakness ratings ○ With prevelance and ○ Detectability Impact ratings ○ Technical and ○ Business Of course, these are specific to your application as we saw in the Threat Modeling chapter, but OWASP aims to give us a general idea for each of these. There is a PDF version of these web pages, and in the PDF, they explain how they calculated these, and they also show them all in one table so we can see how they ordered them in terms of highest to lowest risk. 42 © 2020 - Cybr Next, we get guidance on how we can determine whether our application is vulnerable to this form of attack. In the case of injections, such as SQL or other injections, our application is vulnerable if: User-supplied data is not validated, filtered, or sanitized by the application We can see examples of what is meant by this and how it would be achieved: SELECT * FROM accounts WHERE custID = ‘” + request.getParamter(“id”) + “’”; The attacker could modify the ID parameter value to send ‘ or ’1’=’1 … it might look like this: http://example.com/app/accountView?id=’ or ’1’=’1 Which would result in the database returning all customer records, not just your information since that query is saying WHERE custID = 1=1which is always true SELECT * FROM accounts WHERE custID = ‘’ or ’1’=’1’; …and that’s one way you end up with your username, email, and passwords on the black market for sale Injections can also be used to modify or delete data, which can cause even more harm. 43 © 2020 - Cybr To defend against this, OWASP also provides suggestions here. For example: We have to always assume that any user-supplied data is always going to be dangerous, and we have to use techniques to validate, filter, and sanitize it…but thankfully, frameworks and languages will contain methods that do this on our behalf – we just have to make sure they are properly being used. Going back to our SQL injection example from earlier, methods cleaning up user inputs would escape the single quotes in order to make them harmless: SELECT * FROM accounts WHERE custID = ‘\’ or \’1\’=\’1\’’; We can also use LIMIT statements so that even if we have a 1=1 which is always true, we LIMIT the customer records returned to just 1. Even if one of your customer’s records becomes compromised as a result of that, it’s better than all of your customers being affected! However, certain injections can bypass the LIMIT statement, so this is a fail-safe to use in addition to other techniques. Definitely not by itself. This is an example of limiting impact even if we weren’t able to successfully prevent an attack. We also get a list of extremely useful references in the bottom right to explore this subject further. 44 © 2020 - Cybr Fairly recent and high profile examples of SQL Injection attacks include companies like Target, Yahoo, Zappos, Equifax, Epic Games, LinkedIn, Sony, and many others. So while SQL Injections are not a new type of attack, they are still effectively used to this day. Broken Authentication The second vulnerability listed is Broken Authentication. Because so many applications have been compromised over the years, username and password lists have become easy to get a hold of. Example lists: https://github.com/danielmiessler/SecLists https://github.com/jeanphorn/wordlist https://haveibeenpwned.com/ If improper authentication security is used for an application, attackers can use those lists to do credential stuffing attacks that attempt the username & password combinations of millions of records to see if any of them work on your application. Other attacks try to use default username/password combinations, automated brute force attacks that try millions of passwords to see if any of them work, and dictionary attack tools that create combinations using words in the dictionary. 45 © 2020 - Cybr All it takes is one admin or high-value account to be compromised for authentication attacks to be worth the effort. An application is vulnerable to this type of attack if: It allows automated attacks It allows brute force attacks It allows default, weak, or well-known passwords like “Password1” or “admin/admin” It uses weak or ineffective credential recovery and forgot-password processes It uses plain text passwords or weakly encrypted and hashed passwords It has missing or ineffective MFA It exposes session IDs in URLs which can be used for something called URL rewriting, where an attacker can steal your session It does not properly rotate sessions IDs after successful login It does not properly invalidate session IDs after logout or after inactivity If you spent some time reviewing the proactive controls from a prior chapter, a lot of these should sound very familiar, and the ways of preventing will also look familiar. The overall recommendations here are to: Implement MFA wherever possible — passwords alone are becoming less and less secure when it comes to authentication. Adding another layer like multi-factor authentication makes it much more difficult to compromise accounts Don’t ship or deploy with any default credentials Implement weak-password checks by enforcing a certain password length and by checking for common passwords Ensure the registration, credential recovery, and general API pathways are hardened against enumeration attacks ○ Enumeration attacks consist of finding patterns that can be exploited. For example, have you ever seen a login form that tells you whether the username or password are wrong? As in “your username is correct, but the password is incorrect!” While this can be helpful to users of the application, it’s also helpful for attackers because now they know that they have a correct username, and they just need to find the password. Having generic messages such as “your username or password is incorrect” prevents attackers from knowing whether they have a correct username. 46 © 2020 - Cybr Limit or increasingly delay failed login attempts. It frankly baffles me how so many platforms don’t prevent basic brute force attacks. Even WordPress, at least at the time of this recording, does not prevent brute force login attempts in fresh installs. You have to either code it yourself or use a plugin to turn this protection on. This means attackers can try millions of combinations for usernames and passwords without anything preventing them. ○ Also, log all failures and alert administrators when attacks are detected. Finally, they recommend server-side built-in session management that generates new and random session IDs. Sessions IDs should not be in the URL, and they should be invalidated after logout or idle times. There are, of course, other ways of preventing authentication attacks, but these are common prevention methods. Go ahead and take a look at the example attack scenarios and feel free to check out the references for more information. A fairly recent example of successful credential stuffing attacks includes Nest. You may remember in 2019 that some Nest users were horrified when strangers started speaking to them through their Nest cameras. One of the ways attackers were gaining access to these devices was by using credential stuffing attacks. In response to these issues, Nest forced certain users to change their passwords if they were using compromised credentials. As a quick reminder, you will see the Application Security Verification Standard being linked to in these references a lot because many of the requirements we explored in prior chapters help prevent these types of attacks. We’re simply looking at why those types of requirements are so important to have when working on applications. OK, we’ve looked at a couple of the top 10 security risks so far and there are still 8 more. As we complete this chapter, go ahead and review them as we have been doing. If you have any further questions, please use the forums for this material. I’ll see you in the next chapter! DoS Attacks and Defense Another type of attack that I want to include here is called a Denial of Service attack or DoS for short. You may have heard of it being referred to as DDoS instead, which is simply a Distributed Denial of Service attack. While OWASP didn’t explicitly call it out as one of the top security risks, they have alluded to it a number of times. 47 © 2020 - Cybr I’m including it because Denial of Service attacks are quite common and not very difficult to do, so they’ve been an obvious choice for many attackers over the years. DoS attacks are a problem because they can cost a lot of money by causing disruptions in your service to customers, and they also put stress on your application and its infrastructure, which can result in unwanted behavior like revealing sensitive data that can later be exploited — a problem we’ve talked about already under the name of information leakage. The thing is, DoS attacks are not always caused by vulnerabilities in your code. Even if you have an extremely efficient and secure application, an attack that overwhelms the resources powering your application will bring it down to its knees. With that said, there are ways of protecting against attacks like these, and we’re going to take a look at some of them. What are DDoS attacks? But let’s back up for a minute — what are DoS or DDoS attacks in the first place? DoS attack illustration 48 © 2020 - Cybr DDoS attack illustration The point of a Denial of Service attack is to deny service to legitimate users. This could happen to websites, email, or really any service that relies on computers or a network. An attack like this is accomplished by flooding the system with so much traffic that the underlying systems can’t handle anymore requests. A Distributed Denial of Service attack is the same thing, except the attacker is using multiple different machines to attack that one target. The end result usually means a much larger attack, and a harder attack to defend against because the requests are coming from so many different locations — so you can’t just block one IP address, for example. Research from Kaspersky’s SecureList shows that in Q2 of 2019, there were more high-profile DDoS attacks than in the previous quarter — some of which were political in nature versus commercial. China and the U.S. ranked as the top two targets for DDoS attacks with 63.8% and 17.5 percent of the attacks, respectively. And Q1 also had seen an increase in attacks by 84 percent in just 3 months as compared to the prior quarter. According to Bulletproof’s 2019 Annual Cyber Security Report, a DDoS attack could cost up to $120,000 for a small company or more than $2 million for an enterprise organization. Other reports place these costs much higher One reason for this sharp increase in recent years has to do with the move towards Internet of Things. More and more devices are becoming connected to the internet, yet their security is oftentimes laughable. 49 © 2020 - Cybr According to a press release from Gartner, the number of IoT devices that are estimated to exist is 20.4 billion. Think about connected refrigerators and other appliances, baby monitors, thermostats, and all kinds of other devices. Outside of IoT, your other computers and devices can also be targets — like your phone, laptop, PC, etc… These devices can become compromised and turned into malicious bot farms, or botnets. As these devices are compromised, threat agents can control them with simple commands and have them do whatever they want: from spamming to brute force attacks, DDoS attacks, and everything in between. So what can we do to defend against these types of attacks? Let’s start by understanding these types of attacks a little bit better. If we consider the OSI Model, we can group attacks as the Infrastructure Layer and Application Layer attacks. There are other types of attacks, but we will focus on some of the bigger ones in this chapter. 50 © 2020 - Cybr Infrastructure Layer Attacks These attacks are usually at layers 3 and 4. They include attack vectors like SYN and UDP floods, and if you are not familiar with either of those I recommend a quick lookup – or feel free to ask in our forums! In any case, these attacks are usually large in volume and their aim is to overload the capacity of the network or the application servers. Fortunately, these attacks can be easier to detect which typically makes them easier to defend against. 51 © 2020 - Cybr Application Layer Attacks Attacks are layers 6 and 7. They are typically smaller in volume but they can do more damage with fewer resources and they can be difficult to detect and prevent because the traffic can be made to look legitimate. For example, a flood of HTTP requests to a login page could take down the ability for users to login, or even potentially taking down the entire application – but detecting bot requests versus legitimate user requests can be difficult depending on the sophistication of the attack. 52 © 2020 - Cybr DDoS Protection Techniques Reduce Attack Surface Area Knowing this, we can start to think about defense techniques. One defense technique is to reduce the attack surface area by limiting the exposure of your application and its resources to the outside world. 53 © 2020 - Cybr Architecture limiting database exposure You can do this by hiding resources in private networks, like hiding databases and making them only accessible from inside of your networks — which is a best practice for other reasons anyway. This doesn’t mean that attackers can’t take down your database by making your application run expensive database queries over and over again, but at least they can’t attack the database directly. We can also do this by restricting ports and protocols that aren’t absolutely necessary for your applications. Again, these are things we should be doing anyway to reduce the potential of other types of attacks. Another way of restricting the surface area is by using CDNs and load balancers in front of your web servers or other resources. If you use a CDN like Cloudflare or CloudFront, then traffic goes through those servers before reaching your application servers, and they will have other defense mechanisms included for free or for an extra charge. 54 © 2020 - Cybr Build elasticity I mentioned using load balancers in front of resources, and as the name implies, load balancers are typically used to balance load between servers. So if you have 4 web servers serving traffic for your application, the load balancer chooses which of the 4 servers to send a request to. By having 4 servers, you can theoretically handle more users at one time. But if the attack overwhelms those 4 servers, you could have automated scaling that spins up additional servers to handle the additional load. More advanced architecture with CDN, load balancer, and elasticity This can work, but it also means a higher bill unless, especially if your application is hosted in the cloud. If your scaling policies end up having to spin up 10 more servers, that automatically increases your costs by 10x for the duration of the attack. 55 © 2020 - Cybr You could always use a load balancer in front of just one web server; it doesn’t have to be in front of multiple web servers, while still providing benefits. Firewalls and other preventative services One more method that we will mention in this chapter is using things like firewalls or other services that can detect abnormal traffic and prevent it from making connections. Example architecture with a web firewall If your systems know what normal traffic patterns look like, it can detect whether something weird is going on. This can get pretty advanced, and there are premium services available for this very reason. Of course, many of the security features and preventions we’ve already discussed in this ebook will help protect against DDoS attacks. For example, preventing against SQL injection attacks can protect against denial of service attacks. Or preventing brute force attacks against login pages can also protect against DoS. 56 © 2020 - Cybr This is another topic we could spend hours talking about, but now that we’ve covered the basics of DoS attacks, let’s move on to the next chapter! 57 © 2020 - Cybr Mobile Application Security The state of Mobile Application Security 91% and 95% of applications for iOS and Android, respectively, have some sort of security vulnerability according to a report by Veracode. Found iOS & Android vulnerabilities 58 © 2020 - Cybr A different report by Micro Focus states that 88% of the mobile apps they tested had at least one critical or high severity issue in 2018, which was up 20% from 2016. Apps with at least 1 critical/high severity issue Considering our reliance on mobile applications for our day-to-day personal and professional lives, these are scary statistics, especially when you take into account the fact that many of us have apps that: control our home’s security, provide access to our banking and finances, contain personal images, videos, and more than enough personal information about a person and their family to do serious harm if it fell in the wrong hands. So as we build mobile applications, just like with web applications, it’s critical that we think about security from the very beginning. And we can do that by taking into account the two major mobile platforms: iOS and Android. Security differences between iOS & Android When looking at both iOS and Android, the two different platforms offer unique values and unique perspectives when it comes to security: 59 © 2020 - Cybr Android: Relies on open source code, giving owners of devices the ability to mess around and customize code…which is fantastic because it provides more flexibility. But, it can create weakness in the devices’ security because we can introduce flaws and vulnerabilities when making modifications There are also many different manufacturers with their different flavors of software and hardware, which again provides much more flexibility but potentially at the cost of security When it comes to updates, some providers or manufacturers may restrict which updates you receive, making it difficult to get the latest version – which is a critical step in keeping your devices secure Android devices do have the most market share when compared to any other mobile device, including iOS devices. This can be regarded as a weakness, because more users means more attractive targets for hackers. iOS: On the other hand, iOS: Is not open-source, Apple doesn’t release its source code to app developers. This can create limits, which many users and developers don’t like, but those limits can be a positive when talking about security Apple devices are tightly integrated between the software and hardware which reduces the number of variances iOS releases are pushed to all devices much more quickly, and since there aren’t a huge number of manufacturers and different custom devices, users can receive and apply those updates faster Security considerations for mobile In any case, both platforms have their own share of security issues and threats. When developing mobile applications, we have to keep that in mind, and we have to design security from the very start… …We have to think about how data is stored and transferred. 60 © 2020 - Cybr We have to think about the APIs our app is talking to, and vulnerabilities that may be present there. We have to consider how application permissions could be exploited, how to handle user authentication and authorization, and anything else that may get exploited. Things to consider and inspect: Stored data Web APIs and transport security settings Permissions Compiler options Root and jailbreak detection … In short, we need to think like an attacker, and in the following chapters, we’re going to explore frameworks that help us build a baseline for our mobile application security, as well as top mobile security threats and ways of preventing them. Later in this material, we will also explore testing tools to find issues in our code, and simulation tools to help us learn how to build more secure software. With that said, let’s get started! Establishing a Baseline with the MASVS Resource link: MASVS We’ve looked at the OWASP Application Security Verification Standard before, but that version was focused on web applications. In this chapter, we take a look at the mobile version. MASVS While the Mobile ASVS or MASVS is very similar to the ASVS that we’ve already seen, there are a number of differences. 61 © 2020 - Cybr For examples, the ASVS had 3 different verification levels, while the mobile version has 2. The first level is the recommended level for most mobile applications, and the second level is for apps that handle highly sensitive data, such as banking or healthcare apps. Also, the mobile version has a set of reverse engineering resiliency requirements which we don’t have in the web version, and they aim to prevent client-side threats. These are meant to be used in addition to L1 or L2 requirements, and not as a replacement All of the requirements are grouped in 8 categories, which can be viewed and navigated to on the left-hand side. It’s also important to keep in mind that the MASVS covers requirements to protect mobile applications on the client-side and the network communication between the app and remote endpoints, as well as generic authentication and session management. But, it does not have requirements for the remote services – like web services – that are used by the app. That’s when the regular ASVS can come into play, but just keep in mind the end-to-end security. MASVS does not contain reqs for web services - refer to ASVS for that MASVS Requirements Let’s take a look at a few of the requirements. 62 © 2020 - Cybr V1: Architecture, Design, and Threat Modeling V1 is for Architecture, Design, and Threat Modeling Requirements. Just like with the ASVS, we start our requirements by creating processes to integrate security throughout our software development lifecycle. This will help prevent only considering security at the very end of development, which – as we know by now – is not a security best practice. Some of the references should already look familiar, such as the OWASP Threat Modeling, which we would use to figure out which of these requirements are high, medium, and low priority for our application and for our organization. V2: Data Storage and Privacy Requirements V2, or the second requirement category, is for Data Storage and Privacy Requirements. Data used by mobile applications has unique security considerations. For example, how do we keep data protected if a mobile device is stolen? How do we make sure that data stored in the phone’s keychain is properly encrypted? Don’t assume that the keychain is encrypting for you, and be mindful of data, such as keychain entries, that persist even after an application is uninstalled. Understanding how data is stored on devices, but also how data is transferred to and stored in the cloud, is critical to making sure that data is secure. These requirements help us with this. It also depends on whether you are developing for Android or iOS, and OWASP provides references for both platforms in their OWASP Mobile Security Testing Guide which we will review in a later chapter. Other references that you may have already noticed from the prior page include links to an OWASP mobile top 10 list. This is a list similar to the Web Top 10 List, which we will review in the next chapter. Remaining Requirements The other requirements cover: 63 © 2020 - Cybr Cryptography Requirements Authentication and Session Management Requirements Network Communication Requirements Platform Interaction Requirements Code Quality and Build Setting Requirements Resilience Requirements Please take a look at these after completing this chapter, and as always, if you have any further questions, reach out in the forums! Once you’re ready, I’ll see you in the next chapter! Common Vulnerabilities and Attacks Just like for web applications, OWASP has created a top 10 list of security risks for mobile applications. This is an incredibly helpful starting point for building a baseline understanding of mobile application security. And as we saw in the MASVS, many of the requirement categories link to these pages since they aim to protect our mobile apps from these risks. Another helpful starting point is a 2018, NowSecure research that tested apps in the App store and Google Play store, and compiled the number of applications that their tests found to be violating at least 1 of the OWASP top 10 risks, and then breaking it down by which of the risks were most often violated. They found that 85% of apps violated at least one of these top 10 risks. 64 © 2020 - Cybr Of those apps, 50% had insecure data storage and almost the same number of apps used insecure communication. As you’ll see, those two risks are not necessarily the most difficult to protect against in mobile applications. The first step is knowing about them, and then the second step is to review and test for them. So let’s take a look at a few of these risks, starting with the first, and then moving on to the top 2 from NowSecure’s research. M1: Improper Platform Usage Each platform, whether it is Android or iOS, has a certain way of doing things. Failure to follow best practices can lead to vulnerabilities – whether in the mobile application itself or with the web services powering the mobile app. For example, if we do not properly implement TouchID security for iOS applications, it’s possible that malicious users could bypass this security mechanism to access an application – such as a banking app. This isn’t just theory, there are examples of people bypassing TouchID because it wasn’t implemented correctly. 65 © 2020 - Cybr This page helps us understand different, important, factors as they relate to Improper Platform Usage. This should look familiar to the risk and threat modeling ratings we saw in a prior chapter: We have information on Threat Agents, which are going to be application-specific. We have information on Attack Vectors, with a typical ranking of how difficult or easy it is to exploit these attack vectors related to this risk. Which, in this case, OWASP rates as EASY, with an explanation of what they are. A lot of the issues associated with the Improper Platform Usage are tied to web services, and since we went over the OWASP Top Ten Web Application Security Risks in the prior section, please refer to those chapters if you don’t remember what they are. When it comes to the Security Weakness, OWASP provides a prevalence and detectability rating. Prevalence labels this risk as being a common vulnerability in mobile applications, with an average difficulty of detecting it in your code. The Technical Impact is listed as SEVERE here, but it does depend on which vulnerability is exploited. Business Impacts, as we know, is highly dependent on the application and the business. Next, OWASP lists a few ways of figuring out whether our application is vulnerable to this risk. In this case, they list several 3 ways: 1. Violation of published guidelines – each platform has a different way of doing things and developers can sometimes cut corners to make it easier, faster, or for whatever other reason. Doing this can result in vulnerabilities. 2. Violation of convention or common practice – many tutorials or documentation can leave out important details or can be misinterpreted by the developer. The end-result is improper implementation that opens up the application to vulnerabilities. 3. Unintended Misuse – in some cases, you may be following best practices and all of your intentions were good, but maybe you missed something or introduced a bug. Following this section, they list ways of preventing improper platform usage – which in this case refers to the OWASP Web Top Ten list like we talked about. Then, they provide a helpful list of example attack scenarios so that we can see what kinds of attacks could take advantage of this risk. 66 © 2020 - Cybr Finally, there is a list of references that we can look into in order to continue researching relevant information. This is structured a bit differently than the web application risks, but it still follows a similar format which makes it easy for us to understand. Now, let’s take a look at the 2nd risk, which is the highest found violation in the NowSecure report we saw earlier. M2: Insecure Data Storage In 2014, Tinder – a very popular dating application – was sending users’ exact locations in order to figure out which users were near your location. Except the location data was not encrypted properly, and so people figured out how to find this data on their smartphones and see exactly where other users lived. Insecurely storing data can result in: Identity theft Privacy violation Fraud Reputation damage and other losses or damages …and this risk is not just relevant if someone’s phone gets stolen. It can also get exploited by malware. Just because you store something in the keychain, SQL databases, cookies, SD cards, on the cloud, or anywhere else; you can’t assume that it is being encrypted. You have to assume the opposite and plan accordingly. In the case of this risk, the exploitability of attack vectors is easy because if an attacker gets physical access to the mobile device, they can simply hook up the device to a computer and, with freely available software, they can see all third party application directories They don’t even have to have physical access to your mobile device, though. They could create malware or modify the application to send them this information. 67 © 2020 - Cybr The security weakness prevalence is COMMON and the detectability is AVERAGE. We can check that important data is being encrypted using similar tools that would be used to exploit this vuln

Introduction to Application Security PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue