In the dynamic realm of software development and cybersecurity, safeguarding your APIs is akin to ensuring a safe passage through turbulent waters. Just as a well-crafted restaurant menu simplifies the dining experience, APIs (Application Programming Interfaces) streamline the interaction between diverse software components. Securing these vital communication channels is not just a best practice; it's a necessity to uphold the integrity of your applications. Akto, an open-source API security platform, steps in as your trusty navigation tool, promising a seamless setup in just 60 seconds. Like a captain steering a ship, security teams rely on Akto to keep a constant eye on the health of their APIs, spot vulnerabilities on the horizon, and swiftly address any runtime issues.
Akto's prowess extends to encompassing the realm of the OWASP Top 10 and HackerOne Top 10, akin to a versatile culinary menu offering a plethora of delectable choices. Among its offerings are BOLA, a security configuration platter, the sizzling authentication option, the XSS dessert, and the spicy SSRF specialty. Much like a diverse menu catering to various culinary preferences, Akto caters to an array of security challenges, assuring you a satisfying and secure experience.
Akto's Test Editor
One of the standout features of Akto is its Test Editor, which empowers you to craft custom tests tailored to your specific security requirements. With this editor, you can define the criteria, filters, and validations essential for your API security testing process. Custom tests offer unparalleled flexibility, allowing you to concentrate on the most critical aspects of your APIs.
The Test Editor comprises three vital components:
1)Test Library: Featuring a repository of over 100 built-in tests.
2)YAML Test Editor: This is where you define your custom test using YAML (Yet Another Markup Language).
3)Sample API Requests and Responses: These serve as references to guide your test creation.
Writing Custom Tests in Akto
Creating a custom test in Akto involves using YAML to articulate the test's parameters. YAML, known for its human-readable data serialization format, enables both technical and non-technical users to design custom tests in a structured and comprehensible manner. Here's a step-by-step guide to writing a custom test in Akto:
Step 1: Find the Test Editor in Akto
Step 2: Define Test Information
Begin your custom test YAML with essential information about the test:
Test Name: Choose a clear, descriptive name.
Description: Provide a concise overview of your test's purpose.
Details: Elaborate on the logic and rationale behind your test.
Impact: Specify the potential consequences if the vulnerability is exploited.
Category and Sub-Category: Categorize your test for better organization.
Severity: **Indicate the test's severity level.
**Tags: Use tags to classify your test for easy filtering.
**References: **Include relevant reference links or documentation.
Example YAML Template:
id: CUSTOM_TEST_ID
info:
name: "Your Test Name"
description: "Brief description of your test."
details: >
"Detailed description or logic behind your test."
impact: "Potential impact of the vulnerability if exploited."
category:
name: LFI
shortName: Local File Inclusion
displayName: Local File Inclusion (LFI)
subCategory: CUSTOM_SUB_CATEGORY_NAME
severity: YOUR_SEVERITY_LEVEL
tags:
- Your
- Tags
- Here
references:
- "Relevant reference link"
api_selection_filters: YOUR_FILTERS_HERE
wordLists: YOUR_PAYLOADS_HERE
execute: YOUR_EXECUTION_METHOD_HERE
validate: YOUR_VALIDATION_METHOD_HERE
Step 3: API Selection Filters
Define the conditions under which your test should run. Filter APIs based on parameters like request headers, query parameters, or request bodies. For instance, target APIs with specific query parameters containing specific keywords.
Example API Selection Filters:
api_selection_filters:
response_code:
gte: 200
lt: 300
url:
contains_either:
- login
- signin
- sign-in
- log-in
request_payload:
for_one:
key:
contains_either:
- password
- pwd
- pass
- passwd
request_headers:
for_one:
key:
contains_either: cookie
extract: header_key
Step 4: Writing the Execute Section
The execution section outlines how your test should interact with the API under examination. Modify request parameters, headers, or bodies to simulate potential attacks.
execute:
type: single
requests:
- req:
- modify_query_param:
limitKey: ${limitValue}0
Example for better understanding:
// original request body
{
"user": "Brad Pitt",
"email": "bradpitt22@example.com"
}
execute:
add_body_param:
status: admin
Step 5: Validation - Ensuring the Safety Net
The validation section of your custom test in Akto serves as the safety net, ensuring that your test produces meaningful results and accurately detects vulnerabilities. Think of it as the vigilant sentry guarding your digital fortress against potential threats. This section not only confirms that your test executed successfully but also checks the expected outcomes, response codes, payload integrity, and other relevant data. Here's a more detailed look at the validation section:
1)Response Codes Validation: Response codes play a pivotal role in determining the outcome of an API request. In this validation section, you can specify the expected response codes that indicate the success or failure of your test. For example, you might want to validate that a response code of 200 or 201 signifies a successful test execution.
Example YAML for Response Code Validation:
validate:
response_code:
or:
eq: 200
eq: 201
2)Response Payload Validation: The content of the response is equally critical. You can define conditions for the response payload, such as ensuring that it contains specific keys or values. This is particularly important when your test is looking for specific data within the API response.
Example YAML for Response Payload Validation:
validate:
response_payload:
for_one:
key:
eq: user
value:
contains_either:
- testuser
- defaultuser
3)Response Headers Validation: The headers accompanying the API response can also be examined to ensure they meet security standards. You might want to check that response headers adhere to specific patterns or contain certain values.
Example YAML for Response Headers Validation:
validate:
response_headers:
for_one:
value:
regex: https?:.*
4)Complex Validation Scenarios: In real-world security testing, conditions can be complex, requiring multiple criteria to evaluate whether a given endpoint is vulnerable. In such cases, boolean operators come into play, allowing you to define intricate combinations of conditions. These conditions can include checks on response codes, payload content, and header values, making your tests comprehensive and effective.
Example YAML for Complex Validation Scenario:
validate:
response_code:
eq: 200
response_payload:
for_one:
key:
eq: user
value:
contains_either:
- testuser
- defaultuser
response_headers:
for_one:
value:
regex: https?:.*
By employing these robust validation techniques, your custom tests not only run effectively but also serve as a reliable security measure to identify vulnerabilities. Just as a vigilant gatekeeper ensures that only authorized individuals gain entry to a secure facility, the validation section of Akto's custom tests ensures that your APIs remain well-guarded and resilient against potential threats.
Step 6: Completing Your Custom Test YAML - Crafting the Blueprint
The below test is about Local File Inclusion Vulnerability in Akto.
Local File Inclusion (LFI) represents a security vulnerability that opens the door for malicious actors to include files located on the server within the output of an application. This vulnerability essentially allows unauthorized access to files that should remain confidential. In essence, it's like someone gaining access to the hidden nooks and crannies of a server's filing cabinet. The consequences of LFI attacks can be severe, potentially leading to a complete compromise of the server if it's configured with inadequate permissions and security measures.
These vulnerabilities typically rear their heads in applications that fail to rigorously verify user-provided input for file inclusion functionalities. Essentially, it's a bit like letting a guest into your home without thoroughly checking their identification - you might end up giving them access to your private spaces.
Completing your custom test YAML is akin to crafting the blueprint for a complex structure. It sets the foundation for the entire testing process, detailing the essence of your test. In this step, you provide all the essential information and configurations that ensure your custom test performs as intended. Here's a closer look at what this crucial phase involves:
1)Defining the Test's Purpose: Within your custom test YAML, the "description" field is where you articulate the core purpose of your test. This description should be comprehensive and descriptive, ensuring that anyone who reads it can quickly understand the test's objectives and significance.
Example YAML for Defining the Test's Purpose:
info:
name: "LFI via Backup Files"
description: "Checks for accessible backup files which can be exploited for LFI."
2)Understanding the Impact: To gauge the severity of your test's results, you must specify the potential impact of the vulnerability if exploited. This information is critical for risk assessment and prioritizing security measures.
Example YAML for Understanding the Impact:
impact: "Exposure of sensitive information and potential system compromise."
3)Categorizing Your Test: Categorization helps in organizing and identifying your test's purpose within your testing framework. It makes it easier to locate, manage, and report on specific types of vulnerabilities.
Example YAML for Categorizing Your Test:
category:
name: LFI
shortName: Local File Inclusion
displayName: Local File Inclusion (LFI)
4)Setting Severity Levels: Indicating the severity level of your test is crucial. It helps prioritize and respond to vulnerabilities effectively, with higher severity tests demanding immediate attention.
Example YAML for Setting Severity Levels:
severity: HIGH
5)Adding Tags for Organization: Tags are like labels that help you categorize and filter your tests efficiently. They can represent specific aspects of your test, such as its nature or the types of vulnerabilities it targets.
Example YAML for Adding Tags:
tags:
- Backup
- Misconfiguration
6)Providing References: Including reference links or documentation relevant to your test can be immensely helpful. These references serve as valuable resources for anyone working with your custom test.
Example YAML for Providing References:
references:
- "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion"
By completing these aspects of your custom test YAML, you're essentially creating a comprehensive guide for your test. It's like having a well-structured architectural plan before you embark on constructing a building. This step ensures that your custom test aligns with your security objectives, and it helps anyone who interacts with it to fully grasp its purpose, significance, and potential impact. In essence, it's the roadmap to a secure API.
Step 7: Select Your Sample API for Testing
Step 8: Running the Test
Validate the results of your custom test and save it for future use.
Resources
Akto Quick Start -(https://app.akto.io/dashboard/quick-start)
Akto Documentation -(https://docs.akto.io/test-editor/writing-custom-tests)
Akto Tutorial to get you started - ( https://www.youtube.com/watch?v=4BIBra9J0Ek)
In Conclusion
Akto stands as a robust tool that simplifies API security testing. The Test Editor feature grants you the power to craft custom tests that cater to your specific security needs. By using YAML to write custom tests, you gain full control over your API security testing process, ensuring the protection of your APIs. This proactive approach not only safeguards your applications but also elevates your organization's overall cybersecurity posture.
Top comments (0)