Web security | Web development part 1

Table of contents:

1. Problem

 Problem

• Feature and deadlines vs Security
• Web development is less focused on how could things go wrong and more towards how to load the page faster.
• It's easier to attack now as it was earlier, due to the availability of various tools. 

    Hence the dev ought to make sure, that his feature not just won't break but, also mischief can't be caused.

Type of attackers

• Black hat hackers: cause damage, hold(encrypt) the data for some ransom, for their personal gain.
• Grey hat hackers: They also don't have permission to enter into the system, but they break into it. But make no damage, can report the vulnerabilities as well. They do it mostly due to curiosity. 
• White hat hackers: Break into the system but with permissions. They get paid and so make money "bug bounties". 

Type of attacks:

    Attacks on Client side:

• Click jacking
• XSS: Cross side scripting
• CSRF
• 3rd party access

    Attacks on: CDN side

• Resource tempering

    Attacks on: Server side

• HTTPS downgrade
• Man in the middle

1. XSS: Cross site scripting:
   CSS is already a defined term for developers so it's called as XSS and not CSS.
   
   It's also called an injection attack.
   
   In short, this is to put and execute a code by some tricks in a place that is designed for a text.
   
   More than 30 % of sites are vulnerable to XSS attack in some way, might not be a very straight forward but could be possible in some browsers(mainly the older ones) at some time. 
   
   The hacker can perform actions on user's behalf. It becomes more vulnerable when the user is system admin or database admin. In this way, the hacker can allow permisstions to other users, create new admin users, drop the entire database.
   
   Vulnerable code:
   * EJS -- Embedded JavaScript 
   <h1>Hello, <%- name %></h1>
   expected input: name = "Shubham". <h1>Hello, Shubham</h1>
   hackers input: name = "Hacker is here ". <h1>Hello, Shubham<script>codeToHack()</script></h1>
   
   Although the modern libraries and framework took this vulnerability serious and they take care of such things. But there are still some ways, not the suggested one, but we still use it in one way or another. Like in React we have `dangerouslySetInnerHTML`. We might not be using this function, maybe the third part node module is using this. Or `innerHTML` in vanilla JS.
   
   Types of Cross side scripting:
   1. Stored XSS: Attackers code is persisted. Like a review posted by attacker had the XSS code, saved in the system and that is now being executed for all the users landing on that page. Here the code getting executed for more than user and is more dangerous.
   2. Reflected XSS: 
   3. DOM based XSS: Query param being rendered without escaping. 
   4. Blind XSS: Same as stored XSS but with one difference. It takes advantage of the fact that the interns apps go through less review, less scrutiny, and less testing. The attack on these apps can collect data for years and figure out the way/relation about public data or the actual site and then execute the actual attack. 
   
   
   Dangerous areas:
   1. Rich text editor
   2. element.innerHTML = 
   3. Anywhere users have control over a URL. Be it a path, path variable, or query param.
   4. Anywhere where the input is reflected back. `Couldn't find the account with username <% username %>`
   5. Browser plugins and extensios. Since they have the access to all of content (depending upon the permission provided), and the inject code anywhere, even on an HTTPS certified page.
   
   
   
2. Click jacking
3. CSRF
4. 3rd Part Access
5. Resource tempering
6. HTTPS downgrade
7. Man in the middle
   
   
   
   src: https://frontendmasters.com/courses/web-security/locations-for-xss-attacks/  and google