OWASP API Security Top 10 THM

 INTRODUCTION

OWASP - Open Web Application Security Project (OWASP) is a non-profit and collaborative online community that aims to improve application security via a set of security principles, articles, documentation etc. Back in 2019, OWASP released a list of the top 10 API vulnerabilities, which will be discussed in detail, along with its potential impact and a few effective mitigation measures. 

We have split this room into two parts. In Part 1, you will study the top 5 principles, and in Part 2, you will learn the remaining principles.

Learning Objectives

• Best practices for API authorisation & authentication.
• Identification of authorisation level issues.
• Handling excessive data exposure.
• Lack of resources and rate-limiting issues.

Learning Pre-requisites
An understanding of the following topics is recommended before starting the room:

• How websites work.
• HTTP protocols & methods.
• Principles of security.
• OWASP top 10 web vulnerabilities.

Connecting to the Machine
We will be using Windows as a development/test machine along with Talend API Tester - free edition throughout the room with the following credentials:

• Machine IP:  MACHINE_IP 
• Username:   Administrator
• Password:    Owasp@123

You can start the virtual machine by clicking Start Machine. The machine will start in a split-screen view. In case the VM is not visible, use the blue Show Split View button at the top-right of the page. Alternatively, you can connect with the VM through Remote Desktop using the above credentials. Please wait 1-2 minutes after the system boots completely to let the auto scripts run successfully that will execute Talend API Tester and Laravel-based web application automatically.

Let's begin!

Answer the questions below

I can connect and log in to the machine.

Understanding APIs - A refresher

What is an API & Why is it important?

API stands for Application Programming Interface. It is a middleware that facilitates the communication of two software components utilising a set of protocols and definitions. In the API context, the term 'application' refers to any software having specific functionality, and 'interface' refers to the service contract between two apps that make communication possible via requests and responses. The API documentation contains all the information on how developers have structured those responses and requests. The significance of APIs to app development is in just a single sentence, i.e., API is a building block for developing complex and enterprise-level applications.

Recent Data Breaches through APIs

• LinkedIn data breach: In June 2021, the data of over 700 million LinkedIn users were offered for sale on one of the dark web forums, which was scraped by exploiting the LinkedIn API. The hacker published a sample of 1 million records to confirm the legitimacy of the LinkedIn breach, containing full names of the users, email addresses, phone numbers, geolocation records, LinkedIn profile links, work experience information, and other social media account details. 
• Twitter data breach: In June 2022, data of more than 5.4 Million Twitter users was released for sale on the dark web. Hackers conducted the breach by exploiting a zero-day in the Twitter API that showed Twitter's handle against a mobile number or email.
• PIXLR data breach: In January 2021, PIXLR, an online photo editor app, suffered a data breach that impacted around 1.9 million users. All the data by the hackers was dumped on a dark web forum, which included usernames, email addresses, countries, and hashed passwords. 

Now that we understand the threat and the damage caused due to non-adherence to mitigation measures - let's discuss developing a secure API through OWASP API Security Top 10 principles.

Answer the questions below

In the LinkedIn breach (Jun 2021), how many million records (sample) were posted by a hacker on the dark web?

Is the API documentation a trivial item and not used after API development (yea/nay)?

I understand the APIs and am ready to learn OWASP Top 10 Principles.

Vulnerability I - Broken Object Level Authorisation (BOLA)

How does it Happen?

Generally, API endpoints are utilised for a common practice of retrieving and manipulating data through object identifiers. BOLA refers to Insecure Direct Object Reference (IDOR) - which creates a scenario where the user uses the input functionality and gets access to the resources they are not authorised to access. In an API, such controls are usually implemented through programming in Models (Model-View-Controller Architecture) at the code level.

Likely Impact

The absence of controls to prevent unauthorised object access can lead to data leakage and, in some cases, complete account takeover. User's or subscribers' data in the database plays a critical role in an organisation's brand reputation; if such data is leaked over the internet, that may result in substantial financial loss.

Practical Example

• Open the VM. You will find that the Chrome browser and Talend API Tester application are running automatically, which we will be using for debugging the API endpoints.
• Bob is working as an API developer in Company MHT and developed an endpoint /apirule1/users/{ID} that will allow other applications or developers to request information by sending an employee ID. In the VM, you can request results by sending GET requests to http://localhost:80/MHT/apirule1_v/user/1.

• What is the issue with the above API call? The problem is that the endpoint is not validating any incoming API call to confirm whether the request is valid. It is not checking for any authorisation whether the person requesting the API call can ask for it or not.
  
• The solution for this problem is pretty simple; Bob will implement an authorisation mechanism through which he can identify who can make API calls to access employee ID information.
  
• The purpose is achieved through access tokens or authorisation tokens in the header. In the above example, Bob will add an authorisation token so that only headers with valid authorisation tokens can make a call to this endpoint.
• In the VM, if you add a valid Authorization-Token and call http://localhost:80/MHT/apirule1_s/user/1, only then will you be able to get the correct results. Moreover, all API calls with an invalid token will show 403 Forbidden an error message (as shown below).
  

Mitigation Measures

• An authorisation mechanism that relies on user policies and hierarchies should be adequately implemented. 
• Strict access controls methods to check if the logged-in user is authorised to perform specific actions. 
• Promote using completely random values (strong encryption and decryption mechanism) for nearly impossible-to-predict tokens.

Answer the questions below

Suppose the employee ID is an integer with incrementing value. Can you check through the vulnerable API endpoint the total number of employees in the company?

What is the flag associated with employee ID 2?

What is the username of employee ID 3?

Broken Object Level Authorization (BOLA) is a security vulnerability that affects web applications that use an access control mechanism based on object level authorization. In essence, BOLA occurs when a web application does not correctly enforce access control for objects such as files, database records, or other resources.

BOLA can occur in a number of ways, such as when an attacker is able to manipulate an object's ID or other identifying attributes, when the application does not validate access control requests properly, or when an application fails to enforce access control consistently across all resources.

The consequences of a BOLA vulnerability can be severe, as it can allow an attacker to access sensitive data or functionality that they should not have access to. For example, an attacker could use a BOLA vulnerability to access another user's private data or to gain administrative access to a system.

To prevent BOLA vulnerabilities, web application developers should implement proper access control mechanisms that are based on the principle of least privilege, validate all input data, and consistently enforce access control across all resources. Additionally, regular security testing and code reviews can help to identify and remediate BOLA vulnerabilities before they can be exploited.

Vulnerability II - Broken User Authentication (BUA)

How does it happen?

User authentication is the core aspect of developing any application containing sensitive data. Broken User Authentication (BUA) reflects a scenario where an API endpoint allows an attacker to access a database or acquire a higher privilege than the existing one. The primary reason behind BUA is either invalid implementation of authentication like using incorrect email/password queries etc., or the absence of security mechanisms like authorisation headers, tokens etc.

Consider a scenario in which an attacker acquires the capability to abuse an authentication API; it will eventually result in data leaks, deletion, modification, or even the complete account takeover by the attacker. Usually, hackers have created special scripts to profile, enumerate users on a system and identify authentication endpoints. A poorly implemented authentication system can lead any user to take on another user's identity. 

Likely Impact 

In broken user authentication, attackers can compromise the authenticated session or the authentication mechanism and easily access sensitive data. Malicious actors can pretend to be someone authorised and can conduct an undesired activity, including a complete account takeover. 

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
• Bob understands that authentication is critical and has been tasked to develop an API endpoint apirule2/user/login_v that will authenticate based on provided email and password.
• The endpoint will return a token, which will be passed as an Authorisation-Token header (GET request) to apirule2/user/details to show details of the specific employee. Bob successfully developed the login endpoint; however, he only used email to validate the user from the user table and ignored the password field in the SQL query. An attacker only requires the victim's email address to get a valid token or account takeover.
•  In the VM, you can test this by sending a POST request to http://localhost:80/MHT/apirule2/user/login_v with email and password in the form parameters.

• As we can see, the vulnerable endpoint received a token which can be forwarded to /apirule2/user/details to get detail of a user.
• To fix this, we will update the login query logic and use both email and password for validation. The endpoint /apirule2/user/login_s is a valid endpoint, as shown below, that authorises the user based on password and email both.

Mitigation Measures 

• Ensure complex passwords with higher entropy for end users.
• Do not expose sensitive credentials in GET or POST requests.
• Enable strong JSON Web Tokens (JWT), authorisation headers etc.
• Ensure the implementation of multifactor authentication (where possible), account lockout, or a captcha system to mitigate brute force against particular users. 
• Ensure that passwords are not saved in plain text in the database to avoid further account takeover by the attacker. 

Answer the questions below

Can you find the token of hr@mht.com?

To which country does sales@mht.com belong?

Is it a good practice to send a username and password in a GET request (yea/nay)?

Broken User Authentication (BUA) is a type of security vulnerability that occurs when an application does not properly authenticate users before granting access to sensitive data or functionality. This can happen due to various reasons, such as weak password policies, weak encryption algorithms, session hijacking, or other forms of attacks that can compromise the authentication mechanism.

If an attacker successfully exploits a BUA vulnerability, they can gain unauthorized access to sensitive data or perform actions on behalf of another user without their consent. This can lead to data theft, unauthorized modification or deletion of data, or other malicious activities.

To prevent BUA vulnerabilities, developers should implement strong authentication mechanisms that use secure password policies, multi-factor authentication, and encryption algorithms that cannot be easily cracked. Additionally, applications should regularly check the validity of user sessions and prevent unauthorized access attempts.

It is also important to regularly test and review the application's authentication mechanisms to identify any weaknesses that may exist and to address them in a timely manner. By following these best practices, developers can significantly reduce the risk of BUA vulnerabilities in their applications.

Vulnerability III - Excessive Data Exposure

How does it happen?

Excessive data exposure occurs when applications tend to disclose more than desired information to the user through an API response. The application developers tend to expose all object properties (considering the generic implementations) without considering their sensitivity level. They leave the filtration task to the front-end developer before it is displayed to the user. Consequently, an attacker can intercept the response through the API and quickly extract the desired confidential data. The runtime detection tools or the general security scanning tools can give an alert on this kind of vulnerability. However, it cannot differentiate between legitimate data that is supposed to be returned or sensitive data. 

Likely Impact 

A malicious actor can successfully sniff the traffic and easily access confidential data, including personal details, such as account numbers, phone numbers, access tokens and much more. Typically, APIs respond with sensitive tokens that can be later on used to make calls to other critical endpoints.

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
  
• The company MHT launched a comment-based web portal that takes users' comments and stores them in the database and other information like location, device info, etc., to improve the user experience.
  
• Bob was tasked to develop an endpoint for showing users' comments on the company's main website. He developed an endpoint apirule3/comment_v/{id} that fetches all information available for a comment from the database. Bob assumed that the front-end developer would filter out information while showing it on the company's main website.

• What is the issue here? The API is sending more data than desired. Instead of relying on a front-end engineer to filter out data, only relevant data must be sent from the database.
• Bob realising his mistake, updated the endpoint and created a valid endpoint /apirule3/comment_s/{id} that returns only the necessary information to the developer (as shown below).

Mitigation Measures 

• Never leave sensitive data filtration tasks to the front-end developer. 
• Ensure time-to-time review of the response from the API to guarantee it returns only legitimate data and checks if it poses any security issue. 
• Avoid using generic methods such as to_string() and to_json(). 
• Use API endpoint testing through various test cases and verify through automated and manual tests if the API leaks additional data.

Answer the questions below

What is the device ID value for post-ID 2?

What is the username value for post-ID 3?

Should we use network-level devices for controlling excessive data exposure instead of managing it through APIs (programmatically) - (yea/nay)?

 

Excessive data exposure is a type of security vulnerability that occurs when an application exposes more data than necessary, leaving it vulnerable to unauthorized access or disclosure. This can happen due to various reasons, such as misconfigured permissions, lack of encryption, or inadequate access controls.

If an attacker successfully exploits an excessive data exposure vulnerability, they can gain access to sensitive data such as personally identifiable information (PII), financial information, or other confidential data. This can lead to identity theft, financial fraud, or other malicious activities.

To prevent excessive data exposure, developers should implement strict access controls and encryption mechanisms to protect sensitive data. This includes using strong authentication mechanisms, access control policies, and encryption techniques to ensure that data is protected both during transmission and storage.

Developers should also review their code to ensure that it does not inadvertently expose data or provide unnecessary access to resources. Regular vulnerability scanning and penetration testing can help to identify any weaknesses in the application's data handling and access controls and help to remediate them before they can be exploited.

In summary, excessive data exposure can have serious consequences for both the application and its users. Developers must implement strict security measures to protect sensitive data and regularly review and test their code to identify and remediate any vulnerabilities that could lead to data exposure.

Vulnerability IV - Lack of Resources & Rate Limiting

How does it happen?

Lack of resources and rate limiting means that APIs do not enforce any restriction on the frequency of clients' requested resources or the files' size, which badly affects the API server performance and leads to the DoS (Denial of Service) or non-availability of service. Consider a scenario where an API limit is not enforced, thus allowing a user (usually an intruder) to upload several GB files simultaneously or make any number of requests per second. Such API endpoints will result in excessive resource utilisation in network, storage, compute etc.

Nowadays, attackers are using such attacks to ensure the non-availability of service for an organisation, thus tarnishing the brand reputation through increased downtime. A simple example is non-compliance with the Captcha system on the login form, allowing anyone to make numerous queries to the database through a small script written in Python.

Likely Impact 

The attack primarily targets the Availability principles of security; however, it can tarnish the brand's reputation and cause financial loss.

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
  
• The company MHT purchased an email marketing plan (20K emails per month) for sending marketing, password recovery emails etc. Bob realised that he had successfully developed a login API, but there must be a "Forgot Password" option that can be used to recover an account.
  
• He started building an endpoint /apirule4/sendOTP_v that will send a 4-digit numeric code to the user's email address. An authenticated user will use that One Time Password (OTP) to recover the account.

• What is the issue here? Bob has not enabled any rate limiting in the endpoint. A malicious actor can write a small script and brute force the endpoint, sending many emails in a few seconds and using the company's recently purchased email marketing plan (financial loss).
• Finally, Bob came up with an intelligent solution (/apirule4/sendOTP_s) and enabled rate limiting such that the user has to wait 2 minutes to request an OTP token again.

Mitigation Measures 

• Ensure using a captcha to avoid requests from automated scripts and bots.
• Ensure implementation of a limit, i.e., how often a client can call an API within a specified time and notify instantly when the limit is exceeded. 
• Ensure to define the maximum data size on all parameters and payloads, i.e., max string length and max number of array elements.

Answer the questions below

Can rate limiting be carried out at the network level through firewall etc. (yea/nay)?

What is the HTTP response code when you send a POST request to /apirule4/sendOTP_s using the email address hr@mht.com?

What is the "msg key" value after an HTTP POST request to /apirule4/sendOTP_s using the email address sale@mht.com?

Lack of resources and rate limiting are two distinct security vulnerabilities, but they can often be related to each other.

Lack of resources refers to a vulnerability that occurs when an application does not have the necessary resources to handle requests from multiple users or to perform necessary security checks. This can happen due to various reasons, such as insufficient server capacity, limited bandwidth, or other resource constraints. If an attacker successfully exploits a lack of resources vulnerability, they can overwhelm the application with requests or launch a denial of service (DoS) attack, which can cause the application to crash or become unavailable.

Rate limiting, on the other hand, is a security mechanism that limits the rate at which requests can be sent to an application, helping to prevent DoS attacks and other malicious activities. By controlling the rate at which requests are processed, rate limiting can prevent attackers from overwhelming an application's resources and can help to ensure that the application remains available to legitimate users.

To prevent lack of resources and rate limiting vulnerabilities, developers should implement security controls that ensure that an application has adequate resources to handle requests from multiple users and can effectively control the rate at which requests are processed. This includes implementing scalable architectures, optimizing performance, and implementing rate limiting mechanisms that are configured to prevent abuse while allowing legitimate traffic.

In addition to these measures, developers should regularly review their code and infrastructure to identify any weaknesses that may exist and to address them in a timely manner. This can help to prevent lack of resources and rate limiting vulnerabilities from being exploited by attackers and ensure the availability and security of the application.

Vulnerability V - Broken Function Level Authorisation

How does it happen?

Broken Function Level Authorisation reflects a scenario where a low privileged user (e.g., sales) bypasses system checks and gets access to confidential data by impersonating a high privileged user (Admin). Consider a scenario of complex access control policies with various hierarchies, roles, and groups and a vague separation between regular and administrative functions leading to severe authorisation flaws. By taking advantage of these issues, the intruders can easily access the unauthorised resources of another user or, most dangerously – the administrative functions. 

Broken Function Level Authorisation reflects IDOR permission, where a user, most probably an intruder, can perform administrative-level tasks. APIs with complex user roles and permissions that can span the hierarchy are more prone to this attack. 

Likely Impact 

The attack primarily targets the authorisation and non-repudiation principles of security. Broken Functional Level Authorisation can lead an intruder to impersonate an authorised user and let the malicious actor get administrative rights to perform sensitive tasks. 

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
  
• Bob has been assigned another task to develop an admin dashboard for company executives so that they can view all employee's data and perform specific tasks.
  
• Bob developed an endpoint /apirule5/users_v to fetch data of all employees from the database. To add protection, he added another layer to security by adding a special header isAdmin in each request. The API only fetches employee information from the database if isAdmin=1 and Authorization-Token are correct. The authorisation token for HR user Alice is YWxpY2U6dGVzdCFAISM6Nzg5Nzg=.

• We can see that Alice is a non-admin user (HR) but can see all employee's data by setting custom requests to the endpoint with isAdmin value = 1. 
• The issue can be resolved programmatically by implementing correct authorisation rules and checking the functional roles of each user in the database during the query. Bob implemented another endpoint  /apirule5/users_s that validates each user's role and only shows employees' data if the role is Admin.

Mitigation Measures 

• Ensure proper design and testing of all authorisation systems and deny all access by default. 
• Ensure that the operations are only allowed to the users belonging to the authorised group. 
• Make sure to review API endpoints against flaws regarding functional level authorisation and keep in mind the apps and group hierarchy's business logic. 

Answer the questions below

What is the mobile number for the username Alice?

Is it a good practice to send isAdmin value through the hidden fields in form requests - yea/nay?

What is the address flag of username admin?

Broken Function Level Authorization (BFLA) is a security vulnerability that occurs when an application improperly enforces access controls at the function or operation level. This can happen due to various reasons, such as insufficient validation of user input, lack of proper authentication, or inadequate access control policies.

If an attacker successfully exploits a BFLA vulnerability, they can gain access to specific functions or operations that they should not have access to, which can allow them to perform unauthorized actions or access sensitive data.

To prevent BFLA vulnerabilities, developers should implement proper access control mechanisms that are based on the principle of least privilege. This means that users should only be granted access to the specific functions or operations that they need to perform their job functions and nothing more.

Developers should also implement proper authentication mechanisms to ensure that users are who they claim to be and validate all user input to prevent injection attacks. It is also important to regularly test the application for BFLA vulnerabilities and to ensure that all access control policies are consistently enforced across all functions and operations.

In addition to these measures, developers should follow secure coding practices to minimize the risk of BFLA vulnerabilities. This includes properly sanitizing input data, using parameterized queries, and avoiding the use of insecure coding practices such as hardcoding credentials or relying on client-side validation.

By following these best practices, developers can significantly reduce the risk of BFLA vulnerabilities in their applications and ensure that only authorized users are able to access sensitive functions or operations.

Vulnerability VI - Mass Assignment

How does it happen?

Mass assignment reflects a scenario where client-side data is automatically bound with server-side objects or class variables. However, hackers exploit the feature by first understanding the application's business logic and sending specially crafted data to the server, acquiring administrative access or inserting tampered data. This functionality is widely exploited in the latest frameworks like Laravel, Code Ignitor etc.

Consider a user's profiles dashboard where users can update their profile like associated email, name, address etc. The username of the user is a read-only attribute and cannot be changed; however, a malicious actor can edit the username and submit the form. If necessary filtration is not enabled on the server side (model), it will simply insert/update the data in the database. 

Likely Impact 

The attack may result in data tampering and privilege escalation from a regular user to an administrator. 

Practical Example

• Open the VM. You will find that the Chrome browser and Talend API Tester application are running automatically, which we will be using for debugging the API endpoints.
  
• Bob has been assigned to develop a signup API endpoint /apirule6/user that will take a name, username and password as input parameters (POST). The user's table has a credit column with a default value of 50. Users will upgrade their membership to have a larger credit value.
• Bob has successfully designed the form and used the mass assignment feature in Laravel to store all the incoming data from the client side to the database (as shown below).

• What is the problem here? Bob is not doing any filtering on the server side. Since using the mass assignment feature, he is also inserting credit values in the database (malicious actors can update that value).
  
• The solution to the problem is pretty simple. Bob must ensure necessary filtering on the server side (apirule6/user_s) and ensure that the default value of credit should be inserted as 50, even if more than 50 is received from the client side (as shown below). 

Mitigation Measures 

• Before using any framework, one must study how the backend insertions and updates are carried out. In the Laravel framework, fillable and guarded arrays mitigate the above-mentioned scenarios. 
• Avoid using functions that bind an input from a client to code variables automatically.
• Allowlist those properties only that need to get updated from the client side. 

Answer the questions below

Is it a good practice to blindly insert/update user-provided data in the database (yea/nay)?

Using /apirule6/user_s, insert a record in the database using the credit value as 1000.

What would be the returned credit value after performing Question#2?

Mass assignment is a security vulnerability that occurs when an application allows an attacker to set or modify the values of attributes or parameters of an object through a single request. This can happen when developers use frameworks or libraries that allow mass assignment without proper validation or filtering of user input.

If an attacker successfully exploits a mass assignment vulnerability, they can modify or add attributes that they should not have access to, which can lead to unauthorized access, data leakage, or other malicious activities.

To prevent mass assignment vulnerabilities, developers should implement proper input validation and filtering mechanisms to ensure that only authorized attributes can be modified or added. This includes implementing a whitelist or blacklist approach to control which attributes can be modified or added by users.

Developers should also avoid using frameworks or libraries that allow mass assignment by default or provide mechanisms to disable mass assignment if necessary. Additionally, developers should follow secure coding practices to prevent other vulnerabilities, such as SQL injection and cross-site scripting (XSS), which can also lead to unauthorized access and data leakage.

In addition to these measures, developers should regularly review their code and infrastructure to identify any weaknesses that may exist and to address them in a timely manner. This can help to prevent mass assignment vulnerabilities from being exploited by attackers and ensure the confidentiality and integrity of the application's data.

Vulnerability VII - Security Misconfiguration

How does it happen?

Security misconfiguration depicts an implementation of incorrect and poorly configured security controls that put the security of the whole API at stake. Several factors can result in security misconfiguration, including improper/incomplete default configuration, publically accessible cloud storage, Cross-Origin Resource Sharing (CORS), and error messages displayed with sensitive data. Intruders can take advantage of these misconfigurations to perform detailed reconnaissance and get unauthorised access to the system. 

Security misconfigurations are usually detected by vulnerability scanners or auditing tools and thus can be curtailed at the initial level. API documentation, a list of endpoints, error logs etc., must not be publically accessible to ensure safety against security misconfigurations. Typically, companies deploy security controls like web application firewalls, which are not configured to block undesired requests and attacks.

Likely Impact 

Security misconfiguration can give intruders complete knowledge of API components. Firstly, it allows intruders to bypass security mechanisms. Stack trace or other detailed errors can provide the malicious actor access to confidential data and essential system details, further aiding the intruder in profiling the system and gaining entry.  

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
  
• The company MHT is facing serious server availability issues. Therefore, they assigned Bob to develop an API endpoint /apirule7/ping_v (GET) that will share details regarding server health and status.
• Bob successfully designed the endpoint; however, he forgot to implement any error handling to avoid any information leakage.

• What is the issue here? In case of an unsuccessful call, the server sends a complete stack trace in response, containing function names, controller and route information, file path etc. An attacker can use the information for profiling and preparing specific attacks on the environment.
  
• The solution to the issue is pretty simple. Bob will create an API endpoint /apirule7/ping_s that will carry out error handling and only share desired information with the user (as shown below).

Mitigation Measures 

• Limit access to the administrative interfaces for authorised users and disable them for other users. 
• Disable default usernames and passwords for public-facing devices (routers, Web Application Firewall etc.).
• Disable directory listing and set proper permissions for every file and folder. 
• Remove unnecessary pieces of code snippets, error logs etc. and turn off debugging while the code is in production.

Answer the questions below

Is it an excellent approach to show error logs from the stack trace to general visitors (yea/nay)?

Try to use the API call /apirule7/ping_s in the attached VM.

What is the HTTP response code?

What is the Error ID number in the HTTP response message?

Security misconfiguration is a security vulnerability that occurs when an application is configured with settings that are not secure or when security controls are not properly implemented or maintained. This can happen due to various reasons, such as default configurations that are not secure, outdated or unsupported software, or human error.

If an attacker successfully exploits a security misconfiguration vulnerability, they can gain unauthorized access to sensitive data or resources, execute malicious code, or disrupt the normal operation of the application.

To prevent security misconfiguration vulnerabilities, developers should implement secure configurations for all components of the application, including the operating system, web server, database server, and any other components that are used. This includes disabling or removing unnecessary features, enabling secure settings, and properly configuring access controls and permissions.

Developers should also regularly review and update all components of the application to ensure that they are running the latest, most secure version of the software. This includes applying security patches and updates as soon as they become available.

In addition to these measures, developers should regularly perform security audits and vulnerability assessments to identify any weaknesses or misconfigurations that may exist and to address them in a timely manner. This can help to prevent security misconfiguration vulnerabilities from being exploited by attackers and ensure the confidentiality, integrity, and availability of the application and its data.

Overall, proper security configuration and maintenance are critical to ensuring the security and protection of an application and its users. Developers must take proactive measures to identify and address security misconfigurations and regularly review and update all components to ensure the security of the application.

Vulnerability VIII - Injection

How does it happen?

Injection attacks are probably among the oldest API/web-based attacks and are still being carried out by hackers on real-world applications. Injection flaws occur when user input is not filtered and is directly processed by an API; thus enabling the attacker to perform unintended API actions without authorisation. An injection may come from Structure Query Language (SQL), operating system (OS) commands, Extensible Markup Language (XML) etc. Nowadays, frameworks offer functionality to protect against this attack through automatic sanitisation of data; however, applications built in custom frameworks like core PHP are still susceptible to such attacks. 

Likely Impact 

Injection flaws may lead to information disclosure, data loss, DoS, and complete account takeover. The successful injection attacks may also cause the intruders to access the sensitive data or even create new functionality and perform remote code execution. 

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
  
• A few users of company MHT reported that their account password had changed, and they could not further log in to their original account. Consequently, the dev team found that Bob had developed a vulnerable login API endpoint /apirule8/user/login_v that is not filtering user input.
  
• A malicious attacker requires the username of the target, and for the password, they can use the payload ' OR 1=1--' and get an authorisation key for any account (as shown below).

• Bob immediately realised his mistake; he updated the API endpoint to /apirule8/user/login_s and used parameterised queries and built-in filters of Laravel to sanitise user input.
• As a result, all malicious payloads on username and password parameters were effectively mitigated (as shown below)

Mitigation Measures

• Ensure to use a well-known library for client-side input validation.
• If a framework is not used, all client-provided data must be validated first and then filtered and sanitised. 
• Add necessary security rules to the Web Application Firewall (WAF). Most of the time, injection flaws can be mitigated at the network level.
• Make use of built-in filters in frameworks like Laravel, Code Ignitor etc., to validate and filter data. 

Answer the questions below

Can injection attacks be carried out to extract data from the database (yea/nay)?

Can injection attacks result in remote code execution (yea/nay)?

What is the HTTP response code if a user enters an invalid username or password?

Injection is a security vulnerability that occurs when an attacker is able to inject malicious code into an application. This can happen through various input vectors, such as user input fields, query parameters, or HTTP headers.

If an attacker successfully exploits an injection vulnerability, they can execute arbitrary code, access sensitive data, or take control of the application or underlying systems.

There are several types of injection attacks, including:

1. SQL injection: This occurs when an attacker injects malicious SQL commands into an application's database query.

2. Cross-site scripting (XSS): This occurs when an attacker injects malicious JavaScript code into an application's response, which can be executed by unsuspecting users.

3. Command injection: This occurs when an attacker injects malicious system commands into an application's input fields, which can be executed by the underlying system.

To prevent injection vulnerabilities, developers should implement proper input validation and sanitization mechanisms to ensure that user input is properly filtered and formatted. This includes using parameterized queries and stored procedures to prevent SQL injection, encoding user input to prevent XSS attacks, and using input validation libraries to prevent command injection.

Developers should also regularly test their applications for injection vulnerabilities and implement measures to prevent them, such as input validation, output encoding, and firewall rules to block known injection attacks.

In addition to these measures, developers should follow secure coding practices to minimize the risk of injection vulnerabilities. This includes using secure coding practices such as avoiding the use of user-supplied input in system commands or queries, validating all input data, and minimizing the use of third-party libraries that may contain vulnerabilities.

By following these best practices, developers can significantly reduce the risk of injection vulnerabilities in their applications and ensure that user input is properly validated and sanitized, and the application is protected from malicious code injection attacks.

Vulnerability IX - Improper Assets Management

How does it happen?

Inappropriate Asset Management refers to a scenario where we have two versions of an API available in our system; let's name them APIv1 and APIv2. Everything is wholly switched to APIv2, but the previous version, APIv1, has not been deleted yet. Considering this, one might easily guess that the older version of the API, i.e., APIv1, doesn't have the updated or the latest security features. Plenty of other obsolete features of APIv1 make it possible to find vulnerable scenarios, which may lead to data leakage and server takeover via a shared database amongst API versions.

It is essentially about not properly tracking API endpoints. The potential reasons could be incomplete API documentation or absence of compliance with the Software Development Life Cycle. A properly maintained, up-to-date API inventory and proper documentation are more critical than hardware-based security control for an organisation.

Likely Impact 

The older or the unpatched API versions can allow the intruders to get unauthorised access to confidential data or even complete control of the system. 

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
  
• During API development, the company MHT has developed different API versions like v1 and v2. The company ensured to use the latest versions and API calls but forgot to remove the old version from the server.
  
• Consequently, it was found that old API calls like apirule9/v1/user/login return more information like balance, address etc., against the user (as shown below).

• Bob being the developer of the endpoint, realised that he must immediately deactivate old and unused assets so that users can only access limited and desired information from the new endpoint /apirul9/v2/user/login (as shown below)

Mitigation Measures 

• Access to previously developed sensitive and deprecated API calls must be blocked at the network level.
• APIs developed for R&D, QA, production etc., must be segregated and hosted on separate servers.
• Ensure documentation of all API aspects, including authentication, redirects, errors, CORS policy, and rate limiting. 
• Adopt open standards to generate documentation automatically.

Answer the questions below

Is it good practice to host all APIs on the same server (yea/nay)?

Make an API call to /apirule9/v1/user/login using the username "Alice" and password "##!@#!!".

What is the amount of balance associated with user Alice?

What is the country of the user Alice?

 

Improper assets management is a security vulnerability that occurs when an application does not properly manage or protect its digital assets, such as sensitive data, configuration files, credentials, or encryption keys. This can happen due to various reasons, such as improper storage, insufficient access controls, or lack of encryption.

If an attacker successfully exploits an improper assets management vulnerability, they can gain unauthorized access to sensitive data or resources, execute malicious code, or disrupt the normal operation of the application.

To prevent improper assets management vulnerabilities, developers should implement proper security controls for all digital assets, including encryption, access controls, and secure storage mechanisms. This includes using encryption to protect sensitive data both in transit and at rest, implementing access controls and permissions to limit who can access digital assets, and storing digital assets in secure locations that are protected from unauthorized access.

Developers should also regularly review and update all digital assets to ensure that they are properly protected and secured. This includes regularly changing passwords and encryption keys, using two-factor authentication, and performing regular security audits and vulnerability assessments.

In addition to these measures, developers should follow secure coding practices to minimize the risk of improper assets management vulnerabilities. This includes avoiding hardcoding sensitive information in the source code, avoiding the use of weak encryption algorithms, and minimizing the use of third-party libraries that may contain vulnerabilities.

Overall, proper assets management is critical to ensuring the security and protection of an application and its users. Developers must take proactive measures to identify and address improper assets management vulnerabilities and regularly review and update all digital assets to ensure the security of the application.

Vulnerability X - Insufficient Logging & Monitoring

How does it happen?

Insufficient logging & monitoring reflects a scenario when an attacker conducts malicious activity on your server; however, when you try to track the hacker, there is not enough evidence available due to the absence of logging and monitoring mechanisms. Several organisations only focus on infrastructure logging like network events or server logging but lack API logging and monitoring. Information like the visitor's IP address, endpoints accessed, input data etc., along with a timestamp, enables the identification of threat attack patterns. If logging mechanisms are not in place, it would be challenging to identify the attacker and their details. Nowadays, the latest web frameworks can automatically log requests at different levels like error, debug, info etc. These errors can be logged in a database or file or even passed to a SIEM solution for detailed analysis.

Likely Impact 

Inability to identify attacker or hacker behind the attack. 

Practical Example

• Continue to use the Chrome browser and Talend API Tester for debugging in the VM.
  
• In the past, the company MHT has been susceptible to multiple attacks, and the exact culprit behind the attacks could not be identified. Therefore, Bob was assigned to make an API endpoint /apirule10/logging (GET) that will log users' metadata (IP address, browser version etc.) and save it in the database as well (as shown below).
  

• Later, it was also decided that the same would be forwarded to a SIEM solution for correlation and analysis.

Mitigation Measures 

• Ensure use of the Security Information and Event Management (SIEM) system for log management. 
• Keep track of all denied accesses, failed authentication attempts, and input validation errors, using a format imported by SIEM and enough detail to identify the intruder.
• Handle logs as sensitive data and ensure their integrity at rest and transit. Moreover, implement custom alerts to detect suspicious activities as well. 

Answer the questions below

Should the API logs be publically accessible so that the attacker must know they are being logged (yea/nay)?

What is the HTTP response code in case of successful logging of user information?

Insufficient logging and monitoring is a security vulnerability that occurs when an application does not have adequate mechanisms in place to detect and respond to security incidents. This can happen due to various reasons, such as lack of logging or monitoring capabilities, insufficient event logging, or failure to monitor security events.

If an attacker successfully exploits an insufficient logging and monitoring vulnerability, they can carry out their attack undetected and maintain access to the system or sensitive data for an extended period of time, causing significant harm to the application and its users.

To prevent insufficient logging and monitoring vulnerabilities, developers should implement proper logging and monitoring mechanisms that can detect and respond to security incidents in a timely manner. This includes implementing logging capabilities that capture all relevant security events, such as login attempts, failed authentication attempts, and unusual or suspicious behavior.

Developers should also implement a system for monitoring and analyzing security logs to detect and respond to security incidents in real-time. This includes using security information and event management (SIEM) systems to collect and analyze security events, setting up alerts and notifications for potential security incidents, and conducting regular security assessments and penetration testing to identify potential vulnerabilities and attack scenarios.

In addition to these measures, developers should follow secure coding practices to minimize the risk of insufficient logging and monitoring vulnerabilities. This includes using strong authentication and authorization mechanisms, minimizing the use of hardcoded passwords and credentials, and avoiding the use of insecure libraries and frameworks.

Overall, proper logging and monitoring is critical to ensuring the security and protection of an application and its users. Developers must take proactive measures to identify and address insufficient logging and monitoring vulnerabilities and regularly review and update all logging and monitoring mechanisms to ensure the security of the application.