Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Securing PHP Web Applications

samzenpus posted more than 5 years ago | from the protect-ya-neck dept.

PHP 229

Michael J. Ross writes "The owners and the developers of typical Web sites face a quandary, one often unrecognized and unstated: They generally want their sites' contents and functionality to be accessible to everyone on the Internet, yet the more they open those sites, the more vulnerable they can become to attackers of all sorts. In their latest book, Securing PHP Web Applications, Tricia and William Ballad argue that PHP is an inherently insecure language, and they attempt to arm PHP programmers with the knowledge and techniques for making the sites they develop as secure as possible, short of disconnecting them from the Internet." Keep reading for the rest of Michael's review.The book was published by Addison-Wesley on 26 December 2008, under the ISBN 978-0321534347. The publisher maintains a Web page for the book, where visitors will find a detailed description, the table of contents, and a sample chapter ("Cross-Site Scripting," Chapter 10) only three pages in length — undoubtedly a record. That is essentially all one will find on that Web page. Most technical publishers offer far more information on the Web pages for each one of their books — such as the preface and index online, updates to the book's content (including reported errata, confirmed and otherwise), descriptions of the chapters, information about and pictures of the author(s), feedback from readers and the media, and, perhaps most valuable of all, the sample code used in the given book. (However, that is less of a factor with this particular book, since it does not contain much sample code.) Many such publisher pages even have links to book- or technology-specific forums, where readers can post questions to the authors, and read other people's questions and the replies. Addison-Wesley, like all of the Pearson Education imprints, has through the years proven quite sparing with the supplementary online content, thereby no doubt reducing the number of prospective readers and other traffic to their sites.

Despite its fairly modest length (336 pages) in comparison to the average programming book being published these days, Securing PHP Web Applications tries to cover a sizable number of topics, in five parts, which encompass 17 chapters: general security issues; error handling; system calls; buffer overflows and sanitizing variables; input validation; file access; user authentication; encryption and passwords; sessions and attacks against them; cross-site scripting; securing Apache and MySQL; securing IIS and SQL Server; securing PHP; automated testing; exploit testing; designing a secure application; and hardening an existing application. The book concludes with an epilogue on professional habits to improve the security of one's applications, an appendix describing additional resources, a glossary, and an index. Throughout the book, the authors illustrate key ideas with the use of a sample application — in this case, a Web-based guest book.

The first chapter, which is the only one in the first part of the book, is rather brief, but does prime the reader for all the material that follows, because it explains the inherent security problems of Web applications, and explains the dangers of some of the inadequate measures that naive programmers can take, such as security through obscurity, and the common belief that hackers only go after major Web sites.

Chapter 2 focuses on error handling, but begins with an example of SQL injection, and how effective it can be against the first iteration of the guest book application code. The most potentially confusing part of the discussion is when the authors show an SQL injection attack that perverts an INSERT statement by injecting it with an SQL command to drop a table, and the two commands are separated by a semicolon. But then instead of discussing how multiple SQL statements can be separated by semicolons (well, depending upon one's server settings), they instead discuss separating PHP commands was semicolons, but not SQL commands. Nonetheless, readers will find some good advice on handling unexpected input and using a centralized error-handling mechanism, even if quite simple. Also, the question of whether or not to accept HTML in user input, is briefly addressed. However, the material would be more useful if the authors were to explain specifically when htmlspecialchars() should be used instead of htmlentities(). Also, the option of using standard bulletin board codes (such as [b]bold[/b]) should have been mentioned, if only briefly with references to outside resources. At the bottom of page 22, the bare regex following a !"~" is not valid PHP (or even Perl, which it much more resembles). Lastly, one should not follow the recommendation of providing absolutely no feedback to the user as to what characters were invalid in the text they entered. Hackers gain nothing from being told the obvious, that HTML tags are not allowed; but legitimate users will be incensed when told only that the system didn't understand their input, with no indication as to how to make it acceptable.

In the third chapter, the authors explain the obvious danger of using unsanitized user input within a call to the operating system, such as exec() or system(). The discussion here assumes that you are on a *nux server, not Windows. Two PHP commands are suggested for sanitizing user input, as well as the option and advantages of building a custom API that is limited to only the system calls that should ever be executed within your Web application. On page 33, their test code appears to assume that register_globals has been enabled (so the GET variables in the malicious URL are automatically instantiated and set to the values in the URL), which is disappointing for a book on PHP security, since the dangers inherent in register_globals are so severe that it is now disabled by default, is deprecated in PHP version 5.3.0, and will be completely removed in version 6.

In Chapter 4, readers get an overview of program and data storage on a computer, including buffers, stacks, and heaps, as groundwork for learning what buffer overflows are and how hackers can try to exploit them to execute database and operating system statements, including using your server as a staging point for remote exploits and denial-of-service attacks. The fifth chapter dovetails nicely with the previous one, because it discusses input validation, which is a key component of avoiding boundary condition attacks. The authors explain the importance of validating tainted data, using character length and regular expressions. One simple countermeasure to such attacks that the authors fail to mention, is simply setting a maximum input length ("maxlength") on HTML "input" tag fields. After all, most entry fields on forms are input tags — not textarea tags, for which the maxlength attribute only specifies wrapping. Using maxlength does not prevent manipulation of POST values, but does prevent the less knowledgeable attacker from overflowing input tag fields.

Chapter 6 explains the risks in working with local and remote files, and why it is critical to not allow mischievous users do such tricks as inserting a pathname in a filename, when your code is expecting only a simple filename. Unfortunately, some of the code and claims in this chapter are suspect: On page 70, the value of $path_to_uploaded_files is missing a needed trailing forward slash. The suggested method of processing malicious file paths could be made much more simple and secure with the use of basename(). The file_get_contents() attack shown on page 71 again seems to assume that register_globals is enabled; even if it were enabled, the exploit wouldn't work because $file is always set to a value in the script code. The authors seemingly believe that GET variables can override anything in a script. Nonetheless, their advice about handling user-uploaded files is spot on.

Part 4 of the book focuses on user security. The first of its chapters covers user authentication and authorization — combining the two for their sample application — and starting with usernames and passwords. Access denial due to invalid username or password is supposedly illustrated by Figure 7.2, but all that it illustrates is that a concept that needs no visual depiction is not made more clear by trying to represent it with a confusing image. The authors provide a thorough discussion of authentication purposes and methods, as well as password encryption and strength. Yet they provide no rationale for setting the default values for usernames, passwords, and e-mail addresses to " " simply because the columns are non-nullable. After all, a record would only be added to the table if those values were known. Also, in their validateUsernamePassword() function, they've mistakenly commented out the first "return FALSE;" and they create unused variables $username and $password.

Chapter 8 provides an overview of various types of encryption, particularly for passwords, and some recommendations for PHP-supported algorithms. One blemish in this discussion is the claim that the longer the key for decryption, the longer it will take for your application to load the data (presumably the encrypted text) — which doesn't make sense. Also, their password() and login() functions reference class member names of an object not yet defined or explained. Code out of context like this can be confusing to the reader.

Sessions are a key component of maintaining and securing the identity of an authenticated user as she goes from one page to another in your PHP application. In Chapter 9, the authors describe the three major categories of session attacks: fixation, hijacking, and injection. The next chapter addresses cross-site scripting (XSS), but runs only three pages, and provides no examples of an XSS attack, which would have been helpful for the reader to understand how such an attack could try to compromise his PHP code, and what sort of malicious code to look for in his site. However, references to four open source XSS filtering projects are provided, in case the reader would like to learn more about them.

The fifth part of the book is devoted to securing whichever server environment on which you choose to host your application — Apache and MySQL, or IIS and Microsoft SQL Server, as well as PHP. In the chapter on PHP, the authors present the Zend Core release of PHP, which can save developers time in installing components of the LAMP stack, and also save them from reinventing the wheel, by using the Zend Framework. Other techniques for hardening PHP are discussed. Chapters 14 and 15 explain how to use automated testing and exploit testing, to increase your application's security, using powerful exploit testing tools — free and proprietary.

The sixth and final part of the book contains two chapters, which purportedly discuss the advantages of designing security into a new application right from the start, and how to improve security in an application that has already been built. In the former chapter, the authors stress the importance of balancing no design ("Skip reading Slashdot for one day...") and too much design (i.e., stalling). But the material mostly consists of the basics of designing a Web application, with no new information on security, and concludes with a brief reiteration of security principles detailed in earlier chapters. The latter chapter offers some good advice on having separate development and test environments, in addition to the production environment. The principles expounded in each of the two chapters, do not overlap at all, and yet together they apply equally to new applications under development just as much as they do to finished applications; splitting the principles up does not make sense.

Sadly, the book does not live up to its potential. In general, much of the sample code is sloppy, as exemplified by the instances noted above. The authors and the technical reviewers should have tested the attacks, and thereby found which ones don't work. Even the HTML should not be used by any new Web developer as an example of quality code that adheres to leading standards. In the HTML that they have their sample PHP code generate, the tag attribute values are in single quotes, and not double, which means all of that code would need to be changed to make it compliant with XHTML 1.0. Moreover, by choosing to use single quotes for both the attribute values and the PHP strings, the authors end up having to escape every single attribute value quote mark, which wastes space and looks ridiculous. They repeat this at the end of Chapter 6, but this time with all double quotes. Also, some of the technical decisions are rather odd, such as their setting those default values to spaces in the user table, noted earlier. A few terms are used strangely, as well, such as their statement that IIS's footprint is the number of entry points to it; actually, a Web server software's footprint generally refers to how much memory it consumes. Every chapter ends with a summary, titled "Wrapping It Up," none of which add any value to the book. There are at least three technical errata in the book that should have been caught: spaces in "u + rwx, go + rx" (page 76), and the invalid addresses "www.blog/modsecurity.org" (page 215) and "www.ballad-nonfiction/SecuringPHP/" (page 288; adding ."com" does not fix it).

On the other hand, the book's marketing copy claims that "Tricia and William Ballad demystify PHP security by presenting realistic scenarios and code examples, practical checklists, detailed visuals..." and that is certainly a fair claim. Most of the explanations are straightforward and informative. As a side note, kudos to Addison-Wesley for printing this book on recycled paper; one can only hope that all publishers adopt that policy.

The primary value of Securing PHP Web Applications is that it touches upon security topics that are often glossed over or completely neglected in other PHP security books and articles. This is important, because online miscreants will be searching out every possible chink in your Web site's armor. You should do the same, before they strike — and this book shows how.

Michael J. Ross is a freelance Web developer and writer.

You can purchase Securing PHP Web Applications from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

First post (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27042823)

Yo dawg, I herd u liek trolling, so we put trolls in yo trolls so you can mod me down while you mod me down.

Re:First post (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#27043223)

Yo dawg, this is the troll inside my troll.

mods,
MacFags,
H1-B applicants,
niggers,
Jews,
and especially mods all suck dicks. Fuck 'em.

God Hates Fags! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27042853)

Linux Torvalds is now in Hell. And it is not relevant that Linux Torvalds boasted that he does not believe in Hell when he lived on earth. He believes in Hell now. Like the rich man that the Lord Jesus told about in Luke 16, who died and in Hell he lifted up his eyes being in torments and he cried, "Lord Abraham have mercy on me, and send Lazarus the beggar on earth, that he may dip the tip of his finger in water and cool my tongue, for I am tormented in flame." Luke 16:23,24. When told that he could not have a drop of water, forever, though tormented in flames, he begged somebody to rise from the dead to preach to his kinfolk, thus they also die and come to his place of torment. Linux Torvalds the filthy blasphemer, the obscene pottymouth skeptic, agnostic and profane atheist had nothing but disdain for God and the Bible, all the days of his tragic life is at this minute and and forever writhing and screaming in exquisite pain, pleading for mercy from that God he flipped off while performing for NBC lucre. Montalban made lots of money making fun of god, now he must deal with God face to face forever. The Lord the God repayeth them that hate him to their face, to destroy them, he will not be slapped to them that hateth him, he will repay him to his face. Deut. 7:10. When Montalban died January the fourteenth, he split hell wide open at once, as it is written, "Hell from beneath is moved for thee to meet thee at thy coming. It stirreth up the dead for thee. All they shall speak and say unto thee: art thou also become weak as we 'Linux Torvalds?' The worm is spread unto thee, and the worms cover thee. Isaiah 14:9,10. Westboro Baptist Church exists to publish Gospel truth and thereby to expose Satanic lies. Linux Torvalds is in hell, deal with it! You will soon join him there, America is doomed! We will picket Linux Torvalds's funeral.

Re:God Hates Fags! (3, Funny)

Leafheart (1120885) | more than 5 years ago | (#27043025)

Linux Torvalds (snip.) Linux Torvalds (snip.) Linux Torvalds (snip.) 'Linux Torvalds?' (snip.) Linux Torvalds (snip.) Linux Torvalds's

Who is this Linux Torvalds you keep talking about? Is that a new distro I don't know?

Re:God Hates Fags! (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#27043063)

Trolled.

Just don't (1, Insightful)

Lord Ender (156273) | more than 5 years ago | (#27042907)

If you want to produce secure web apps, you need to hire a security specialist to audit the application, and (ideally) assist with the design phase as well. Application security is an incredibly subtle thing in many ways. A developer who read a book on security will get security wrong. It's a topic that simply requires a specialist.

Re:Just don't (5, Insightful)

FredFredrickson (1177871) | more than 5 years ago | (#27043027)

Things like this always surprise me when I hear them.

Making a secure PHP web app is not that hard.

-Make sure to keep globals off (or initialize all variables before using them.
-Sanitize all inputs before getting to the database.
-Always sanitize user-inputted data before displaying it on screen (strip_tags)
-Check permissions on every page. (Make sure I can't change id=17 to id=18 and see things I shouldn't.)
And so on...

Honestly, it's not some mysterious voodoo, it's very basic procedures (like these) that all programmers should get in the habit of doing, no matter what language you use.

Re:Just don't (2, Insightful)

Zero__Kelvin (151819) | more than 5 years ago | (#27043233)

I know what you mean. It's like heart surgery. All you do is:
  1. Cut a guy open
  2. Put him on bypass
  3. Do a little tweaking
  4. Take him off bypass
  5. Sew 'em back up

I'm not really sure why people think it is so hard!

The fact that you think it is easy means you are unable to do it properly and don't know that you don't know.

Re:Just don't (5, Insightful)

FredFredrickson (1177871) | more than 5 years ago | (#27043301)

As a programmer, I probably couldn't do what a heart surgeon would do. But as a programmer, I can do what programmers do. Part of my job is security. Some times its tedious, sometimes I miss things. But it's not magic or voodoo. And I believe the heart surgeon doesn't beleve what he does is voodoo either.

As a programmer (5, Funny)

NotQuiteReal (608241) | more than 5 years ago | (#27043543)

If I had to, under certain circumstances, I would take a stab at doing what a heart surgeon would do. If it didn't go right, then I might consider reading up on the procedure.

However, if the patient survives long enough to be released, I am confident that I could simply document any lingering anomalies he might suffer as a feature, not malpractice.

Re:Just don't (-1, Flamebait)

Zero__Kelvin (151819) | more than 5 years ago | (#27044397)

"As a programmer, I probably couldn't do what a heart surgeon would do. But as a programmer, I can do what programmers do."

I'll let slide the fact that you refer to system analysis and design as "programming" since I don't know if you mean it generically, or if you really think input validation is a programming job. What we are about to see, however, is your failure to properly categorize and label activities and specialties, and how doing so can make one sound smart even though what they say doesn't actually make any sense.

Let us try a substitution and see if it makes sense:

As a doctor, I probably couldn't do what a software security expert would do. But as a doctor, I can do what heart surgeons do.

Hmmm ... that really doesn't make any sense! I definitely don't want a pediatrician performing heart surgery on me! OH! I see what you did. You used heart surgeon as a substitution for doctor. All programmers are programmers. All doctors are doctors. Not all doctors are heart surgeons, just as not all programmers are security specialists (or at least sufficiently skilled in that specialty).

Now here you really go off the deep end. In order to do this, you looked in a special thesaurus and found a synonym for hard, to wit: voodoo! Now lets substitute the original word I used in place and see if it still makes sense:

And I believe the heart surgeon doesn't beleve (sic) what he does is hard either.

Really? Seriously? Once you untwist my words, it turns out you made rather ridiculous statements after all. I have to admit, it looked real pretty and sounded real good as long as you didn't look closely and think. No doubt you'll get a +5 on it.

Re:Just don't (4, Insightful)

mikael_j (106439) | more than 5 years ago | (#27043305)

The fact that you think it is easy means you are unable to do it properly and don't know that you don't know.

Or it's possible that, you know, he's an experienced developer who's got enough experience with PHP that to him it really is easy.

/Mikael

Re:Just don't (1)

Phil John (576633) | more than 5 years ago | (#27043257)

What about protecting against CSRF?

That one's fun because even if you use tokens in forms, if you have even 1 XSS vulnerability any countermeasures are rendered useless.

Re:Just don't (2)

FredFredrickson (1177871) | more than 5 years ago | (#27043423)

My list wasn't exhaustive, but you can eliminate XSS by scrubbing all your inputs. If the only thing a user can post is plaintext and some bbcode, that's all they'll post.

Another cool one that I'm surprised Myspace hasn't used:
A great way to kill phishers is using the out-bound warning page. Re-code all outbound hyperlinks to a "Warning, this is no longer myspace" page, then allow them to click the url.

Re:Just don't (1)

aftk2 (556992) | more than 5 years ago | (#27043703)

Myspace does that.

Re:Just don't (1)

merreborn (853723) | more than 5 years ago | (#27044447)

Another cool one that I'm surprised Myspace hasn't used:
A great way to kill phishers is using the out-bound warning page. Re-code all outbound hyperlinks to a "Warning, this is no longer myspace" page, then allow them to click the url.

Yeah, that's a great way to make your users more aware of potential phishing attempts, except for the fact it's fucking terrible from a usability perspective.

Sure, you might help a few mouthbreathers realize they're being phished, but frankly, they aren't going to read your warning page anyway. They're the type that just click "okay" to make dialogs go away, with no thought to the consequences.

And for the rest, you're only going to annoy people who now have to go through *two* clicks and page loads for what would have otherwise been a single click. I clicked the link, I know what I'm doing. Don't make me tell you twice.

Re:Just don't (0)

encoderer (1060616) | more than 5 years ago | (#27043613)

For CSRF to work the attacker has to be able to inject his own content into your site that a victim can then come by and download.

Quite a few ways to do this, but if you take the precautions mentioned above, you'll be safe.

Tho, I would add one more IMPORTANT bullet point: Install the Suhosin Hardened PHP Patch.

And for fool-proof input sanitization, use filter_input() (and the other Filter functions PHP introduced at 5.something)

Re:Just don't (0)

Anonymous Coward | more than 5 years ago | (#27043903)

And for fool-proof input sanitization, use filter_input() (and the other Filter functions PHP introduced at 5.something)

Far from fool proof, for example the email validation function just uses some copy-pasted PEAR regex, it lacks length checks and fails on valid RFC 822 addresses. The API is awful and the extension has had it's own share of security issues.

  • http://www.php-security.org/MOPB/MOPB-18-2007.html
  • http://www.php-security.org/MOPB/MOPB-19-2007.html
  • http://secunia.com/advisories/24824/

Don't get me started on the API...

// sane code
$valid_int = (int) $_GET['raw_int'];
$valid_int = intval($_GET['raw_int']);

// moronic code
$valid_int = filter_var($_GET['raw_int'], FILTER_VALIDATE_INT);
$valid_int = filter_input(INPUT_GET, 'raw_int', FILTER_VALIDATE_INT);

No he doesn't (2, Informative)

dblackshell (1450807) | more than 5 years ago | (#27044063)

For CSRF to work the attacker has to be able to inject his own content into your site that a victim can then come by and download.

I don't know what you are talking about, but it seems partially XSS combined with some malware...

CSRF is something else...

http://slashdot.org/my/logout [slashdot.org] - this is a CSRF link

Re:No he doesn't (1)

encoderer (1060616) | more than 5 years ago | (#27044585)

That's a good illustration: You just injected content that I downloaded. In your case, it was the link.

Sure, there are a lot of apps that have some sort of facility for this. But there are just as many that don't.

Re:Just don't (1, Insightful)

LurkerXXX (667952) | more than 5 years ago | (#27043341)

"Sanitize all inputs before getting to the database."

NO! How many times to people have to get hammered because their own or someone else's sanatizer didn't really sanitize (ex: php's mysql_escape_string vs mysql_REAL_escape_string, and other idiotic things)
before folks will listen to DBAs and start using well parametrized stored procedures/prepared statements.

If you use a well parametrized stored procedures/prepared statements you don't have to worry about any idiots trying to do sql injection, nor how you or someone else may have botched your sanitizer.

Re:Just don't (1)

kuzb (724081) | more than 5 years ago | (#27043481)

NO! How many times to people have to get hammered because their own or someone else's sanatizer didn't really sanitize (ex: php's mysql_escape_string vs mysql_REAL_escape_string, and other idiotic things) before folks will listen to DBAs and start using well parametrized stored procedures/prepared statements.

More important than sanitization is actual validation. Is it supposed to be an integer? Check that first. If the input is no good, reject the whole thing before it gets in to your query in any way, shape or form. http://php.net/filter [php.net] is a very underrated way to do this.

OTOH, I do agree, much grief could be saved if more people just used PDO.

Re:Just don't (1)

SgtChaireBourne (457691) | more than 5 years ago | (#27044069)

"Sanitize all inputs before getting to the database."

NO! How many times to people have to get hammered because their own or someone else's sanatizer didn't really sanitize (ex: php's mysql_escape_string vs mysql_REAL_escape_string, and other idiotic things)
before folks will listen to DBAs and start using well parametrized stored procedures/prepared statements.

If you use a well parametrized stored procedures/prepared statements you don't have to worry about any idiots trying to do sql injection, nor how you or someone else may have botched your sanitizer.

That is correct, but PHP programming is taught generally as the blind leading the blind. I usually say PHP will be fine for those that are already quite good at C. The sanitizers have often been very disappointing when looking under the hood. Quite often there is no real parsing going on, simply global search and replace which can be gamed.

Use of parametrized stored procedures and prepared statements needs to be part of the introduction to databases with any language. The APIs are there, they're documented. Use them.

Re:Just don't (0, Redundant)

pjt33 (739471) | more than 5 years ago | (#27043367)

Sanitize all inputs before getting to the database.

I don't know why language / library designers nowadays don't make it harder to use unsanitised input. Make it easy to use prepared statements and hard (or impossible if you don't care about those who say "But I know what I'm doing and don't want to take a performance hit from using features designed to make things safer") to execute SQL directly. For something like PHP which is primarily going to be used as glue between a database and a web server it might even make sense to automatically compile its SQL execution statement into a prepared statement unless an extra package is installed and configured - a hurdle which the average user wouldn't bother with, but which might placate the soi-disant power user.

Re:Just don't (1)

kuzb (724081) | more than 5 years ago | (#27043409)

I completely agree. In a lot of cases, it's not the language which is the problem. It's the programmer. They run out and learn PHP from some outdated tutorial that had bad practices without understanding their implications. Too many people spend a week with the language and then think they are somehow experts. PHP can be made as secure as any other language out there. The trick is to actually read the manual, and learn the pitfalls.

Re:Just don't (1)

dblackshell (1450807) | more than 5 years ago | (#27044151)

and you could also blame books like the above one... register_globals? for f***s sake we are using php 5 (Some of us at least) which has it turned off and books like this one put us back (at least) 8 years in time...

I think that the ones that wrote the books are security experts and due to the fact that in their last pentest (security audit) didn't find any xss/sql injection/rfi vulnerability they decided to "repair" the problem.

Re:Just don't (1, Flamebait)

Lord Ender (156273) | more than 5 years ago | (#27043457)

And yet I spend lots of time cleaning up after developers who think they understand security; they even list their security skills on their resumes. They just keep getting it wrong.

Re:Just don't (1)

FredFredrickson (1177871) | more than 5 years ago | (#27043583)

No doubt, not everybody lives up to their own hype. Some people aren't nearly as qualified as they think they are. I'm sure neither you nor I are exempt from this. It's easier to find something wrong with somebody's code, than to code it correctly in the first place. It's nice to have a second pair of eyes for that reason.

That being said, it's still not rocket science, or magic. It's just tedious, and requires forethought. Considering all the angles is important. When you get into the habit, it becomes second nature.

Surely this is not a limitation of PHP or the PHP programmer. Just coincidental evidence against particular instances you've encountered make it seem as if it is so. (Anecdotes)

Re:Just don't (0)

Anonymous Coward | more than 5 years ago | (#27043753)

- strip_tags will not protect you against XSS if the value ends up in an attribute.
- you also need to be very careful with character encodings; not all systems will interpret the bytestream the same way as your 'sanitizer' did. Null bytes and overlong UTF-8 sequences are popular examples.
- sanitizing input before it gets to the database will result in users not able to edit their content. You need to use the appropriate escaping when when user-supplied data is used in another context.

For more, see http://acko.net/blog/safe-string-theory-for-the-web

Re:Just don't (4, Funny)

Anonymous Coward | more than 5 years ago | (#27043031)

A developer who read a book on security will get security wrong.

So I guess we have to tell Bruce Schneier that his "Secure Programming for Linux and Unix HOWTO" book is simply useless.

Re:Just don't (4, Funny)

PotatoFarmer (1250696) | more than 5 years ago | (#27043253)

So I guess we have to tell Bruce Schneier that his "Secure Programming for Linux and Unix HOWTO" book is simply useless.

We? Who is this 'we'? You tell him, I'm not going anywhere near Bruce while you're in the process of making him angry.

Oblig. link to Schneier Facts [geekz.co.uk]

Re:Just don't (0)

Anonymous Coward | more than 5 years ago | (#27043597)

So I guess we have to tell Bruce Schneier that his "Secure Programming for Linux and Unix HOWTO" book is simply useless.

I've got the book and I have never got security wrong... maybe because I never actually read it.

Its not useless though.. its propping my server cabinet up.

Bruce Schneier != David A. Wheeler (4, Informative)

dwheeler (321049) | more than 5 years ago | (#27044341)

Thanks for the plug for Secure Programming for Linux and Unix HOWTO [dwheeler.com] . But I wrote it, not Bruce Schneier. Schneier has written other books, such as "Applied Cryptography" and "Schneier on Security".

Re:Just don't (0)

Anonymous Coward | more than 5 years ago | (#27044439)

I googled "Secure Programming for Linux and Unix HOWTO" and it seems to have been authored by David A. Wheeler. Was this just a typo or did I not get the joke?

Thanks

Re:Just don't (1)

Joe U (443617) | more than 5 years ago | (#27043041)

Or at least take the time to validate all your input. Geez, if I had $1 for every time someone wrote an app that didn't properly validate.

Re:Just don't (1)

Zero__Kelvin (151819) | more than 5 years ago | (#27043279)

I'd rather have a dollar for everyone who said: " all you have to do is validate your input !" when they had no idea to do so properly themselves. I am quite certain that 90% of the people saying that make an attempt at validating that they think is successful, when in fact the validation logic is thoroughly flawed. You might not be one of them; I'm just making a point.

Re:Just don't (2, Insightful)

cbiltcliffe (186293) | more than 5 years ago | (#27043321)

.....Geez, if I had $1 for every time someone wrote an app that didn't properly validate.

....then you'd be almost as rich as me, if I had $1 for every time someone wrote a web page that didn't properly validate.

And I'd be almost as rich as random_grammar_nazi, if they had $1 for every time someone wrote a sentence that didn't properly validate.

There's a running theme here, in case you hadn't noticed. People, as a general rule, suck at following rules that don't have obvious, immediate consequences for breaking them.

Re:Just don't (1)

steve.howard (988489) | more than 5 years ago | (#27043381)

For that matter, learn modern database query techniques. That how-to guide you read over the weekend that shows you how to do

mysql_query("SELECT * FROM USERS WHERE name= {$_POST['username']}' AND PASSWORD= '{$_POST['password']}'")

was a nice teaching tool, but PHP 5 + PDO/mysqli can accomplish this with placeholders. That's not to say you shouldn't validate your data to make sure that it's what it should be, it's just that if you screw that up but use placeholders, your damage is minimal.

Re:Just don't (0)

Anonymous Coward | more than 5 years ago | (#27044431)

mysql_query("SELECT * FROM USERS WHERE name= {$_POST['username']}' AND PASSWORD= '{$_POST['password']}'")

you forgot a single quote before {$_POST['username']}'

Re:Just don't (2, Funny)

Anonymous Coward | more than 5 years ago | (#27043499)

Or at least take the time to validate all your input. Geez, if I had $1 for every time someone wrote an app that didn't properly validate.

Uh oh, I forgot to validate $1 !

Re:Just don't (1)

morgan_greywolf (835522) | more than 5 years ago | (#27044297)

I always validate against '\$[0-9].*'!

Re:Just don't (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27043077)

Application security is an incredibly subtle thing in many ways. A developer who read a book on security will get security wrong. It's a topic that simply requires a specialist.

Feeling insecure and trying to build yourself some job security by belittling developers? How cute. Yeah, let's leave developers in the dark so overpaid "specialists" can be required to do twice the work.

Re:Just don't (0)

Anonymous Coward | more than 5 years ago | (#27043723)

Right, because we all know security specialists are born with such knowledge, there is no way in hell "mere mortals" can obtain such arcane powers!

Re:Just don't (1)

Ninnle Labs, LLC (1486095) | more than 5 years ago | (#27043985)

If you want to produce secure web apps, you need to hire a security specialist to audit the application, and (ideally) assist with the design phase as well. Application security is an incredibly subtle thing in many ways.

Or you can save yourself money in the long run and just teach your developers how to design and code secure web pages.

A developer who read a book on security will get security wrong. It's a topic that simply requires a specialist.

So how did the specialist learn security? Osmosis?

Re:Just don't (2, Insightful)

ericspinder (146776) | more than 5 years ago | (#27044139)

A developer who read a book on security will get security wrong. It's a topic that simply requires a specialist.

And specialists come from where? Are these individuals born with an innate knowledge of PHP security, or are these skills passed from father to son, mentor to apprentice? No, they get their knowledge from books, lectures, and websites; they read and learn (hopefully). I'd say the the best are likely senior developers who've developed a specialty.

Acting like security isn't in the realm of the developer is a particularly dangerous statement, and I really do hope that it's just a joke. As it's one of the basic parts of web application (no matter what the language). Sure one could hire a security specialist to review the process, but you're better off just using an intrusion detecting application (or service), and a proper code review.

Re:Just don't (1)

merreborn (853723) | more than 5 years ago | (#27044521)

A developer who read a book on security will get security wrong. It's a topic that simply requires a specialist.

Any developer who doesn't qualify as a "security specialist" by your definition has no business writing code in the first place.

Write secure code, and draft secure designs from the beginning. If you're a developer, security is your job, not an afterthought for someone else to layer on after the fact.

Re:Just don't (0)

Anonymous Coward | more than 5 years ago | (#27044709)

Yes, no company should invest in training their developers on how to securely develop apps. Clearly it is far more in their benefit to keep them in the dark on how to do this and hire expensive "specialists" to do this. This is one of the stupidest fucking posts I've ever seen.

tl;dr; (0)

Anonymous Coward | more than 5 years ago | (#27042911)

Could some summarize the review using one word or less?

Thanks.

Re:tl;dr; (3, Funny)

ianare (1132971) | more than 5 years ago | (#27043127)

Not a problem. It's in my own word though.

PHPisaninherentlyinsecurelanguagesousecaution

How to write a secure PHP app (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27042941)

Rewrite it in .NET

That is all.

Re:How to write a secure PHP app (1, Funny)

Anonymous Coward | more than 5 years ago | (#27042977)

Of course. The best way to make anything secure is to use Microsoft tools and become one yourself.

Are you for real?

Re:How to write a secure PHP app (2, Insightful)

cbiltcliffe (186293) | more than 5 years ago | (#27043361)

Are you for real?

No. Otherwise they wouldn't have posted AC. .....just like you.

Re:How to write a secure PHP app (0, Redundant)

ianare (1132971) | more than 5 years ago | (#27043081)

AAaaww what a cute little troll. I was just about to feed you.

Use .NET instead (3, Funny)

Anonymous Coward | more than 5 years ago | (#27043001)

PHP has been bloated since 1.5, and the new .NET libraries offer improvements over all of PHP's core services. Why bother trudging through the maze of PHP gotchas, when .NET security is just a wizard away?

Re:Use .NET instead (1)

MightyMartian (840721) | more than 5 years ago | (#27043227)

Um, because some of us want to write portable apps that aren't dependent on a single vendor, and don't want to be double-screwed by the forever-not-quite-up-to-date Mono libs. There is a world beyond Microsoft, and besides that, people in glass houses shouldn't throw rocks. I wouldn't exactly go to Microsoft for security.

But I agree that PHP sucks, it's the BASIC of this decade. It's a godawful mess of a language that simply permits idiots too much capacity for getting ill-running programs up with little or no thought to security, to disciplined programming or anything else.

Re:Use .NET instead (0)

Anonymous Coward | more than 5 years ago | (#27043395)

PHP is just as dependent on a single vendor as .NET.

Re:Use .NET instead (1)

MightyMartian (840721) | more than 5 years ago | (#27043559)

Not really. I can get the source for PHP and do what I like with it. Mono is not in the same category, by any stretch.

Re:Use .NET instead (1)

tepples (727027) | more than 5 years ago | (#27044073)

Not really. I can get the source for PHP and do what I like with it. Mono is not in the same category, by any stretch.

What do you mean? Mono is free software [mono-project.com] .

Re:Use .NET instead (1)

MightyMartian (840721) | more than 5 years ago | (#27044273)

And Mono is, to one extent or another, a reverse-engineered product. You're now not only reliant on Microsoft, but also on the Mono project's ability to get it right. Mono is not .Net, and quite frankly I think there are enough questions about legal encumbrance that I would never use it.

Re:Use .NET instead (1)

Ninnle Labs, LLC (1486095) | more than 5 years ago | (#27044317)

And Mono is, to one extent or another, a reverse-engineered product.

And that stops you from grabbing the source and doing what you like with it, how?

Re:Use .NET instead (0)

Anonymous Coward | more than 5 years ago | (#27044013)

PHP it's not the best language, but almost any language well used with a good design will produce a good app. Depends on the programmer.

I've seen a lot of good apps made in PHP.

Script kiddies editing ready-to-install apps are not programers and only make shit out of any app.

Re:Use .NET instead (5, Funny)

NotBornYesterday (1093817) | more than 5 years ago | (#27043259)

Security from a MS wizard? Maybe they could teach Clippy to implement security in development!

Hi there! It looks like you are passing user input to an SQL statement. Would you like to:
A) Sanitize your input before going any further.
B) Sanitize, schmanitize, just code that sucker together. We'll iron out the kinks later.
C) Huh? Why would that be a problem?

Re:Use .NET instead (0)

Anonymous Coward | more than 5 years ago | (#27043325)

Surely you jest to suggest that a wizard is the answer to security?

Simpler method (0)

Anonymous Coward | more than 5 years ago | (#27043083)

Simpler method than reading this book:
  1. Use Drupal
  2. When writing modules always ensure you use Drupal's API, particularly for paramaterisation of Database queries and such. Check http://api.drupal.org/ [drupal.org]

Re:Simpler method (1)

ianare (1132971) | more than 5 years ago | (#27043437)

It's true that using frameworks makes things a lot easier, especially for filtering and validation. But a good understanding of why certain things have to be done is more important in the long run. I've seen the best frameworks destroyed by programmers bypassing major security precautions out of laziness or for "performance tuning".

Can you just block by country? (3, Funny)

tjstork (137384) | more than 5 years ago | (#27043163)

A lot of bogus traffic comes from countries that don't offer much in commercial value. I'm wondering if you could just configure Apache to just refuse connections to certain countries, or take them to an alternative page. Like, "404, We're sorry Russia, but you have too damned many crooks."

Even still, one wonders if ISPs offer that service as well.

Re:Can you just block by country? (5, Funny)

myVarNamesAreTooLon (1474005) | more than 5 years ago | (#27043311)

That would work well, people from other countries would NEVER think of spoofing their address.

Re:Can you just block by country? (1)

Chandon Seldon (43083) | more than 5 years ago | (#27043315)

This is a bad idea.

The only thing it might stop is automated scans, and your application shouldn't have those holes to begin with. It'll have basically no effect on targeted attacks (attackers know about proxies), and it will annoy the hell out of the - unknown number of - visitors you would have from these countries.

Re:Can you just block by country? (5, Funny)

InsertWittyNameHere (1438813) | more than 5 years ago | (#27043393)

Ok, but that might backfire. Take this hypothetical situation as an example:

Let's say a Nigerian prince recently became the beneficiary of a large sum of money. Now in order to access that money he needs someone to lend him some seed money in order to fund the process to facilitate the release of said money. In return for the help, he promises to reward the lender generously.

If he can't reach you with his urgent message YOU will be the one losing out!

Re:Can you just block by country? (1)

neoform (551705) | more than 5 years ago | (#27043471)

Get an IP2Location database, there's a bunch of free ones on the net. Then do a lookup based on $_SERVER['REMOTE_ADDR'] at the beginning of all your scripts.. there might be an apache mod for this, but I've never used such a thing.

Re:Can you just block by country? (1)

clarkkent09 (1104833) | more than 5 years ago | (#27043663)

A lot of bogus traffic comes from countries that don't offer much in commercial value.

Depends on what you're selling. If your products have global appeal, you might well be losing some customers from Russia. I have setup and maintained credit card processing system for a number of sites and in my experience about 95% of customers are from USA and Europe, the remaining 5% split between Australia, Japan, S. Korea, Russia, Israel, and very occasionally a South American or one of the wealthier Arab countries. So I guess it is possible that you can exclude some countries and not lose much, but it's not as easy as you think. You also may lose reputation if you are a serious company and people see a message like that pop up due to failings with IP geolocation or simply because your client went on a trip. IMO it also makes the internet a sadder place. Imagine if such practice became widespread and every site started excluding traffic on country by country basis based on what commercial value each country represents. Given the numbers I mentioned above, most of the world would effectively be cut off from the internet, except for their local sites.

Re:Can you just block by country? (0)

Anonymous Coward | more than 5 years ago | (#27043835)

You can add an ip filter, every coutry has a segment assined, so probably you can do someone like that

Re:Can you just block by country? (0)

Anonymous Coward | more than 5 years ago | (#27044527)

I've had a few customer request that their server be configured this way, and I would bet that doing so has blocked an enormous number of attacks. Yes, you can spoof IP addresses, but from what I've seen, almost all successful attacks on servers are from foreign IP addresses in either Russia, China, or Brazil.

Re:Can you just block by country? (0)

Anonymous Coward | more than 5 years ago | (#27044611)

I'm guessing this is precisely the kind of idea that a book on security might say is a really, really, really bad one.

inherently insecure.... (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27043249)

"Tricia and William Ballad argue that PHP is an inherently insecure language"

If it was inherently insecure you could never secure it, I rather think that is it up to the developer to set his security level - the language does not offer any false promises of being secure (which is probably a best practice as any developer should be more aware how in/secure their apps are and know how to secure them better).

We've seen that closed source models that touted secure system (or my favorite, "improved security") aren't always and then the poor developers on such platforms can't do much but wait for those powers-that-be to do their "magic" and fix their security, and may not know if it was really fixed or not.

"inherently insecure" is a bad phrase (1)

MattW (97290) | more than 5 years ago | (#27043699)

One might be charitable and infer they meant that PHP is inherently insecure, as in - if you don't take steps to properly write secure code, it won't be secure. But is that true of any language used in web programming? You're providing a service often trusted with secure data to a bunch of effectively anonymous clients.

PHP has a pedigree which includes a lot of poor design decisions about security, but it certainly is very much possible to write secure PHP code, and lots of places do it.

Re:"inherently insecure" is a bad phrase (1)

MrHorse (1490495) | more than 5 years ago | (#27044145)

its true for _any_ language. If you don't break your program before you make it available to the public, you're just asking for someone to pounce all over it.

Security should be addressed on both ends of the spectrum...the server side (developing a solid tough to crack nut of a server side app) and client side ( developing a secure unbreakable client side app). unfortunately, in the commercial world, deadlines and such limitations plague this to no end...thus sloppy insecure code from deadline pressed coders.

what no AJAX (3, Informative)

ianare (1132971) | more than 5 years ago | (#27043327)

AJAX is probably the biggest security hole, even in a well designed application. Be especially careful when the AJAX does a DB update/insert - sometimes all the attacker needs is the JS code (obviously not secure) to see what url to hit and what parameters to send.

I find it very disappointing that this book doesn't cover that. Even if not an in-depth analysis, which could well require its own volume, at least a chapter on basic concepts.

Because otherwise PHP security is actually pretty simple. There's only 3 major rules :
Never trust anything from outside : filter/validate all user input.
Don't display error messages on production servers.
Wrap system binaries in scripts rather than executing them directly.

Re:what no AJAX (5, Insightful)

dedazo (737510) | more than 5 years ago | (#27043371)

Be especially careful when the AJAX does a DB update/insert - sometimes all the attacker needs is the JS code (obviously not secure) to see what url to hit and what parameters to send.

Well yes, but usually you're doing cookie-based authentication, which flows with out of band requests as well. So it's no different than a normal POST operation. Ajax is not particularly less or more secure, unless you have an insecure app to begin with.

huh? (0)

Anonymous Coward | more than 5 years ago | (#27043617)

attackers can see regular requests in plain sight too. ajax is nothing special when it comes to securing applications.

Re:what no AJAX (4, Insightful)

truthsearch (249536) | more than 5 years ago | (#27043735)

I don't understand your point. From the server's perspective an AJAX request is identical to any other. So how does securing your server change if the request is AJAX?

Re:what no AJAX (1)

drspliff (652992) | more than 5 years ago | (#27043971)

Because developers forget that just because somethings hidden in thousands of javascript and never invoked directly by users doesn't mean that it won't be a target, if anything it makes it more of a target because us security folks have long since picked up on that :)

Re:what no AJAX (2, Insightful)

SatanicPuppy (611928) | more than 5 years ago | (#27044091)

The number of people who don't know how to lock down a database astounds me. Whitelist IPs, use low privilege users, never re-use users between applications.

If you screw up your injection scrubbing, and someone sends in a "Drop tables" injection on a user who doesn't have those permissions, there's no issue. Likewise, lock the user down so it only has access to specific data...Never give a user the ability to touch a system table if they're used for a public app.

I don't allow deletions most times, I just add a delete flag to the record, and use an account running locally to do the deletes later...Someone tries to delete a whole table, row by row, and I can catch it before it happens.

Securing your code is necessary, but it shouldn't be your primary line of defense. Start at the server and work your way back.

Re:what no AJAX (1)

MightyMartian (840721) | more than 5 years ago | (#27044343)

This is a pretty damned good component, and goes to show you that security should be thought about like layers of onion. Due diligence at every layer means that even if worst comes to worst (say, there's a serious flaw in the interpreter itself), that there's something below that that can catch, or at least minimize the extent of the breach. Having your app access a user with privileges like "drop table" is nuts, no matter whether you think you have ironclad security on the app itself.

Re:what no AJAX (1)

ianare (1132971) | more than 5 years ago | (#27044255)

Securing the server doesn't change, and if you follow proper security guidelines you will be generally OK. It's just that AJAX does add complexity, and any time complexity increases, so do potential exploits.

For example some devs will forget that the return needs to be tested not to contain potentially dangerous information ... things like DB structures or users, info only visible to certain users, etc. Quite often this may be debug info that needs to be turned off on production, but because it's hidden under a layer of JS, people forget.

Re:what no AJAX (1)

dblackshell (1450807) | more than 5 years ago | (#27044281)

I would add to those:
  • don't filter/validate using regular expressions unless you know what you're doing.
  • don't give too much power to the user (of course it will abuse it)...

inherently insecure? (1)

gsgleason (1241794) | more than 5 years ago | (#27043545)

What makes php more inherently insecure compared to other scripting languages that a web app might use? There are plenty of functions to "sanitize" input and satisfy the other "major rules," so why is php scrutinized more than others?

Re:inherently insecure? (0)

Anonymous Coward | more than 5 years ago | (#27043775)

There are some scripting languages that do a lot of sanitizing automatically... In order to get at "unsanitary" contents, you have to access a function. One example is Coldfusion (mostly dead scripting language at this point)

Re:inherently insecure? (5, Informative)

benjymouse (756774) | more than 5 years ago | (#27043811)

  1. Culture. For a long time the mysqli library did not allow the use of parameterized queries leading to the unhealthy culture of concatenating or interpolating sql queries and even "require" arguments.
  2. Easy entry with little architectural guidance which leads beginners down the dangerous paths.
  3. Poor design decisions such as (just examples)
    1. the ability to "require" scripts from foreign servers.
    2. stupid type coercion such as 1 == "1more" is actually true.
    3. super-weak type system, meaning that you can never trust what you expect to be an integer to be just that.
    4. stupid attempts to accomodate developers and save LOCs by introducing "magic quotes", superglobals and the ability to "automagically" map query parameters to global variables.
  4. The fact that PHP is merely a glue layer, relying on binary extensions written in C with the usual buffer overflows, memory corruptions etc.
  5. etc etc etc

Re:inherently insecure? (0)

Anonymous Coward | more than 5 years ago | (#27044705)

The truth sure does hurt.
But PHP is ... ! ... ::sigh::

Use a framework (1)

Anonymous Showered (1443719) | more than 5 years ago | (#27043681)

I use CakePHP personally: sanitizes data and offers me ACL out of the box.

Can someone explain (1)

MyLongNickName (822545) | more than 5 years ago | (#27043725)

Why securing a PHP application would be any different than securing an application written in any other language. I mean is PHP really the only language where you need to sanitize database inputs? Or is this just another principles of security where they inserted code snippets from [insert your language here].

Re:Can someone explain (1)

seebs (15766) | more than 5 years ago | (#27043859)

Probably more a question of "since you're probably writing in PHP, here's some security stuff". PHP's not my favorite language for security-related things; it doesn't necessarily do much to encourage or help with sanity checks.

Get Chris Shiflett's book instead (5, Informative)

MattW (97290) | more than 5 years ago | (#27043761)

What qualifies these authors to even write on these topics? Do they engage the community of PHP developers at all? Do they have the exposure to enough environments and circumstances and code to be effective authors on the topic?

Chris Shiflett is the CTO of OmniTI, arguably one of the biggest PHP development braintrusts around. Several of the Schlossnagle family work there (and it used to include George, who wrote the awesome Advanced PHP Programming. Chris wrote Essential PHP Security, and also maintains a blog that has a lot of good stuff.

If I was buying one, I'd buy Chris's book.

No language is secure (1)

mlwmohawk (801821) | more than 5 years ago | (#27043885)

PHP is not inherently more or less secure. That's just marketing language to get you to buy the book.

All public access to systems via any language creates potential security holes, ESPECIALLY when terms are accepted from users and used in conjunction with database queries.

One of the biggest risks, and we are ALL GUILTY, is the use of things like printf to construct a query line. Technically, you should prepare a statement and then execute the statement using the parameters as terms. Not only is this faster, it eliminates the possibility that the terms will be parsed by the query parser as they are passed to a pre-parsed query.

Even "good" sites have to be monitored for abuse because jerks post viagra and porn links in almost every blog. Captcha is good for that, but it doesn't work 100% of the time and its getting worse.

Re:No language is secure (1)

dblackshell (1450807) | more than 5 years ago | (#27044365)

till know I didn't see a bot which could solve a reCAPTCHA ?!

Re:No language is secure (1)

Qzukk (229616) | more than 5 years ago | (#27044485)

is the use of things like printf to construct a query line.

That's just dumb. If you're going to go through the trouble of getting everything in just the right order for printf to fill in those %s placeholders, what the heck are you doing using printf?

I can understand
$sql="SELECT * FROM foo WHERE day<='$maxdate'";
because then at least you have the excuse of adding on a
if ($mindate) { $sql.=" AND day>='$mindate'"; }
which back in the bad old days of using "?" as placeholders in a prepared query would have been impossible without turning your execute call into a candidate for the dailywtf of the year.

Inherently Insecure... (0)

Anonymous Coward | more than 5 years ago | (#27044159)

Do they actually argue this? I didn't read the book and I only glossed over the review but I didn't really see anything that suggested these problems were inherent to using PHP.

The only "inherent" problem with PHP is that it's incredibly easy to pick up as a starter language. There is nothing really intimidating about PHP, and gettign your "hello world" running is quick, easy, and free (generally). This allows every newb and their little newphew to create websites for their family and employers...(Not that I haven't seen epic POS' out of pro java-shops)

Community more unsecure than the language (1)

daeg (828071) | more than 5 years ago | (#27044323)

The community and fleet of developers available to PHP is far and away the more vulnerable than register_globals could ever be.

Modern code bases, books, and examples are STILL being written using string concatenation to build SQL! These examples are teaching these dated, insecure methods to novices, thus guaranteeing these horrible practices will propagate for a long, long time.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?