Download Cross Site Scripting OR XSS PowerPoint Presentation

Login   OR  Register

Share on Social Media


Home / Computers & Web / Computers & Web Presentations / Cross Site Scripting OR XSS PowerPoint Presentation

Cross Site Scripting OR XSS PowerPoint Presentation

Note : Cross Site Scripting OR XSS PPT Presentation is available for free download. Click on Download Free PowerPoint Presentation top red button for free download Cross Site Scripting OR XSS presentation in .ppt/pptx format.
ashif By : ashif

On : Jul 07, 2016

In : Computers & Web

Embed :

Login / Signup - with account for

  • → Make favorite
  • → Flag as inappropriate
  • → Download Presentation
  • → Share Presentation

Cross Site Scripting OR XSS
Presentation Transcript

  • Slide 1 - CROSS SITE SCRIPTING Moutasem Hamour Supervised By: Dr. Lo’ai Tawalbeh New York Institute of Technology (NYIT)-Amman
  • Slide 2 - Introduction Full explanation – the CSS technique Scope and feasibility -Variations on the theme Other ways to perform (traditional) CSS attacks What went wrong? Securing a site against CSS attacks How to check if your site is protected from CSS How Sanctum’s AppShield protects against CSS attacks How Sanctum’s AppScan scans for CSS vulnerabilities
  • Slide 3 - Introduction Cross Site Scripting (CSS for short, but sometimes abbreviated as XSS) is one of the most common application level attacks that hackers use to sneak into web applications today. Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site.
  • Slide 4 - Introduction (Cont....) The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can identify the client with the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site – specifically, impersonate the user.
  • Slide 5 - Introduction (Cont....) Example :- in one audit conducted for a large company it was possible to peek at the user’s credit card number and private information using a CSS attack. This was achieved by running malicious Javascript code at the victim (client) browser, with the “access privileges” of the web site. These are the very limited Javascript privileges which generally do not let the script access anything but site related information. It should be stressed that although the vulnerability exists at the web site, at no time is the web site directly harmed. Yet this is enough for the script to collect the cookies and send them to the attacker. The result, the attacker gains the cookies and impersonates the victim.
  • Slide 6 - Full explanation – the CSS technique I will consider the under attack site is www.vulnerable.com At the core of a traditional CSS attack lies a vulnerable script in the vulnerable site. This script reads part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it i.e. making sure it doesn’t contain Javascript code and/or HTML tags.
  • Slide 7 - Full explanation – the CSS technique(Cont...) This script is named welcome.cgi, and its parameter is “name”. It can be operated this way: GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host: www.vulnerable.site ... And the response would be: Welcome! Hi Joe Hacker
    Welcome to our system ...
  • Slide 8 - Full explanation – the CSS technique(Cont...) How can this be abused? Well, the attacker manages to lure the victim client into clicking a link the attacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the web browser of the victim to access the site (www.vulnerable.site) and invoke the vulnerable script. The data to the script consists of a Javascript that accesses the cookies the client browser has for www.vulnerable.site. It is allowed, since the client browser “experiences” the Javascript coming from www.vulnerable.site, and Javascript’s security model allows scripts arriving from a particular site to access cookies belonging to that site.
  • Slide 9 - Full explanation – the CSS technique(Cont...) Such a link looks like: http://www.vulnerable.site/welcome.cgi?name= The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows: GET/welcome.cgi?name= HTTP/1.0 Host: www.vulnerable.site And the vulnerable site response would be: Welcome! Hi
    Welcome to our system
  • Slide 10 - Full explanation – the CSS technique(Cont...) The victim client’s browser would interpret this response as an HTML page containing a piece of Javascript code. This code, when executed, is allowed to access all cookies belonging to www.vulnerable.site, and therefore, it will pop-up a window at the client browser showing all client cookies belonging to www.vulnerable.site. Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a web site (www.attacker.site), and use a script to receive the cookies. Instead of popping up a window, the attacker would write a code that accesses a URL at his/her own site (www.attacker.site), invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.site server.
  • Slide 11 - Full explanation – the CSS technique(Cont...) The malicious link would be: http://www.vulnerable.site/welcome.cgi?name= And the response page would look like: Welcome! Hi
    Welcome to our system ...
  • Slide 12 - Full explanation – the CSS technique(Cont...) The browser, immediately upon loading this page, would execute the embedded Javascript and would send a request to the collect.cgi script in www.attacker.site, with the value of the cookies of www.vulnerable.site that the browser already has. This compromises the cookies of www.vulnerable.site that the client has. It allows the attacker to impersonate the victim. The privacy of the client is completely breached. It should be noted, that causing the Javascript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to a CSS attack. If Javascript’s “alert” function can be called, there’s usually no reason for the “window.open” call not to succeed. That is why most examples for CSS attacks use the alert function, which makes it very easy to detect its success.
  • Slide 13 - ppt slide no 13 content not found
  • Slide 14 - Scope and feasibility The attack can take place only at the victim’s browser, the same one used to access the site (www.vulnerable.site). The attacker needs to force the client to access the malicious link. This can happen in several ways: - The attacker sends an email containing an HTML page that forces the browser to access the link. This requires the victim use the HTML enabled email client, and the HTML viewer at the client is the same browser used for accessing www.vulnerable.site. - The client visits a site, perhaps operated by the attacker, where a link to an image or otherwise active HTML forces the browser to access the link. Again, it is mandatory that the same browser be used for accessing this site and www.vulnerable.site.
  • Slide 15 - Scope and feasibility (Cont...) The malicious Javascript can access: - Permanent cookies (of www.vulnerable.site) maintained by the browser. - RAM cookies (of www.vulnerable.site) maintained by this instance of the browser, only when it is currently browsing www.vulnerable.site - Names of other windows opened for www.vulnerable.site Identification/authentication/authorization tokens are usually maintained as cookies. If these cookies are permanent, the victim is vulnerable to the attack even if he/she is not using the browser at the moment to access www.vulnerable.site. If, however, the cookies are temporary i.e. RAM cookies, then the client must be in session with www.vulnerable.site.
  • Slide 16 - Scope and feasibility (Cont...) Other possible implementations for an identification token is a URL parameter. In such cases, it is possible to access other windows using Javascript as follows (assuming the name of the page whose URL parameters are needed is “foobar”):
  • Slide 17 - Variations on the theme It is possible to use many HTML tags, beside , one can use (good for sites that filter the , it is possible to use ”> ...
  • Slide 19 - Other ways to perform (traditional) CSS attacks So far we’ve seen that a CSS attack can take place in a parameter of a GET request which is echoed back to the response by a script. But it is also possible to carry out the attack with POST request, or using the path component of the HTTP request, and even using some HTTP headers (such as the Referer). Particularly, the path component is useful when an error page returns the erroneous path. In this case, often including the malicious script in the path will execute it. Many web servers are found vulnerable to this attack.
  • Slide 20 - What went wrong? It should be understood that although the web site is not directly affected by this attack -it continues to function normally, malicious code is not executed on the site, no DoS condition occurs, and data is not directly manipulated/read from the site- it is still a flaw in the privacy the site offers its’ clients. Just like a site deploying an application with weak security tokens, wherein an attacker can guess the security token of a victim client and impersonate him/her, the same can be said here.
  • Slide 21 - What went wrong?(Cont...) The weak spot in the application is the script that echoes back its parameter, regardless of its value. A good script makes sure that the parameter is of a proper format, and contains reasonable characters, etc. There is usually no good reason for a valid parameter to include HTML tags or Javascript code, and these should be removed from the parameter prior to it being embedded in the response or prior to processing it in the application, to be on the safe side!
  • Slide 22 - Securing a site against CSS attacks It is possible to secure a site against a CSS attack in three ways: 1. By performing “in-house” input filtering (sometimes called “input sanitation”). For each user input be it a parameter or an HTTP header, in each script written in-house, advanced filtering against HTML tags including Javascript code should be applied. For example, the “welcome.cgi” script from the above case study should filter the “
  • Slide 25 - How to check if your site is protected from CSS (Cont....) to each parameter of each script, via a Javascript enabled browser to reveal a CSS vulnerability of the simplest kind – the browser will pop up the Javascript alert window if the text is interpreted as Javascript code. Of course, there are several variants, and therefore, testing only the above variant is insufficient. And as we saw above, it is possible to inject Javascript into various fields of the request – the parameters, the HTTP headers, and the path. In some cases (notably the HTTP Referer header), it is awkward to carry out the attack using a browser.
  • Slide 26 - How Sanctum’s AppShield protects against CSS attacks AppShield, Sanctum’s Web application firewall, is a secure proxy positioned in front of the web server, and protecting it, and all the code and data sitting behind it, from attack. AppShield inspects all incoming requests. Therefore, any CSS attack attempt will send the request (to welcome.cgi in the example) to AppShield, instead of directly to the web server. AppShield inspects the parameters of the request before forwarding it to the server. AppShield’s patented Dynamic Policy Recognition technology incorporates sophisticated pattern matching which blocks input potentially used for CSS attacks. For example, the patterns cover the following strings as referred to in this paper:
  • Slide 27 - How Sanctum’s AppShield protects against CSS attacks(Cont...) In the example, there is a parameter whose value contains the string Upon spotting this illegal pattern, AppShield blocks the request and logs the attack attempt.
  • Slide 28 - How Sanctum’s AppScan scans for CSS vulnerabilities to mutate all "reasonable" parameters into various CSS attack variants. For example, it may try to inject the string into all parameters of all scripts. AppScan's uniquely comprehensive assembly of CSS attacks enables it to penetrate some applications that are resistant to simple CSS attacks. For each script it tries to attack, AppScan will inspect the results (the script response), and if the Javascript code is detected (that is, if the string returned as is - intact and in fullness: ), it indicates that the attack succeeded (because the browser of the victim will execute the JS code). Moreover, the internal browser in AppScan will pop-up the Javascript alert window with the text "CSS is possible", which graphically demonstrates that the Javascript code was indeed executed.
  • Slide 29 - Conclusion Cross Site Scripting is one of the most common application level attacks that hackers use to sneak into web applications today, and one of the most dangerous. It is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unfortunately, this is often done without the knowledge of either the client or the organization being attacked. In order to prevent this malicious vulnerability, it is critical that an organization implement both an online and offline security strategy. This includes using an automated application vulnerability assessment tool, like AppScan from Sanctum, which can test for all the common web vulnerabilities, and application specific vulnerabilities (like cross site scripting) on a site. And for a full online defense, installing an application firewall, like AppShield from Sanctum, that can detect and defend against any type of manipulation to the code and content sitting on and behind the web servers.
  • Slide 30 - THANK YOU

Description : Cross-Site Scripting (XSS) attacks are a type of injection through malicious scripts. Cross-Site Scripting comes under hacking ticks.

Tags : cross site scripting | XSS | CSS | hacking | hacking tips | computer security | hacking technology | illegal technology | tech