Web Security Notes

Web Security Notes

There are some security concepts in web development that a developer needs to understand. I wrote this note because nobody can remember all those things they read. Taking notes is a good way to store them instead of trying to remember them - impossible =)))

I. CORS

  • What: Technique that allows a server to indicate any other domains which can make requests to that server in the browser
  • Why we need: the same origin policy of browser which restricts JavaScript code from making requests from one domain to another domain

    Ex: you open a Facebook tab and a hacker website tab on your browser. The tab Facebook uses JS to request to the server, if there is no same origin policy, JS of hacker website could also make requests to the Facebook server. That’s why the browser needs to have a policy to detect JS of a resource could access other resources or not

  • How to work:

    • a client send a request to a server with Origin header which contains the domain of the current website
    • The server will validate the Origin, and if valid, return a response with the header Access-Control-Allow-Origin (often have the same value as the Origin header)
    • If there is no Access-Control-Allow-Origin header in a response or an invalid value there, the browser will return an error
  • Config CORS in Spring Boot:

    • Use @CrossOrigin annotation to enable cross-origin calls from a list of other domains
    • Define maxAge to cache the preflight response
    • Config at method level, class level, or globally
    • To config globally, you need to config a configuration bean that implement webMvcConfiguer to add CorsMappings

II. Attack Basics

1. SQL Injection

  • What: Attack that uses malicious SQL statement to access information that is not intended to display.
  • Results:

    • Extract sensitive data
    • Delete data or drop tables
  • How to prevent:

    • do not use string concat to build a query
    • use parameterized queries with spring JPA or JDBC to prevent that.
    • Principle of least privilege: reduce the permissions of the application/users at runtime
      so it can at most edit data, but not change table structures
    • Password hashing: use one-way hash algorithms such as Bcrypt, can use with salt

2. XSS - Cross-Site Scripting

Attackers can inject malicious JavaScript into your website.

a. Persistent XSS

  • How: user can add content such as new comments, and those comments which contain malicious JavaScript will be stored in database. So any other users who see that comment will be attacked, and their browser will run this javascript
  • Results:

    • Spreading malicious js on social media sites, auto download something to your computer,...
    • Steal your session
    • Steal your sensitive data
  • How to prevent:

    • Escape dynamic content: replace significant characters with HTML entity encoding => the script will never be treated as executable code by the browser
    • Whitelist values: users have to select from a list rather than provide any input
    • Implement Content-Security Policy that defines script source and tells the browser to never execute inline JavaScript
    • HTTP-only cookies: mark cookies as HTTP-only so cookies will be received, stored, and sent by the browser only, but cannot be modified or read by JavaScript
  • Set HTTP-only on Spring:

    • Create a ResponseCookie object
    • Set HTTP only = true, set maxAge
    • Add cookie to the response

b. Reflected XSS

  • How:

    • Hacker injects malicious JavaScript into the query string and sends it to users
    • Users click to that URL, the server will respond the parameter back to the user (such as on the search results page)
    • Then the browser will render the script (send requests to the hacker website with the param is the cookie of users).
    • Hacker server has session or cookie, then can call to that website as that user.
  • Types of pages will be attacked:

    • Search results: search criteria get displayed back to the users
    • Error pages: have an error message which contains invalid input, does the input get escaped properly when it is displayed back to the user?
    • Form submissions: if a page post data, does any part of the data being submitted by the form get displayed back to the user?

3. CSRF

  • What: If hackers can forge HTTP requests to your site, they may be able to trick your users into triggering unintended actions

  • How to attack:

    • User login to their website A
    • Hacker create a malicious website and trick users to click on their link
    • In the hacker’s website, there is a form or img to forge a request to website A with user’s cookie
    • Website A has no way to distinguish between a forged request and an actual request
    • That request could do some intended action via the user’s account such as posting a new post, spreading worms on social media, or transferring funds from the visitor’s account to others,...
  • How to prevent:

    • Use REST standard: GET requests are used only to view resources => limit the harm that can be done by malicious URLs - an attacker will have to work much harder to generate a harmful POST request
    • Client-side generated CSRF-tokens: client code generates and sends the same unique secret value in both Cookie and a custom HTTP header.

      => considering a website is only allowed to read/write a Cookie for its own domain, so only a real website can send the same value in both headers

      => The server will compare the token attached to the request with the value stored in the cookie.

    • Check the HTTP Referer and Origin header: check the expected domain which triggered the request and reject any requests with abnormal domains

4. DDOS

  • What: Denial of Service, when attackers attempt to make your website unavailable to others
  • How: flooding with requests to exhaust all the available resources (server resources, network bandwidth) => real users are unable to get access
  • Types:
    • SYN flood: exploits 3-way handshake of TCP when client does not send ACK message to server so may connections do not close so that the server cannot open new connections with real users
    • HTTP Flood: hackers will exploit legitimate GET or POST requests => exhaust the server’s connection pool
    • Others: ...
  • How to prevent:
    • Block IP address => hackers will use distributed DOS
    • Apply rate limit for IP address, users
    • Autoscaling
    • Caching commonly accessed resources to reduce database access
    • Serve your images, videos and other resources from CDN so that you are offloading accessed resources to a third-party service designed to withstand large amounts of traffic

III. Other Concepts

Hash vs Encrypt vs Encode

  • Hashing is the act of transforming data from arbitrary size to a fixed size value. => use for checking the integrity of data or verifying the password (Bcrypt hashing)
  • Encode is a way to transform data into another form to preserve usability. Ex: we transform text, audio, image into bits 1 and 0 so computers can understand, store and process them.
  • Encryption is the act of transforming data into another form to preserve the confidentiality

    Ex: RSA encryption uses a public key to encrypt and a private key to decrypt data

Is there any way to crack Hash?

Yes of course. We can try to guess the original string by calculating the hash of every possible input and then comparing the results.

Encryption Algorithms

  • Symmetric encryption: uses the same key for both encrypting and decrypting data (such as AES,...)
  • Asymmetric encryption: uses a public key to encrypt and a private key to decrypt data (such as RSA,...)

To be continued...