Avatar

web security

security

Van Truong

## Hashing vs Encoding vs Encryption

| Hashing     | Encoding     | Encryption     |
| ---------- | ---------- | ---------- |
| converting a given __key__ into another smaller and __fixed-size__ value (`SHA-X`, `Bcrypt`, `MD5`)       | data is transformed from one form to other form. (`BASE64`, `ASCII`, `MP4`, `binary`, `decimal`, ...)       | An encoding technique, in which message (text, json…) is encoded by __encryption algorithm__ that only authorized people can read the message.RSA (Private key, public key)       |
| not reversible, collision       | reversible, no collision       | reversible       |
| key => value, password storage, __data’s integrity__ validation | purpose: transform data into a form that is readable by external process       | purpose: transfer private data, authorization       |

## Password Storage

> How to store passwords in DB securely ?

`Hash` + `Salt` + `Pepper`

- A `salt` is a unique, randomly generated string that is added to each password as part of the hashing process
- `Salt` is stored in database.
- Hacker has to crack hashes one at a time instead of calculating the hash once and compare with every stored hash. => slow hacking process
- Impossible to check if 2 users have same password. 
  - `hashed_password = hash(unique_salt + password)`

- `Pepper` is a randomly generated string that is added to password as part of the hashing process.
- `Pepper` is not stored in database. (`env` variable, secure centralized store)
- `pepper` is shared between all passwords rather than being unique like a salt.
- Prevent hacker from crack any hash if they only have access to the database.
  - `hashed_password = hash(common_pepper + unique_salt + password)`

## Symmetric - Asymmetric Encryption

`Symmetric encryption`:  both side (sender and receiver) share 
the same key to encrypt/decrypt the text, it is fast.

`Asymmetric encryption`
- When a message is encrypted using a `public key`, it can only be decrypted using a `private key`.
- When a message is encrypted using a `private key`, it can be only decrypted using a `public key`.
- Slow
- Most common algorithm: `RSA`

### RSA for authentication

The purpose is to confirm that a message has been sent by the entity who claims to have sent it, and proving that a message hasn’t been altered or tampered with.

- Sender produces a __digital signature__ by applying a hash function on a message m and sign it with the SK (Scret Key or Private Key)
  - `signature = encrypt(hash(m), SK)`

- Signer sends (`signature`, `hashed_of_m`) to verifier.
- Verifier verifies by reproduce message hash using PK (Public key) and compare with actual hash value.
  - To check who send it: check `decrypt(signature, PK) == hashed_of_m`
  - To check if message changed or not:	`hash(m) == hashed_of_m`

## TLS - Transport Layer Security

> HTTPS = HTTP + TLS

![TLS handshake](https://ssl.vn/wp-content/uploads/2018/09/ssl-tls-handshake-process-1024x670.png.webp)

- Using a __asymmetric encryption__ to setup TLS handshake
- Client sends `Client Hello` message to Server which include:
  - TLS version
  - Cipher suites client supports (algorithm)
  - Client random bytes

- Server sends `Server Hello` message to Client which include:
  - Server's SSL certificate
  - Server's chosen cipher suites
  - Server random bytes

- Client confirms Server's identity (authentication) by checking the server's SSL certificate using RSA encryption:
  - __*SSL certificate*__ contains:
    - __domain name__
    - __CA's digital signature__
    - __server's public key__
    - Other informations like: person/ organization owns the certificate, which Certificate authority (CA) issued it, issue date, expiration date, ...
  - The whole identity authentication is based on the idea `You trust the CA, and they trust me, therefore you can trust me.`:
    - The browser or OS has a build-in list of all CA's public key
    - It uses CA's Public Key to decrypt the CA's digital signature
    - It confirms that the decrypted data is matched.
      - Public key of server is included in the decrypted signature => check if it matches the public key in certificate.

- Key Exchange, use RSA
  - Client generates a random `pre-master secret`, encrypts it with the Server's public key (found in Server SSL's certificate), sends the result to Server
  - Server decrypts the `pre-master secret` using its secret key.
  - At this point, both Client and Server share the same `pre-master secret`. 

- Both Client and Server generate `Session key` or `Master Key` from `pre-master secret`, `client random`, and `server random`

  - `session_key = hash(pre-master secret, ClientHello.random, ServerHello.random)`
  - use client, server random to avoid replay attack: if there is no client random and server random, hacker capture the package and resend.

- Client is ready: The client sends a `finished` message that is encrypted with a `session key`.

- Server is ready: The server sends a `finished` message encrypted with a `session key`.

- The handshake is completed, and communication continues using the __symmetric encryption__ with key = Session key, since it is much faster.

## CORS

Two URLs have the same origin if they have the same: `protocol` (http, https), `host` (vnexpress.net, google.com), `port` (80, 8080)

```text
http://example.com/index.html

// Same origin
http://example.com/profile.html
http://example.com:80/profile.html

// Different origin
https://example.com/index.html
http://example.com:81/index.html
http://blog.example.com/index.html
```

__*SOP - Same Origin Policy*__: A web application using APIs can only request HTTP resources from the same origin the application was loaded from.
- a policy that is compiled by most of the browsers (security reason)
- Not apply for debug tool like `Postman`, `curl`
- Not apply for some html tags: `<script>`, `<img>`, `<link>`, `<frame>`, `<iframe>`

***CORS*** __is a mechanism to bypass SOP__, we can define which origin can request the server's origin

## JWT - Json Web Token

JWT is an open standard that defines a way for securely transmitting data between parties (client, server). This information can be verified and trusted because it is digitally signed.

> JWT = Base64(HEADER) + Base64(PAYLOAD) + Base64(SIGNATURE)

- __Header__: metadata about hashing algorithm being used
- __Payload__: data (user, expire time, role, ...)
- __Signature__: used to validate that the token is trustworthy 
and has not been tampered with

> With JWT token we can get data easily by decode payload (base64), it main feature is to check if that token is integrity or not.

> If hacker can get your JWT, they have full access to your account. Therefore, store it somewhere safe.

__*How JWT is validated*__
- JWT token is generate in server with a `secret key`
- When server receive a token: it check if the __Signature__ part is match with `hash(encode(header) + encode(payload), secret_key)` or not ⇒ Validation

__*Advantage*__
- __stateless__: server does not need to maintain a session storage because all authentication information is stored in JWT, which is stored in client side (browser).

- because JWT is sent along with the request in the __request header__, it eliminates the possibility of __CSRF__ (Cross-site Request Forgery) attack.

__*Disadvantage*__
- No Built-In Token Revocation by the User:
  - JWT only become invalid when it expires. The user has no built-in feature to explicitly revoke the validity of a token
  - The solution would be creating a database to maintain a revocation list. This would add complexity to the system and eliminate the stateless property of JWT authentication.


Storage, SSL/TLS, JWT, CORS, SQL injection ...

TAGGED POSTS security

Technical things about Web Security