Date: Thu, 28 Mar 2024 18:37:21 -0400 (EDT) Message-ID: <2092557645.517.1711665441475@windcrest.sei.cmu.edu> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_516_620472034.1711665441472" ------=_Part_516_620472034.1711665441472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Original release date: February 2, 2000
Last revised: February 3, 2000
A complete revision history is at the end of this file.
A web site may inadvertently include malicious HTML tags or script in a = dynamically generated page based on unvalidated input from untrustworthy so= urces. This can be a problem when a web server does not adequately ensure t= hat generated pages are properly encoded to prevent unintended execution of= scripts, and when input is not validated to prevent malicious HTML from be= ing presented to the user.
Most web browsers have the capability to interpret scripts embedded in w= eb pages downloaded from a web server. Such scripts may be written in a var= iety of scripting languages and are run by the client's browser. Most brows= ers are installed with the capability to run scripts enabled by default.
Sites that host discussion groups with web interfaces have long guarded = against a vulnerability where one client embeds malicious HTML tags in a me= ssage intended for another client. For example, an attacker might post a me= ssage like
When a victim with scripts enabled in their browser reads this message, = the malicious code may be executed unexpectedly. Scripting tags that can be= embedded in this way include <SCRIPT>, <OBJECT>, <APPLET>= ;, and <EMBED>.
When client-to-client communications are mediated by a server, site deve= lopers explicitly recognize that data input is untrustworthy when it is pre= sented to other users. Most discussion group servers either will not accept= such input or will encode/filter it before sending anything to other reade= rs.
Many Internet web sites overlook the possibility that a client may send = malicious data intended to be used only by itself. This is an easy mistake = to make. After all, why would a user enter malicious code that only the use= r will see?
However, this situation may occur when the client relies on an untrustwo= rthy source of information when submitting a request. For example, an attac= ker may construct a malicious link such as
When an unsuspecting user clicks on this link, the URL sent to exampl= e.com includes the malicious code. If the web server sends a page back = to the user including the value of mycomment, the malicious code may= be executed unexpectedly on the client. This example also applies to un= trusted links followed in email or newsgroup messages.
In addition to scripting tags, other HTML tags such as the <FORM> = tag have the potential to be abused by an attacker. For example, by embeddi= ng malicious <FORM> tags at the right place, an intruder can trick us= ers into revealing sensitive information by modifying the behavior of an ex= isting form. Other HTML tags can also be abused to alter the appearance of = the page, insert unwanted or offensive images or sounds, or otherwise inter= fere with the intended appearance and behavior of the page.
At the heart of this vulnerability is the violation of trust that result= s from the "injected" script or HTML running within the security context es= tablished for the example.com site. It is, presumably, a site the br= owser victim is interested in enough to visit and interact with in a truste= d fashion. In addition, the security policy of the legitimate server site <= i>example.com may also be compromised.
This example explicitly shows the involvement of two sites:
Note the SRC attribute in the <SCRIPT> tag is explicitly incorpora= ting code from a presumably unauthorized source (bad-site). Both of = the previous examples show violations of the same-source origination policy= fundamental to most scripting security models:
Because one source is injecting code into pages sent by another source, = this vulnerability has also been described as "cross-site" scripting.
At the time of publication, malicious exploitation of this vulnerability= has not been reported to the CERT/CC. However, because of the potential fo= r such exploitation, we recommend that organization CIOs, managers, and sys= tem administrators aggressively implement the steps listed in the solution section of this document. Technical feedback to= appropriate technical, operational, and law enforcement authorities is enc= ouraged.
Users may unintentionally execute scripts written by an attacker when th= ey follow untrusted links in web pages, mail messages, or newsgroup posting= s. Users may also unknowingly execute malicious scripts when viewing dynami= cally generated pages based on content provided by other users.
Because the malicious scripts are executed in a context that appears to = have originated from the targeted site, the attacker has full access to the= document retrieved (depending on the technology chosen by the attacker), a= nd may send data contained in the page back to their site. For example, a m= alicious script can read fields in a form provided by the real server, then= send this data to the attacker.
Note that the access that an intruder has to the Document Object Model (= DOM) is dependent on the security architecture of the language chosen by th= e attacker. Specifically, Java applets do not provide the attacker with any= access to the DOM.
Alternatively, the attacker may be able to embed script code that has ad= ditional interactions with the legitimate web server without alerting the v= ictim. For example, the attacker could develop an exploit that posted data = to a different page on the legitimate web server.
Also, even if the victim's web browser does not support scripting, an at= tacker can alter the appearance of a page, modify its behavior, or otherwis= e interfere with normal operation.
The specific impact can vary greatly depending on the language selected = by the attacker and the configuration of any authentic pages involved in th= e attack. Some examples that may not be immediately obvious are included he= re.
The malicious script tags are introduced before the Secure Socket Layer = (SSL) encrypted connection is established between the client and the legiti= mate server. SSL encrypts data sent over this connection, including the mal= icious code, which is passed in both directions. While ensuring that the cl= ient and server are communicating without snooping, SSL makes no attempt to= validate the legitimacy of data transmitted.
Because there really is a legitimate dialog between the client and the s= erver, SSL reports no problems. Malicious code that attempts to connect to = a non-SSL URL may generate warning messages about the insecure connection, = but the attacker can circumvent this warning simply by running an SSL-capab= le web server.
Once malicious code is executing that appears to have come from the auth= entic web site, cookies may be modified to make the attack persistent. Spec= ifically, if the vulnerable web site uses a field from the cookie in the dy= namic generation of pages, the cookie may be modified by the attacker to in= clude malicious code. Future visits to the affected web site (even from tru= sted links) will be compromised when the site requests the cookie and displ= ays a page based on the field containing the code.
By constructing a malicious URL an attacker may be able to execute scrip= t code on the client machine that exposes data from a vulnerable server ins= ide the client's intranet.
The attacker may gain unauthorized web access to an intranet web server = if the compromised client has cached authentication for the targeted server= . There is no requirement for the attacker to masquerade as any particular = system. An attacker only needs to identify a vulnerable intranet server and= convince the user to visit an innocent looking page to expose potentially = sensitive data on the intranet server.
If your browser is configured to allow execution of scripting languages = from some hosts or domains while preventing this access from others, attack= ers may be able to violate this policy.
By embedding malicious script tags in a request sent to a server that is= allowed to execute scripts, an attacker may gain this privilege as well. F= or example, Internet Explorer security "zones" can be subverted by this tec= hnique.
Browsers interpret the information they receive according to the charact= er set chosen by the user if no character set is specified in the page retu= rned by the web server. However, many web sites fail to explicitly specify = the character set (even if they encode or filter characters with special me= aning in the ISO-8859-1), leaving users of alternate character sets at risk= .
Under some conditions, an attacker may be able to modify the behavior of= forms, including how results are submitted.
None of the solutions that web users can take are complete solutions. In= the end, it is up to web page developers to modify their pages to eliminat= e these types of problems.
However, web users have two basic options to reduce their risk of being = attacked through this vulnerability. The first, disabling scripting languag= es in their browser, provides the most protection but has the side effect f= or many users of disabling functionality that is important to them. Users s= hould select this option when they require the lowest possible level of ris= k.
The second solution, being selective about how they initially visit a we= b site, will significantly reduce a user's exposure while still maintaining= functionality. Users should understand that they are accepting more risk w= hen they select this option, but are doing so in order to preserve function= ality that is important to them.
Unfortunately, it is not possible to quantify the risk difference betwee= n these two options. Users who decide to continue operating their browsers = with scripting languages enabled should periodically revisit the CERT/CC we= b site for updates, as well as review other sources of security information= to learn of any increases in threat or risk related to this vulnerability.=
Exploiting this vulnerability to execute code requires that some form of= embedded scripting language be enabled in the victim's browser. The most s= ignificant impact of this vulnerability can be avoided by disabling all scr= ipting languages.
Note that attackers may still be able to influence the appearance of con= tent provided by the legitimate site by embedding other HTML tags in the UR= L. Malicious use of the <FORM> tag in particular is not prevented by = disabling scripting languages.
Detailed instructions to disable scripting languages in your browser are= available from our Malicious Code FAQ:
Some users are unable or unwilling to disable scripting languages comple= tely. While disabling these scripting capabilities is the most effective so= lution, there are some techniques that can be used to reduce a user's expos= ure to this vulnerability.
Since the most significant variations of this vulnerability involve cros= s-site scripting (the insertion of tags into another site's web page), user= s can gain some protection by being selective about how they initially visi= t a web site. Typing addresses directly into the browser (or using securely= stored local bookmarks) is likely to be the safest way of connecting to a = site.
Users should be aware that even links to unimportant sites may expose ot= her local systems on the network if the client's system resides behind a fi= rewall, or if the client has cached credentials to access other web servers= (e.g., for an intranet). For this reason, cautious web browsing is not<= /b> a comparable substitute for disabling scripting.
With scripting enabled, visual inspection of links does not protect user= s from following malicious links, since the attacker's web site may use a s= cript to misrepresent the links in the user's window. For example, the cont= ents of the Goto and Status bars in Netscape are controllable by JavaScript= .
Web site administrators and developers can prevent their sites from bein= g abused in conjunction with this vulnerability by ensuring that dynamicall= y generated pages do not contain undesired tags.
Attempting to remove dangerous meta-characters from the input stream lea= ves a number of risks unaddressed. We encourage developers to restrict vari= ables used in the construction of pages to those characters that are explic= itly allowed and to check those variables during the generation of the outp= ut page.
In addition, web pages should explicitly set a character set to an appro= priate value in all dynamically generated pages.
Because encoding and filtering data is such an important step in respond= ing to this vulnerability, and because it is a complicated issue, the CERT/= CC has written a document which explores this issue in more detail:
Some web server products include dynamically generated pages in the defa= ult installation. Even if your site does not include dynamic pages develope= d locally, your web server may still be vulnerable. For example, your serve= r may include malicious tags in the "404 Not Found" page generated by your = web server.
Web server administrators are encouraged to apply patches as suggested b= y your vendor to address this problem. Appendix A = contains information provided by vendors for this advisory. We will update = the appendix as we receive more information. If you do not see your vendor'= s name, the CERT/CC did not hear from that vendor. Please contact your vend= or directly.
More information from apache can be found at
Please see recommendations for Java Web Server at:
Sun is also providing information on security issues in general. = ; This information is posted at=20 A good introduction is in http:/= /java.sun.com/sfaqWhile any web-based object, including Java Applets, can be unintentional= ly loaded through the mechanisms described in this advisory, once they are = loaded the Java security mechanisms prevent any harmful information from be= ing disclosed or client information from being damaged.
Our thanks to Marc Slemko, Apache Software Foundation member; Iris Assoc= iates; iPlanet; the Microsoft Security Response Center, the Microsoft Inter= net Explorer Security Team, and Microsoft Research.
Copyright 2000 Carnegie Mellon University.