This attack targets applications that use parameters to indicate redirects. For example, here is a potentially vulnerable URL:
http://website/redirect.cgi?page=http://website/welcome.cgi
A good input validation routine would ensure that the value for the page parameter consists of a valid URL. Yet if arbitrary characters can be included, then the parameter might be rewritten with something like this:
http://website/redirect.cgi?page =0d%0aContent-Type:%20text/
html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/
html%0d%0a%0d%0a%3chtml%3eHello, world!%3c/html%3e
html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/
html%0d%0a%0d%0a%3chtml%3eHello, world!%3c/html%3e
The original value of page has been replaced with a series of characters that mimics the HTTP response headers from a web server and includes a simple HTML string for “Hello, world!” The malicious payload is more easily understood by replacing the encoded characters:
Content-Type: text/html
HTTP/1.1 200 OK
Content-Type: text/html
<html>Hello, world!</html>
HTTP/1.1 200 OK
Content-Type: text/html
<html>Hello, world!</html>
The end result is that the web browser displays this faked HTML content rather than the HTML content intended for the redirect. The example appears innocuous, but a malicious attack could include JavaScript or content that appears to be a request for the user’s password, Social Security number, credit card information, or other sensitive information.
The point of this example is not how to create an effective phishing attack, but to demonstrate how a parameter’s content can be manipulated to produce unintended effects.
No comments:
Post a Comment