By participating in this program, you agree to:

• Respect the Community Code of Conduct
• Respect the Intigriti Terms and Conditions
• Respect the scope of the program
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo)

Validation times

We will validate all submissions within the below timelines, once your submission has been verified by Intigriti.
Submissions validated outside of this may be awarded a €25 bonus.

This remains at the discretion of Aikido Security BV to award.

Check our fix
We offer up to €50 bonus to verify a resolved issue for us (when requested).
This remains at the discretion of Aikido Security BV to award.

Introduction

Zen is used by customers to protection against common web application attacks, such as path traversal, SQL injection and shell injection. It's different than a traditional WAF, since it lives inside your app and thus has full context of the called code and the user's input. This allows us to dramatically lower the amount of false positives, as our detection only kicks in when a relevant sink is called.

Zen is open-source and currently only available for Node.js. The source is available at: https://github.com/AikidoSec/firewall-node.

The current version of Zen is compatible with any Express-powered apps. Any bypass in other apps (lambda, NextJs, Hono, Google functions,..) are currently out-of-scope.

Focus

We are interested in submissions related to:

• Vulnerability in the firewall component itself

Beyond bypasses, there's also the risk of introducing security vulnerabilities in the user's app via our own firewall library. We encourage any research into this area as well, and have also assigned a separate tier for this (Tier 1).

• Bypasses in the detection of vulnerabilities
  Zen hooks into several sinks, and when a sink is called, our detection kicks in. Together with the user input, we evaluate whether the user is exploiting a vulnerability.

Some examples of bypasses would be a missing sink, or a fundamental flaw in the way we perform the detection (e.g. universal bypass in the SQL injection module). Issues within this category will be awarded according to Tier 2.

• False positives while user input is safely passed to sink

Any false positives you encounter with our vulnerability detection, such as flagging a shell injection while it is safely encapsulated in the sink. Issues will be awarded in Tier 3. See Severity Assessment for more details.

Feedback
Would you like to help us improve our program or have some feedback to share, please send your anonymous feedback here:

Program feedback link
Please note this form will be checked periodically and should not be used for submission or support queries.

Tier 2: known bypasses of vulnerability detection

• See https://github.com/AikidoSec/firewall-node/pulls for potential bypasses/issues where a fix is queued.

• Using wrong escaping (e.g. using PostgreSQL escaping while DBMS is MySQL) of user input inside SQL query, renders SQL injection detection ineffective

• Possible to inject a single argument in shell injection sinks (e.g. --output=name), which may lead to RCE/arbitrary file write depending on the command. If you are able to inject multiple arguments, we'd be interested in it!

• Safe usage of sinks (e.g. execFile and execFileSync without shell option enabled), but able to run arbitrary command if the user input is the only value of the sink. For example:

const { execFile } = require("child_process");

...
execFile(req.query.foo);
...

• Shell injection bypasses where the user input is the only value of the sink, for example:
  • Missing commands at https://github.com/AikidoSec/firewall-node/blob/main/library/vulnerabilities/shell-injection/containsShellSyntax.ts#L41. These are only detected if the user input is the only value of the sink (e.g. exec(req.user_input), and are therefore of less interest, since our detection is not consistent in such cases.

General

• Bypasses related to any rate limiting functionality are out of scope for the time being.
• Bypasses on prototype pollution freezing
• Bypasses on SQL injection detection (temporarily out of scope, see latest update).
• Bypasses of our detection algorithm, which is also applicable to other languages without language-specific constraints, may be treated as one report.
  • This shouldn't happen often, and if the same bypass is attacked differently on another target (for example, on Python you need to pass an array, on Node you need to pass a string), we may still treat it as a separate report.

Additional notes for Zen for Python

• SQL injection is currently out of scope since we're working on a new approach for detecting this vulnerability. See the latest update.
• SSRF bypasses are currently out of scope as we're working hard to fix the existing issues in the backlog. Stay tuned for an update. We'll soon put it back into scope.
• As for missing sources: we still have a backlog of frameworks we want to support in the upcoming future. For this reason, we are only interested in potential missing sources within the frameworks we currently support (Flask, Django, Quart).

Application

• Wordpress usernames disclosure
• Pre-Auth Account takeover/OAuth squatting
• Self-XSS that can't be used to exploit other users
• Verbose messages/files/directory listings without disclosing any sensitive information
• CORS misconfiguration on non-sensitive endpoints
• Missing cookie flags
• Missing security headers
• Cross-site Request Forgery with no or low impact
• Presence of autocomplete attribute on web forms
• Reverse tabnabbing
• Bypassing rate-limits or the non-existence of rate-limits.
• Best practices violations (password complexity, expiration, re-use, etc.)
• Clickjacking without proven impact/unrealistic user interaction
• CSV Injection
• Sessions not being invalidated (logout, enabling 2FA, etc.)
• Tokens leaked to third parties
• Anything related to email spoofing, SPF, DMARC or DKIM
• Content injection without being able to modify the HTML
• Username/email enumeration
• Email bombing
• HTTP Request smuggling without any proven impact
• Homograph attacks
• XMLRPC enabled
• Banner grabbing/Version disclosure
• Not stripping metadata of files
• Same-site scripting
• Subdomain takeover without taking over the subdomain
• Arbitrary file upload without proof of the existence of the uploaded file
• Blind SSRF without proven business impact (pingbacks aren't sufficient)
• Disclosed/misconfigured Google Maps API keys
• Host header injection without proven business impact

General

• In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate
• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited
• Spam, social engineering and physical intrusion
• DoS/DDoS attacks or brute force attacks
• Vulnerabilities that only work on software that no longer receive security updates
• Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
• Recently discovered zero-day vulnerabilities found in in-scope assets within 14 days after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty
• Reports that state that software is out of date/vulnerable without a proof-of-concept

Tier 1 (vulnerabilities in firewall)

We follow Intigriti's contextual CVSS standard.

Tier 2 (bypasses of vulnerability detection)

Aikido's Node.js agent general severity assessment table

For bypasses of vulnerability detection, severity is determined on a case-by-case basis. The following table provides a general overview on what to expect for each bypass:

Notes:

• Shell injection bypasses are currently out-of-scope as we are working on a new approach for detecting these type of vulnerabilities.

Aikido's Python agent general severity assessment table

Notes:

• SQL injection and shell injection bypasses are currently out-of-scope as we are working on a new approach for detecting these type of vulnerabilities.
• SSRF bypasses are currently out of scope as we're working hard to fix the existing issues in the backlog. Stay tuned for an update. We'll soon put it back into scope.
• As for missing sources: we still have a backlog of frameworks we want to support in the upcoming future. For this reason, we are only interested in potential missing sources within the frameworks we currently support (Flask, Django, Quart).

Some crucial factors which determine the severity are:

• in case of a missing sink or source, how popular/common a sink/source is (which could usually be determined based on a GitHub code search)
• whether the bypass is only possible in limited cases (for example, a bypass which is only possible in an UPDATE SQL query)
• the impact of the bypass (for example, path traversal bypasses have a lower reward than a SQL injection bypass)

Bypasses which only work on Windows or macOS environments may be lower in severity, since web services are not commonly deployed on those.

Tier 3 (false positives of vulnerability detection)

We're also interested in cases where we falsely block requests from the user, while the user input is safely encapsulated. We've made the bounties simple on purpose for those cases, so you are aware what to expect.

Issues in this Tier will be awarded on a case-by-case basis and depends mostly on:

• how common the false positive may be (for instance, if you catch a false positive with a commonly used SQL query operator like SELECT, the award will be on the higher end, since such queries may be executed on almost every page you visit as an user).
• if it has environmental constraints (e.g. only possible with a certain DBMS).

Difference between the tiers

All tiers have the same scope. There is a difference in bounties based on the following:

• Tier 1: actual vulnerabilities in the firewall
• Tier 2: bypasses of our detection (this doesn't directly expose a security risk, but improves our security product)
• Tier 3: false positives of our detection (this doesn't directly expose a security risk as well, but improves our security product)

How do I install firewall-node?

See https://github.com/AikidoSec/firewall-node/tree/main?tab=readme-ov-file#installation, and follow the instructions for Express.js based apps.

Ensure you set the environment variable AIKIDO_BLOCKING to true when launching your app. This ensures that you get immediate feedback during testing if your attack is blocked.

We recommend you to install firewall-node with any of the Express.js sample apps or with a DVWA like NodeGoat.

How do I install firewall-python?

You can install firewall-python directly from PyPi. Ensure you set the environment variable AIKIDO_BLOCKING to true when launching your app. Setting AIKIDO_DEBUG to true may be useful as well.

You can use one of the sample apps as starting point: https://github.com/AikidoSec/firewall-python/tree/main/sample-apps. The Dockerfile contains instructions to build aikido_firewall, so you don't have to do it yourself.

Do I need to create an Aikido account to test the firewall?

No, you don't. Zen can be used without an Aikido account. An account is only needed when you want to report issues to your Aikido dashboard, but any reporting functionality is not in scope for the time being.

Do you offer a live Damn Vulnerable Web Application (DVWA) to test for bypasses?

We are considering it for future iterations, but for now, we recommend you to install Firewall with a project like OWASP NodeGoat. This would also allow you to use the debugger, which could help with understanding and testing the detection logic.

Beyond NodeGoat, you could also use some of our sample apps: https://github.com/AikidoSec/firewall-node/tree/main/sample-apps (Node.js) or https://github.com/AikidoSec/firewall-python/tree/main/sample-apps (Python). As an alternative, you can also write some vulnerabilities yourself.