Web Dev Theory Stuff
Published: 2021-04-20 15:49:05

Theory stuff

## Table Of Contents
  * [CORS](#cors)
  * [CSRF](#csrf)
  * [403 vs 401](#403-vs-401)
  * [How to store password](#how-to-store-passwords)
  * [HTTPS](#https)   
  * [process-when-visit-URL](#process-when-visit-URL)     

### <a name="cors">CORS</a>
Cross Origin Resource Sharing
HTTP-header based mechanism that allows a server to indicate any other origins than its own from which a browser should permit loading of resources. 
[source](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)

### <a name="csrf">CSRF</a>
Cross Site Request Forgery
web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform.
Attack requires:
1. Relevant action. 
There is a privileged action within the application that the attacker has a reason to induce. 
2. Cookie-based session handling. 
Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. 
3. No unpredictable request parameters. 
The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess

https://portswigger.net/web-security/csrf
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

workaround:
same-site policy
cookies only accessible by only your domain

Cookie security:
[HttpOnly cookie](https://www.cookiepro.com/knowledge/httponly-cookie/) prevents client-side scripts from accessing data. It provides a gate that prevents the specialized cookie from being accessed by anything other than the server.


### <a name="403-vs-401">CORS</a>
403: Forbidden 
401: Unauthenticated

403 - can login, is authorized user of application but not enought priviledge to access functions.
401 - cannot login, unauthorised user

### JWT
JSON Web token
compact and self-contained way for securely transmitting information between parties as a JSON object.
https://auth0.com/docs/tokens/json-web-tokens

### JWT VS Cookie
Cookie is automatically sent by browser. JWT must be attached to HTTP headers every HTTP call.
https://stackoverflow.com/a/37635977

1. Scalability
as user base grows must store  more session data. 

2. Seurity
JWT if stored in web storage (local/sessino storage) is vulnerable to XSS.
Cookies may be vulnerable to CSRF

to circumvent attacks JWT usually have short expiration time

3. REST ful API
RESTful API is stateless - when request is made response with certain parameters can alwayse anticipated
JWT is stateless, cookie it not. cookie mantain session state

4. Performance
if a lot of data encoded in JWT there will be significant overhead with every HTTP request. 

https://ponyfoo.com/articles/json-web-tokens-vs-session-cookies

6. XSS 
Cross site scripting
inject malicious code into vulnerable web application. It doesn't directly target aplication, users of web application are the ones at risk. 

https://www.imperva.com/learn/application-security/cross-site-scripting-xss-attacks/

7. localStorage VS sessionStorage
data in sessionStorage clear when page session ends but data in localStorage doesnt expire. 

 both access a session storage object for the current origin. 

https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

### <a name="how-to-store-passwords">Store password in DB</a>
https://www.vaadata.com/blog/how-to-securely-store-passwords-in-database/
https://www.geeksforgeeks.org/store-password-database/
https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/
1. Dont store plain text
2. Hash passwords
3. Add salt (random phrase) to password
4. Add dynamic salt (random phrase that changes for every user). each user will have to store hashed password + dynamic salt.
5. use BCrypt VS md5. (BCrypt does salt)

Note:
- never tell someone their selected password is not unique

<u>md5</u>
very quick hashing function -> faster calculation - faster brute force attacks

<u>BCrypt</u>
[more info](https://javascript.plainenglish.io/how-bcryptjs-works-90ef4cb85bf4)
1. generate salt
2. hash password with generated salt
3. can choose value of salt Rounds (increase time to compute hash & reduce brute force attacks) 
however time to compute hash must not be too long so users will not run out of patience

<u>bcrypt VS md5</u>
- slower => brute force attacks are less effective
- can increase the number of iterations to match computing power. (if computing power increases)[info](https://javascript.plainenglish.io/how-bcryptjs-works-90ef4cb85bf4)
[Auth0](https://auth0.com/blog/hashing-in-action-understanding-bcrypt/) article explains why bcrypt (salt generation) is preferred


### <a name="https">HTTPS</a>
previously SSL not TLS
https://robertheaton.com/2014/03/27/how-does-https-actually-work/
1. Hello
2. Certificate exchange - server sends client its cert + public key (authentication, server is not impersonator) (SSL cert contains public key)
certificates usually come with digital signature, (signature encrypted with CA's "private" key) so you can take the CA public key decrypt and check if cert is signed by correct CA.
3. Key Exchange - exchange symmetric key (encrypted with public key). 
All information exchanged encrypted with symmetric key since symmetric key can do encryption a lot more efficiently.

man in middle can technically replay info from client to server. but information is encrypted and attacker will not have server's private key to decrypt and read information. 

![alt text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pmli43mw98b8d6ec2zp4.png)