我来帮你梳理清楚数值1234（如果换成恶意脚本就会触发漏洞）从URL传递到表单动作的完整路径，以及漏洞是怎么产生的：

• 第一步：用户发起构造后的请求
  假设应用的基础URL是https://example.com/default.aspx，用户在浏览器地址栏输入https://example.com/default.aspx/1234并回车。这里的1234是附加在URL路径末尾的用户可控内容，浏览器会把这个请求发送到服务器。

• 第二步：服务器端解析并获取参数
  服务器上的ASP.NET Web Forms引擎接收到请求后，会解析URL结构。应用的服务器端代码可能通过Request.Url.Segments、Request.PathInfo或者自定义的路由逻辑，把1234这个值提取出来。

• 第三步：未过滤的参数被直接注入表单动作
  这就是漏洞的核心所在：应用的服务器端代码在生成页面的<form>标签时，直接把获取到的1234拼接到了action属性里，完全没有做HTML编码或者输入校验。举个不安全的代码例子：

  // 后台代码（default.aspx.cs）里的危险写法
  form1.Action = Request.PathInfo;
  

  或者前台.aspx页面里直接绑定未编码的值：

  <form runat="server" action='<%= Request.PathInfo %>'>
  

• 第四步：恶意内容被执行，触发XSS
  当服务器把渲染好的HTML返回给浏览器时，表单的action属性就变成了/default.aspx/1234。如果用户输入的不是1234，而是恶意脚本比如</form><script>alert('XSS')</script>，浏览器解析HTML时会先闭合表单标签，然后直接执行注入的脚本，这就触发了跨站脚本漏洞。

要修复这个漏洞其实很简单，ASP.NET Web Forms提供了内置的安全编码方式：要么用HttpUtility.HtmlEncode()对用户输入进行编码后再输出，要么在前台用<%: %>语法（会自动做HTML编码）来绑定值，比如：

<form runat="server" action='<%: Request.PathInfo %>'>

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