Difference between revisions of ".NET Security Cheat Sheet"
Xandersherry (talk | contribs) (Update hashing guidance) |
Bill Sempf (talk | contribs) m (Added Sam as a contributor.) |
||
(20 intermediate revisions by 5 users not shown) | |||
Line 3: | Line 3: | ||
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- | {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- | ||
− | | valign="top" | + | | valign="top" style="border-right: 1px dotted gray;padding-right:25px;" | |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
== Introduction == | == Introduction == | ||
Line 32: | Line 32: | ||
* Use of the [http://msdn.microsoft.com/en-us/data/ef.aspx Entity Framework] is a very effective [http://msdn.microsoft.com/en-us/library/ms161953(v=sql.105).aspx SQL injection] prevention mechanism. Remember that building your own ''ad hoc'' queries in EF is just as susceptible to SQLi as a plain SQL query. | * Use of the [http://msdn.microsoft.com/en-us/data/ef.aspx Entity Framework] is a very effective [http://msdn.microsoft.com/en-us/library/ms161953(v=sql.105).aspx SQL injection] prevention mechanism. Remember that building your own ''ad hoc'' queries in EF is just as susceptible to SQLi as a plain SQL query. | ||
* When using SQL Server, prefer integrated authentication over SQL authentication. | * When using SQL Server, prefer integrated authentication over SQL authentication. | ||
+ | * Use [https://msdn.microsoft.com/en-us/library/mt163865.aspx Always Encrypted] where possible for sensitive data (SQL Server 2016 and SQL Azure), | ||
=== Encryption === | === Encryption === | ||
* Never, ever write your own encryption. | * Never, ever write your own encryption. | ||
* Use the [http://msdn.microsoft.com/en-us/library/ms995355.aspx Windows Data Protection API (DPAPI)] for secure local storage of sensitive data. | * Use the [http://msdn.microsoft.com/en-us/library/ms995355.aspx Windows Data Protection API (DPAPI)] for secure local storage of sensitive data. | ||
− | |||
* Use a strong hash algorithm. | * Use a strong hash algorithm. | ||
** In .NET (both Framework and Core) the strongest hashing algorithm for general hashing requirements is [http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha512.aspx System.Security.Cryptography.SHA512]. | ** In .NET (both Framework and Core) the strongest hashing algorithm for general hashing requirements is [http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha512.aspx System.Security.Cryptography.SHA512]. | ||
Line 47: | Line 47: | ||
=== General === | === General === | ||
− | |||
* Lock down the config file. | * Lock down the config file. | ||
** Remove all aspects of configuration that are not in use. | ** Remove all aspects of configuration that are not in use. | ||
** Encrypt sensitive parts of the web.config using aspnet_regiis -pe | ** Encrypt sensitive parts of the web.config using aspnet_regiis -pe | ||
+ | |||
+ | * For Click Once applications the .Net Framework should be upgraded to use version 4.6.2 to ensure TLS 1.1/1.2 support. | ||
==ASP.NET Web Forms Guidance== | ==ASP.NET Web Forms Guidance== | ||
Line 58: | Line 59: | ||
* Always use [http://support.microsoft.com/kb/324069 HTTPS]. | * Always use [http://support.microsoft.com/kb/324069 HTTPS]. | ||
* Enable [http://msdn.microsoft.com/en-us/library/system.web.configuration.httpcookiessection.requiressl.aspx requireSSL] on cookies and form elements and [http://msdn.microsoft.com/en-us/library/system.web.configuration.httpcookiessection.httponlycookies.aspx HttpOnly] on cookies in the web.config. | * Enable [http://msdn.microsoft.com/en-us/library/system.web.configuration.httpcookiessection.requiressl.aspx requireSSL] on cookies and form elements and [http://msdn.microsoft.com/en-us/library/system.web.configuration.httpcookiessection.httponlycookies.aspx HttpOnly] on cookies in the web.config. | ||
− | * Implement [ | + | * Implement [https://msdn.microsoft.com/library/h0hfz6fc.aspx customErrors]. |
* Make sure [http://www.iis.net/configreference/system.webserver/tracing tracing] is turned off. | * Make sure [http://www.iis.net/configreference/system.webserver/tracing tracing] is turned off. | ||
* While viewstate isn't always appropriate for web development, using it can provide CSRF mitigation. To make the ViewState protect against CSRF attacks you need to set the [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 ViewStateUserKey]: | * While viewstate isn't always appropriate for web development, using it can provide CSRF mitigation. To make the ViewState protect against CSRF attacks you need to set the [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 ViewStateUserKey]: | ||
Line 114: | Line 115: | ||
{ | { | ||
// Validate the Anti-XSRF token | // Validate the Anti-XSRF token | ||
− | + | if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue || | |
(string)ViewState[AntiXsrfUserNameKey] != (Context.User.Identity.Name ?? String.Empty)) | (string)ViewState[AntiXsrfUserNameKey] != (Context.User.Identity.Name ?? String.Empty)) | ||
{ | { | ||
Line 127: | Line 128: | ||
** In the HTTP Response Headers pane, click Add... in the Actions pane. | ** In the HTTP Response Headers pane, click Add... in the Actions pane. | ||
** In the Add Custom HTTP Response Header dialog box, set the name and value for your custom header, and then click OK. | ** In the Add Custom HTTP Response Header dialog box, set the name and value for your custom header, and then click OK. | ||
+ | ** This is a recommended web.config setup that handles HSTS among other things. | ||
+ | |||
+ | <?xml version="1.0" encoding="UTF-8"?> | ||
+ | <configuration> | ||
+ | <system.web> | ||
+ | <httpRuntime enableVersionHeader="false"/> | ||
+ | </system.web> | ||
+ | <system.webServer> | ||
+ | <security> | ||
+ | <requestFiltering removeServerHeader="true" /> | ||
+ | </security> | ||
+ | <staticContent> | ||
+ | <clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" /> | ||
+ | </staticContent> | ||
+ | <httpProtocol> | ||
+ | <customHeaders> | ||
+ | <add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" /> | ||
+ | <add name="X-Content-Type-Options" value="NOSNIFF" /> | ||
+ | <add name="X-Frame-Options" value="DENY" /> | ||
+ | <add name="X-Permitted-Cross-Domain-Policies" value="master-only"/> | ||
+ | <add name="X-XSS-Protection" value="1; mode=block"/> | ||
+ | <remove name="X-Powered-By"/> | ||
+ | </customHeaders> | ||
+ | </httpProtocol> | ||
+ | <rewrite> | ||
+ | <rules> | ||
+ | <rule name="Redirect to https"> | ||
+ | <match url="(.*)"/> | ||
+ | <conditions> | ||
+ | <add input="{HTTPS}" pattern="Off"/> | ||
+ | <add input="{REQUEST_METHOD}" pattern="^get$|^head$" /> | ||
+ | </conditions> | ||
+ | <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/> | ||
+ | </rule> | ||
+ | </rules> | ||
+ | <outboundRules> | ||
+ | <rule name="Add HSTS Header" enabled="true"> | ||
+ | <match serverVariable="RESPONSE_Strict_Transport_Security" | ||
+ | pattern=".*" /> | ||
+ | <conditions> | ||
+ | <add input="{HTTPS}" pattern="on" ignoreCase="true" /> | ||
+ | </conditions> | ||
+ | <action type="Rewrite" value="max-age=15768000" /> | ||
+ | </rule> | ||
+ | </outboundRules> | ||
+ | </rewrite> | ||
+ | </system.webServer> | ||
+ | </configuration> | ||
+ | |||
* Remove the version header. | * Remove the version header. | ||
Line 137: | Line 187: | ||
=== HTTP validation and encoding === | === HTTP validation and encoding === | ||
− | * Do not disable [http://www.asp.net/whitepapers/request-validation validateRequest] in the web.config or the page setup. This value enables | + | * Do not disable [http://www.asp.net/whitepapers/request-validation validateRequest] in the web.config or the page setup. This value enables limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections. |
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it. | * The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it. | ||
− | * Whitelist allowable values anytime user input is accepted | + | * Whitelist allowable values anytime user input is accepted. |
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString]. | * Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString]. | ||
Line 157: | Line 207: | ||
==ASP.NET MVC Guidance== | ==ASP.NET MVC Guidance== | ||
− | ASP.NET MVC (Model-View-Controller) is a contemporary web application framework that uses more standardized HTTP communication than the Web Forms postback model. | + | ASP.NET MVC (Model-View-Controller) is a contemporary web application framework that uses more standardized HTTP communication than the Web Forms postback model. The OWASP Top 10 lists the most prevalent and dangerous threats to web security in the world today and is reviewed every 3 years. This section is based on this. Your approach to securing your web application should be to start at the top threat A1 below and work down, this will ensure that any time spent on security will be spent most effectively spent and cover the top threats first and lesser threats afterwards. After covering the top 10 it is generally advisable to assess for other threats or get a professionally completed Penetration Test. |
+ | |||
+ | * '''A1 SQL Injection''' | ||
− | + | DO: Using an object relational mapper (ORM) or stored procedures is the most effective way of countering the SQL Injection vulnerability. | |
− | + | ||
− | * | + | DO: Use parameterized queries where a direct sql query must be used. |
+ | |||
+ | e.g. In entity frameworks: | ||
+ | |||
+ | var sql = @"Update [User] SET FirstName = @FirstName WHERE Id = @Id"; | ||
+ | context.Database.ExecuteSqlCommand( | ||
+ | sql, | ||
+ | new SqlParameter("@FirstName", firstname), | ||
+ | new SqlParameter("@Id", id)); | ||
+ | |||
+ | DO NOT: Concatenate strings anywhere in your code and execute them against your database (Known as dynamic sql). NB: You can still accidentally do this with ORMs or Stored procedures so check everywhere. | ||
+ | |||
+ | e.g | ||
+ | string strQry = "SELECT * FROM Users WHERE UserName='" + txtUser.Text + "' AND Password='" + txtPassword.Text + "'"; | ||
+ | EXEC strQry // SQL Injection vulnerability! | ||
+ | |||
+ | DO: Practise Least Privilege - Connect to the database using an account with a minimum set of permissions required to do it's job i.e. not the sa account | ||
− | + | * '''A2 Weak Account management''' | |
− | + | Ensure cookies are sent via httpOnly: | |
− | + | CookieHttpOnly = true, | |
− | + | Reduce the time period a session can be stolen in by reducing session timeout and removing sliding expiration: | |
− | |||
− | + | ExpireTimeSpan = TimeSpan.FromMinutes(60), | |
− | + | SlidingExpiration = false | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/App_Start/Startup.Auth.cs here] for full startup code snippet | |
− | + | Ensure cookie is sent over https in the production environment. This should be enforced in the config transforms: | |
− | |||
− | |||
− | + | <!-- SECURE: Require all custom cookies to travel via SSL --> | |
+ | <httpCookies requireSSL="true" xdt:Transform="SetAttributes(requireSSL)"/> | ||
+ | <authentication> | ||
+ | <forms requireSSL="true" xdt:Transform="SetAttributes(requireSSL)"/> | ||
+ | <!-- SECURE: Authentication cookie should only be passed over SSL --> | ||
+ | </authentication> | ||
+ | Protect LogOn, Registration and password reset methods against brute force attacks by throttling requests (see code below), consider also using ReCaptcha. | ||
+ | [HttpPost] | ||
+ | [AllowAnonymous] | ||
[ValidateAntiForgeryToken] | [ValidateAntiForgeryToken] | ||
− | public | + | '''[AllowXRequestsEveryXSecondsAttribute(Name = "LogOn", Message = "You have performed this action more than {x} times in the last {n} seconds.", Requests = 3, Seconds = 60)]''' |
− | { | + | public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl) |
− | // | + | |
− | } | + | |
+ | Find [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/Attributes/ThrottleAttribute.cs here] the code to prevent throttling | ||
+ | |||
+ | DO NOT: Roll your own authentication or session management, use the one provided by .Net | ||
+ | |||
+ | DO NOT: Tell someone if the account exists on LogOn, Registration or Password reset. Say something like 'Either the username or password was incorrect', or 'If this account exists then a reset token will be sent to the registered email address'. This protects against account enumeration. The feedback to the user should be identical whether or not the account exists, both in terms of content and behaviour: e.g. if the response takes 50% longer when the account is real then membership information can be guessed and tested. | ||
+ | |||
+ | |||
+ | * '''A3 Cross Site Scripting''' | ||
+ | |||
+ | DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists | ||
+ | |||
+ | You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library: | ||
+ | |||
+ | Install-Package AntiXSS | ||
+ | |||
+ | then set in config: | ||
+ | |||
+ | <system.web> | ||
+ | <!-- SECURE: Don't disclose version header in each IIS response, encode ALL output including CSS, JavaScript etc, reduce max request length as mitigation against DOS --> | ||
+ | <httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" /> | ||
+ | |||
+ | DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly. | ||
+ | |||
+ | DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script): | ||
+ | <system.webServer> | ||
+ | <httpProtocol> | ||
+ | <customHeaders> | ||
+ | <add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" /> | ||
+ | ... | ||
+ | |||
+ | * '''A4 Insecure Direct object references''' | ||
+ | |||
+ | When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there | ||
+ | |||
+ | // Insecure | ||
+ | public ActionResult Edit(int id) | ||
+ | { | ||
+ | var user = _context.Users.FirstOrDefault(e => e.Id == id); | ||
+ | return View("Details", new UserViewModel(user); | ||
+ | } | ||
+ | |||
+ | // Secure | ||
+ | public ActionResult Edit(int id) | ||
+ | { | ||
+ | var user = _context.Users.FirstOrDefault(e => e.Id == id); | ||
+ | // Establish user has right to edit the details | ||
+ | if (user.Id != _userIdentity.GetUserId()) | ||
+ | { | ||
+ | HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details")); | ||
+ | return View("Error", error); | ||
+ | } | ||
+ | return View("Edit", new UserViewModel(user); | ||
+ | } | ||
+ | |||
+ | * '''A5 Security Misconfiguration''' | ||
+ | |||
+ | Ensure debug and trace are off in production. This can be enforced using web.config transforms: | ||
+ | |||
+ | <!-- SECURE: Ensure debug information is turned off in production --> | ||
+ | <compilation xdt:Transform="RemoveAttributes(debug)" /> | ||
+ | <!-- SECURE: Ensure trace is turned off in production --> | ||
+ | <trace enabled="false" xdt:Transform="Replace"/> | ||
+ | |||
+ | DO NOT: Use default passwords | ||
+ | |||
+ | DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs: | ||
+ | |||
+ | protected void Application_BeginRequest() | ||
+ | { | ||
+ | #if !DEBUG | ||
+ | // SECURE: Ensure any request is returned over SSL/TLS in production | ||
+ | if (!Request.IsLocal && !Context.Request.IsSecureConnection) { | ||
+ | var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:"); | ||
+ | Response.Redirect(redirect); | ||
+ | } | ||
+ | #endif | ||
+ | } | ||
+ | |||
+ | * '''A6 Sensitive data exposure''' | ||
+ | |||
+ | DO NOT: Store encrypted passwords. | ||
+ | |||
+ | DO: Use a strong hash to store password credentials. Use PBKDF2, BCrypt or SCrypt with at least 8000 iterations and a strong key. | ||
+ | |||
+ | DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy. | ||
+ | |||
+ | DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly. | ||
+ | |||
+ | DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org]. | ||
+ | |||
+ | DO NOT: Allow SSL, this is now obsolete | ||
+ | |||
+ | DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test] | ||
+ | |||
+ | DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders] or disable via web.config: | ||
+ | <system.web> | ||
+ | <httpRuntime enableVersionHeader="false"/> | ||
+ | </system.web> | ||
+ | <system.webServer> | ||
+ | <security> | ||
+ | <requestFiltering removeServerHeader="true" /> | ||
+ | </security> | ||
+ | <httpProtocol> | ||
+ | <customHeaders> | ||
+ | <add name="X-Content-Type-Options" value="NOSNIFF" /> | ||
+ | <add name="X-Frame-Options" value="DENY" /> | ||
+ | <add name="X-Permitted-Cross-Domain-Policies" value="master-only"/> | ||
+ | <add name="X-XSS-Protection" value="1; mode=block"/> | ||
+ | <remove name="X-Powered-By"/> | ||
+ | </customHeaders> | ||
+ | </httpProtocol> | ||
+ | |||
+ | * '''A7 Missing function level access control''' | ||
+ | |||
+ | DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level: | ||
+ | |||
+ | [Authorize(Roles = "Admin")] | ||
+ | [HttpGet] | ||
+ | public ActionResult Index(int page = 1) | ||
+ | |||
+ | or better yet, at controller level: | ||
+ | |||
+ | [Authorize] | ||
+ | public class UserController | ||
+ | |||
+ | You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName) | ||
+ | |||
+ | * '''A8 Cross site request forgery''' | ||
+ | |||
+ | DO: Send the anti-forgery token with every Post/Put request: | ||
+ | using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" })) | ||
+ | { | ||
+ | @Html.AntiForgeryToken() | ||
+ | <ul class="nav nav-pills"> | ||
+ | <li role="presentation">Logged on as @User.Identity.Name | ||
+ | <li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li> | ||
+ | </ul> | ||
+ | } | ||
+ | |||
+ | Then validate it at the method or preferably the controller level: | ||
+ | |||
+ | [HttpPost] | ||
+ | '''[ValidateAntiForgeryToken]''' | ||
+ | public ActionResult LogOff() | ||
+ | |||
+ | Make sure the tokens are removed completely for invalidation on logout. | ||
+ | |||
+ | /// <summary> | ||
+ | /// SECURE: Remove any remaining cookies including Anti-CSRF cookie | ||
+ | /// </summary> | ||
+ | public void RemoveAntiForgeryCookie(Controller controller) | ||
+ | { | ||
+ | string[] allCookies = controller.Request.Cookies.AllKeys; | ||
+ | foreach (string cookie in allCookies) | ||
+ | { | ||
+ | if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken") | ||
+ | { | ||
+ | controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1); | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | |||
+ | NB: You will need to attach the anti-forgery token to Ajax requests. | ||
+ | |||
+ | After .NET Core 2.0 it is possible to automatically generate and verify the antiforgery token. Forms must have the requisite helper as seen here: | ||
+ | |||
+ | <form action="RelevantAction" > | ||
+ | @Html.AntiForgeryToken() | ||
+ | </form> | ||
+ | |||
+ | And then add the [AutoValidateAntiforgeryToken] attribute to the action result. | ||
+ | |||
+ | * '''A9 Using components with known vulnerabilities''' | ||
+ | |||
+ | DO: Keep the .Net framework updated with the latest patches | ||
+ | |||
+ | DO: Keep your NuGet packages up to date, many will contain their own vulnerabilities. | ||
+ | |||
+ | DO: Run the OWASP Dependency checker against your application as part of your build process and act on any high level vulnerabilities. [[https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Checker]] | ||
+ | |||
+ | * '''A10 Unvalidated redirects and forwards''' | ||
+ | |||
+ | A protection against this was introduced in Mvc 3 template. Here is the code: | ||
+ | |||
+ | public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl) | ||
+ | { | ||
+ | if (ModelState.IsValid) | ||
+ | { | ||
+ | var logonResult = await _userManager.TryLogOnAsync(model.UserName, model.Password); | ||
+ | if (logonResult.Success) | ||
+ | { | ||
+ | await _userManager.LogOnAsync(logonResult.UserName, model.RememberMe); | ||
+ | return RedirectToLocal(returnUrl); | ||
+ | .... | ||
+ | |||
+ | private ActionResult RedirectToLocal(string returnUrl) | ||
+ | { | ||
+ | if (Url.IsLocalUrl(returnUrl)) | ||
+ | { | ||
+ | return Redirect(returnUrl); | ||
+ | } | ||
+ | else | ||
+ | { | ||
+ | return RedirectToAction("Landing", "Account"); | ||
+ | } | ||
+ | } | ||
+ | |||
+ | Other advice: | ||
+ | |||
+ | * Protect against Clickjacking and man in the middle attack from capturing an initial Non-TLS request, set the X-Frame-Options and Strict-Transport-Security (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here] | ||
+ | * Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload] | ||
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API. | * Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API. | ||
+ | |||
+ | More information: | ||
+ | |||
+ | For more information on all of the above and code samples incorporated into a sample MVC5 application with an enhanced security baseline go to [http://github.com/johnstaveley/SecurityEssentials/ Security Essentials Baseline project] | ||
==XAML Guidance== | ==XAML Guidance== | ||
Line 222: | Line 500: | ||
== Authors and Primary Editors == | == Authors and Primary Editors == | ||
− | Bill Sempf - bill.sempf(at)owasp.org<br/> | + | Bill Sempf - bill.sempf(at)owasp.org<br /> |
− | Troy Hunt - troyhunt(at)hotmail.com<br/> | + | Troy Hunt - troyhunt(at)hotmail.com<br /> |
Jeremy Long - jeremy.long(at)owasp.org<br /> | Jeremy Long - jeremy.long(at)owasp.org<br /> | ||
+ | |||
+ | == Contributors == | ||
+ | |||
+ | Shane Murnion | ||
+ | John Staveley | ||
+ | Steve Bamelis | ||
+ | Xander Sherry | ||
+ | Sam Ferree | ||
== Other Cheatsheets == | == Other Cheatsheets == | ||
Line 232: | Line 518: | ||
|} | |} | ||
− | [[Category:Cheatsheets]][[Category:OWASP .NET Project]] | + | [[Category:Cheatsheets]] |
+ | [[Category:OWASP .NET Project]] |
Revision as of 15:56, 3 August 2018
Last revision (mm/dd/yy): 08/3/2018 IntroductionThis page intends to provide quick basic .NET security tips for developers. The .NET FrameworkThe .NET Framework is Microsoft's principal platform for enterprise development. It is the supporting API for ASP.NET, Windows Desktop applications, Windows Communication Foundation services, SharePoint, Visual Studio Tools for Office and other technologies. Updating the FrameworkThe .NET Framework is kept up-to-date by Microsoft with the Windows Update service. Developers do not normally need to run seperate updates to the Framework. Windows update can be accessed at Windows Update or from the Windows Update program on a Windows computer. Individual frameworks can be kept up to date using NuGet. As Visual Studio prompts for updates, build it into your lifecycle. Remember that third party libraries have to be updated separately and not all of them use Nuget. ELMAH for instance, requires a separate update effort. .NET Framework GuidanceThe .NET Framework is the set of APIs that support an advanced type system, data, graphics, network, file handling and most of the rest of what is needed to write enterprise apps in the Microsoft ecosystem. It is a nearly ubiquitous library that is strong named and versioned at the assembly level. Data Access
Encryption
General
ASP.NET Web Forms GuidanceASP.NET Web Forms is the original browser-based application development API for the .NET framework, and is still the most common enterprise platform for web application development.
protected override OnInit(EventArgs e) { base.OnInit(e); ViewStateUserKey = Session.SessionID; } If you don't use Viewstate, then look to the default master page of the ASP.NET Web Forms default template for a manual anti-CSRF token using a double-submit cookie. private const string AntiXsrfTokenKey = "__AntiXsrfToken"; private const string AntiXsrfUserNameKey = "__AntiXsrfUserName"; private string _antiXsrfTokenValue; protected void Page_Init(object sender, EventArgs e) { // The code below helps to protect against XSRF attacks var requestCookie = Request.Cookies[AntiXsrfTokenKey]; Guid requestCookieGuidValue; if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue)) { // Use the Anti-XSRF token from the cookie _antiXsrfTokenValue = requestCookie.Value; Page.ViewStateUserKey = _antiXsrfTokenValue; } else { // Generate a new Anti-XSRF token and save to the cookie _antiXsrfTokenValue = Guid.NewGuid().ToString("N"); Page.ViewStateUserKey = _antiXsrfTokenValue; var responseCookie = new HttpCookie(AntiXsrfTokenKey) { HttpOnly = true, Value = _antiXsrfTokenValue }; if (FormsAuthentication.RequireSSL && Request.IsSecureConnection) { responseCookie.Secure = true; } Response.Cookies.Set(responseCookie); } Page.PreLoad += master_Page_PreLoad; } protected void master_Page_PreLoad(object sender, EventArgs e) { if (!IsPostBack) { // Set Anti-XSRF token ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey; ViewState[AntiXsrfUserNameKey] = Context.User.Identity.Name ?? String.Empty; } else { // Validate the Anti-XSRF token if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue || (string)ViewState[AntiXsrfUserNameKey] != (Context.User.Identity.Name ?? String.Empty)) { throw new InvalidOperationException("Validation of Anti-XSRF token failed."); } } }
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.web> <httpRuntime enableVersionHeader="false"/> </system.web> <system.webServer> <security> <requestFiltering removeServerHeader="true" /> </security> <staticContent> <clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" /> </staticContent> <httpProtocol> <customHeaders> <add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" /> <add name="X-Content-Type-Options" value="NOSNIFF" /> <add name="X-Frame-Options" value="DENY" /> <add name="X-Permitted-Cross-Domain-Policies" value="master-only"/> <add name="X-XSS-Protection" value="1; mode=block"/> <remove name="X-Powered-By"/> </customHeaders> </httpProtocol> <rewrite> <rules> <rule name="Redirect to https"> <match url="(.*)"/> <conditions> <add input="{HTTPS}" pattern="Off"/> <add input="{REQUEST_METHOD}" pattern="^get$|^head$" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/> </rule> </rules> <outboundRules> <rule name="Add HSTS Header" enabled="true"> <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" /> <conditions> <add input="{HTTPS}" pattern="on" ignoreCase="true" /> </conditions> <action type="Rewrite" value="max-age=15768000" /> </rule> </outboundRules> </rewrite> </system.webServer> </configuration>
<httpRuntime enableVersionHeader="false" />
HttpContext.Current.Response.Headers.Remove("Server"); HTTP validation and encoding
Forms authentication
ASP.NET MVC GuidanceASP.NET MVC (Model-View-Controller) is a contemporary web application framework that uses more standardized HTTP communication than the Web Forms postback model. The OWASP Top 10 lists the most prevalent and dangerous threats to web security in the world today and is reviewed every 3 years. This section is based on this. Your approach to securing your web application should be to start at the top threat A1 below and work down, this will ensure that any time spent on security will be spent most effectively spent and cover the top threats first and lesser threats afterwards. After covering the top 10 it is generally advisable to assess for other threats or get a professionally completed Penetration Test.
DO: Using an object relational mapper (ORM) or stored procedures is the most effective way of countering the SQL Injection vulnerability. DO: Use parameterized queries where a direct sql query must be used. e.g. In entity frameworks: var sql = @"Update [User] SET FirstName = @FirstName WHERE Id = @Id"; context.Database.ExecuteSqlCommand( sql, new SqlParameter("@FirstName", firstname), new SqlParameter("@Id", id)); DO NOT: Concatenate strings anywhere in your code and execute them against your database (Known as dynamic sql). NB: You can still accidentally do this with ORMs or Stored procedures so check everywhere. e.g string strQry = "SELECT * FROM Users WHERE UserName='" + txtUser.Text + "' AND Password='" + txtPassword.Text + "'"; EXEC strQry // SQL Injection vulnerability! DO: Practise Least Privilege - Connect to the database using an account with a minimum set of permissions required to do it's job i.e. not the sa account
Ensure cookies are sent via httpOnly: CookieHttpOnly = true, Reduce the time period a session can be stolen in by reducing session timeout and removing sliding expiration: ExpireTimeSpan = TimeSpan.FromMinutes(60), SlidingExpiration = false See here for full startup code snippet Ensure cookie is sent over https in the production environment. This should be enforced in the config transforms: <httpCookies requireSSL="true" xdt:Transform="SetAttributes(requireSSL)"/> <authentication> <forms requireSSL="true" xdt:Transform="SetAttributes(requireSSL)"/> </authentication> Protect LogOn, Registration and password reset methods against brute force attacks by throttling requests (see code below), consider also using ReCaptcha. [HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] [AllowXRequestsEveryXSecondsAttribute(Name = "LogOn", Message = "You have performed this action more than {x} times in the last {n} seconds.", Requests = 3, Seconds = 60)] public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl)
DO NOT: Roll your own authentication or session management, use the one provided by .Net DO NOT: Tell someone if the account exists on LogOn, Registration or Password reset. Say something like 'Either the username or password was incorrect', or 'If this account exists then a reset token will be sent to the registered email address'. This protects against account enumeration. The feedback to the user should be identical whether or not the account exists, both in terms of content and behaviour: e.g. if the response takes 50% longer when the account is real then membership information can be guessed and tested.
DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library: Install-Package AntiXSS then set in config: <system.web> <httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" /> DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly. DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script): <system.webServer> <httpProtocol> <customHeaders> <add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" /> ...
When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there // Insecure public ActionResult Edit(int id) { var user = _context.Users.FirstOrDefault(e => e.Id == id); return View("Details", new UserViewModel(user); } // Secure public ActionResult Edit(int id) { var user = _context.Users.FirstOrDefault(e => e.Id == id); // Establish user has right to edit the details if (user.Id != _userIdentity.GetUserId()) { HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details")); return View("Error", error); } return View("Edit", new UserViewModel(user); }
Ensure debug and trace are off in production. This can be enforced using web.config transforms: <compilation xdt:Transform="RemoveAttributes(debug)" /> <trace enabled="false" xdt:Transform="Replace"/> DO NOT: Use default passwords DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs: protected void Application_BeginRequest() { #if !DEBUG // SECURE: Ensure any request is returned over SSL/TLS in production if (!Request.IsLocal && !Context.Request.IsSecureConnection) { var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:"); Response.Redirect(redirect); } #endif }
DO NOT: Store encrypted passwords. DO: Use a strong hash to store password credentials. Use PBKDF2, BCrypt or SCrypt with at least 8000 iterations and a strong key. DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy. DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly. DO: Use TLS 1.2 for your entire site. Get a free certificate from StartSSL.com or LetsEncrypt.org. DO NOT: Allow SSL, this is now obsolete DO: Have a strong TLS policy (see SSL Best Practises), use TLS 1.2 wherever possible. Then check the configuration using SSL Test DO: Ensure headers are not disclosing information about your application. See HttpHeaders.cs , Dionach StripHeaders or disable via web.config: <system.web> <httpRuntime enableVersionHeader="false"/> </system.web> <system.webServer> <security> <requestFiltering removeServerHeader="true" /> </security> <httpProtocol> <customHeaders> <add name="X-Content-Type-Options" value="NOSNIFF" /> <add name="X-Frame-Options" value="DENY" /> <add name="X-Permitted-Cross-Domain-Policies" value="master-only"/> <add name="X-XSS-Protection" value="1; mode=block"/> <remove name="X-Powered-By"/> </customHeaders> </httpProtocol>
DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level: [Authorize(Roles = "Admin")] [HttpGet] public ActionResult Index(int page = 1) or better yet, at controller level: [Authorize] public class UserController You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)
DO: Send the anti-forgery token with every Post/Put request: using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" })) { @Html.AntiForgeryToken() <ul class="nav nav-pills"> <li role="presentation">Logged on as @User.Identity.Name <li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li> </ul> } Then validate it at the method or preferably the controller level: [HttpPost] [ValidateAntiForgeryToken] public ActionResult LogOff() Make sure the tokens are removed completely for invalidation on logout. /// <summary> /// SECURE: Remove any remaining cookies including Anti-CSRF cookie /// </summary> public void RemoveAntiForgeryCookie(Controller controller) { string[] allCookies = controller.Request.Cookies.AllKeys; foreach (string cookie in allCookies) { if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken") { controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1); } } } NB: You will need to attach the anti-forgery token to Ajax requests. After .NET Core 2.0 it is possible to automatically generate and verify the antiforgery token. Forms must have the requisite helper as seen here: <form action="RelevantAction" > @Html.AntiForgeryToken() </form> And then add the [AutoValidateAntiforgeryToken] attribute to the action result.
DO: Keep the .Net framework updated with the latest patches DO: Keep your NuGet packages up to date, many will contain their own vulnerabilities. DO: Run the OWASP Dependency checker against your application as part of your build process and act on any high level vulnerabilities. [OWASP Dependency Checker]
A protection against this was introduced in Mvc 3 template. Here is the code: public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl) { if (ModelState.IsValid) { var logonResult = await _userManager.TryLogOnAsync(model.UserName, model.Password); if (logonResult.Success) { await _userManager.LogOnAsync(logonResult.UserName, model.RememberMe); return RedirectToLocal(returnUrl); .... private ActionResult RedirectToLocal(string returnUrl) { if (Url.IsLocalUrl(returnUrl)) { return Redirect(returnUrl); } else { return RedirectToAction("Landing", "Account"); } } Other advice:
More information: For more information on all of the above and code samples incorporated into a sample MVC5 application with an enhanced security baseline go to Security Essentials Baseline project XAML Guidance
Windows Forms Guidance
WCF Guidance
Authors and Primary EditorsBill Sempf - bill.sempf(at)owasp.org ContributorsShane Murnion John Staveley Steve Bamelis Xander Sherry Sam Ferree Other Cheatsheets |