JS: Web Cache Deception Express

[aydinnyunus]

Pull Request: Add Web Cache Deception Query for CodeQL

Overview

This pull request introduces a new CodeQL query to detect potential Web Cache Deception vulnerabilities in web applications. Web Cache Deception is a security vulnerability where attackers trick a server into caching sensitive information, which they can later access. This query aims to identify code patterns that might make an application susceptible to this type of attack.

Changes Introduced

• New Query Added: WebCacheDeception.ql - Detects patterns where web applications might cache sensitive information inadvertently.
• Experimental Code Samples: Included in the /CWE-525 directory, demonstrating both vulnerable (bad) and secure (good) coding practices related to caching.
• Documentation: Added documentation explaining the query's purpose, usage, and the nature of the vulnerability.

Implementation Details

• The query looks for server configurations or code patterns where URLs can be manipulated to cache sensitive information.
• Focuses on common web languages and frameworks where this vulnerability might occur.

Testing and Validation

• Query tested against a range of synthetic code samples (included in the PR).
• Validated for false positive rates and performance impact on large codebases.

Future Work

• Plan to extend support to additional languages and frameworks.
• Open to community feedback for further refinement and optimization.

References

• Link to the OWASP page on Web Cache Deception: OWASP Web Cache Deception Attack.

[github-actions]

QHelp previews:

javascript/ql/test/experimental/Security/CWE-525/WebCacheDeception.qhelp

Web Cache Deception in Express

Web Cache Deception is a security vulnerability where an attacker tricks a web server into caching sensitive information and then accesses that cached data.

This attack exploits certain behaviors in caching mechanisms by requesting URLs that trick the server into thinking that a non-cachable page is cachable. If a user then accesses sensitive information on these pages, it could be cached and later retrieved by the attacker.

Recommendation

To prevent Web Cache Deception attacks, web applications should clearly define cacheable and non-cacheable resources. Implementing strict cache controls and validating requested URLs can mitigate the risk of sensitive data being cached.

Example

Vulnerable code example: A web server is configured to cache all responses ending in '.css'. An attacker requests 'profile.css', and the server processes 'profile', a sensitive page, and caches it.

const express = require('express')
const app = express()
port = 3000

app.get('/test*', (req, res) => {
  res.send('test')
})

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

Example

Secure code example: The server is configured with strict cache controls and URL validation, preventing caching of dynamic or sensitive pages regardless of their URL pattern.

const express = require('express')
const app = express()
port = 3000

app.get('/test', (req, res) => {
  res.send('test')
})


app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

References

• OWASP Web Cache Deception Attack: Understanding Web Cache Deception Attacks

[ghsecuritylab]

Hello aydinnyunus 👋
You have submitted this pull request as a bug bounty report in the github/securitylab repository and therefore this pull request has been put into draft state to give time for the GitHub Security Lab to assess the PR. When GitHub Security Lab has finished assessing your pull request, it will be marked automatically as Ready for review. Until then, please don't change the draft state.

In the meantime, feel free to make changes to the pull request. If you'd like to maximize payout for your this and future submissions, here are a few general guidelines, that we might take into consideration when reviewing a submission.

• the submission models widely-used frameworks/libraries
• the vulnerability modeled in the submission is impactful
• the submission finds new true positive vulnerabilities
• the submission finds very few false positives
• code in the submission is easy to read and will be easy to maintain
• documentation is written clearly, highlighting the impact of the issue it finds and is written without grammatical or other errors. The code samples clearly show the vulnerability
• the submission includes tests, change note etc.

Please note that these are guidelines, not rules. Since we have a lot of different types of submissions, the guidelines might vary for each submission.

Happy hacking!

[intrigus-lgtm]

This tag is wrong.

Suggested change

	* cwe-525
	* external/cwe/cwe-525

[intrigus-lgtm]

Suggested change

	* cwe-525
	* external/cwe/cwe-525

[intrigus-lgtm]

Where in the sample code is the "server is configured to cache all responses ending in '.css'."?