Missing Tls in Aspnet
How Missing TLS Manifests in ASP.NET
Missing TLS in ASP.NET applications creates multiple attack vectors that are particularly dangerous in .NET environments. When HTTPS is not enforced, attackers can exploit several ASP.NET-specific vulnerabilities.
One common scenario involves session hijacking through ASP.NET's default cookie behavior. By default, ASP.NET session cookies don't require the 'secure' flag, meaning they can be transmitted over HTTP. An attacker performing a man-in-the-middle attack can intercept these cookies when users access the application over unencrypted connections. This is especially problematic in development environments where developers often run applications over HTTP for convenience.
Another manifestation occurs with ASP.NET's Forms Authentication. When configured without HTTPS enforcement, authentication tickets can be transmitted in plaintext. The FormsAuthenticationModule generates authentication cookies that, without the secure flag, are vulnerable to network sniffing. This is particularly concerning in shared hosting environments or corporate networks where traffic might be monitored.
ASP.NET Web API endpoints are also vulnerable when TLS is missing. Without HTTPS, API keys and tokens transmitted in HTTP headers or query parameters can be captured by network observers. This is especially problematic for applications using JWT tokens or API keys for authentication, as these credentials can be reused by attackers to impersonate legitimate users.
Configuration-based attacks are another concern. ASP.NET applications often store sensitive configuration data in web.config files. When served over HTTP, attackers can modify configuration values in transit, potentially enabling debug mode, altering connection strings, or changing authentication providers. The customErrors setting in web.config can also be manipulated to expose stack traces and sensitive error information.
ASP.NET-Specific Detection
Detecting missing TLS in ASP.NET applications requires examining both configuration and runtime behavior. Start by inspecting the web.config file for HTTPS-related settings. Look for the system.webServer section where URL rewrite rules for HTTPS enforcement should be configured.
<system.webServer>
<rewrite>
<rules>
<rule name="Force HTTPS" enabled="true" stopProcessing="true">
<match url="(.*)" ignoreCase="false" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:0}" appendQueryString="true" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>Also check the system.web section for authentication and session configuration. The authentication element should specify secure cookie requirements, and sessionState should be configured appropriately.
Runtime detection involves checking the Request.IsSecureConnection property in your ASP.NET code. If this returns false when it should be true, you have a TLS enforcement problem. You can also examine the Request.Url.Scheme property to verify HTTPS usage.
For automated detection, middleBrick's scanner specifically tests ASP.NET applications for missing TLS. It attempts to access your API endpoints over HTTP and analyzes the responses for security headers, cookie flags, and authentication mechanisms. The scanner checks for the absence of HSTS headers, missing secure flags on cookies, and the ability to access authenticated endpoints without HTTPS.
middleBrick's LLM security module also detects if your ASP.NET application has AI endpoints that might be exposed over HTTP, potentially leaking system prompts or training data. This is particularly relevant for ASP.NET applications using ML.NET or integrated AI services.
ASP.NET-Specific Remediation
Remediating missing TLS in ASP.NET requires a multi-layered approach. Start with configuration changes in web.config. Add URL rewrite rules to force HTTPS redirection and configure HSTS headers.
<system.webServer>
<rewrite>
<rules>
<rule name="Force HTTPS" enabled="true" stopProcessing="true">
<match url="(.*)" ignoreCase="false" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:0}" appendQueryString="true" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
</customHeaders>
</httpProtocol>
</system.webServer>In your ASP.NET application code, implement HTTPS enforcement at the controller level using attributes:
public class SecureController : ApiController
{
[RequireHttps] // This attribute enforces HTTPS
public IHttpActionResult GetSecureData()
{
if (!Request.IsSecureConnection)
{
return StatusCode(HttpStatusCode.Forbidden);
}
return Ok("Secure data");
}
}For ASP.NET Core applications, use middleware for HTTPS redirection:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseHttpsRedirection();
app.UseHsts(options => options.MaxAge(days: 365).IncludeSubdomains());
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}Configure authentication to use secure cookies:
public void ConfigureServices(IServiceCollection services)
{
services.AddAuthentication(options =>
{
options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie(options =>
{
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
options.Cookie.SameSite = SameSiteMode.Strict;
options.LoginPath = "/Account/Login";
});
}Finally, implement certificate validation and pinning for API communications. In ASP.NET, you can use HttpClientHandler with custom validation:
var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) =>
{
// Custom validation logic
return errors == SslPolicyErrors.None;
};
var client = new HttpClient(handler);
var response = await client.GetAsync("https://your-api.com");Related CWEs: encryption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |