- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Security Through Obscurity at its finest.
Admin
This is so bad that I had to read it three times and now I'm not the first one to post any mor :/
Admin
I think "The Whiz" refers to the fact his code deserves to be urinated on. [:P] [+o(]
Admin
Funny how encryption just escapes some people. If you're worried about exposing values, you could just encrypt what you want to hide then decrypt it on the receiving page to reveal its true beauty, just like the poor Phantom of the Opera.
Or you could, you know, not pass values in the querystring...
Admin
Wow. Just wow.
Note: for full effect from this particular WTF, go find the title music from Clockwork Orange and listen as you read the code.
Admin
The worst part is, this is exactly equivalent to:
maskerAmount = 4340 * oTotal + 88040
So the last digit of maskerAmount is always zero
Admin
Dammit! Now I'll have to go back and change all my code to not use querystring :o(
Admin
with posts like these, Alex - you'll need to rename the site to:
"the daily OMFG"
-space
Admin
(999999 - 100000 + 1)
What's the point of doing that calcuation not only once but mutliple times?
Admin
Nothing wrong with using the querystring... as long as you verify it independently.
For example....
1. User pulls up "view product" page
2. User notes price - $50
3. User reads description
Time passes...
4. Manager changes price to $60
Time passes...
5. User decides "all right, I'll buy it"
6. User clicks "Add to cart" link which passes product ID and price via querystring
7. "add to cart" page compares price from query string and database and notices they're different
8. "add to cart" page displays helpful message to user along the lines of "The price of this product has recently changed to $60. Add to cart anyway? OK / Cancel"
Admin
Because 900000 isn't obfuscated enough, silly ;)
Admin
This is the classical definition of encraption. When the same amount is sent through this routine multiple times, only one part of the query string will remain constant -- the 7th through 12th digits of track. Now an attacker just needs to collect several of these values for different purchases and perform a linear regression to find they all fall on the line y=4340x+88040. It's then trivial to find x is the purchase amount, and modify it accordingly (depending, of course, on the context). Security by obscurity, indeed. [:@]
Admin
The power of mathematics compels you!
The power of mathematics compels you!
*** projectile vomit pea soup ***
Admin
This smells of overengineering if you ask me - especially in nontrivial systems where there's a lot more to consider about an item than just price. Just pass the product ID via querystring and present the user with a price totals page before they confirm their purchase. Even better, internally track the price that they "picked up" the item for in their shopping cart and do some sanity validation on that price (e.g. it is less than 4 hours old, etc.) and just charge them that price. Works out great for all concerned.
Admin
Why? if you're just going to check against the DB later, why pass the price? Better to do something like pass the timestamp and check it against when the product was updated.
Admin
<font size="2">grrr...god I hate code like this.
why would you even encrypt the total anyway?
</font>
Admin
Because the manager could change his mind and set it back to $50 again. This would lead to the user getting a confusing message like "The price has changed to $50" when it already was $50. Or maybe the manager just changed an internal field on the Products table, like the accounting code.
Admin
The YAGNI principle was invented specifically for this kind of thing. In practice, this is not a genuine problem. I've written a couple of web-store applications and my current employer shares an office suite with a company whose sole business is building web-store apps. Any user who doesn't check their totals on the checkout screen before blindly throwing their credit card number at a web site deserves to get snipped out of the $10 price difference - and customer service departments exist for smoothing over the problem. I'd be willing to lay out a decent wad of cash that a large amount of WTFery is generated by over-engineering to account for such non-issues.
Admin
And what if the total changes between when they load the "checkout" page and when they submit the "checkout" page? Do you check that?
Admin
Since you missed it the first time:
Admin
Admin
No, you misunderstand [:)] I'm fine with letting the user buy something at the price that was on the shelf at the time they put the item in their cart, even if we changed it by the time they got to the register. I do that myself in my homegrown shopping cart.
But I do pass the total from the "gather credit card" page to the "process credit card" page, because I worry about the user slipping something into the cart after I've swiped their card and before they leave the register.
1. User goes to checkout page with a stick of gum in their cart - total is $0.10
2. In another browser, user adds a big-screen TV to their cart
3. User pays $0.10 and walks out with their gum and their TV
Admin
Does that really work? Just askin', you know. Might be something to look out for in my own code. Yeah, that's it... [;)]
Admin
Try this at amazon.com and you just get sent back to the "confirm order" screen.
Passing anything important through the query string is a WTF. What stops someone from sending any query string they want? Nothing!
You should lock the shopping cart on the server, or check for new items in the cart before placing the order. Never trust any data that the client sends you.
Admin
Well, I do. Specifically, I compare the total I get from the form against the total I get by adding up the product prices currently in their cart.
So they could switch out products all they want, as long as their total remains the same. They are charged for - and their receipt contains - the products in their cart at the time I process their card, not necessarily what they had in their cart when the "enter credit card info" page was loaded.
Admin
It's actually: maskerAmount = 4340 * oTotal + 80600
I wonder if there's even bigger WTF behind this code. Why did he feel that total amount needs to be "masked" in the first place. From the code it looks like, it's being redirected to thankyou.asp, what is a big deal having total in query string on that page? Maybe it’s over engineering as some suggest. Or maybe the query string value is the actual value that is being charged to user credit card?
Relying on query string for any significant input is in general a WTF; what would happen if a user changed qs values and resubmitted this page with maskerAmount=0 or maskerAmount=xxxWTFxxx?
Admin
I'd highly reccomend changing that. It's practically begging for a mischarge lawsuit, since the possibility of billing for goods not received exists, and as you seem to be saying, is exceptionally easy.
While I think Apoch can take YAGNI, and shove it where the sun doesn't shine along with the rest of eXtreme Programming, he certainly has a point regarding the verification of goods in the cart against their current price at the time of checkout.
Admin
Nobody beats The Whiz!
Admin
You are missing the larger picture: what is the point of this entire bit of code?
Admin
Job security. Once you manage to slip such a beast into production you can't be fired. And if you leave the company by your own decission you can charge for consulting again and again, or have some revenge and leave them high and dry if you feel like it.
Admin
I'm confused. Is he trying to protect "The System" from End-Users or other developers?
[job] security through obscurity
Admin
Well, Alex. I think it's time to shut down your site. This is never going to be topped, IMO.
Admin
Are you sure?
Admin
Hmmm.... revenge may be good, but employment references are better.
Admin
<font size="1">Mortimer Armstrong:
Where in the world have you been hiding?
Really you were perfect.
I only wish I knew your secret,
Who is this so called whiz?
Coworker:
The user once spoke of an whiz,
I used to dream he'd appear,
Now as I code I can sense him,
And I know he's here.
Here in this asp-snip he calls me softly,
Somewhere inside...hiding.
Somehow I know, he's always with me,
he's the unseen [mathematical] genius.
Mortimer Armstrong:
My friend you must have been dreaming,
Stories like this can't come true
My friend you're talking in riddles,
And it's not like you!
Coworker:
Whiz of The System,
l33t h4x0r and Guardian,
Grant to me you glory!
Mortimer Armstrong:
Who is this Whiz?
This...
Both:
Whiz of The System,
Hide no longer,
secret and strange whiz
Coworker:
He's with me even now
Mortimer Armstrong:
Your hands are cold
Coworker:
All around me
Mortimer Armstrong:
Your face, my friend, it's white
Coworker:
It frightens me
[...]</font>
Admin
Keep your hand at the level of your eyes ;)
Admin
I suppose Mortimer would like to practice some punjab lasso techniques on "The Whiz"
Admin
Hahaha, oh man that's damn funny!
Admin
I'm sure there's a few people out there by now who would want to. With clue-by-fours.
Admin
Heheh... kudos for the Seinfeld reference...
Now, to re-write all this code:
Session["price"] = price
Done!
Admin
Hey this looks like my code!!!!!
Admin
The Whiz is Evil!!!!
Admin
Bah! That's easily fixed - you just need to use higher-order polynomials. If, instead of ax+b, you use ax^100+bx^99+cx^88+...+d, it will require 100 (or 101, I can't remember) orders to solve the polynomial values.
Obviously, you can make this even harder to attack by using massive polynomial coefficients. And, when the customers find that each order on the net is taking 2.7 years to complete, they'll go elsewhere :-).
It's a joke, Joyce.
Admin
Real mathemawizards use complex numbers to encrypt their pricetags.
Admin
Sometimes we need to use passing parameters through url (or post) for systems that have nothing to do with each other. The anti-tempering solution was easy to implement without obsuring anything - we calculate md5 signature for url + "a secret part" and append it as the end of the url as the last parameter. Works like a charm.
Admin
What amazes me more than the code is that in all the replies so far about ASP code, there has only been one reference to the server side only session object.
Suddenly, the Wizz.
Uh, since it is (APPARENTLY) only a thank you page, I'm not entirely sure why it is even really required to be so obtuse, but hey, whatever turns your crank.
Interesting technique to ensure that he can always pull out the price tho - you have to at least respect the thought put into the random padding, even if you can't admire his litteracy skills reading the asp manuals...
Admin
Speaking of litteracy skills.. :$
I was GOING to say, suddenly the wizz doesn't seem to be so alone... (after all, if everyone here can ignore the session object, why shouldn't he?)
As an interesting side note, and a totally different WTF, who set the limit limit for editing posts to obscenely small time limits less than 10 seconds??
Admin
Ooooo. u1tr4 l33t encryption by linear transformation. Julius Caesar would be completely baffled.
Yeah, it's overengineered. You never need more than ROT13 for anything.
--Rank
Admin
If maskerAmount is the "masked" amount and maskerDummy is "throw someone off", why is maskerDummy being passed in the Response?
Admin
There are some fundamental rules broken by the code snippet.
- Never expose private data via the Query String. This particularly
applies to sensitive data as well as data that is used to reconstruct a
portion of the UI that the user sees.
- By obfuscating the total amount and by attempting to mislead
anyone that is curious enough to modify the url, the author has
constructed two parameters: track to hold the actual amount and tot to
mislead. This in itself indicates that the author is aware of the
consequences of breaking #1 if not knowing the actual rule itself.
- Anyone trying to defend such methodology (as some have attempted
to argue that it is reasonable to send the data via the query string)
merely demonstrates a lack of understanding of what it takes to make
secure and functional web applications.
- Protecting the data from tampering can take many forms: one could
store the data in SQL Server with a timestamp or guid to provide the
reference key. Alternatively, one could store it in the Session object
(or in ASP.NET, one could store it in the ViewState and have enableMac
property set to true)
Invariably, any web developer who is still doing what this snippet does, exposing private data in the querystring ought to be publicly humiliated. They just give web developers a bad name and by no small measure, we have quite a significant mass of web programmers who are neither programmers of any decent distinction nor proponents of any worthwhile methodology.