Table Of Contents
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.
Cross Site Request Forgery
web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform.
- Relevant action. There is a privileged action within the application that the attacker has a reason to induce.
- 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.
- No unpredictable request parameters. The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess
cookies only accessible by only your domain
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.
403 - can login, is authorized user of application but not enought priviledge to access functions.
401 - cannot login, unauthorised user
JSON Web token
compact and self-contained way for securely transmitting information between parties as a JSON object.
JWT VS Cookie
Cookie is automatically sent by browser. JWT must be attached to HTTP headers every HTTP call.
as user base grows must store more session data.
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
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
if a lot of data encoded in JWT there will be significant overhead with every HTTP request.
- 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.
- 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.
Store password in DB
- Dont store plain text
- Hash passwords
- Add salt (random phrase) to password
- Add dynamic salt (random phrase that changes for every user). each user will have to store hashed password + dynamic salt.
- use BCrypt VS md5. (BCrypt does salt)
- never tell someone their selected password is not unique
very quick hashing function -> faster calculation - faster brute force attacks
- generate salt
- hash password with generated salt
- 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
previously SSL not TLS
- 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.
- 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.
Top comments (0)