PHP and SQL Security 305
An anonymous reader writes "PHP and SQL
Security are being proven more weak every day. Uberhacker.Com is running a PHP
and SQL security research
project to raise awareness of secure scripting. The site hosts guides
to secure PHP programming, forums, and scripting
challenges to see who can create the most secure scripts."
Re:I can't take a security sight seriously that... (Score:4, Interesting)
and to boot are they running php as a CGI instead of a module?
*shrug*
e.
Re: cutting off an arm (Score:5, Interesting)
Or would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?
Yes, I would: he was obviously doing something with the saw that was inappropriate; what saw-oriented task [when done correctly] involves waving it at one's own arm?* The fact that the blade was unprotected is irrelevant since he should have known it was unprotected and therefore dangerous. All tools can be used stupidly, and oddly enough the results really can be the fault of the operator. It is also possible for fault to lie in more than one area.
Yes, I know the traditional definition of 'hacking' includes making $ITEM do something it was not intended to do, but there are limits.
* I'm guessing that 'buzz-saw' == 'circular saw'.
This business will ALWAYS have amateurs (Score:2, Interesting)
Crap site (Score:3, Interesting)
That being said, I used to write a lot of PHP (I rarely do it anymore at work, but I still try to keep up with the language) and when I first started out I would have loved a comprehensive and easy-to-understand guide to common security holes. The world needs a simple "how to write security-conscious code" for beginners! The sooner you get to see stuff like SQL injection or XSS in action, the better.
Input verification (Score:3, Interesting)
So far the most "unsafe" aspect with PHP / SQL setups is poor input validation;
If you allow direct writing to your SQL and don't do sufficient checks on the input, well.. you'll get in probs with that.
Proof of concept;
Hello.. enter your email for free porn: sucker@hotmail.com '; DROP TABLE 'emails';
Or you have those pages who mess up or display info which can be abused (and / or shouldn't be on that particular page) after there's a "<blockquote>" injected and redisplayed without checking..
Same with <input type=text>
Then.. there's JS, and htmlentities, and, and..
All caffeine intense, and headache inducing subjects you should keep in mind if you plan on bringing something on wire.
"Nah.. you don't have to do that.. Who's going to know how to do that?"
"Trust me.. You want me to put in that extra code.."
"If you really say so.."
You also have stupid defaults, and uninspired [google.com] coding which gets abused, ofcourse...
I actually like the PHP / SQL combination and believe it to be safe enough for what I do with it.
Not sure if this is news (Score:5, Interesting)
Some of my favorite things I see _ALL_ the time:
Something bad happens while executing the code?
Let's <? die("here's my database connection info in case you wanted it"); ?>
Then there was the client who's previous developer was some moron who stored the database connection info into a
The web "design" group who's MySQL database was wide open without authorizing with a password.
The arsehole developers who built themselves little backdoor webpages during development to exec shell commands and upload/exec files
I've seen about 3 websites store credit card numbers unencrypted into a MySQL database.
I could go on and on and on, being a development gun for hire since 98, I've seen some things that defy all logic and explanation. In fact, I still wonder why they call it Computer Science. Now, Computational Arts I could buy into.
Re:magic_quotes (Score:3, Interesting)
at least with PEAR::DB now, i can finally do:
$db->query(select * from foo where a = ?", $a)
and not worry about it- the way it should have been all along.
theory vs practice (Score:3, Interesting)
aha
Well, rather than debate whether or not the data should be persisted in the context of its rules and actions (which doesn't work in reporting, btw), lets get down to what simply works.
You need to plan on including security awareness within each layer and component of your architecture. Since we've moved beyond client-server we seldom now authenticate & authorize individual users in the database. That's fine, but locking down the data should still be done in any database, even if the granularity is now at the application level rather than the individual.
The difference between today and ten years ago is that we're now mostly implementing database security at the application level of granularity.
Here's a trivial example:
- 20 users are in ldap group finance
- all are also in ldap group report
- 10 are also in ldap group invoice
- 4 userids are used by the database:
- userid invoice has ownership privs on invoice schema
- userid gl has ownership privs on general ledger schema
- userid fa has ownership privs on fixed-asset schema
- userid report has read privs on above schemas
- The invoice application will authenticate users via ldap service
- The invoice application will use ldap service to authorize users using either report or invoice group depending on what the user attempts to do
- The application(s) will connect to the database using either appropriate database userid. This will be used by database to ensure that invoice application does not attempt to write to general-ledger schema, etc.
This isn't the end of your security concerns in the database. You've also got to lock down all your file systems, ensure that no users can create new database objects, etc, etc. That's also fairly straight-forward.
Anyhow, don't get all hung up about where security must go - or in the interests of some kind of misguided purity you'll end up leaving giant gaping holes in your defenses. Implementing security at the application level of granularity is both simple and effective. Take advantage of it.
Re:Bind variables (Score:2, Interesting)
I don't doubt there may be more examples of bad ASP in the wild, but that has more to do with developer skills than anything else. PHP developers as a whole are probably more skilled than their MS counterparts. That's not the fault of the language though, and it's certainly not the fault of the RDBMS. ASP against any other database server would be just as bad.
Why do you hate SQL Server so much?
Here's an example of "Bind variables" courtesy of MS. Not what I'd call hard, but it is a little more involved than your example above. JSP does it in much the same way.
Dim cn As New ADODB.Connection
Dim cmdPrep1 As New ADODB.Command
Dim prm1 As New ADODB.Parameter
Dim prm2 As New ADODB.Parameter
Dim strCn As String
strCn = "Server=MyServerName;Database=pubs;Trusted_Connec
cn.Provider = "sqloledb"
cn.Open strCn
Set cmdPrep1.ActiveConnection = cn
cmdPrep1.CommandText = "UPDATE titles SET type=? WHERE title_id =?"
cmdPrep1.CommandType = adCmdText
cmdPrep1.Prepared = True
Set prm1 = cmdPrep1.CreateParameter("Type", adChar, adParamInput, 12, "New Bus")
cmdPrep1.Parameters.Append prm1
Set prm2 = cmdPrep1.CreateParameter("ProductID", adInteger, adParamInput, 4, 3)
cmdPrep1.Parameters.Append prm2
cmdPrep1.Execute
cn.Close