Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

Pro PHP Security 105

Posted by samzenpus from the keep-it-secure dept.
Michael J. Ross writes "The global accessibility of Web sites is a double-edged sword: At the same time that your online e-commerce site is open for business to anyone with an Internet connection, it is also open to malicious attack. Web sites based upon the popular language PHP, are no exception. Thus, it is both astonishing and worrisome that there are currently so few books devoted to PHP security — particularly ones that go beyond the handful of typical security countermeasures discussed in articles. Fortunately, Pro PHP Security, written by Chris Snyder and Michael Southwell, is intended to fill this critical need." Read the rest of Michael's review.
Pro PHP Security
author Chris Snyder and Michael Southwell
pages 528
publisher Apress
rating 9
reviewer Michael J. Ross
ISBN 1590595084
summary A comprehensive guide to developing secure PHP-based Web sites.


Pro PHP Security spans 528 pages, consisting of 24 chapters organized into four major parts. The first part, comprising only one chapter, explains the nature and significance of computer security, and reasons as to why absolute security is an unattainable goal. Nonetheless, it is worthwhile to take all appropriate and reasonable security measures, and the authors provide a brief overview of the different types of attacks to which Web applications are vulnerable.

On their Web site, Apress has a page devoted to the book, where they offer the book's source code (in a Zip archive file), the table of contents, corrections to the book (i.e., errata), and a sample chapter (Chapter 12 - Preventing SQL Injection) in PDF format. In addition, there is a link for any reader who would like to purchase this title as an e-book.

One of the most laudable aspects of Pro PHP Security, is that the authors — both experienced software and Web site developers — go far beyond the standard PHP security advice of validating and escaping user input, etc. Those topics are covered in depth, but they are provided in the context of thorough discussions as to how to set up a secure environment in which to use those techniques. In addition, the authors present best practices that have evolved over time, as Web masters and system administrators have learned — often the hard way — the general types of attacks to which their Web sites and computer networks have been subjected.

In fact, Snyder and Southwell hold off on presenting the aforesaid specific PHP security techniques, until the third part of the book. Prior to that, they explain the characteristics of a secure online computing environment, such as using encryption, securing network connections via SSL and SSH, controlling access via authentication and permissions, and other important topics. Their coverage of the subject matter is complete, without being overwhelming. For instance, the material on encryption is helpfully divided into two separate chapters — devoted to theory and practice, respectively. Consequently, a PHP application developer or system administrator can immediately dive into the authors' recommended practices for encoding sensitive data, without getting bogged down in the theoretical underpinnings, if the reader is in a hurry to implement encryption on their own systems, or simply has no interest in the theory behind the methods.

As noted earlier, Part 3 of this monograph explains all of the well-known techniques that crackers use for attacking PHP-based Web sites, as well as the countermeasures that should be adopted by the developer or maintainer of the site. First up is validation of user input, which — though being essential to basic security — is still neglected on far too many Web sites. The attention to detail seen in this discussion is also reflected in the subsequent chapters, which cover SQL injection, cross-site scripting, remote execution, temporary files, and session hijacking. For each topic, the authors explain how the typical attack is attempted, and what needs to be done to prevent such attacks.

The fourth and last major part of the book covers vitally important topics that are usually glossed over in most PHP security books, or neglected altogether. Snyder and Southwell explain methods of limiting access to your Web site to humans (thus minimizing attacks that employ scripts), verifying the identities of those users, authorizing what those users can do on your system, and tracking their actions once they have logged in. The authors also explain how to reduce the chances of data loss, and how to execute system commands and make remote procedure calls without exposing your site to vulnerabilities. The last chapter covers the benefits to be gained from opening up your site and its source code to a review by your technical peers.

This book has much to recommend it: The discussions of security issues are more complete and thorough than in any other book that I have seen. The information chosen by the authors is detailed enough to be understandable and usable, but not so excessive as to prove daunting or discouraging to the reader who needs answers to their security questions, and does not have the time or inclination to slog through academic or pointless discussion. The information is well-organized, and presented in context, so the reader is not simply given a laundry list of security techniques, but instead better understands the rationale behind them. Lastly, because no technical topic can be covered in full in a single book, the authors provide a generous number of references to outside resources.

The content of this book appears to have only one noticeable weakness, and that is the poor quality of the comments in the sample source code. Not only are they few in number and lacking in detail, but they are written in all lowercase letters, with little to no punctuation. This coding style results in the comments visually blending in with the code itself, and makes reading both to be more difficult than is justifiable.

The physical book itself also has only one weakness, and that may only apply to a portion of the copies produced and distributed by the publisher. Specifically, the bottom and side edges of the book are cut cleanly, while the top edge is quite rough. As I was unable to find any mention within the book as to a possible reason or advantage for having the rough edging on top of the pages, I can only conclude that it was not intended on the part of Apress, and represents an error in production. I hope that the copy that I received — kindly given to me by the publisher — is not representative of all the copies produced and sold.

In spite of these minor complaints, I was quite pleased with this book. Pro PHP Security is arguably the most comprehensive PHP security book available, and is highly recommended to any developer or administrator of a PHP-based Web site.

Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com."

You can purchase Pro PHP Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Pro PHP Security More

Pro PHP Security

Comments Filter:

  • Observation on Competitors (Score:3, Informative)

    by SB_SamuraiSam ( 962776 ) * on Wednesday July 19, 2006 @03:42PM (#15745663) Homepage

    Here is an observation: With all the publicity Ruby on Rails [rubyonrails.org] and other frameworks like Zend Framework [zend.com], Turbogears [turbogears.org] and the like are receiving these days--why are we not seeing an innumerable number of security trolls like Chris Shiflett on the *framework side of web development? My thoughts are that PHP users are told "you can too" when in many cases, with forums other resources like the ten gazillion books, they *can*, to an extent (but either with really bad help or books assuming the reader is not working on a *real* project).

    Conversely, Rails, Turbogears and Symphony are, too, saying "you can too." Yet, where are the security trolls? It seems though that the *actual* users of the *frameworks, the ones using them for real-life projects are those who have struggled with PHP and (perl, python, etc...) CGI programming for so long and decided "fuck it." Things like database abstraction (and therefore quoting, etc), single-entry-point, and template-safety are, in the most part, taken care of for you.

    P.S. XSS is not a PHP problem!

    • The problem I have with stuff that is "taken care of for you" is that it's pretty difficult to find out afterwards whether or not the framework forgot something and if they did, it creates a much larger set of vulnerable hosts. Of course Open Source is taking care of that so a fix is quite quick, but how much house/garden/kitchen programmers do actually upgrade their stuff once deployed?

      A good programmer can also make mistakes, but if there is a decent thinking person and a small plan, then it will imho be
      • I dunno. I don't think you can generalize like that.

        For example, Microsoft's infamous Foundation Classes (MFC) relies heavily on IDE wizardry and arcane preprocessor abuse to make things "simple".

        On the other end of the spectrum, RoR just generates straightforward code using a sensibly chosen patterns. If somebody handed you the output of RoR, and you'd never heard of RoR, it would be perfectly readable and maintainable. RoR (or any framework for that matter) can't solve your problems for you; from what I

      • ...if you have a problem, you can take care of it yourself because you know how you think.

        Unfortunately, this is not a luxury that some website owners/creators have the luxury of...

        On a more serious note. At lot of sites are "set it and forget it." Probably less that actually do e-commerce (or any volume of it). But I even do it every now and then...I just updated my libraries and packages, so its all good, nothing to worry about. Then a week goes by, a month...and the window is opened.

        Maintaining

      • Yes, but "knowing how you think" isn't ideal when working with a group of developers. To place that thought in more technical terms, it becomes a "cluster fuck."
      • it's pretty difficult to find out afterwards whether or not the framework forgot something

        Forgot?!?!

        Besides the SQL insertion hype, there are many web applications that serve inserted content into documents without any further validation. There was an article about RFID, " Virus Jumps to RFID [slashdot.org]," and it is like RFID in this sense of validation. Someone scans, or http-gets, for data and it is served. The data actually might come from the expected object/webserver, but there may be other data inserted al
    • All I know about Ruby on Rails is that every other week I can't view the Penny Arcade [penny-arcarde.com] comic. It's not exactly a stellar endorsement for Rails or the development company that did the site. I mean sure it looks nice, but half the time I go there I get an error message and no comics.

  • No exception? (Score:4, Funny)

    by ShaunC ( 203807 ) on Wednesday July 19, 2006 @03:44PM (#15745692)
    Web sites based upon the popular language PHP, are no exception.
    That was addressed in PHP5... ;)

  • Dueling Oxymorons (Score:3, Funny)

    by kelzer ( 83087 ) on Wednesday July 19, 2006 @03:52PM (#15745754) Homepage
    Wow "Pro PHP" and "PHP Security" both in the same title! (Just kidding! I know PHP is really the web development platform of choice for professionals, and is incredibly secure!)

  • Top Edge PHP Attack (Score:5, Funny)

    by digitaldc ( 879047 ) * on Wednesday July 19, 2006 @03:55PM (#15745781)
    The physical book itself also has only one weakness...Specifically, the bottom and side edges of the book are cut cleanly, while the top edge is quite rough.

    This is because someone tried to do a physical attack on the top edge of the PHP Security book.
    However, the Page's Horizontal Periphery security kept it from getting through.
  • While only partly on topic, I have recently been wondering how to implement user/role management in PHP in a reusable, secure and performant way. I could do it myself, but using procedural programming/direkt SQL requests you quickly end up with code that is hard to reuse. Using O/R mapping seems to be not practical because a) no good solutions for PHP exist yet so it lacks performance and/or flexibility, and b) I need a solution that the end user can install without shell access, via FTP.

    Are there any secur

  • The problem with the alternatives to PHP (Score:5, Insightful)

    by baadger ( 764884 ) on Wednesday July 19, 2006 @04:07PM (#15745859)
    PHP as a language is outclassed by Ruby and Python, yet they aren't beating it back in the web arena. Why?

    Ignoring support by ISP's there is are two main reasons I think from the developers perspective,

    1) PHP's online documentation of both the core language it's standard libraries is comprehensive. I'm not even aware of where I could find documentation on Python libraries to communicate with MySQL, with PHP it's all shipped in the package and all documented in one place - php.net. One place I might add where users/developers can and do comment and actually make the documentation better and clearer (although some bad ideas get into the mix too, they are usually corrected by following comments). All the Python and Ruby documentation seems to be humped into two ends of the spectrum, 101 and web framework. Atleast this is the impression I get as someone once interested in Python for web development, after being spoilt for documentation at PHP it's just frustrating.

    2) PHP allows you to inline your code into your documents (as does ASP) providing a, nasty, dangerous yet incredibly easy route for people from a web design background to get into web development without any programming knowledge. As these users develop, some will become well seasoned and actually start to seperate code from design. The rate at which people are being introduced to server side scripting and indeed PHP is, in my opinion, probably increasing and there is always, for that reason, alot of unsavvy PHP users.

    It's also worth mentioning that to a certain extent, Ruby on Rails gems (which I haven't used personally) and Perl's CPAN solve some of the shortfalls, but Python seens way behind.
    • You seem to be overlooking the fact that Ruby and Python were not designed or primarily intended as web authoring languages, I know PHP has stumbled around and 'rediscovered' itself several times but its primary focus has always been web pages and web apps. You will see this start to change though, particulary for any sort of sizable web app as the frameworks built in Ruby and Python become more sophisticated.
    • Of all the guides and intros I've read, I don't think I recall getting a good intro on how to do MVC in PHP.
      • Check out Smarty [php.net]. MVC in PHP is something that, like many other C-derivative languages, is not forced. The writer has the option to ignore MVC completely. Just follow any old guide to the generics of MVC if you don't want to use a template engine. It really isn't that hard...
    • For what it is worth, I find the PHP documentation to be of poor quality. The fact that comments even exist in documentation points to an attempt to fill the gap. Unfortunately, the comments are frequently useless, and oftentimes harmful. I've had the misfortune of having to use PHP to repair existing systems, and I can definitely say I find the documentation for other languages to be vastly superior.

    • Re:The problem with the alternatives to PHP (Score:4, Insightful)

      by Bogtha ( 906264 ) on Wednesday July 19, 2006 @04:33PM (#15746030)

      Ignoring support by ISP's

      That's the #1 issue by far. Even if all the competition were ten times better than PHP, if the average person can only find cheap PHP hosting, that's what they are going to use.

      I'm not even aware of where I could find documentation on Python libraries to communicate with MySQL

      Seriously? Go to python.org. Scroll down the page to where you see the "Using Python for... databases" link. Click it.

      There's another point - Python modules come with help built into them, and Python comes with a help browser [incutio.com]. And if you don't want to use that, just load the Python interpreter and run help(module). I don't think PHP has anything similar to that yet.

      PHP allows you to inline your code into your documents

      So does mod_python [modpython.org].

      • The link you provide for the help browser leads to a blog post for which the first statement is

        "Pydoc is awesome; I don't know how I missed it for so long".

        I think this only puts emphasis one of my points. Thanks for the links, I will be investigating Python myself thoroughly at some point, but my post is based on initial impressions of web development in other languages, something I think is obviously vital for the uptake of a language in web dev.

      • if the average person can only find cheap PHP hosting, that's what they are going to use.

        Well, my host runs mod_perl, and my local server runs mod_perl. I'd gladly learn to use Perl, if only I could figure out how to run a Perl script. With PHP, I simply suffix a file with .php, and any code between PHP tags will be executed. Apparently, it's not this simple with mod_perl.

        With bash, all I have to do is put #!/usr/bin/perl at the start of the file. But no matter what I try, I can't get Apache to execute a

        • how about you configure your webserver? even PHP needs to be plugged in to "simply suffix a file with .php, and any code between PHP tags will be executed" -- it does not automagically work.

          • What? My webserver? As in, the one owned by the company who provide my hosting? Are you suggesting that I root their datacentre and reconfigure my account on the sly? Are you suggesting that they advertise themselves as providing mod_perl while leaving it completely unconfigured?

            PHP has worked out of the box on both hosts I've used, and on every version of the XAMPP [apachefriends.org] package I've installed. Even on the vanilla Slackware Apache setup, all I have to do is uncomment the PHP line in /etc/apache/httpd.conf.

            As f

      • Seriously? Go to python.org. Scroll down the page to where you see the "Using Python for... databases" link. Click it.

        Funny, I just did this and couldn't find it. I ended looking at some sourceforge boilerplate. I think the OP was pointing out that PHP has comprehensive and *consistent* documentation.
        • You're kidding, right?

          I just did the same thing. There's a sidebar named "Using Python for..." on the right hand side. "Databases" is the second entry:

          # Databases
          # ODBC, MySQL, Others

          How much easier does it have to be to find?

          Oh, wait. You don't like the fact that it links directly to the site for the plug-in, I take it. Too bad. If you had bothered to check the "Docs" link on the Sourceforge page, you would have seen a link to "How to Use MySQLdb", which states:

          "MySQLdb is compliant with the Python Da
    • You've really missed only one major point, and that's installation.. specifically of projects rather than languages. Installing an existing PHP application is as simple as tar -zxvf. There's no need to edit fcgi/rb files to set paths, setup something specific with Lighty that's different from any other website, et cetera. It has no entrance exam, no setup time. At the same time, however, I feel that documentation is the single greatest factor. PHP.net is nothing short of amazing, and other, "better" fram

    • PHP as a language is outclassed by Ruby and Python, yet they aren't beating it back in the web arena. Why?

      1. Ruby is a bitch to get working with apache. You've got to either run fastcgi (which is out of date), or proxypass to another webserver. They need to fix mod_ruby so that each instance doesn't share namespaces.

      2. Python is stable, but the modules are too fragile. The API for libxml2-python has changed several times... breaking any scripts using it.

      • fastcgi out of date? It still works well.

        It's a simple and fairly clean way to accelerate CGI style apps. It's so simple it doesn't usually need to be changed even if your webserver changes.

        You can run your fastcgi apps on apache and zeus.

        The apache mod_xxx stuff is more likely to give you problems.

    • I would say that as a language (talking about the syntax) I prefer php over ruby and python

    • At least for me, PHP was easier to learn than Ruby or Python because it borrows a lot of concepts from C++ and C. The learning curve for a language is really important in its acceptance because it's great to be able to use knowledge you already have to enter a new field (for me, web applications).

  • Chris Snyder is a liar and a fraud. (Score:1, Interesting)

    by Anonymous Coward
    He doesn't know anything about security. For years he told people to use addslashes() to protect against SQL injection, even though dozens of people pointed out that he was wrong, he simply deleted such comments on his blog. After someone finally made their own site just to warn people about this charlatan, he finally went back and edited his old comments to hide his bullshit, and make it appear as though he never advocated addslashes().

  • I've owned this book for a while (Score:3, Informative)

    by Fozzyuw ( 950608 ) on Wednesday July 19, 2006 @04:46PM (#15746131)
    I've owned this book for a few months now.

    It's a good book to get started with PHP Security ideas. It has a lot of theory and explains a lot of issues. However, I don't like the examples or how the book uses the examples.

    Often times I would have like to see a larger scale project outline shown, instead of just the theory. But, it was worth the purchase.

  • Save $15.30 by buying the book here! (Score:1, Interesting)

    by Anonymous Coward
    Save yourself $15.30 by buying the book here: Pro PHP Security [amazon.com]. And if you use the "secret" A9.com discount [amazon.com], you can save an extra 1.57%! That's a total savings of $15.77, or 35.58%!
  • Do not use global variables and claim tha you are an experienced php developer.. Unless you fell liek having yoru server compromised and everyone laughing at your sorry ass.. And avoid web app software that does, RadBids comes to mind..

  • PHP Security in 5 sentences, Not 500 Pages (Score:3, Insightful)

    by KidSock ( 150684 ) on Wednesday July 19, 2006 @09:28PM (#15747318)
    No doubt user's need to be very careful but you don't need a 528 page book to describe how to escape reserved characters in your input and sql. I can summerize what you need to do right here with one use case. The use case is accepting an HTML form text field input and using it in an SQL statement.

    First, you trim() and strlen() to make sure you have something. Then you use ereg to validate the hell out of it. Then you use the following function: // pardon the horrible formatting, it's a ./ problem // Quote variable to make safe
            function quote_smart($value)
            { // Stripslashes
                    if (get_magic_quotes_gpc()) {
                            $value = stripslashes($value);
                    } // Quote if not integer
                    if (!is_numeric($value)) {
                            $value = "'" . mysql_real_escape_string($value) . "'";
                    }

                    return $value;
            }
    to prep the input for inserting into the DB. Finally, you call that in conjuction with sprintf to build the SQL you're going to call like:

            $sql = sprintf("SELECT * FROM acct WHERE name=%s", quote_smart($name));

    This looks like a lot of work but in practice it's really not that bad. Also, every website must do this. It's not like there's something wrong with PHP. Some environments might abstract this stuff a little but frankly I'd rather do it explicitly so that I know exactly what's happening.
    • I think you just showed us why you need more than five sentences to describe PHP security.

      For one thing, you're not protecting yourself from URL-encoded strings.

      And since PHP doesn't yet support bind-variables (prepared statements) natively, looking at PEAR::DB [php.net] is a good idea; it saves you the hassle of quoting and whatnot.

      You're also not dealing with the problem of XSS, since you've failed to deal with output to screen.

      You are, in fact, not dealing with anything that's not related to MySQL.
      • Think you need to wake-up, since PHP 5 there is the PDO extension set which supports lots of DBs and there is also the MySQL(i) extension which stands for "improved" that has prepared statements. But you are right that PHP security doesn't hold in 5 lines, it's a matter of getting something generic and right once and for all and propagate that in the tutorials to the noobs that start using it every day.

        • Think you need to wake-up, since PHP 5 there is the PDO extension set which supports lots of DBs and there is also the MySQL(i) extension which stands for "improved" that has prepared statements.

          Okay, I didn't consider these to be "native" when I wrote it, but I can see how you might want to consider them "native", and I didn't think it prudent to mention database-specific interfaces.

          My recommendation for PEAR::DB is because it supports emulation of prepared statements for databases that don't support it na

    • How many effective SQL injection attacks have there been? Every time someone shows me an example of a SQL injection attack, it seems a bit contrived.

      Take the following as an example:

      bad_string="SELECT * FROM foo WHERE id=" + BAR_DATA_GOES_HERE
      EXEC(bad_string)

      Wouldn't the attacker need to know your data model pretty well. Wouldn't the attacker need a way of extracting the results of the query through HTTP response. In other words, what does a really good SQL injection attack look like? Sure, I could poss
  • I noticed that the under the related links section here it has a link to the book for $40 bucks if you are a B&N member, which I am not so i tried Amazon. I found it was $29.96 there with free shipping.

    -MS2k
  • If you work in PHP and you think that cleaning and escaping user input for SQL statements is all there is to writing and deploying secure code, then you are the person who most needs to study this book! I am just finishing up the last couple chapters myself and I agree with the positive review. I've been writing PHP code for money for a few years, and I picked up so much new information on the first read through that I believe a second will be in order soon. The book covers a very wide range of topics, pro

  • ... dive into [...] recommended practices [...], without getting bogged down in the theoretical underpinnings, if the reader is in a hurry to implement encryption ...

    Scary thought. If you are implementing encryption (or any security measure, for that matter), the last thing you should be in is hurry.

    • Pro
    • PHP
    • Security

    Choose two. ;)

Slashdot Top Deals

"No matter where you go, there you are..." -- Buckaroo Banzai

Close