Web application Security

Web application security is to prevent attacks that occur through Cross-site scripting (XSS), Click Jacking and Cross-Site Request Forgery(CSRF). This is possible to write flawless code and sanitize application inputs and outputs. The following are the major security threats in web application security. (all main heading list)

Cross-site Scripting (XSS)

Cross-site scripting (XSS) enables attackers to inject malicious code into web pages. Such code can then, for example, steal user data (in particular, login data) or perform actions to impersonate the user. This is one of the most common attacks on the web. There are three types of Cross-site scripting

  1. Reflected Cross-Site Scripting
  2. Persistent Cross-Site Scripting
  3. DOM-based Cross-Site Scripting

1 Reflected Cross-Site Scripting

Reflected Cross-site Scripting (XSS) occurs when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

2 Persistent Cross-Site Scripting

Persistent Cross-site Scripting (XSS) is the most dangerous type of Cross-Site Scripting. Web applications that allow users to store data are potentially exposed to this type of attack. This chapter illustrates examples of stored cross-site scripting injection and related exploitation scenarios.

This vulnerability can be used to conduct a number of browser-based attacks including:

  1. Hijacking another user's browser
  2. Capturing sensitive information viewed by application users
  3. Pseudo defacement of the application
  4. Port scanning of internal hosts ("internal" in relation to the users of the web application)
  5. Directed delivery of browser-based exploits Other malicious activities

3 DOM-based Cross-Site Scripting

DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. This document only discusses JavaScript bugs which lead to XSS.

Example:

In image src tag passing javascript function.

<IMG SRC="javascript:alert('XSS');">

For further more info. please refer this link: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

How we prevent the XSS attack?

In our Projects, we are using the angular framework. so, it will systematically block XSS bugs, Angular treats all values as untrusted by default. When a value is inserted into the DOM from a template, via property, attribute, style, class binding, or interpolation, Angular sanitizes and escapes untrusted values.

Sometimes applications genuinely need to include executable code, display an <iframe>

from some URL, or construct potentially dangerous URLs. To prevent automatic sanitization in any of these situations, you can tell Angular that you inspected a value, checked how it was generated, and made sure it will always be secure. But be careful. If you trust a value that might be malicious, you are introducing a security vulnerability to your application. If in doubt, find a professional security reviewer.

To mark a value as trusted, inject DomSanitizer and call one of the following methods:

  1. bypassSecurityTrustHtml
  2. bypassSecurityTrustScript
  3. bypassSecurityTrustStyle
  4. bypassSecurityTrustUrl
  5. bypassSecurityTrustResourceUrl

Example: 

constructor(private sanitizer: DomSanitizer) {
  // javascript: URLs are dangerous if attacker controlled.
  // Angular sanitizes them in data binding, but you can
  // explicitly tell Angular to trust this value:
  this.dangerousUrl = 'javascript:alert("Hi there")';
  this.trustedUrl = sanitizer.bypassSecurityTrustUrl(this.dangerousUrl);
}

Cross-Site Request Forgery (CSRF)

CSRF is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end-user data and operation when it targets a normal user. If the targeted end-user is the administrator account, a CSRF attack can compromise the entire web application.

CSRF relies on the following:

  1. Web browser behavior regarding the handling of session-related information such as cookies and Http authentication information.
  2. Knowledge by the attacker of valid web application URLs.
  3. Application session management relying only on information that is known by the browser.
  4. Existence of HTML tags whose presence causes immediate access to an http[s] resource; for example the image tag img.

Furthermore info please refer this link:

https://www.owasp.org/index.php/Cross-SiteRequest_Forgery%28CSRF%29

How to prevent CSRF?

Angular has built-in support to help prevent two common HTTP vulnerabilities, cross-site request forgery (CSRF or XSRF) and cross-site script inclusion (XSSI). Both of these must be mitigated primarily on the server-side, but Angular provides helpers to make integration on the client-side easier.

In a common anti-XSRF technique, the application server sends a randomly generated authentication token in a cookie. The client code reads the cookie and adds a custom request header with the token in all subsequent requests. The server compares the received cookie value to the request header value and rejects the request if the values are missing or don't match.

This technique is effective because all browsers implement the same-origin policy. Only code from the website on which cookies are set can read the cookies from that site and set custom headers on requests to that site. That means only your application can read this cookie token and set the custom header.

Example

Need to add xsrf module in app.module or your parent module

imports: [
  HttpClientModule,
  HttpClientXsrfModule.withOptions({
    cookieName: 'My-Xsrf-Cookie',
    headerName: 'My-Xsrf-Header',
  }),
],

further more info: https://angular.io/guide/http#security-xsrf-protection

ClickJacking

"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different from what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages

How to prevent clickjacking?

There are two ways to defend against Clickjacking at the browser level:

1) using the Content Security Policy frame-ancestors directive

The frame-ancestors directive can be used in a Content-Security-Policy HTTP response header to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>

Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites.

frame-ancestors allows a site to authorize multiple domains using the normal Content Security Policy semantics.

For more info please refer this link: https://w3c.github.io/webappsec-csp/

2) X-Frame-Options Response Headers (note this is being slowly deprecated in some browsers)

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>

Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites.

X-Frame-Options Header Types

There are three possible values for the X-Frame-Options header:

  • DENY, which prevents any domain from framing the content.

  • SAMEORIGIN, which only allows the current site to frame the content.

  • ALLOW-FROM Uri, which permits the specified 'Uri' to frame this page. (e.g., ALLOW-FROM http://www.example.com) Check Limitations Below this will fail open if the browser does not

Example headers.

    // Website you wish to allow to connect

    // res.setHeader('Access-Control-Allow-Origin', req.protocol +'://' + req.get('host'));

    // Request methods you wish to allow
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, OPTIONS, PATCH, DELETE');

    // Request headers you wish to allow
    res.setHeader('Access-Control-Allow-Headers', 'X-Requested-With,content-type,access_token');

    // Set to true if you need the website to include cookies in the requests sent
    // to the API (e.g. in case you use sessions)
    res.setHeader('Access-Control-Allow-Credentials', true);

    // Request headers you wish allow rendering a page in a <frame> <iframe> <embed> or <object>

    res.setHeader('X-Frame-Options', 'deny');

    // Request headers indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed
    res.setHeader('X-Content-Type-Options', 'nosniff');

    // HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.
    res.setHeader('Referrer-Policy', 'no-referrer-when-downgrade');

    // Http header for allowing feature of browser
    res.setHeader('Feature-Policy', "geolocation 'self';");

    // tops pages from loading when they detect reflected cross-site scripting (XSS) attacks
    res.setHeader('X-XSS-Protection', '1; mode=block');

    // content security policy not allowing unsafe inline
    res.setHeader('Content-Security-Policy', "default-src 'self'; style-src 'self' https://maxcdn.bootstrapcdn.com https://fonts.googleapis.com https://www.gstatic.com 'unsafe-inline'; img-src 'self' data: https://cdn.cidaas.de; font-src 'self' https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com; script-src 'unsafe-inline' 'self' https://cdnjs.cloudflare.com https://maxcdn.bootstrapcdn.com https://www.gstatic.com https://maps.googleapis.com;");

    // strict transport security
    res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains;');

Insecure URL Redirects

Insecure URL Redirection is an input validation flaw that exists when an application accepts a user-controlled input that specifies a link that leads to an external URL that could be malicious. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.

This vulnerability occurs when an application accepts untrusted input that contains a URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.

Prevention:

Angular has built-in support to help prevent two common HTTP vulnerabilities. Angular treats all values as untrusted by default. By manually we can do the same as well.

Safe use of redirects and forwards can be done in a number of ways:

  1. Do not allow the URL as user input for the destination. This can usually be done. In this case, you should have a method to validate the URL.
  2. If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
  3. It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL and that server-side code translate this value to the target URL.
  4. Sanitize input by creating a list of trusted URLs (lists of hosts or a regex).

Web application Security Guidelines URL: https://infosec.mozilla.org/guidelines/web_security



results matching ""

    No results matching ""