This is a vulnerability disclosure program for Infrared Finance. # Disclosure policy * Infrared Finance will investigate legitimate reports and make every effort to quickly resolve any vulnerability. Please make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services. * Infrared Finance will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy. Infrared Finance considers activities conducted consistent with this policy to constitute “authorised” conduct under the Computer Fraud and Abuse Act. Infrared Finance will not bring a DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope of this program. * If legal action is initiated by a third party against you, and you have complied with this security policy, Infrared Finance will take steps to make it known that your actions were conducted in compliance with this policy. * It is also important to note, Infrared Finance will not take legal action against you simply for providing us with a proof of concept of the security vulnerability. Please follow the guidelines listed in the *Proof of concepts* section below to ensure that your proof of concept is detailed enough to demonstrate the issue and still follows the guideline listed above. * If you have any questions or concerns about Infrared Finance's disclosure policy, please contact us via [Twitter](https://twitter.com/InfraredFinance), [Discord](https://discord.gg/https://discord.gg/infrared-finance) or email (security@infrared.finance). If your messages contain sensitive information, please use email and encrypt using our PGP key: ``` $ curl https://infrared.finance/.well-known/pubkey.asc | gpg --import $ gpg --output document.gpg --encrypt --recipient security@infrared.finance document ``` # Scope The following projects/domains are in scope: * Infrared Finance ([https://infrared.finance](https://infrared.finance)) **If an asset is not listed above, always verify that the `security.txt` file points to this page.** If it doesn't, then that project does not belong to Infrared Finance and is not in scope. You can verify the authenticity of the `security.txt` file by using the following commands: ``` $ curl https://infrared.finance/.well-known/pubkey.asc | gpg --import $ curl https://infrared.finance/.well-known/security.txt | gpg --verify gpg: Signature made Thu Jul 25 21:57:58 2024 EDT gpg: using RSA key 5FAC42F82D85D0F463F188FF0748018EFD9C7298 gpg: issuer "security@infrared.finance" gpg: Good signature from "Infrared Finance " [ultimate] gpg: aka "[jpeg image of size 12173]" [ultimate] ``` # Exclusions The following **test types** are excluded from the scope: * Findings from physical testing such as office access (e.g. open doors, tailgating). * Findings derived primarily from social engineering (e.g. phishing, vishing). * Findings from applications or systems not listed in the "Scope" section. **Infrared Finance does accept high-severity issues on out of scope assets if they directly affect the protocol.** * Vulnerability reports with video only PoCs. * Reports that state that software is out of date or vulnerable without a proof of concept. * Highly speculative reports about theoretical damage. * Vulnerabilities as reported by automated tools without additional analysis as to how they’re an issue. * Issues in third-party services should be reported to the respective team. The following **issue types** are excluded from scope: * Network-level Denial of Service (DoS/DDoS) vulnerabilities - please do not disrupt any running services. * Low severity issues that can be detected with tools such as [Hardenize](https://www.hardenize.com/) and [Security Headers](https://securityheaders.io/). We run regular scans with these services. * Content injection issues. The severity of this issue is so low that it does not warrant a report. * Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.). This does not apply to most Infrared Finance properties. * Missing cookie flags. This does not apply to Infrared Finance properties as we do not use cookies. * UI and UX bugs (including spelling mistakes). * Stack traces that disclose information. Most Infrared Finance projects are open-source therefore this information is usually public knowledge. **That said, if you discover a stack trace that discloses information which is not located in a public Infrared Finance GitHub repository, please do submit a report.** * Host header issues without an accompanying proof-of-concept demonstrating vulnerability. * Open ports without an accompanying proof-of-concept demonstrating vulnerability. * Missing `X-Frame-Options` header (Clickjacking). The lack of `X-Frame-Options` does not always indicate that a security vulnerability is present. This is an optional header that is only necessary on endpoints where the UI is rendered to invoke state changing actions. * Cross-site tracing - in order for Cross-Site Tracing (XST) to really be a significant issue you would need to find an endpoint vulnerable to Cross-site Scripting (XSS). * CSP uses `unsafe-inline` - The fact that a CSP includes `unsafe-inline` is not an issue in itself. In order for you to demonstrate the actual impact of this value, we highly recommend you look for an XSS vulnerability. Try to trigger `alert(document.domain)`. * Disclosure of robots.txt file - We are aware that in some cases robots.txt files have been known to disclose sensitive information. We have determined that our robots.txt files do not contain any information that poses a potential security risk. * Email spoofing (SPF misconfigurations) - We understand the risk that this issue poses and have taken acceptable measures to mitigate it. * Open redirect using `Host` header - Open redirects in the `Host` header are not exploitable. # Proof of concepts * XSS - For XSS, a simple `alert(document.domain)` should suffice. * RCE - Please only execute harmless code. Simply printing something or evaluating an expression should be enough to demonstrate the issue. * Unvalidated redirect - Set the redirect endpoint to http://example.com. * Information disclosure - If your report contains sensitive data, please use our [PGP key](https://infrared.finance/publickey.asc) to encrypt it. * CSRF - Either attach a file to demonstrate the issue or paste the code in a code block in your report. * SSRF - Do not tamper with any internal networks. If you feel the necessity to retrieve an internal file, please only request the internal security.txt file. * LFI - Please do not go against the guideline listed in the *Disclosure policy* section. There should be a security.txt file located in the root directory. Being able to retrieve that file should be enough to demonstrate the issue. If you have any questions or concerns about Infrared Finance's disclosure policy, please contact us via [Twitter](https://twitter.com/InfraredFinance), [Discord](https://discord.gg/infrared-finance) or email (security@infrared.finance). # Terminology The term "severity" is frequently used interchangeably with "impact" or "priority". This section defines terminology in order to prevent any potential confusion. **Severity** > The fact or condition of being severe. **Impact** > A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority. **Priority** > A category used to identify the relative importance of an incident, problem or change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken. # Rewards We may or may not offer a financial reward, depending on the severity, impact, and priority of disclosure. Please note that this section may change in the future. Thank you for helping us keep Infrared Finance safe! Updated: 2024-07-24