Updated the "Hidden Input Field Detection at Response Level (Passive)" Finding

vulnerability-classes/injection/Detecting hidden input fields for XSS.bcheck

@@ -1,17 +1,55 @@
 metadata:
-    language: v1-beta
+    language: v2-beta
     name: "Hidden Input Field Detection at Response Level (Passive)"
-    author: "mrrootsec"
-    description: "This Bcheck identifies hidden input fields in the response for further examination."
-    tags: "passive" , "xss"
+    author: "mrrootsec, Kyle Gilligan"
+    description: "This Bcheck identifies hidden input fields in the HTTP response for further examination."
+    tags: "passive", "xss", "html", "hidden"
+
+define:
+    issueDetail_FULL = 
+`An '<input>' HTML field with the 'type="hidden"' or 'style="display: none;"' attribute has been detected.
+This HTML field may be susceptible to XSS injections.
+It is recommended to check this field for XSS by appending its "id", "name", or "class" attribute into a URL or body parameter.
+
+For Example: -<input type="hidden" id="a1" name="b2" class="c3" value="Hello World!">-
+- Append a URL for XSS via 'id': 'https://example.com?a1=%3Cscript%3Ealert(%27Attack%27)%3C/script%3E'
+- Append a URL for XSS via 'name': 'https://example.com?b2=%3Cscript%3Ealert(%27Attack%27)%3C/script%3E'
+- Append a URL for XSS via 'class': 'https://example.com?c3=%3Cscript%3Ealert(%27Attack%27)%3C/script%3E'
+
+For context, JavaScript typically gets used to interact between front-end HTML fields & backend servers.
+- JavaScript via "id": 'document.getElementById()'
+- JavaScript via "name": 'document.getElementsByName'
+- JavaScript via "class": 'document.getElementsByClassName'`
+
+    issueRemediation_FULL = 
+`Developers must ensure user-controllable input fields pass the following conditions to safeguard against Cross-Site Scripting & other injection attacks.
+---
+1. CONTEXT: Establish what data context this user input field adheres to; should this field accept text only, numbers only, any characters, etc.
+\t> For example: (A) Personal names - alphabetical characters only. (B) Phone numbers - numerical characters only.
+
+2. VALIDATE: Validate user input through a character whitelist which detects for deployment of any unapproved characters.
+\t> Unapproved characters will typically be contextually-unnecessary character types, or all non-UTF8 characters (often based on the language context of the application).
+\t> Libraries like 'DOMPurify', 'Helmet', & 'ESAPI' exist to automate detection of illicit characters & character types.
+
+3. RESPONSE: If unapproved characters become detected, either 'REJECT this payload' immediately OR 'SANITIZE & REEVALUATE this payload'.
+\t> REJECT: Deny data transferal from this payload & send a response that indicates rejection has occurred.
+\t> SANITIZE & REEVALUATE: Perform sanitization on non-whitelisted characters once to convert these values into safer alternatives. Then, reevaluate the payload for illicit characters again & REJECT this time if unsafe.
+\t\t>> This practice should be tried if 'necessary' content appears expected to possess known illicit characters, and this functionality cannot be rewritten.
+
+4. ENCODE: If approved, this application must encode all HTML metacharacters contained within user input whenever this content would be copied directly into an HTTP webpage.
+\t> For example: '<' becomes '&lt;', '>' becomes '&gt;', '&' becomes '&amp', '"' becomes '&quot', etc.
+\t> Metacharacters especially-relevant to XSS include: <, >, &, ", ', =, /, & \.`
 
 given response then
-    if {latest.response} matches "<input type=\"hidden\" id=\"[0-9A-Za-z-_]{0,}\"" then
-        report issue:
-            severity: info
-            confidence: firm
-            detail: "A Hidden Input Field has been Detected. It is recommended to manually check this field by appending them in the URL for potential Cross-Site Scripting (XSS) vulnerabilities."
-            remediation: "To prevent potential security risks, In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
-a) Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
-b) User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > \" \' and =, should be replaced with the corresponding HTML entities (&lt; &gt; etc)."
+    # This check ensures that only notable 200s HTTP responses appear present in the HTTP response & unacceptable MIME types get ignored.
+    if ({latest.response.status_code} matches "(200|204|206)") and ({latest.response.headers} matches "(Content-Type: text/html)") then
+
+        # This check looks for the `<input>` HTML element followed by type="hidden" or style="display:none;" within 50 characters until a `>` appears.
+        if ({latest.response} matches "<input[^>]{0,50}?(type=['\"]hidden['\"]|style=['\"]display:\\s*none;['\"])") then
+            report issue:
+                severity: info
+                confidence: firm
+                detail: `{issueDetail_FULL}`
+                remediation: `{issueRemediation_FULL}`
+        end if
     end if