“A chain is only as strong as its weakest link.” —— Thomas Reid
“Essays on the Intellectual Powers of Man” (1786)
We live in a world where we are more susceptible to cybercrimes than ever before, especially when we have social media! Cybercrime is an umbrella term referring to all the illegal activities that can be performed with a computer and network, including financial theft, theft of private assets such as sales documents and research reports, exploitation of sensitive information such as an individual’s biological data, and more. A report in 2018 quoted the revenue generated by the cybercrime industry to be $1.5 trillion, and social media enabled cybercrimes alone to have generated $3.25 billion. 1 That is unquestionably a huge amount, and sadly, it may include some of our and our friends’ hard-earned money!
Further, the numbers imply that cybercrimes are more prevalent than we would have imagined. Daily news also shows us proof that cybercrimes are not restricted just to banking or social media sites but to all kinds of websites—hotel booking, flight booking, adult dating sites get attacked too. We will discuss such real-life attacks later in the chapter to get more insights. This poses a crucial question to the software teams: What measures can we take to protect an application from such attacks?
To build a strong, secure system, the industry recommended principle is to build your defenses at depth, i.e., build security measures in multiple layers of the application and not just restrict it to only a single outer solid layer. This is analogous to how kingdoms protected themselves - with a moat, then strong iron gates, armed guards, and so on. Each layer has to be strong enough, as breaking through one layer gives access to more and more resources every time.
Also, remember the security of your system is only as strong as your weakest link—be it your internal admins or hacked passwords. Thus exploring for weak links is a crucial step in the effort to build strong impenetrable systems. And security testing is the primary activity that unveils such weak links!
Security testing is the skill to think like a hacker and identify the potential vulnerabilities, threats, and risks in the system that opens gates tocybercrimes. Professional security testers or penetration (or pen) testers have developed such a skill over many years, and they can script different attacks on the application to expose the vulnerabilities. However, you don’t have to be a pen tester to use some good automated security testing tools and techniques in your day-to-day team activities to prevent significant security issues.
Security bugs, just like any functional software bug, are incredibly costly to fix when found at later stages of the development cycle. As a result, waiting to engage pen testers until the end of the delivery cycle can leave considerable gaps in your application’s defense systems. Hence, you should practice shift-left security testing.
Indeed, the recommended best practice is to start thinking about a feature’s security aspects right from the beginning of the requirements gathering phase. For example, the requirement to hide all account transactions from anyone other than the account holder and bank administrator is an obvious and necessary security feature. Similarly, the requirement to have a two- factor authentication feature provides an additional layer of security, much like having armed guards in addition to a stone wall protecting a castle. So inculcating security best practices throughout analysis, development, and testing phases, frequently and continuously, will help you build strong, secure systems.
This chapter will cover the necessary topics needed to upskill yourself in security testing so that you can shift your security testing to the left in the delivery cycle. You will learn about real-life attacks, application vulnerabilities, STRIDE threat model, an exercise on threat modeling, a testing strategy that implements shift-left security testing, guided exercises on security testing tools and elaboration on how to integrate them in the CI to get continuous feedback on your application security.
Assets are the critical entities in the application that need to be guarded by building appropriate defense mechanisms. A security compromise happens when the defense mechanisms of the system fail to protect the assets.
Vulnerability is a term to refer to the potential gaps in your system which can be leveraged to compromise the security of the system.
Threats are the potential negative actions or events that can leverage the underlying vulnerabilities to compromise the security of your system.
An attack is performing an unauthorized malicious action on the system and compromising the security of the system.
Encryption is a technique to scramble information in such a way that only the intended recipient who has the key to decipher can understand the information.
Hashing is a technique to map any length of data to a fixed size output using algorithms. This is used to verify the authenticity of the information itself. Hashing is a one-way technique, i.e., it is hard to get back the original content. Hashes are immutable, i.e., each unique input produces the same unique output.
Here is a collation of some of the widespread attacks with real-life examples.
The easiest way to abuse a system is to exploit the publicly available data on the website, especially the user’s personal data. It’s almost equivalent to placing your valuables at your window. A web scraping attack is a method to automatically crawl a website and gather crucial information, which is further used for malicious intent. Especially, social media has a lot of personal data like the user’s location, phone numbers, and more. From the report mentioned at the beginning of the chapter, the personal data scraped from social media makes a revenue of $630 million per year.
An example of a web scraping attack is that in 2019, 419 million Facebook user records that had their phone numbers were found in an unprotected database server on the internet, as reported by TechCrunch. 2 Though Facebook had removed the feature to display phone numbers on user’s profiles by then, it seemed that the information was scraped when the feature was available. Another example of unintentional exposure of data is, in 2018, Twitter found a bug in their internal tool, which logged the passwords in plain text without hashing 3 (you never know where the weak link is!). Hence Twitter asked its 330 million users to change their passwords though fortunately, there was no evidence of compromises.
Exposed data is always an avenue for exploitation, whether it be on the website or anywhere else. When you are thinking like a hacker, you should look for such exposed data throughout your application.
If you had to guess your friend’s password, how would you go about it? You might try their date of birth, favorite color, spouse’s name, or a combination of such things, correct? When you extend the same trial and error method with a big organized list of all possible key combinations, it’s called brute force attack.
For example, the brute force attack on the AdultFriendFinder site in 2016 exposed 412 million user records with passwords and other sexual preferences. 4 It is said that the usernames and passwords were hashed using the SHA-1 cryptography algorithm in their database. With modern brute force techniques and the availability of computing power, SHA-1 failed to provide a good defense.
Social Engineering is the psychological manipulation of individuals into giving away their confidential information. You might have also received such phone calls from what seemed like a reputed company, and a friendly customer service person would have requested your credit card details in exchange of their service! You are not alone. In 2019, a UK-based energy company’s CEO was manipulated by a phone call from someone who sounded like his boss (later found out to be a trained AI program) to transfer a lump sum of $243,000 to the hacker’s account!
A phishing attack is a type of social engineering where an attacker sends a fraudulent communication to the victim in the disguise of being benevolent and resourceful with the intention to steal their personal data. Especially emails have become the prevalent medium for phishing attacks where the victim is tricked to download a malware attachment or given an illegitimate URL to pursue the communication. It would be a surprise if you didn’t receive one such email in today’s world. In 2021, Microsoft 365 users received a phishing email in the pretext of discussing price revisions with an HTML attachment — only that the attachment was scripted to abduct their authentication details on opening.
Cross-site scripting is when the attackers take advantage of an unsecured website and inject code to manipulate the application’s behavior. For instance, hackers can inject code into the website to redirect the customer’s payment details to their servers. In 2018, British Airways had a cross-site scripting attack on their website, exposing 380,000 customers’ credit card details. British Airways was fined heavily due to a lack of a proper defense system.
Ransomware attacks are where a malware blocks the system until a ransom is paid to the attacker. The Weather Channel went offline for an hour in 2019 due to a malicious ransomware attack on their network. Since they had backup servers, they were able to get past the episode successfully.
Cookie forging is a technique to manipulate the cookies that store user information on a website and get access to the user’s account. In 2016, around 32 million Yahoo! user accounts were breached by forging the cookies. It was stated that the hackers learned the internal login functionality of Yahoo! from their proprietary code and forged the cookies to gain access to accounts.
Cryptojacking has become a widespread attack these days. It is the activity of secretly mining cryptocurrencies in an unauthorized machine. Usually, bots are set to crawl the public Github repositories to find infrastructure (e.g., AWS) access keys. Once found, the instances are exploited within seconds, costing huge losses for the infrastructure owners. In 2018, Tesla Inc. was a victim of such illegal mining.
The real-life examples we discussed in the previous section elicit the attackers’ motives clearly—they seek to abuse the user’s personal data, money, infrastructure, access to services, and brand reputation. These are the primary assets that we need to protect in any application. I worked on a project where we designed the central security system for a bank. We discussed so many security threats (it was such a stand-out experience!) that could lead to a compromise of these five assets.
Similarly, when you are brainstorming the security threats for your application, you need to think of all possible threats that could compromise your application’s assets. To help you navigate the vast breadth of threats, you can adopt a threats thinking framework called the STRIDE invented by Loren Kohnfelder and Praerit Garg from Microsoft. STRIDE is an acronym for Spoofed identity, Tampering with inputs, Repudiation of actions, Information disclosure, Denial of service, and Escalation of privileges. You can take one at a time and discuss all possible threats under that category for your application.
Let’s take a closer look at each of these classifications of security threats.
Spoofed identity attacks are those where a hacker assumes the identity of an authorized person to access the assets. Recall the social engineering example from earlier where the AI impersonated the CEO’s boss’s identityto launder money. Identity thefts are prevalent and made possible by social engineering, phishing attacks, malware, and shoulder surfing (the method of spying over someone’s shoulder when they’re entering their personal information, such as a password or ATM pin), just to name a few.
Some of the defense mechanisms adopted for this type of threat are multifactor authentication, strong password recommendations, strong encryptions while storing data and while transferring credentials, and so on.
The threat of tampering with inputs involves modifying something on the application (e.g., code, data, memory, etc.), which violates integrity. This could happen by injecting malicious code, such as a script, into the UI or other layers. As we saw in the British Airways example from earlier, the hacker changed the behavior of the website by injecting scripts to get the customer’s credit card details.
The defense to this threat includes adding appropriate validations (e.g., add validations on the input fields to prevent someone from sending SQL queries), authentication and authorization mechanisms, and other standard security practices while coding to avoid vulnerabilities resulting in a code injection.
Repudiation occurs when the actions of a malicious user cannot be proved or tracked back to them. For example, a customer could deny receiving the item after delivery if there is no systemic proof. This is a critical aspect to consider while designing a functionality as it will result in loss of goods, reputation, money, and sometimes legal suits to compromise. To prevent this threat, the application should have adequate logs and auditing mechanisms to ensure non-repudiation.
The information disclosure class of threats involves unauthorized entities having access to the application’s assets. As we saw in the Twitter exampleearlier, the employees could see the exposed user passwords, which they were not supposed to have access to. The Twitter example is an unintentional consequence, and fortunately, there were no security compromises. However, such attacks to gain unauthorized information can be conducted by setting up malware to listen in the background and relay the information from a legitimate site to the hacker. This is referred to as a man-in-the-middle attack. To provide a proper defense against this kind of threat, you should build a strong authorization mechanism, encrypt all secrets, and have secure transmission protocols.
The denial of services threat deals with an attacker bringing the application’s services down, causing loss of revenue and reputation for the company. One way this threat could manifest is by a Distributed Denial of Services (DDoS) attack. The system is intentionally overloaded with millions of requests so that it becomes slow and finally starts failing. The defense to this kind of threat is to add load balancers, throttle requests per IP address, whitelisting only the relevant IP addresses, create backups for systems, auto-spin new machines on load, set up monitoring systems to alert on sudden surges in request volumes, to list a few among others.
An escalation of privileges threat happens when a malicious unauthorized user gains higher privileges than necessary to an application causing loss of private data, denial of services, loss of money, and so on. In my opinion, this is the worst kind of threat to deal with. Imagine a hacker getting super admin privileges to a system! A best practice is to follow the principle of least privilege, which is to give only the least necessary privilege to all the system’s users and nothing more. We can also apply it to our everyday activities, like granting code-committing privileges only to developers on the team and granting access to others only when necessary. Some useful defense techniques to this threat are frequent access token refreshes, multi- signature features for authorizing transactions, secrets stored in vaults, etc.After brainstorming all the security threats for your application using the STRIDE model, obviously, you need to think of solutions to prevent the threats from becoming attacks and also think of confining the impact radius of the attack, if it happens unfortunately.
In the effort towards learning to think like a hacker, we have discussed some of the widespread attacks, potential assets that hackers try to abduct, and a framework to think of all possible threats to your application. The next step is to get closer to the application code to learn about the different security vulnerabilities that can be leveraged by the threats. Understanding these vulnerabilities will help you to add defense code and test for them.
An attacker could inject malicious commands or SQL queries to alter the behavior of the website if it is unprotected. Example 7-1 shows the code to retrieve the student’s record by name.
//SQL query in the code to fetch student’s record by name
SELECT * FROM Students WHERE name = '$name'As we can see, the query takes an input $name from the user. The query is written in such a way that when a malicious user enters a SQL query to drop the table instead of a student’s name, it will work perfectly fine, as seen in Example 7-2.
//Malicious user inputs this as ‘student name’ in UI
Name: Alice'; DROP TABLE Students; --
//The application will execute this command:
SELECT * FROM Students WHERE name = 'Alice'; DROP TABLE Students; -
-'As discussed earlier, cross-site Scripting (XSS) allows attackers to execute scripts in the victim’s browser and take control of user sessions which is then used to redirect the users to malicious sites or deface websites. It is prevalent when there is no validation and proper sanitization of the user input data.
For example, a Twitter user posted a sample harmless Javascript to reveal the XSS vulnerability in the Tweetdeck application, as seen in Figure 6-3. It is a code to auto-retweet itself whenever it appears on someone’s timeline, popping an alert dialog box after. This could have been prevented if the app had properly validated the post’s text for the presence of scripts. But since the app didn’t, the browser innocently executed the script.
If an application is dependent on several third-party softwares (e.g., OS, libraries, frameworks, tools), a vulnerability in any of these could be exploited to gain access to the system. Such vulnerabilities are often found, fixed, and patches are sent for an update by the tool maintainers. But the teams do not regularly update the vulnerable components, continuing to expose the application. Tools extend assistance here. For example, Github’s Dependabot 12 offers to auto-update the dependencies with known vulnerabilities in the application code. Similarly, vulnerability scanningtools like Snyk, OWASP Dependency-check help highlight the vulnerable components.
Sometimes, authentication mechanisms in the websites are not foolproof, leaving space for attackers to steal the session tokens and exploit the privileges. If you store session IDs and sensitive user data in the session cookie, you need to refresh them very often and invalidate the older cookies. Also, you need to watch out for vulnerabilities like exposing session IDs in the URLs, using unencrypted connections to send sensitive authentication data, and so on.
Many times, we fall prey to the common vulnerability of unencrypted private data. We saw how unintentional exposure of sensitive data such as the Facebook users’ phone numbers from the example earlier resulted in exploitation. You must ensure private data is not laid open without encryption in logs, databases, code repositories, project documentations, publicly hosted services, etc. Also, choose high-end cryptographic algorithms like the AES, HMAC, SHA-256, etc., with dynamic salt and pepper techniques to help protect data in transit and rest.
It is a frequent mistake to give blanket admin permissions everywhere and for everyone using the application for no better reason other than to save themselves from maintenance efforts. Misconfiguring the relevant permissions to users, folders, systems, etc., will result in unauthorized access and escalation of privileges to application content such as the database and admin endpoints, which can be easily abused without much effort. The principle of least privilege as discussed earlier should be strictly adhered to by teams.
A common practice that leads to compromise is hardcoding the application secrets such as the environment credentials, superuser credentials, etc., in code and configuration files as plain text. An appropriate measure is to use secret management services such as the vaults and access secrets only from there. This applies to application code, CI/CD pipelines, configuration files, and all the places you might have to access secrets.
The list in this section shows a set of vulnerabilities that have to be carefully dealt with during development and testing. Open Web Application Security Project (OWASP), a community-led non-profit organization, has identified the top ten common vulnerabilities on the web, which you might be interested in reading as well.
Having come this far, you might be thinking about the security threats and vulnerabilities your application might be exposed to right now. We shall discuss a methodical approach to threat modeling, a structured way to aggregate all the potential security threats, in this section that you can apply to your application as well.
A general best practice is to do the threat modeling exercise as a recurrent activity for a small scope of the application, such as a 15-minute threat modeling exercise per user story. Once you model your security threats, you can prioritize them based on impact and probability of risk, which then can be solutionized as part of the story or as a new feature. When you prioritize the threats, use the general rule of thumb - ‘the cost of building security measures to handle a potential threat should not be higher than the value of the asset that you are trying to protect.’
For example, let’s say your team is developing a blogging platform. Before building the home page, you do a 15-minute threat modeling exercise to discover a potential threat that a ransomware attack could bring down the page. The team proposes to have a security monitoring system as a solution. The monitoring system is estimated to cost $400K per year. Do you need to fix the ransomware threat? Maybe not, as the cost to fix the threat might be higher than the profit per year for the company. Also, how often does a ransomware attack happen on a blogging platform? The probability is very low. On the other hand, a threat like a code injection attack on the website that leads to loss of credit card details can be considered a high impact and a high probability threat.
Once you have identified the prioritized threats, address the solutions in the same user story or, if needed, create abuser/evil user stories—user stories that address the solutions to prioritized threats.
For example:
“As an abusive user, I cannot inject code to redirect the content of the website.”
You can also derive security-related test cases from the threat modeling exercise and abuser stories’ acceptance criteria for development and testing purposes.
Let’s take a closer look at the framework for completing a threat modeling exercise. It is recommended to do this exercise as a team with all roles represented. Whiteboarding with colored stickies works well as you can capture your team’s thoughts and categorize them quickly. In a remote world, choose tools like Mural to conduct the exercise. Once your team is assembled, navigate through the following milestones:
The first step is to define the scope of the feature. Then, start by drawing the user flows and the different types of users or actors in the system. Once this is clear, understand the flow of data from one component to another. This way, you would have covered user flows, actors, data flow, and the integration between components in the system.
The second step is to identify the assets in the feature that need to be protected. Also, discuss the impact of losing that asset and capture the severity.
Next, open the floor for black hat thinking, where you start thinking like a hacker and come up with ways to attack the application’s assets. Here, the mindset of the team should be - ‘Let’s break the system’! Use the STRIDE model to structure this discussion. Allow the imagination to flow freely without debating if it’s really a threat or not for now and capture them all as stickies.
Analyze the probability and the impact of threats and prioritize them. Capture these as abuser stories so the team can act on them after the threat modeling brainstorming session. Now that you know the basics, get a first-hand experience by actually doing a sample threat modeling exercise.
The practices/approaches we discussed so far—conducting a 15 minutes threat modeling exercise per user story, writing abuser stories, building security measures in layers, deriving security-related test cases, and so on, will significantly help strengthen your defense systems. One more critical step is to add mechanisms to give continuous feedback on the code being developed for potential vulnerabilities so that it can be fixed at the earliest. This is where you need to think of shifting security testing to the left. We will discuss a security testing strategy that implements shift-left testing here.
Figure 6-7 shows a shift-left security testing strategy across the different stages of the path to production. Let’s discuss them one by one now.
SAST refers to the technique of analyzing the static application source code, byte code, and assembled code for known vulnerabilities. For example, it scans the application code for unencrypted secrets. SAST tools come in various forms—plugins, libraries, SaaS solutions (e.g., Snyk IDE, Checkmarx, Security code scan) and can be integrated with CI pipelines to run against every commit. SAST is a huge shift-left step as it helps discover issues during development. Further, Talisman, though not exactly a SAST tool, is specifically designed to scan the application code for secrets such as private keys, environment credentials, and so on, which can be integrated as a pre- commit hook. This prevents secrets from even being pushed to the repository. We will explore the Snyk IDE plugin and Talisman later in the chapter.
SCA is the technique that identifies the vulnerabilities in the application’s third-party dependencies. Especially when you are using a lot of open source libraries, these tools (e.g. OWASP Dependency Check, Snyk Open source) will add a lot of value. They also give feedback during development and can be integrated with CI for every commit. SCA combined with SAST will help uncover the static application code’s vulnerabilities during the development phase itself. A guided exercise on OWASP Dependency-check is included in the chapter.
Containers have become a widely adopted way to package and deploy applications. Hence testing for vulnerabilities in the container images, if you are using them, is critical. Tools like Snyk Container, Anchore, etc., can be used to do image scanning and can be integrated with CI. Dockerhas an inbuilt command docker scan to perform vulnerability scanning on docker images. Similarly, Amazon Elastic Container Registry (ECR) 18 offers image scanning capabilities for the images pushed to the ECR. When you are writing your infrastructure code using Terraform and Kubernetes, tools like Snyk Iac, terraform-compliance, etc., can be used to enforce security best practices as well.
DAST is a black-box testing technique. It finds security issues by analyzing how the application responds to specially crafted requests that mimic actual attacks. For example, DAST tools (e.g. OWASP ZAP, Burp Suite) try to inject malicious scripts into the application to check for code injection vulnerability. They can be integrated with CI pipelines too. They might take longer to run based on the application. So you can choose to integrate them as nightly regression in CI. A detailed exercise to perform DAST with OWASP ZAP is provided in the chapter.
These days, the interactive application security testing (IAST) technique tries to combine both the SAST and DAST techniques to analyze the application behavior during run time. It works through software instrumentation and scans for security vulnerabilities in real- time. This space is evolving, and some example IAST tools are Contrast security and Acunetix.
You can add automated tests using the functional automation tools, as discussed in Chapter 3, to cover the functional security test cases. For instance, in the OMS threat modeling example from earlier, the security test case: ‘system admin should not have access to edit the order’ can be added as a service test in the order service.
Also, during manual exploratory testing, derive security-related test cases from threat modeling exercises across all layers, i.e., the UI, services, DB. Chrome DevTools and Postman provide various flexibilities to execute security test cases, which we shall see in the chapter.
Based on the criticality of the application and the development team’s competency with respect to security, choose to involve a professional security tester near the end of the delivery cycle so that the application doesn’t suffer from security issues later.
Techniques like SAST and DAST discussed earlier help in figuring the vulnerabilities in the application code. But when attacks actually happen in the production environment you need a layer of defense mechanism to prevent the attack from being successful. RASP 20 is that kind of security technique, which monitors the application for potential attacks in the production environment and prevents them from happening. It extends the traditional firewall concept further by working within the application runtime and building a knowledge of what is and not an expected application behavior. Based on that, the RASP tools (e.g., Twistlock, Aqua Security) listens to the application processes at runtime and automatically takes protective measures. For example, it automatically terminates crypto mining processes when it finds one, it examines incoming request payloads and denies them if they are malicious, and it helps prevent malware attacks beyond the anti-virus software protection. RASP tools are currently available only as paid products.
That’s shifting security testing throughout the delivery cycle and in production. We shall see how some of these tools can be applied in practice in the coming sections.
One of my observations from experience is that we might shell out our ultimate efforts in all the activities discussed till now to create secure software, but unless we make security a habit, we might still leave unexpected weak links that could be exploited. Infact, several day-to-day practices in a software team could lead to a security compromise. For example, have you thought about the security aspects of the tools that you use to assist in development and testing? Is it storing project data in their private cloud? Are you leaving the architecture diagram of the project with environment details in an online portal? Did you share the production system credentials with all your team members? Was it shared in Slack in plain text? And many, many such simple acts could result in a compromise very easily.
Therefore making security a habit is the only way forward. It is the same as how we analyze a food item before eating it or become conscious when someone is following us. We do those checks unconsciously and naturally. Similarly, we, as software teams, should train ourselves to make security an unconscious and natural habit. Let’s start by questioning ourselves on a daily basis if our simple, unintentional, harmless act could result in a security breach!
Cybercrimes in the digital era are more prevalent than we would imagine, producing a revenue of $1.5 trillion to the underworld.
The real life attacks show us that all sorts of digital platforms are hacked with the intention to steal money, private data, infrastructure and so on. So, clearly, security is not anymore a ‘nice-to-have’ feature.
Security measures should be built-in the application starting from analysis to testing throughout the SDLC in order to achieve the goal of building strong impenetrable systems.
The STRIDE model gives a structured lens to explore security threats for an application, which can be applied to perform threat modeling for the application.
Threat modeling exercises have to be done frequently with the entire team for small portions of application functionalities, such as a user story and a feature. Threat modeling should result in creating abuser stories and security-related test cases.
Deploy shift-left security testing strategies using various types (SAST, SCA, DAST, etc.) of automated security testing tools apart from manual exploratory and functional automated testing.
With the availability of such automated security testing tools, software teams don’t have to wait for penetration testing as the only way to receive feedback on security issues.
Most importantly, make security a habit.