Add “Common Pitfalls in Input Validation” Section to Strengthen Practical Guidance

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 `<script>` tag, but this is a massively flawed approach as it is trivial for an attacker to bypass such filters.

cheatsheets/Multifactor_Authentication_Cheat_Sheet.md

@@ -343,6 +343,42 @@ 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 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. 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. 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
+
+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. 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. 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, 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. 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. 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
 
 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.