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."
A bad workman blames his tools (Score:5, Insightful)
No. (Score:5, Insightful)
Essentially, the problem is with those making insecure scripts, not the whole PHP and SQL system.
Ease of introduction (Score:5, Insightful)
Re:A bad workman blames his tools (Score:2, Insightful)
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 (Score:5, Insightful)
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:No. (Score:3, Insightful)
PHP is as secure as you make it (Score:4, Insightful)
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
http://uberhacker.com/cgi-bin/index.php?page=fl
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:Ease of introduction (Score:2, Insightful)
PHP/MySQL will be considered secure once XAML and Avalon [ximian.com] 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 [jaxn.org]
Re:No. (Score:5, Insightful)
Security comes from simplicity, not complexity. And security should start at the DBMS level, not be left to applications.
C'mon, Drop the FUD (Score:5, Insightful)
Re:A bad workman blames his tools (Score:3, Insightful)
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:"more weak"? (Score:0, Insightful)
Re:Blame should be shared between coder and langua (Score:3, Insightful)
They're called stored procedures. They've existed for at least 20 years.
Bind variables (Score:3, Insightful)
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 (Score:3, Insightful)
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 (Score:1, Insightful)
Re:PHP is as secure as you make it (Score:3, Insightful)
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 (Score:2, Insightful)
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
Walked Right Into That (Score:3, Insightful)
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 (Score:5, Insightful)
This is not an issue dealing with PHP and MySQL, this is an issue with weak programmers writing bad code [phpnuke.org], and I'm sorry to say, you find it in every language. As a regular in #php [hashphp.org] on freenode [freenode.net], 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 [php.net], 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 [php.net] 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 [xchat.org] and ASK US (irc://irc.freenode.net). We're there to help!
-Good- Sites (Score:2, Insightful)
Very weak article (Score:1, Insightful)
Next article will be.
"PHP has weak performance because it can be slashdotted."
Re:No. (Score:4, Insightful)
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:Nope (Score:1, Insightful)
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.
"fuzzy developing" (Score:5, Insightful)
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? (Score:2, Insightful)
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:No. (Score:5, Insightful)
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.
Re:A bad workman blames his tools (Score:3, Insightful)
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!
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:
Re: cutting off an arm (Score:5, Insightful)
> 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...