Why is web security important?

• How do we use the web today?
  • Shopping, Banking, Conversations, ...
  • Sensitive and important information
    • Privacy, Society, Web of things (Internet of Trouble)
  • Downtime === lost of money
    • Denial of Service (DOS, DDOS)
  • Rendering code running on clients
    => more attack vectors

What is web security?

• Risk factors
  • Undeveloped awareness, education
  • Simplicity to build web applications
    • Copy & paste
  • Functionality vs. security
  • Time, cost
    • Expertise in web security?
  • New attacks, new technology, hard to staying up-to-date!
  • Security in different layers of the service
    • Not just the code...

Always be suspicious!

The application must always assume that all input is potentially malicious

OWASP

Open Web Application Security Project

• Open, global non-profit organization
  • https://www.owasp.org
• The Top 10 OWASP
  • No changes in 2020...
• Web Security Testing Guide (WSTG)

XSS - How?

Image from: http://excess-xss.com/ Excess XSS by Jakob Kallin and Irene Lobo Valbuena is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

XSS - Protection?

• Client validations?
• Validate/Sanitize input or output?
  • FIEO - Filter input, escape output
    • Encoding harmful characters ( < and > ect.)
  • Whitelist/Blacklist
  • How will our application use the data?
• How does your template engine work?
  • How does you use the output in your application?

    document.querySelector('a').href = userInput
    // userInput = "javascript:alert('hacked')"
    

  • Implementing modules like https://github.com/yahoo/xss-filters ?

XSS - Protection - CSP

Content Security Policy

• Using the Content-Security-Policy HTTP header
• Widely supported in modern browsers
• Whitelisting allowed sources of script, style, and other resources.

  Content-Security-Policy: default-src 'self'; img-src *;
  media-src media1.com media2.com; script-src cdn.script.example.com

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://github.com/helmetjs/helmet

CSRF - How?

CSRF - How?

by using GET requests for state changing operations.

CSRF - Protection?

• Synchronized Token pattern (STP)
  • Check that the request is made by our client
  • Include a token in forms (and/or in meta tag)
  • Must be unique for each request

  <form action="/account" method="post">
    <input type="hidden" name="_csrf" value="HvtsC1Ka-yq1Q2KPAu_Yh_H8F4vJEYfMIlBQ" />
  </form>

https://github.com/expressjs/csurf

CSRF - Protection?

• Same-site cookie
  • Pretty new, but implemented in most modern browsers
    • https://caniuse.com/#feat=same-site-cookie-attribute
  • strict
    • prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link (e.g. GET).
  • lax (default from 2020)
    • Blocking POSTs

const sessionOptions = {
  name: 'name of keyboard cat', // Don't use default session cookie name.
  secret: 'keyboard cat', // Change it!!! 
  resave: false, // Resave even if a request is not changing the session.
  saveUninitialized: false, // Don't save a created but not modified session.
  cookie: {
    secure: true, // should be true to check that we´re using HTTPS
    httpOnly: true, // dont allow client script messing with the cookie
    maxAge: 3200, // will live for 1 day
    sameSite: 'lax' // protect against POST csrf-attack(?)
  }
}

Injections - How?

"SELECT * FROM user WHERE username='" + request.getParameter("username") + "'";

// will show all accounts
"SELECT * FROM user WHERE username='' or 1=1--"

SQL Injections

Injections - noSQL

• You're not safe!
• A lot of different databases with a lot of query languages
• MongoDB
  • JS syntax permitted in some queries
  • $where, $or, ...

      db.myCollection.find( { $where: function() {
        return obj.credits - obj.debits < $userInput; }
      });
    

• mongoose.js
  • Handle all input as strings
  • OK, you're safe...hopefully

Session cookie and HTTPS

const sessionOptions = {
  name: 'name of keyboard cat', // Don't use default session cookie name.
  secret: 'keyboard cat', // Change it!!! 
  resave: false, // Resave even if a request is not changing the session.
  saveUninitialized: false, // Don't save a created but not modified session.
  cookie: {
    secure: true, // should be true to check that we´re using HTTPS
    httpOnly: true, // dont allow client script messing with the cookie
    maxAge: 3200, // will live for 1 day
    sameSite: 'lax' // protect against csrf-attack?
  }
}

Certificates

• A digital signed document
  • Often created by a trusted part (CA - Certificate Authority)
    • Browser have a list of these
    • Bind to your domain name, could cost money, different levels of trust
    • Comodo, Symantec, GlobalSign...
  • https://letsencrypt.org/ - Check it out!
    • In development we can create our own - Self-signed

Extended Validation (EV)
Like OV plus more control of the organization that gives higher thrust

Encryption

• Symmetric
  • Both parts have the private/secret key
• Asymmetric (public-key encryption)
  • A public key is used to encrypt a messages
  • A private key is used to decrypt the message
  • The part that only have the public key can only encrypt the message
  • Only the part with the private key can decrypt

1. Client connect on port 443, requests the server identity
2. Server sends a copy of the TLS Certificate, including servers public key
3. Client check against list of thrusted CA´s and that the certificate is valid. Creates a symmetric key, encrypt it with the public key from the server.
4. Server decrypt the symmetric key with its own private key. Start using the symmetric key when encrypt the messages
5. We have a trusted and encrypted communication