Beta

Slashdot: News for Nerds

×

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!

Pro PHP Security

samzenpus posted more than 7 years ago | from the keep-it-secure dept.

105

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 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.

cancel ×

105 comments

Observation on Competitors (3, Informative)

SB_SamuraiSam (962776) | more than 7 years ago | (#15745663)

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!

Re:Observation on Competitors (2, Interesting)

guruevi (827432) | more than 7 years ago | (#15745731)

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 just as good as those frameworks. The other thing is that you learn a lot and if you have a problem, you can take care of it yourself because you know how you think.

Re:Observation on Competitors (2, Insightful)

hey! (33014) | more than 7 years ago | (#15745862)

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've seen this is particularly true around security. But RoR is nice becauseit takes care of a some of the repetive work of your application in a way that doesn't create problems.

Thinking is the key concept (1)

suggsjc (726146) | more than 7 years ago | (#15746233)

...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 a secure site and code base is a constant battle. And again unfortunately again one that most tend to either forget or ignore.

Re:Observation on Competitors (1)

SB_SamuraiSam (962776) | more than 7 years ago | (#15746344)

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."

Re:Observation on Competitors (1)

Dzonatas (984964) | more than 7 years ago | (#15746492)

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 along with it. Did someone forget to check such inserted data?

Try to get a solid XHTML application to run on PHP. The problem is the PHP strings aren't easily validated when they are just kinda thrown into a document. If someone enters an ampersand and it echos to an XHTML page, it'll cause the client program to just display an error. With a nightmare of code, it is possible to get PHP to work well with XHTML. It is possible to test for the ampersand and properly handle it, but there are other environments without the code nightmare to do it.

Most of the HTML sent out over the web is not even validated before it is sent. The client app is left to validate it. However, how is the client app suppose to know where the source of the data came from a secure validation process or not? It just validates if the document is well-formed. Most HTML transitional processors don't even check if it is well-formed. They just display whatever it can figure out from what's given.

It appears that RFID is not the only application affected by such validation quirks. FUD or not, this RFID 'virus' example parallels a perfect picture of what happens with web pages. Both need more security.

Is it a problem with the webserver instead of PHP? The webserver is just designed to serve the content. A system like Apache could have a post processor to check every page before it actually is sent and detect security issues before it gets to the client. That still doesn't solve many issues. PHP or any other framework needs to validate the input. After you notice what needs to be done in PHP in order to get such validation secure, the competition does look greener.

Re:Observation on Competitors (0)

Anonymous Coward | more than 7 years ago | (#15748544)

If someone enters an ampersand and it echos to an XHTML page, it'll cause the client program to just display an error.
Only when the developers don't know what they're doing, there's htmlentities() or the tidy extension for PHP. I write apps that accept user input and produce xhtml strict all the time.

Re:Observation on Competitors (0)

Anonymous Coward | more than 7 years ago | (#15746710)

chris shiflet works on the framework side at zend framework. he may lack some social skills, but this doesn't change the fact that he's a gifted security engineer.

Re:Observation on Competitors (2, Funny)

tbannist (230135) | more than 7 years ago | (#15752144)

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? (3, Funny)

ShaunC (203807) | more than 7 years ago | (#15745692)

Web sites based upon the popular language PHP, are no exception.
That was addressed in PHP5... ;)

PHP is broken... (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#15745753)

At what point do PHP developers accept that PHP is broken and that it has been horribly designed from day one?

Re:PHP is broken... (1, Informative)

Anonymous Coward | more than 7 years ago | (#15745779)

I've found it very easy to pick up and learn for doing simple tasks with and without database interaction, and I have relatively little programming experience...

Re:PHP is broken... (3, Informative)

John Nowak (872479) | more than 7 years ago | (#15745846)

If you're getting the bulk of your programming experience from PHP, you have trouble ahead. :-) I realize that sounds like snarky crap, and it is to some extent, but it pays to sit down with a good book about the fundamentals of computing and programming design. Something like How to Design Programs (google it -- available free online), which makes use of Scheme, will make you ten times as productive when/if you return to PHP.

Re:PHP is broken... (1)

KIFulgore (972701) | more than 7 years ago | (#15746186)

Scheme? Stab me in the eye with a pointy stick. I can't program in a language where lines end with 5 to 15 closing parentheses ;).

Re:PHP is broken... (1)

John Nowak (872479) | more than 7 years ago | (#15746258)

You've obviously not tried. ;-) Regardless, the point of using Scheme for HtDP is that its simple syntax and semantics make it useful as a teaching language. The knowledge one gets from HtDP can be applies to any number of other languages.

Re:PHP is broken... (0)

Anonymous Coward | more than 7 years ago | (#15746248)

You know, I honestly have to agree with you. I've been coding in PHP for a few years now, and while I'm trying to learn C++ on the side, it's finally making me understand a lot of the concepts and basics. That would have come in handy.

Re:PHP is broken... (1)

xaraya (635792) | more than 7 years ago | (#15746506)

I'm guessing you mean this?

http://www.htdp.org/ [htdp.org]

Nice tip! (1)

-noefordeg- (697342) | more than 7 years ago | (#15746945)

Would be nice if people with similar tips could post some follow ups to parent.

Other books, albeit not free (to my knowledge):
-Design patterns : elements of reusable object-oriented software, Erich Gamma, ISBN: 0201633612
-Patterns of Enterprise Application Architecture, Martin Fowler, ISBN: 0321127420

Would really enjoy some more free information.

Re:Nice tip! (1)

John Nowak (872479) | more than 7 years ago | (#15747309)

Step 1: How to Design Programs (http://www.htdp.org/)
Step 2: Structure and Interpretation of Computer Programs (http://mitpress.mit.edu/sicp/)

Both are available online in full text from MIT Press. I personally feel everyone has something to gain from these books, even if you have twenty years experience. Not that I do yet -- It's a projection. :-)

Re:PHP is broken... (0)

Anonymous Coward | more than 7 years ago | (#15745850)

Well, just because it's easy to learn doesn't mean that it's well designed, does it?

Re:PHP is broken... (0)

Anonymous Coward | more than 7 years ago | (#15745913)

No of course not, however, that does not mean that being "easy to learn" should not be a factor that can go into a "well designed" language.

PHP: Get over it (1)

tehshen (794722) | more than 7 years ago | (#15749063)

Many people just use PHP because it's popular and because they can't be bothered to use anything else. Which is a shame, because it doesn't deserve to be, and many people should be much better than that.

I remember (ah, memories) when I discovered PHP. I thought it was brilliant. I could write dynamic web pages! Wow! I had variables, and for loops, and while loops, and all sorts. It was amazing! Then I got a database up and running, and could actually make a site, o frabjous day, calloo, callay! This was back when PHP was all I knew, apart from BASIC, which isn't saying much.

I was so impressed with what I could be doing with PHP that I overlooked all the things I didn't like. I didn't understand why the function naming was so inconsistent. Why sometimes my program couldn't see its variables. Heck, I was using hosting from Lycos Tripod, which was a complete pile of gibs, but it was worth it 'cause I could make dynamic web sites, and it was good.

We were happy, PHP and I. Why should I go and learn another language when PHP was accomplishing what I wanted just fine, thanks?

The answer is that I was lazy. Yes, I'm admitting that I was a big lazy fat-ass, to use a stupid term. I couldn't be bothered to learn another language, even though there were plenty out there. I thought that PHP was the best language there was. In the end, though, I gave in and dabbled in Python and Ruby, then gave up and went back to PHP again, then really gave in this time and went to Ruby for web development. (Then Rails came along... which was nice, though I'm not fond)

These days, I look at PHP and go "bleh". While it was alright to keep looking at the docs when I was learning the language, it's not right if I keep having to look at them several years later to find out what function to use. I look at some of the 'features' and wonder what the hell they were thinking. PHP is so inconsistent that I wonder if the coders talked to each other as much as the Slashdot editors do. (By the way, I don't see what's so special about the PHP docs. Sure, it's nice that they exist, but pydoc and perldoc and ri beat them any day)

Y'see, I'm done with PHP now. While it was nice of it to help me get started on web programming, I realised that it wasn't the only thing out there, and learning Ruby has improved my hacking ability by great amounts.

Even if you're 100% in love with PHP right now, please take the time to learn something else. Python and Ruby are popular for the right reasons these days. It doesn't matter what you learn: toss a coin, use what your favourite Slashdotter uses; they're both better than PHP and can both be used to make web sites with. Maybe you'll like one of them. They'll teach you new ways of doing things, and make you question the old ways, such as why you have to use for loops instead of iterating over a range. If not, learn one anyway. It'll do you good.

PHP is the right tool for the right task (0)

mangu (126918) | more than 7 years ago | (#15746882)

PHP is broken and that it has been horribly designed from day one


You are either not a professional programmer or a troll or both. PHP is the best available language if what you need is a simple way of creating dynamic web pages that handle database access. One sees so many people making so many claims about Ruby this or Ruby that, but have you ever tried to compare both languages? Forget closures and block parameters, you don't need that to create a dynamic web site. What you need is a simple syntax that works well with existing editors and code management tools, and PHP provides that. Using a database abstraction library such as Adodb and a good development framework, such as phpGroupWare, creating simple applications is faster in PHP than in any other language. And easier to maintain, too.


Of course, if what you want is to create a theoretical study on some esoteric programming task, by all means use your precious lambdas and closures or whatever resources you have in Ruby or Scheme, but if you need to keep a team of junior programmers chugging out simple enterprise applications you should choose PHP, the tool that gets the task done.

Re:PHP is the right tool for the right task (0)

Anonymous Coward | more than 7 years ago | (#15746958)

Uh... Maybe the best free language, but iHTML is far superior.

Re:PHP is the right tool for the right task (3, Insightful)

VGPowerlord (621254) | more than 7 years ago | (#15748205)

I noticed that, despite your diatribe, you never actually said that the grandparent was wrong.

The original poster has a point. I can think of a number of language features that were just plain bad ideas.

1. Providing an inconsistant programming environment, based on INI settings. This exacerbates the next two problems.

2. Having register globals turned on by default. First "fixed" in php.ini-recommended for PHP 4. Later fixed in php.ini-dist for PHP 4.2. Scheduled for removal from the language in PHP 6.

3. Having magic quotes GPC turned on by default. First "fixed" in php.ini-recommended for PHP 4. Scheduled for removal from the language in PHP 6.

4. Lack of a good database abstraction layer shipped with PHP. Although dbx and Pear DB both ship with PHP, neither is that commonly used. dbx due to being disabled by default; Pear DB due to its slowness. This is fixed in PHP 5.1 with the addition of PDO. Unfortunately, this is a case of too little, too late, as anyone who writes things for multiple DBs already uses ADODB or hand-rolls their own abstraction layer (coughphpBBcough).

Rather than waiting for a perl programmer to come along and post this url, I will: PHP in contrast to Perl [tnx.nl] . I know very well that this is slanted against PHP, but that doesn't make a lot of the comments in it any less true. Particularly since PHP 1 was written in Perl 5.

Re:PHP is the right tool for the right task (0)

Anonymous Coward | more than 7 years ago | (#15748391)

You are either not a professional programmer or a troll or both. PHP is the best available language if what you need is a simple way of creating dynamic web pages that handle database access.
Pure, unadulterated bullshit.

if you need to keep a team of junior programmers chugging out simple enterprise applications you should choose PHP, the tool that gets the task done.
How about a tool that gets the task done right, instead. You PHP fanboys are so funny. You simply have no clue about what real, enterprise software is. Did they teach you all about PHP at Devry?

Dueling Oxymorons (2, Funny)

kelzer (83087) | more than 7 years ago | (#15745754)

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!)

MOD PARENT FUNNY (0)

Anonymous Coward | more than 7 years ago | (#15745868)

eom

YES!!! I NEARLY WET MYSELF (1)

Unski (821437) | more than 7 years ago | (#15746019)

no, I didn't actually.

Re:Dueling Oxymorons (0)

Anonymous Coward | more than 7 years ago | (#15745886)

Oh fucking great, here we go again, PHP sucks Perl rulz... lets all suck slashdot's ass until their colon is clean.

We all know that slashcode, since it is written in perl is the pinnacle of perfection. Nevermind that I have never seen a php application that cannot paginate threads in a comments forum properly, unlike slashdot. Let alone losing posts altogether in some views. And its fixed oh so quickly, its been like this for ages now...

So come on everybody, lets shit on php, we know we'll never tire of it.

Re:Dueling Oxymorons (1)

jbarket (530468) | more than 7 years ago | (#15745998)

While I'm personally no supporter of Perl for web application development, doesn't it make more sense to blame the people writing slashcode rather than the language for those errors?

Re:Dueling Oxymorons (1)

1iar_parad0x (676662) | more than 7 years ago | (#15754260)

I never really understood the page links at the bottom of each 'page' of comments. It doesn't seem to work properly. What's it supposed to do? How does it decide where one page starts and another ends?

Re:Dueling Oxymorons (1)

ToxicBanjo (905105) | more than 7 years ago | (#15746254)

It's only as secure as the idiot writing it wants it to be... same as most programming languages.

Obvious Question about PHP (-1, Troll)

heauxmeaux (869966) | more than 7 years ago | (#15745774)

Who gives a living shit?

Top Edge PHP Attack (4, Funny)

digitaldc (879047) | more than 7 years ago | (#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.

Book's available for cheaper through Amazon (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#15745819)

It seems just plain rude for Slashdot to keep linking to B & N when Amazon has it cheaper [amazon.com] . Look at their third-party sellers, there's not a site on the web that will get you a new, mint copy of the book for less. I understand that Slashdot gets kickbacks from B & N, but they shouldn't rip their readership off.

Re:Book's available for cheaper through Amazon (1)

CRiMSON (3495) | more than 7 years ago | (#15745870)

I found it cheaper in my local book store. I find it rude /. didn't link to it! Or for that matter a site wher eI can get that book in a deal with others, Maybe pick up some DVD's too! I mean come on are we expected to do our own research before buying a book! I mean /. does link to B&N but yah man I'm not fucking typing the name of the book into amazon that's like work!

Re:Book's available for cheaper through Amazon (0, Troll)

Drantin (569921) | more than 7 years ago | (#15747740)

One Click Patent...

Re:Book's available for cheaper through Amazon (0)

Anonymous Coward | more than 7 years ago | (#15748077)

The Free Software community decided years ago that Amazon was not a threat, and GNU ended its boycott [gnu.org] . Get with the times.

User/role management (1)

knipknap (769880) | more than 7 years ago | (#15745838)

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 secure user/role management solutions that you can recommend? What are the advantages and where are the drawbacks? How du you solve user/role management in a reusable way?

Re:User/role management (1)

Bogtha (906264) | more than 7 years ago | (#15746073)

I don't know of any general-purpose libraries, but the latest version of Wordpress has a system [wordpress.org] like that that you could rip out.

Re:User/role management (1)

beavis88 (25983) | more than 7 years ago | (#15746194)

ASP.NET 2.0

Downside: it probably won't work with PHP :)

Re:User/role management (3, Informative)

gnud (934243) | more than 7 years ago | (#15746499)

When will people learn to check the PEAR before asking for PHP functionality?
http://pear.php.net/package/LiveUser [php.net] supports users from multiple sources (at the same time), group permissions and per-user-permissions.

Re:User/role management (1)

knipknap (769880) | more than 7 years ago | (#15746626)

Unfortunately, Pear does not meet the "can be installed using FTP" requirement (and is often not preinstalled by cheap webspace providers).

Re:User/role management (2, Informative)

Anonymous Coward | more than 7 years ago | (#15747004)

Upload pear to a folder pear/

On top of your script, do

ini_set('include_path', ini_get('include_path'). ":pear/");

Done.

I can't remember if it is include_path or something similar, but after 14 hours at work, I am not gonna look it up :)

Re:User/role management (1)

Achromatic1978 (916097) | more than 7 years ago | (#15748200)

Even better, put same in a .htaccess or similar directive in your folder, nice and neat.

PHPGACL? (0)

Anonymous Coward | more than 7 years ago | (#15746928)

have you looked at this?

http://wiki.cc/php/PhpGACL [wiki.cc]

i haven't implemented it, but i have filed it for a future perusing.

Re:PHPGACL? (1)

knipknap (769880) | more than 7 years ago | (#15748623)

I just read through the whole (excellent) documentation. It's exactly what I have been looking for, and I'll use it. Thanks!

Re:User/role management (1)

tolan-b (230077) | more than 7 years ago | (#15747213)

Re:User/role management (0)

Anonymous Coward | more than 7 years ago | (#15748797)

Users can belong to many groups, groups have access to one or more functions. Simple.

(User A belongs to Group 1 and Group 2. Group 1 has access to Function I and Function II. Group 2 has access to Function III and Function IV.

Therefore User A has access to Functions I, II, III and IV.)

Pro PHP (-1, Troll)

iluvcapra (782887) | more than 7 years ago | (#15745839)

Contradiction in terms?

The problem with the alternatives to PHP (4, Insightful)

baadger (764884) | more than 7 years ago | (#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.

Re:The problem with the alternatives to PHP (2, Insightful)

Timesprout (579035) | more than 7 years ago | (#15745958)

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.

Re:The problem with the alternatives to PHP (1)

baadger (764884) | more than 7 years ago | (#15746066)

This is completely true.

I am however implicitly responding to posts that always arise saying "Don't use PHP! It's a shit poorly designed language use (Python|Perl|Ruby)".

Oh and I also disagree with PHP for anything but web applications. I'm glad you mentioned it.

Re:The problem with the alternatives to PHP (1)

mattyrobinson69 (751521) | more than 7 years ago | (#15746128)

php is nice for some scripting tasks where sed, grep, awk and cut are just clumbersome. Also, stuff like

echo "update x set y=y+1 where z=a" | mysql -uuser -ppassword mydatabase

just seems like a nasty hack.

I'm not saying it should be used for desktop gui apps though

Re:The problem with the alternatives to PHP (1)

kv9 (697238) | more than 7 years ago | (#15748772)

I'm not saying it should be used for desktop gui apps though
why not [php.net] ?

Re:The problem with the alternatives to PHP (1)

kevin_conaway (585204) | more than 7 years ago | (#15745966)

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.

Re:The problem with the alternatives to PHP (2, Informative)

macx666 (194150) | more than 7 years ago | (#15747195)

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...

Re:The problem with the alternatives to PHP (1)

John Nowak (872479) | more than 7 years ago | (#15745995)

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 (1)

Anthony Boyd (242971) | more than 7 years ago | (#15747053)

It must just be personal preference, then. I agree with the grandparent post, the PHP docs are the best. I've seen the docs cited by others as a reason for considering PHP, so apparently it's a factor in PHP's success. If other languages provide documentation in different forms, then perhaps they are merely catering to other smaller markets. Maybe one of these different methods of documentation will prove to be superior at some point, and cause others to switch.

I guess the decision for those language developers would be, do we want to use our existing documentation system at the risk of marginalizing our language, or do we want to jump on the "Web-based with comments" bandwagon to entice a larger audience?

Note that an important part of the PHP documentation is the ability to type php.net/function into the browser, and get back a page with guesses as to what function you need to use. So php.net/array returns info on arrays, php.net/string returns info on strings, php.net/array_push returns the documentation for that particular function, etc. That would be an important part to implement, for anyone considering copying the PHP model.

Re:The problem with the alternatives to PHP (1)

destiney (149922) | more than 7 years ago | (#15747352)


100% Troll..

Re:The problem with the alternatives to PHP (3, Insightful)

Bogtha (906264) | more than 7 years ago | (#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] .

Re:The problem with the alternatives to PHP (1)

baadger (764884) | more than 7 years ago | (#15746096)

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.

Re:The problem with the alternatives to PHP (1)

linvir (970218) | more than 7 years ago | (#15746345)

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 any Perl code. The result? I continue to use PHP.

So I'd say availability is pretty important, but ease of use matters too.

Re:The problem with the alternatives to PHP (1)

kv9 (697238) | more than 7 years ago | (#15748784)

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.

Re:The problem with the alternatives to PHP (1)

linvir (970218) | more than 7 years ago | (#15748986)

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 far as I'm concerned, PHP does work automagically. Which was my point: ease of use is important.

Re:The problem with the alternatives to PHP (1)

kv9 (697238) | more than 7 years ago | (#15751012)

What? My webserver? As in, the one owned by the company who provide my hosting?

then perhaps you should ask them for support instead of whining on slashdot that "perl is teh hard omgplz!11one"?

Re:The problem with the alternatives to PHP (1)

KidSock (150684) | more than 7 years ago | (#15747338)

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.

Re:The problem with the alternatives to PHP (1)

sgtrock (191182) | more than 7 years ago | (#15749182)

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 Database API Specification version 2.0. You should become familar with this document before trying to use MySQLdb.

Additional HTML documentation is located in the doc directory of the source tarball. If you obtained MySQLdb/MySQL-python through a third-party vendor, they should have installed these files where they install other documentation. Typically this is in /usr/share/doc on most Linux distributions.

In addition, MySQLdb is documented using Python documentation standards. This documentation can be viewed using pydoc or the help function in recent versions of Python. Example:

>>> from pydoc import help # not needed for 2.2 or newer
>>> help("MySQLdb")"

The reason that the "import help" statement isn't needed in >=2.2 is because it's embedded. :)

Re:The problem with the alternatives to PHP (1)

jbarket (530468) | more than 7 years ago | (#15746058)

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" frameworks out there have little to no documentation at all. Couple that with the fact that in addition to learning a framework, a lot of developers will be learning a new language at the same time, and you're really screwed without some decent documentation. All in all, however, I feel it's just a matter of time. After using it for half a decade, I ran out of interest in PHP before I had ever seen Rails, Django or anything else out there today. It's a fantastic language, but PHP and Classic ASP are dinosaurs... "low level" web application languages... in this day and age.

Re:The problem with the alternatives to PHP (0)

Anonymous Coward | more than 7 years ago | (#15746346)

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.

I think you're being a bit closed-minded with that comment. For many of us, this is what made PHP great. I've used PHP for nine years, and this feature is why I started using it and why I continue to use it. I have several good web designers, but I can afford only one good programmer. I can have my web designers layout web pages and get customer approval then my programmer will add the parts of the screen that make the system dynamic. Obviously this won't work when you're doing something like an online store, but for most web sites it works very well. You get to easily combine the strengths of two very different groups of people.

Things like XML with XSL promise this same sort of division of labor, but the simple fact is I can find web designers to do HTML (with or without a helper program like Adobe Premiere) much easier than I can find designers that can write XSL.

Re:The problem with the alternatives to PHP (2, Interesting)

prockcore (543967) | more than 7 years ago | (#15746533)

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.

Re:The problem with the alternatives to PHP (1)

TheLink (130905) | more than 7 years ago | (#15748147)

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.

Re:The problem with the alternatives to PHP (0)

Anonymous Coward | more than 7 years ago | (#15746571)

Actually, I think PHP remains popular for the same reason VB and Python does - because anybody can come up with something working in a matter of minutes. Like someone said, though (about VB), it is dead easy to get 80% of your application up and running, while the remaining 20% will present enormous problems.

I know I'm going to be beat up for including Python in that list, but it is in many ways the VB of open source. It has it's uses, but rarely (just as VB or PHP) does it produce great and maintainable apps. They do exist, but there are far better tools if you don't buy the hype (from any of the three).

Great programmers can do wonders in any of them, but great programmers usually use something else because it is *even better*. Great programmers can do wonders in anything.

What all of the three really have is lots of users. That makes them popular. It does not by any means make them good.

PHP (1)

Vexorian (959249) | more than 7 years ago | (#15746826)

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

Re:The problem with the alternatives to PHP (1)

Ankur Dave (929048) | more than 7 years ago | (#15747773)

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).

Obvious Reason (0)

Anonymous Coward | more than 7 years ago | (#15745877)

I've noticed this is quite common with open source stuff. Usually there is either a lack of books or the ones that are out are quite uninformative or little more than overviews. Could be open source programmers tend to look through various sources of online documentation thus staving possible book writers/publishers/etc of customers. Or the everything should be free mentality starves these vendors of possible customers. Also the quickly changing nature of most open source projects means that many times the books are outdated as soon as they are published.

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

Anonymous Coward | more than 7 years ago | (#15746053)

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 (3, Informative)

Fozzyuw (950608) | more than 7 years ago | (#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.

PHP ...Security? (0)

Anonymous Coward | more than 7 years ago | (#15746193)

Ha Ha! Charade you are!

PHP Bashing (0, Redundant)

bryxal (933863) | more than 7 years ago | (#15746295)

I understand the current group think is bash PHP but let me try to stick a somewhat sensible word in. The goal of PHP is to be able to make scripts quickly that will then be able to support thousands of hits a day without too much tinkering. I find it incredible that people are still complaining that with PHP its too easy to make security holes. These people often refer to the fact that alot of young "N008S" are playing with it. Well that might not be because its an easy language but maybe because it fits what they want to do. Lots of people these days don't want to make a single player game, they want a multiplayer game. They want to be connected and with PHP and its many built in functions mass accessibility, C like syntax it makes it easy for people to pick and twiddle around with. The real problem aren't people who are making insecure sites, its the people who are hiring people with no credentials to make sites. No Zend Certified Engeneer will have glaring security holes in their applications, we don't just hire some guy off the street to do a GUI app so why are they hiring some kid off teh street for a web app?

zen certified engineer? (0)

Anonymous Coward | more than 7 years ago | (#15747709)

lol! stfu n00b!

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

Anonymous Coward | more than 7 years ago | (#15746307)

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 No tuse Global variables! (2, Informative)

shareme (897587) | more than 7 years ago | (#15746349)

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..

RadEverything is awful. (0)

Anonymous Coward | more than 7 years ago | (#15746605)

The radscripts moron doesn't know how to program, he's a real estate agent. He just pays the least possible to the lowest common denominator "programmers" he can find. Not suprisingly, you end up with a horrible mess. Although I guess the unreadable code does help hide the fact that its all got backdoors and phone-home treats hidden in it.

Re:Do No tuse Global variables! (0)

Anonymous Coward | more than 7 years ago | (#15750020)

I'm going to go ahead and assume you mean 'register_globals'

LAMP vs .Net (1)

jt2377 (933506) | more than 7 years ago | (#15747019)

Would you use Linux Apache MySQL PHP vs ASP.net IIS and MS SQL?

Good Stuff (1)

cheese-cube (910830) | more than 7 years ago | (#15747224)

While I do use PHP, I don't use it enough so that it poses a large security risk (I only really use it for includes, EXIF tag reading and browser detection). However I have still had my concerns about various aspects of it, such as the fact that it logs failed includes to an error_log file on the server, and this is why I would consider looking into this certain book especially since I foresee myself extending my PHP knowledge and usage in the near future.

This is a rather well written review and the book sounds rather solid although I am turned off by the abundance of theory. When it comes to learning programming languages I really prefer a more hands-on approach. This is one of the reasons why I chose to study website design at TAFE (Technical and Further Education for all you non-Australians) instead of university. Of course you can just skip all the theory, but I am unsure whether the theory is a required prerequisite to the practical sections.

Also does this book deal with only PHP 5 or does it cover older versions of PHP? My host only has version 4.4.2 and I am aware that there are many differences between version 4 and 5, especially security wise.

PHP Security in 5 sentences, Not 500 Pages (2, Insightful)

KidSock (150684) | more than 7 years ago | (#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.

Lack of PHP Security in 5 sentences, Not 500 Pages (2, Informative)

jani (4530) | more than 7 years ago | (#15748388)

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.

Re:Lack of PHP Security in 5 sentences, Not 500 Pa (1)

metarox (883747) | more than 7 years ago | (#15748788)

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.

That was all so 2001 (0)

Anonymous Coward | more than 7 years ago | (#15748600)

Backslashes don't escape anything in sqlite, I think you must mean PDO::quote? See also prepared statements and remember that ereg functions are being depreciated in favour of PCRE (faster). ctype functions perform much better, it's rare you actually need to do a regex aside from the occassional complex string. Then there's the abuse of regex for parsers, which should be taken care of by a decent PHP parser generator hitting PEAR sometine soon ;-)

Ten Bucks Cheaper at Amazon (1)

madstork2000 (143169) | more than 7 years ago | (#15747534)

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

PHP security: not what you think (2, Informative)

rhowardiv (856443) | more than 7 years ago | (#15747794)

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, providing good references for further reading where needed AND is just as useful for sysadmins as it is for developers. There is a lot of good stuff about maintaining secure and productive environments for development and production. I especially liked the introduction to using CLI PHP with PCNTL functions to set up an API for securely handling calls to system commands, with queuing, batch processing, etc. One thing not mentioned in the review is that the book is pretty heavily focused on PHP in the *nix/Apache environment -- if you're running on Windows, say, a lot of the provided details won't apply for you. Still recommended reading though; it's just something to be aware of.

Haste makes waste (1)

Bostik (92589) | more than 7 years ago | (#15748145)

... 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.

nice but SELECT * is evil (0)

Anonymous Coward | more than 7 years ago | (#15748189)

Nice that somebody finally wrote a book about security for PHP, but I wish they wouldn't use SELECT * FROM in code examples without at least explaining it's pitfalls.

http://www.parseerror.com/sql/select*isevil.html [parseerror.com]

for those that don't what I'm talking about.

Re:nice but SELECT * is evil (1)

nyctopterus (717502) | more than 7 years ago | (#15748955)

Meh, it's a shortcut. Sure it's less efficient in certain circumstances, and maybe harder to understand later on - I would have thought that was bleeding obvious. It's hardly evil.

Re:nice but SELECT * is evil (0)

Anonymous Coward | more than 7 years ago | (#15749803)

It's less efficient in almost all circumstances, and seriously inefficient when theres a blob field in the table, and as it's a "short cut" then maybe the authors should point that out rather than just using it without explanation.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...