SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsnet-auth-audit

net-auth-audit

Data & analytics

View repository

Updated 10-16 09:53

About this skill

.NET Authentication Mechanism Audit

From .NET / ASP.NET project source code, decompiled artifacts, or net-route-mapper output, sort out the authentication mechanism, cover all routes, pages, and interfaces, identify authentication bypasses, unauthorized access, missing permissions, and resource-level privilege escalation issues, and generate Markdown audit artifacts according to a fixed directory structure.

Applicable and Not Applicable

Applicable:

  • Audit the authentication mechanism of ASP.NET Core / MVC5 / Web API2 / Web Forms / Minimal API / Handler / ASMX
  • Check login state, roles, Policy, Claim, custom permission Attribute, Filter, Middleware, BaseController, Page base class
  • Output the authentication status of each interface based on the route list or source code
  • When a closed-source project only has bin/*.dll、.aspx、web.config , first reuse or generate shared decompiled artifacts before auditing
  • Check horizontal privilege escalation / IDOR / tenant isolation / resource ownership validation

Not Applicable:

  • Only extracting routes and parameters: use net-route-mapper
  • Specialized audits such as SQL injection, XSS, SSRF, file upload, file read
  • Only explaining the principles of JWT / OAuth / Cookie / Session
  • Helping users implement login, registration, permission systems
  • Only auditing frontend menus, button visibility, frontend route guards
  • Only doing code quality, architecture optimization, or general NuGet/CVE dependency checks

Core Rules

  • Must first sort out the project authentication mechanism before drawing vulnerability conclusions.
  • Must cover all routes, pages, and interfaces; must not list only high-risk interfaces, and must not omit using "etc." or "other".
  • Every conclusion must have code evidence or configuration evidence, marking the file, class/method, configuration section, or decompiled artifact path.
  • Must distinguish authentication, role/policy authorization, and resource-level authorization; "login required" does not equal "complete permissions".
  • It is forbidden to determine unauthorized access based solely on an Action lacking [Authorize] ; must check global Filter, FallbackPolicy, DefaultPolicy, middleware, base classes, route groups, and web.config。
  • It is forbidden to treat frontend menus, button hiding, or frontend route guards as backend authorization evidence.
  • It is forbidden to execute destructive requests. PoC can only provide non-destructive verification ideas or HTTP request templates.
  • When risk is high but evidence is incomplete, mark as "to be verified"; must not fabricate vulnerabilities.
  • This Skill does not perform authentication component version/CVE audits unless explicitly extended later.

Workflow

1. Initialize Input

  1. Confirm the input type: source code project, decompiled artifacts,net-route-mapper output, or mixed input.
  2. If there is already net-route-mapper output, prioritize it as the route baseline; otherwise enumerate routes and pages yourself, and do not skip.
  3. Identify the project type: ASP.NET Core, MVC5/Web API2, Web Forms, Minimal API, Handler/ASMX, mixed project.
  4. Read references/AUTH_PATTERNS.md, and locate authentication entry points and search terms according to the project type.

2. Handle Closed-Source or Source-Missing Projects

If the source code is missing, or .aspx / the backend class pointed to by the configuration only exists in the dll:

  1. Prioritize checking {project}_audit/decompiled/manifest.json。
  2. status=success and input_dir matches the current target: directly reuse {project}_audit/decompiled/。
  3. status=partial: the successful assembly can be reused, but the failed items and the incomplete audit scope must be noted in the README and the main report.
  4. Entry assembly failed, manifest missing, mismatched, or unavailable: follow ../net-route-mapper/references/DECOMPILE_STRATEGY.md to perform shared binary preprocessing.
  5. If {project}_audit/deobfuscated/manifest.jsonexists, the README must record its status; decompilation should preferentially be based on deobfuscated/bin_clean/。

Do not maintain another set of decompilation specifications in this Skill; the shared preprocessing artifacts are project-level audit evidence for reuse by multiple net audit skills.

3. Sort out the authentication mechanism

The following mechanism conclusions must be output:

  • Authentication method: Cookie / Session / FormsAuthentication / Windows / JWT Bearer / custom Token / hybrid
  • Authorization method: Role / Policy / Claim / custom permission service / page or controller base class / Filter / Middleware
  • Global rules: FallbackPolicy, DefaultPolicy, GlobalFilters,web.config <authorization>、location path
  • Whitelist and anonymous entry points:[AllowAnonymous]、AllowAnonymous()、permitAll equivalent logic, login page, static resources, health checks, public APIs
  • Resource-level authorization: whether users, tenants, departments, companies, and owner/member relationships are constrained in the service layer or query conditions

4. Generate the authentication mapping

Provide a one-line mapping for each route, page, or interface:

  • Route/page, HTTP method, entry location
  • Authentication status: public, protected, authentication-only, no authentication, uncertain
  • Authentication evidence: Attribute, Filter, Middleware, web.config, base class, code judgment
  • Required role/Policy/Claim
  • Resource-level authorization status
  • Risks and notes

When the status is uncertain, the missing evidence must be explained, and the interface must not be omitted.

5. Vulnerability analysis

Only write vulnerability details into the main report when the evidence chain is satisfied:

  • Reachable entry point is clear
  • The relevant authentication layers have been checked
  • Whether subsequent interception layers exist has been analyzed
  • The impact scope after bypass is clear
  • Missing resource ownership or missing permissions has code evidence

IDOR / horizontal privilege escalation must read references/IDOR_CHECKLIST.md。

Vulnerability numbering and scoring must read ../net-shared/SEVERITY_RATING.md, follow {C/H/M/L}-AUTH-{序号}, for example H-AUTH-001. Each vulnerability must provide R/I/C, Score/CVSS, and the rationale for the determination.

6. Fixed output directory

After the audit is completed, fixed directories and fixed file names must be generated in the style of net-route-mapper , without using timestamped file names:

{project}_audit/auth_audit/
├── README.md                 # 主索引：范围、机制概览、风险统计、产物链接
├── auth_mapping.md           # 全部路由/页面/接口的鉴权状态表
├── auth_findings.md          # 漏洞详情、证据链、PoC、修复建议
└── modules/
    ├── {ModuleA}.md          # 每模块详细鉴权证据和备注
    ├── {ModuleB}.md
    └── ...

Template:

  • Main index:references/OUTPUT_TEMPLATE_README.md → output as README.md
  • Authentication mapping table:references/OUTPUT_TEMPLATE_MAPPING.md → output as auth_mapping.md
  • Vulnerability details:references/OUTPUT_TEMPLATE_MAIN.md → output as auth_findings.md

Division of responsibilities:

  • README.md records the scope, inputs, tools, shared binary manifest, mechanism overview, risk statistics, and artifact links; do not put complete vulnerability details.
  • auth_mapping.md must list all routes/pages/interfaces; do not put detailed vulnerability analysis.
  • auth_findings.md only contains vulnerability details, evidence chains, PoCs, and remediation suggestions; do not put the complete route list.
  • modules/ is used to split authentication evidence by module for large projects; small projects may not generate module files, but the directory structure should remain consistent.

Gotchas

  • ASP.NET Core no longer uses web.config to configure application authentication; focus on Program.cs / Startup.cs / appsettings.json / middleware order.
  • UseAuthentication() Must be before UseAuthorization() ; abnormal order may cause authentication to fail or behavior to deviate.
  • FallbackPolicy / DefaultPolicy may cause interfaces without [Authorize] to be protected by default.
  • MVC5 / Web API2 may apply global authentication through GlobalFilters.Filters.Add(new AuthorizeAttribute()) .
  • Web Forms often places authentication in the Page base class,OnInit、Page_Load, master pages, or web.config location path .
  • OnActionExecuting / IAsyncAuthorizationFilter / custom Attributes may carry out the real permission checks.
  • [AllowAnonymous] is not necessarily a vulnerability; it must be judged in combination with the login page, public resources, health checks, and business public interfaces.
  • .ashx、.asmx, Razor Pages, Minimal API, and MapGroup routes are easy to miss.
  • After decompilation, do not only look at clearly named classes; obfuscated classes, event handlers, and base classes may also contain authentication logic.
  • Checking only login state will miss IDOR; whenever resource identifiers such as userId、tenantId、deptId、companyId、ownerId appear, ownership checks must be traced.

Self-check before completion

  • Project type and input type have been identified
  • Shared decompilation manifest has been reused or generated (closed-source/missing-source scenarios)
  • All routes, pages, and interfaces have been covered
  • Authentication, authorization, whitelists, global rules, and resource-level authorization have been sorted out
  • Every interface has authentication status and evidence
  • Vulnerability conclusions all have code or configuration evidence
  • Frontend permissions have not been treated as backend authorization evidence
  • Generated according to {project}_audit/auth_audit/ fixed directory README.md、auth_mapping.md、auth_findings.md and cross-linked

Maintenance evaluation

Triggering, non-triggering, boundary, and failure cases are maintained in references/EVAL_CASES.md. After modifying the description, workflow, or output template, these examples must be reviewed to ensure the trigger boundary has not become wider or narrower.