Rapplex reports Reflected-Filtered Inputs when user-supplied data is reflected in the server response, but is modified, encoded, or partially filtered before being rendered.

This indicates that:

• The application accepts and processes input
• The input is reflected back in the response
• Defensive mechanisms (e.g. filtering, encoding, WAF rules) are altering the payload

Why this matters

Although the payload does not execute as injected, this behavior is still significant:

• It confirms a reflection point exists
• Filtering may be incomplete or inconsistent
• Alternative encodings or payload variants may bypass protections
• Different contexts (HTML, attribute, JavaScript) may still be exploitable

This is often a near-miss condition for vulnerabilities such as XSS.

Example

Injected payload:

<script>alert(1)</script>

Reflected response:

<script>alert(1)</script>

The input is reflected but safely encoded, preventing execution. However, it confirms that user input reaches the response.

Detection Logic

Rapplex flags this condition when:

• The payload (or fragments of it) are present in the response
• The reflected content does not exactly match the original input due to transformations such as:
  • HTML encoding (< → <)
  • Character stripping
  • Keyword filtering
  • Case normalization

Recommendation

Treat these findings as potentially exploitable:

• Try alternative encodings
• Test different injection contexts
• Look for inconsistent filtering across endpoints
• Combine with other parameters or payload techniques

---

Input Filtering Behavior Matrix

The table represents how the application handles a predefined set of test characters and tokens when injected into a parameter.

Rapplex generates this matrix by sending controlled inputs and analyzing how each character is reflected in the response.

Structure

• The top row lists tested characters or tokens
  (e.g. <, >, ", ', /, (, ), = …)
• The bottom row indicates whether each character is filtered

Legend

• X → Filtered (the character was modified, encoded, or removed)
• - → Not filtered (the character is reflected unchanged)

How to Read

Each column represents a tested character:

• If the column contains X, the character is filtered
• If the column contains -, the character is allowed and reflected as-is

Note: This matrix does not indicate how filtering is applied (e.g. encoding vs removal).
It only shows whether the original input was preserved or altered in the response.

Why this matters

This matrix helps identify:

• Which characters are permitted vs restricted
• Whether filtering is consistent or selective
• Potential opportunities for filter bypass

Even when common payloads are blocked, allowed characters may still be combined into a working exploit.

Injection Context Example

<a href="INJECTION_HERE">...</a>

In this case, the injection occurs inside an HTML attribute context, making certain characters critical:

• " → breaks out of the attribute
• > → closes the tag
• on*= → introduces event handlers
• javascript: → enables script execution

The matrix helps determine whether these vectors are viable based on observed filtering behavior.