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

cheatsheets/Input_Validation_Cheat_Sheet.md

@@ -33,6 +33,48 @@ 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.
+
+Note: Client‑side validation and denylisting are already covered in the sections below. See “Server‑Side Validation” and “Allowlist vs Denylist” for detailed guidance.
+
+### Skipping Validation After Deserialization
+
+Data that appears safe before serialization can become unsafe once parsed again. Formats like JSON, XML, and protobuf may contain unexpected structures or types after deserialization. Always validate after deserialization, when the final structure is known.*Reference: [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html).
+
+### 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 Maturity Model](https://www.cisa.gov/resources-tools/resources/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 may hide malicious or unexpected data deep inside nested objects or extremely large arrays. Validation should enforce limits on depth, element count, and overall structure to prevent resource‑exhaustion or parser abuse.
+Reference: OWASP API Security Top 10 – API4:2023 (Unrestricted Resource Consumption).
+
+### Overlooking Unicode Normalization
+
+Normalization must occur before validation so that visually similar or canonically equivalent characters are evaluated consistently. However, Unicode TR36 warns that normalization alone is not a security control — it must be paired with strict allowlisting and canonicalization rules.
+Reference: Unicode Technical Report #36 (Security Considerations).
+
+### 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.
+Reference: OWASP API Security Top 10 – API8:2023 (Security Misconfiguration).
+
+### Forgetting to Validate Before Logging or Storing Data
+
+Input validation reduces unexpected or malformed data, but log injection is primarily mitigated through output encoding when writing to logs. Applications should validate structure and type on input, and then safely encode log entries on output to prevent injection.
+*Reference: OWASP Logging Cheat Sheet*  
+
 ### 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.