daffainfo
/
nuclei-templates
mirror of https://github.com/daffainfo/nuclei-templates.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
nuclei-templates/http/fuzzing/cache-poisoning-fuzz.yaml

37 lines
1.2 KiB
YAML
Raw Normal View History

Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
id: cache-poisoning-fuzz
info:
name: Cache Poison Fuzzing
updated matcher part
2023-02-01 08:53:01 +00:00
author: dwisiswant0,ColbyJack1134
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
severity: info
reference:
- https://youst.in/posts/cache-poisoning-at-scale/
Update cache-poisoning-fuzz.yaml Proposed fixes to cache-poisoning-fuzz.yaml based on issue #5070 What I believe was wrong before: - The author of this template used the {{uniq}} in three places in the template, however, all three values are different with each pair of requests. This means that the cache buster query changes between request 1 and request 2, causing cache poisoning detection to not work properly. Implemented fixes: - Changed the cache buster query to be the same for request 1 and request 2, allowing for proper cache poisoning detection - Used the consistent {{randstr}} preprocessor as the value for headers, since {{uniq}} would not be detected in the matchers as it changes every call - Used the same User-Agent for each request, as having user agents change between request 1 and request 2 could cause a cache to miss - Added a matching condition for {{randstr}} to exist in both responses to avoid false positives - Added reference to portswigger's web cache poisoning lesson Side notes: - The tag "fuzz" for some reason caused errors on my nuclei instance, but "fuzzing" would not. However, I left it alone in case it is just a local issue - Template tested on and properly detected web cache poisoning for https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-targeted-using-an-unknown-header
2022-10-02 23:35:04 +00:00
- https://portswigger.net/web-security/web-cache-poisoning
Added max request counter of each template
2023-04-28 08:11:21 +00:00
metadata:
max-request: 5834
Revert "TemplateMan Update [Mon Apr 8 11:30:07 UTC 2024] :robot:" This reverts commit 433dda4ae5b824564b44075bb95a96ecdbe263a6.
2024-04-08 11:34:33 +00:00
tags: fuzz,cache
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
Refactoring the directory structure based on protocols (#7137) * moving http templates * updated cves.json * moved network CVEs * updated scripts * updated workflows * updated requests to http * replaced network to tcp --------- Co-authored-by: sandeep <8293321+ehsandeep@users.noreply.github.com>
2023-04-27 04:28:59 +00:00
http:
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
- raw:
- |
Update cache-poisoning-fuzz.yaml Proposed fixes to cache-poisoning-fuzz.yaml based on issue #5070 What I believe was wrong before: - The author of this template used the {{uniq}} in three places in the template, however, all three values are different with each pair of requests. This means that the cache buster query changes between request 1 and request 2, causing cache poisoning detection to not work properly. Implemented fixes: - Changed the cache buster query to be the same for request 1 and request 2, allowing for proper cache poisoning detection - Used the consistent {{randstr}} preprocessor as the value for headers, since {{uniq}} would not be detected in the matchers as it changes every call - Used the same User-Agent for each request, as having user agents change between request 1 and request 2 could cause a cache to miss - Added a matching condition for {{randstr}} to exist in both responses to avoid false positives - Added reference to portswigger's web cache poisoning lesson Side notes: - The tag "fuzz" for some reason caused errors on my nuclei instance, but "fuzzing" would not. However, I left it alone in case it is just a local issue - Template tested on and properly detected web cache poisoning for https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-targeted-using-an-unknown-header
2022-10-02 23:35:04 +00:00
GET /?{{md5(headers)}}=1 HTTP/1.1
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
Host: {{Hostname}}
Update cache-poisoning-fuzz.yaml Proposed fixes to cache-poisoning-fuzz.yaml based on issue #5070 What I believe was wrong before: - The author of this template used the {{uniq}} in three places in the template, however, all three values are different with each pair of requests. This means that the cache buster query changes between request 1 and request 2, causing cache poisoning detection to not work properly. Implemented fixes: - Changed the cache buster query to be the same for request 1 and request 2, allowing for proper cache poisoning detection - Used the consistent {{randstr}} preprocessor as the value for headers, since {{uniq}} would not be detected in the matchers as it changes every call - Used the same User-Agent for each request, as having user agents change between request 1 and request 2 could cause a cache to miss - Added a matching condition for {{randstr}} to exist in both responses to avoid false positives - Added reference to portswigger's web cache poisoning lesson Side notes: - The tag "fuzz" for some reason caused errors on my nuclei instance, but "fuzzing" would not. However, I left it alone in case it is just a local issue - Template tested on and properly detected web cache poisoning for https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-targeted-using-an-unknown-header
2022-10-02 23:35:04 +00:00
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
updated header
2023-02-10 08:51:09 +00:00
{{headers}}: {{randstr}}.tld
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
- |
Update cache-poisoning-fuzz.yaml Proposed fixes to cache-poisoning-fuzz.yaml based on issue #5070 What I believe was wrong before: - The author of this template used the {{uniq}} in three places in the template, however, all three values are different with each pair of requests. This means that the cache buster query changes between request 1 and request 2, causing cache poisoning detection to not work properly. Implemented fixes: - Changed the cache buster query to be the same for request 1 and request 2, allowing for proper cache poisoning detection - Used the consistent {{randstr}} preprocessor as the value for headers, since {{uniq}} would not be detected in the matchers as it changes every call - Used the same User-Agent for each request, as having user agents change between request 1 and request 2 could cause a cache to miss - Added a matching condition for {{randstr}} to exist in both responses to avoid false positives - Added reference to portswigger's web cache poisoning lesson Side notes: - The tag "fuzz" for some reason caused errors on my nuclei instance, but "fuzzing" would not. However, I left it alone in case it is just a local issue - Template tested on and properly detected web cache poisoning for https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-targeted-using-an-unknown-header
2022-10-02 23:35:04 +00:00
GET /?{{md5(headers)}}=1 HTTP/1.1
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
Host: {{Hostname}}
Update cache-poisoning-fuzz.yaml Proposed fixes to cache-poisoning-fuzz.yaml based on issue #5070 What I believe was wrong before: - The author of this template used the {{uniq}} in three places in the template, however, all three values are different with each pair of requests. This means that the cache buster query changes between request 1 and request 2, causing cache poisoning detection to not work properly. Implemented fixes: - Changed the cache buster query to be the same for request 1 and request 2, allowing for proper cache poisoning detection - Used the consistent {{randstr}} preprocessor as the value for headers, since {{uniq}} would not be detected in the matchers as it changes every call - Used the same User-Agent for each request, as having user agents change between request 1 and request 2 could cause a cache to miss - Added a matching condition for {{randstr}} to exist in both responses to avoid false positives - Added reference to portswigger's web cache poisoning lesson Side notes: - The tag "fuzz" for some reason caused errors on my nuclei instance, but "fuzzing" would not. However, I left it alone in case it is just a local issue - Template tested on and properly detected web cache poisoning for https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-targeted-using-an-unknown-header
2022-10-02 23:35:04 +00:00
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
attack: clusterbomb
payloads:
templateman update
2023-10-14 11:27:55 +00:00
headers: helpers/wordlists/headers.txt
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
stop-at-first-match: true
matchers:
- type: dsl
dsl:
Update cache-poisoning-fuzz.yaml Proposed fixes to cache-poisoning-fuzz.yaml based on issue #5070 What I believe was wrong before: - The author of this template used the {{uniq}} in three places in the template, however, all three values are different with each pair of requests. This means that the cache buster query changes between request 1 and request 2, causing cache poisoning detection to not work properly. Implemented fixes: - Changed the cache buster query to be the same for request 1 and request 2, allowing for proper cache poisoning detection - Used the consistent {{randstr}} preprocessor as the value for headers, since {{uniq}} would not be detected in the matchers as it changes every call - Used the same User-Agent for each request, as having user agents change between request 1 and request 2 could cause a cache to miss - Added a matching condition for {{randstr}} to exist in both responses to avoid false positives - Added reference to portswigger's web cache poisoning lesson Side notes: - The tag "fuzz" for some reason caused errors on my nuclei instance, but "fuzzing" would not. However, I left it alone in case it is just a local issue - Template tested on and properly detected web cache poisoning for https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-targeted-using-an-unknown-header
2022-10-02 23:35:04 +00:00
- 'contains(body_1, "{{randstr}}")'
- 'contains(body_2, "{{randstr}}")'
updated matcher part
2023-02-01 08:53:01 +00:00
condition: and
Auto Template Signing [Tue Mar 19 16:40:41 UTC 2024] :robot:
2024-03-19 16:40:41 +00:00
# digest: 4a0a00473045022100893d371d193cc0f4111cf8b61a2d092bf7820039aa9a6eecf49529c0d59ac41702201b80bdfb4007c9173b4cff9a55590cf605b0918021c8bbd96b3cc0294ecd5124:922c64590222798bb761d5b6d8e72950