Analyzer::Aspnet::WebForms
Inherits Analyzer < FileHelper < Reference < Object
ASP.NET WebForms attack surface.
WebForms is file-path routed: an .aspx page's location under the web
root is its URL. The parameters, however, mostly do not live in the
page — they live in its code-behind and, more often, in the .ascx
user controls the page registers. Across the validation corpus only
~19% of literal request reads sit in page code-behind and 54% sit in
user controls, so a page-only scan would miss most of the surface.
Control reads are therefore attributed to the pages that register
them.
Constants
Collection reads, in both indexer syntaxes. In every pattern below
the closing delimiter must follow the literal immediately:
Request("laauth-" & TabModuleId) builds its key at runtime, and
capturing laauth- from it would invent 216 bogus params.
QueryString / Form / ServerVariables name nothing but an HTTP
request, so any receiver is accepted. That is what catches aliased
locals: kartris's Image.ashx assigns
Dim req As HttpRequest = context.Request and then does ten reads
through req, which a Request-anchored pattern would all miss.
Class declarations, used only to resolve services whose code lives away from the handler file.
A content page's form belongs to its master page. The master is
normally resolved and scanned, so SERVER_FORM_RE finds it there —
but not always: CarrotCake's plugin pages name ~/Site1.Master from
a sibling project the scan base does not contain. Declaring a master
is itself the evidence, since a master page without an HtmlForm is
not a usable master.
WebForms postback plumbing, not user-facing parameters.
Global.asax marks the application root, and unlike CFML's
Application.cfc there is at most one per web app (verified across
the corpus: 1 for kartris, 1 for DNN at DNN Platform/Website/,
0 for the two module-style repos), which makes it a trustworthy
anchor rather than a guess.
Directives span multiple physical lines in real projects, so the
whole <%@ ... %> block is captured rather than the first line.
Requestable handlers. .ascx (user control) and .master (master
page) are composed into pages and are blocked by the default IIS
handler mapping, so they are sources of params but never routes.
Code-behind evidence, for handlers and for pages whose markup carries
no form at all. Reading — or merely enumerating — the form collection
is conclusive: DNN's PayPal IPN receiver has no markup beyond its
directive and does foreach (string strName in this.Request.Form),
which yields no literal parameter name but proves the page is a POST
target. Files and InputStream are only ever populated by one.
Params / Cookies / Headers are ordinary member names — mail
messages, HTTP clients and parsers all expose them — so these must
be anchored to Request. \bRequest\. still covers every receiver
chain (this., context., HttpContext.Current.).
Evidence that a page can act on a POST.
<form runat="server"> is the decisive one — the framework posts
back to the page's own URL — but the tag name has to be matched
loosely, because control libraries subclass HtmlForm: DNN's own
Default.aspx carries <dnn:Form ID="Form" runat="server">, and an
anchored <form missed it.
[WebMethod] / <WebMethod()> on an .asmx service maps to
POST /Service.asmx/MethodName.
Class methods
Instance methods
Instance-side view of the same declaration. The per-file rescues live on
this base class, which has no way to name the analyzer that is running
inside them, so a skipped file could not be attributed to a tech.
Deriving it from analyzer_for keeps the name written exactly once.