Cross-site scripting

Cross-site scripting

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007.[1] Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.

Contents

Background

Cross-site scripting holes are web-application vulnerabilities which allow attackers to bypass client-side security mechanisms normally imposed on web content by modern web browsers. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a special case of code injection.

The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including Java, ActiveX, VBScript, Flash, or even pure HTML, and SQL Queries), causing some confusion to newcomers to the field of information security.[2]

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter,[3] Facebook,[4] MySpace, and Orkut.[5][6] In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly-reported security vulnerability,[7] with some researchers viewing as many as 68% of websites as likely open to XSS attacks.[8]

Types

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent

Example of non-persistent XSS
Non-persistent XSS vulnerabilities in Google could allow malicious sites to attack Google users who visit them while logged in.[9]

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type.[10] These holes show up when the data 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 request.[11]

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.[10][11] A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.[12]

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

Persistent

Example of persistent XSS
A persistent cross-zone scripting vulnerability coupled with a computer worm allowed execution of arbitrary code and listing of filesystem contents via a QuickTime movie on MySpace.[13]

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.[11]

For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody's real name and email. These are kept secret on the server. The only time a member's real name and email are in the browser is when the member is signed in, and they can't see anyone else's.

Suppose that Mallory, a hacker, joins the site and wants to figure out the real names of the men she sees on the site. To do so, she writes a script that runs from men's browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal) but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won't be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory’s profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob’s real name and email directly from his own machine.

Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.[14]

The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, etc.) that can be controlled by an attacker could become an injection vector.

Traditional versus DOM-based vulnerabilities

Example of DOM-based XSS
Before the bug was resolved, Bugzilla error pages were open to DOM-based XSS attack in which arbitrary HTML and scripts could be injected using forced error messages.[15]

Traditionally, cross-site scripting vulnerabilities would occur in server-side code responsible for preparing the HTML response to be served to the user. With the advent of web 2.0 applications a new class of XSS flaws emerged, DOM-based vulnerabilities. DOM-based vulnerabilities occur in the content processing stages performed by the client, typically in client-side JavaScript. The name refers to the standard model for representing HTML or XML contents which is called the Document Object Model (DOM). JavaScript programs manipulate the state of a web page and populate it with dynamically-computed data primarily by acting upon the DOM.

A typical example is a piece of JavaScript accessing and extracting data from the URL via the location.* DOM, or receiving raw non-HTML data from the server via XMLHttpRequest, and then using this information to write dynamic HTML without proper escaping, entirely on client side.

Exploit scenarios

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the cast of characters commonly used in computer security.

Non-persistent:

  1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information.
  2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
  3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website (either directly or through an iframe or ajax), but will contain Mallory's malicious code, which the website will reflect.
  4. Alice visits the URL provided by Mallory while logged into Bob's website.
  5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc.) without Alice's knowledge.

Persistent attack:

  1. Mallory posts a message with malicious payload to a social network.
  2. When Bob reads the message, Mallory's XSS steals Bob's cookie.
  3. Mallory can now hijack Bob's session and impersonate Bob.[16]

Framework:

The Browser Exploitation Framework could be used to attack the web site and the user's local environment.

Mitigation

Contextual output encoding/escaping of string input

The primary defense mechanism to stop XSS is contextual output encoding/escaping. There are several different escaping schemes that must be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding.[17] 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.

It is worth noting that although it is widely recommended, simply performing HTML entity encoding on the five XML significant characters is not always sufficient to prevent many forms of XSS. Encoding can be tricky, and the use of a security encoding library is highly recommended.[17]

Safely validating untrusted HTML input

Many operators of particular web applications (e.g. forums and webmail) wish to allow users to utilize some of the features HTML provides, such as a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as &lt;b&gt;very&lt;/b&gt; large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "<b>very</b> large"). Stopping XSS when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML policy engine to ensure that it does not contain XSS. HTML sanitization tools such as OWASP AntiSamy [18] and http://htmlpurifier.org/ accomplish this task.

Cookie security

Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. 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.[19] To mitigate this particular threat (though not the XSS problem in general), 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.[20] This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker spoofs their IP address, is behind the same NATed IP address or web proxy—or simply opts to tamper with the site or steal data through the injected script, instead of attempting to hijack the cookie for future use.[20]

Another mitigation present in IE (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is a HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature does not fully prevent cookie theft nor can it prevent attacks within the browser.[21]

Disabling scripts

Finally, while Web 2.0 and Ajax designers favor the use of JavaScript,[22] some web applications are written to (sometimes optionally) operate completely without the need for client-side scripts.[23] This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.

Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. If scripting is allowed by default, then this approach is of limited value, since it blocks bad sites only after the user knows that they are bad, which is too late. 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. This has been possible for a long time in IE (since version 4) by setting up its so called "Security Zones",[24] and in Opera (since version 9) using its "Site Specific Preferences".[25] A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some anti-XSS protection even when scripts are enabled.[26]

The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded).[27] Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities.[28] The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed.[29]

Emerging defensive technologies

There are three classes of XSS defense that are emerging. These include, Mozilla's Content Security Policy,[30] Javascript Sandbox tools, and Auto-escaping templates. These mechanisms are still evolving but promise a future of heavily reduced XSS.

Scanning service

Some companies offer a periodic scan service, essentially simulating an attack from their server to a client's in order to check if the attack is successful. If the attack succeeds, the client receives detailed information on how it was performed and thus has a chance to fix the issues before the same attack is attempted by someone else. A trust seal can be displayed on the site that passes a recent scan. The scanner may not find all possible vulnerabilities,[31] and therefore sites with trust seals may still be vulnerable to new types of attack, but the scan may detect some problems. After the client fixes them, the site is more secure than it was before using the service. For sites that require complete mitigation of XSS, assessment techniques like manual code review are necessary. Additionally, if javascript is executing on the page, the seal can be overwritten with a static copy of the seal.

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.[32] 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).[33]

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.[34]

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.[35][36]

Notes

  1. ^ During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared ，to 2,134 "traditional" vulnerabilities documented by Symantec, in (PDF) Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary). XIII. Symantec Corp.. April 2008. pp. 1–3. http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf. Retrieved May 11, 2008. 
  2. ^ Grossman, Jeremiah (July 30, 2006). "The origins of Cross-Site Scripting (XSS)". http://jeremiahgrossman.blogspot.com/2006/07/origins-of-cross-site-scripting-xss.html. Retrieved September 15, 2008. 
  3. ^ Arthur, Charles (September 21, 2010). "Twitter users including Sarah Brown hit by malicious hacker attack". The Guardian. http://www.guardian.co.uk/technology/blog/2010/sep/21/twitter-bug-malicious-exploit-xss. Retrieved September 21, 2010. 
  4. ^ Leyden, John (May 23, 2008). "Facebook poked by XSS flaw". The Register. http://www.theregister.co.uk/2008/05/23/facebook_xss_flaw/. Retrieved May 28, 2008. 
  5. ^ "Full List of Incidents". Web Application Security Consortium. February 17, 2008. http://projects.webappsec.org/Web-Hacking-Incident-Database. Retrieved May 28, 2008. 
  6. ^ "Obama site hacked; Redirected to Hillary Clinton". ZDNet. April 21, 2008. http://www.zdnet.com/blog/security/obama-site-hacked-redirected-to-hillary-clinton/1042. Retrieved May 28, 2008. 
  7. ^ Christey, Steve and Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. http://cwe.mitre.org/documents/vuln-trends/index.html. Retrieved June 7, 2008. 
  8. ^ Berinato, Scott (January 1, 2007). "Software Vulnerability Disclosure: The Chilling Effect". CSO (CXO Media): p. 7. Archived from the original on 2008-04-18. http://web.archive.org/web/20080418072230/http://www.csoonline.com/article/221113. Retrieved June 7, 2008. 
  9. ^ Amit, Yair (December 21, 2005). "Google.com UTF-7 XSS Vulnerabilities". Watchfire. http://www.securiteam.com/securitynews/6Z00L0AEUE.html. Retrieved May 29, 2008. 
  10. ^ a b Hope, Paco; Walther, Ben (2008). Web Security Testing Cookbook. O'Reilly Media, Inc.. p. 128. ISBN 978-0-596-51483-9. 
  11. ^ a b c "Cross-site Scripting". Web Application Security Consortium. 2005. http://projects.webappsec.org/Cross-Site-Scripting. Retrieved May 28, 2008. 
  12. ^ Grossman, Jeremiah and Robert Hansen, Seth Fogie, Petko D. Petkov and Anton Rager (2007). XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract). Elsevier Science & Technology via Google Book Search. pp. 70, 156. ISBN 1597491543. http://books.google.com/?id=dPhqDe0WHZ8C. Retrieved May 28, 2008. 
  13. ^ This worm is named JS/Ofigel-A, JS/Quickspace.A and JS.Qspace, in "JS/Ofigel-A". Sophos. http://www.sophos.com/security/analyses/viruses-and-spyware/jsofigela.html. Retrieved June 5, 2008.  and "F-Secure Malware Information Pages: JS/Quickspace.A". F-Secure. January 5, 2007. http://www.f-secure.com/v-descs/js_quickspace_a.shtml. Retrieved June 5, 2008.  and "JS.Qspace". Symantec Corp.. February 13, 2007. http://www.symantec.com/security_response/writeup.jsp?docid=2006-120313-2523-99. Retrieved June 5, 2008. 
  14. ^ Viruses and worms in Alcorn, Wade (September 27, 2005). "The Cross-site Scripting Virus". BindShell.net. http://www.bindshell.net/papers/xssv. Retrieved May 27, 2008.  and Grossman, Jeremiah (April 2006). "Cross-Site Scripting Worms and Viruses: The Impending Threat and the Best Defense" (PDF). WhiteHat Security. p. 20. http://www.whitehatsec.com/downloads/WHXSSThreats.pdf. Retrieved June 6, 2008. [dead link]http://web.archive.org/web/*/http://www.whitehatsec.com/downloads/WHXSSThreats.pdf
  15. ^ "Bug 272620 – XSS vulnerability in internal error messages". Bugzilla@Mozilla. 2004. http://bugzilla.mozilla.org/show_bug.cgi?id=272620. Retrieved May 29, 2008. 
  16. ^ Brodkin, Jon (October 4, 2007). "The top 10 reasons Web sites get hacked". Network World (IDG). http://www.networkworld.com/news/2007/100407-web-site-vulnerabilities.html. Retrieved June 8, 2008. 
  17. ^ a b Williams,Jeff (January 19, 2009). "XSS (Cross SIte Scripting) Prevention Cheat Sheet". OWASP. http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet. Retrieved February 4, 2009. 
  18. ^ Dabirsiaghi,Arshan (November 3, 2010). "OWASP AntiSamy Project". OWASP. http://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project. Retrieved November 3, 2010. 
  19. ^ Sharma, Anand (February 3, 2004). "Prevent a cross-site scripting attack". IBM. http://www.ibm.com/developerworks/ibm/library/wa-secxss/. Retrieved May 29, 2008. 
  20. ^ a b "ModSecurity: Features: PDF Universal XSS Protection". Breach Security. http://www.modsecurity.org/projects/modsecurity/apache/feature_universal_pdf_xss.html. Retrieved June 6, 2008. 
  21. ^ "Ajax and Mashup Security". OpenAjax Alliance. http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.php. Retrieved June 9, 2008. 
  22. ^ O'Reilly, Tim (September 30, 2005). "What Is Web 2.0". O'Reilly Media. pp. 4–5. http://oreilly.com/web2/archive/what-is-web-20.html. Retrieved June 4, 2008. 
  23. ^ "A page should work, even if in a degraded form, without JavaScript." in Zammetti, Frank (April 16, 2007). Practical JavaScript, DOM Scripting and Ajax Projects via Amazon Reader. Apress. p. 36. ISBN 1590598164. http://www.amazon.com/gp/reader/1590598164/. Retrieved June 4, 2008. 
  24. ^ "How to use security zones in Internet ?Explorer". Microsoft. December 18, 2007. http://support.microsoft.com/kb/174360/en-us. Retrieved June 4, 2008. 
  25. ^ Håkon Wium Lie (February 7, 2006). "Opera 9 Technology Preview 2". Opera Software. http://labs.opera.com/news/2006/02/07-2/. Retrieved June 4, 2008. 
  26. ^ "NoScript". Mozilla. May 30, 2008. https://addons.mozilla.org/en-US/firefox/addon/722?id=722. Retrieved June 4, 2008.  and Mogull, Rich (March 18, 2008). "Should Mac Users Run Antivirus Software?". TidBITS (TidBITS Publishing). http://db.tidbits.com/article/9511. Retrieved June 4, 2008. 
  27. ^ ""Using client-side events" in DataWindow Programmer's Guide". Sybase. March 2003. http://www.elsevier.com/homepage/saa/trac/progmeth.htm. Retrieved June 4, 2008. 
  28. ^ 73% of sites relied on JavaScript in late 2006, in "'Most websites' failing disabled". BBC News. December 6, 2006. http://news.bbc.co.uk/2/hi/technology/6210068.stm. Retrieved June 4, 2008. 
  29. ^ "NoScript Features". http://noscript.net/features. Retrieved March 7, 2009. 
  30. ^ "Security/CSP/Specification". https://wiki.mozilla.org/Security/CSP/Specification. 
  31. ^ Sceptic blog
  32. ^ "Security hole in Internet Explorer allows attackers to execute arbitrary programs". Heise Media UK. May 16, 2008. http://www.h-online.com/security/news/item/Security-hole-in-Internet-Explorer-allows-attackers-to-execute-arbitrary-programs-735225.html. Retrieved June 7, 2008. 
  33. ^ "Update available for potential HTTP header injection vulnerabilities in Adobe Flash Player". Adobe Systems. November 14, 2006. http://www.adobe.com/support/security/bulletins/apsb06-18.html. Retrieved June 7, 2008. 
  34. ^ Auger, Robert (April 17, 2008). "The Cross-Site Request Forgery (CSRF/XSRF) FAQ (version 1.59)". Cgisecurity.com. http://www.cgisecurity.com/articles/csrf-faq.shtml. Retrieved June 7, 2008. 
  35. ^ "SQL Injection". Web Application Security Consortium. 2005. http://projects.webappsec.org/SQL-Injection. Retrieved June 7, 2008. 
  36. ^ "The Cross-Site Scripting FAQ". Cgisecurity.com. 2002. http://www.cgisecurity.com/xss-faq.html. Retrieved June 7, 2008. 

See also

Portal-puzzle.svg Software Testing portal

External links


Wikimedia Foundation. 2010.

Игры ⚽ Поможем написать реферат

Look at other dictionaries:

  • Cross-Site Scripting — (XSS) bezeichnet das Ausnutzen einer Computersicherheitslücke in Webanwendungen, indem Informationen aus einem Kontext, in dem sie nicht vertrauenswürdig sind, in einen anderen Kontext eingefügt werden, in dem sie als vertrauenswürdig eingestuft… …   Deutsch Wikipedia

  • Cross-Site-Scripting — (XSS; deutsch Seitenübergreifendes Scripting) bezeichnet das Ausnutzen einer Computersicherheitslücke in Webanwendungen, indem Informationen aus einem Kontext, in dem sie nicht vertrauenswürdig sind, in einen anderen Kontext eingefügt werden …   Deutsch Wikipedia

  • Cross Site Scripting — Le cross site scripting, abrégé XSS, est un type de faille de sécurité des sites Web, que l on trouve typiquement dans les applications Web qui peuvent être utilisées par un attaquant pour faire afficher des pages web contenant du code douteux.… …   Wikipédia en Français

  • Cross site scripting — Le cross site scripting, abrégé XSS, est un type de faille de sécurité des sites Web, que l on trouve typiquement dans les applications Web qui peuvent être utilisées par un attaquant pour faire afficher des pages web contenant du code douteux.… …   Wikipédia en Français

  • Cross-site scripting — Le cross site scripting, abrégé XSS, est un type de faille de sécurité des sites Web, que l on trouve typiquement dans les applications Web qui peuvent être utilisées par un attaquant pour provoquer un comportement du site Web différent de celui… …   Wikipédia en Français

  • Cross-site scripting — XSS, del inglés Cross site scripting es un tipo de inseguridad informática o agujero de seguridad basado en la explotación de vulnerabilidades del sistema de validación de HTML incrustado. Contenido 1 Introducción 2 XSS Indirecto (reflejado) 3 …   Wikipedia Español

  • cross site scripting — ● ►en loc. m. ►WEB►SECU Technique de détournement d informations consistant à insérer dans un site, un message ou un forum, un lien vers un second site (lien de préférence assez obscur, éventuellement codé en hexadécimal, ou contenant un bout de… …   Dictionnaire d'informatique francophone

  • Cross-zone scripting — is a browser exploit taking advantage of a vulnerability within a zone based security solution. The attack allows content (scripts) in unprivileged zones to be executed with the permissions of a privileged zone i.e. a privilege escalation within… …   Wikipedia

  • Cross-application scripting — (CAS) is a vulnerability affecting desktop applications that don t check input in an exhaustive way. CAS allows an attacker to insert data that modifies the behaviour of a particular desktop application. This makes it possible to extract data… …   Wikipedia

  • Cross-Zone Scripting — ist ein Browser Exploit für den Internet Explorer, der die Zonenaufteilung dieses Browsers ausnutzt. Der Angriff erlaubt Webseiten beliebigen Code innerhalb einer privilegierten Zone auszuführen. Ursachen ein Programmfehler des Browsers, der… …   Deutsch Wikipedia

Share the article and excerpts

Direct link
… Do a right-click on the link above
and select “Copy Link”