A couple of good questions I have seen, and my best attempt to answer them:
1. Don't you mean rel? No, I mean rev. It indicates a reverse link.
2. Why not make your URLs short in the first place? I happen to like my URLs and have made them as short as I want them. They're only too long in some very specific use cases, like Twitter. I could just complain about Twitter, or I could support an idea that makes URL shortening suck less. I chose the latter.
Thanks for reading, and please do feel free to criticize whatever you think is wrong with this idea. I'd like a way to indicate a preferred short URL for my own stuff, and this seems like a pretty good way to do it that makes sense semantically and is easy to implement. For an ongoing discussion about adding an HTTP header to do the same thing (so that only a HEAD request is required), read here:
I'm not certain how wise it is to ask a network security guy's opinion about web application security matters. Maybe he cross-trains.
He's being funny, but he has a valid point. Here's an example from your comment:
A lot of Cross-Site Scripting attacks let you steal cookies. So they probably found those. But the question is: when you have a cookie, what can you do with it? Can you steal important data? Can you turn that cookie into a breach?
You shouldn't have to ask these questions, nor should you be suggesting that the worst thing XSS attacks can do is steal cookies. Show any competent web application security specialist a XSS vulnerability, and there is almost no limit to what he can do. I discuss some possibilities here:
I wanted to reply to one thing, because it's a very valid point:
In light of the author's expertise, one would presume that he would make every effort to write the definitive volume on PHP security -- covering every conceivable topic, including: execution of system commands, verification of user IDs and authorization, e-mail spamming via Web forms, (the related topic of) exclusion of bots, and remote procedure calls.
I deliberately chose to focus this book on the 80%, and I'm actually happy that I did. PHP's reputation suffers because of security concerns, and I'm sure you'll see some of that expressed here. I want PHP developers who read this book to focus on what's most important, and the principles and practices that they learn along the way should prepare them to deal with more minor concerns.
The execution of system commands is covered, but you're right that email injection is missing. HTTP response splitting is another. The second edition might include these, but they really boil down to the same thing as so many other vulnerabilities. If you filter input and escape output, neither are a concern. (After a recent change to header(), HTTP response splitting is no longer a concern, but we'll have to work with older versions of PHP for quite some time.)
Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.
PHP's ease of use and flexibility do make for a dangerous combination. There's no arguing that.
I'm not so sure that the answer lies in the interpreter, although I'm open to the idea. In the meantime, the PHP Security Consortium is an effort to help educate the community about secure programming practices (among other things).
I also try to do my part (in addition to my work with the PHPSC) by providing free articles, giving various talks (including the PHP Security Briefing), and writing Essential PHP Security. Education might not be the only answer, but I think it helps.
So, you're right that there is a bit of a problem, but some of us are trying to help.
That lack of rigidity is something that many developers enjoy. Things like Java are often preferred by managers, and things like PHP (and C, Perl, etc.) are often preferred by developers.
Re:PHP definitely does not follow the KISS princip
on
A Decade of PHP
·
· Score: 1
It's KISS, not KICS. You can argue that PHP isn't consistent (although it's a tired argument), but you've done nothing to support your claims that it isn't simple.
PHP's simplicity stems from some of the things that you complain about - verbosity being one. Whereas Perl (a language I also love) has many powerful operators, these are not intuitive. An inexperienced developer has a lower chance of intuiting the purpose of a cryptic Perl operator versus a verbose PHP function name.
As for the consistency argument, much of that also stems from the fact that many PHP developers are also C developers. I think Rasmus once said something like, "If anyone ever changes strlen() to str_len(), I'll cram an entire K&R book down their throat."
Drop all insecure legacy features like "register globals".
As mentioned here, we recommend that register_globals be left disabled. It has been disabled by default in PHP since version 4.2.0.
HTML ESCAPE BY DEFAULT.
This is a poor approach. Data should be filtered on input and properly escaped for its particular purpose on output. Escaping data for one particular purpose on input requires developers to unescape it for any other use, and this unnecessary complexity poses a security risk. Properly educating users as to what functions are there to help properly escape data is our approach. For example, want to avoid XSS? Escape your (already filtered) data with htmlentities(). Want to avoid SQL injection? Use an escaping function specific to your database of choice such as mysql_escape_string().
Then I'll start to take PHP seriously.
We are not an advocacy group. Our purpose is to promote secure programming practices within the PHP community, not promote PHP to other groups. PHP is already taken very seriously by some of the web's largest and most heavily trafficked sites.
Yes, you can always get away with such things on a small scale. In the case of Yahoo, the biggest problem (at the time I learned of this technique, which was about two years ago) was massive registrations. If you register less than a thousand users for an email account or something, they probably didn't care.
I think CAPTCHAs are just another example of a technology that can be effective if used appropriately. Don't depend on it to protect you from anything absolutely, but you can help to prevent automation on a large scale, and you might be able to employ other techniques to help with what's left.
Yes, I first heard this from an engineer at Yahoo. They were, as far as I know, the first site to have to deal with this technique on a major scale. Fortunately, this attack requires that the attacker's system communicate with your server, playing the role of a typical user.
So, although the "answer" to the CAPTCHA is provided an actual human, you can still pinpoint mass registrations and the like to a single group of IP addresses in most cases, because the users are not the ones interacting with your application. This becomes a network problem rather than an application problem.
And anyone who thinks PHP is a pillar of security obvious hasen't used PHP all that much.
It's difficult to argue that anything is a pillar of security, but those who buy into the myth that PHP is insecure are the ones who haven't used PHP that much, not the other way around.
And this reveals a common misconception. Rather than pointing out the obvious flaws in your statement, let me ask if you think C has a lot of vulnerabilities. After all, I know a lot of software written in C that has had buffer overflows. Surely that's the fault of the language, right?
I think it's time to quit supporting this theory that developers aren't accountable for their work.
Scalability is such a tired and misused argument, as you've just demonstrated. It's easier to argue that PHP scales than it is to argue that J2EE scales, but then scalability is just part of the picture. Read here for more information and perspective:
Also, PHP is behind a lot of huge sites, Yahoo being but one. Amazon.com uses a lot of Mason and Perl. Perl in the form of mod_perl powers a lot of major stuff. Python is important at Google. Where are these J2EE success stories that can justify the rhetoric that gets thrown around?
I think the stereotype that "everything that begins with the letter J is slow" is justified, with the exception of jBASE, and I hear those poor guys are thinking of changing the name of their flagship product because of it.
You're making an incorrect assumption. "SQL passwords," which I assume means the database access credentials, do not have to be readable by the Web server.
Well, that's too broad. Apache typically has a parent process running as root. Child processes actually handle the requests, and it is these that other users of a multi-user system can control using a variety of technologies (this is not language dependent). These processes typically run as nobody.
You can provide your access credentials to the parent process in such a way that only requests for your virtual host are given this information. I describe this technique in more detail here:
People with this perspective tend to be very poor programmers - no "real programmer" would assert that a programming language can be "covered in incredible detail in about a 3 page brochure."
I disagree. Your suggestion is the way the US education system tends to work - teach kids the easy way first, then teach them the right way later (and explain why the easy way is wrong).
The magic quotes feature escapes data for use in a query. There are lots of things you can be doing with data, and storing it is just one.
Also, the escaping that magic quotes does is equivalent to the addslashes function. This is a good last resort, but better options exist for many databases - for example, mysql_escape_string for MySQL.
That link gives George a bit more money. If you're feeling really generous, visit his blog and click the little "Buy from amazon.com" button. He gets a larger percentage from those (ironically, more than he'll get from royalties).
Slashdot Mirror
A couple of good questions I have seen, and my best attempt to answer them:
1. Don't you mean rel? No, I mean rev. It indicates a reverse link.
2. Why not make your URLs short in the first place? I happen to like my URLs and have made them as short as I want them. They're only too long in some very specific use cases, like Twitter. I could just complain about Twitter, or I could support an idea that makes URL shortening suck less. I chose the latter.
Thanks for reading, and please do feel free to criticize whatever you think is wrong with this idea. I'd like a way to indicate a preferred short URL for my own stuff, and this seems like a pretty good way to do it that makes sense semantically and is easy to implement. For an ongoing discussion about adding an HTTP header to do the same thing (so that only a HEAD request is required), read here:
http://shiflett.org/blog/2009/apr/a-rev-canonical-http-header
The safeguard you're describing protects against CSRF and has nothing to do with XSS.
Joel, I'm afraid it is you who aren't getting it.
I think Jeremiah Grossman says it best:
He's being funny, but he has a valid point. Here's an example from your comment:
You shouldn't have to ask these questions, nor should you be suggesting that the worst thing XSS attacks can do is steal cookies. Show any competent web application security specialist a XSS vulnerability, and there is almost no limit to what he can do. I discuss some possibilities here:
Using CSRF for Browser Hijacking
Another example of "not getting it" is thinking IP addresses are unique and/or static among a large userbase:
Good web sites? You can't be serious.
If you are serious and want to really put your money where your mouth is, I'm sure you'll find no shortage of people to take it. Here's one:
$1000 to Steal Data From 30% of Sites
You're welcome to read the reviews and the (very thorough) errata yourself:
:-)
http://phpsecurity.org/reviews
http://phpsecurity.org/errata
You'll be hard-pressed to find anything beyond simple typos and unclear sentences, I think, and the reviews have been very positive.
I wanted to reply to one thing, because it's a very valid point:
I deliberately chose to focus this book on the 80%, and I'm actually happy that I did. PHP's reputation suffers because of security concerns, and I'm sure you'll see some of that expressed here. I want PHP developers who read this book to focus on what's most important, and the principles and practices that they learn along the way should prepare them to deal with more minor concerns.
The execution of system commands is covered, but you're right that email injection is missing. HTTP response splitting is another. The second edition might include these, but they really boil down to the same thing as so many other vulnerabilities. If you filter input and escape output, neither are a concern. (After a recent change to header(), HTTP response splitting is no longer a concern, but we'll have to work with older versions of PHP for quite some time.)
Thanks for reading, and I hope it helps!
If you want to save some money and also support the author (me), please use this link:
:-)
http://phpsecurity.org/buy
You get the book for less than $20.
Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.
There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.
As BP says, it's a start.
PHP's ease of use and flexibility do make for a dangerous combination. There's no arguing that.
I'm not so sure that the answer lies in the interpreter, although I'm open to the idea. In the meantime, the PHP Security Consortium is an effort to help educate the community about secure programming practices (among other things).
I also try to do my part (in addition to my work with the PHPSC) by providing free articles, giving various talks (including the PHP Security Briefing), and writing Essential PHP Security. Education might not be the only answer, but I think it helps.
So, you're right that there is a bit of a problem, but some of us are trying to help.
That lack of rigidity is something that many developers enjoy. Things like Java are often preferred by managers, and things like PHP (and C, Perl, etc.) are often preferred by developers.
It's KISS, not KICS. You can argue that PHP isn't consistent (although it's a tired argument), but you've done nothing to support your claims that it isn't simple.
PHP's simplicity stems from some of the things that you complain about - verbosity being one. Whereas Perl (a language I also love) has many powerful operators, these are not intuitive. An inexperienced developer has a lower chance of intuiting the purpose of a cryptic Perl operator versus a verbose PHP function name.
As for the consistency argument, much of that also stems from the fact that many PHP developers are also C developers. I think Rasmus once said something like, "If anyone ever changes strlen() to str_len(), I'll cram an entire K&R book down their throat."
The tattlers are the reason people knew about this before they announced it.
As mentioned here, we recommend that register_globals be left disabled. It has been disabled by default in PHP since version 4.2.0.
This is a poor approach. Data should be filtered on input and properly escaped for its particular purpose on output. Escaping data for one particular purpose on input requires developers to unescape it for any other use, and this unnecessary complexity poses a security risk. Properly educating users as to what functions are there to help properly escape data is our approach. For example, want to avoid XSS? Escape your (already filtered) data with htmlentities(). Want to avoid SQL injection? Use an escaping function specific to your database of choice such as mysql_escape_string().
We are not an advocacy group. Our purpose is to promote secure programming practices within the PHP community, not promote PHP to other groups. PHP is already taken very seriously by some of the web's largest and most heavily trafficked sites.
There are links in the Library that point to existing resources like that.
I guess you missed the PHP Security Guide?
:-)
Yes, you can always get away with such things on a small scale. In the case of Yahoo, the biggest problem (at the time I learned of this technique, which was about two years ago) was massive registrations. If you register less than a thousand users for an email account or something, they probably didn't care.
I think CAPTCHAs are just another example of a technology that can be effective if used appropriately. Don't depend on it to protect you from anything absolutely, but you can help to prevent automation on a large scale, and you might be able to employ other techniques to help with what's left.
Yes, I first heard this from an engineer at Yahoo. They were, as far as I know, the first site to have to deal with this technique on a major scale. Fortunately, this attack requires that the attacker's system communicate with your server, playing the role of a typical user.
So, although the "answer" to the CAPTCHA is provided an actual human, you can still pinpoint mass registrations and the like to a single group of IP addresses in most cases, because the users are not the ones interacting with your application. This becomes a network problem rather than an application problem.
PHP developers might find this article useful:
http://phpsec.org/articles/2005/text-captcha.html
It sounds like the Times agrees with what several of us discussed at Foo Camp:
http://shiflett.org/archive/62
It's difficult to argue that anything is a pillar of security, but those who buy into the myth that PHP is insecure are the ones who haven't used PHP that much, not the other way around.
And this reveals a common misconception. Rather than pointing out the obvious flaws in your statement, let me ask if you think C has a lot of vulnerabilities. After all, I know a lot of software written in C that has had buffer overflows. Surely that's the fault of the language, right?
I think it's time to quit supporting this theory that developers aren't accountable for their work.
Scalability is such a tired and misused argument, as you've just demonstrated. It's easier to argue that PHP scales than it is to argue that J2EE scales, but then scalability is just part of the picture. Read here for more information and perspective:
http://shiflett.org/archive/46
Also, PHP is behind a lot of huge sites, Yahoo being but one. Amazon.com uses a lot of Mason and Perl. Perl in the form of mod_perl powers a lot of major stuff. Python is important at Google. Where are these J2EE success stories that can justify the rhetoric that gets thrown around?
I think the stereotype that "everything that begins with the letter J is slow" is justified, with the exception of jBASE, and I hear those poor guys are thinking of changing the name of their flagship product because of it.
You're making an incorrect assumption. "SQL passwords," which I assume means the database access credentials, do not have to be readable by the Web server.
Well, that's too broad. Apache typically has a parent process running as root. Child processes actually handle the requests, and it is these that other users of a multi-user system can control using a variety of technologies (this is not language dependent). These processes typically run as nobody.
You can provide your access credentials to the parent process in such a way that only requests for your virtual host are given this information. I describe this technique in more detail here:
http://shiflett.org/articles/security-corner-mar20 04
People with this perspective tend to be very poor programmers - no "real programmer" would assert that a programming language can be "covered in incredible detail in about a 3 page brochure."
I disagree. Your suggestion is the way the US education system tends to work - teach kids the easy way first, then teach them the right way later (and explain why the easy way is wrong).
The magic quotes feature escapes data for use in a query. There are lots of things you can be doing with data, and storing it is just one.
Also, the escaping that magic quotes does is equivalent to the addslashes function. This is a good last resort, but better options exist for many databases - for example, mysql_escape_string for MySQL.
http://www.amazon.com/exec/obidos/ASIN/0672325616/ georgeschloss-20/
That link gives George a bit more money. If you're feeling really generous, visit his blog and click the little "Buy from amazon.com" button. He gets a larger percentage from those (ironically, more than he'll get from royalties).