Vulnerability Note VU#652278

Microsoft Internet Explorer does not properly display URLs

Original Release date: 19 Dec 2003 | Last revised: 17 Feb 2004

Overview

Microsoft Internet Explorer does not properly display the location of HTML documents. An attacker could exploit this behavior to mislead users into revealing sensitive information.

Description

Web browsers frequently display the Uniform Resource Locator (URL) in the address bar. Users expect this information to indicate the source of the current browser frame. Microsoft Internet Explorer (IE) does not properly display URLs that contain certain non-printable characters. IE may connect to one address but display a different address.

Per RFC 2396, the URL scheme for HTTP is represented as

  <userinfo>@<host>:<port>

When IE encounters a NULL or similar non-printable character before the @ sign, the browser displays the <userinfo> data but accesses the correct location specified by the <host>:<port> portion of the URL. Code that displays the contents of the address bar and the status bar does not properly handle NULL and other non-printable characters. Both the address bar and the display bar show the truncated URL.

Even in the absence of this vulnerability, a class of social engineering attacks (also called "phishing") attempts to mislead a user into visiting a web site that appear to be legitimate but is in fact under the control of an attacker. The attacker might disguise the actual location of a URL by populating <userinfo> with credible data and obfuscating <host>:<port> with various URL representations, URL encoding, or other techniques. By making the web site appear to be legitimate, the attacker seeks to convince the user to provide sensitive information such as credit card numbers, account numbers, and passwords.

The vulnerability described in this document significantly adds to the attacker's ability to mislead users, since only <userinfo> is visible, not the actual location of the URL.

Outside the scope of this vulnerability, it is worth noting that RFC 2396 specifically recommends against including passwords in the <userinfo> portion of a URL:

    Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.

Impact

An attacker could convince a user that they were viewing a legitimate site when in fact they are visiting a site controlled by the attacker. The attacker could use additional social engineering techniques to trick the victim into disclosing sensitive information such as credit card numbers, account numbers, and passwords.

Solution

Apply patch
Apply the patch (832894) referenced in Microsoft Security Bulletin MS04-004 or a more recent IE cumulative patch.

Note that after applying the patch, the status bar continues to display the truncated URL.


Enter URLs manually

Do not click on URLs from untrusted sources such as unsolicited email or instant messages. Type URLs or use trusted bookmarks for sensitive sites.

For further information about safely determining URLs in IE, please see Microsoft Knowledge Base Article 833786. Also, Microsoft Knowledge Base Article 834489 discusses a change that causes IE to no longer support the "user:password" format for the <userinfo> portion of HTTP and HTTPS URLs.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Microsoft CorporationAffected09 Dec 200302 Feb 2004
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A

References

Credit

This vulnerability was publicly reported by Zap The Dingbat.

This document was written by Art Manion and Shawn Hernan.

Other Information

  • CVE IDs: CAN-2003-1025
  • Date Public: 09 Dec 2003
  • Date First Published: 19 Dec 2003
  • Date Last Updated: 17 Feb 2004
  • Severity Metric: 14.29
  • Document Revision: 65

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.