Sunday, 30 January 2022

Web security fundamentals

 

Importance

  • Website security is important to protect your business, brand, and website reputation and also prevent financial loss.
  • You will be able to protect your website reputation and retain customers and/visitors.

Type of attackers

  • Black hat hackers: A black hat hacker is a hacker who violates computer security without permission, for their own personal profit or out of malice. 
  • Grey hat hackers: They also don't have permission to enter into the system, but they break into it. Making no damage, can report the vulnerabilities as well. They do it mostly due to curiosity. 
  • White hat hackers: They break into the system but with permissions. They get paid and hence make money in terms of "bug bounties". They are also called as Ethical hackers. 

Type of attacks

    Attacks on Client side

  • XSS: Cross-site scripting
  • CSRF: Cross-site request forgery
  • Click jacking

    Attacks on CDN side

  • Resource tempering, or 3rd party access

    Attacks on Server side

  • HTTPS downgrade
  • Man in the middle

XSS: Cross-site scripting

  • CSS is already a defined term for developers so it's called 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 frameworks took this vulnerability seriously 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-site 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.

  • Prevention and 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 extensions. Since they have the access to all of the content (depending upon the permission provided), and then inject code anywhere, even on an HTTPS certified page.
    6. Don't make any secret URLs for some advanced users to any public-facing App. Like to allow some to see the Database schema, to open any admin page, to get a database dump. Even with the read-only permissions.

CSRF: Cross-Site Request Forging

  • Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering, an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
  • Works on the fact that cookies are passed with requests.
  • Considering the fact that request can be made by multiple other ways apart from Http[s] request. Like as <image src='' /> or in a <form> submit action. Prevention:
  • To defeat a CSRF attack, applications need a way to determine if the HTTP request is legitimately generated via the application’s user interface. The best way to achieve this is through a CSRF token. A CSRF token is a secure random token (e.g., synchronizer token or challenge token) that is used to prevent CSRF attacks. The token needs to be unique per user session and should be of large random value to make it difficult to guess.


Click jacking

  • Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.
  • One of the most notorious examples of Clickjacking was an attack against the Adobe Flash plugin settings page. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer’s microphone and camera.

  • Clickjacking also made the news in the form of a Twitter worm. This clickjacking attack convinced users to click on a button which caused them to re-tweet the location of the malicious page, and propagated massively.

  • How to defend Click jacking:
    1) CSP: Sending the proper Content Security Policy (CSP) frame-ancestors directive response headers that instruct the browser to not allow framing from other domains. (This replaces the older X-Frame-Options HTTP headers.)
        CSP is usually implemented in the web server as a return header of the form.    


    Content-Security-Policy: frame-ancestors 'self';
     
    X-Frame-Options: ALLOW-FROM https://example.com/

    2) Employing defensive code in the UI to ensure that the current frame is the most top level window.
      

    if(self == top){
         //not inside iframe
    } else {
        // inside an iframe
    }

3rd Party Access

  • Types of using third party assets:

    1) Using a resource that is hosted somewhere else and we are just requesting it in.
       


    2) Using a versioned dependency (npm dependency)

       "react":"^17.1.2"


      Here the code is pushed into some other repository and we just pull it in.
    3) When the script added, makes its own request to load and run the actual script. This is worst because the version is not being controlled and we will not be aware about the changes.

  • All of the three above attacks can be possible on 3rd party attacks because of the same reason. Also, people who write your dependencies make mistakes.
  • Prevention:
    1) What you test is what you ship. To have package-lock.json file in your npm project to make sure the version won't change in production.
    2) Use LTS (Long Term Support) version, might miss some new edge cases but will get security patches and will be more stable.
    3) Support Bug bounties
    4) Tests that assert only expected requests are sent out, no other requests.
    5) Use CDNs only from a trusted source.
    6) Check the changelogs before using a different version.
    7) Use "integrity" attributes for all <script> tag and <style> tags. 
      

Man in the middle

  • A man in the middle (MITM) attack is a general term for when a perpetrator positions himself in a conversation between a user and an application—either to eavesdrop or to impersonate one of the parties, making it appear as if a normal exchange of information is underway.
  • The goal of an attack is to steal personal information, such as login credentials, account details and credit card numbers. Targets are typically the users of financial applications, SaaS businesses, e-commerce sites and other websites where logging in is required.

  • Successful MITM execution has two distinct phases: interception and decryption.

  • Interception: The first step intercepts user traffic through the attacker’s network before it reaches its intended destination. 
    The most common (and simplest) way of doing this is a passive attack in which an attacker makes free, malicious WiFi hotspots available to the public. Typically named in a way that corresponds to their location, they aren’t password protected. Once a victim connects to such a hotspot, the attacker gains full visibility to any online data exchange. Attackers wishing to take a more active approach to interception may launch one of the following attacks: IP spoofing, ARP spoofing or DNS spoofing

  • Decryption: After interception, any two-way SSL traffic needs to be decrypted without alerting the user or application. A number of methods exist to achieve this: HTTPS spoofing, SSL BEAST, SSL hijacking and SSL stripping.

  • Prevention:
    1) Avoiding WiFi connections that aren’t password protected.
    2) Paying attention to browser notifications reporting a website as being unsecured.
    3) Immediately logging out of a secure application when it’s not in use.
    4) Not using public networks (e.g., coffee shops, hotels) when conducting sensitive transactions.

HTTPS downgrade

  • Nowadays, most websites and web applications use HTTPS as their default protocol because of following benefits:
    1) It guarantees confidentiality since data exchanged between the client and the server are encrypted.
    2) It ensures authenticity since the domain identity is verified by a trusted third-party (Certificate authorities).
    3) It offers data integrity since any tampering attempt is detected.
    4) In other words, by using HTTPS, you avoid typical person-in-the-middle (man-in-the-middle) attacks, where an attacker intercepts and possibly alters messages exchanged between the client and the server.

  • However, even if you enabled your website to use HTTPS, there are situations that an attacker can exploit to downgrade the secure protocol to the unprotected HTTP. How can this happen?
    1) Suppose your website is using HTTPS, but you missed updating a link in one of your pages, or from search results or from an legacy SEO URL, or from a bookmark, user clicks on a link which is still using HTTP.
    2) This link uses plain HTTP. What happens if the user clicks that link and the HTTPS-enabled server receives a plain HTTP request? The typical approach is to redirect the client to use HTTPS, as shown by the following diagram:

    3) However, an attacker may intercept that apparently harmless HTTP request and trigger the person-in-the-middle attack you are attempting to avoid with HTTPS. The following diagram shows how interception may 636pxoccur:

    4) From that request on, all messages sent by the client are transmitted via HTTP and manipulated by the attacker.

  • Defenses:
    1) Content-security-policy: upgrade-insecure-requests
    The HTTP Content-Security-Policy (CSP) header can help you force browsers to use HTTPS throughout your website. The upgrade-insecure-requests directive is designed for this purpose. By adding the following meta tag in the head section of all the pages of your website, any link using HTTP will be interpreted as if it uses HTTPS:

    <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">


    2) Using HSTS
    There are situations where the CSP upgrade-insecure-requests directive may not be enough. For example, this happens when a third-party website has a link to your website with the http scheme.  Actually, the upgrade-insecure-requests directive tells the browser to use HTTPS for any further request originated by that page. However, the page itself is supposed to be requested through HTTPS. If it is requested via HTTP, the person-in-the-middle attack may still happen, and the attackers can manipulate the HTTP headers before they reach the browser. In other words, the CSP upgrade-insecure-requests directive doesn't eliminate the risk of having HTTPS downgraded to HTTP. You need a way to tell the browser to use HTTPS to request any resource of your website, not just the resources linked to the current page. This is the purpose of another HTTP header: the HTTP Strict-Transport-Security header (HSTS). 
    Eg:

    Strict-Transport-Security: max-age=31536000; includeSubDomains



    * Note: CSP is resource specific while HSTS is for the entire domain.

    3) Browser plugins(HTTPS Everywhere) that attempt auto upgrade whenever possible. 

Sources


at No comments:
Subscribe to: Posts (Atom)