not a problem if using an ORM or a NoSQL database
Broken Authentication and Session Management
a. session hijacking
- use https so that attackers cannot see the cookie containing the session id of another user
- session timeouts can be helpful. if a session id / cookie is stolen, the attacker has a limited time to exploit it
- super tin foil hat:
store user agent as part of the session id in the cookie. if the user is using chrome all the time and then all of a sudden is using IE, there may be a problem do something from that point, maybe log the user out, or flag all actions taken by the user from that point in time.
b. unencrypted passwords
- never store passwords in plain text
- always hash passwords
- always append a randomly generated salt to the password before hashing it to prevent reverse rainbow attacks
- always use slow hashing functions. 0.5 seconds can be good. not enough for a human to notice, but slow enough to make brute force attacks infeasible
Cross site scripting (XSS)
If you are exposed to XSS it is impossible to prevent other attacks like cross site request forgery.
3 types of XSS:
- type 0 - DOM based, everything happens on the client. eg opening inspect element and deleting paywalls from the html code, etc.
- type 2 - Non-persistent / reflective (MOST COMMON). Commonly used in search fields, or form fields, where the server returns data a user entered.
- all three are running in the same "security context".
- the "security context" has only do with where it is loaded. e.g.: http://www.mydomain.com:80
- protocol, domain and port, which all have to match
- same origin policy. CORS.
- escape these characters for html entities, i.e. blacklist them:
- tag delimiters < >
- attribute delimiters " '
- the ampersand character &
- maybe use the X-XSS-Protection HTTP header to take advantage of inbuilt browser XSS protection (set to 0 to turn it off)
- use "content security policy". !!!!!!!!!!
- server sends an http header Content-Security-Policy and a policy telling the browser where to load resources / data from.
- image-src -> where to load images from
- script-src -> where to load scripts from
- style-src -> where to load stylesheets from
- font-src -> where to load fonts from
- default-src -> where to load everything from
"Content-Security-Policy": "default-src 'self'" "Content-Security-Policy": "image-src http://localhost:1234 'self'"
js from another origin - 'self' means load it from the current origin. if it's not from the current origin, don't load it.
js from the server - only if the attacker was able to upload js to the server beforehand then execute it.
- but if this is possible, then you have bigger problems wanna enable inline?
"Content-Security-Policy": "default-src 'self' 'unsafe-inline'"
- the browser enforces that. so, if the policy says "only load images from here", the browser will do it.
- if there are some images from somewhere else, the browser just wont load it.
- tin foil hat stuff:
- only load js code if it has THIS hash. but this option is only available in CSP version 2.
Broken Access Control
- access control to data
- access control to functions
in an mvc application, normally a URL maps to some function. if you think your URLs are secret, think again. you need to assume people can guess them. so you need to protect them. - send an http post to some create endpoint, with two fields called title and description.
- the http post has a creation date which is just set to the current date in the model class.
- but if the http post request contains a creation date which is filled by the app, not the user, this is potentially overridable.
- if the creation date field is instead something like... is_admin, then this could be bad.
- So don't let users set important information via the client like this.
- Do not send detailed error messages to the client.
- Do not send application versions to the client.
- Patch OS packages.
Sensitive data exposure
- if you go to http://blah.com, and the server rewrites the request to https, and you have some session token in the request the first requests is visible, the very first one.
- if you use the hsts header, this eliminates this attack vector.
- for passwords too!
Insufficient Attack Protection
- Detect Automated Attacks
- Tin Foil: Detect Manual Attacks
- Quickly Install Patches
Cross Site Request Forgery (CSRF)
- trick someone into going to your website
- that code prompts your browser to send an http request to another site
- the other site might be your router at home and the request might be "change the WPA2 key"
- how do i know your router? google the most common router in xx country
- how do i know the default ip of that router? buy it and check the ip
- social engineer someone to log into logging into their router before going to your site
- then find out where the person lives and you have free wifi
- ... super tin foil hat, because it's advanced
Using components with known vulnerabilities
For example: redis
Do not just protect your website, also protect the APIs.
Once you have an external link on your site to a link you do not control, you need to add rel="noopener" to the anchor tag to prevent the link from redirecting the original tag to a phishing site.
<a href="blah.com" target="_blank">link</a> <a href="blah.com" rel="noopener" target="_blank">link</a> // Add noreferrer for firefox prior to version 52. <a href="blah.com" rel="noopener noreferrer" target="_blank">link</a>