Web Dev Theory Stuff

Theory stuff

Table Of Contents

• CORS
• CSRF
• 403 vs 401
• How to store password
• HTTPS
• process-when-visit-URL

CORS

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

CSRF

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 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.

CORS

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

1. 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

2. 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

1. 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/

1. 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

Store password in DB

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

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

BCrypt
more info

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

bcrypt VS md5

• slower => brute force attacks are less effective
• can increase the number of iterations to match computing power. (if computing power increases)info Auth0 article explains why bcrypt (salt generation) is preferred

HTTPS

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.