Archive for May, 2006

Are “bug bounties” cost effective?


Recently Microsoft, Mozilla, and VeriSign have offered “bug bounties” to help squash critical defects before release. Brilliant I say! Using money to motivate testers during development is a win-win situation. Testers win since they can get some serious cash if they put their nose to the grind-stone and the software/company wins because:

  • Defects that are found and fixed early are cheaper than post-release defects (post-release cost can be 100 times development cost, e.g $50 vs $5000).
  • There will be less embarrassing critical and security defects found at post-release.
  • Quality Assurance (ad-hoc) is marketed, which screams “We care about quality”.
  • The company only pays for severe defects but will still get a valuable set of less severe defects for free.

Are there hidden costs though? I can think of a few:

  • The time and effort wading through crappy and duplicate defect reports.
  • Larger scale efforts to manage the plethora of testers and defects.

The benefits obviously out-weigh the hidden costs. What other positive and negatives can you think of? Talk to me fellow engineers!

Microsoft Virtual PC 2004 documentation


Today I sat down and started to configure my new test environments which are hosted on Microsoft Virtual PCs. I wanted to refresh myself on some of the advanced features and hit Google, Microsoft and MSDN in search of the VPC user documentation that I had found about a year ago and then proceeded to lose. Long story short, don’t go looking on the Web for the official user manual for Microsoft Virtual PC 2004, it’s under your nose. A MS kb article reminded me of the painful unobvious that I learned once before:

“In a default installation of Microsoft Virtual PC 2004, the documentation that is included with Virtual PC is located in the following folder on the hard disk of the host PC: Drive:\Program Files\Microsoft Virtual PC\Documentation”

Painfully unobvious because there are no shortcuts from Start menu to this documentation (which is where I started my search).

In my quest for documenation I ran into the following useful MS VPC 2004 links too:

The Official Microsoft Virtual PC 2004 site is here.

A MSDN VPC Blog is here.

VPC Overview Presentations are here.

The Code Room: Breaking Into Vegas


A while back MSDN TV posted a great video titled “The Code Room: Breaking Into Vegas“. If you have an extra half hour it’s a cool, informational watch about security and hacking with some real world scenarios and examples. The acting is pathetic and cheesy but the actors are real life experts and geeks so I guess that’s expected! Here is a summary from the site:

“In this episode of The Code Room watch the White Hats and Black Hats battle for the security of Las Vegas. Jessi Knapp and Microsoft Security Guru Joe Stagner narrate as the Hackers try to gain control of The Plaza’s online money management system and our Security Team tries to stay one step ahead.”

Test cookie poisoning


Web site cookie poisoning came up twice in the last week while testing so I guess now is great time to talk about how to test the for the vulnerability of cookie poisoning. I’m not going to get into the details of how a cookie works but rather how to poison them. If you want details of how they work from a testing point of view read this respectable paper.

Web sites use cookies (a lot of them), cookies can be permanent (on disk) or temporary (in memory), and cookies contain variables; variables that the site cares about, and can be messed with or “poisoned” to get results that the Web site didn’t intend to give you. Use the following test page as an example, The test pages are simple, if you have the right cookie content then you will receive a 50% discount; if the content isn’t right then you will not receive the 50% discount. The first page sets the cookie with the content of “SpecialOffer=No” indicating that you are not eligible by default. The cookie setting code on this page is simple and looks like this:

document.cookie = “SpecialOffer=No”;

Now, if you click the link “Click here to see if you are eligible for 50% discount” you’ll see that you are not eligible for the discount. The check on the 2nd page is pretty simple too and looks like this:

var pos = document.cookie.indexOf( “SpecialOffer=Yes” );
if( pos == -1 ) {
document.write(“I’m sorry you are NOT eligible for the 50% discount”);
else {
document.write(“You are eligible for the 50% discount”);

In the above script I look for the value of “SpecialOffer=Yes” in the cookie content and then react accordingly. If I don’t see “SpecialOffer=Yes” then you aren’t eligible for the discount. Now, on to the fun stuff! How do you make yourself eligible for the discount? To do this we need to change the default cookie content value from “SpecialOffer=No” to “SpecialOffer=Yes”. How does one change cookie values? There are quite a few ways but I’ll share with you my 3 favorites:

  1. Add N Edit Cookies FireFox extension
  2. Paros Proxy
  3. Paste the following JavaScript in the URL bar to view the cookies:

    and the following to modify it:

    javascript:alert(window.c=function a(n,v,nv) {c=document.cookie;c=c.substring(c.indexOf(n) +n.length,c.length);c=c.substring(1,((c.indexOf(“;”)>-1) ?   c.indexOf(“;”) : c.length));nc=unescape(c).replace  (v,nv);document.cookie=n+”=”+escape(nc);return unescape  (document.cookie);});alert(c(prompt(“cookie name:”,””), prompt(“replace this value:”,””),prompt(“with::”,””)));

How to poison cookies with Add N Edit Cookies

  1. Navigate to in FireFox
  2. Click the cookie icon in your FireFox toolbar
  3. Find the cookie for and double click it or highlight it and press the edit button
  4. Change the content form field from “No” to “Yes” (case sensitive)
  5. Go back to the browser and click the link “Click here to see if you are eligible for 50% discount”
  6. KaaaaPOW…. You now have the 50% discount! You’re a freakin’ evil, bad to the bone tester!

How to poison cookies with Paros Proxy
Typically I wouldn’t use Paros in this situation because the cookie is being set on the client side (you won’t see this too much in the real world). The following example isn’t what I consider cookie poisoning but more JavaScript manipulation. The following assumes you have cleared your cache:

  1. Turn on Paros and set you IE connection options to use the address of with a port of 8080
  2. In Paros click the “Trap” tab and check the “Trap Request” and “Trap Response” checkboxes
  3. Navigate to in IE
  4. Go back to Paros (Trap tab) and press the “continue” button until you see the following text in the bottom pane:
    document.cookie = “SpecialOffer=No”;

  5. Change the “No” to “Yes” in the above line
  6. Click the “Continue” button.
  7. Go back to IE and click the link “Click here to see if you are eligible for 50% discount”
  8. Whoot! You now have the 50% discount! You’re one sexy cool tester with a severity 1 defect that needs to be submitted.

    There are situations where you will want to change the cookie value in the header (the top pane in the trap tab) on the response or the request, this is when you would use Paros over Add n Edit Cookies. Situations where you would need to manipulate the cookie before the response is rendered or before the request is sent due to the server or client side code manipulating the cookie.

How to poison cookies with JavaScript

  1. Navigate to in IE
  2. To view the set cookie, type the following in the URL bar:
  3. You will see “SpecialOffer=No”. Click Ok
  4. Copy and paste the following JavaScript in the browser URL bar:
    javascript:alert(window.c=function a(n,v,nv) {c=document.cookie;c=c.substring(c.indexOf(n) +n.length,c.length);c= c.substring(1,((c.indexOf(“;”)>-1) ?  c.indexOf(“;”) : c.length)); nc=unescape(c).replace(v,nv); document.cookie= n+”=”+escape(nc);return unescape(document.cookie);}); alert(c(prompt(“cookie name:”,””), prompt(“replace this value:”,””), prompt(“with::”,””)));
  5. Hit the enter key
  6. Click the Ok button at the JavaScript Alert
  7. Type the cookie name of SpecialOffer in the Alert box and click the Ok button
  8. At the “replace this value” script prompt type No and press the Ok button
  9. At the “with:” script prompt type Yes (case sensitive) and press the Ok button
  10. The next alert will show you the replaced cookie. You should see: SpecialOffer=Yes
  11. Click the Ok button
  12. In IE click the link “Click here to see if you are eligible for 50% discount”
  13. DingDingDingDing…. You’re a winner! You now have the 50% discount! You’re quite the bad-ass tester aren’t you? You’re like the wicked witch in Snow White but instead of poisoning apples you poison cookies.

And that’s how I conduct cookie poisoning when testing. Not too awful tough eh? Oh…if I ever get confused about the state of cookies before and after poisoning I use HTTPWatch to get a better idea of what is going on. I can usually get the gist of it by looking through the cookie and header tabs.

When do you test for the cookie poisoning vulnerability you ask? Whenever there is a cookie being used! Is it a defect if you can manipulate the cookie? Not necessarily. They typically are defects when a cookie is being placed that impacts or restricts the site’s behavior and you can exploit that feature. If you manipulate a cookie and it doesn’t gain you anything or exploit a feature then it’s not of much value, thus not a defect. But…it’s important that you know what the cookie you are poisoning does, without knowing what the cookie does you may be poisoning something and may not be seeing that exploit. To prevent guess-work it’s easiest if you work with your developer to understand what he/she is doing with cookies on the site so you can go straight for the kill.

Happy poisoning!

The credit card system is a joke


The credit card system is a joke. Yeah, I know you know. I just wanted to remind you with my latest mockery of the system.

So, I receive a new MBNA Visa card about 3 months ago and have been using it pretty consistently since then. During the last few weeks while away on business I used it at least twice a day every day for food at various restaurants in Seattle, Bellevue, and Issaquah. Needless to say, a lot of activity. The night before I came back from my trip, after a delightful dinner of seared Tuna encrusted with soy and black pepper, the waitress handed me my card with a receipt after paying my bill. She unintentionally handed it to me backwards (no she wasn’t backwards, the card was, stay with me here) and I noticed that I never signed it.

So about now you are thinking “Wow, what an idiot. How can you be so stupid?”. Funny thing though, I don’t feel stupid, not even the least bit. I find it rather amazing and pathetic that I could conduct 50+ transactions on this card and not one merchant ever asked me about it or probably looked at the back of the card for that matter. Should I feel stupid for not being “safer” with card? If you think so, then think about the following:

  1. Let’s say that somebody steals my credit card and signs it for me. Now when merchants do the signature comparisons the fraudsters receipt signatures will match the credit card signature. OH WAIT, MERCHANTS DIDN’T COMPARE SIGNATURES FOR 50+ TRANSACTIONS.
  2. On the back of my card in small text below the signature strip it says “Not valid unless signed”. SEEMS TO BE VALID TO ME, IT WORKED WITH 50+ TRANSACTIONS.
  3. On the back of my card in small text below the signature strip it says “Authorize Signature “. I BET MERCHANTS READ THIS REMINDER RIGHT AFTER THEY LOOK AT THE SIGNATURE (EXCEPT ALL 50+ TIMES).
  4. CitiBank says to prevent identity theft “Sign your credit card or write that the merchant must ‘check id’ on the back of your card”. SEEMS FEASIBLE, IF THE MERCHANT EVER LOOKED AT THE BACK OF THE CARD (ALL 50+ TIMES).

See any trends in those examples?

Well…I’ve signed the card. I’m not sure why, but everybody else does so I might as well do it too. Everybody seems to think it’s a good idea for some reason. I mean, I would hate to have the merchant get a wild hair and happen to CHECK THE SIGNATURE ON THE BACK OF THE CARD, and call me out on it. I can hear it now.

Merchant: Mr. Strange you didn’t sign the back of your card.
Brent: Dagnabbit! I totally spaced it. I feel so stupid. Here let me sign it.
Merchant: Oh, no problem don’t worry about it.
Brent: (the sound of chicken scratch as I create my humble cipher)
Merchant: Thanks Mr. Strange, I’ll be right back with your receipt.

Heh, and that’s the end of this sad sad joke.

Hmmm.. I may have found a good reason to sign it. I read somewhere: “By law, you are only liable for $50 of any fraudulent transactions on your card. Most credit card banks like AMEX, Citibank, MBNA, etc actually offer zero-liability on their cards, which means that you are not liable for any fraudulent activity at all! If you don’t sign the card — you are actually not eligible for those benefits!”

That’s assuming you get caught. How many stolen cards do you think are recovered? When they recover them do you think they check to see if you signed it?

Three blog posts per week…Riiiiiight.


Dear faithful readers (the 4 of you, the other 395 hits a day are search engine hits for “Windows Vista keys” and “play Mrs. Pacman online”),

I’m back. The last 3 weeks have been crazy busy with work and home. I spent 2 weeks testing up at the Microsoft Scalability Labs, and after returning home I’ve spent the last week: trying to make it up to my wife for being gone 2 weeks, getting the garden ready for the season, getting the yard under control, going to my boys’ baseball games, getting food poisoning from a local restaurant, putting Reedville Baseball back in order, and then finally… soaking in the fun-ness of our littlest one walking now (really cool and in the nick of time because crawling through wood chips at the baseball field equals slivers).

So yeah, I’m back but being baseball season its the busiest time of the year at our house (we have 2 boys playing). I’m going to try to stick to my goal of 3 posts per week (which I failed horribly in the last 3 weeks).

Wish me luck. 🙂

Post navigation