• DiverKas (unregistered)

    URL variables are the devil spawn of noobs reading all the doom and gloom about session variables.

    See this all the time. Even Amazon for a brief time had the same problem, and I could see other users shopping carts. Amazing what some people read.

  • (cs)

    Ahhh, management; willing to spend $10 to avoid a $1 fix.

    It's why we'll always have jobs ;)

  • ObstinateCoder (unregistered)

    This sounds like OCAN's Annual Conference on Child Abuse and Neglect's registration web app. What a wonderful project that was to work on.

  • Squidfood (unregistered)

    Not CC information? For practical jokes alone, the science jokers I work with would pay to mess with reservations of their colleagues in our small little world. I'd sooner trust them with my cc, at least those charges are stoppable.

  • (cs) in reply to ObstinateCoder
    ObstinateCoder:
    This sounds like OCAN's Annual Conference on Child Abuse and Neglect's registration web app. What a wonderful project that was to work on.
    Sounds like there should be an Annual Conference on Security Abuse and Neglect, and everyone on that project team should attend?
  • Jim (unregistered)

    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.

  • Harrow (unregistered)

    I Spread Love Sheets

    -Harrow.

  • Kozz (unregistered) in reply to Jim

    TopC0d3r, you're using the wrong login again.

  • (cs) in reply to Kozz
    Kozz:
    TopC0d3r, you're using the wrong login again.

    Good catch!

  • RBoy (unregistered)

    Of COURSE they were not holding credit card information. They were holding the information regarding the virtual cash that was being used in place of credit cards. Don't be such a pecus.

  • (cs)

    A coworker found this very same hack (the querystring number) in our 401k system. It was another group's code, and we told our manager that it had to be fixed. She couldn't believe that the other group could have allowed this -- "No, they always do good work."

    She changed her tune when I looked up her number in the database, logged into the system, changed the querystring number to her number, and handed her a printout.

  • Procedural (unregistered) in reply to Jim
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.

    Interesting. Which software is this ?

  • Kris (unregistered) in reply to Jim
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You're kidding, right? Your application is a WTF in the making...
  • (cs) in reply to Kris
    Kris:
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You're kidding, right? Your application is a WTF in the making...

    I hope he's kidding.

  • BN (unregistered)

    I'm not all that sure what the WTF is for a manager who makes a business decision that the value of fixing an issue is lower than the opportunity cost of fixing it.

  • (cs)

    I saw this same mistake made once with an electrical engineering online homework site developed by the professor. I told him about the problem, and he said "thanks" and fixed it himself that same day.

  • (cs)
    Andre:
    Bite!
    Hooked three in one hour. Impressive.
  • CynicalTyler (unregistered)

    The next step is Glen telling them he upped his rates to $500/hr.

  • Nielkie (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    Kris:
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You're kidding, right? Your application is a WTF in the making...

    I hope he's kidding.

    It reminds me of my school. Although they are strict about password security (minimum length, letters, numbers, must be changed one a month, etc), to send your password from the super-wizz-bang-flash-login portal to the actual web application, it is simply rot13 encoded and sent as a URL variable. Not even over https.

    Furthermore, the web application is vulnerable to XSS, and stores your password as a cookie in plain text. Fun :)

  • (cs)

    My first consulting job (many decades ago) was for a hospital with a recently-completed computerized patient management system. The job was to add what we now call a session timeout, so that the operator would have to log in again if the terminal was idle for more than 10 minutes.

    It seems that some prankster had discovered a logged-in terminal on the test system and admitted the head of the I.T. department with a combination of veneral diseases.

    Or perhaps the prankster was someone really concerned about security. Sometimes that's what it takes to convince management.

    (There's a bit more to the story too: The original contractors had "finished" the job but there was still some money in the budget. Someone who knew I was looking for work brought me in for as many hours as the leftover money would allow. I finished my work but heard later that it was never added to the system, but as far as I know nobody played any pranks with the production system.)

  • JimBastard (unregistered)

    and let the CF bashing begin in 3...2...1..

  • Anonymous (unregistered)

    Mark, you're not a very good writer.

  • (cs) in reply to JamesQMurphy

    Our website got hacked a while back. I was chatting with the main network guy on IM. I asked about SSNs. He said "No, they're not in that database."

    I logged into "that" database, queried his name, pulled the "ID" field, pasted it into IM and said "Look familiar?"

  • greg (unregistered) in reply to Jim

    @jim:

    I hope you're being sarcastic? what security do you think base64 encoding grants you?

  • BEF (unregistered) in reply to Jim

    (Ignoring the "base64 encode" bait)

    Passing personally identifiable information in the querystring

    From what I read, there was no information in the querystring. BUT modifying the querystring was sufficient to gain access to personal information.

  • Sean (unregistered) in reply to Jim
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.

    I think the count is up to 6 or 7 now. Fairly impressive for a 2 line comment. Usually it takes a few more rows to get most people.

  • BillyGoat (unregistered) in reply to Nielkie
    Nielkie:
    JamesQMurphy:
    Kris:
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You're kidding, right? Your application is a WTF in the making...

    I hope he's kidding.

    It reminds me of my school. Although they are strict about password security (minimum length, letters, numbers, must be changed one a month, etc), to send your password from the super-wizz-bang-flash-login portal to the actual web application, it is simply rot13 encoded and sent as a URL variable. Not even over https.

    Furthermore, the web application is vulnerable to XSS, and stores your password as a cookie in plain text. Fun :)

    The third Billy Goat, Stepped onto the bridge....

  • Wyrd (unregistered)

    I think this is better than most of the wtfs on the site because in this one the consequences for not doing the Right Thing(tm) were clearly demonstrated, and they were rather painful as well.

    -- Furry cows moo and decompress.

  • KP (unregistered)

    I believe this was the exact same type of problem that the Canadian online passport application website suffered from until somebody pointed out that you just needed to change the ClientID in the fat url, and you could get access to anyone's passport application who had logged in in the last day.

    No spreadsheets involved, but same url problem.

  • (cs) in reply to BN
    BN:
    I'm not all that sure what the WTF is for a manager who makes a business decision that the value of fixing an issue is lower than the opportunity cost of fixing it.

    In this case the WTF is the manager underestimating the cost of not fixing it.

    Sure there were no CC #s in there, but apparently there were green M&Ms.

  • Tom (unregistered)

    Are you kidding? I was on the Google Store a few years ago after a friend linked me to his order form since it used the same URL trick, and you could increment and decrement the number and see other orders. So we went down to the early numbers and got some GOOGLE EMPLOYEE PURCHASES. And their home addresses.

    And we did nothing with them. Just told Google. Oh well.

  • J (unregistered) in reply to JimBastard
    JimBastard:
    and let the CF bashing begin in 3...2...1..

    Y'know it's actually pretty good.

    Just sayin' is all...

  • Ananamous (unregistered)
    I <3 Spread Sheets
    Man ... i want this cup! But with a similar message:

    I <3 Spread Legs

  • Robert (unregistered) in reply to Jim
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You should review your software right away! That's an headache waiting to happen! If someone figures out that you're using base64 to encode the credit card they can easily decode it!!

    I suggest that you pass the CC through base64 more than just once. Something like base64(base64(base64(base64(cc_string)))). You should change the number of times the string go through the base64 encoding at least monthly. That way it will be very difficult for anyone to figure it out.

  • Mr.'; Drop Database -- (unregistered) in reply to Ananamous
    Ananamous:
    I <3 Spread Sheets
    Man ... i want this cup! But with a similar message:I <3 Spread Legs
    I'd like one that says "I ♡ Unicode"

    (Yes, that's intentional.)

  • (cs)

    I'd like one along the lines of "I <= 2.9 math". But with the 9 overlined.

  • Chris (unregistered) in reply to Robert
    Robert:
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You should review your software right away! That's an headache waiting to happen! If someone figures out that you're using base64 to encode the credit card they can easily decode it!!

    I suggest that you pass the CC through base64 more than just once. Something like base64(base64(base64(base64(cc_string)))). You should change the number of times the string go through the base64 encoding at least monthly. That way it will be very difficult for anyone to figure it out.

    No, what you should do is first generate a truly random number. You can do this by taking the product of 10 successive calls to your languages random command. You will now have some number 'n'. Now run the base64 encode n times and pass n as a base64 encoded value to the next phase of the process. You can now decode the value of n and then run a loop to iterate doing a base64 decode n times.

    Something like:

    $value = $_REQUEST['something'];

    $n = base64decode($_REQUEST['uYpiI']); // Pick a random request variable name, and change this name monthly/weekly for( $i = 0; $i < $n; $i++ ) { $value = base64decode($value); }

    There's no way anyone will be able to hack that!

    CAPTCHA: aptent ... lol

  • El Dorko (unregistered)

    "Playing devil's advocate, he ticked the number at the end of the URL down by one and refreshed the page. Suddenly, he found himself viewing the user details of Greg Smith. Glen tried reproducing his test on the live system and confirmed that not only could he pull up any user's information ...but, more frighteningly, without first having to sign in."

    It's not even funny how many times I've found this (I do analysis and audits of systems built by others), even in so called "serious" apps built by so called "serious" businesses. 99% of the developers I've ever met deserve a kick in the groin every morning for the following seven years by a Bulgarian wrestler for this sin alone.

  • (cs) in reply to CynicalTyler
    CynicalTyler:
    The next step is Glen telling them he upped his rates to $500/hr.
    QFT

    TRWTF is that Glen still performed the fix in 16 hours. We have an obligation to educate the people by hitting them where it hurts.

  • (cs) in reply to Jim
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.

    But beware of hacking tools. There are evil websites that let you hack by decoding the base64 encryption! :P

  • Eddypearson (unregistered) in reply to DiverKas

    "About 16 hours to change, test, and..."

    There's your WTF. How can it take 16 hours to add a bloody IF statement?

  • (cs) in reply to lolwtf
    lolwtf:
    I'd like one along the lines of "I <= 2.9 math". But with the 9 overlined.
    Like this? “I ≤ 2.9̅ math”

    Well, assuming your browser renders it right. Mine's inconsistent...

  • PyroTyger (unregistered)

    Excellent. This is one of those perfect little WTF stories, sublime in its lean simplicity. It's all in there:

    • A simple, stupid balls-up, of the type anyone with a modicum of development experience knows to avoid by instinct
    • The issue being raised, and then completely ignored by management because it hasn't been a problem so far
    • The issue rearing its ugly head later and scaring the shit out of management with its predictable consequences
    • The developer getting to drop a big fat "Told You So"

    It's not a huge, convoluted, terrifying tale full of dramatic licence and personal gripes, and it's not just someone posting crap code and going "LOL n00b!" It simply says it all, with a really obvious WTF, and a valuable lesson. Who knows - maybe this kind of article could serve as ammunition next time you confront the Director with a problem...

    More of this, please.

  • (cs)

    The Real WTF is that Alex trademarked The Real WTF...

  • Sebastian (unregistered) in reply to Arancaytar
    Jim: Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science

    I dont think there is much point in doing encryption on the client side in script, the code will be visible. Wont it be better to use https and post for security. another way would be to use some applet for the encryption. so at least its somewhat hidden.

  • (cs) in reply to bjolling
    bjolling:
    TRWTF is that Glen still performed the fix in 16 hours. We have an obligation to educate the people by hitting them where it hurts.

    Yes, let's all gouge the non-profits!

  • Anonymous (unregistered) in reply to Robert
    Robert:
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You should review your software right away! That's an headache waiting to happen! If someone figures out that you're using base64 to encode the credit card they can easily decode it!!

    I suggest that you pass the CC through base64 more than just once. Something like base64(base64(base64(base64(cc_string)))). You should change the number of times the string go through the base64 encoding at least monthly. That way it will be very difficult for anyone to figure it out.

    That's idiotic. If you already knew the parameter was a credit card number and because it would be obvious that it's base 64 encoded anybody could do something like:

    String cc = request.getParameter("cc"); while (cc.length() > 16) { cc = base64decode(cc); }

    You gotta love developers who think different variations of base 64 encoding inherently means better security.

  • (cs) in reply to Anonymous
    Anonymous:
    You gotta love developers who think different variations of base 64 encoding inherently means better security.
    And you gotta love T0pCod3r (and his offspring)'s "innovative solutions" even more. Sometimes they provide more fun than the article itself.
  • Fnord (unregistered) in reply to Jim
    Jim:
    Wow, I'm shocked. Passing personally identifiable information in the querystring without any obfuscation is just plain stupid. Needless to say, when our shopping cart software confirms a sale and passes us the user's CC number in the querystring, we have the good sense to BASE64 encode it on the client first. It's hardly rocket science.
    You, sir, are a genius.

    Like flies to a bug zapper...

  • m (unregistered)
    When Glen Sommers was hired to add some features to a Cold Fusion based web application for a non-profit organization, he wasn't surprised by the quality he found, instead he expected it.

    When I read the Daily WTF, I'm not surprised by the number of comma splices I find, instead I expect them.

Leave a comment on “The Revealing Spreadsheet”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article