I know this concept from Perl DBI, but in PHP I haven't seen anyone (phpBB,...) using bind_param. Why is this? Performance? Keeping the code short and simple?
The reason is that the function you reference is only available in ext/mysqli, and this requires MySQL 4.1 or greater. There was previously no way to bind parameters like this using PHP and MySQL.
Also, phpBB is not a good example to use with regard to secure programming practices. It is one of the applications that give people this silly notion that the language is to blame for poor programming.
Re:Guides to Secure Programming?
on
PHP and SQL Security
·
· Score: 4, Informative
I'm also writing a monthly PHP security column in php|architect, and these articles will be available for free six months after publication.
Lastly, I am writing PHP Security for O'Reilly, which is due out in the fall.
Re:Apache 2.x safe to use yet?
on
PHP 5 RC 1 released
·
· Score: 4, Informative
You have to use the pre-fork MPM, which is the same condition you'll have when using various modules with mod_perl. Basically, PHP core is thread-safe, but you're likely to use some extensions in your own configuration, and these aren't necessarily thread-safe.
I'm not aware of a list of "who's safe", but such a thing would be nice.
Although it is PHP-specific, this free article explains XSS and CSRF in quite a bit of detail and might be useful for Web developers using any language:
I appreciate the honest feedback, and I'd like to address a few concerns/criticisms/whatever that I have seen mentioned.
Convincing the reader of the importance of HTTP - The first few pages do focus a lot on explaining why HTTP is important to a Web developer. Just look at all of the comments that mention how knowing HTTP is useless, and you can hopefully see why I think this is important. I see questions on various mailing lists all the time that reflect a general lack of knowledge in this area; developers don't really understand cookies, when SSL is needed (or what it does), how to secure their sessions (or applications in general), how to keep up with data from one page to the next, and all sorts of things.
The book caters to beginners - I want the book to cater to both the beginner and the experienced developer. HTTP isn't rocket science, and it can provide a great foundation for Web developers to build from. For those who are already experienced, the book can provide a good reference to the protocol (if you're experienced, you should also know that RFC 2616 isn't a substitute for this) and can help people gain a deeper understanding of things they already know a little about. I don't think a book has to confuse the reader to be considered advanced, and I wasn't writing to impress anyone. My approach was to try and help as many people as I could.
Learn Dreamweaver, not HTTP - Well, people with this opinion might be a lost cause, but what happens when your next place of employment thinks FrontPage is the only way to write Web applications? In general, I think it is better to teach people fundamental things and let them apply those things in any way that they want.
I don't claim to be an expert in this area, but I know that Dotster offers a service to hide this information. Well, it doesn't hide this information exactly, but you can't get it without querying their specific whois server. When you try something like this:
What are the major differences between radio and file sharing?
If musical artists dream of getting played on the radio (because of the wonderful effects exposure has on an artist), why would an artist not also dream of having his/her songs being shared by millions of people around the world? Isn't the Internet just a vastly improved distribution and exposure mechanism?
Would the same concerns arise if radio was able to achieve the same quality as MP3?
To many of us, file sharing is more ethical than many traditional aspects of the music industry.
Your browser generates the key pair using whatever length you specify during registration. The public key is provided as an HTML form field and used to create the digital certificate if/when you pass in-person proofing. Your private key should never leave your possession (whether you keep it in the browser, on a smart card, or whatever).
Who knows what they are planning now, but when I was working on it, the user had two options: let your browser keep your private key (as well as your personal digital certificate) or download your private key and digital certificate to a smart card. It is the user's responsibility to keep up with these things.
The USPS has its own CA which is used to issue the personal digital certificates. If you have a relatively new browser, their CA's certificate is probably in your certificate store, so you can check it out for yourself.
I was actually one of the developers of this project (three years ago), and it is funny to see that they are finally "announcing" it.
The idea is simple, and it is actually a useful service that the USPS has the resources to provide, if they actually go through with it. Whereas SSL only authenticates the server (among other things, of course), the allocations for client authentication in SSL are optional and very rarely used. All the client needs for this is its own digital certificate, just like the server has its certificate.
So, to get an SSL certificate, we (whether we like it or not) trust the various CAs to make certain that they are granted to the rightful owners. When it comes to client certificates, the scope of the problem becomes much larger, because you are authenticating people rather than domains. If you fail to properly identify someone before issuing the digital certificate, the point is lost.
The USPS has post offices all over the US (their only country of concern in this case), and this fact provides the perfect platform for authenticating people. Just as with Passports, you must prove your identity in person before being authenticated.
How do the pieces fit together? Well, it is fairly simple, but it involves a lot of existing systems, some of which are aging. You register online (providing much personal information, including what forms of ID you will be bringing with you). This generates a letter that is sent to your address (verifying your address in the process). You take this letter to the post office, and if you pass the in-person proofing, the clerk scans the barcode on the letter. This scan makes its way back to the system in about 24 hours, and then your digital certificate is generated. An email is sent to let you know, and you can then download it from the Web site after logging in.
At any rate, I still think the general idea is a good one, and this would be a useful service for a lot of people. I hope it is successful.
HTTP was NOT handed off to the IETF by the W3C as your post appears to imply, there was no W3C at that time. HTTP was taken to the IETF to get recognition as a protocol standard. There was no 'handing off', the same people continued to work on the protocol as before.
Notice that I did not mention the W3C. Also, it was in fact handed off, at least by my definition. Yes, it may have been as simple as a change of mailing list, but you even explain why such subtleties (such as the involvement of the IETF) can be important. Of course, demand drove a lot of what was implemented over the years, which has created some unfortunate violations (tangents might be a more polite term) of the specification, but that is why books such as this are so important (a point we can both agree on).
I was not involved in the working group, and while I appreciate the efforts of all who do contribute in those discussions, I do wish you would not try to make that fact justify everything you say. Your original post appeared to ridicule someone who simply recommended "reading up" on HTTP at the W3C's Web site. As many others have pointed out, this recommendation was perfectly valid. In addition, you seemed to undermine the importance of the very RFCs you claim to have contributed to, and I think knowledge of HTTP is already greatly underestimated by the majority of Web developers.
As a last bit of advice, you might want to avoid trying to claim ownership of something simply because you contributed (e.g., "my work"). Even if your contributions are substantial, such self-gratification actually lessens the respect you will receive for your efforts. Also, there is a difference between pointing out an error and suggesting someone is lying.
I hope this tangential discussion does not take the focus away from the real topic - that a great book (or even two or three) exists on an important topic.
Now that both HTTP extensions and HTTP/1.1 are stable specifications, W3C has closed the HTTP Activity. The Activity has achieved its goals of creating a successful standard that addresses the weaknesses of earlier HTTP versions.
Now that both HTTP extensions and HTTP/1.1 are stable specifications, W3C has closed the HTTP Activity. The Activity has achieved its goals of creating a successful standard that addresses the weaknesses of earlier HTTP versions.
HTTP was created long before it was handed off to be maintained by the IETF. It existed prior to the RFC that you claim to have co-wrote. The only reason that exchange was made is because HTTP is viewed as a piece of the Internet's infrastructure; in fact it is essentially where the Internet and the Web intersect.
Also, HTTP is very useful as "a guide to how what is out there works." Check out a mailing list for mod_perl, PHP, etc. You will find countless questions being asked that would be answered by a simple understanding of HTTP - how the Web works. This is what real Web developers need; then maybe I can check my bank account balance or sell some stocks without having to interact with a poorly-constructed Web site.
As the author of the HTTP Developer's Handbook, you might think that I would point out weaknesses in O'Reilly's effort. On the contrary, I think this work is very good, and I would highly recommend it to anyone involved in Web development. I think my book is more suited for the everyday reference that you carry with you that explains things specifically from a Web developer's perspective rather than focusing on clarifying the standards, and I think the two go well together.
At any rate, I think this is a quality book on a very important topic.
Assuming you are looking here, "Waldo" is (I think) a few different people, mainly the guy to the left on the soldiers leg in the top-left photo (the guy looking left who has something red around his neck).
In the top-right photo, the same guy is partially blocked by the soldier, but you can still see his knee and back. On the doctored photo, this guy appears on both the right and left side of the soldier's leg. In addition, there are two people a bit more in the distance behind "Waldo" who also appear to the right and left. Since the angle chanegd slightly between photos, these people were duplicated.
Those three are the only duplicates; the crowd to the right of the soldier in the doctored photo is identical to the crowd in the top-right photo. To the left of the soldier's leg is the crowd as seen in the top-left photo.
Slashdot Mirror
APD. It's been around for several years (it was hosted elsewhere before being moved to PECL in 2002).
This is the best thing I've read in a while. Brilliant. :-)
The reason is that the function you reference is only available in ext/mysqli, and this requires MySQL 4.1 or greater. There was previously no way to bind parameters like this using PHP and MySQL.
Also, phpBB is not a good example to use with regard to secure programming practices. It is one of the applications that give people this silly notion that the language is to blame for poor programming.
I have a few articles on my Web site that might be informative: http://shiflett.org/articles
I'm also writing a monthly PHP security column in php|architect, and these articles will be available for free six months after publication.
Lastly, I am writing PHP Security for O'Reilly, which is due out in the fall.
You have to use the pre-fork MPM, which is the same condition you'll have when using various modules with mod_perl. Basically, PHP core is thread-safe, but you're likely to use some extensions in your own configuration, and these aren't necessarily thread-safe.
I'm not aware of a list of "who's safe", but such a thing would be nice.
Well, my name is Chris Shiflett, and I was invited.
(For those who don't get it, Chris Shiflett is also the name of a Foo Fighter. I'm not sure which one.)
Although it is PHP-specific, this free article explains XSS and CSRF in quite a bit of detail and might be useful for Web developers using any language:
http://www.phparch.com/sample.php?mid=16
Enjoy
You can use this one to support the author (me):
http://www.amazon.com/exec/obidos/ASIN/0672324547Or, here is the plain link (it's not cheaper; you just give Amazon more money):
http://www.amazon.com/exec/obidos/ASIN/0672324547I appreciate the honest feedback, and I'd like to address a few concerns/criticisms/whatever that I have seen mentioned.
Convincing the reader of the importance of HTTP - The first few pages do focus a lot on explaining why HTTP is important to a Web developer. Just look at all of the comments that mention how knowing HTTP is useless, and you can hopefully see why I think this is important. I see questions on various mailing lists all the time that reflect a general lack of knowledge in this area; developers don't really understand cookies, when SSL is needed (or what it does), how to secure their sessions (or applications in general), how to keep up with data from one page to the next, and all sorts of things.
The book caters to beginners - I want the book to cater to both the beginner and the experienced developer. HTTP isn't rocket science, and it can provide a great foundation for Web developers to build from. For those who are already experienced, the book can provide a good reference to the protocol (if you're experienced, you should also know that RFC 2616 isn't a substitute for this) and can help people gain a deeper understanding of things they already know a little about. I don't think a book has to confuse the reader to be considered advanced, and I wasn't writing to impress anyone. My approach was to try and help as many people as I could.
Learn Dreamweaver, not HTTP - Well, people with this opinion might be a lost cause, but what happens when your next place of employment thinks FrontPage is the only way to write Web applications? In general, I think it is better to teach people fundamental things and let them apply those things in any way that they want.
I also have a companion Web site for the book at http://shiflett.org/books/http-developers-handbook .
I don't claim to be an expert in this area, but I know that Dotster offers a service to hide this information. Well, it doesn't hide this information exactly, but you can't get it without querying their specific whois server. When you try something like this:
whois example.org
you get information that looks like this:
Registrant Name:SEE SPONSORING REGISTRAR
Registrant Street1:Whois Server:whois.dotster.com
Registrant Street2:Referral URL:www.dotster.com/help/whois
Registrant City:N/A
Registrant Postal Code:N/A
Registrant Country:CA
Registrant Email:not@available.org
The Admin, Billing, and Tech entries are the same. If you, however, do this:
whois example.org@whois.dotster.com
you get all of the personal information like normal.
What are the major differences between radio and file sharing?
If musical artists dream of getting played on the radio (because of the wonderful effects exposure has on an artist), why would an artist not also dream of having his/her songs being shared by millions of people around the world? Isn't the Internet just a vastly improved distribution and exposure mechanism?
Would the same concerns arise if radio was able to achieve the same quality as MP3?
To many of us, file sharing is more ethical than many traditional aspects of the music industry.
I think you misunderstand. I am telling you that this is how it (the USPS implementation) works.
And yeah, any system where the user cannot take full responsibility over the privacy of their private key is a broken system. :-)
Your browser generates the key pair using whatever length you specify during registration. The public key is provided as an HTML form field and used to create the digital certificate if/when you pass in-person proofing. Your private key should never leave your possession (whether you keep it in the browser, on a smart card, or whatever).
Who knows what they are planning now, but when I was working on it, the user had two options: let your browser keep your private key (as well as your personal digital certificate) or download your private key and digital certificate to a smart card. It is the user's responsibility to keep up with these things.
The USPS has its own CA which is used to issue the personal digital certificates. If you have a relatively new browser, their CA's certificate is probably in your certificate store, so you can check it out for yourself.
I was actually one of the developers of this project (three years ago), and it is funny to see that they are finally "announcing" it.
The idea is simple, and it is actually a useful service that the USPS has the resources to provide, if they actually go through with it. Whereas SSL only authenticates the server (among other things, of course), the allocations for client authentication in SSL are optional and very rarely used. All the client needs for this is its own digital certificate, just like the server has its certificate.
So, to get an SSL certificate, we (whether we like it or not) trust the various CAs to make certain that they are granted to the rightful owners. When it comes to client certificates, the scope of the problem becomes much larger, because you are authenticating people rather than domains. If you fail to properly identify someone before issuing the digital certificate, the point is lost.
The USPS has post offices all over the US (their only country of concern in this case), and this fact provides the perfect platform for authenticating people. Just as with Passports, you must prove your identity in person before being authenticated.
How do the pieces fit together? Well, it is fairly simple, but it involves a lot of existing systems, some of which are aging. You register online (providing much personal information, including what forms of ID you will be bringing with you). This generates a letter that is sent to your address (verifying your address in the process). You take this letter to the post office, and if you pass the in-person proofing, the clerk scans the barcode on the letter. This scan makes its way back to the system in about 24 hours, and then your digital certificate is generated. An email is sent to let you know, and you can then download it from the Web site after logging in.
At any rate, I still think the general idea is a good one, and this would be a useful service for a lot of people. I hope it is successful.
Don't assume anyone accepted anything as fact. Other than the three or four people who asked a question, everyone was muted the entire time.
HTTP was NOT handed off to the IETF by the W3C as your post appears to imply, there was no W3C at that time. HTTP was taken to the IETF to get recognition as a protocol standard. There was no 'handing off', the same people continued to work on the protocol as before.
Notice that I did not mention the W3C. Also, it was in fact handed off, at least by my definition. Yes, it may have been as simple as a change of mailing list, but you even explain why such subtleties (such as the involvement of the IETF) can be important. Of course, demand drove a lot of what was implemented over the years, which has created some unfortunate violations (tangents might be a more polite term) of the specification, but that is why books such as this are so important (a point we can both agree on).
I was not involved in the working group, and while I appreciate the efforts of all who do contribute in those discussions, I do wish you would not try to make that fact justify everything you say. Your original post appeared to ridicule someone who simply recommended "reading up" on HTTP at the W3C's Web site. As many others have pointed out, this recommendation was perfectly valid. In addition, you seemed to undermine the importance of the very RFCs you claim to have contributed to, and I think knowledge of HTTP is already greatly underestimated by the majority of Web developers.
As a last bit of advice, you might want to avoid trying to claim ownership of something simply because you contributed (e.g., "my work"). Even if your contributions are substantial, such self-gratification actually lessens the respect you will receive for your efforts. Also, there is a difference between pointing out an error and suggesting someone is lying.
I hope this tangential discussion does not take the focus away from the real topic - that a great book (or even two or three) exists on an important topic.
To quote the W3C:
Now that both HTTP extensions and HTTP/1.1 are stable specifications, W3C has closed the HTTP Activity. The Activity has achieved its goals of creating a successful standard that addresses the weaknesses of earlier HTTP versions.
Never.
To quote the W3C:
Now that both HTTP extensions and HTTP/1.1 are stable specifications, W3C has closed the HTTP Activity. The Activity has achieved its goals of creating a successful standard that addresses the weaknesses of earlier HTTP versions.
Your entire post could not be more untrue.
HTTP was created long before it was handed off to be maintained by the IETF. It existed prior to the RFC that you claim to have co-wrote. The only reason that exchange was made is because HTTP is viewed as a piece of the Internet's infrastructure; in fact it is essentially where the Internet and the Web intersect.
Also, HTTP is very useful as "a guide to how what is out there works." Check out a mailing list for mod_perl, PHP, etc. You will find countless questions being asked that would be answered by a simple understanding of HTTP - how the Web works. This is what real Web developers need; then maybe I can check my bank account balance or sell some stocks without having to interact with a poorly-constructed Web site.
As the author of the HTTP Developer's Handbook, you might think that I would point out weaknesses in O'Reilly's effort. On the contrary, I think this work is very good, and I would highly recommend it to anyone involved in Web development. I think my book is more suited for the everyday reference that you carry with you that explains things specifically from a Web developer's perspective rather than focusing on clarifying the standards, and I think the two go well together.
At any rate, I think this is a quality book on a very important topic.
That's not a vulnerability. That's just unaware (stupid?) users giving their username and password to the bad guys.
I'm pretty sure he was referring to Janis Ian.
Assuming you are looking here, "Waldo" is (I think) a few different people, mainly the guy to the left on the soldiers leg in the top-left photo (the guy looking left who has something red around his neck).
In the top-right photo, the same guy is partially blocked by the soldier, but you can still see his knee and back. On the doctored photo, this guy appears on both the right and left side of the soldier's leg. In addition, there are two people a bit more in the distance behind "Waldo" who also appear to the right and left. Since the angle chanegd slightly between photos, these people were duplicated.
Those three are the only duplicates; the crowd to the right of the soldier in the doctored photo is identical to the crowd in the top-right photo. To the left of the soldier's leg is the crowd as seen in the top-left photo.
If you have 955 days of uptime, your kernel does not have this vulnerability. Of course, it might have others. :-)