The topic describes Traceable's concept of vulnerability along with the vulnerability-management life cycle. The topic also describes the description and mitigation of each detected vulnerability.
Vulnerabilities are security gaps in your API definition that threat actors may exploit to attack your API infrastructure. The Vulnerability-management life cycle process helps in identifying and remediating security risks before they can be exploited by threat actors. The life cycle includes being aware of all the assets in your organization, carrying out a vulnerability scan, assessing the risks, and taking action to mitigate those risks.
Traceable identifies assets or the API endpoints in your environment through the discovery process. After Traceable discovers the API endpoints, it does a vulnerability scan and displays them in the Vulnerability section.
Vulnerability-management life cycle
You can carry out a risk assessment of the API endpoint based on the vulnerabilities identified. Traceable also provides possible remediation. Once you have applied the remediation, verify that your API is secure. Traceable continuously monitors the API endpoints that you have remediated and secured. It reports a vulnerability if it finds any in the future, hence continuous monitoring is essential.
The Vulnerability page displays the type of vulnerability, the severity of the vulnerability, the API endpoint or service, and the time when it was detected. When you click on a vulnerability, Traceable displays the description and possible mitigation steps you can take. If a known vulnerability is not resolved, it may lead to an attack on your API ecosystem.
Traceable, based on its continuous learning, detects the following four types of vulnerabilities:
    API parameter contains URL
    Service uses basic authentication
    Query parameter contains sensitive data
    Lack of encryption
You can manually change the state of the detected vulnerability to any of the following:
    Open - Traceable has detected a vulnerability.
    Under review - Vulnerability has been acknowledged. You are taking steps to close the vulnerability.
    Resolved - Vulnerability has been closed. Traceable keeps monitoring the asset (API endpoint or service) even after you have marked it as resolved. If Traceable finds new vulnerabilities, the vulnerability is automatically moved to an Open state for you to review and resolve.
    Ignored - Move the vulnerability to Ignored state when you do not want Traceable to report it. If Traceable keeps seeing an Ignored vulnerability, it does not move it to open state.
The vulnerability feature is currently in a beta state.
The following table describes the reason for a vulnerability and the mitigation steps you can take.
API parameter contains URL
Server-Side Request Forgery (also known as SSRF) is an attack vector that allows an attacker to masquerade as the Server-Side application and perform requests to an arbitrary domain of his choosing. In typical SSRF attacks, the attacker usually targets:
    accessing services available through the loopback interface ( of the exploited server
    Internal systems behind firewalls that are not accessible from the external network
    External third-party systems
    To access and steal credentials and access tokens from metadata services (for example, AWS Instance Metadata Service, Azure Instance Metadata Service, GCP metadata server).
Where possible, do not let users specify URLs for outgoing requests issued by your server. In cases where dynamic URLs are required, use a list of accepted URLs and do not accept other URLs. Use internal DNS resolvers to resolve domains first and reject external domains resolving to private IPs and metadata services.
Service uses basic authentication
Basic authentication sends credentials in base64 encoding (which can be easily converted to plaintext). If the website/API does not implement HSTS, the credentials are open to being captured via MITM. The password is cached by the browser, at a minimum for the length of the window/process which can silently be leveraged by session-related exploits, notably CSRF. Further, the password may be stored permanently in the browser based on user preferences which could be compromised on a shared device.
Avoid using HTTP Basic Authentication. If using Basic Authentication is not preventable, ensure HSTS is implemented to safeguard against MITM. In some cases, exploiting vulnerable HTTP basic authentication might only grant an attacker access to a seemingly uninteresting page. However, in addition to providing a further attack surface, the credentials exposed in this way might be reused in other, more confidential contexts. Ensure to limit access for the resources exposed via basic authentication and the credentials are not shared for other authentication mechanisms.
Query parameter contains sensitive data
The query string can be saved in the browser's history or cache, passed through Referrers to other websites, stored in weblogs, or otherwise recorded in other sources. If the query string contains sensitive information such as session identifiers, then attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes or launch further attacks. Simply using HTTPS does not resolve this vulnerability. Vulnerabilities that result due to the disclosure of sensitive data especially credentials can result in compromises that are extremely difficult to investigate due to obscured audit trails.
Do not use query parameters to pass sensitive data. Use POST methods for such requests and pass the sensitive data in the request body. Some sensitive data like session identifiers or authorization tokens can be passed via cookies or headers.
Lack of encryption
An attacker with the ability to intercept a user's network traffic can read and modify any messages that are exchanged with the server. This allows the attacker to see passwords in clear text, modify the appearance of your website, redirect the user to other web pages or steal session information. Therefore no message sent to the server remains confidential and its integrity cannot be guaranteed. Lack of encryption also reflects in modern browsers flagging such hosts and leading to bad user experience, loss of users trust, or security.
Use a vetted encryption scheme that is currently considered to be strong by experts in the field such as TLS 1.2 or higher.
Last modified 4mo ago
Export as PDF
Copy link