rules-csharp

BinaryFormatter and related formatters deserialize arbitrary types and are a well-known RCE vector. Microsoft has deprecated them. Use System.Text.Json or protobuf instead.

RISK: a file operation keyed off a raw deep-link / pipe argv token enables path traversal and arbitrary read/write/delete in the user's profile — the forwarded-argv path is attacker-influenced (any local user can write the 'sigmashake-desktop' pipe). FIX: canonicalize with Path.GetFullPath, assert the result StartsWith the expected base dir (e.g. the rules/workspace root) using StringComparison.OrdinalIgnoreCase, and require the .rules extension before touching the filesystem.

RISK: passing a deep-link / forwarded-pipe argv value straight into Process.Start (or ProcessStartInfo.FileName) lets an attacker who controls a sigmashake:// URL or the named-pipe payload launch an arbitrary executable in the user's session — RouteArgv treats these tokens as untrusted input. FIX: never spawn from argv; route deep links to in-app navigation only (DesktopApp routes them to ShowMainWindow). If a value MUST become a file path, validate it: reject schemes, require it to end in .rules, and confirm Path.GetFullPath(value) stays under an allowed base directory.

RISK: .GetAwaiter().GetResult() synchronously blocks on a Task and rethrows unwrapped — under a UI/request SynchronizationContext it deadlocks the same way .Result does, and it hides the async call graph. FIX: propagate async — make the caller `async Task` and `await` instead. Reserve sync-over-async for the documented top-of-stack `Main`/installer shim, never inside UI callbacks or RPC handlers.

Hardcoded connection strings expose database credentials in source control. Store connection strings in environment variables or a secrets manager and retrieve via IConfiguration.

RISK: writing under HKEY_LOCAL_MACHINE from a per-user, non-elevated app throws UnauthorizedAccessException at best, and where it does succeed (a misconfigured ACL) it grants a machine-wide persistence/escalation foothold any local user benefits from. SigmaShake Desktop deliberately registers deep-link + autostart + file-association under HKCU only. FIX: use Registry.CurrentUser (HKCU\Software\Classes / HKCU\...\Run) like DeepLink/Autostart/FileAssociation do; reserve HKLM for an elevated installer with an explicitly-scoped ACL.

RISK: Json.NET TypeNameHandling.All/.Auto/.Objects embeds and instantiates CLR types named in the JSON ($type), a well-documented deserialization RCE vector (e.g. ObjectDataProvider gadgets) — the pipe listener already JsonSerializer.Deserialize's attacker-reachable input. FIX: keep TypeNameHandling.None (the default), deserialize into concrete known DTOs (string[] for forwarded argv), and prefer System.Text.Json which has no polymorphic type resolution unless you opt in with a vetted JsonDerivedType allow-list.

String interpolation/concatenation in LDAP filters enables LDAP injection. Escape user input with Encoder.LdapFilterEncode() before including it in a filter string.

MD5 and SHA-1 are cryptographically broken and must not be used for password hashing or data integrity. Use SHA-256 or higher, and for passwords use BCrypt, PBKDF2, or Argon2.

RISK (CWE-280): a NamedPipeServerStream created without a PipeSecurity ACL is reachable by ANY local user, who can then connect and inject forwarded argv — the single-instance pipe 'sigmashake-desktop' routes that payload into RouteArgv, so an unprivileged local attacker drives deep-link/.rules opens in your session. FIX: build a PipeSecurity granting only ReadWrite to WindowsIdentity.GetCurrent().Owner (or a PipeAccessRule for the current SID) and pass it via NamedPipeServerStreamAcl.Create(...); deny everyone else.

File operations with user-controlled paths enable path traversal. Validate that Path.GetFullPath(userInput) starts with the expected base directory before performing file operations.

RISK: constructing `new HttpClient()` per request and disposing it leaks sockets — each instance holds its connection in TIME_WAIT for ~240s, so a busy loop (the updater's latest.json poll, daemon port probes) exhausts ephemeral ports with SocketException 'address already in use'. FIX: use IHttpClientFactory (CreateClient), or share one long-lived `static readonly HttpClient` for the process and set PooledConnectionLifetime on a SocketsHttpHandler to honor DNS changes.

RISK: Process.Start via cmd.exe/powershell/bash, or ProcessStartInfo.UseShellExecute = true, passes the command line through a shell that performs metacharacter expansion — interpolated input enables command injection (CWE-78). NOTE: UseShellExecute=true is the correct ShellExecute path ONLY for opening a vetted URL/document (as OpenExternal does for https://sigmashake.com); never combine it with attacker-influenced argv. FIX: set UseShellExecute = false, FileName to the explicit executable, and add each argument via ProcessStartInfo.ArgumentList (no manual quoting, no shell).

String concatenation in SQL commands enables SQL injection. Use parameterized queries with SqlParameter or an ORM like Entity Framework.

RISK: blocking on a Task with .Result or .Wait() in an app with a SynchronizationContext (WinForms/WPF/ASP.NET) deadlocks when the awaited continuation needs the captured context that the blocked thread holds, and elsewhere starves the thread pool. The DesktopApp UI thread (WindowsFormsSynchronizationContext) is exactly this case. FIX: make the method async and `await` the Task; if a sync entry point is unavoidable use Task.Run(() => asyncWork()).GetAwaiter().GetResult() off the UI thread, and add .ConfigureAwait(false) in library code.

RISK: a ServerCertificateCustomValidationCallback (or ServicePointManager.ServerCertificateValidationCallback) that returns true accepts ANY certificate, disabling TLS authentication — every HTTPS call (the updater fetching latest.json + the signed installer from download.sigmashake.com) becomes MITM-able, letting an attacker swap in a malicious signed update. FIX: remove the override and trust the OS store; to pin a specific cert, compare chain/thumbprint against an expected value and return false on mismatch — never an unconditional true.

RISK: AddHostObjectToScript projects a live .NET object into page JavaScript; any script the WebView2 loads (including an XSS in the localhost dashboard or a redirected origin) can call its methods and reflect over its members, turning a web bug into native code execution. FIX: prefer the message-passing bridge (WebMessageReceived + PostWebMessageAsJson, as ViewBridge does) over a host object; if a host object is truly required, expose a tiny COM-visible facade with no filesystem/process surface and gate it to the bundled origin via AddWebAllowedObject + an origin check.

RISK: forcing CoreWebView2Settings.AreDevToolsEnabled = true ships an open inspector/console over the WebView2 surface — when that surface loads remote/untrusted content (the dashboard at http://127.0.0.1:<port>, or any non-local origin) it exposes the host-bridge RPC channel and the dashboard token to anyone who can reach the page. FIX: gate devtools behind a dev-only env flag exactly as WebHost.MapAppRoot does (AreDevToolsEnabled=false + AreDefaultContextMenusEnabled=false in release), and never enable it on a window that navigates beyond the bundled app.sigmashake.local origin.

RISK: leaving IsScriptEnabled / AreHostObjectsAllowed true on a WebView2 that renders untrusted content lets injected page script run and reach any exposed host object — a single XSS in remote content then pivots into the C# host. FIX: only enable scripting for content you fully control (the bundled setup/wizard views under app.sigmashake.local); for any remote origin keep scripting off or strip host-object access, and validate the navigation origin in a NavigationStarting handler before allowing it.

RISK: XML parsing with DTD/external-entity resolution enabled is vulnerable to XXE (CWE-611) — file disclosure and SSRF via crafted DOCTYPE entities. DtdProcessing.Parse, an XmlUrlResolver, ProhibitDtd=false, or an XmlReaderSettings/XmlDocument left at its default resolver all open it. FIX: set XmlReaderSettings.DtdProcessing = DtdProcessing.Prohibit (or .Ignore) AND XmlResolver = null; for XmlDocument set XmlResolver = null before Load.