From 78494aa2f8b047e15f03d29e1848703fa4cbc172 Mon Sep 17 00:00:00 2001 From: Sujala Vasanthasena Nelavai Date: Mon, 15 Jun 2026 17:56:10 +0100 Subject: [PATCH 01/11] =?UTF-8?q?Modern=20MFA=20Attack=20Patterns=20(Vendo?= =?UTF-8?q?r=E2=80=91Neutral)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add modern MFA attack patterns (vendor-neutral) to MFA Cheat Sheet --- .../Multifactor_Authentication_Cheat_Sheet.md | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md index 28564f1839..f13c2d729d 100644 --- a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md +++ b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md @@ -343,6 +343,34 @@ Email verification requires that the user enters a code or clicks a link sent to - Email may be received by the same device the user is authenticating from. - Susceptible to phishing. +- ## Modern MFA Attack Patterns (Vendor‑Neutral) + +Even with MFA in place, attackers continue to find ways around it. The patterns below reflect common techniques seen across modern environments. These examples are vendor-neutral and focus on the underlying weaknesses rather than specific products or malware families. + +### MFA Fatigue / Push Abuse +Attackers repeatedly trigger push notifications to overwhelm users until one is approved accidentally or out of frustration. + +### Token Theft +Session cookies, refresh tokens, or other post-authentication tokens can be stolen and reused, allowing attackers to bypass MFA entirely. + +### Reverse-Proxy Phishing Kits +Phishing frameworks can intercept MFA codes or session tokens in real time by sitting between the user and the legitimate service. + +### Cloud MFA Misconfigurations +Legacy protocols, weak conditional access rules, or incomplete MFA enforcement can leave gaps that attackers exploit. + +### Weak MFA on Remote Access Services +Services like RDP, SSH, or VPN may have MFA enabled inconsistently or incorrectly, allowing attackers to gain initial access. + +### Cross-Platform MFA Weaknesses +When MFA is applied differently across Windows, Linux, and cloud systems, attackers may target the weakest link to move laterally. + +### Device Compromise +If a user’s device is already compromised, attackers may approve MFA prompts, steal tokens, or intercept authentication flows. + +### Token Replay +Captured or intercepted tokens can sometimes be reused if they are not bound to the device, session, or client. + ## Something You Are Inherence-based authentication is based on the physical attributes of the user. This is less common for web applications as it requires the user to have specific hardware, and is often considered to be the most invasive in terms of privacy. However, it is commonly used for operating system authentication, and is also used in some mobile applications. From 61152f80808aa3fac4dbfc71519c095e4bba4f32 Mon Sep 17 00:00:00 2001 From: Sujala Vasanthasena Nelavai Date: Mon, 15 Jun 2026 20:29:52 +0100 Subject: [PATCH 02/11] Update Multifactor_Authentication_Cheat_Sheet.md --- cheatsheets/Multifactor_Authentication_Cheat_Sheet.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md index f13c2d729d..324a2c286d 100644 --- a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md +++ b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md @@ -343,32 +343,40 @@ Email verification requires that the user enters a code or clicks a link sent to - Email may be received by the same device the user is authenticating from. - Susceptible to phishing. -- ## Modern MFA Attack Patterns (Vendor‑Neutral) +## Modern MFA Attack Patterns (Vendor‑Neutral) Even with MFA in place, attackers continue to find ways around it. The patterns below reflect common techniques seen across modern environments. These examples are vendor-neutral and focus on the underlying weaknesses rather than specific products or malware families. ### MFA Fatigue / Push Abuse + Attackers repeatedly trigger push notifications to overwhelm users until one is approved accidentally or out of frustration. ### Token Theft + Session cookies, refresh tokens, or other post-authentication tokens can be stolen and reused, allowing attackers to bypass MFA entirely. ### Reverse-Proxy Phishing Kits + Phishing frameworks can intercept MFA codes or session tokens in real time by sitting between the user and the legitimate service. ### Cloud MFA Misconfigurations + Legacy protocols, weak conditional access rules, or incomplete MFA enforcement can leave gaps that attackers exploit. ### Weak MFA on Remote Access Services + Services like RDP, SSH, or VPN may have MFA enabled inconsistently or incorrectly, allowing attackers to gain initial access. ### Cross-Platform MFA Weaknesses + When MFA is applied differently across Windows, Linux, and cloud systems, attackers may target the weakest link to move laterally. ### Device Compromise + If a user’s device is already compromised, attackers may approve MFA prompts, steal tokens, or intercept authentication flows. ### Token Replay + Captured or intercepted tokens can sometimes be reused if they are not bound to the device, session, or client. ## Something You Are From bfaf25df2d83dfbab77df6a6eef70dacc2cb3191 Mon Sep 17 00:00:00 2001 From: Sujala Vasanthasena Nelavai Date: Mon, 15 Jun 2026 20:40:58 +0100 Subject: [PATCH 03/11] Update Multifactor_Authentication_Cheat_Sheet.md --- .../Multifactor_Authentication_Cheat_Sheet.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md index 324a2c286d..ba719979e8 100644 --- a/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md +++ b/cheatsheets/Multifactor_Authentication_Cheat_Sheet.md @@ -345,39 +345,39 @@ Email verification requires that the user enters a code or clicks a link sent to ## Modern MFA Attack Patterns (Vendor‑Neutral) -Even with MFA in place, attackers continue to find ways around it. The patterns below reflect common techniques seen across modern environments. These examples are vendor-neutral and focus on the underlying weaknesses rather than specific products or malware families. +Even with MFA in place, attackers continue to find ways around it. The patterns below reflect common techniques seen across modern environments. These examples are vendor-neutral and focus on underlying weaknesses rather than specific products or malware families. ### MFA Fatigue / Push Abuse -Attackers repeatedly trigger push notifications to overwhelm users until one is approved accidentally or out of frustration. +Attackers repeatedly trigger push notifications to overwhelm users until one is approved accidentally or out of frustration. This technique has been widely documented in real-world intrusions. [Microsoft](https://www.microsoft.com/en-us/security/blog/2022/09/12/defending-against-mfa-fatigue-attacks/) ### Token Theft -Session cookies, refresh tokens, or other post-authentication tokens can be stolen and reused, allowing attackers to bypass MFA entirely. +Session cookies, refresh tokens, or other post-authentication tokens can be stolen and reused, allowing attackers to bypass MFA entirely. NIST highlights the risks of session hijacking and the importance of binding authentication to the client. [NIST SP 800‑63B](https://pages.nist.gov/800-63-3/sp800-63b.html) ### Reverse-Proxy Phishing Kits -Phishing frameworks can intercept MFA codes or session tokens in real time by sitting between the user and the legitimate service. +Reverse-proxy phishing frameworks can intercept MFA codes or session tokens in real time by sitting between the user and the legitimate service. CISA recommends phishing-resistant MFA specifically to mitigate these attacks. [CISA](https://www.cisa.gov/news-events/alerts/2022/10/31/implementing-phishing-resistant-mfa) ### Cloud MFA Misconfigurations -Legacy protocols, weak conditional access rules, or incomplete MFA enforcement can leave gaps that attackers exploit. +Legacy protocols, weak conditional access rules, or incomplete MFA enforcement can leave gaps that attackers exploit. Misconfigurations are a leading cause of MFA bypass in cloud environments. [Microsoft](https://www.microsoft.com/en-us/security/blog/2021/10/07/5-identity-attack-vectors-and-how-to-prevent-them/) ### Weak MFA on Remote Access Services -Services like RDP, SSH, or VPN may have MFA enabled inconsistently or incorrectly, allowing attackers to gain initial access. +Services like RDP, SSH, or VPN may have MFA enabled inconsistently or incorrectly, allowing attackers to gain initial access. CISA advisories frequently highlight remote-access MFA gaps in real incidents. [CISA](https://www.cisa.gov/news-events/cybersecurity-advisories) ### Cross-Platform MFA Weaknesses -When MFA is applied differently across Windows, Linux, and cloud systems, attackers may target the weakest link to move laterally. +When MFA is applied differently across Windows, Linux, SaaS, and cloud systems, attackers may target the weakest link to move laterally. NIST emphasizes consistent authenticator assurance across systems. [NIST SP 800‑63B](https://pages.nist.gov/800-63-3/sp800-63b.html) ### Device Compromise -If a user’s device is already compromised, attackers may approve MFA prompts, steal tokens, or intercept authentication flows. +If a user’s device is already compromised, attackers may approve MFA prompts, steal tokens, or intercept authentication flows. Compromised endpoints remain a major vector for MFA bypass. [Microsoft](https://www.microsoft.com/en-us/security/blog/2023/03/13/understanding-identity-based-attacks/) ### Token Replay -Captured or intercepted tokens can sometimes be reused if they are not bound to the device, session, or client. +Captured or intercepted tokens can sometimes be reused if they are not bound to the device, session, or client. Google Cloud provides detailed analysis of session hijacking and replay attacks. [Google Cloud](https://cloud.google.com/blog/topics/threat-intelligence/understanding-session-hijacking) ## Something You Are From 06072160758bb20c54ebcfccf5ebb2eb46ab1e6c Mon Sep 17 00:00:00 2001 From: Sujala Vasanthasena Nelavai Date: Mon, 15 Jun 2026 21:41:11 +0100 Subject: [PATCH 04/11] Add Common Pitfalls section to Input Validation Cheat Sheet MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This pull request adds a new “Common Pitfalls in Input Validation” section to the Input Validation Cheat Sheet, as discussed in Issue #2228. The goal of this update is to highlight the mistakes that developers frequently make even when they believe they are validating input correctly. These pitfalls come up repeatedly in real-world assessments, code reviews, and incident investigations, so documenting them helps readers avoid subtle but high-impact vulnerabilities. The new section covers practical issues such as relying only on client-side validation, using blacklists instead of whitelists, skipping validation after deserialization, trusting internal services too much, unsafe regular expressions, Unicode normalization problems, and assumptions about JSON input. Each point is written in a clear, human tone and includes references to relevant OWASP, NIST, CISA, and Unicode guidance where appropriate. This addition fits naturally after the “Implementing Input Validation” section and before the allowlisting/denylisting discussion. It strengthens the cheat sheet by giving readers a realistic understanding of where input validation often fails in practice, complementing the existing guidance on how to implement it correctly. --- cheatsheets/Input_Validation_Cheat_Sheet.md | 44 +++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/cheatsheets/Input_Validation_Cheat_Sheet.md b/cheatsheets/Input_Validation_Cheat_Sheet.md index 7535fa1f16..b8742a2142 100644 --- a/cheatsheets/Input_Validation_Cheat_Sheet.md +++ b/cheatsheets/Input_Validation_Cheat_Sheet.md @@ -33,6 +33,50 @@ Input validation can be implemented using any programming technique that allows - Regular expressions for any other structured data covering the whole input string `(^...$)` and **not** using "any character" wildcard (such as `.` or `\S`) - Denylisting known dangerous patterns can be used as an additional layer of defense, but it should supplement - not replace - allowlisting, to help catch some commonly observed attacks or patterns without relying on it as the main validation method. +## Common Pitfalls in Input Validation + +Even when teams try to implement input validation, a lot of applications still end up vulnerable because of small oversights or assumptions that don’t hold up in the real world. These are some of the issues that come up again and again during security reviews and incident investigations. + +### Relying Only on Client-Side Validation + +Client-side checks (like JavaScript validation or HTML5 rules) are helpful for user experience, but they’re not security controls. Anyone can bypass them by turning off scripts, modifying requests, or using tools like curl or Burp. The server must always validate the final input. [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) + +### Using Blacklists Instead of Whitelists + +Trying to block “bad” input with a blacklist almost always fails. Attackers can use encoding tricks, alternate characters, or new payloads you didn’t think of. It’s much safer to define what *good* input looks like and only allow that. [NIST SP 800‑53 SA-11](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) + +### Skipping Validation After Deserialization + +Data that looked safe before serialization can become unsafe once it’s parsed again. Formats like JSON, XML, and protobuf can hide unexpected structures or types. Always validate *after* deserialization, when you know exactly what the data looks like. [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/) + +### Trusting Internal APIs or Microservices Too Much + +It’s common for internal services to skip validation because they’re “inside the perimeter.” But modern attacks often target internal trust boundaries. Every service—internal or external—needs proper validation. [CISA Zero Trust Guidance](https://www.cisa.gov/zero-trust-maturity-model) + +### Not Validating File Uploads or Filenames + +File uploads are a huge attack surface. You need to validate the file type, size, extension, and even the filename. Attackers can sneak in traversal sequences or special characters that cause trouble later. [OWASP File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/) + +### Using Unsafe or Overly Complex Regular Expressions + +Some regex patterns can cause catastrophic backtracking (ReDoS), slowing your server to a crawl. Keep patterns simple, anchored, and performance-tested. [OWASP ReDoS Prevention](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) + +### Ignoring Nested JSON or Large Arrays + +Attackers often hide malicious data deep inside nested objects or huge arrays. Validation needs to walk the entire structure and enforce limits at every level. + +### Overlooking Unicode Normalization + +Unicode can be tricky. Different characters can look identical or behave unexpectedly, which can let attackers slip past naive filters. Normalizing input (like using NFC) helps avoid these issues. [Unicode Security Considerations](https://unicode.org/reports/tr36/) + +### Assuming JSON Input Is Automatically Safe + +JSON feels structured and predictable, but attackers can still inject harmful strings, unexpected types, or oversized payloads. It needs the same level of validation as any other input. + +### Forgetting to Validate Before Logging or Storing Data + +Unvalidated input written to logs or databases can lead to log injection, stored XSS, or parsing errors later. Validation should happen before the data goes anywhere—logs included. + ### Allowlist vs Denylist It is a common mistake to use denylist validation in order to try to detect possibly dangerous characters and patterns like the apostrophe `'` character, the string `1=1`, or the `