Making a site unhackable is unfeasible

Organizations should balance between,

1. cost to protect,
2. value of assets,
3. likelihood of exploit.,
4. impact of exploit

Different risk profits mean different required investments to protect.

1. Hacktivists
   • social interests
2. Online criminals
   • cash
3. Nation states
   • cyber warfare

The Open Web application Security Project

• Non-profits
• Top 10 lists are language agnostic

1. Injection
2. Cross-Site Scripting
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-site request forgery
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards.

1. Threat Agents
2. Attack Vectors
3. Security Weaknesses
4. Security Controls
5. Technical Impact (Dependant on asset)
6. Business Impact (dependent on nature of data)

Security is layered

Top 10 is the starting point not the end…

Anyone who send untrusted data to the system.

Simple text based attack

• Data loss/corruption
• Lack of accountability
• Denial of access
• Host take over

With regards to

• theft,
• modification
• deletion

Consider value of

• affected data
• the platform running the interpreter

Principle of least Privilege :: every modules in a system must be able to access only the information and resources that are necessary for it's legitimate purpose.

Update sql user permissions to be only what is needed.

• dbowner is too permissive.
• Give access to only tables needed.

Stop breaking out of data context (IE input parameter) into the query context. IE. can only change data, not the query

• Remove online string concatenation.
• Use new SqlCommand().Parameters.Add() method instead.

• Always parameterized value by default.
• Still possible to run injection if just running an exec! in the storedProc. eg. building a like.
  • use sp_executesql not exec

• alway validate data
• explicit filter out anything not truster

Whitelist is a more future proof alternative than a blacklist

• Automates parameterization.

Automation reduces the bar to entry. IE makes injection easier.

• http://havij-advanced-sql-injection.software.informer.com/

Anyone who send untrusted data to the system.

Simple text based attack

Execute scripts in victems browser

• hijack session
• deface web sites
• insert hostile content
• redirect users
• hijack via malware

Consider value of

• affected system
• all data it processes

Include in consideration impact of

• public exposure of exploit

XSS mitigation is making sure untrusted data is rendered the same whay it was entered.

• Use output encoding, (eg. html encoding) for display the characters.
• • CSS
  • HTML, HTML attribute, HTML form url
  • Javascript
  • LDAP distungished name, LDAP filter
  • URL, URL path
  • XML, XML attribute
• Frameworks encoding actions
  • WebForms: Different controls will encode differently.
  • ASP.MVC: Razor encodes everything by default.

Persistent XSS is stored in the datbase.

Each encoding context required different encoding sequences.

Using a proven library is the right approach. Do not roll your own

• regex is a viable option against string data
• Be careful not to miss valid chars. eg. ~@"^\p{L} \.­\+$"~ ~ misses quotes.

Requestion validation is on by default in ASP.NET so attacks will be caught before request hits usercode.

Returns A potentially dangerous... error is returned.

<configuration>
  <system.web>
<!-- explictly enable request validation,
`validateRequest` attribute will be missing and `true` by default -->
    <pages validateRequest="true"> ... </pages>
  </system.web>
</configuration>

validateRequest can be disabled

• Pre-ASP.NET 4.5 - done on the page level. eg. for a WYSIWYG editor.
• ASP.NET 4.5 - done at control level, or code behind.
• ASP.MVC - The decorator AllowHtml can be set on a Model value.

<%@ Page Title="disabled request validation" ValidateRequest="false" Language="C#..." />

Code as if request validation doesn't exist. It is a last line of defense.

1. Some browers blocked thing on their own.
2. Custom headers provide a method to control browser behaviour.
3. Cannot rely on brower implementations

• Encode the entire url.
• Use a url shortener.

• Output encoding is base of XSS protection
• Default Encoding is performed differently be different frameworks
• Whitelist are important
• Request validation isa safetly net
• Code as if XSS is in the database
• brower defenses are inconsistent
• Expect attack obfuscation to occur

Anonymous external attackers trying to steal accounts, Insiders wanting to hide their actions

Leaks/flaws in authentication/session management functions to impersonate users

• Allow all account to be attacked
• Full priveleages of attacked user

Consider value of

• affected data
• application functions

Include in consideration impact of

• public exposure of vunerability

Rolling your own authentication is hard. The recommendation is to use pre-rolled. Eg. ASP.NET's MembershipProvider

Timeout is a balance between the convenience between

1. user remaining logged in and
2. session becoming hijacked.

ASP Default

• Session : 20 minutes
• 30 minutes

By default, A new ASP.NET Forms application will increase the timeout to 2 days

Types

• Sliding - <forms sliding="false" /> - Ends XX time after inactivy.
• Fixed - default - Explict duration.

1. Cryptographically secure password credential storage.
2. Robust minimum password criteria.
3. Never send password by email.
4. Protect session IDs in cookies.

Users with partial access

Authorised user changes a parameter value, and get access to another object the user isn't aithourized for.

• Compromise all data referenced by the parameter
• Commonly all data of that type

Consider value of

• exposed data

Include in consideration impact of

• public exposure of vunerability

Correct access control makes sure users can only access the appropriate records.

Heart of Indirect Object Reference Access is a lack Access controls.

An abstration between what is publicly obwservable and the individual database record.

• Map internal records to temporary, user specific, random record.
• Server maintains a map between the the temp record and the internal value
• • Temporary
  • User specific
  • Indirect reference is random
• • Multiple front ends?
  • Potential overhead?

• INterger and natural string types can be enumerated
• Non pattern bases surrogate keys add further obfuscation (eg GUID)
• Security through obscurity,
• There are tradeoffs.
• Not real proper access control

Anyone who can trick users into submitting a request to your site.

Attecker create forged HTTP request and tricks user into submitting them. If the user is authenticated the attack succeeds.

• Change any data the victen can change
• Perform any function the victem can perform

Consider value of

• affected data or application functions
• Imagine not being sure if the user performed the actions

Include in consideration impact on

• customer
• reputation

A CSRF token is a random string known to both legitimate page where the form is and the browser via cookie.

The token is know to the page and is validated against the value in the cookie

1. Implement referrer checking wil restrict cross-domain request Partially helpful, but this does not address the risk introduced by XSS.
2. Disable HTTP GET on at-risk pages Attacker can still construct POST requests
3. Valida the IP address from loading page to POSTing IP. Does not help since it will be the client's IP each time

The only real defense is CSRF tokens.

• CRSF risk may be exploited by Cros-Origin-Resource Sahring (CORS)
• Drifferent vrowsers provide variting levels against CORS
• Should never be relied on.

• Anonymous external attackers, users withown accounts, insiders trying to hide actions.

• acccesses default accounts, unused pages, unpathed flaes unprotected files,
• to gain access/knowlege of the system

• Unauthorized access to system data or functionality
• Complete system compromises

Consider value of

• complete system
• all data

Include in consideration impact on

• complete compromise without knowledge of it
• recovery costs
• modification of data over time

To stop automated tools fromscrapping for errors:

1. Enabling Custom Errors - (Hide internal implementation details)
2. Rediret to 404/Error page, (Hide the custom error 500)
3. Rewrite the response - (Hide url/response code from displaying the error)

<configuration>
  <system.web>
    <customErrors mode="On" defaultRedirect="Error.aspx" responseRewrite="true"/>
  </system.web>
</configuration>

• user of your system
• internal administrators

• Attackers don't ussually break crypto
• They break something else to get keys, copies of data, or access data via automatic decryption channels

• Frequently compromises all data that should be encrypted

Consider value of

• lost data

Include in consideration impact of

• reputation
• legal implocations

• Symetric encryption use a single password for encryption and decryption
• Asymetric using a public prive key pair
• Is reversible for both cases.
• • encryption is useless is private key is known
  • most compromised datastores, often include the source files with the private keys

• Uses the machine key for encryption
• Included in System.Security.Cryptography.ProtectedData namespace
  • Processes can share data with LocalMachine

• Anyone with network access to send a request to the application

• Changes to a url grants access to privileged page.

• Allows attackes unauthorized functionaliy
• Admin functions are key targets

Consider value of

• exposed functions
• data exposed by the functions

Include in consideration impact of

• reputation if publicised

1. Path level in web.config location element, and Roles (location level is pretty heavy handed)
2. Method level in class using principal permissions
3. Entire MVC controller with Authorize attirubue
4. MVC controller action with Authorize attribute
5. Any point in code using ASP.NET Identity and Role Feature

• Overlooked URLs (api endpoints, resources (docs, pdf))
• Obfuscation is not access control (urls, ips…)
• Urls with credential (caching, proxies, included https…)

• Anyone who can monitor network traffic

• Difficulty comes from monitoriing while the user is using the website

• Accoutn theft
• Facilitation of phishing, and Man in the middle attacks

Consider value of

• data exposed on the communications channel

Include in consideration impact of

• confidentiality
• integrity needed by both pariticpants.

Cookies with Secure flag set will not be sent to non-http requests. The Secure flag will only be set by the server, The browsers does not send the cookie with the flag.

Different level of cookie security

1. Enable SSL for the authentication cookie
2. Enable SSL for all cookies
3. Keep a cookie as non-secure

<system.web>
  <authentication mode="Forms">
    <forms loginUrl="~/Account/Login/" timeout="2880" requireSSL="true" />
  </authentication>
<system.web>

<system.web>
  <<httpCookies requireSSL="true" />
</system.web>

Response.Cookies.Add(new HttpCookie("UnsecureCookie"){
  Value = "cookie-value",
  Secure - false;
});

For Web Forms,

/* On Page_Load */
// Be careful that the box actually runnning this is handling the cert (ie. NOT behind a load balancer)
if (Request.IsSecureConnection()) {
  var secureUrl = GetUrl().replace("http", "https");
  Response.RedirectPermanent(secureUrl);
}

For ASP.MVC, just use an attribute per action,

[RequireHttps]
public ActionResult SomeActionTheMustBeHTTPSListRegister() { return View(); }

https is for confidence and integrity. If a single resource is not http all confidence and integrity is lost. Hence the Mixed content warning in browsersn

Browser load content relative URL using the parent pages scheme.

<!-- Note the // -->
<script src="//ajax.com/jquery.js" type="text/javascript" ></script>

Stop browser from making any unsecure request with HSTS header. HSTS header stops man in the middle requests.

HttpContext.Current.Response.AddHeader("Strict-Transport-Security", "max-age=31536000");

• Loading login from http, but post to https
• https form inside https inside a http iframe
• Allowing http when there is no use case where it ever should be
• Passing sensitive information in a https url.

• SSL comes at a cost. but it was a 1% cpu load, and 2% network overhead for google in 2010.
• Inital unsecure requests can always be picked up be man in the middle attacks. eg MithM attacks like sslstrip then fake the https.
• Intergirty of the Certificate Authenticaties is paramount to the whole https landscape.

• any one who can trick users into submitting requests

• links to unvalided redirect and trick victent to clicking it.

• Attempts to install malware, phishing, disclosing sensitive information
• Unsafge forwards may allow access controll bypass

Consider value of

• retaining users trust

Include in consideration impact of

• client getting owned
• attackers access internal only functions

1. Whitelist the redirect
2. Check to see is a user is coming from own own site.

var url = Request.QueryString["redirectTo"];

// 2. Check to see is a user is coming from own own site.
var referrer = Request.UrlReferrer;
if (referrer.?Host != Request.Url.Host) {
  throw new ApplicationException("Referrer is not this site.");
}

// 1. Whitelist the redirect
var db = new TrustedUrlsContext();
if (!db.TrustedUrls.Any(x => x.Url == url)) {
  throw new ApplicationException("URL not trusted");
}
Response.Redirect(url);

• Often viewed as a light risk, used as a launchpad
• Google does not pay bug bounties for the risk.
• Risk is about reputation