Alright, let’s break down this ASP.NET security issue flagged in your scan report—it’s a classic gotcha related to URL path handling and form action rendering:

Vulnerability Breakdown #

Your scan uncovered two linked security problems:

• A URL parameter-based cross-site scripting (XSS) vulnerability with plaintext attack code 22746
• ASP.NET form action attribute tampering triggered by simple URL manipulation

How the Vulnerability Triggers #

Here’s a concrete example to show exactly how this works:

• Normal application URL: https://example.com/default.aspx
• When a user (or attacker) visits https://example.com/default.aspx/1234, the vulnerability activates
• Inspecting the page’s HTML will reveal the form’s action has been altered to ./1234, like this snippet:

<form id="aspnetForm" action="./1234" method="post">
  <!-- Rest of form content -->
</form>

Root Cause & Associated Risks #

ASP.NET has a default behavior where it automatically uses the "path info" (the segment after the .aspx filename in the URL) to populate the form’s action attribute. The critical flaw here is:

• No validation or encoding is applied to this path info, so malicious content (like script tags) can be injected directly into the page’s HTML, triggering XSS attacks
• Attackers can also tamper with the form’s submission target, potentially redirecting user input to a malicious server or executing unauthorized actions on the application

Fixes to Implement #

You’ve got a few solid, actionable options to patch this issue:

1. Explicitly set the form action
   Skip ASP.NET’s auto-population and manually define the correct action path. For example, in your code-behind:

   Page.Form.Action = Request.Url.AbsolutePath;
   

   Or directly in your .aspx markup:

   <form id="aspnetForm" action="default.aspx" method="post">
   

2. Sanitize path info before use
   If your application does require using path info, sanitize and encode it to prevent injection:

   string safePath = HttpUtility.HtmlEncode(Request.PathInfo);
   Page.Form.Action = safePath;
   

3. Disable path info handling entirely
   If you don’t use path info at all, block this behavior in your web.config:

   <system.web>
     <httpRuntime relaxedUrlToFileSystemMapping="false" />
   </system.web>
   

   You can also set up IIS request filtering rules to block requests with extra path segments after .aspx files.

内容的提问来源于stack exchange，提问作者user3068724