| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Next » |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:04
•
by
Anonymous
(unregistered)
|
|
Why listen to your IT department when management know exactly what is best? I wonder why some companies bother having an IT department at all, surely it's just an unnecesary overhead?
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:05
•
by
JdFalcon04
(unregistered)
|
|
I wanted to post a comment, but I had nowhere to store it. Ah, I'll just throw it into Session and we're all set. No WAY it can be lost there!
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:11
•
by
Connect to Reality
(unregistered)
|
|
Who actually uses Access, for anything?
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:11
•
by
TheSilverBadger
(unregistered)
|
|
Of course it will be the IT departments fault when the application inevitably crashes and burns...
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:13
•
by
50% Opacity
(unregistered)
|
|
"Signed an NDA", huh? I guess I'm not supposed to see that huge chunk of code then.
|
Saw that one coming a hundred miles away. It is in situations like this where you have a moral obligation to demonstrate the security weaknesses by totally corrupting the database about 3 days after launch. From a Russian proxy, of course. (The "3 days" thing is critical. Too soon, and they haven't lost enough data. Too late, and they're beyond the point of falling back to the previous solution while they rethink.) And yes, your IT department is nothing more than a cost overhead. All modern companies are eliminating them as they just stand in the way of progress and fat bailout bonuses. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:13
•
by
Florian Junker
(unregistered)
|
Computer Science in HS. It was awful. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:16
•
by
A Secure Programmer (ASP)
(unregistered)
|
The mark of a pro. In case the select returns more than one row, you're ready.
Oops. No array index. Need to slurp the entire database into the session, not just the last row of the results. Having everything in memory really improves performance. |
|
This is why it pays to be cynical.
After 30+ years, my metric is simply, "Do the paychecks bounce?" If no, then I'm good with whatever cockamamie thing they dream up. Face it, folks. We're all just prostituting ourselves to some greater or lesser degree. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:19
•
by
Another nonny mouse
(unregistered)
|
Somehow, I always read that as "ass-enter". Don't know why. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:21
•
by
Been There
(unregistered)
|
|
Still remember what fun it was to show the vendor of an "industry leading" online brokerage package how to use their bulletproof code to grab a copy of /etc/passwd off the host. Gulp. Blink. Sales weasel shrivels and shuts up. Technical guy "um, yeah, I'll open a bug on that..."
It's not like an insecure stock trading system could cause much of a problem, right? Oh, but in their defense, the colors were quite vivid. And our marketing people were infatuated with their marketing people. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:22
•
by
Protector one
(unregistered)
|
|
Could someone explain why typing ' OR ''=' in the password field would give him access to anything? I don't see the magic happening there. :/
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:22
•
by
Anonymous
(unregistered)
|
|
Dammit...
So... much... rage...! |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:23
•
by
LikeWhoCares
(unregistered)
|
Acchole |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:23
•
by
Been There
(unregistered)
|
Cause that was the administrator's password. You're supposed to use special characters, you know. |
|
To be fair, instead of queuing the Access database every page request to fetch user information, it makes sense to put all that data in the session. It's likely quicker than Access. No real WTF there in my opinion. Makes sense with the tools they have at their disposal.
The rest, though.. yikes. SQL injection to dumbass management. Sounds like my previous company. Which is a nice story on itself. Basically: I recommended not to hire person X as my replacement, because he simply didn't know how to program. They hired him anyway. Only a few months later they decided he was indeed not worth the paycheck they threw at him so willingly. He's now picking up the phone, and the company hires some company in India to do their programming - something I also discouraged. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:24
•
by
basseq
(unregistered)
|
They certainly don't. Unless Dave's working, apparently. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:25
•
by
Steve the Cynic
(unregistered)
|
"Sir, incoming trace on the troll radar!" "Son, that's a big one. Give it everything we've got!" |
|
Can't say that this is really a "Curious perversion in IT". Where I work, it's more like "An everyday occurrence". |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:26
•
by
Connect to Reality
(unregistered)
|
|
I can imagine this happening over politics, like the software developers were big clients, or they were friends with someone in the company that got offended, i.e. the president's son's cousin's friend.
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:33
•
by
Protector one
(unregistered)
|
Ehm, no, I'm serious. I really don't get it. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:33
•
by
Addison
(unregistered)
|
|
*shakes fist*
I use ASP (.Net though) and I can tell you that large sessions KILL EVERYTHING. Who'd have thought IE crashes when presented with a 2 meg postback? Weird, huh? /sarcasm |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:34
•
by
GCU Arbitrary
|
I can imagine this happening in any organisation where management rolls over just as soon as the big-titted HR drone starts her high-pitched whining... |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:34
•
by
Little bobby... oh FFS you know the joke
(unregistered)
|
see http://xkcd.com/327/ and http://en.wikipedia.org/wiki/SQL_injection if you still dont get it |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:37
•
by
Barrett Jacobsen
(unregistered)
|
Because the code that called the SQL they were using was probably along the lines of ...WHERE...AND [Password] = '" + string_user_entered + "' Which when inputed with ' OR ''=' results in the following SQL ...WHERE...AND [Password] = '' OR ''='' Notice the last part the OR ''='' - that's always going to be true :P |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:40
•
by
lbp
(unregistered)
|
Wow, that's almost MY last company. Except they didn't hire a replacement for me: first dumb hire was a systems engineer who didn't seem very good. "Oh, ", cries the director "LBP, please try to like him, he's very cheap". So they hire him. Within a week he's rebooted every server he could in the mess of a system before doing due diligence and the dns crumbles around the failing Domain Controller. Oh, and he just did NOT understand IP. second dumb hire: Southern indian guy for a PHP dev role who I said seemed to have no clue. I said definite no hire, went on holiday, they hired him. And he was gone 3 days later. Everything is now being shipped off to India, and it sounds like they're replacing what was possibly the worst systems I'd ever inherited with something even worse! Hurrah |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:41
•
by
random.next
(unregistered)
|
There are many things wrong if that works... |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:41
•
by
akatherder
|
The SQL statement behind the scenes was something to the effect of: select * from tblUserLogin where username='<%=request.form("username")%>' and password ='<%=request.form("password")%>' If you enter your password as ' OR ''=' the resulting SQL statement is: select * from tblUserLogin where username='whatever' and password ='' OR ''='' Since ''='' you will be logged in as whatever username you entered. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:41
•
by
That Troper
(unregistered)
|
|
I get the concept of SQL injection, but I don't get how the "OR =" affects the SQL stuff.
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:42
•
by
www.learn-english-online.org
(unregistered)
|
Imagine their SQL is this: SELECT * FROM USER WHERE username = '%s' AND password = '%s' Which, when entering a username of bob and password of ' OR ''=' then becomes: SELECT * FROM USER WHERE username = 'bob' AND password = '' OR ''='' |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:42
•
by
Vilx-
|
|
Maybe you mixed up sessions with ViewState?
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:44
•
by
Voodoo Coder
|
Yer doin it wrong. It's not "OR "=" It's ' OR ''='' The difference: " != '' (double v single quotes...it is in effect saying OR BLANK SPACE IS EQUAL TO BLANK SPACE) |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:45
•
by
douglas
(unregistered)
|
Pretty standard SQL injection. You send a username and password to the server, the server tries to find your account by executing something like this: "Select * From Users Where USERNAME = '<insert entered username here>' and PASSWORD = '<insert entered password here>'. Send "admin" as the username and "' OR ''='" as the password and this turns into "Select * From Users Where USERNAME = 'admin' and PASSWORD = '' OR ''=''". This query will search the database for every user where a) the username is admin, and b) either the password is empty or an empty string is the same as an empty string. Since an empty string is always the same as an empty string, this effectively completely removes the password check - all you have to do is guess the name of the administrator account (and admin is pretty standard for that), and you can log in as the system administrator without having to actually know the password. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:46
•
by
MP
(unregistered)
|
The login code overlooks best practices and trustingly adds the password field to the database query looking up the user account. The additional (injected) string shown in the example checks for a blank string equal to a blank string. Because this test is connected to the first test with OR, you now have a tautology. So any person that can guess a username now has access to the system. This likely means the attacker will be able to gain administrative rights within the system. CAPTCHA: similis - This is similis to the dumbest thing I've ever seen. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:46
•
by
Niels
(unregistered)
|
|
No need to use SQL injection if the database is in the wwwroot :) Just download database.mdb and grab the passwords.
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:48
•
by
random.next
(unregistered)
|
Don't forget that they also seem to store passwords as plaintext. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:53
•
by
amischiefr
|
|
What is the website? I want to use ' OR ''=' and see what's going on!
Stupid CEO will get what he deserves soon enough I suppose. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:56
•
by
Code Dependent
|
I assumed it was a portmanteau word for "Access Adventure". Hmm... could be the same thing, I suppose. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:56
•
by
dkf
|
You're being too smart. Remember, computers are seriously dumb and do just what you tell them to, but no matter how dumb computers are, the authors of that code are dumber. If the authors had been any good, they'd have used bound variables or (non-blecherous) stored procedures, and that trick wouldn't have worked. It would have just been an odd password. But instead they're just dozy noobs and went for simple string substitution. (For goodness's sake, they didn't even apply magic quoting, which is a bit of a sucky and effort-intensive way to solve it but still works.) The true fix of course is to delete their entire database from underneath their feet while they're in the middle of demonstrating to a massive client, or (if you're feeling evil and want to do things untraceably) perhaps to just brag about how that whole system is totally unbreakable. I'm continually amazed at just how naïve some programmers are, even after years of experience. (I'm also worried that I used to be just as bad…) |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:56
•
by
Anonymous Coward
(unregistered)
|
|
Yep, Why listen to your local experts when you can outsource them to people who will tell you anything you want to hear.
Isn't that the FIRST thing they cover in Managment 101 nowadays? |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 09:58
•
by
Protector one
(unregistered)
|
|
Thanks for all the explanations. :)
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 10:07
•
by
Ben Jammin
(unregistered)
|
|
For some extra resources on SQL Injection:
http://xkcd.com/327/ (oldie but goodie) |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 10:08
•
by
Ben Jammin
(unregistered)
|
|
And that's what I get for only reading 75% of comments. I hate myself
|
There, fixed that for y'all. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 10:11
•
by
steenbergh
|
Lesdyxia... |
|
Well, if Accenture did it!
Did you guys see that story on Digg a while back about how the London Stock Exchange was "ditching Windows", because some (Windows based) software Accenture wrote crashed, so they were replacing it with a (Unix based) alternative? Yeah, I'm sure Windows was the deciding factor there, not some idiot at Accenture's shitty code. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 10:19
•
by
Bruce W
(unregistered)
|
|
Since I worked for Arthur Andersen when Accenture was still Andersen Consulting I enjoy *anything* that pokes fun at self-absorbed AC consultants.
|
Re: Slow, Difficult to Code, and Buggy
2009-07-09 10:20
•
by
mr_smith
(unregistered)
|
Like the other guy said, yer mixing up session and viewstate. viewstate is a type of session - http://www.martinfowler.com/eaaCatalog/clientSessionState.html The session they are talking about here means the server side session. Don't stick 2mb worth of anything in the viewstate! That's a WTF all in itself. |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 10:20
•
by
DOA
|
QFT |
Re: Slow, Difficult to Code, and Buggy
2009-07-09 10:23
•
by
Niels
(unregistered)
|
|
So, if HR explicitly chooses to use a system without security. Does that make it legal to 'improve' the data in such a system ... like everyone's salary (except the HR people of cource)?
|
| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Next » |