- 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
But I did NOT use IE... this alone increased security too.
Admin
Yeah, it was that "Better Ways" part that was escaping me. You're right, I wouldn't want to piss anyone off if I didn't have to, just didn't see that "didn't have to" part Thanks
Admin
My favorite is the last one, using the SQL keywords. I had a client whose former developer tried a similar tactic -- they "sanitized" (ahem) every input from the web site.
Among the no-no words were all of the above, plus my favorite, exec. Since exec was never allowed as input, any user signing up for the site using an e-mail address of execpc.com, executrain.com, etc., was simply denied the ability to sign up -- and therefore the client literally lost business.
We cleaned up that mess pretty quickly. Especially since all of the SQL input of the site was already encapsulated in parameterized queries.
Oy!
Admin
How about this for a trojan?:
Lets look at the easy things to do: Hook into IE and figure out what its connecting to. Check. Figure out when the mouse is clicking. Check. Taking a screen shot. Check. Sending it. Check.
Of course, it's a pretty targetted trojan, as it will only work on sites like the ones described above. But there's nothing really stopping someone from rolling this into their own keyboard logger.
Admin
I forgot to mention when I wrote it that I was thinking of a worst-case scenario - a lan-house PC, AKA virus colony. If I was in your house I supposedly know you as I knew my friend, then I can trust you enough to skip the whole USB search.
Admin
It just misses the point. You need to properly prepare/escape the query before you run it. If you do that correctly it doesn't matter what the input is, so there is no point in banning SQL keywords, and your database will be perfectly capable of handling little bobby tables, little jimmy delete where, and little suzy update.
Banning keywords is a pain anyway. Inevitably there will be a person who will want to use one of them, and will grow incensed because they can't.
Admin
Admin
We have just implemented this as a new security measure in our shop, means were 100% safe and secure....and thats a price were prepared to pay for the improved efficiency of our staff....
Admin
np: Amon Tobin - The Killer's Vanilla (Foley Room)
Admin
-Harrow.
Admin
It obviously was a good joke - it keeps re-appearing :-)
Admin
TRWTF is these people believing parametrized queries makes you safe, there is always a moron who would use exec inside the stored procedure to build the query dynamically...
Now, from experience don't say anything in a job interview, just go with the "official microsoft answer": parametrized queries (tm)
Admin
Admin
Is that sarcasm or are you for real? Is there really malware that does this?
Admin
All this fancy "security" and they're still hard-coding the opening and closing quotes instead of using a QuotedStr()-like function to quote the string, doubling any internal quotes*.
*Which a parameterized query would do automatically, anyways. But that's too easy...
Admin
Smash King: Trust us, we don't give a fsck about your webmail password.
There are tens of thousands of people falling for phishing scams every day, and giving up credit card data.
Hell, there are hundreds of people still falling for the Nigerian Prince scam. What makes you think anyone cares about your hotmail account?
Admin
I was playing some mmorpg the other day. The login screen is a normal one with user/pass but to enter the game, you need to put a 4 digit code on your character. The digits are aligned on the screen and you have to click the numbers with your mouse. These numbers are sorted randomly and each time you click, they reorder themselves.
I still haven't understood why the characters/toons are "secure" but not the account.
CAPTCHA : bene
Admin
Maybe the site should have a dropdown of obligitory responses including various xkcd strips and stuff about wooden tables.
Admin
Huh? I always thought prepared statements would NOT be combined together to one query if the dbms is capable of handling these. So there would be no quote doubling/escaping. It's just sent as "additional" data in the packet, the query having those values replaced by ? or a smiliar replacement.
Of course, if the dbms can't handle those prepared statements, somewhere they have to be combined together with their values into one query.
Admin
The better mouse-based password entry systems combine OTP and CAPTCHA characteristics to make something that is easy enough for humans to bypass (so it won't keep your girlfriend or pissed off helpdesk staff out) but are fairly challenging to automate (so they slow down the massive automated attacks that represent the real risk at this point). Not a waste of time. Copy paste tricks will slow your boyfriend with the hardware keylogger but aren't going to stop anyone.
Regarding the keyword list... I have no idea whether they actually did that for security or not. "Security" has market value in some realms. It's like the "no guns" signs you see in store windows in some areas -- nobody who is planning to commit a crime with a gun is going to be bothered by a "no guns" sign, but some store actually spent money to put up that sign thinking it would improve their bottom line. Why? Because they thought their customers would perceive the store as being more secure and would be more likely to shop there. That can even apply to security measures that actually interfere with the customers. Sort of the "everybody take off your shoes for the TSA" approach to security. So long as they block only whole words ('in' not 'indiana') it isn't even a huge bother.
Admin
Admin
There is nothing steamier than a hot sequel injection! Just turns me on thinking about it.
Admin
Actually, yeah, NULL.
' UNION SELECT login, passwd, NULL, NULL FROM users --
is a great way to leak information from a database. Still an asinine defense, though.
Admin
select (*) FROM articles where columns like '%');%'
Oh wait.
Admin
Because if you have done your job properly (sanitize/escape data), it is completely irrelevant what keywords are used and it is a huge annoyance to the user to be unable to use commonplace words.
Admin
select (*) FROM articles where columns like '%');%'
Oh wait.
(Sorry about double post,quoting phail)
Admin
As for my webmail password, it may be little value for you, but it is quite important to me. Important enough to make me spend 40 seconds on this little measure. Besides, email accounts are used for other purposes other than communication with an old college friend; the information in it could be valuable enough to be worth those 40 seconds; and my password might be used in other authentication systems.
Admin
Admin
Why not
base64_decode(base64_decode(base64_encode(base64_encode($sensitive_string))))
Double-encoding works so much better.
Admin
Overlong UTF-8 sequences. Google them.
Admin
Prepared statements won't, but the results of those statements might.
If the user inputs '; DROP DATABASE--
Your code looks like this:
Yes, @INPUT becomes properly escaped and passed into the database as a single string, '''; DROP DATABASE'
BUT what if instead of a direct SELECT, you ran a stored proc:
You have the same problem all over again. SELECT * FROM users WHERE name LIKE ''; DROP DATABASE-- ';'
Alternatively, you also risk having a replay attack. Basically, someone puts something harmful into a field that will be accessible by others. Say the tagline underneath someone's avatar. They put in as their tagline "<script>MASSIVE XSS BUMREAM</script>". Or they put in a Bobby Tables, and then start looking for other insecure stored procs in your system.
Let's say their favorite fruit is ';--DROP DATABASE, and you've made sure that your user-entering fields are properly parametarized. So when he updates his profile with the Evil Fruit, it's saved OK and doesn't trigger anything. Then he hits the button that says "Find all users with the same fruit preference as me", which submits ';--DROP DATABASE to a second stored procedure written by the junior developer, that isn't paramaterized...
So a double defense is better. Make sure your don't accept harmful stuff (unescaped special characters, etc) to catch everything you know about, and paramaterize EVERYTHING to catch everything you don't know about.
Admin
Please to respond with your email address and password to prove your point that no one cares about a webmail account.
Admin
Shhh, don't give them ideas - one of the banks I use online has an awful system that flashes the actual number codes and turn them into asterisks when your cursor is above them. It also scrambles the numbers between clicks.
It's incredibly annoying to use!
My favorite bank now uses hardware tokens... Impossible to capture with a trojan, and the only thing I have to do is not lose them.
Admin
Perhaps I am missing some sarcasm here. I have seen the mouse-based login before and it is actually very secure. Screenshots wouldn't do you much good unless you were taking several a second. This would cause a noticeable delay on many systems. Capture of mouse clicks could provide some useful information, but would be much harder to parse through than keyboard logs.
Admin
Surely, base64_decode(base64_decode(base64_decode(base64_encode(base64_encode(base64_encode($sensitive_string)))))) , would be much more secure!
Admin
while(true) { base64_decode(base64_encode($sensitive_string)); }
Infinite security. Perfect.
Admin
I'm confused... It seems to me that base64 encoding the table entries would prevent SQL injection. Granted it does so in the weirdest and most roundabout way ever, but it would work, wouldn't it?
Admin
Nope.
You beat the living sh*t out of your devlopers that don't use prepared statements, and DBAs that allow SPs that create strings and exec them like that.
Code reviews ever heard of them?
Admin
Wait -- wouldn't this be more secure?
base64_decode(base64_decode(base64_decode(base64_encode(base64_encode(base64_encode($sensitive_string))))))
Admin
how about you just ban unparameterized queries? I know, some places don't even use source control, but rejecting code out of hand unless it uses parameters solvers this side of the problem. Stripping html out of stuff that other users will see, or using a filter that only allows specific markup fixes the xss attack.
Admin
Parameterized queries makes you safe from users. They can not make you safe from your own moronic coders that would exec a query in a stored proc.
The point here is to protect you from malicious users. Code reviews are supposed to protect you from the idiots you hire.
Admin
/*- You can never be secure enough. Recommend security level
- no less than 999.
*/
function make_sensitive_string_safe($sensitive_string, $security_level = 0)
{
$sensitive_string = base64_decode(base64_encode($sensitive_string));
if($security_level > 0)
make_sensitive_string_safe($sensitive_string, --$security_level);
return($sensitive_string);
}
(Untested :P)<sarcasm/>
Admin
Ah, forgot to assign the result back to the variable (and I wonder if 999 would be enough to overflow the stack in typical operation...). :-[ You get the point.
Admin
Do you really think that would solve anything? My guess is that he hoped the encoding process would be vulnerable to the same sort of error, without access to the SQL database, and would only return the part of the string that did not contain the SQL injection. The following decode line is so that the rest of the password is readable in its original form. Doing that over and over again would add nothing.
Admin
Parametrized queries are not rocket science. In fact, using them is vastly easier than all the attempted hacks to prevent injection attacks.
Nothing pained me more than when I first Googled "prevent SQL injection" several years ago and the first several pages of results had morons suggesting trying to sanitize input and other stupid hacks.
Admin
seems like most of the problem lies in selecting the username and password at the same time. with php i generally do:
$username=$_POST['username']; $password=$_POST['password']; $password_md5=md5($password); $db_val=getPass($username); //getPass: select
passwordfromuserswhereusername=$username //the query can't be broken via injectionif ($password_md5 == $db_val ) { $_SESSION['authenticated']=true; }
Admin
This might be true, if the base64 encoded values were stored in the database. However, in the example shown the value is encoded and then immediately decoded, so you wind up stuffing the original value into the database.
Admin
I shudder to think of such a perfect world like that, because then there'd be no more WTFs-- and then what would I do with my time?
Admin
In theory, yes. At first.
But it makes the data pretty had to work with. Every time you want to do anything with the data, you'd have to un-encode it.
Then you'd still be in the same boat, because the unencoded data would be DROP DATABASE, and the minute you try to use it in a query, poof.
That is assuming your servers don't grind to a halt first from having to encode and decode every piece of data you process. Or if they are able to handle it, you hope your company doesn't grind to a halt because it spent all its money on servers that are spec'd beyond its requirements.
Admin
Actually, that would be a great way to "improve" the performance of your web app. Throw in a bunch of layers of encoding/decoding. Then, when the client complaigns it's too slow, remove a couple layers of the encode/decode. Voila! Instant 'optimization' and speed improvements!