Slashdot Mirror

Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.

This is my main beef with PHP. They have their head in the sand with regards to server configuration.

Case in point: the company I work for sells PHP-based service center and reservations systems to large companies. These companies generally have windows-based server infrastructures, so we have to deploy on windows/IIS. If you look at the suggested configuration for PHP on IIS in the PHP manual, you'll find this page, which explains regular CGI and ISAPI (multi-threaded) configurations. What the manual doesn't tell you is that neither of these configurations actually work in production environments. Regular CGI configurations are too slow (on windows), and ISAPI is too unreliable (customers that deployed with ISAPI configurations suffered daily server hangs).

The only viable configuration for production IIS servers, as it turns out, is FastCGI, which is not documented in PHP's manual section on IIS configuration. Their documentation actively misinforms people on how to configure PHP. That's bad.

I tested it last night on a Win2003 Server box, and there is a missing file from the Win32 ZIP distribution: php_xmlrpc.dll.

http://bugs.php.net/bug.php?id=41292

The file can be obtained from the latest snapshot, though: http://snaps.php.net/

I tested it last night on a Win2003 Server box, and there is a missing file from the Win32 ZIP distribution: php_xmlrpc.dll.

http://bugs.php.net/bug.php?id=41292

The file can be obtained from the latest snapshot, though: http://snaps.php.net/

The PHP Documentation Team is always looking for contributors. For an easy start, you could help by documenting undocumented functions, for example..

Get laptop and connect to internet: working over crappy DSL line, 2Mb top speed 8( run ssh to get to a suse server I had installed earlier in the week for the project, (the server was also running some other services so could not be restarted during the working day)

Same on the windows side, even a crappy dsl line is more than enough to support RDP, which works pretty cleanly over dial-up, once it caches any bitmaps you might encounter.

Use Yast to install apache and php requiremements from up-to-date suse internet repository.

Use Add/Remove Programs to install IIS and WWW on windows. Due to the way windows is setup, as long as your base OS is patched, then your IIS/WWW is already patched. So that was easy.

(and although you dont need the install media to install IIS on an installed server, if you dont have install media on your network or on the server, then you're not doing a good job of setting up your environment. alternatively, you can just use the RAC/ILO on the server to remote mount the CD or an ISO. Whatever works best for you.)

Use vi to edit the apache config to create virtual server.

Use IIS Admin to do this, or use the command line tool, or modify the metabase.xml directly. Whichever way is more comfortable for you, there are lots of options.

To install PHP, take 30 seconds and read this:
http://www.php.net/manual/en/install.windows.php#i nstall.windows.installer.msi

Use rsync to copy the php application to the server. (for windows users, rsync is a little like FTP, but over an ssh connection, and can easily replicate a full folder structure)

Use XCOPY to copy the php application to the server. (for unix users, XCOPY is a little like rsync, but will run over any CIFS connection (including an RDP connection), and can easily replicate a full folder structure)

Test, debug, then secure access to only http, https and ssh. Approx 4 hrs for the whole job.

Test, debug, then secure access to only http, https, and rdp from inside the network (ie, requires vpn).

Compare that to what you wrote:

To do the same thing in Windows - Take Previously installed Windows 2K3 server, enable remote desktop access, oh hang on, that wasn't done initially so will have to call someone at the office to do it for me,

Why didnt you do it right the first time?

Oh, and have to install whole citrix gateway infrastructure to support secure encrypted remote access.

I have no idea what you're talking about here. The SOP way to do this is to VPN into your protected network and RDP from there.

Add software - IIS, hang on, no network repository for i386 directory, get someone at the office to stick in a CD, then restart.

Why dont you have a network repository for i386? Thats SOP for this kind of environment when done by competent admins. CD? And why would you restart? You dont need to restart after installing IIS.

And I'm about 80% sure that you dont need the CD or media at all to install IIS on a box that is already installed and setup.

Add php services to IIS - umm, haven't done that before so I don't know how hard it is to do.

Go to php.net, download the msi, run it. Yawn.

Here's the link to make it easier:

There are frameworks for session management which will fall-back to URL session-ids if cookies fail. They're just as easy to work with as cookies.

Yeah, and it's usually recommended to avoid using them, because of the added risk in including sensitive information in the querystring. I am a huge fan of graceful degradation, but IMHO it's not "graceful" to degrade from cookie-based session management to URL-based session management for that reason.

From PHP session documentation:

URL based session management has additional security risks compared to cookie based session management. Users may send a URL that contains an active session ID to their friends by email or users may save a URL that contains a session ID to their bookmarks and access your site with the same session ID always, for example.

Maybe I'm just oblivious, but isn't that what PDO is included for?

Check out the PEAR project's solution. http://pear.php.net/package/MDB2. The code at PEAR is normally high caliber and will make your own PHP code much more robust.

Does this IDE just use the normal PHP interpreter available from http://www.php.net/ or did Borland/CodeGear write their own PHP implementation?

As another user stated, CGI is a specification. One that PHP uses if it's compiled as a CGI binary or emulates if it's installed as a web server module. $_SERVER, for instance, is populated mostly with CGI Environment variables. $_GET is a processed version of the CGI QUERY_STRING variable. $_COOKIE is a processed version of the the CGI $COOKIE (and possibly $COOKIE2) variables. The $_FILES array is filled with the parts of a multipart/form-data input that have a filename= section. This comes from a POSTed form (which uses STDIN as per the HTML and CGI specs).

Need I go on?

As another user stated, CGI is a specification. One that PHP uses if it's compiled as a CGI binary or emulates if it's installed as a web server module. $_SERVER, for instance, is populated mostly with CGI Environment variables. $_GET is a processed version of the CGI QUERY_STRING variable. $_COOKIE is a processed version of the the CGI $COOKIE (and possibly $COOKIE2) variables. The $_FILES array is filled with the parts of a multipart/form-data input that have a filename= section. This comes from a POSTed form (which uses STDIN as per the HTML and CGI specs).

Need I go on?

I believe serialize() preserves references -- it certainly does in PHP5 -- and (as mentioned elsewhere in the discussion) several PHP applications unserialize() remote data (notably phpBB).

Now, since the bug is apparently PHP4 only (gigabytes worth of references notwithstanding), the Big Question is whether or not the PHP4 unserialize() restores references.

Way ahead of you.

One of the biggest problems with PHP is the die-hard adherance to backwards compatibility. Functions don't get deprecated, the API doesn't change, it gets overloaded with nearly-the-same but-not-quite methods so that somewhere, somebody doesn't complain about how their website "broke" with the latest release--never mind the fact that by using insecure functions, their sites are already broke.

It goes beyond that. When the new API variants are released, details the actual problem resolved are usually found deep in the discussion and not the primary document itself.

Does the main documentation for unserialize call any attention to the hazards associated with it?

http://ca3.php.net/manual/en/function.unserialize. php

I have no particular grudge against PHP. I used it myself for small projects because the language is relatively easy to relearn on the fly. Perl demands too much head space to use it less than once a month. However, when you decided you really want to get a function right, you tear your hair out trying to get an exhaustive account from the online PHP documentation of the issues you need to concern yourself with.

The PHP project brought the month of bugs onto themselves. The simplest measure they could have taken was to make prominent in their online documentation the risks associated with each function PHP provides. I have no problem with caveat emptor. In fact, I've always shunned the languages that attempt to save me despite myself. The lack of prominent "beware of dog" signs in the online PHP documentation is what drives the security split within the PHP community: allowing one camp to remain lax, while the other camp becomes increasingly strident.

I regard this "month of bugs" as long belated complement to the online PHP documentation for concise information on the risk side of the equation.

strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for.

WTF are you smoking()? From the manual:

If needle is not found, strpos() will return boolean FALSE.

Like this:

$result = strpos($haystack, $needle);
if ($result === false) die("$needle was not found\n");

> There is no equivalent of a "contains" method for the string class, with strpos() being the recommended alternative. strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for.

strpos? *and* a separate check? strstr not good enough?
Returns false if string A does not contain string B, otherwise it is contained. What about preg_match?

So your webhost won't upgrade, and that's PHP's fault? PHP5 has been out a LONG time. Don't bother complaining about bugs in PHP4 simply because your website can't be bothered to upgrade. Find a decent webhost instead.

strpos() return FALSE when it can't find the 'needle'. http://us2.php.net/strpos Use a proper test (===) and you'll have all you need in a single statement.

Some people really LIKE dynamically-typed variables. It's not a bug or a problem. It's a design choice.

Your flamebait at the end (vbscript) does nothing to enhance your argument. Leave it off next time.

the major issue is [...] and a lack of attention to bug reports.

I don't think that's fair. I've anonymously reported a handful of bugs over the past couple of years and most were fixed within 24 hours. Here's one I recall from last year (yes I admit that particular one is not really a core bug). I'll criticize PHP until I'm blue in the face but my experience with bug fixing has been an overall positive experience.

http://php.net/xmlwriter
http://php.net/stream_wrapper_register

What you call extreme would others call a challenge.

You're making it yourself very easy with your generators argument. It's always the same ... not ... possible ... no .. generators ... only .. holy ... generators ... can ... work. Like a robot. When do you invest some time and learn? Just because you did something useful in the 80ies or 90ies doesn't mean you can stop learning.

http://php.net/xmlwriter
http://php.net/stream_wrapper_register

What you call extreme would others call a challenge.

You're making it yourself very easy with your generators argument. It's always the same ... not ... possible ... no .. generators ... only .. holy ... generators ... can ... work. Like a robot. When do you invest some time and learn? Just because you did something useful in the 80ies or 90ies doesn't mean you can stop learning.

Know it gets funny. You're talking about how stupid I'm about not knowing what I'm talking about, but you can't even type http://php.net/xmlreader and read what it's really about.

BTW, QED: You won't accept any Kid like solution in PHP, because PHP is not Python and it won't be exactly the same. At least I'm sure _you_ couldn't implement it in PHP.

Now if you want me stop criticizing you and the stuff you write you should really learn and understand PHP.

This is what stuff like smarty is for. That's just for PHP, but it's an example that decent systems to separate the hard logic from the presentation do exist.

mysqli supports bound parameters, http://us2.php.net/mysqli just because people use the mysql module instead of mysqli doesnt mean php doesn't support them. just skiddie apps don't. Also looking forward to see what they do reveal in the month.

Not only is the PHP development team negligent when it comes to dealing with security bugs, but they're incompetent when it comes to understanding the limitations of their own language, the tenants of object oriented programming, and database object-relational mapper design.

Here is quick summary of my previous post about Zend's ZActiveRecord Boondoggle:

The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".

To summarize: [Criticism of PHP "references".] [Criticism of PHP "object system".] [Description of "static methods".] [Description of Ruby on Rail's ActiveRecord.] [Description of "ZActiveRecord", Zend's lame half-baked cargo cult attempt to ape ActiveRecord.] [Zend busted for misleading screencast.] [Blog posting that proves: ZActiveRecord Can't Work.] [Zend misunderstood their own language's object system, showed fake code in a screencast that could not possibly work (because of a PHP bug), and made promises of ZActiveRecord they couldn't keep, because of that stupid bug they refused to fix.] [Longstanding bug that PHP static methods that the developers refuse to fix.] [Summary of comments on the bug that prevents anyone from writing an ActiveRecord-like ORM in PHP.] [Final word from andi, calls it expected behavior, demonstrating how he misunderstands object oriented programming, and casually dismisses all the bug report's valid comments.] [Zend gets hoisted on their own pitard by this very bug.]

And here's the final word from andi: "Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ [php.net] and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [php.net] This is expected behavior. self:: binds statically to its class (to the best of my knowledge other languages like C++ don't support this either as they require to explicitly use the class name). There are actually advantages also to this approach as they allow you to protect and encapsulate functinality."

Since Zend's dishonest and embarassing public-relations disaster with the ZActiveRecord Boondoggle, Zend has quietly withdrawn their plans for ZActiveRecord, instead of fixing the stupid bug that made it impossible to implement and ORM like ActiveRecord in PHP.

It's not just security that the PHP developers and Zend don't care about. They also don't care about nor understand object oriented programming, nor database object-relational mapping.

There is absolutely no reason to use PHP, when there are great languages like Python with extremely powerful, easy to use, safe and secure, database independent, object-relational mappers like SQLObject , and intelligent scalable SQL toolkits with multiple modular ORMs like SQLAlchemy. That stuff so blows away PHP's horribly insecure string-concatination approach to SQL, and all of the kludgy PHP database libraries people have cobbled together over the years.

-Don

Not only is the PHP development team negligent when it comes to dealing with security bugs, but they're incompetent when it comes to understanding the limitations of their own language, the tenants of object oriented programming, and database object-relational mapper design.

Here is quick summary of my previous post about Zend's ZActiveRecord Boondoggle:

The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".

To summarize: [Criticism of PHP "references".] [Criticism of PHP "object system".] [Description of "static methods".] [Description of Ruby on Rail's ActiveRecord.] [Description of "ZActiveRecord", Zend's lame half-baked cargo cult attempt to ape ActiveRecord.] [Zend busted for misleading screencast.] [Blog posting that proves: ZActiveRecord Can't Work.] [Zend misunderstood their own language's object system, showed fake code in a screencast that could not possibly work (because of a PHP bug), and made promises of ZActiveRecord they couldn't keep, because of that stupid bug they refused to fix.] [Longstanding bug that PHP static methods that the developers refuse to fix.] [Summary of comments on the bug that prevents anyone from writing an ActiveRecord-like ORM in PHP.] [Final word from andi, calls it expected behavior, demonstrating how he misunderstands object oriented programming, and casually dismisses all the bug report's valid comments.] [Zend gets hoisted on their own pitard by this very bug.]

And here's the final word from andi: "Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ [php.net] and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [php.net] This is expected behavior. self:: binds statically to its class (to the best of my knowledge other languages like C++ don't support this either as they require to explicitly use the class name). There are actually advantages also to this approach as they allow you to protect and encapsulate functinality."

Since Zend's dishonest and embarassing public-relations disaster with the ZActiveRecord Boondoggle, Zend has quietly withdrawn their plans for ZActiveRecord, instead of fixing the stupid bug that made it impossible to implement and ORM like ActiveRecord in PHP.

It's not just security that the PHP developers and Zend don't care about. They also don't care about nor understand object oriented programming, nor database object-relational mapping.

There is absolutely no reason to use PHP, when there are great languages like Python with extremely powerful, easy to use, safe and secure, database independent, object-relational mappers like SQLObject , and intelligent scalable SQL toolkits with multiple modular ORMs like SQLAlchemy. That stuff so blows away PHP's horribly insecure string-concatination approach to SQL, and all of the kludgy PHP database libraries people have cobbled together over the years.

-Don

Not only is the PHP development team negligent when it comes to dealing with security bugs, but they're incompetent when it comes to understanding the limitations of their own language, the tenants of object oriented programming, and database object-relational mapper design.

Here is quick summary of my previous post about Zend's ZActiveRecord Boondoggle:

The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".

To summarize: [Criticism of PHP "references".] [Criticism of PHP "object system".] [Description of "static methods".] [Description of Ruby on Rail's ActiveRecord.] [Description of "ZActiveRecord", Zend's lame half-baked cargo cult attempt to ape ActiveRecord.] [Zend busted for misleading screencast.] [Blog posting that proves: ZActiveRecord Can't Work.] [Zend misunderstood their own language's object system, showed fake code in a screencast that could not possibly work (because of a PHP bug), and made promises of ZActiveRecord they couldn't keep, because of that stupid bug they refused to fix.] [Longstanding bug that PHP static methods that the developers refuse to fix.] [Summary of comments on the bug that prevents anyone from writing an ActiveRecord-like ORM in PHP.] [Final word from andi, calls it expected behavior, demonstrating how he misunderstands object oriented programming, and casually dismisses all the bug report's valid comments.] [Zend gets hoisted on their own pitard by this very bug.]

And here's the final word from andi: "Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ [php.net] and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [php.net] This is expected behavior. self:: binds statically to its class (to the best of my knowledge other languages like C++ don't support this either as they require to explicitly use the class name). There are actually advantages also to this approach as they allow you to protect and encapsulate functinality."

Since Zend's dishonest and embarassing public-relations disaster with the ZActiveRecord Boondoggle, Zend has quietly withdrawn their plans for ZActiveRecord, instead of fixing the stupid bug that made it impossible to implement and ORM like ActiveRecord in PHP.

It's not just security that the PHP developers and Zend don't care about. They also don't care about nor understand object oriented programming, nor database object-relational mapping.

There is absolutely no reason to use PHP, when there are great languages like Python with extremely powerful, easy to use, safe and secure, database independent, object-relational mappers like SQLObject , and intelligent scalable SQL toolkits with multiple modular ORMs like SQLAlchemy. That stuff so blows away PHP's horribly insecure string-concatination approach to SQL, and all of the kludgy PHP database libraries people have cobbled together over the years.

-Don

Why do you have to wait a month? Something with your setup must be wrong if you can't get the recent source from CVS or download the latest snapshot.

Why do you have to wait a month? Something with your setup must be wrong if you can't get the recent source from CVS or download the latest snapshot.

And you're surprized? You made your bed, now sleep in it.

Or rather, stop sleeping until you've un-installed PHP on all your servers, because it will never be secure

thanks to the PHP team's attitude.

Actually, that bug is resolved in PHP 5.2.1

http://bugs.php.net/bug.php?id=35106

Separation of code and presentation can be done by using a templating system. Smarty is a popular one, although it's often criticized, and there are a lot others around as well. FastTemplate, although old, is also a choice.

Most of the frameworks mentioned above are built fanatically on MVC, so this separation is imperative.

http://www.php.net/register_globals Read the first sentence on that page please...it was fixed in PHP 4.2, not PHP 5.

Well, I do not have a lot of experience with PHP (only some typical unsecure LAMP tests) but after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?

I have programmed in PHP and C#/VB.NET for web forms (back when .NET was just out) and I can tell you that even there, the microsoft product was better than PHP. One of the things I dislike about PHP and I liked about the WebForms .NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.

Well, I do not have a lot of experience with PHP (only some typical unsecure LAMP tests) but after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?

I have programmed in PHP and C#/VB.NET for web forms (back when .NET was just out) and I can tell you that even there, the microsoft product was better than PHP. One of the things I dislike about PHP and I liked about the WebForms .NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.

I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.

I'm not surprised. Their attitude to bug reports in general is pretty hostile. See, for instance, this report of a segmentation fault bug.

Well, http://www.php.net/ is running PHP on it. I've gotta wonder if THEIR version is as much a watershed as the versions they make public.

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

• no first-class functions (and no, create_function does not count)
• no usable object-model (check out response of developer below!)
• no namespaces
• problems with recursion
• general problems with consistency
• countless other horrible mis-designed "features" (not even starting on the security problems)

Planet Source Code is not that hot. There's heaps of trivial examples that just aren't done very well - like a "new" PHP4-style class for connecting to MySQL which hard-codes "localhost" for the server name. I guess the guy hasn't heard of mysqli?

The quality of the writing itself is pretty bad, too. People who are purporting to teach you something ought to be a bit more... well... literate.

Neither am I inclined to be overly impressed when a site throws 175+ JavaScript and CSS errors in Firefox in just the first 2-3 pages. (I didn't bother counting the errors after that point.)

From Goaway \\\
The thing is, the vast majority of PHP users don't even understand that there is a problem. PHP is a language used mainly by beginners, and actively aimed at beginners, but it is not designed to be used by beginners. It's a landmine-filled sandbox.
\\\

So, where do you get that PHP is a "landmine-filled sandbox"? Because people don't use it properly (see function list below)? If so, that rather asinine.

From Goaway \\\
Thus, the internet is full of SQL injection vulnerabilities.
\\\

SQL injection errors are created by people that have no clue how to do there jobs. It is NOT language dependent (see list of functions below).

From Goaway \\\
Blaming every PHP programmer for not being a security expert is idiotic. Most programmers aren't, and they wouldn't need to be, if the language was designed properly.
\\\

If you define a security expert as one who pretty much uniquely knows to escape params to a SQL query, then I'd hate to think what your code looks like. In fact, my first piece of paper was from a college where I got a 2 year diploma. And even there they EXPLICITLY taught to do sanity checking at the client AND server level. And the instructor HATED teaching that stuff AND his actual expertise was networking. This is NOT about being a security expert, it is about /common sense/.

This also is an issue that has NOTHING to do with language design. If we were talking about having a standard db interface then THAT would be language design (btw PHP doesn't have one and that is a problem, but that's a completely other issue). What we ARE talking about, is how that design is IMPLEMENTED. These things are completely different.

From Goaway \\\
I don't use PHP, for exactly that reason.
\\\

Well, it's obvious that you don't use PHP because you have no clue what functions are in its library.

From http://ca3.php.net/manual/en/function.dbx-escape-s tring.php

"""
Escape a string so it can safely be used in an sql-statement
"""

and from http://ca3.php.net/manual/en/function.pg-escape-st ring.php

"""
Escape a string for insertion into a text field
"""

and from http://ca3.php.net/manual/sv/function.mysql-real-e scape-string.php

"""
Escapes special characters in a string for use in a SQL statement
"""

etc

So, there are loads of functions that do the required escaping without the "programmer" having to be a "security expert" i.e. it's just having a clue as to what functions are available /and using them/.

Also, point of fact, web programming today REQUIRES knowledge of security features/programes/etc. If you don't know, then you have no business doing it.

Point of fact, security is about creating layers of defenses to ensue that the app is pretty much tamper proof.

This starts with sanity checking at the browser, then a web application firewall (e.g. http://www.modsecurity.org/), specific sanity checks in the application code itself (e.g. restricting usernames to alphanumeric and checking for it), and if one is using a language that has functions like the above, use them (if they implemented internally, great), if not, do it yourself.

Of course sanity checking at the client level and using a web application firewall are optional but the others are required, period. If you don't do this you're asking for trouble. Furthermore, if you depend on others to do this checking for you, you are as well asking for trouble.

There will always be vulnerabilities in any language, web server, db server, etc. What makes any vulnerabilities not exploitable (or extremely difficult to exp

From Goaway \\\
The thing is, the vast majority of PHP users don't even understand that there is a problem. PHP is a language used mainly by beginners, and actively aimed at beginners, but it is not designed to be used by beginners. It's a landmine-filled sandbox.
\\\

So, where do you get that PHP is a "landmine-filled sandbox"? Because people don't use it properly (see function list below)? If so, that rather asinine.

From Goaway \\\
Thus, the internet is full of SQL injection vulnerabilities.
\\\

SQL injection errors are created by people that have no clue how to do there jobs. It is NOT language dependent (see list of functions below).

From Goaway \\\
Blaming every PHP programmer for not being a security expert is idiotic. Most programmers aren't, and they wouldn't need to be, if the language was designed properly.
\\\

If you define a security expert as one who pretty much uniquely knows to escape params to a SQL query, then I'd hate to think what your code looks like. In fact, my first piece of paper was from a college where I got a 2 year diploma. And even there they EXPLICITLY taught to do sanity checking at the client AND server level. And the instructor HATED teaching that stuff AND his actual expertise was networking. This is NOT about being a security expert, it is about /common sense/.

This also is an issue that has NOTHING to do with language design. If we were talking about having a standard db interface then THAT would be language design (btw PHP doesn't have one and that is a problem, but that's a completely other issue). What we ARE talking about, is how that design is IMPLEMENTED. These things are completely different.

From Goaway \\\
I don't use PHP, for exactly that reason.
\\\

Well, it's obvious that you don't use PHP because you have no clue what functions are in its library.

From http://ca3.php.net/manual/en/function.dbx-escape-s tring.php

"""
Escape a string so it can safely be used in an sql-statement
"""

and from http://ca3.php.net/manual/en/function.pg-escape-st ring.php

"""
Escape a string for insertion into a text field
"""

and from http://ca3.php.net/manual/sv/function.mysql-real-e scape-string.php

"""
Escapes special characters in a string for use in a SQL statement
"""

etc

So, there are loads of functions that do the required escaping without the "programmer" having to be a "security expert" i.e. it's just having a clue as to what functions are available /and using them/.

Also, point of fact, web programming today REQUIRES knowledge of security features/programes/etc. If you don't know, then you have no business doing it.

Point of fact, security is about creating layers of defenses to ensue that the app is pretty much tamper proof.

This starts with sanity checking at the browser, then a web application firewall (e.g. http://www.modsecurity.org/), specific sanity checks in the application code itself (e.g. restricting usernames to alphanumeric and checking for it), and if one is using a language that has functions like the above, use them (if they implemented internally, great), if not, do it yourself.

Of course sanity checking at the client level and using a web application firewall are optional but the others are required, period. If you don't do this you're asking for trouble. Furthermore, if you depend on others to do this checking for you, you are as well asking for trouble.

There will always be vulnerabilities in any language, web server, db server, etc. What makes any vulnerabilities not exploitable (or extremely difficult to exp

From Goaway \\\
The thing is, the vast majority of PHP users don't even understand that there is a problem. PHP is a language used mainly by beginners, and actively aimed at beginners, but it is not designed to be used by beginners. It's a landmine-filled sandbox.
\\\

So, where do you get that PHP is a "landmine-filled sandbox"? Because people don't use it properly (see function list below)? If so, that rather asinine.

From Goaway \\\
Thus, the internet is full of SQL injection vulnerabilities.
\\\

SQL injection errors are created by people that have no clue how to do there jobs. It is NOT language dependent (see list of functions below).

From Goaway \\\
Blaming every PHP programmer for not being a security expert is idiotic. Most programmers aren't, and they wouldn't need to be, if the language was designed properly.
\\\

If you define a security expert as one who pretty much uniquely knows to escape params to a SQL query, then I'd hate to think what your code looks like. In fact, my first piece of paper was from a college where I got a 2 year diploma. And even there they EXPLICITLY taught to do sanity checking at the client AND server level. And the instructor HATED teaching that stuff AND his actual expertise was networking. This is NOT about being a security expert, it is about /common sense/.

This also is an issue that has NOTHING to do with language design. If we were talking about having a standard db interface then THAT would be language design (btw PHP doesn't have one and that is a problem, but that's a completely other issue). What we ARE talking about, is how that design is IMPLEMENTED. These things are completely different.

From Goaway \\\
I don't use PHP, for exactly that reason.
\\\

Well, it's obvious that you don't use PHP because you have no clue what functions are in its library.

From http://ca3.php.net/manual/en/function.dbx-escape-s tring.php

"""
Escape a string so it can safely be used in an sql-statement
"""

and from http://ca3.php.net/manual/en/function.pg-escape-st ring.php

"""
Escape a string for insertion into a text field
"""

and from http://ca3.php.net/manual/sv/function.mysql-real-e scape-string.php

"""
Escapes special characters in a string for use in a SQL statement
"""

etc

So, there are loads of functions that do the required escaping without the "programmer" having to be a "security expert" i.e. it's just having a clue as to what functions are available /and using them/.

Also, point of fact, web programming today REQUIRES knowledge of security features/programes/etc. If you don't know, then you have no business doing it.

Point of fact, security is about creating layers of defenses to ensue that the app is pretty much tamper proof.

This starts with sanity checking at the browser, then a web application firewall (e.g. http://www.modsecurity.org/), specific sanity checks in the application code itself (e.g. restricting usernames to alphanumeric and checking for it), and if one is using a language that has functions like the above, use them (if they implemented internally, great), if not, do it yourself.

Of course sanity checking at the client level and using a web application firewall are optional but the others are required, period. If you don't do this you're asking for trouble. Furthermore, if you depend on others to do this checking for you, you are as well asking for trouble.

There will always be vulnerabilities in any language, web server, db server, etc. What makes any vulnerabilities not exploitable (or extremely difficult to exp

The answer:
mysqli prepared statements.