PHP and SQL Security

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."

Comments

A bad workman blames his tools

[dorward]

Looks more like "Scripts people write using PHP and SQL without understanding security issues are being proven more weak every day." to me.

Re:A bad workman blames his tools

[sv25]

"Scripts people write using PHP and SQL without understanding security issues are being proven more weak every day."

That is stating the obvious, but none the less - it must be said. Nealry every language/backend is a potential threat when developers who don't have an understanding or awareness of security start coding.

Re:A bad workman blames his tools

[quigonn]

Well, sometimes you can simply blame the tools. Or would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?

The same is valid for programming languages, with some it's just easier to shoot yourself in the foot when you make a mistake. One example are buffer overflows and C: it's so easy to mistakenly write code that produces one, while in other languages like Ada or Perl it's virtually impossible.

The same goes for PHP and SQL, which is shown everyday on the usual mailing lists like Bugtraq or full-disclosure.

Re:A bad workman blames his tools

[dorward]

Would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?

I would if he ignored the instructions telling him to protect himself before using it after hearing the horror stories from the large collection of one armed men (watch out Dr Richard Kimble) in the building!

Re:A bad workman blames his tools

[slamb]

No, you are missing the point. magic_quotes_gpc is a handy safe-guard for newbies, most of whom will be using MySQL. The downside is some errant slashes that may be annoying, but are far less dangerous.

So you're saying it's a language feature aimed at helping newbies producing mediocre code.

magic_quotes_gpc is dangerous, in that it confuses said newbies horribly about a critical issue. They may be producing mediocre code where they would have been producing bad code, but it will lengthen the time until they learn to produce good code. Or maybe prevent them from ever doing so!

• When newbies see words like "magic quotes", they may think "okay, everything's quoted and safe". When it's not nearly so simple.
• A feature intended to help people mix untrusted data into SQL statements suggests that it is a good practice to do so. It's not! It's much better to use bind variables.
• It increases the operating modes a program executes in. Take a look at this bit from the get_magic_quotes_gpc section of the manual:

  if (!get_magic_quotes_gpc()) {
  $lastname = addslashes($_POST['lastname']);
  } else {
  $lastname = $_POST['lastname'];
  }

  They're promoting the idea of having the same program work in both modes. Do you think people extensively test both? It would be much better to say "loudly fail if your program is not run in the expected mode". Hell, they're not even doing this in a general function; they're proposing doing that for each variable reference! That's stupid! People will inevitably write code that works in one mode or the other. Seeing this pattern elsewhere in the code will falsely lead people to believe the entire thing works in both modes.
• With this "safety" feature on, truly safe code would be much more complicated than without, and this is never stated in the manual. The correct way before was to "escape stuff in way X right as you use it in way X". Now it needs an addendum: "except if it's from a GET/POST string and it's to a MySQL or PostgreSQL database literal. and when you use GET/POST strings for anything else, strip off the slashes first." That's complicated enough that a newbie may never learn the correct way of doing things in any mode. They'll always think it is too complicated to really understand, always be tinkering, and always screw it up.
• it makes people have some data floating around that should be treated quite differently depending on where they got it. If they get it from the database, it's not escaped in a similar way. Do you think they'll keep rigorously keep track of every string being passed around and state and follow a contract for how each function's arguments should be quoted? (And yes, there are valid reasons for getting something from the database and sending it right back.)

By the way, you mentioned stripslashes. I'd argue that any use of stripslashes means that you've screwed up and escaped something badly. If something has slashes, it's intended to be parsed through a layer that mixes strings and some higher-level construct. So when you strip them out, either:

• you're writing a parser that doesn't know the length of the string until it's done. It'll be appending to the string as it goes. stripslashes doesn't help.
• you've got something escaped in the style to send it through a layer you actually aren't using. You're escaping something at the wrong place in your code. If you haven't already screwed it up and introduced a security problem, you soon will, because your function's contracts are too confusing.

No.

[mfh]

PHP and MySQL are not weak; faux programmers are weak. Purification of incoming data is essential, and often ignored by novice script-writers, and that's the problem. SQL injections are common among novice coders, and they can slip past even competent coders, but a strict design engine for passing SQL vars using $_REQUEST, and turning off register_globals, will result in better results.

Essentially, the problem is with those making insecure scripts, not the whole PHP and SQL system.

Re:No.

[Richthofen80]

Seriously, I agree. Object oriented programming should prevent this, too. Develop object models then take the request variables and insert them into the objects before inserting them into SQL. Constructors should parse special characters that could lead to injection. Also, it is easier to implement business rules using OOP. Seriously, even interpreted languages do OO now, its time we all used them.

Re:No.

[leandrod]

> Object oriented programming should prevent this

Security comes from simplicity, not complexity. And security should start at the DBMS level, not be left to applications.

Re:No.

[noda132]

what blows my mind is those that use the DB column name in a webform to be passed.

Along the same vein: I cannot count the number of scripts I've seen which use <select> tags and simply assume in the processing script that the only possible values are those which were given in <option> tags. Ditto for text inputs with a maxlength.

It all stems from a complete ignorance of the specs, or a bunch of reading-between-the-lines which is utterly stupid. Nowhere in the HTML spec does it say that the page referenced in a form action will always be requested with valid input.

The other thing which irritates me is how so many people assume using mysql_ functions is the best way to talk with a database. The PEAR project has had a fully-functional, object-oriented database package for years which handles escaping all by itself. It also makes INSERT/UPDATE queries much easier to write with its auto-queries.

In my opinion, this is the tutorials' fault. But it's kind of the same with any language, I suppose: everybody learns C with the standard library and with fixed-length char[] arrays, without learning all the pitfalls (i.e., buffer overflows) and other libraries (i.e., glib) which work around them.

Proper layering and abstraction should be a primary focus of any intro-to-programming class or tutorial.

Re:No.

[Frizzle Fry]

Constructors should parse special characters that could lead to injection.

No! No, no, no. You don't look for characters that "could lead to injection" and block (or escape) them, you look for input patterns that you know to be safe (ones that can't lead to injection) and only allow those. Trying to guess every possible input that can cause problems is not a good security practice. Please reread Writing Secure Code.

Ease of introduction

[holzp]

I think a lot of the blame for this can be traced to the ease of getting started with PHP/MySQL. Result: more people learning how to program with php will of course result in less thought about security. Add the ability to have input arguments via the http request be automagically available to the running code shares a lot of the blame too. Put them togeather and thats a disaster.

Re:Ease of introduction

[TekZen]

Good point.
PHP/MySQL will be considered secure once XAML and Avalon are released to the world. That will be the new "insecure platform" on slashdot. Not be cause PHP is inherently insecure now and XAML and Avalon will be more insecure, but rather because PHP is the easiest entry into programming and XAML will lower the bar.
-Jackson

PHP is as secure as you make it

[kyndig]

Your scripts are only as secured as you make them. What this "UBERHACK" website is simply doing is sending a flock of young script junkies out to locate sites which have not implemented a good code structure.

PHP documentation clearly states the pitfalls of using variables in a global scope. It is for this reason that PHP changed its GLOBAL array structure to read $_POST and $_GET methods, as well as default setting register_globals to off.

I find it a poor use of a developers time to attempt to see whose site they can deface. It is imoral and shows a lack of respect for those whom put countless hours into their site development.

I would challenge "UBERHACKER" to spend more time developing their website which is showing to be in poor syntatical use of HTML, slow loading and poor in URL design. Why run a php scritp in a /cgi-bin/ do you feel more secure by doing so? The ScriptAlias which you most probably have set for this directory will in no way prevent malicious intent from remote connections if your php is not properly configured for base_directories, register_globals, and safe_mode.

http://uberhacker.com/cgi-bin/index.php?page=fla b
Pick up any book on programming and learn proper developmental tactics ( Throw / Catch ) before promoting the attack of others because your 'Uber' site thinks it can't be Hax0r3d.

End Rant.

Re:PHP is as secure as you make it

[CaptainTux]

Those who put countless hours into site development and yet leave it easily hacked are not deserving of our respect!

Last time I checked, PERSONAL morals and ethics weren't defined by the actions of others or whether you "respected" someone or not. You're either moral or not. Nobody can "earn" your morality.

Re:PHP is as secure as you make it

[kyndig]

There is a responsible aproach, and an irresponsable aproach. The responsible thing to do is if you are reviewing code, or a website and locate a falacy which could be considered a security concern; you notify the individual or group.

What this site is promoting is the Defacement of a website. They further go to provide script security tips which have no relevance in any way to good program practices. Quite frankly, I am suprised this topic made it to /. It apears to be nothing more than an advertisement for a poorly designed and thought out website.

C'mon, Drop the FUD

[da3dAlus]

There is no trully unsecure language, only programmers that practice building unsecure sites. Bugs and security holes can always be patched, but if the site is crap to begin with, then that's just asking for trouble. You should always check user input, esp if you plan to use said input as part of a SQL query or entry. Duh.

Re:"more weak"?

[Anonymous Coward]

Writing on Slashdot seems to getting more worser every day!

Re:Blame should be shared between coder and langua

[NineNine]

I am often amazed that more people aren't working towards programatic ways to express SQL queries and/or regular expressions

They're called stored procedures. They've existed for at least 20 years.

Bind variables

[ArsenneLupin]

Actually, bind variables help much more than object oriented programming.

Writing al=execute_query("SELECT access_level FROM user WHERE user=? AND password=?", user, password) is naturally so much more secure than al=execute_query("SELECT access_level FROM user WHERE user='"+user+"' AND password='"+password+"'");

Nowadays, most database products worth their salt (Oracle, Postgresql, and even my Mysql!) support bind variables. And even if you have an old version of Mysql (which doesn't support them), Perl DBI and Php PEAR can emulate bind variables for you.

Of course, if you're stuck with ASP and Sequel Sewer, you're somewhat out of luck, and need to do the proper quote escaping yourself.

MySQL is not SQL

[leandrod]

When will /. stop posting misinformation?

SQL is a language, defined by ISO. MySQL is not SQL-compliant. Not even Oracle is. IBM DB2, PostgreSQL are SQL compliant, and a lot better than MySQL too. PostgreSQL is even faster and simpler.

Re:No. Mod Parent Up

[Anonymous Coward]

This is exactly right. GET, POST, or COOKIE data? It's all equally dangerous. Anybody have firefox and the web developer extension? Try displaying form details and change some post inputs. Or just use javascript in the url to alter the form at will.

Walked Right Into That

[mfh]

> If you're going to make that argument (which, BTW, I think is accurate), then you'd better be prepared to say that Windows isn't inherantly insecure as well.

No, not really. If you're arguing that Windows isn't insecure (which is slightly off-topic) I would have to disagree. The security flaws in Windows are due to over-complication of a proprietary system, leading to gaping holes that keep springing up on a systemic level; these holes are compounded by closed source, financial rationale (lacking in motivation for corrections) and corporate belligerence on a systemic level. Fewer eyes have seen Windows source code than PHP source code, and those that have are swimming from confusing and conflicting design models.

Windows is insecure because the people involved are xenophobic. Plus PHP isn't an operating system, so we're really talking about penguins, apples and windows.

Nope

[kuzb]

This is not an issue dealing with PHP and MySQL, this is an issue with weak programmers writing bad code, and I'm sorry to say, you find it in every language. As a regular in #php on freenode, we are constantly correcting bad coding practices.

In fact, it's not uncommon to find people using GET and POST variables straight out of the box without any kind of validation whatsoever. Many people do not learn the de-facto first rule of web programming: the user can not, and should never be trusted.

To make matters worse, applications like PHP-Nuke spring up which are notorious for sloppy coding practices, and people tend to see them as reflect on the PHP community as a whole. That's like blaming the C language because someone, one day, wrote some bad code in it that got someone else hacked. This happens all the time, but we don't make claims like "C security is weak". Instead, we worry about the truth of it, that the programmer in question did a bad job, or just flat out missed something.

One of the key points that seems to trip most novices up (and granted, this is one of the stupider moves presented by the PHP Core Development team) was a thing called magic_quotes_gpc, which attempts to auto-escape incoming GET, POST and COOKIE variables in an attempt to sanitize user input. This is usually a double-edge sword because newbies are typicly not aware if it is, or isn't on. In later versions, this is on by default, and does prevent many SQL injections from occuring. However, for the more experienced user, having your input auto-munged can be something of a pain. Unfortunatly, to write truely portable code one must test this value and normalize data accordingly.

The issues don't stop there though. I've seen many a more serious faux pas committed by the newbie. Another more serious flaw that I see happen on a regular basis is the use of user data within include statements without proper path checking. This is probably one of the more disasterous errors I see occuring because it typicly exposes sensitive data. There has been more than one occasion where i've shown a user their own passwd file in a browser to make my point.

Anyhow, to the newbies: we, the more experienced people of PHP are on our own quest to educate people, many times in a one-on-one basis on Freenode. If you're not sure about a particular issue, grab an IRC client and ASK US (irc://irc.freenode.net). We're there to help!

Re:Nope

[Anonymous Coward]

> but we don't make claims like "C security is weak"

That's just plain wrong for the majority. Every time there's a Java or a secure language topic comes up, there are just too many flaming C because of its "security" - lack of magic behind the scenes like garbage collection, etc. The typical rants are hardware costs are insignificant to programmers' costs, and efficiency isn't worth security because hardware is too cheap. The typical solution given is to dump hardware at security, and pick a "secure" language.

-Good- Sites

[Talian]

Anyone have suggestions for a bit more uh, quality sites on the topics? Seen plenty of coding sites, but none particular to security of this combo.

Very weak article

[GetPFunky]

The point of this article is based upon the misconception that writing secure applications should be done for you.

Next article will be.
"PHP has weak performance because it can be slashdotted."

"fuzzy developing"

[mabu]

Interesting topic, but I don't think the problem lies with PHP or MySQL. You can create insecure apps in any development environment. Yes, some are more problem-prone than others, but I'd rank Perl much higher than PHP/MySQL in terms of being conducive to allowing vulnerabilities.

I attribute much of this problem to something I call "fuzzy developing". It's the latest trend. The crux of this problem involves Web designers, who know very little about programming who are deploying more and more complicated applications in a cut-and-paste manner. These fuzzy developers have no concept of proper programming skills. Many of them can't program at all, but they can snarf someone else's "free" code online, change a few config parameters, whine to an admin for access, and compromise entire servers.

This new breed of developer relies on existing code, following the fallacy that if it's on the net, it must work. They use sites like experts-exchange to get other people to code for them when they get in a snag, and don't contemplate the priorities involved when you put something on a public system.

new security holes every DAY, huh?

[panic911]

PHP and SQL Security are being proven more weak every day.

Where does this guy get his facts? Tell me, what exactly is insecure about SQL or PHP? If you know what you're doing and write your scripts to prevent any SQL injections and you set adequite permissions on the database, you're not going to have any problems (assuming there isn't some huge flaw in the database server, itself).

By the way, I don't trust anyone who puts up a research project in Comic font. What is this guy, a 12 year old boy, or a 60 year old grandma? Either way, it's ugly and a Windows-specific font and I don't trust one word this llama says.

One more rant - he doesn't talk about SQL in general, he talks about MySQL. There is a difference.

(OK, I'll stop being a troll now :)

Re: cutting off an arm

[kpharmer]

>>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

Yeah, that's pretty much the line of the discredited 19th century factory-owners. They all insisted that worker injureries were due to carelessness on the part of the worker. Then people began to noticed that eventually almost all workers became completely disabled. About that time folks began to realize that a tool that requires you to be perfect 100% of the time is a flawed tool. Or a self-mutilation device, you pick.

And the same arguement keeps resurfacing, btw. Not just among factory owners trying to preserve maximum profitability. But also amoung techies trying to defend crappy products:
- RTFM
- can't get a printer to work with cups? must be a newbie
blah, blah, blah

Then in the late 90s Usability and Information Architecture really took off. These guys saw a a few patterns:
- the jack-assed argument that difficulty with a tool was the user's fault - resulted in lost users, lost sales, lost revenue. Those who insisted on blaming the workman rather than the tool - thankfully went out of business.
- usability challenges also caused security vulnerabilities - when users couldn't figure out how to secure a device it became a liability to everyone. So, in this case the tool harmed the entire community not just one workman.

The only interesting thing in the above comment is that you actually got modded-up for repeating a completely discredited notion. Sigh, probably just a clever troll and I fell for it...