Slashdot Mirror
Securing PHP Web Applications
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.
Securing PHP Web Applications
author
Tricia Ballad, William Ballad
pages
336
publisher
Addison-Wesley Professional
rating
7/10
reviewer
Michael J. Ross
ISBN
978-0321534347
summary
A wide-ranging guide to PHP security.
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.
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.
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Could some summarize the review using one word or less?
Thanks.
Of course. The best way to make anything secure is to use Microsoft tools and become one yourself.
Are you for real?
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?
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?
--- "When you gotta do something wrong. You gotta do it right. (Fighter)"
AAaaww what a cute little troll. I was just about to feed you.
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.
This is my sig.
"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.
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.
Are you for real?
No. Otherwise they wouldn't have posted AC. .....just like you.
"City hall" in German is "Rathaus" Kinda explains a few things......
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.
This issue is a bit more complicated than you think.
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?
attackers can see regular requests in plain sight too. ajax is nothing special when it comes to securing applications.
I use CakePHP personally: sanitizes data and offers me ACL out of the box.
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.
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].
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
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.
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.
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 - this is a CSRF link
$god = null;
if($god) echo 'I believe!';
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)
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.
Thanks for the plug for Secure Programming for Linux and Unix HOWTO. But I wrote it, not Bruce Schneier. Schneier has written other books, such as "Applied Cryptography" and "Schneier on Security".
- David A. Wheeler (see my Secure Programming HOWTO)
who advises people to not encrypt their wireless access points. So yes, let's quote him on all security matters.
Purely replying to a troll does not automatically mean you've been trolled.
Clippy is undressing me with his eyes. The sexual harassment lawsuit is ongoing. I don't think I could take security advice from someone like that.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I'm amazed you don't know that.
No, but taking blatantly obvious bait like "Linux Torvalds" sure does.
One technique for security is to limit the visible data to only what the web-app's DB login can access. For example, limit the app's login user-name to pre-defined read-only views, and stored procedures for the write stuff. Thus, if the hacker is able to inject her way into the SQL interpreter, she can only read and change what has been pre-allowed at the maximum, which is often only what the app allowed anyhow. It's a bit tedious, but that's the cost of security.
Table-ized A.I.
Who is this Linux Torvalds you keep talking about? Is that a new distro I don't know?
Linus Torwalds' firstborn son?
Only to idiots, are orders laws.
-- Henning von Tresckow
must preserve my resources . . .
resist the urge to flame back . . .
Really everything isn't
cloak and dager on the internet
PHP is a pretty damn good free language.
Ya, idiots. They are everywhere. Posting
their lame rants.
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?
If you just clicked option A, what would be the problem? I'm not following your logic.
Wow, that was one hell of a typo. It's spelled "First Post."
Hey, look! It's Bono's brother.
I'm *really* getting sick of people saying that programming language X is inherently insecure. It's total bullshit. EVERY language has its pros and cons and unless the INTERPRETER has an issue, then it's NOT the languages fault. And since EVERY INTERPRETER has had flaws in it, that can_not_ be the criteria for whether a *language* is secure or not.
In other words, STOP BLAMING THE LANGUAGE FOR THE FOLLY OF THE PROGRAMMER. Just because PHP has been used by some idiots does _not_ make it an "inherently insecure" language. Those idiots would make an insecure site regardless of language.
I would add as a security measure to be able to reinstall a web application from a recent backup immediately. Any place, any time, on a very short notice. Just have the recent backup ready to upload. Or even several of them, if one for some reason is corrupted.
I experienced an SQL attack which destroyed one of MySQL tables. I reinstalled it from backup and corrected the breach a month later. I mean a hacker most probably will not be watching your website day and night and attack it as soon as it is back online. Have it up online from a backup and correct the security issue later.
I would also question the mantra "security by obscurity". Sort of, never use home-made encryption, as it is "security by obscurity", use instead 3 or 4 existing implementations of encryption. Then I read about Vernam's algorithm http://en.wikipedia.org/wiki/One_time_pad . I tried to implement it in PHP and JavaScript. It is like 25 lines of code. And it is mathematically absolutely secure. What I think is that an existing encryption solution, which contains thousands lines of a convoluted code, may as well contain a hidden backdoor. While if one understands the mathematical model of an encryption algorithm and implement it himself, it makes it probably more reliable. I trust mathematics more then a vendor, even if seemingly reputable.
I mean they listen to phone conversations (it's the fact), would not it be a thing to expect that they read encrypted strings? I have nothing against it, until these eavesdropping capabilities diffuse to petty tugs next door.
The problem with php is that they made the insecure feature first, and told people to use it. Then they found out it was insecure and fixed it by making an other safer way to do the same thing.
Examples include the entire way mysql is accessed. First they made mysql_query which is very very difficult to make secure, because it require the developer to manually escape all
input that need to be escaped. (Not to talk about the fuckup with both having a mysql_escape_string() and then finding out it's not good enough, so they made a mysql_real_escape_string()).
Yes now they have pdo and preparedStatement but it took so long for them to make, that the insecure mysql_* functions are still the default and most mentioned.
And just look at all the magic options(Magic_quotes). Magic_quotes were added as a feature to make database access safe, because the php developers realized that the mysql_* functions were very difficult to use safely.
But they totally fucked up the design of the magic_* feature, so a program with magic_quotes sat to on, is now one of the most difficult things to make both safe and usefull.
So if you know exactly which part of php to avoid, then the rest of the language is not really insecure, but the part to avoid is mostly all the things that are mentioned(And thus used) most because it was the first thing they made.
Php need a feature to be compiled with ./configure --remove-all-the-features-we-the-developers-would-wish-we-had-newer-made
That way, you could install that version and atleast get a fatal error, each time someone used a function which should not be used. It would result in much better software, but that version of php would most likely not be able to run much predeveloped software.
Has had a book out for years that covers all this. The fact they wrote "PHP is inherently insecure" just goes to show how much knowledge the author lacks. XSS is not exclusive to any 1 language for instance. Various PHP frameworks protect you against SQL injection. Programming is a tool and every tool has potential for abuse ( fire, hammers ). Rant over.
Not everybody can afford specialists (yeah, sure, how did they become one...) so a comprehensive good practice guide will always be welcome.
IANAL but write like a drunk one.
Languages that allow you to do stupid stuff are less secure than the ones that don't.
It is that simple really.
Some languages were designed with expediency above any other concern (security included), so it is a fair assessment to make that there are some languages more secure than others.
IANAL but write like a drunk one.
Unless you saw that you could make a funny post about a troll post, then it is funny. :)
--- "When you gotta do something wrong. You gotta do it right. (Fighter)"
Only this one works in all languages:
1. Filter your input with a character white list
2. Limit your input size
3. convert input to the smallest character set possible
and finally
4. Use prepared statements (or stored procedures in conjunction with prepared statements) for all sql queries
Beyond that it's all host and database security.
Application security is Really Simple(tm):
Assume all input is malicious. Code accordingly.
The more powerful a language (whether scripting or not) is, and the more it opens up the underlying system, the more inherently dangerous it is. PHP is more exploitable than a lot of stuff because it opens up a pretty big chunk of C and available system libraries. This characteristic also makes it a powerful scripting language.
C is arguably the most insecure language of all, out done only by assembler. Guess what PHP (and just about the entire system) is written in? C. So it's just as accurate to say that operating systems, kernels and drivers are insecure ;)
I'm not saying they aren't, I'm just saying. The authors of this book are kind of framing PHP in the wrong light... EVERY single chapter in this book could be re-written for any language because they all have the same hazards.
-Viz
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
Why the need to obsess on errors that make no difference?