.NET / C# source review
SkillDocs & knowledgeSecurity review of .NET / C# code, dangerous sinks and ASP.NET pitfalls. Load when reviewing a C#/.NET codebase/PR, on .cs source in scope, or "review this .NET app". Signals: .csproj/.sln, ASP.NET (Core/MVC/WebForms), BinaryFormatter, SqlCommand, Razor Html.Raw, XmlDocument.
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; ahel provides instructions and does not run this skill.
Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.
Then ask your AI: use the .NET / C# source review skill
What this skill tells your AI
The instructions your AI receives, as published by noorqureshi/sploitagent in skills/code-review/code-review-dotnet/SKILL.md and read by ahel’s review.
When it applies
Reviewing C#/.NET source (ASP.NET Core, MVC, or legacy WebForms). The headline risks are unsafe deserialization, string-built SQL, XXE, and Razor's raw-output escape hatch.
Why it works
.NET ships powerful-but-dangerous serializers (BinaryFormatter, Json.NET with
TypeNameHandling, LosFormatter/ViewState) that instantiate arbitrary types, and several XML APIs
resolve DTDs by default on older frameworks. Reviews find where these meet untrusted input.
Sinks & patterns (grep, then trace to user input)
- Deserialization:
BinaryFormatter,LosFormatter,SoapFormatter,NetDataContractSerializer,JsonConvertwithTypeNameHandling != None,Js.NET/fastJSONpolymorphic types → RCE gadgets. - SQLi: string-concatenated
SqlCommand/ExecuteReader/FromSqlRaw(EF Core) vs parameters. - Command exec:
Process.Startwith concatenated arguments /UseShellExecute. - XXE:
XmlDocument/XmlReader/XmlTextReaderwithoutDtdProcessing=Prohibit(legacy default resolves entities);XmlSerializerwith a user-controlled type. - XSS: Razor
@Html.Raw(...),MvcHtmlString, WebForms<%= %>with unencoded input;Response.Write. - Other: path traversal via
Path.Combine(root, input),LdapConnectionfilter injection, reflection (Type.GetType/Activator.CreateInstance) on input, insecure ViewState (no MAC).
Framework specifics
- ASP.NET Core: model binding over-posting/mass assignment (bind whole entity),
[AllowAnonymous]on sensitive actions, disabled antiforgery on POST APIs, exposed dev endpoints, open redirect viaRedirect(returnUrl)withoutUrl.IsLocalUrl. - WebForms: ViewState deserialization (machineKey), event-validation off.
Method
- Run
security-code-scan/CodeQL; treat as leads. rg 'BinaryFormatter|TypeNameHandling|FromSqlRaw|Html\.Raw|XmlDocument|Process\.Start'→ trace to input.- Check controller
[Authorize]/antiforgery coverage and model-binding scope. - Confirm with
web-deserialization,web-sqli,web-xxe,web-command-injection.
Gotchas
Json.NETis safe by default — the bug is an explicitTypeNameHandling.All/Auto.- EF Core parameterises LINQ;
FromSqlRaw/ExecuteSqlRawwith interpolation is where SQLi returns. - ViewState RCE needs the
machineKey(leaked/weak) — note the precondition.
References
OWASP .NET security cheat sheet; ysoserial.net gadget research; Microsoft secure-coding guidance.
Signals
- GitHub stars
- 20
- Forks
- 7
- Last commit
- Sep 2026
Advanced
- Item type
- skill
- Key
code-review-dotnet- Source
- github.com/noorqureshi/sploitagent
github.com/noorqureshi/sploitagent
Related picks
Skill · akiojin
The pick for C#tia-csharp-common
Skill · czarnak
The pick for C#legacy-js
Skill · thedaviddias
The pick for JavaScriptmodern-javascript-patterns
Skill · wshobson
The pick for JavaScriptdotnet-test
Skill · nikiforovall
The pick for .NETdotnet-backend-patterns
Skill · wshobson
The pick for .NET