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/fuzzing/cache-poisoning-fuzz.yaml

36 lines
957 B
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
tags: fuzz,cache
Add cache-poisoning-fuzz (#3413)
2021-12-25 07:56:35 +00:00
requests:
- 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:
headers: helpers/wordlists/headers.txt
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