OWASP - User contributions [en]

Deserialization Cheat Sheet

2018-08-29T22:42:49Z

Shaneinsweden: Added a .Net section with some .Net tips and .Net references and tools-

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br />
__TOC__{{TOC hidden}}
= Introduction =

This article is focused on providing clear, actionable guidance for safely deserializing untrusted data in your applications.

=What is Deserialization?=

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.

==PHP==
===WhiteBox Review===
Check the use of 'unserialize()' and review how the external parameters are accepted.
Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user.
Please also refer to to http://php.net/manual/en/function.unserialize.php

==Python==
===BlackBox Review===
If the traffic data contains the symbol dot . at the end, it's very likely that the data was sent in serialization.

===WhiteBox Review===
The following API in Python will be vulnerable to serialization attack. Search code for the pattern below.

1. The uses of pickle/c_pickle/_pickle with load/loads
<pre>
import pickle
data = """ cos.system(S'dir')tR. """
pickle.loads(data)
</pre>

2. Uses of PyYAML with load
<pre>
import yaml
document = "!!python/object/apply:os.system ['ipconfig']"
print(yaml.load(document))
</pre>

3. Uses of jsonpickle with encode or store methods

==Java==
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].

Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.

===WhiteBox Review ===
Be aware of the following Java API uses for potential serilization vulnerability.
1. 'XMLdecoder' with external user defined parameters
2. XStream with fromXML method. (xstream version <= v1.46 is vulnerable to the serialization issue.)
3. 'ObjectInputSteam' with 'readObject'
4. Uses of 'readObject' 'readObjectNodData' 'readResolve' 'readExternal'
5. 'ObjectInputStream.readUnshared'
6. 'Serializable'

=== BlackBox Review ===
If the captured traffic data include the following patterns may suggest that the data was sent in Java serialization streams
* "AC ED 00 05" in Hex
* "''rO0" in Base64''
* Content-type = '<nowiki/>''application/x-java-serialized-object'''

===Prevent Data Leakage and Trusted Field Clobbering===
If there are data members of an object that should never be controlled by end users during deserialization or exposed to users during serialization, they should be declared as [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> keyword].

For a class that defined as Serializable, the sensitive information variable should be declared as 'private transient'.
For example, the class myAccount, the variable 'profile' and 'margin' were declared as transient to avoid to be serialized.

<pre>
public class myAccount implements Serializable
{
private transient double profit; // declared transient

private transient double margin; // declared transient
....
....

</pre>

===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.

<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized");
}</pre>

===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:

* You can change the code that does the deserialization
* You know what classes you expect to deserialize

The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow. A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:

<pre>public class LookAheadObjectInputStream extends ObjectInputStream {

public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
super(inputStream);
}

/**
* Only deserialize instances of our expected Bicycle class
*/
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
if (!desc.getName().equals(Bicycle.class.getName())) {
throw new InvalidClassException(
"Unauthorized deserialization attempt",
desc.getName());
}
return super.resolveClass(desc);
}
}</pre>

More complete implementations of this approach have been proposed by various community members:

* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.

===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution.

Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.

To enable these agents, simply add a new JVM parameter:

<pre>-javaagent:name-of-agent.jar</pre>

Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]

A similar, but less scalable approach would be to manually patch and bootstrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].

==.Net C#==

=== WhiteBox Review ===
Search the source code for the following terms<br />

# TypeNameHandling
# JavaScriptTypeResolver

Look for any serializers where the type is set by a user controlled variable.

=== BlackBox Review ===
Search for the following base64 encoded content that starts with:

<pre>AAEAAAD/////</pre>

Search for content with the following text:
# "TypeObject"
# "$type":

=== General Precautions ===

Don't allow the datastream to define the type of object that the stream will be deserialized to. You can prevent this by for example using the '''DataContractSerializer''' or '''XmlSerializer''' if at all possible.

Where '''JSON.Net''' is being used make sure the '''TypeNameHandling''' is only set to '''None'''.

<pre>TypeNameHandling = TypeNameHandling.None</pre>

If '''JavaScriptSerializer''' is to be used do not use it with a '''JavaScriptTypeResolver'''

If you must deserialise data streams that define their own type, then restrict the types that are allowed to be deserialized. One should be aware that this is still risky as many native .Net types potentially dangerous in themselves. e.g.

<pre>System.IO.FileInfo</pre>

FileInfo objects that reference files actually on the server can when deserialized, change the properties of those files e.g. to read-only, creating a potential denial of service attack.<br />

Even if you have limited the types that can be deserialised remember that some types have properties that are risky. '''System.ComponentModel.DataAnnotations.ValidationException''', for example has a property '''Value''' of type '''Object'''. if this type is the type allowed for deserialization then an attacker can set the '''Value''' property to any object type they choose.

Attackers should be prevented from steering the type that will be instantiated. If this is possible then even '''DataContractSerializer''' or '''XmlSerializer''' can be subverted e.g.
<pre>
var typename = GetTransactionTypeFromDatabase(); // <-- this is dangerous if the attacker can change the data in the database

var serializer = new DataContractJsonSerializer(Type.GetType(typename));

var obj = serializer.ReadObject(ms);
</pre>

Execution can occur within certain .Net types during deserialization. Creating a control such as the one shown below is ineffective.

<pre>
var suspectObject = myBinaryFormatter.Deserialize(untrustedData);

if (suspectObject is SomeDangerousObjectType) //Too late! Execution may have already occurred.
{
//generate warnings and dispose of suspectObject
}
</pre>

For '''BinaryFormatter''' and '''JSON.Net''' it is possible to create a safer form of white list control useing a custom '''SerializationBinder'''.<br />

Try to keep up-to-date on known .Net insecure deserialization gadgets and pay special attention where such types can be created by your deserialization processes. A deserializer can only only instantiate types that it knows about. Try to keep any code that might create potential gagdets separate from any code that Vas internet connectivity. As an example '''System.Windows.Data.ObjectDataProvider''' used in WPF applications is a known gadget that allows arbitrary method invocation. It would be risky to have this a reference to this assembly in a REST service project that deserializes untrusted data.

=== Known .NET RCE Gadgets ===
System.Configuration.Install.AssemblyInstaller
* System.Activities.Presentation.WorkflowDesigner
* System.Windows.ResourceDictionary
* System.Windows.Data.ObjectDataProvider
* System.Windows.Forms.BindingSource
* Microsoft.Exchange.Management.SystemManager.WinForms.ExchangeSettingsProvider
* System.Data.DataViewManager, System.Xml.XmlDocument/XmlDataDocument
* System.Management.Automation.PSObject

= Language-Agnostic Methods for Deserializing Safely =

==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native (de)serialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.

Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.

==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.

= Mitigation Tools/Libraries =
* Java secure deserialization library https://github.com/ikkisoft/SerialKiller

* SWAT (Serial Whitelist Application Trainer) https://github.com/cschneider4711/SWAT
* NotSoSerial https://github.com/kantega/notsoserial

= Detection Tools =
* [https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet Java deserialization cheat sheet aimed at pen testers]

* [https://github.com/frohoff/ysoserial A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.]
* Java De-serialization toolkits https://github.com/brianwrf/hackUtils
* Java de-serialization tool https://github.com/frohoff/ysoserial
* .Net payload generator https://github.com/pwntester/ysoserial.net
* Java de-serialization detection by DNS https://github.com/GoSeecure/break-fast-serial
* Burp Suite extension https://github.com/federicodotta/Java-Deserialization-Scanner/releases
* Java secure deserialization library https://github.com/ikkisoft/SerialKiller
* Serianalyzer is a static bytecode analyzer for deserialization https://github.com/mbechler/serianalyzer
* Payload generator https://github.com/mbechler/marshalsec
* Android Java Deserialization Vulnerability Tester https://github.com/modzero/modjoda
* Burp Suite Extension
** JavaSerialKiller https://github.com/NetSPI/JavaSerialKiller
** Java Deserialization Scanner https://github.com/federicodotta/Java-Deserialization-Scanner
** Burp-ysoserial https://github.com/summitt/burp-ysoserial
** SuperSerial https://github.com/DirectDefense/SuperSerial
** SuperSerial-Active https://github.com/DirectDefense/SuperSerial-Active

= References =
* https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet
* [[Deserialization of untrusted data]]
* [[Media:GOD16-Deserialization.pdf|Java Deserialization Attacks - German OWASP Day 2016]]
* [http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles AppSecCali 2015 - Marshalling Pickles]
* [http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#websphere FoxGlove Security - Vulnerability Announcement]
* [https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet Java deserialization cheat sheet aimed at pen testers]
* [https://github.com/frohoff/ysoserial A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.]
* Java De-serialization toolkits https://github.com/brianwrf/hackUtils
* Java de-serialization tool https://github.com/frohoff/ysoserial
* Java de-serialization detection by DNS https://github.com/GoSeecure/break-fast-serial
* Burp Suite extension https://github.com/federicodotta/Java-Deserialization-Scanner/releases
* Java secure deserialization library https://github.com/ikkisoft/SerialKiller
* Serianalyzer is a static bytecode analyzer for deserialization https://github.com/mbechler/serianalyzer
* Payload generator https://github.com/mbechler/marshalsec
* Android Java Deserialization Vulnerability Tester https://github.com/modzero/modjoda
* Burp Suite Extension
** JavaSerialKiller https://github.com/NetSPI/JavaSerialKiller
** Java Deserialization Scanner https://github.com/federicodotta/Java-Deserialization-Scanner
** Burp-ysoserial https://github.com/summitt/burp-ysoserial
** SuperSerial https://github.com/DirectDefense/SuperSerial
** SuperSerial-Active https://github.com/DirectDefense/SuperSerial-Active
* .Net
** Alvaro Muñoz: .NET Serialization: Detecting and defending vulnerable endpoints https://www.youtube.com/watch?v=qDoBlLwREYk
** James Forshaw - Black Hat USA 2012 - Are You My Type? Breaking .net Sandboxes Through Serialization https://www.youtube.com/watch?v=Xfbu-pQ1tIc
** Jonathan Birch BlueHat v17 || Dangerous Contents - Securing .Net Deserialization https://www.youtube.com/watch?v=oxlD8VWWHE8
** Alvaro Muñoz & Oleksandr Mirosh - Friday the 13th: Attacking JSON - AppSecUSA 2017 Https://www.youtube.com/watch?v=NqHsaVhlxAQ

= Authors and Primary Editors =

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br />
Tony Hsu (Hsiang-Chih)

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
|}

.NET Security Cheat Sheet

2017-01-12T08:21:39Z

Shaneinsweden: /* ASP.NET MVC Guidance */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
== Introduction ==
__TOC__{{TOC hidden}}
This page intends to provide quick basic .NET security tips for developers.

===The .NET Framework===
The .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 Framework===
The .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 [http://windowsupdate.microsoft.com/ Windows Update] or from the Windows Update program on a Windows computer.

Individual frameworks can be kept up to date using [http://nuget.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home 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 Guidance==

The .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 ===

* Use [http://msdn.microsoft.com/en-us/library/ms175528(v=sql.105).aspx Parameterized SQL] commands for all data access, without exception.
* Do not use [http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx SqlCommand] with a string parameter made up of a [http://msdn.microsoft.com/en-us/library/ms182310.aspx concatenated SQL String].
* Whitelist allowable values coming from the user. Use enums, [http://msdn.microsoft.com/en-us/library/f02979c7.aspx TryParse] or lookup values to assure that the data coming from the user is as expected.
** Enums are still vulnerable to unexpected values because .NET only validates a successful cast to the underlying data type, integer by default. [https://msdn.microsoft.com/en-us/library/system.enum.isdefined Enum.IsDefined] can validate whether the input value is valid within the list of defined constants.
* Apply the principle of least privilege when setting up the Database User in your database of choice. The database user should only be able to access items that make sense for the use case.
* 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.
* Use [https://msdn.microsoft.com/en-us/library/mt163865.aspx Always Encrypted] where possible for sensitive data (SQL Server 2016 and SQL Azure),

=== 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.
* The standard .NET framework libraries only offer unauthenticated encryption implementations. Authenticated encryption modes such as AES-GCM based on the underlying newer, more modern Cryptography API: Next Generation are available via the [https://clrsecurity.codeplex.com/ CLRSecurity library].
* 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 the .NET framework the strongest algorithm for password hashing is PBKDF2, implemented as [http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx System.Security.Cryptography.Rfc2898DeriveBytes].
** In .NET Core the strongest algorithm for password hashing is PBKDF2, implemented as [https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing Microsoft.AspNetCore.Cryptography.KeyDerivation.Pbkdf2] which has several significant advantages over Rfc2898DeriveBytes.
** When using a hashing function to hash non-unique inputs such as passwords, use a salt value added to the original value before hashing.
* Make sure your application or protocol can easily support a future change of cryptographic algorithms.
* Use Nuget to keep all of your packages up to date. Watch the updates on your development setup, and plan updates to your applications accordingly.

=== General ===

* Lock down the config file.
** Remove all aspects of configuration that are not in use.
** 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 is the original browser-based application development API for the .NET framework, and is still the most common enterprise platform for web application development.

* 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.
* Implement [http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=VS.71).aspx customErrors].
* 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]:

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.");
}
}
}

* Consider [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] in IIS.
** In the Connections pane, go to the site, application, or directory for which you want to set a custom HTTP header.
** In the Home pane, double-click HTTP Response Headers.
** 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.
* Remove the version header.

<httpRuntime enableVersionHeader="false" />

* Also remove the Server header.

HttpContext.Current.Response.Headers.Remove("Server");

=== 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 the XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting.
* 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. The regex namespace is particularly useful for checking to make sure an email address or URI is as expected.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== Forms authentication ===

* Use cookies for persistence when possible. Cookieless Auth will default to UseDeviceProfile.
* Don't trust the URI of the request for persistence of the session or authorization. It can be easily faked.
* Reduce the forms authentication timeout from the default of 20 minutes to the shortest period appropriate for your application. If slidingExpiration is used this timeout resets after each request, so active users won't be affected.
* If HTTPS is not used, slidingExpiration should be disabled. Consider disabling slidingExpiration even with HTTPS.
* Always implement proper access controls.
** Compare user provided username with User.Identity.Name.
** Check roles against User.Identity.IsInRole.
* Use the ASP.NET Membership provider and role provider, but review the password storage. The default storage hashes the password with a single iteration of SHA-1 which is rather weak. The ASP.NET MVC4 template uses [http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity ASP.NET Identity] instead of ASP.NET Membership, and ASP.NET Identity uses PBKDF2 by default which is better. Review the OWASP [[Password Storage Cheat Sheet]] for more information.
* Explicitly authorize resource requests.
* Leverage role based authorization using User.Identity.IsInRole.

==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. 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:


<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)

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 XSS

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.

* 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:


<compilation xdt:Transform="RemoveAttributes(debug)" />

<trace enabled="false" xdt:Transform="Replace"/>

DO NOT: Use default passwords

* 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.

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] or [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] to remove Server tags

* 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>
<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()

NB: You will need to attach the anti-forgery token to Ajax requests.

* 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. So 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 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.

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==

* Work within the constraints of Internet Zone security for your application.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==Windows Forms Guidance==

* Use partial trust when possible. Partially trusted Windows applications reduce the attack surface of an application. Manage a list of what permissions your app must use, and what it may use, and then make the request for those permissions declaratively at run time.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==WCF Guidance==

* Keep in mind that the only safe way to pass a request in RESTful services is via HTTP POST, with TLS enabled. GETs are visible in the querystring, and a lack of TLS means the body can be intercepted.
* Avoid BasicHttpBinding. It has no default security configuration. Use WSHttpBinding instead.
* Use at least two security modes for your binding. Message security includes security provisions in the headers. Transport security means use of SSL. TransportWithMessageCredential combines the two.
* Test your WCF implementation with a fuzzer like the Zed Attack Proxy.

== Authors and Primary Editors ==

Bill Sempf - bill.sempf(at)owasp.org<br/>
Troy Hunt - troyhunt(at)hotmail.com<br/>
Jeremy Long - jeremy.long(at)owasp.org<br />

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:OWASP .NET Project]]

.NET Security Cheat Sheet

2017-01-12T08:16:57Z

Shaneinsweden: /* ASP.NET MVC Guidance */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
== Introduction ==
__TOC__{{TOC hidden}}
This page intends to provide quick basic .NET security tips for developers.

===The .NET Framework===
The .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 Framework===
The .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 [http://windowsupdate.microsoft.com/ Windows Update] or from the Windows Update program on a Windows computer.

Individual frameworks can be kept up to date using [http://nuget.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home 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 Guidance==

The .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 ===

* Use [http://msdn.microsoft.com/en-us/library/ms175528(v=sql.105).aspx Parameterized SQL] commands for all data access, without exception.
* Do not use [http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx SqlCommand] with a string parameter made up of a [http://msdn.microsoft.com/en-us/library/ms182310.aspx concatenated SQL String].
* Whitelist allowable values coming from the user. Use enums, [http://msdn.microsoft.com/en-us/library/f02979c7.aspx TryParse] or lookup values to assure that the data coming from the user is as expected.
** Enums are still vulnerable to unexpected values because .NET only validates a successful cast to the underlying data type, integer by default. [https://msdn.microsoft.com/en-us/library/system.enum.isdefined Enum.IsDefined] can validate whether the input value is valid within the list of defined constants.
* Apply the principle of least privilege when setting up the Database User in your database of choice. The database user should only be able to access items that make sense for the use case.
* 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.
* Use [https://msdn.microsoft.com/en-us/library/mt163865.aspx Always Encrypted] where possible for sensitive data (SQL Server 2016 and SQL Azure),

=== 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.
* The standard .NET framework libraries only offer unauthenticated encryption implementations. Authenticated encryption modes such as AES-GCM based on the underlying newer, more modern Cryptography API: Next Generation are available via the [https://clrsecurity.codeplex.com/ CLRSecurity library].
* 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 the .NET framework the strongest algorithm for password hashing is PBKDF2, implemented as [http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx System.Security.Cryptography.Rfc2898DeriveBytes].
** In .NET Core the strongest algorithm for password hashing is PBKDF2, implemented as [https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing Microsoft.AspNetCore.Cryptography.KeyDerivation.Pbkdf2] which has several significant advantages over Rfc2898DeriveBytes.
** When using a hashing function to hash non-unique inputs such as passwords, use a salt value added to the original value before hashing.
* Make sure your application or protocol can easily support a future change of cryptographic algorithms.
* Use Nuget to keep all of your packages up to date. Watch the updates on your development setup, and plan updates to your applications accordingly.

=== General ===

* Lock down the config file.
** Remove all aspects of configuration that are not in use.
** 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 is the original browser-based application development API for the .NET framework, and is still the most common enterprise platform for web application development.

* 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.
* Implement [http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=VS.71).aspx customErrors].
* 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]:

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.");
}
}
}

* Consider [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] in IIS.
** In the Connections pane, go to the site, application, or directory for which you want to set a custom HTTP header.
** In the Home pane, double-click HTTP Response Headers.
** 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.
* Remove the version header.

<httpRuntime enableVersionHeader="false" />

* Also remove the Server header.

HttpContext.Current.Response.Headers.Remove("Server");

=== 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 the XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting.
* 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. The regex namespace is particularly useful for checking to make sure an email address or URI is as expected.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== Forms authentication ===

* Use cookies for persistence when possible. Cookieless Auth will default to UseDeviceProfile.
* Don't trust the URI of the request for persistence of the session or authorization. It can be easily faked.
* Reduce the forms authentication timeout from the default of 20 minutes to the shortest period appropriate for your application. If slidingExpiration is used this timeout resets after each request, so active users won't be affected.
* If HTTPS is not used, slidingExpiration should be disabled. Consider disabling slidingExpiration even with HTTPS.
* Always implement proper access controls.
** Compare user provided username with User.Identity.Name.
** Check roles against User.Identity.IsInRole.
* Use the ASP.NET Membership provider and role provider, but review the password storage. The default storage hashes the password with a single iteration of SHA-1 which is rather weak. The ASP.NET MVC4 template uses [http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity ASP.NET Identity] instead of ASP.NET Membership, and ASP.NET Identity uses PBKDF2 by default which is better. Review the OWASP [[Password Storage Cheat Sheet]] for more information.
* Explicitly authorize resource requests.
* Leverage role based authorization using User.Identity.IsInRole.

==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. 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:


<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)

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 XSS

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.

* 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:


<compilation xdt:Transform="RemoveAttributes(debug)" />

<trace enabled="false" xdt:Transform="Replace"/>

DO NOT: Use default passwords

* 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.

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] to remove Server tag

* 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>
<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()

NB: You will need to attach the anti-forgery token to Ajax requests.

* 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. So 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 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.

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==

* Work within the constraints of Internet Zone security for your application.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==Windows Forms Guidance==

* Use partial trust when possible. Partially trusted Windows applications reduce the attack surface of an application. Manage a list of what permissions your app must use, and what it may use, and then make the request for those permissions declaratively at run time.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==WCF Guidance==

* Keep in mind that the only safe way to pass a request in RESTful services is via HTTP POST, with TLS enabled. GETs are visible in the querystring, and a lack of TLS means the body can be intercepted.
* Avoid BasicHttpBinding. It has no default security configuration. Use WSHttpBinding instead.
* Use at least two security modes for your binding. Message security includes security provisions in the headers. Transport security means use of SSL. TransportWithMessageCredential combines the two.
* Test your WCF implementation with a fuzzer like the Zed Attack Proxy.

== Authors and Primary Editors ==

Bill Sempf - bill.sempf(at)owasp.org<br/>
Troy Hunt - troyhunt(at)hotmail.com<br/>
Jeremy Long - jeremy.long(at)owasp.org<br />

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:OWASP .NET Project]]

.NET Security Cheat Sheet

2017-01-09T22:36:42Z

Shaneinsweden: /* ASP.NET MVC Guidance */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
== Introduction ==
__TOC__{{TOC hidden}}
This page intends to provide quick basic .NET security tips for developers.

===The .NET Framework===
The .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 Framework===
The .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 [http://windowsupdate.microsoft.com/ Windows Update] or from the Windows Update program on a Windows computer.

Individual frameworks can be kept up to date using [http://nuget.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home 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 Guidance==

The .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 ===

* Use [http://msdn.microsoft.com/en-us/library/ms175528(v=sql.105).aspx Parameterized SQL] commands for all data access, without exception.
* Do not use [http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx SqlCommand] with a string parameter made up of a [http://msdn.microsoft.com/en-us/library/ms182310.aspx concatenated SQL String].
* Whitelist allowable values coming from the user. Use enums, [http://msdn.microsoft.com/en-us/library/f02979c7.aspx TryParse] or lookup values to assure that the data coming from the user is as expected.
** Enums are still vulnerable to unexpected values because .NET only validates a successful cast to the underlying data type, integer by default. [https://msdn.microsoft.com/en-us/library/system.enum.isdefined Enum.IsDefined] can validate whether the input value is valid within the list of defined constants.
* Apply the principle of least privilege when setting up the Database User in your database of choice. The database user should only be able to access items that make sense for the use case.
* 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.
* Use [https://msdn.microsoft.com/en-us/library/mt163865.aspx Always Encrypted] where possible for sensitive data (SQL Server 2016 and SQL Azure),

=== 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.
* The standard .NET framework libraries only offer unauthenticated encryption implementations. Authenticated encryption modes such as AES-GCM based on the underlying newer, more modern Cryptography API: Next Generation are available via the [https://clrsecurity.codeplex.com/ CLRSecurity library].
* 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 the .NET framework the strongest algorithm for password hashing is PBKDF2, implemented as [http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx System.Security.Cryptography.Rfc2898DeriveBytes].
** In .NET Core the strongest algorithm for password hashing is PBKDF2, implemented as [https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing Microsoft.AspNetCore.Cryptography.KeyDerivation.Pbkdf2] which has several significant advantages over Rfc2898DeriveBytes.
** When using a hashing function to hash non-unique inputs such as passwords, use a salt value added to the original value before hashing.
* Make sure your application or protocol can easily support a future change of cryptographic algorithms.
* Use Nuget to keep all of your packages up to date. Watch the updates on your development setup, and plan updates to your applications accordingly.

=== General ===

* Lock down the config file.
** Remove all aspects of configuration that are not in use.
** 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 is the original browser-based application development API for the .NET framework, and is still the most common enterprise platform for web application development.

* 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.
* Implement [http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=VS.71).aspx customErrors].
* 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]:

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.");
}
}
}

* Consider [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] in IIS.
** In the Connections pane, go to the site, application, or directory for which you want to set a custom HTTP header.
** In the Home pane, double-click HTTP Response Headers.
** 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.
* Remove the version header.

<httpRuntime enableVersionHeader="false" />

* Also remove the Server header.

HttpContext.Current.Response.Headers.Remove("Server");

=== 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 the XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting.
* 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. The regex namespace is particularly useful for checking to make sure an email address or URI is as expected.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== Forms authentication ===

* Use cookies for persistence when possible. Cookieless Auth will default to UseDeviceProfile.
* Don't trust the URI of the request for persistence of the session or authorization. It can be easily faked.
* Reduce the forms authentication timeout from the default of 20 minutes to the shortest period appropriate for your application. If slidingExpiration is used this timeout resets after each request, so active users won't be affected.
* If HTTPS is not used, slidingExpiration should be disabled. Consider disabling slidingExpiration even with HTTPS.
* Always implement proper access controls.
** Compare user provided username with User.Identity.Name.
** Check roles against User.Identity.IsInRole.
* Use the ASP.NET Membership provider and role provider, but review the password storage. The default storage hashes the password with a single iteration of SHA-1 which is rather weak. The ASP.NET MVC4 template uses [http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity ASP.NET Identity] instead of ASP.NET Membership, and ASP.NET Identity uses PBKDF2 by default which is better. Review the OWASP [[Password Storage Cheat Sheet]] for more information.
* Explicitly authorize resource requests.
* Leverage role based authorization using User.Identity.IsInRole.

==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. 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:


<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)

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 XSS

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.

* 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:


<compilation xdt:Transform="RemoveAttributes(debug)" />

<trace enabled="false" xdt:Transform="Replace"/>

DO NOT: Use default passwords

* A6 Sensitive data exposure

DO: Use a strong hash to store password credentials. Use PBKDF2, BCrypt or SCrypt with at least 8000 iterations.

DO: Enforce passwords with a minimum complexity: Minimum 8 characters at least 1 upper case, lower case and number.

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] to remove Server tag

* 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>
<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()

NB: You will need to attach the anti-forgery token to Ajax requests.

* 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. So 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 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.

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==

* Work within the constraints of Internet Zone security for your application.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==Windows Forms Guidance==

* Use partial trust when possible. Partially trusted Windows applications reduce the attack surface of an application. Manage a list of what permissions your app must use, and what it may use, and then make the request for those permissions declaratively at run time.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==WCF Guidance==

* Keep in mind that the only safe way to pass a request in RESTful services is via HTTP POST, with TLS enabled. GETs are visible in the querystring, and a lack of TLS means the body can be intercepted.
* Avoid BasicHttpBinding. It has no default security configuration. Use WSHttpBinding instead.
* Use at least two security modes for your binding. Message security includes security provisions in the headers. Transport security means use of SSL. TransportWithMessageCredential combines the two.
* Test your WCF implementation with a fuzzer like the Zed Attack Proxy.

== Authors and Primary Editors ==

Bill Sempf - bill.sempf(at)owasp.org<br/>
Troy Hunt - troyhunt(at)hotmail.com<br/>
Jeremy Long - jeremy.long(at)owasp.org<br />

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:OWASP .NET Project]]

.NET Security Cheat Sheet

2017-01-09T22:35:08Z

Shaneinsweden: /* General */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
== Introduction ==
__TOC__{{TOC hidden}}
This page intends to provide quick basic .NET security tips for developers.

===The .NET Framework===
The .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 Framework===
The .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 [http://windowsupdate.microsoft.com/ Windows Update] or from the Windows Update program on a Windows computer.

Individual frameworks can be kept up to date using [http://nuget.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home 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 Guidance==

The .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 ===

* Use [http://msdn.microsoft.com/en-us/library/ms175528(v=sql.105).aspx Parameterized SQL] commands for all data access, without exception.
* Do not use [http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx SqlCommand] with a string parameter made up of a [http://msdn.microsoft.com/en-us/library/ms182310.aspx concatenated SQL String].
* Whitelist allowable values coming from the user. Use enums, [http://msdn.microsoft.com/en-us/library/f02979c7.aspx TryParse] or lookup values to assure that the data coming from the user is as expected.
** Enums are still vulnerable to unexpected values because .NET only validates a successful cast to the underlying data type, integer by default. [https://msdn.microsoft.com/en-us/library/system.enum.isdefined Enum.IsDefined] can validate whether the input value is valid within the list of defined constants.
* Apply the principle of least privilege when setting up the Database User in your database of choice. The database user should only be able to access items that make sense for the use case.
* 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.
* Use [https://msdn.microsoft.com/en-us/library/mt163865.aspx Always Encrypted] where possible for sensitive data (SQL Server 2016 and SQL Azure),

=== 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.
* The standard .NET framework libraries only offer unauthenticated encryption implementations. Authenticated encryption modes such as AES-GCM based on the underlying newer, more modern Cryptography API: Next Generation are available via the [https://clrsecurity.codeplex.com/ CLRSecurity library].
* 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 the .NET framework the strongest algorithm for password hashing is PBKDF2, implemented as [http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx System.Security.Cryptography.Rfc2898DeriveBytes].
** In .NET Core the strongest algorithm for password hashing is PBKDF2, implemented as [https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing Microsoft.AspNetCore.Cryptography.KeyDerivation.Pbkdf2] which has several significant advantages over Rfc2898DeriveBytes.
** When using a hashing function to hash non-unique inputs such as passwords, use a salt value added to the original value before hashing.
* Make sure your application or protocol can easily support a future change of cryptographic algorithms.
* Use Nuget to keep all of your packages up to date. Watch the updates on your development setup, and plan updates to your applications accordingly.

=== General ===

* Lock down the config file.
** Remove all aspects of configuration that are not in use.
** 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 is the original browser-based application development API for the .NET framework, and is still the most common enterprise platform for web application development.

* 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.
* Implement [http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=VS.71).aspx customErrors].
* 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]:

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.");
}
}
}

* Consider [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] in IIS.
** In the Connections pane, go to the site, application, or directory for which you want to set a custom HTTP header.
** In the Home pane, double-click HTTP Response Headers.
** 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.
* Remove the version header.

<httpRuntime enableVersionHeader="false" />

* Also remove the Server header.

HttpContext.Current.Response.Headers.Remove("Server");

=== 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 the XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting.
* 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. The regex namespace is particularly useful for checking to make sure an email address or URI is as expected.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== Forms authentication ===

* Use cookies for persistence when possible. Cookieless Auth will default to UseDeviceProfile.
* Don't trust the URI of the request for persistence of the session or authorization. It can be easily faked.
* Reduce the forms authentication timeout from the default of 20 minutes to the shortest period appropriate for your application. If slidingExpiration is used this timeout resets after each request, so active users won't be affected.
* If HTTPS is not used, slidingExpiration should be disabled. Consider disabling slidingExpiration even with HTTPS.
* Always implement proper access controls.
** Compare user provided username with User.Identity.Name.
** Check roles against User.Identity.IsInRole.
* Use the ASP.NET Membership provider and role provider, but review the password storage. The default storage hashes the password with a single iteration of SHA-1 which is rather weak. The ASP.NET MVC4 template uses [http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity ASP.NET Identity] instead of ASP.NET Membership, and ASP.NET Identity uses PBKDF2 by default which is better. Review the OWASP [[Password Storage Cheat Sheet]] for more information.
* Explicitly authorize resource requests.
* Leverage role based authorization using User.Identity.IsInRole.

==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. 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 paramaterized 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:


<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)

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 XSS

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.

* 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:


<compilation xdt:Transform="RemoveAttributes(debug)" />

<trace enabled="false" xdt:Transform="Replace"/>

DO NOT: Use default passwords

* A6 Sensitive data exposure

DO: Use a strong hash to store password credentials. Use PBKDF2, BCrypt or SCrypt with at least 8000 iterations.

DO: Enforce passwords with a minimum complexity: Minimum 8 characters at least 1 upper case, lower case and number.

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] to remove Server tag

* 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>
<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()

NB: You will need to attach the anti-forgery token to Ajax requests.

* 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. So 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 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.

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==

* Work within the constraints of Internet Zone security for your application.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==Windows Forms Guidance==

* Use partial trust when possible. Partially trusted Windows applications reduce the attack surface of an application. Manage a list of what permissions your app must use, and what it may use, and then make the request for those permissions declaratively at run time.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==WCF Guidance==

* Keep in mind that the only safe way to pass a request in RESTful services is via HTTP POST, with TLS enabled. GETs are visible in the querystring, and a lack of TLS means the body can be intercepted.
* Avoid BasicHttpBinding. It has no default security configuration. Use WSHttpBinding instead.
* Use at least two security modes for your binding. Message security includes security provisions in the headers. Transport security means use of SSL. TransportWithMessageCredential combines the two.
* Test your WCF implementation with a fuzzer like the Zed Attack Proxy.

== Authors and Primary Editors ==

Bill Sempf - bill.sempf(at)owasp.org<br/>
Troy Hunt - troyhunt(at)hotmail.com<br/>
Jeremy Long - jeremy.long(at)owasp.org<br />

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:OWASP .NET Project]]

.NET Security Cheat Sheet

2017-01-09T22:32:11Z

Shaneinsweden: /* .NET Framework Guidance */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
== Introduction ==
__TOC__{{TOC hidden}}
This page intends to provide quick basic .NET security tips for developers.

===The .NET Framework===
The .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 Framework===
The .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 [http://windowsupdate.microsoft.com/ Windows Update] or from the Windows Update program on a Windows computer.

Individual frameworks can be kept up to date using [http://nuget.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home 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 Guidance==

The .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 ===

* Use [http://msdn.microsoft.com/en-us/library/ms175528(v=sql.105).aspx Parameterized SQL] commands for all data access, without exception.
* Do not use [http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx SqlCommand] with a string parameter made up of a [http://msdn.microsoft.com/en-us/library/ms182310.aspx concatenated SQL String].
* Whitelist allowable values coming from the user. Use enums, [http://msdn.microsoft.com/en-us/library/f02979c7.aspx TryParse] or lookup values to assure that the data coming from the user is as expected.
** Enums are still vulnerable to unexpected values because .NET only validates a successful cast to the underlying data type, integer by default. [https://msdn.microsoft.com/en-us/library/system.enum.isdefined Enum.IsDefined] can validate whether the input value is valid within the list of defined constants.
* Apply the principle of least privilege when setting up the Database User in your database of choice. The database user should only be able to access items that make sense for the use case.
* 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.
* Use [https://msdn.microsoft.com/en-us/library/mt163865.aspx Always Encrypted] where possible for sensitive data (SQL Server 2016 and SQL Azure),

=== 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.
* The standard .NET framework libraries only offer unauthenticated encryption implementations. Authenticated encryption modes such as AES-GCM based on the underlying newer, more modern Cryptography API: Next Generation are available via the [https://clrsecurity.codeplex.com/ CLRSecurity library].
* 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 the .NET framework the strongest algorithm for password hashing is PBKDF2, implemented as [http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx System.Security.Cryptography.Rfc2898DeriveBytes].
** In .NET Core the strongest algorithm for password hashing is PBKDF2, implemented as [https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing Microsoft.AspNetCore.Cryptography.KeyDerivation.Pbkdf2] which has several significant advantages over Rfc2898DeriveBytes.
** When using a hashing function to hash non-unique inputs such as passwords, use a salt value added to the original value before hashing.
* Make sure your application or protocol can easily support a future change of cryptographic algorithms.
* Use Nuget to keep all of your packages up to date. Watch the updates on your development setup, and plan updates to your applications accordingly.

=== General ===

* Lock down the config file.
** Remove all aspects of configuration that are not in use.
** Encrypt sensitive parts of the web.config using aspnet_regiis -pe

==ASP.NET Web Forms Guidance==

ASP.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.

* 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.
* Implement [http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=VS.71).aspx customErrors].
* 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]:

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.");
}
}
}

* Consider [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] in IIS.
** In the Connections pane, go to the site, application, or directory for which you want to set a custom HTTP header.
** In the Home pane, double-click HTTP Response Headers.
** 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.
* Remove the version header.

<httpRuntime enableVersionHeader="false" />

* Also remove the Server header.

HttpContext.Current.Response.Headers.Remove("Server");

=== 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 the XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting.
* 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. The regex namespace is particularly useful for checking to make sure an email address or URI is as expected.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== Forms authentication ===

* Use cookies for persistence when possible. Cookieless Auth will default to UseDeviceProfile.
* Don't trust the URI of the request for persistence of the session or authorization. It can be easily faked.
* Reduce the forms authentication timeout from the default of 20 minutes to the shortest period appropriate for your application. If slidingExpiration is used this timeout resets after each request, so active users won't be affected.
* If HTTPS is not used, slidingExpiration should be disabled. Consider disabling slidingExpiration even with HTTPS.
* Always implement proper access controls.
** Compare user provided username with User.Identity.Name.
** Check roles against User.Identity.IsInRole.
* Use the ASP.NET Membership provider and role provider, but review the password storage. The default storage hashes the password with a single iteration of SHA-1 which is rather weak. The ASP.NET MVC4 template uses [http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity ASP.NET Identity] instead of ASP.NET Membership, and ASP.NET Identity uses PBKDF2 by default which is better. Review the OWASP [[Password Storage Cheat Sheet]] for more information.
* Explicitly authorize resource requests.
* Leverage role based authorization using User.Identity.IsInRole.

==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. 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 paramaterized 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:


<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)

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 XSS

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.

* 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:


<compilation xdt:Transform="RemoveAttributes(debug)" />

<trace enabled="false" xdt:Transform="Replace"/>

DO NOT: Use default passwords

* A6 Sensitive data exposure

DO: Use a strong hash to store password credentials. Use PBKDF2, BCrypt or SCrypt with at least 8000 iterations.

DO: Enforce passwords with a minimum complexity: Minimum 8 characters at least 1 upper case, lower case and number.

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] to remove Server tag

* 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>
<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()

NB: You will need to attach the anti-forgery token to Ajax requests.

* 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. So 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 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.

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==

* Work within the constraints of Internet Zone security for your application.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==Windows Forms Guidance==

* Use partial trust when possible. Partially trusted Windows applications reduce the attack surface of an application. Manage a list of what permissions your app must use, and what it may use, and then make the request for those permissions declaratively at run time.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==WCF Guidance==

* Keep in mind that the only safe way to pass a request in RESTful services is via HTTP POST, with TLS enabled. GETs are visible in the querystring, and a lack of TLS means the body can be intercepted.
* Avoid BasicHttpBinding. It has no default security configuration. Use WSHttpBinding instead.
* Use at least two security modes for your binding. Message security includes security provisions in the headers. Transport security means use of SSL. TransportWithMessageCredential combines the two.
* Test your WCF implementation with a fuzzer like the Zed Attack Proxy.

== Authors and Primary Editors ==

Bill Sempf - bill.sempf(at)owasp.org<br/>
Troy Hunt - troyhunt(at)hotmail.com<br/>
Jeremy Long - jeremy.long(at)owasp.org<br />

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:OWASP .NET Project]]

.NET Security Cheat Sheet

2017-01-09T22:26:01Z

Shaneinsweden: /* ASP.NET MVC Guidance */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
== Introduction ==
__TOC__{{TOC hidden}}
This page intends to provide quick basic .NET security tips for developers.

===The .NET Framework===
The .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 Framework===
The .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 [http://windowsupdate.microsoft.com/ Windows Update] or from the Windows Update program on a Windows computer.

Individual frameworks can be kept up to date using [http://nuget.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home 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 Guidance==

The .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 ===

* Use [http://msdn.microsoft.com/en-us/library/ms175528(v=sql.105).aspx Parameterized SQL] commands for all data access, without exception.
* Do not use [http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx SqlCommand] with a string parameter made up of a [http://msdn.microsoft.com/en-us/library/ms182310.aspx concatenated SQL String].
* Whitelist allowable values coming from the user. Use enums, [http://msdn.microsoft.com/en-us/library/f02979c7.aspx TryParse] or lookup values to assure that the data coming from the user is as expected.
** Enums are still vulnerable to unexpected values because .NET only validates a successful cast to the underlying data type, integer by default. [https://msdn.microsoft.com/en-us/library/system.enum.isdefined Enum.IsDefined] can validate whether the input value is valid within the list of defined constants.
* Apply the principle of least privilege when setting up the Database User in your database of choice. The database user should only be able to access items that make sense for the use case.
* 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.

=== 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.
* The standard .NET framework libraries only offer unauthenticated encryption implementations. Authenticated encryption modes such as AES-GCM based on the underlying newer, more modern Cryptography API: Next Generation are available via the [https://clrsecurity.codeplex.com/ CLRSecurity library].
* 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 the .NET framework the strongest algorithm for password hashing is PBKDF2, implemented as [http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx System.Security.Cryptography.Rfc2898DeriveBytes].
** In .NET Core the strongest algorithm for password hashing is PBKDF2, implemented as [https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing Microsoft.AspNetCore.Cryptography.KeyDerivation.Pbkdf2] which has several significant advantages over Rfc2898DeriveBytes.
** When using a hashing function to hash non-unique inputs such as passwords, use a salt value added to the original value before hashing.
* Make sure your application or protocol can easily support a future change of cryptographic algorithms.
* Use Nuget to keep all of your packages up to date. Watch the updates on your development setup, and plan updates to your applications accordingly.

=== General ===

* Lock down the config file.
** Remove all aspects of configuration that are not in use.
** Encrypt sensitive parts of the web.config using aspnet_regiis -pe

==ASP.NET Web Forms Guidance==

ASP.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.

* 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.
* Implement [http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=VS.71).aspx customErrors].
* 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]:

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.");
}
}
}

* Consider [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] in IIS.
** In the Connections pane, go to the site, application, or directory for which you want to set a custom HTTP header.
** In the Home pane, double-click HTTP Response Headers.
** 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.
* Remove the version header.

<httpRuntime enableVersionHeader="false" />

* Also remove the Server header.

HttpContext.Current.Response.Headers.Remove("Server");

=== 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 the XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting.
* 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. The regex namespace is particularly useful for checking to make sure an email address or URI is as expected.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== Forms authentication ===

* Use cookies for persistence when possible. Cookieless Auth will default to UseDeviceProfile.
* Don't trust the URI of the request for persistence of the session or authorization. It can be easily faked.
* Reduce the forms authentication timeout from the default of 20 minutes to the shortest period appropriate for your application. If slidingExpiration is used this timeout resets after each request, so active users won't be affected.
* If HTTPS is not used, slidingExpiration should be disabled. Consider disabling slidingExpiration even with HTTPS.
* Always implement proper access controls.
** Compare user provided username with User.Identity.Name.
** Check roles against User.Identity.IsInRole.
* Use the ASP.NET Membership provider and role provider, but review the password storage. The default storage hashes the password with a single iteration of SHA-1 which is rather weak. The ASP.NET MVC4 template uses [http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity ASP.NET Identity] instead of ASP.NET Membership, and ASP.NET Identity uses PBKDF2 by default which is better. Review the OWASP [[Password Storage Cheat Sheet]] for more information.
* Explicitly authorize resource requests.
* Leverage role based authorization using User.Identity.IsInRole.

==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. 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 paramaterized 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:


<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)

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 XSS

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.

* 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:


<compilation xdt:Transform="RemoveAttributes(debug)" />

<trace enabled="false" xdt:Transform="Replace"/>

DO NOT: Use default passwords

* A6 Sensitive data exposure

DO: Use a strong hash to store password credentials. Use PBKDF2, BCrypt or SCrypt with at least 8000 iterations.

DO: Enforce passwords with a minimum complexity: Minimum 8 characters at least 1 upper case, lower case and number.

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] to remove Server tag

* 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>
<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()

NB: You will need to attach the anti-forgery token to Ajax requests.

* 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. So 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 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.

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==

* Work within the constraints of Internet Zone security for your application.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==Windows Forms Guidance==

* Use partial trust when possible. Partially trusted Windows applications reduce the attack surface of an application. Manage a list of what permissions your app must use, and what it may use, and then make the request for those permissions declaratively at run time.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==WCF Guidance==

* Keep in mind that the only safe way to pass a request in RESTful services is via HTTP POST, with TLS enabled. GETs are visible in the querystring, and a lack of TLS means the body can be intercepted.
* Avoid BasicHttpBinding. It has no default security configuration. Use WSHttpBinding instead.
* Use at least two security modes for your binding. Message security includes security provisions in the headers. Transport security means use of SSL. TransportWithMessageCredential combines the two.
* Test your WCF implementation with a fuzzer like the Zed Attack Proxy.

== Authors and Primary Editors ==

Bill Sempf - bill.sempf(at)owasp.org<br/>
Troy Hunt - troyhunt(at)hotmail.com<br/>
Jeremy Long - jeremy.long(at)owasp.org<br />

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:OWASP .NET Project]]

.NET Security Cheat Sheet

2017-01-09T22:23:29Z

Shaneinsweden: /* ASP.NET MVC Guidance */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
== Introduction ==
__TOC__{{TOC hidden}}
This page intends to provide quick basic .NET security tips for developers.

===The .NET Framework===
The .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 Framework===
The .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 [http://windowsupdate.microsoft.com/ Windows Update] or from the Windows Update program on a Windows computer.

Individual frameworks can be kept up to date using [http://nuget.codeplex.com/wikipage?title=Getting%20Started&referringTitle=Home 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 Guidance==

The .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 ===

* Use [http://msdn.microsoft.com/en-us/library/ms175528(v=sql.105).aspx Parameterized SQL] commands for all data access, without exception.
* Do not use [http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.aspx SqlCommand] with a string parameter made up of a [http://msdn.microsoft.com/en-us/library/ms182310.aspx concatenated SQL String].
* Whitelist allowable values coming from the user. Use enums, [http://msdn.microsoft.com/en-us/library/f02979c7.aspx TryParse] or lookup values to assure that the data coming from the user is as expected.
** Enums are still vulnerable to unexpected values because .NET only validates a successful cast to the underlying data type, integer by default. [https://msdn.microsoft.com/en-us/library/system.enum.isdefined Enum.IsDefined] can validate whether the input value is valid within the list of defined constants.
* Apply the principle of least privilege when setting up the Database User in your database of choice. The database user should only be able to access items that make sense for the use case.
* 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.

=== 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.
* The standard .NET framework libraries only offer unauthenticated encryption implementations. Authenticated encryption modes such as AES-GCM based on the underlying newer, more modern Cryptography API: Next Generation are available via the [https://clrsecurity.codeplex.com/ CLRSecurity library].
* 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 the .NET framework the strongest algorithm for password hashing is PBKDF2, implemented as [http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx System.Security.Cryptography.Rfc2898DeriveBytes].
** In .NET Core the strongest algorithm for password hashing is PBKDF2, implemented as [https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing Microsoft.AspNetCore.Cryptography.KeyDerivation.Pbkdf2] which has several significant advantages over Rfc2898DeriveBytes.
** When using a hashing function to hash non-unique inputs such as passwords, use a salt value added to the original value before hashing.
* Make sure your application or protocol can easily support a future change of cryptographic algorithms.
* Use Nuget to keep all of your packages up to date. Watch the updates on your development setup, and plan updates to your applications accordingly.

=== General ===

* Lock down the config file.
** Remove all aspects of configuration that are not in use.
** Encrypt sensitive parts of the web.config using aspnet_regiis -pe

==ASP.NET Web Forms Guidance==

ASP.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.

* 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.
* Implement [http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=VS.71).aspx customErrors].
* 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]:

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.");
}
}
}

* Consider [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] in IIS.
** In the Connections pane, go to the site, application, or directory for which you want to set a custom HTTP header.
** In the Home pane, double-click HTTP Response Headers.
** 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.
* Remove the version header.

<httpRuntime enableVersionHeader="false" />

* Also remove the Server header.

HttpContext.Current.Response.Headers.Remove("Server");

=== 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 the XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting.
* 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. The regex namespace is particularly useful for checking to make sure an email address or URI is as expected.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== Forms authentication ===

* Use cookies for persistence when possible. Cookieless Auth will default to UseDeviceProfile.
* Don't trust the URI of the request for persistence of the session or authorization. It can be easily faked.
* Reduce the forms authentication timeout from the default of 20 minutes to the shortest period appropriate for your application. If slidingExpiration is used this timeout resets after each request, so active users won't be affected.
* If HTTPS is not used, slidingExpiration should be disabled. Consider disabling slidingExpiration even with HTTPS.
* Always implement proper access controls.
** Compare user provided username with User.Identity.Name.
** Check roles against User.Identity.IsInRole.
* Use the ASP.NET Membership provider and role provider, but review the password storage. The default storage hashes the password with a single iteration of SHA-1 which is rather weak. The ASP.NET MVC4 template uses [http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity ASP.NET Identity] instead of ASP.NET Membership, and ASP.NET Identity uses PBKDF2 by default which is better. Review the OWASP [[Password Storage Cheat Sheet]] for more information.
* Explicitly authorize resource requests.
* Leverage role based authorization using User.Identity.IsInRole.

==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. 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 paramterised 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:


<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)

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 XSS

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.

* 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:


<compilation xdt:Transform="RemoveAttributes(debug)" />

<trace enabled="false" xdt:Transform="Replace"/>

DO NOT: Use default passwords

* A6 Sensitive data exposure

DO: Use a strong hash to store password credentials. Use PBKDF2, BCrypt or SCrypt with at least 8000 iterations.

DO: Enforce passwords with a minimum complexity: Minimum 8 characters at least 1 upper case, lower case and number.

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] to remove Server tag

* 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>
<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()

NB: You will need to attach the anti-forgery token to Ajax requests.

* 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. So 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 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.

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==

* Work within the constraints of Internet Zone security for your application.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==Windows Forms Guidance==

* Use partial trust when possible. Partially trusted Windows applications reduce the attack surface of an application. Manage a list of what permissions your app must use, and what it may use, and then make the request for those permissions declaratively at run time.
* Use ClickOnce deployment. For enhanced permissions, use permission elevation at runtime or trusted application deployment at install time.

==WCF Guidance==

* Keep in mind that the only safe way to pass a request in RESTful services is via HTTP POST, with TLS enabled. GETs are visible in the querystring, and a lack of TLS means the body can be intercepted.
* Avoid BasicHttpBinding. It has no default security configuration. Use WSHttpBinding instead.
* Use at least two security modes for your binding. Message security includes security provisions in the headers. Transport security means use of SSL. TransportWithMessageCredential combines the two.
* Test your WCF implementation with a fuzzer like the Zed Attack Proxy.

== Authors and Primary Editors ==

Bill Sempf - bill.sempf(at)owasp.org<br/>
Troy Hunt - troyhunt(at)hotmail.com<br/>
Jeremy Long - jeremy.long(at)owasp.org<br />

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:OWASP .NET Project]]