- 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
So, uhm, bone-headed storage of trusted data in cookies, and infinite loops aside, let me get this straight: Nate was required to write code that included a module, SecurityInclude.asp, but was not given the source code nor any spec about how his code was SUPPOSED TO BEHAVE with respect to the "secret" code? How can anyone expect this sort of arrangement to work?
Admin
Excuse my ignorance, but, where is the WTF in the code?
Admin
The real WTF:
Security shmurity!
Admin
Just out of curiosity, I dont see any infinite loop in the code? Or are you suggesting that redirecting to default.asp will trigger the Cookie-check again?
Is it not possible that maybe default.asp is the part of the webpage where users without cookies are forwarded to?
Admin
The code reads the "userid" back from the client and probably assumes it hasn't been tampered with; if the value is set, then the user is logged in. This is a completely invalid assumption.
Further, if you include this code on the home page, 'default.asp,' without any additions, you'll get an infinite redirecting loop when you hit that page. Maybe that doesn't happen in the real code and Alex snipped out or oversimplified that part of it.
Admin
The WTF is in the simplicity of it. This was top secret official security code that would be a huge security risk to leak.
Admin
Compelled to optimise....
If (Len(userID) = 0 or Trim(userID) = "") Then
If Len(Trim(userID)) = 0 Then
So... what was the problem with his page? Duplicate variable declaration of userID? The real WTF is that such simple code caused a problem with the poster's code.
Admin
Or maybe the company just got fed up with all the begging and pleading and decided to show the guy a file that has nothing to do with the "real" SecurityInclude.asp ... :)
Admin
Maybe someone there was aware of the massive insecurity with the code but didn't have access (or didn't care enough) to fix it, so he said "make sure nobody sees this file who doesn't need to know." Security through obscurity is still quite common in web applications.
Admin
Har har, now we know ho to break into this company's extranet. Well, we don't know which company it is, but I've heard there are less than one-hundred Fortune 50 companies, probably a number between 40 and 60. Can't be too hard to check them all.
Admin
The article says that the security code wasn't the source of the poster's problem.
Admin
It asume client data is trust and allowed to enter some areas.
Theres no differente of that and ...
www.example.com/changepassword.php?user=root
I mean, If user can "lie", that code can fail. So is a enormeous hole. A single trick that do nothing, but stop maybe errors, and maybe even errors can enter if other application on the same server use that cookie name... ... And will do because all apps seems to use that!
Its a big WTF made of a small boring naive "safety" trick.
Admin
Perhaps they were so timid about giving up the file because they were afraid someone would go and post the contents on a public website?
Admin
This seems like a slightly lame WTF to have to wait a long weekend for! Okay, it's not terrible – there certainly is a fair bit of stupidity in not letting your developers know at least the interface for the security code, and if that was the real 'security' include their security is pretty comical. But, without prior knowledge of the system and a bit of hackery (well, Notepad), it wouldn't be obvious how to break it – this is a long way from 'LOGGED_IN=NO'.
Admin
"... a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line..."
Wow!!! I mean - WOW!!!! That's the craziest marketing blah-blah I've ever seen :) Fits perfectly in "evrything about nothing" rule. 5 stars, man!! 5 stars.
Also, when I was about to click the Submit button to post this comment, the text of the CAPTCHA Test image was "billgates". Again, WAY COOL :)))))
Admin
No, the real wtf is that his code was probably never hit, as the test user kept getting redirected to /default.asp because he's not logged in.
Admin
Actually, the assumption is that if the value is not set the user is not logged in. They could, but haven't, add more checks to ensure the page request is from a valid user. The cookie check isn't a terrible check to have assuming (and this is, I think, the mother of all assumptions) they don't store the userid in plain text AND they avoid the infintite loop in the default page. The WTF is that they rely on this small, naive, easily hackable check as their SOLE source of security.
Fortune 50 huh, anyone else gonna convert their 401K portfolio to cash and hide it under the mattress?
Admin
If trim("" & userId) = "" Then
...is even more optimized...why wrap it in len()?
Admin
The error is that:
1) it relies on a cookie for authentication. It does not check for any particular value, it just assumes the server set the cookie, and therefore if it exists, we have a valid user. It doesn't check for a particular value, just if one even exists. There are many ways for clients to set cookies. I can set to WTF and i could get in.
2) It assumes all pages need authentication (except the home page), and it assumes all pages need the smae level of security.
3) (really 2.5, related to 2 above) it does not allow any page access except home page for people who turn cookies off. That may or may not be their design, but would piss me off if i just wanted to check their support numbers or something relatively safe like that.
They get an extra "you suck" point for realizing some of the issues (including not trusting clients to run Javascript), but then still letting this big truck drive right through their security (where they should not trust clients).
captcha: giggity (though really should be giggity giggity, i guess i passed my Turing test)
Admin
BAAAAAAHAHAHAHAHAHAHAHA!!!!!!!
Can't really say much else other than "Go figure."
They should try to patent their security approach. It seems completely infallable. They could make billions. It's quite ingenious! In fact, I'm surprised they let Nate see the source instead of having a drone hover over him to ensure that their files remained completely secure.
Admin
If they had this: "don't assume client-side code will run" in their guidelines, why didn't they also have, "don't assume client-side data is secure"...its a logical corollary.
Admin
Having worked for several fortune-50 companies over the past 25 years, I am sad to report that this sort of thing is more norm than abberation.
Aside: it seems to stay at the same level of WTF-iness regardless of the technology (Asm-Fortran-C-C++-Java-Web).
Admin
The real wtf is that some shitty contractor spent all of this time bitching about how some other source file was screwing the company out of N-dollars a day by claiming their code was breaking his, only to find out that it really was his mistake. I wonder if he ever fixed his bug?
Thanks Nate... one more reason to outsource to India.
Admin
"Beginners have a tendency to blame the compiler, the library, or anything other than their own code. Experienced programmers would love to do the same, but they know that, realistically, most problems are their own fault."
Brian W. Kernighan and Rob Pike, The Practice of Programming
The real WTF is blaming the security library which has obviously been used in other applications instead of debugging your own code.
Admin
Among the fortune 50 from 2005 are:
Citigroup
Fannie Mae
Bank of America Corp
J.P. Morgan Chase & Co
Morgan Stanley
State Farm Insurance Cos
So... what you are saying is that my bank and credit card statements, mortage info, investment portfolio, and insurance records could be just a few stupid simple hacks away from being public knowledge? Holy scary shit batman.
Admin
The WTF I see here is "including" security. Security is not some module which can be added or included in the code. It has to be built in to every part of the application.
As for this breaking the application, maybe the username was stored in a cookie named "username" or "login". How was Nate supposed to know how to keep track of session information such as the userID? Especially since he couldn't see the so called SecurityInclude.asp file.
Admin
Clearly in the verbosity of the code. A good coder would have condensed it to:
If (Len(Trim(userID)) = 0 Then ...
/irony
Actually it's the fact that cookies are a highly insecure place to store userid's, passwords, and other sensitive information.
Admin
Today seems to be great programmer quote day.... so......
Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
Admin
No, "security through obscurity" is very very very very very very *rare* in web applications. *In*security through obscurity, on the other hand, of which this is a fine example, reigns supreme.
cheers,
DaveK
Admin
I'll not fault Nate on this at all.
We have all done black box programming, use any control and that is what you are doing, this asp page is nothing more than black box. Now imagine using a control with no documentation on the interface, no explaination on how to interact, nay not even a "secured" form to develop against.
This page is harder than controls for the simple fact that he couldn't even do an interface query. He had to mock up something from nothing just so his code could have the include without breaking. It matters not how simple or complex the include page was, a developer needs at least some info to work with. Yes his code might untimatly have been the one needing change but until he was made even slightly aware of the parameters of the environment he was doomed to failure.
I could ask you to write an application, you could do it right but I can garuntee it will fail on install if I don't give you even a simple parameter like what OS it is to be installed on. Some things are just simply needed to write even one line of code. They failed to provide Nate with this even after he expressed his concerns.
Admin
Well no duh, the entire session based web page uses this concept. Across all the backend languages, the idea is to give the app engine a security token (usually some guid) to identify the appropriate session. There's nothing stopping you from spoofing that token, except for the sheer volume of available tokens.
One could argue that the entire username password idea is really security through obscurity, considering you could (and places like the NSA do) iterate through all possible combinations.
Admin
I concede: you've out-sesquipedalianated me. Someone really ought to use this in a director-level presentation and see if they notice that their legs are being pulled.
Couldn't Nate have just misspelled the name of the security file together with an "on error resume next" (or equivalent)? Use one WTF to kill another.
Admin
All computer security is through obscurity, except biometric security.
Admin
The ASP page "exposes" a variable called UserID which contains the UserID of the person logged on. I am sure they told Nate this information when he was writing his code: "Just include the ASP page and all you need to do is reference UserID and you are all set."
Admin
Amen, brother!
Too many times "security" is considered an add-on just as the app goes out the door.
It causes me to shudder.
Admin
what you are saying is that my bank and credit card statements, mortage info, investment portfolio, and insurance records could be just a few stupid simple hacks away from being public knowledge
Probably not ... if it was a financial co, the other WTF would be that they couldn't make it more secure because of SOX (or as I like to call it - the other WTF).
Admin
The essence of using session ids and encryption keys (and passwords if used properly) is that one can calculate how much time and effort is likely to be needed to break them. One can then increase the level of difficulty to whatever is necessary. With the longest keys even the NSA isn't going to iterate through them all any time soon.
With "security through obscurity" there is no way to perform any calculations and one has no idea whether the security is good or bad (though one can guess that the latter is far more likely.)
Admin
Except that you can never change the keys. And the keys are really easy to steal (you leave fingerprints laying around all the time, or someone can just chop off the appropriate bits (that used to be from a movie, until a couple of car thieves in Manila did it for real so it's not fiction anymore)).
Admin
At least now it's obvious why they wanted to keep the code secret. After all, as long as they keep it secret, nobody is going to figure out they can send a userid cookie and be instantly authenticated...right?
Admin
Unless they look in their browser cookies and see "UserID: 4245" and put 2 and 2 together.
Admin
But there I go assuming they already have an account.
Hopefully UserID=1 isn't the adminstrator account.
Admin
I'm pretty sure that in classic ASP, there's a slight performance advantage to doing
If Len(Trim(string)) = 0 Then
instead of
If Trim(string) = "" Then
I believe it comes down to how slow it is to compare strings in VBScript.
Also, I try to avoid string concatenation (string & "") as much as I possibly can.
Admin
I worked (briefly) at WTF university where all the applications did single signon with a GET request of
/someotherapplication/login.html?user=theusername&password=thepassword
After I pointed this out I left as quickly as possible. I think this is security by stupidity.
Admin
I think you misunderstood security through obscurity. Obviously all security is about having something others don't have. The level of safety is equal to the number of guesses you have to make in a worst case scenario. Security in obscurity refers to a subset of these, where knowing the exact algorithm of security is enough to break it. Session ids stored in cookies or passphrase checks are another thing, no matter how much you know about the method, you have to make lots of guesses to spoof a valid one.
Admin
That's why you also create a hash with a secret salt value and send that to the client too. If the hashes don't match, then the identifier is forged. Granted, you could still brute force it, but you can easily get past the volume of combinations that even a supercomputer can forge quickly.
Admin
Did you miss the point where they said no login was needed for the site?
Besides we're talking about a fortune 50 company. Why in the world would you assume they would give them the information needed to do the job?
I work for a fortune 50, I'm even actually employed by the company, not even a contractor. I'm not allowed access to most of the information I need to do my job, at least not until I've fought through 5 or so layers of beuracracy. Even then the info is never accurate (you have to fight through about 10 layers before you can reach someone who will say "Yeah, the documentation is wrong about that", if you're really lucky they may "know a guy" with the actual information).
Admin
You either have to sniff it or try all possible values. The latter approach is much more formidable, but even the former approach is complicated enough to deter most attackers. If you're in a position to sniff the session ID, you're probably in a position to read the data being sent to the client anyway -- unless you're reading the session ID directly from the user's cookie file.
Ehh. With most areas of security, the basic premise is: "Figure out how much effort an attacker will put in (which correlated with the value of successully breaking in), and design a system just difficult enough to make attacks not worth the time and effort. If the cost of implementation of this system is lower than the value of preventing attacks, implement it." In practice there's an equilbrium between cost of security and cost of security violations.
But with public-key cryptography, the equation changes considerably. The end game is to max out the key space.With 64 bit keys, we get an expected value of 2^64/2 = 9.2e18 keys that need to be brute-forced. A huge number, but not impossible to brute-force. If you can test 1 billion keys per second, then you have an expected value 292 days to recover the key.OK, let's use a 512 bit key. 2^512/2 = 6.7e153. This number is unbelievably large -- literally unbelievable. It dwarfs the number of nanoseconds since the big boom, number of subatomic particles in the known universe, etc. etc. If they key is this large, it is literally unbreakable without access to a quantum computer. The effect is simply to shift the weak point of design: if the key can not possibly be brute-forced, then attackers won't even try, they'll just focus on to the weakest point: steal the private key, dictionary attack, social engineering, etc.
So I disagree that all security is fundamentally based on obscurity, unless you count the fact that secrets worth securing exist in the first place.
Admin
If you use a badge to get into a building where you work, when your job ends, they usually want the badge back...
If you use a handprint...
(or a retinal scan!)
Admin
Pink Duck:
Compelled to optimise....
If (Len(userID) = 0 or Trim(userID) = "") Then
If Len(Trim(userID)) = 0 Then
That looks like an optimisation, but it will actually perform worse in some cases: namely, when Len(userid) = 0, the first part of the first 'if' expression will be true, and the second part will be skipped.
Why not just:
if Trim(userid) = ""
Admin
Nice quote, but you're assuming he didn't bother to test his own code. Nor is it mentioned that Nate was "blaming" the security library. Was it unreasonable of him to expect he might be given even basic details about the interface to the security library, and what effect it might have on the global namespace?