Cross-site Scripting (XSS

)
When the Spider invited the Fly into his living-room, the Fly at first declined with the wariness of prey confronting its predator. The Internet is common with traps, muddy corners, and nasty hosts that make nonchalantly surfing random Web sites a dangerous proposition. Some areas are, if not obviously dangerous, at least highly doubtful. Web sites offering free porn, pirated software, or pirated music tend to be laden with viruses and spiteful software waiting for the next insecure browser to visit. These Spiders living rooms also exist at sites typically assumed to be safe: online well-established shopping, social networking, news, sports, web-based e-mail, entertainment, and more. Somehow such sites do not encourage visitors to download and execute virus loaded programs; they give out content to the browser. The browser executes this content without knowing it, a mix of JavaScript and Hypertext Markup Language (HTML) to perform all sorts of actions. If you¶re with fortunate, the browser shows the next message in your inbox or displays the current balance of your bank account. If you are really lucky, the browser isn¶t siphoning your password to a server in some other country or executing money transfers in the background. On October four, Two thousand five, a bunched of user logged in to MySpace and checked out someone else¶s profile. The web browser, executing JavaScript code it encountered on the page, automatically updated the user¶s own profile to declare someone named "Samy" their hero. Then a friend viewed that user¶s profile and agreed on his own profile that "Samy " was indeed ³my hero.´ Then another friend, who had neither heard of nor met with "Samy", visited MySpace and added the same statement. This pattern continued with such exponential growth, with in twenty four hours, "Samy" had over one million friends, and MySpace was shutdown from the traffic. "Samy" had crafted a cross-site scripting (XSS) attack that, with approximately four thousand characters of text, caused a disaffirmation of service against a company whose servers numbered in the thousands and who¶s rating at that time around five hundred million. The attack also sainted "Samy Worm" as the reference point for the mass cause of XSS. For reader I want to mention that an interview with the inventor of "Samy" can be found at ((((( All kind of academic projects are available . You can get
mba,bba projects or mba assignments, bba assignments , international relations ,biology projects under dead line. contact Jahanzeb Khan 00923004604250 sparklessoft@gmail.com www.sparklessoft.com

))))))))

. Samy, the author of the worm, was on a project to become famous. But consider what he might have done with control of over one million web browsers and the gigabits of bandwidth at their disposition browsers that were also potentially logged-in to Yahoo, Google, MSN, web banks, eBay, stock brokerages, blogs, e-NEWS, or any other webbased applications. It¶s critical that we begin to recognize the magnitude of the risk associated with XSS malware and the ways that companies can protect themselves and their users. Especially when the spyware originates from trusted websites and belligerent authors. In this report we will provide an overview of XSS; define XSS worms; and examine spread methods, virus rates, possible impact, and related threats.

Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's web browser case. A web browser instance can be a standard web browser client, or a web browser object embedded in a software product such as the web browser within an RSS reader, WinAmp, or an email client. The code itself is usually written in JavaScript/HTML, but may also extend to VBScript, ActiveX, Java, Flash, or any other web browser-supported technology. XSS can be more generally described as JavaScript/HTML injection. An XSS attack rewrites the structure of a web page or executes illegal JavaScript within the web browser. This only happen to when a web site takes some information from the user for example; a user ID, an e-mail address, a zip code, a comment to a blog post, and by many other ways« and displays the information in a web page. If the web site is not cautious, then the meaning of the HTML document can be disrupted by a harmful string. When an attacker gets a user's web browser to execute his/her code, the code will run within the security zone of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked, their browser redirected to another location, or possibly shown fake content delivered by the web site they are visiting. Cross-site Scripting attacks basically compromise the trust relationship between a user and the web site. There are four basic types of XSS attacks: stored, reflected, DOM-based and induced. The first type ³stored XSS´ works if an HTML page includes data stored on the web server e.g. from a database that originally comes from user input. All an invader has to do is find a weak server and post an attack. From that moment on, the server will allocate the exploit automatically to all users requesting the vulnerable page. The second type ³reflected XSS´ works because some part of an HTTP request usually a URL parameter, the referrer location or cookie is reflected by the web server into the JavaScript/HTML content that is returned to the requesting browser. Here reflected means, which input is written back unaltered. In this case, a hacker

would have to craft a spite URL and make someone else follow or open that link. This can be done by sending someone a manipulated e-mail with the link and use phishing scams to make the user believe that clicking on the link is a wonderful idea. An alternative approach would be to post such a link somewhere on the Internet, e.g. in a forum, and wait for someone to follow it. The third type (DOM-based XSS) is very similar to the second type. A key difference is that the attack code is not embedded into the HTML content back sent by the server. Therefore all server-side XSS detection mechanisms fail. Instead, it is embedded in the URL of the requested page and ran in the user's web browser by defective script code, contained in the HTML content returned by the server. Defective/Faulty means that the script reads a URL parameter and dynamically adds it to the text object model without any validation form user. This way, spite tags are added to the DOM locally at runtime and are later executed. The fourth type of XSS works if the Web server has a so-called HTTP Response Splitting vulnerability. Through this vulnerability a hacker can change the entire HTML content by manipulating the HTTP header of the server's response. This is done by finding an invalidated request that is echoed by the HTTP response header. A very exciting aspect of DOM-based as well as induced XSS vulnerabilities is that they can also have an effect on static hyper text markup languages pages. Naturally, you always have a Cross Site Scripting risk, if you allow people to send HTML content to your PC, e.g. in the form of attachments to an online application. No matter which type of XSS affects a web application, they are all equally dangerous. In such a case, the form can be submitted without human intervention. Upon clicking on the spiteful link or submitting the spiteful form, the XSS warhead will get echoed back and will get rendered by the user's web browser and execute. Another technique to send virtually arbitrary requests are by using an embedded client, such as Plug-In or Adobe Flash. Constant attacks occur when the spite code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web chat software, and web mail messages. Where will a XSS be executed? XSS exploits are executed in a browser. More technically, unlike most other exploits, XSS exploits run on every operating system, including mobile devices. A second important issue is, that the user that opens a susceptible page, is not necessarily on the same side of the firewall as the attacker. For a brief description let us consider this example, if an attacker sends an online application to a company for a job, the HR manager of the company will read this application from the intranet, possibly with a web browser. When that happens, the attack will be launched on a network. It is important to note that the local intranet zone has usually less restrictive security settings than the global internet zone. Now at the end of the report I want to talk about the similar threats of XSS. We can divide similar types of threats of XSS into two main categories. Cross-Site Request Forgery (CSRF) and Cross Site History manipulation (XSHM)

Cross-Site Request Forgery (CSRF): CSRF is an attack which insists an end user to execute unwanted actions on a web application in which he/she is currently authenticated. By using social engineering (like sending a link via email/chat), an aggressor may force the users of a web application to run actions of the attacker's choosing on his computer. A successful CSRF exploit can compromise end user data and operation in case of normal user. A more big misshape can happen, If the targeted end user is the administrator account, this can compromise the entire web application. Cross Site History manipulation (XSHM): Cross-Site History Manipulation (XSHM) is a SOP (Same Origin Policy) security breach. SOP is the most important security concept of today¶s web browsers. SOP means that web pages from different origins by design cannot communicate with each other. Cross-Site History Manipulation breach is based on the fact that client-side web browser history object is not accurately partitioned on a per-site basis. Dealing with the web browser history may lead to SOP compromising, allow bi-directional CSRF and other exploitations such as: login status detection, sensitive information violation, client privacy violation, resources coping, user¶s action tracking and URL parameter stealing.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.