Intro to ASP.NET OWASP

Presented by Raman But-Husaim

Agenda

  • What is OWASP?
  • ASP.NET & OWASP
  • Security HTTP Headers
  • Cookies
  • Some practice

What Is OWASP?

What Is OWASP?

  • OWASP is an international organization and community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted
  • Core Purpose - Be the thriving global community that drives visibility and evolution in the safety and security of the world’s software.
  • https://www.owasp.org

What Is OWASP?

OWASP gives us

ASP.NET & OWASP

dotNET & Data Access

  • DO NOT: Use SQL command made up of a concatenated SQL string.
someCommand.CommandText = "SELECT AccountNumber FROM Users " +
            "WHERE Username='" + name + 
            "' AND Password='" + password + "'";
  • DO: Use parametrized SQL for all data access.
someCommand.Parameters.Add(
  "@username", SqlDbType.NChar).Value = name;
someCommand.Parameters.Add(
  "@password", SqlDbType.NChar).Value = password;
someCommand.CommandText = "SELECT AccountNumber FROM Users " + 
  "WHERE Username=@username AND Password=@password";

dotNET & Data Access

  • DO: Whitelist allowable values coming from the user.
  • Use enums, TryParse or lookup values to assure that the data coming from the user is as expected.
  • DO: Enums. Still vulnerable to unexpected values. Consider the usage of Enum.IsDefined .
public enum Something { Cool, Awesome};

Something valueCast = (Something)145;
Something valueParse;

Enum.TryParse("182", out valueParse);

valueCast.Dump(); // 145
valueParse.Dump(); // 182

dotNET & Data Access

  • DO: 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.

Good example is our project.

dotNET & Data Access

  • DO: Use of the Entity Framework is a very effective 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.

dotNET & Data Access

var Shipcity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

In case of Redmond

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

In case of Redmond'; drop table OrdersTable--

 

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

See Microsoft Guide

dotNET & Data Access

DO: When using SQL Server, prefer integrated authentication over SQL authentication.

We recommend using Windows authentication wherever possible. Windows authentication uses a series of encrypted messages to authenticate users in SQL Server. When SQL Server logins are used, SQL Server login names and encrypted passwords are passed across the network, which makes them less secure.

Proof is here.

dotNET & Data Access

  • DO: Use Always Encrypted where possible for sensitive data (SQL Server 2016+ and SQL Azure),

Scenarios

  • Client and Data On-Premises
  • Client On-Premises with Data in Azure
  • Client and Data in Azure

dotNET & Encryption

  • DO: Never, ever write your own encryption.
  • DO: Use a strong hashing algorithm.

dotNET & Encryption

  • DO: Make sure your application or protocol can easily support a future change of cryptographic algorithms.
  • DO: 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.
  • DO: Remove all aspects of configuration that are not in use.
  • DO: Encrypt sensitive parts of the web.config.

asp.net

  • DO: always use HTTPS
  • DO: ideally for local development as well.
  • DO: Disable version header. See.
  • DO: Remove Server header.
  • DO: Validate the URI format using Uri.IsWellFormedUriString
  • DO: Forms auth - see here.

asp.net mvc

  • DO: reduce the time period a session can be stolen in by reducing session timeout and removing sliding expiration.
  • DO: Protect LogOn, Registration and password reset methods against brute force attacks by throttling requests (see code below), consider also using ReCaptcha.
  • DO NOT: Roll your own authentication or session management, use the one provided by .Net

asp.net mvc

  • DO NOT: Make LogOn, Registration or Password reset error messages generic to the client.
  • DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists.
  • 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: Use HtmlSanitization if required.

asp.net mvc

  • DO: Ensure debug and trace are off in production. Config transforms could be used for this.
  • DO NOT: Use default and/or weak passwords.
  • 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.

asp.net mvc

  • 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 PII data needs to be restored to it's original format.
  • DO: Use TLS 1.2 for your entire site.
  • DO: Allow SSL, this is now obsolete.
  • DO: Enforce header and cookie policies (discussed later).

asp.net mvc

  • DO: Authorize users on all externally facing endpoints.
  • DO: Send the anti-forgery token with every Post/Put request. 
@Html.AntiForgeryToken()

[ValidateAntiForgeryToken]
  • DO: Make sure the tokens are removed completely for invalidation on logout.

asp.net mvc

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

 

More information and code samples here.

Security HTTP Headers

https://securityheaders.com/

Content Security Policy

  • Control resource the user agent is allowed to load for a given page.
  • Helps to guard against XSS.
  • Fully backward compatible.
  • Represented as:
  1. Content-Security-Policy
  2. X-Content-Security-Policy (legacy)
  3. <meta> element

Content Security Policy

Directives

  • connect-src - wss://*.salemove.eu
  • default-src - 'self'
  • font-src - https://fonts.gstatic.com data:
  • frame-src - *.docusign.net
  • img-src - *.amazonaws.com
  • script-src - 'unsafe-inline' 'unsafe-eval'
  • style-src - https://fonts.googleapis.com
  • ...

Content Security Policy

Tips&Tricks

  • use Content-Security-Policy-Report-Only first
  • Thoroughly test the entire system, especially 3rd parties.
  • Enable continuously across all envs.
  • (though expect to find env-specific issues)
  • Look at browser support
  • https://scotthelme.co.uk/content-security-policy-an-introduction/

HTTP Strict Transport Security (HSTS)

  • Browser prevent any communications from being sent over HTTP to the specified domain
  • Prevents invalid url typing http://example.com (automatically redirects to HTTPS)
  • MIM attack and traffic interception.
Strict-Transport-Security: max-age=31536000; includeSubDomains

HTTP Strict Transport Security (HSTS)

  • Dangerous one as browser will not make HTTP requests to the site.
  • HSTS preload is available.
  • Sending the preload directive from your site can have PERMANENT CONSEQUENCES and prevent users from accessing your site and any of its subdomains if you find you need to switch back to HTTP.

HTTP Strict Transport Security (HSTS)

  • max-age - The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS
  • includeSubDomains  - If this optional parameter is specified, this rule applies to all of the site's subdomains as well
  • preload

Userful info here and here.

X-XSS-Protection

  • browser stops pages from loading when they detect XSS
  • largely unnecessary if string CSP is applied with 'unsafe-inline' js disabled
  • Example - https://scotthelme.co.uk/x-xss-protection-1-mode-block-demo/
X-XSS-Protection: 1; mode=block

X-XSS-Protection

  • X-XSS-Protection: 0 - disabled xss filtering;

  • X-XSS-Protection: 1 - Default. If XSS is detected, the browser will sanitize the page.
  • X-XSS-Protection: 1; mode=block - Enables XSS filtering. Browser will prevent rendering of the page if an attack is detected.
  • X-XSS-Protection: 1; report=<uri>

X-XSS-Protection

X-XSS-Protection: 1; Default ones however has the following issues.

  • widens the attack surface;
  • introduces new vulnerabilities;
  • bypasses are inevitable;

Proof is here.

Best option:

X-XSS-Protection: 0 - if application is XSS-free or cannot afford an unusual filter/auditor bug;

X-XSS-Protection: 1; mode=block - otherwise

Referrer Policy

  • Governs which referrer information sent in the header should be included with requests made.
  • Referer header lets us know where the inbound visitor came from, and is really handy.
Referrer-Policy: origin

Referrer Policy

  • ""
  • no-referrer
  • no-referrer-when-downgrade
  • same-origin
  • origin
  • strict-origin
  • origin-when-cross-origin
  • strict-origin-when-cross-origin
  • unsafe-url

More info here.

Referrer Policy

Recommendations

More info here.

  • unsafe-url - not advised
  • origin - consider strict-origin
  • origin-when-cross-origin - consider with strict
  • no-referrer-when-downgrade - consider when no sensitive info is sent in urls

X-Content-Type-Options

X-Content-Type-Options: nosniff

nosniff

blocks a request if the requested type is

  • "style" and the MIME type is not "text/css", or
  • "script" and the MIME type is not a JavaScript MIME type.

X-Frame-Options

X-Frame-Options: deny
  • Indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> .
  • Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

X-Frame-Options

  • deny - the page cannot be displayed in a frame, regardless of the site attempting to do so.
  • sameorigin - the page can only be displayed in a frame on the same origin as the page itself.
  • allow-from uri - the page can only be displayed in a frame on the specified origin.

Cookies

Useful info here.

Cookies

  • cookies are sent in HTTP headers;
Server

Set-Cookie: id=2bf353246gf3; Secure; HttpOnly
Set-Cookie: lang=en; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Client request

Cookie: id=2bf353246gf3; lang=en
  • attributes influence how cookies are managed by the client;

Cookies - Secure

Cookies marked with the ‘Secure’ attribute are only sent over encrypted HTTPS connections and are therefore safe from man in-the-middle attacks.

<httpCookies requireSSL="false" />

Useful info here.

Affect all cookies...

Except

<authentication mode="Forms">
  <forms loginUrl="~/Something/Wi" timeout="60" requireSSL="true" />
</authentication>

Cookies - Secure

Cookies marked with the ‘Secure’ attribute are only sent over encrypted HTTPS connections and are therefore safe from man in-the-middle attacks.

<httpCookies requireSSL="false" />

Affect all cookies...

Except

<authentication mode="Forms">
  <forms loginUrl="~/Something/Wi" timeout="60" requireSSL="true" />
</authentication>

Useful info here.

+ issues with OWIN :)

Cookies - HttpOnly

“Cookies marked with the ‘HttpOnly’ attribute are not accessible from JavaScript and therefore unaffected by cross-site scripting (XSS) attacks.

<httpCookies httpOnlyCookies="true" />

Useful info here.

Affect all cookies...

Except

  • ASP.NET_SessionId - always httpOnly;
  • Forms Auth Cookie - always httpOnly;

Cookies - What Else

  • path attribute;
  • domain attribute;
  • cookie lifetime;
  • modern cookie protections;

Info could be taken from

Thanks

Made with Slides.com