What is Digg?56 Comments
- usuk, on 10/12/2007, -0/+12Doesn't matter. The information has already been out there and widely known for years. If anything it makes developers aware of the security problem (I've seen so much crappy code that was vulnerable like that). There are some FAR better guides out there like this one:
http://www.ngssoftware.com/papers/advanced_sql_injection.pdf
Too bad this guide is ridiculously short and simple - it even has some errors in it (the "drop table" part would result in a weird/invalid select/sql error but no table dropped, 100% wrong). And it fails to show how to gain info about the schema (which you have to know to be able to do anything). In 2 words: totally pathetic.
And it also fails to offer any advice (short of "we sell some overpriced unecessary junk").
-DON'T make SQL queries by concatenating strings - EVER. Parameterized queries at least, or using sprocs. (If whatever lanaguage/platform you're using sucks bad enough to have none of this, as a last resort, you can strip off things you don't ever to want to make it to the DB from the fields like "drop table" and escape strings, but both are a ugly hack and workaround more than a solution)
-Always validate user input - not only in javascript on client side but ALWAYS on the server-side too (RegExps are good for this).
-Some web/app servers and frameworks have settings that'll detect and protect you against those attacks.
App firewalls are not a bad thing to have, but they're NO substitude to writing proper/secure code. Bolting on security on insecure code is a bad idea. - merreborn, on 10/12/2007, -1/+8Don't trust the client. Input validation on the client side is great and all, but you STILL have to do your input validation on the server too!
Always. - Elixon, on 10/12/2007, -0/+7Only amateurs do such as mistakes like unescaped SQL queries. :-)
The example with "hacking" the BankCO was stupid... I doubt that banks are employing stupid programmers and have no testers...
And the "anti-hacking firewall" that "knows" that values were altered :-) Funny idea to "know" that values were altered on the client's side - in these days when every other word you read every day is "Web2.0" that massively deploys altering of select boxes, hidden form fields and every other elements possible on client's side... If somebody really needs "smart form firewalls" to help detecting the form altering on client's side then he/she should consider doing another job then programming (for banks)... ;-)
Don't you think? - n3tfury, on 10/12/2007, -0/+6they're selling a product, of course it is.
- dbr_onix, on 10/12/2007, -0/+5It's not that they ignore it, it's they don't know about it..
Also, client side scripting should NEVER be used for security-stuff like this (input validation). It should only be used to help the user with stuff like reminding them about empty fields..
- Ben - hchaudh1, on 10/12/2007, -0/+4Couldn't agree more. Our app has about 12 forms and about 400 fields. So validation is a pain but not impossible. And I have explained this point to my boss quite a few times too. But every now and then, he comes around and says, can we drop this req or that req to shave off some hours off the project.
I think devs should have a website about best practices and get them ratified by some business entity. And then these best practices should be taught to managers. - Surreal, on 10/12/2007, -0/+4Yeah, did you read the article description?
"While this may be 1-2-3 for web application programmers, it is quite revealing for those not involved with web application security on a daily basis."
So, OBVIOUSLY, this wasn't meant for developers. - groogs, on 10/12/2007, -2/+6It's actually easier than the video shows. Simply go into your browser options and disable javascript. You don't have to bother with saving to your hard drive, or modifying the page code. There's a chance they'll require javascript (ie, the form does nothing unless the javascript code runs to tell it where to submit) but most sites don't work like that.
- jrhelgeson, on 10/12/2007, -1/+5I meant the site to be a brief introduction to SQL injections for management and non-technical people. Until now, there have been few examples available that were geared to that audience. I KNOW that executing ' drop table users -- would result in an error, but I don't want to put EXACT information out there for script kiddies, I wanted to make a point. This site was NOT DESIGNED for the developer community.
Joel Helgeson - tritium, on 10/12/2007, -1/+5if instr(request.servervariables("REFERER"), "http://www.FAKEdomainNOTREAL.com") then
dim sql, username, password
username = replace(replace(request.form("username"), "-", ""), ";", "")
password = replace(replace(request.form("password "), "-", ""), ";", "")
sql = "select count(*) as count from MYDATABASE where username = "' & _
username & '" and password = "' & password'"
connectiontodatabase.execute(sql)
end if
Problem solved with SERVERSIDE code... - haxx4, on 10/12/2007, -0/+3Doesn't doing an addslashes() on any user input prevent this?
- coding, on 10/12/2007, -0/+3Every query I've written in the past 5 years has been parameterized. Just saying.
- merreborn, on 10/12/2007, -0/+3Mysql is just as vulnerable to injection as any other SQL server. It's true that php's mysql_*() functions only allow one query per call, but that's not true for mysqli_*().
Additionally, there's always UNION, which you can use to execute 2 SELECTs in a single query. Lastly, for the exact exploit shown in this video, you don't need stacked queries at all. - aoeu, on 10/12/2007, -0/+3It does, and very simply by escaping the quotes and makes jumping out of the string impossible.
Plus a simple "wrong password" message is, IMO, much nicer than a Error 400 - Bad Request.
Quotes and "=" are both useful characters in a password, but such a third party utility that the video's author was using, forbids it. - Kickboy, on 10/12/2007, -0/+3PHP has the useful "mysql_real_escape_string()" function that protects against this. I use it on all my input strings (GET and POST), as well as forming my MySQL queries properly to prevent SQL injection. For header values I know are going to be integers (such as ID #'s), I use PHP's intval() function. Just doing these two things protects you against 95% of SQL vulnerabilities. There's no need to install special "firewall" software like this article suggests, just good common sense coding.
- xeeton, on 10/12/2007, -0/+2You can't do stacked queries in MySQL can you? (Not that they're using MySQL.)
- Rickard, on 10/12/2007, -0/+2Or since we're talking ASP, we could do it right and use SQL parameters. Also, what's up with testing HTTP_REFERER? You can never rely on that header. The client can set it to whatever it wants.
Edit: GAH! The correct reply button is impossible to find. Please fix this. - frozendice, on 10/12/2007, -1/+3my oh my. This is why you either make or get a sanitation script and just include it into every php document that has a form. It prevents all kinds of mischif.
- rideagain, on 10/12/2007, -0/+2dugdig, an outsourcing gig had the exact same idea. You can read the whole sorry tale there:
http://thedailywtf.com/forums/thread/73098.aspx - merreborn, on 10/12/2007, -0/+2"There are still developers out there dumb enough to be vulerable to this kind of thing?"
Yeah. I was the guy in my office that had to break the news on SQL injection to everyone. Including to my boss, who used to be our company's sole dev.
There are a lot of naive developers out there. - buss, on 10/12/2007, -0/+2Seriously, that exploit wouldn't exist if they encrypted what was in the password field before querying the sql server. Then no plain-text commands could be passed. That being said...what about putting ' or 1=1 -- into the username field?
Anyway, the way I do authentication is to query the database for the stored encrypted password associated with the username submitted. If the encrypted password that is returned doesn't match the encrypted text of the password field, then the login fails. Exploit solved. - justAMan, on 10/12/2007, -0/+1This is where platforms to build on come in handy. I don't want to get into a language war here, I'm sure this isn't specific to java, but something like tomcat or JBoss support standard user repositories like LDAP. Yes, LDAP injection is possible too, but much less severe (no updates) and the app servers tend to take that into account anyway. Let them do the authentication for you. You try and invent security yourself you will get taken down. Build on the work of others who have been doing this for years.
- bazbax, on 10/12/2007, -0/+1It's called bind variables. In Perl you would do something like this:
my $sth = $dbh->prepare("SELECT 1 WHERE username = ? AND password = ?");
$sth->execute($username, $password);
my $authenticated = $sth->fetchrow();
$sth->finish();
if ( !$authenticated ) {
die "Invalid username or password";
}
# do something useful now that they're logged in
By using bind variables all the escaping is handled for you. This is also much faster because it allows the database to cache the prepare'd queries for you.
Bind variables aren't just a Perl thing. They are allowed an any programming language that has a real database interface. - TresCoronas, on 10/12/2007, -1/+2attempted...and well...they were smart enough to at least change the coding...
- takeda, on 10/12/2007, -0/+1That PHP feature is a pain in the arse. It doesn't give 100% security, and just makes additional issues (try to use a backslash in the digg comments, you'll see). I would recommend to turn it off, and always use mysql_real_escape_string() (or other similar function if you use different DB). I also prefer using sprintf() to fill the fields in SQL query.
- Takteek, on 10/12/2007, -2/+3Hmm... I wonder if it was such a good idea to publish this in an easy step-by-step format...
- Guspaz, on 10/12/2007, -1/+2How are colleges hacked? Easy. My friend made a typo when typing in the URL to check his marks. He got a "page not found". So he backed up and hit backspace until the pagename was gone (so, http://college.com/mycollege/marks.htm became http://college.com/mycollege/).
He got a directory listing. With the java server pages (server side java) source code. He clicked on the source code. The administrator database passwords were at the beginning of the file. The internet-visible completely unprotected file. - dasil003, on 10/12/2007, -1/+2Of course it's not for the developer community, what bothers me is the overall amateurism of the article. I'm not going to nitpick about style or slight inaccuracies like the DROP TABLE thing. The real issue here is at the end. You refer to Javascript 'security' as bolt-on security when in fact it's basically a red herring because javascript is for user convenience only. It should be more clear that client-side validation is not in any way security.
Then you say that properly fixing the problem would require a 'complete rewrite' which is ridiculous. Worst case is you have to go through and patch each query in an application, best case is you just patch this one location by adding a line or two of code. There's no scenario requiring a 'complete rewrite' just to fix SQL injection.
Finally to put the icing on the cake you suggest "simply install an application firewall" and your troubles over, wheee! But that's complete *****. A firewall is not a magic bullet and can not anticipate all possible attack vectors. I can see a sophisticated app firewall as a nice addon, but it's no substitute for securing the application itself.
The bottom line is the website is half finished with dubious information presented poorly. You oughta be ashamed for whoring this out to Digg. If you want to build a business let me give you some advice: start networking. Build your business from client referrals. Digg is just not gonna do anything for you but invite more flames. - dasil003, on 10/12/2007, -0/+1So they just have to put the injection into the username instead? Security is not something to be solved by little clever hacks and tricks. It's not enough to say "oh, I know about this SQL injection attack now, let's put in a little patch just for that one!" If you want to make your app secure (and who doesn't), then you need to completely prevent all SQL injection attacks period, and the only way to do that is to make sure that all untrusted input is properly escaped. Preferably by some sort of query parameterization that makes the process transparent.
- securitymonkey, on 10/12/2007, -1/+2Another example at the bottom of this page: http://blogs.ittoolbox.com/security/investigator/archives/video-hacking-a-college-or-two-9525
- snoble, on 10/12/2007, -0/+1@fuzzycat
Think about the process and how this exploit works. The only way this exploit works is if you take whatever is posted in the password field and stick it right into the SQL query. So you have
WHERE PASSWORD = $password ...
But if you encrypted your passwords (or even better stored a one way hash) you would have in your query
WHERE PASSWORD = hashed($password) ...
Now think hard what happens here when someone injects '' AND 1=1
You end up sticking in
WHERE PASSWORD = hashed('' AND 1=1) ...
which won't return anything.
buss still does have a point about injecting into the the username, and he does authenticate in a nice way which is considerably safer. I personally prefer using a ldap server to authenticate against. Does that clarify things for you a bit? - dasil003, on 10/12/2007, -0/+1So 'or' is no longer allowed in passwords and SQL injection of any other type is still allowed, sounds like a pretty half-baked solution to me. Why not just use parameterization or addslashes and solve it properly.
- Daychilde, on 10/12/2007, -1/+2--> --> --> --> --> --> --> --> --> --> --> --> --> --> --> --> --> --> ^^^^^^^^^^^^^^
Okay. Fixed that for you. It that's not good enough, maybe you can find the "Contact Us" link at the bottom of this page............ :-P - dchesterton, on 10/12/2007, -0/+1The only advantage of MySql is that the latest versions of PHP which is most likely what you are using automatically escapes characters such as " or '. Or is it MySql that escapes them? I forget.
- ItsDrew, on 10/12/2007, -0/+1I think that the network administrators of this college should get some recognition here because they got an audit done prior to getting hacked and becoming yet another statistic like every other stinking college out there that you read about in the news.
My alma mater got hacked into and I'm pretty hot about the whole topic. Adding insult to injury is to see how easy the exploit was. Now I have to worry about identity theft, but only as long as my social security number remains valid... - jrhelgeson, on 10/12/2007, -0/+1I'm just trying to raise awareness of these issues. Yes, I know that I glossed over some details but I am not targeting web developers here, as I have already stated. Web developers are getting push back from management to get code cranked out quick, yet they have a tough time showing the "pointy haired boss" why they need to develop secure applications.
I'm NOT trying to build a business by whoring it out to digg. It was requested that I make these video's available to a larger audience... so I did, and it appears to have worked. So, next time you're told to crank out insecure code, or you're faced with someone who doesn't understand the vulnerabilities, show them the video.
Yes, I do recommend either rewriting the site, or installing an application firewall - either of which I could help with, however, the application firewall *actually works*... It's pretty amazing if you ask me. - usuk, on 10/12/2007, -1/+2Of course this isn't meant for coders/programmer types - they already know FAR more than this on the subject (unless they're still students or something). I'd expect them to be able to make their own app firewall themselves or at least come up with pretty good and secure solutions, and be able to discuss this quite into detail...
This is not quite "not for developers", this is so ridiculously basic it's insulting anyone's intelligence. It may sound harsh, but it is. Not writing for people who already know about this isn't a justification for 100% wrong contents into an article (again, the "drop table" bit - which looks like the mistake of a n00b trying to write an article on a subject he hasn't quite understood yet) - not something that'll make me want to buy whatever product you're selling against this! (the "real security experts" bit at the top made me laugh - I don't think you guys are even remnotely CLOSE to experts on that subject matter)
Not only it doesn't show 5% of the very basics (no getting infos about the schema or data anything interesting which would show how much can be done), nor has real solutions offered, nor common/well established industry best practices mentionned (server side validation/sanitization, parameterized queries/sprocs, escaping...), but it doesn't even address other important points like hashing (let alone salted hashes - against dictionnary attacks) - nobody should have unencrypted/plaintext passwords in a DB - even moreso if it's exposed to the internet... Not even a mention of XSS either.
Anyone who knows the very basics of SQL (and it's quite simple really, we're not talking about index/sproc tuning here or anything like that) would understand FAR more than this... As long as you show the resulting SQL query they'd understand what would happen.
It comes across as something meant to scare you about being hacked (only very very very bad and insecure code is really that vulnerable and easy to exploit), so people go buy some app firewalls which they truly don't need. There is a market for those (I use 'em), but the n00bs aren't that target market, no point in scaring them like that... Fixing their existing codebase and knowing how to write proper and secure code is what matters at this point.
Sorry, but no digg. - vearl, on 10/12/2007, -0/+0This would completely not work if you reverse the sql statement.. Where password= passwordfield.value and username=emailfield.value
that's why I always have done the password first and then username - FuzzyCat, on 10/12/2007, -1/+1
This has nothing to do with how passwords are stored at all. It's an (old) exploit which bypasses the requirement for knowing a password. It's effectively saying
If password='' or 1=1
which would always be true. It doesn't matter how the password is stored. - webaugur, on 10/12/2007, -0/+0This is an extremely common mistake many inexperienced/undereducated programmers make. One should never pass unvalidated user-provided strings directly into your SQL queries...
One way to make absolutely sure your authentication SQL is safe is to hash the input values in the script language and the resultsets on the server to make sure any unsafe characters are scrubbed. Here's a MySQL and PHP example:
$result = mysql_query( 'SELECT * FROM users WHERE MD5(username) = '.md5($username).' AND MD5(password) = '.md5($password) );
if( mysql_num_rows($result) == 1) {
print("User is authorized. Now go do something useful.");
} - FuzzyCat, on 10/12/2007, -1/+1@buss
My reply isn't to your reply it is to snoble's. - FuzzyCat, on 10/12/2007, -1/+1@snoble
Ok, my bad - I misunderstood what you were getting at. - sensor, on 10/12/2007, -1/+1Those videos are total *****. They are selling a ***** "product".
- jrhelgeson, on 10/12/2007, -0/+0It actually DOES "Know" if a parameter has been altered. The application firewall does this by watching all the data that goes out, generating a hash on all the values.. then comparing the hashed values upon receipt.. if the hash doesn't match, then its invalid...
- nessup, on 10/12/2007, -1/+1"While this may be 1-2-3 for web application programmers, it is quite revealing for those not involved with web application security on a daily basis."
So true. App programmers like myself forget to further validate input upon querying the database. Stuff like that leads to huge mistakes and it's disappointing that none of that was ever brought up in the MySQL for C chapter. - buss, on 10/12/2007, -1/+1Yes, it would always be true if you just submit the text of the password field to the sql server. But you aren't understanding what I'm saying. Take the username submitted and query the database for the password that is stored. Then use another language (in my case, php) to compare the (encrypted) password that was returned with the (encrypted) text in the password box from the login page. If they match, then it was a valid login. That way, you can avoid the exploit entirely.
- jrhelgeson, on 10/12/2007, -0/+0You could just as easily type ' or 1=1 or ' for the username, or if the email address is the username type:
foo@bar.com' or 1=1 or '
as the username, or you could put the email after, or put the whole string into the password field. - soda0289, on 10/12/2007, -12/+12I hacked my school website like this. It's amazing how people just ignore the risk of an SQL injection.
- snoble, on 10/12/2007, -1/+1I'm sorry, but does anyone actually use custom authentication against a SQL database in plain text? I mean if you aren't going to use a dedicated authentication server (which why wouldn't you) who's storing their passwords in plain text as well. Hell, even rot47 would solve this.
- TestFar, on 10/12/2007, -2/+1argh, if you can't get enough attention on Full-disclosure, put it on digg...
;) -
Show 51 - 54 of 54 discussions
Browsing Digg on your phone just got easier with our enhancements to the 
© Digg Inc. 2009
— Content created and posted by Digg users is