10 ms·

Our Ambitious Plan to Make Insecure PHP Software a Thing of the Past

139 points by CiPHPerCoder 9y ago

tyingq 9y ago
Reputation management companies struggle to wipe "bad content" off of 3rd party sites. Your goal is laudable, just not sure it's practical. Did you consider focusing on publishing and promoting net new content instead? Get traction that way, and that content will move up the Google serps, effectively moving the old/bad content down.
- CiPHPerCoder 9y ago
  > Did you consider focusing on publishing and promoting net new content instead? We've been doing that for years. We've hit diminishing returns because: 1. There is a lot of incumbent material in the same genre, most of which is 10+ years old, but people still link to it in droves. 2. We don't support the at-best-sketchy SEO industry that's sometimes arm-in-arm with adware. If you read the 2018 guide this post mentions a few times, you'll notice that it, in turn, links to relevant blog posts (and open source libraries) spanning back to early 2015.
  - tyingq 9y ago
    I don't think that asking people to link to content that's clearly superior is "SEO". Asking a 3rd party site to change a link seems easier than asking a different 3rd party site to rewrite content.
    - CiPHPerCoder 9y ago
      That's sort of what I'm asking people for, except presented as a choice. I'll update the article to try to make it clear that "link to clearly superior content" is a viable alternative to rewriting said content, as long as the same goal is achieved.
graphememes 9y ago
It will never be secure unless you do it at the system / language level.
- tyingq 9y ago
  Many of the PHP issues I see cited aren't unique to PHP, but more unique to it's heavily neophyte centric user base. For example...there's nothing about current day PHP that makes it more susceptible to SQL injection than any other dynamically typed language with easy string interpolation. And the official PHP docs do guide you down the right path for SQL.
  - anonymousDan 9y ago
    Hmm, I distinctly remember seeing a talk from the Chaos Computer Club Congress about how the PHP language is fundamentally broken in terms of security in comparison to other scripting languages. Edit: Apologies it was actually Perl (title "The Perl Jam"). In any event well worth watching if you have the time!
    - kbenson 9y ago
      I remember that. That is not a good talk. That the software had those errors sucks, but it's not a fundamental problem with Perl, but in how people had designed their internal APIs. In some cases he was citing problems in a module that was in core, but had long been noted to have problems and was not considered acceptable to use in anything except a quick and dirty script (and has since gone through a long deprecation cycle and finally been removed (CGI). What the talk really exposed was a few similar bugs found in various projects (which is good!), and exposed a fundamental misunderstanding of a language by the researcher due to unfamiliarity. This was all covered in depth here at the time.[1] 1: https://news.ycombinator.com/item?id=8813479 https://news.ycombinator.com/item?id=8813479
      - anonymousDan 9y ago
        Interesting. What about his follow up talk the next year where he rebutted some of those rebuttals as it were: https://media.ccc.de/v/32c3-7130-the_perl_jam_2 https://media.ccc.de/v/32c3-7130-the_perl_jam_2
jjeaff 9y ago
An admirable goal. One of my pet peeves with lots of php code and extensions is the unending desire to make every bit of cold backwards compatible to some of the oldest versions of PHP. There are some great, new cryptographic functions that have been implemented in PHP >= 5.5 Password_hash() and password_verify() are so simple, it's hard to mess up password hashing now. When I upgraded my projects to PHPa7, I replaced dozens of lines of code with those 2 functions alone. But I have seen plenty of implementations of them that still fall back to old more convoluted and error prone methods when you are using some old version of PHP.
- jccc 9y ago
  > When I upgraded my projects to PHPa7 ... The universe of developers with PHP projects to maintain is filled with people who do not share the same goals and constraints that you might enjoy. There is an enormous amount of lousy PHP code, and more being made by clueless developers. But please do not dismiss the need to support old PHPs as being driven primarily by those reasons. 1. The PHP project itself has EOLed 5.3.3, however distros continue to support it with backported security and bug patches of their own. 2. PHP 5.3.3 (with backported security and bug patches) remains the default in CentOS 6.9, which is supported until 2020. More recent versions are not available via their repositories. Hosts would have to upgrade PHP outside of the CentOS packages and assume the maintenance burden from then on. 3. About 50% of sites running PHP are at versions less than 5.5: https://w3techs.com/technologies/details/pl-php/5/all https://w3techs.com/technologies/details/pl-php/5/all https://w3techs.com/technologies/details/pl-php/all/all https://w3techs.com/technologies/details/pl-php/all/all 4. Updating PHP is not like simply updating my Web browser. Real-world production hosts like mine are filled with various work by various developers over years. Bumping PHP further than a maintenance release would almost certainly mean unnecessarily breaking things that are hard to find, probably tricky to fix and written by people I’ve never met who are long gone.
  - smsm42 9y ago
    5.3??? 5.3 has been EOL for 3.5 years now. I do not envy the person that has to maintain backports for so many years. In fact, I'm not even sure all the backports would always work properly...
smacktoward 9y ago
What's needed here is a "naming and shaming" effort. Make a public directory of bad PHP tutorials/references/etc., with the names of the people and companies who wrote and host them prominently attached. Maybe even give them a score, based on how frequently cited/linked to their bad advice has become, or how many pieces of it they've proffered. Then only take them off the list when the documents are cleaned up or removed. If you're a professional PHP developer or a company that builds on PHP, it would be very embarrassing to find yourself prominently featured on such a list. Which would create an incentive for those people to clean up their work so they can get off it. As things stand currently, publishing outdated and dangerous information costs the publisher nothing, so they see no reason to stop doing it. Create a cost by attaching reputational damage to the act, and you create a reason for them to stop.
- CiPHPerCoder 9y ago
  That's certainly a novel approach to solving the problem. I'm hesitant to do this myself, because it might open us to legal action, and I don't have the emotional bandwidth or cash reserves to fight a lawsuit right now.
- thehardsphere 9y ago
  This plan would fail, because someone sophisticated enough to find the naming and shaming list of awfulness would probably already be sophisticated enough to realize that old, bad advice is bad and why it is, and where to find new, good information. The problem is not merely that bad old content exists, but there is a class of PHP developer who is insufficiently sophisticated to distinguish between good and bad information independently. Whether that's a feature or a bug of PHP is an exercise I leave for the reader.
- astrodust 9y ago
  YouTube is littered with awful, preposterously bad tutorials. If there's one thing that'd fix PHP it'd be for the community to put out better, more prominent, higher quality material than the toxic dreck that's out there. This isn't to say that there aren't good YouTube videos, but for each one of these there's easily a hundred where people with no clue are explaining PHP as if they know everything.
laurencei 9y ago
Can you get StackOverflow to "sponser" this idea? Not just for crypto (which you've done) - but for all PHP related answers? Because the problem is there are many "old" accepted answers, with high upvotes, that will always come up as number 1 or 2 in google searches. Given PHP has changed so much, many of those answers are outdated, use incorrect and insecure methods, and some are now just wrong. This is not just security - but a whole host of answers. The "meta" StackOverflow rules will tell you to downvote the old answer and post a new one - but that is not practical - and will take years to take effect. Plus, many people simply read the first large upvoted answer, copy + paste the code, and move on. edit: I guess it would be nice to be able to "flag" an accepted answer (not a question) as outdated, get 5x people with gold badges for that tag to accept it - and then the answer is highlighed as wrong/out of date (or even deleted). Something like that.
- CiPHPerCoder 9y ago
  > Can you get StackOverflow to "sponser" this idea? Possibly. I wouldn't even know where to begin. > Because the problem is there are many "old" accepted answers, with high upvotes, that will always come up as number 1 or 2 in google searches. Yeah, that's my concern. I can definitely edit anything tagged [php], due to having a gold [php] badge, and I think I can edit anything because I have a reputation higher than 10,000. The hardest problem for me, here, is identifying these old accepted answers with high upvotes. My general approach is something like this: https://stackoverflow.com/questions/tagged/php+encryption?sort=votes&pageSize=50 https://stackoverflow.com/questions/tagged/php+encryption?so... https://www.google.com/search?q=site%3Astackoverflow.com+php+encryption https://www.google.com/search?q=site%3Astackoverflow.com+php...
  - laurencei 9y ago
    IMO (as someone with 45k rep on StackOverflow, largely in PHP) - the best way is to modify the "flag" option on answers - and have an extra option called "out of date". If someone flags an answer as out of date, then anyone with a gold badge in that tag (i.e. PHP) - can review and accept or decline the flag. If 5 gold people accept it - then the answer is formally highlighted as out of date, or even deleted. You could raise this on Meta Stackoverflow as one possible way to start: https://meta.stackoverflow.com/ https://meta.stackoverflow.com/ edit: There probably should be another flag option - called "security" - where even if an answer "works" and is "in date" - people can flag it as insecure due to a better option. Think of all the stupid SQL injection answers. You can downvote it to hell - but sometimes they should just be flagged/deleted.
mywittyname 9y ago
I think it would be better to write a plugin for various PHP IDEs that contain fingerprints of bad code which is used to yell at the programmer if they are using these old, insecure code snippets. Heck, you could add a feature or note to the developer to down-vote the source of said code. It would be a lot of work, but I think it's easier than trying to get authors of defunked blogs to take down 10 year old answers. As a side-effect, this increases awareness among developers that you can't blindly accept what's on SO. If developers begin to lose trust in SO, then SO is going to be incentivized to do something about, or go the way of expertsexchange.
- SadWebDeveloper 9y ago
  you will have to add support for the vim/emacs guys, there are dozens of unix zealots still developing like in the ancient days.
- firefoxd 9y ago
  I've been using netbeans recently and it has this very annoying and effective squiggles that warn you when you use deprecated stuff. It also tries to enforce some best practices by default
  - smt88 9y ago
    PHP also has runtime errors for deprecated functions when using strict mode, which everyone should use
- DCoder 9y ago
  There's a plugin for IntelliJ IDEs called "PHP Inspections (EA Extended)" [0] that detects some of these compatibility and security problems. [0]: https://plugins.jetbrains.com/plugin/7622-php-inspections-ea-extended- https://plugins.jetbrains.com/plugin/7622-php-inspections-ea...
  - mywittyname 9y ago
    This could certainly be a starting off point for what I was imagining. I was thinking that they could do analysis on code snippets that are copy-pasted into the editor. It should be straight-forward to compare the contents to a finger-print database and issue a warning when they find a match to online code examples that are marked as vulnerable.
kbenson 9y ago
Well, PHP has finally come full circle in the lifecycle. It's fully following in the footsteps of Perl. There was a big push and a lot of talk in the Perl community around 2010-2012 to find and remove old and poor quality Perl tutorials so people searching didn't end up with bad information. Part of this push included writing new and better tutorials and trying to get them placed higher in results for old tutorials that could not or would not be removed. Since we all saw and remember how Perl regained it's top spot as most popular programming language, I'm sure this will work out wonderfully. :/
- lkrubner 9y ago
  I almost wrote a similar comment, but I figured I would be downvoted. I realize it sounds cynical, but why should this effort be made for PHP? I loved PHP back in the year 2000, and at that time it had advantages that no other language had, but those days are long gone. There are many better languages now. I wrote about this in my essay "PHP is obsolete" and there was a fairly good conversation about that essay on Hacker News: https://news.ycombinator.com/item?id=9598309 https://news.ycombinator.com/item?id=9598309
  - CiPHPerCoder 9y ago
    > but why should this effort be made for PHP? See https://w3techs.com/technologies/overview/programming_language/all https://w3techs.com/technologies/overview/programming_langua... Anyone who wants a more secure Internet must necessarily be interested in improving the security of PHP.
    - code_duck 9y ago
      The figures on that page don’t mean that 83% of developers use PHP... Just that some things written in PHP are very popular. I’m sure that most of that figure is packages like WordPress.
      - CiPHPerCoder 9y ago
        Most of the Internet (5 out of 6 websites) is powered by PHP. This is true despite people saying "don't use PHP". I didn't imply that 83% of developers use PHP. I'm sorry if anyone read it that way. I'm zeroed-in on the "what powers the Internet" statistic.
banhfun 9y ago
A better idea would be to make PHP a thing of the past.
- astrodust 9y ago
  A laudable goal, but you know, destined for failure.
- sumedh 9y ago
  Companies are still using Cobol
stcredzero 9y ago
Golang community, please take the history of the PHP community as a series of models for 1) what to do and 2) what not to do! Also do this for Java, Ruby, Javascript, LISP, C++, and Smalltalk! And if you think the history of PHP isn't applicable, then go and find the Golang library authors who are advocating filtering as a defense against SQL injection!
wcr3 9y ago
or just php in general. just a thought.
deanclatworthy 9y ago
Hi Scott, thanks for all the great efforts. This is a good start, and baseline but security is so much harder once you get past these basics. Once you get into the realm of timing attacks and all the ways to fuck up password recovery for example, it becomes a mine field. What can we do about that, short of “use framework X or Y” as they are the only ones peer reviewed?
fernly 9y ago
> we can raze the mountains of collective technical debt that have accumulated over the past decade. Not likely when professionally written code is full of errors, many security-related (e.g. attempting to load and execute .gifs). I recently presented a compilation[1] of the errors produced by one widely-used commercial ad function. If this is how a professionals write commercial code, I don't want to imagine what amateurs have been doing. [1] https://www.reddit.com/r/web_programming/comments/7o8dzf/copious_and_varied_errors_from/ https://www.reddit.com/r/web_programming/comments/7o8dzf/cop...
- avenius 9y ago
  Sounds like an intentionally malicious function to me - just waiting for a proper payload.
EGreg 9y ago
I want to recommend another technique these days: 1) Sign (HMAC) all the session ids that your server issues. This allows requests with bogus session ids to be rejected at the network borders without doing any I/O or hitting the database. 2) Use web crypto (now supported by all major browsers) to have clients generate a private key with which to sign all requests. Using session keys as bearer tokens opens users up to attacks. 3) Do NOT send passwords to the server! Use passwords to decrypt the private key, and do not expose the decrypted key to external Javascript. And make sure the key can't be exported. 4) Clients authenticate new devices using two-factor authentication. If the person is using a previously authorized device and knows their password this may be considered two factors already. Unless the password was saved, in which case they better have a password on their device. Ultimately you gotta trust the OS. 5) Authentication and authorization for data may be done automatically by a side-channel (QR code via camera, or bluetooth) with the proof submitted to the server by either device. Revocation ultimately needs a blockchain. 6) If you lost all your authorized devices, the backup should be: M of N public keys, plus a passphrase you know. This is only for rare cases and the passphrase can be weak. No more passwords except for the above!!
- CiPHPerCoder 9y ago
  Please tell me you've seen this before? https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
  - EGreg 9y ago
    I haven't seen this particular article, but having read it, I can tell you: there are different threat models. You can't be secure against them all on the Web. Of course we have to trust the server to deliver the initial code. The same is true with apps delivered via the appstore etc. But that doesn't mean you should be send and storing password hashes to the server, even if generated by PHP. It doesn't mean you should be using the session cookie alone as a bearer token to access a session. First of all, you have to agree that a security requirement in addition to a cookie doesn't make things less secure. Secondly, with Web Crypto the Web has a way to mark keys "non exportable". If the website is sending you the wrong resources then of course anything can be sent, and web-based code isn't the ultimate way to protect the user. The same is true of other approaches. However if the initial code download wasn't tampered with, then you are far more protected. Because the secret private key won't be exported from the browser website. And it won't be accessible to anyone outside the JS environment that asks for your password or finger to derive a key to decrypt the master key from the local database. And in that JS environment, you can make sure (via closures) that no one gets access to it in "userland". OH AND YOU SHOULD ALSO BE USING A PRIVATE KEY PER USER TO ENCRYPT DATA AT REST ON YOUR DATABASE, AND STORE THIS KEY IN THE DB MULTIPLE TIMES - EACH ONE ENCRYPTED BY THE USER'S DEVICE KEY. You don't store these device keys. Successfully authentication requests from the device send this key. So once again you need to obtain this key in order to unlock user's info needed for the request. And users can send permissions to unlock their information to each other in sidechannels. You can take this security VERY far... So it's strictly more secure than the server side database for passwords, even hashed and salted with key strengthening. BUT, don't advertise it because then it introduces security attacks where people over-rely on this to te detriment of the vectors mentioned in the article. PS: Oh. This was written in 2011, before the Web Crypto standard I am referring to was published and adopted by all web browsers. I do NOT recommend doing the crypto methods in JS! And yes it has a secure RNG now. https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_... Also Object.freeze() is a thing now.
ewams 9y ago
I disagree with their suggestion to comment out or remove old PHP code. People need to have a date and timestamp at their top of the articles AND state what version of PHP they are coding for. Information on older version should not be pruned as there are legitimate reasons to keep them. Not everyone is using PHP 7; what do you do when you inherit an older code base; what do you do when you just need to modify a few things on an older code base; what if you are trying to learn security based programming; what if you are trying to learn how to break into systems (to then learn how to protect them); what if PHP7 is not available or feasible for your project; etc.
leetbulb 9y ago
I've been a PHP developer for over ten years. Paragon Initiative is amazing. Their Github repos are full of useful things: https://github.com/paragonie https://github.com/paragonie

139 points by CiPHPerCoder 9y ago

Reputation management companies struggle to wipe "bad content" off of 3rd party sites. Your goal is laudable, just not sure it's practical. Did you consider focusing on publishing and promoting net new content instead? Get traction that way, and that content will move up the Google serps, effectively moving the old/bad content down.

CiPHPerCoder 9y ago
> Did you consider focusing on publishing and promoting net new content instead? We've been doing that for years. We've hit diminishing returns because: 1. There is a lot of incumbent material in the same genre, most of which is 10+ years old, but people still link to it in droves. 2. We don't support the at-best-sketchy SEO industry that's sometimes arm-in-arm with adware. If you read the 2018 guide this post mentions a few times, you'll notice that it, in turn, links to relevant blog posts (and open source libraries) spanning back to early 2015.
- tyingq 9y ago
  I don't think that asking people to link to content that's clearly superior is "SEO". Asking a 3rd party site to change a link seems easier than asking a different 3rd party site to rewrite content.
  - CiPHPerCoder 9y ago
    That's sort of what I'm asking people for, except presented as a choice. I'll update the article to try to make it clear that "link to clearly superior content" is a viable alternative to rewriting said content, as long as the same goal is achieved.

graphememes 9y ago

It will never be secure unless you do it at the system / language level.

tyingq 9y ago
Many of the PHP issues I see cited aren't unique to PHP, but more unique to it's heavily neophyte centric user base. For example...there's nothing about current day PHP that makes it more susceptible to SQL injection than any other dynamically typed language with easy string interpolation. And the official PHP docs do guide you down the right path for SQL.
- anonymousDan 9y ago
  Hmm, I distinctly remember seeing a talk from the Chaos Computer Club Congress about how the PHP language is fundamentally broken in terms of security in comparison to other scripting languages. Edit: Apologies it was actually Perl (title "The Perl Jam"). In any event well worth watching if you have the time!
  - kbenson 9y ago
    I remember that. That is not a good talk. That the software had those errors sucks, but it's not a fundamental problem with Perl, but in how people had designed their internal APIs. In some cases he was citing problems in a module that was in core, but had long been noted to have problems and was not considered acceptable to use in anything except a quick and dirty script (and has since gone through a long deprecation cycle and finally been removed (CGI). What the talk really exposed was a few similar bugs found in various projects (which is good!), and exposed a fundamental misunderstanding of a language by the researcher due to unfamiliarity. This was all covered in depth here at the time.[1] 1: https://news.ycombinator.com/item?id=8813479 https://news.ycombinator.com/item?id=8813479
    - anonymousDan 9y ago
      Interesting. What about his follow up talk the next year where he rebutted some of those rebuttals as it were: https://media.ccc.de/v/32c3-7130-the_perl_jam_2 https://media.ccc.de/v/32c3-7130-the_perl_jam_2

jjeaff 9y ago

An admirable goal. One of my pet peeves with lots of php code and extensions is the unending desire to make every bit of cold backwards compatible to some of the oldest versions of PHP. There are some great, new cryptographic functions that have been implemented in PHP >= 5.5 Password_hash() and password_verify() are so simple, it's hard to mess up password hashing now. When I upgraded my projects to PHPa7, I replaced dozens of lines of code with those 2 functions alone. But I have seen plenty of implementations of them that still fall back to old more convoluted and error prone methods when you are using some old version of PHP.

jccc 9y ago
> When I upgraded my projects to PHPa7 ... The universe of developers with PHP projects to maintain is filled with people who do not share the same goals and constraints that you might enjoy. There is an enormous amount of lousy PHP code, and more being made by clueless developers. But please do not dismiss the need to support old PHPs as being driven primarily by those reasons. 1. The PHP project itself has EOLed 5.3.3, however distros continue to support it with backported security and bug patches of their own. 2. PHP 5.3.3 (with backported security and bug patches) remains the default in CentOS 6.9, which is supported until 2020. More recent versions are not available via their repositories. Hosts would have to upgrade PHP outside of the CentOS packages and assume the maintenance burden from then on. 3. About 50% of sites running PHP are at versions less than 5.5: https://w3techs.com/technologies/details/pl-php/5/all https://w3techs.com/technologies/details/pl-php/5/all https://w3techs.com/technologies/details/pl-php/all/all https://w3techs.com/technologies/details/pl-php/all/all 4. Updating PHP is not like simply updating my Web browser. Real-world production hosts like mine are filled with various work by various developers over years. Bumping PHP further than a maintenance release would almost certainly mean unnecessarily breaking things that are hard to find, probably tricky to fix and written by people I’ve never met who are long gone.
- smsm42 9y ago
  5.3??? 5.3 has been EOL for 3.5 years now. I do not envy the person that has to maintain backports for so many years. In fact, I'm not even sure all the backports would always work properly...

smacktoward 9y ago

What's needed here is a "naming and shaming" effort. Make a public directory of bad PHP tutorials/references/etc., with the names of the people and companies who wrote and host them prominently attached. Maybe even give them a score, based on how frequently cited/linked to their bad advice has become, or how many pieces of it they've proffered. Then only take them off the list when the documents are cleaned up or removed. If you're a professional PHP developer or a company that builds on PHP, it would be very embarrassing to find yourself prominently featured on such a list. Which would create an incentive for those people to clean up their work so they can get off it. As things stand currently, publishing outdated and dangerous information costs the publisher nothing, so they see no reason to stop doing it. Create a cost by attaching reputational damage to the act, and you create a reason for them to stop.

CiPHPerCoder 9y ago
That's certainly a novel approach to solving the problem. I'm hesitant to do this myself, because it might open us to legal action, and I don't have the emotional bandwidth or cash reserves to fight a lawsuit right now.
thehardsphere 9y ago
This plan would fail, because someone sophisticated enough to find the naming and shaming list of awfulness would probably already be sophisticated enough to realize that old, bad advice is bad and why it is, and where to find new, good information. The problem is not merely that bad old content exists, but there is a class of PHP developer who is insufficiently sophisticated to distinguish between good and bad information independently. Whether that's a feature or a bug of PHP is an exercise I leave for the reader.
astrodust 9y ago
YouTube is littered with awful, preposterously bad tutorials. If there's one thing that'd fix PHP it'd be for the community to put out better, more prominent, higher quality material than the toxic dreck that's out there. This isn't to say that there aren't good YouTube videos, but for each one of these there's easily a hundred where people with no clue are explaining PHP as if they know everything.

laurencei 9y ago

Can you get StackOverflow to "sponser" this idea? Not just for crypto (which you've done) - but for all PHP related answers? Because the problem is there are many "old" accepted answers, with high upvotes, that will always come up as number 1 or 2 in google searches. Given PHP has changed so much, many of those answers are outdated, use incorrect and insecure methods, and some are now just wrong. This is not just security - but a whole host of answers. The "meta" StackOverflow rules will tell you to downvote the old answer and post a new one - but that is not practical - and will take years to take effect. Plus, many people simply read the first large upvoted answer, copy + paste the code, and move on. edit: I guess it would be nice to be able to "flag" an accepted answer (not a question) as outdated, get 5x people with gold badges for that tag to accept it - and then the answer is highlighed as wrong/out of date (or even deleted). Something like that.

CiPHPerCoder 9y ago
> Can you get StackOverflow to "sponser" this idea? Possibly. I wouldn't even know where to begin. > Because the problem is there are many "old" accepted answers, with high upvotes, that will always come up as number 1 or 2 in google searches. Yeah, that's my concern. I can definitely edit anything tagged [php], due to having a gold [php] badge, and I think I can edit anything because I have a reputation higher than 10,000. The hardest problem for me, here, is identifying these old accepted answers with high upvotes. My general approach is something like this: https://stackoverflow.com/questions/tagged/php+encryption?sort=votes&pageSize=50 https://stackoverflow.com/questions/tagged/php+encryption?so... https://www.google.com/search?q=site%3Astackoverflow.com+php+encryption https://www.google.com/search?q=site%3Astackoverflow.com+php...
- laurencei 9y ago
  IMO (as someone with 45k rep on StackOverflow, largely in PHP) - the best way is to modify the "flag" option on answers - and have an extra option called "out of date". If someone flags an answer as out of date, then anyone with a gold badge in that tag (i.e. PHP) - can review and accept or decline the flag. If 5 gold people accept it - then the answer is formally highlighted as out of date, or even deleted. You could raise this on Meta Stackoverflow as one possible way to start: https://meta.stackoverflow.com/ https://meta.stackoverflow.com/ edit: There probably should be another flag option - called "security" - where even if an answer "works" and is "in date" - people can flag it as insecure due to a better option. Think of all the stupid SQL injection answers. You can downvote it to hell - but sometimes they should just be flagged/deleted.

mywittyname 9y ago

I think it would be better to write a plugin for various PHP IDEs that contain fingerprints of bad code which is used to yell at the programmer if they are using these old, insecure code snippets. Heck, you could add a feature or note to the developer to down-vote the source of said code. It would be a lot of work, but I think it's easier than trying to get authors of defunked blogs to take down 10 year old answers. As a side-effect, this increases awareness among developers that you can't blindly accept what's on SO. If developers begin to lose trust in SO, then SO is going to be incentivized to do something about, or go the way of expertsexchange.

SadWebDeveloper 9y ago
you will have to add support for the vim/emacs guys, there are dozens of unix zealots still developing like in the ancient days.
firefoxd 9y ago
I've been using netbeans recently and it has this very annoying and effective squiggles that warn you when you use deprecated stuff. It also tries to enforce some best practices by default
- smt88 9y ago
  PHP also has runtime errors for deprecated functions when using strict mode, which everyone should use
DCoder 9y ago
There's a plugin for IntelliJ IDEs called "PHP Inspections (EA Extended)" [0] that detects some of these compatibility and security problems. [0]: https://plugins.jetbrains.com/plugin/7622-php-inspections-ea-extended- https://plugins.jetbrains.com/plugin/7622-php-inspections-ea...
- mywittyname 9y ago
  This could certainly be a starting off point for what I was imagining. I was thinking that they could do analysis on code snippets that are copy-pasted into the editor. It should be straight-forward to compare the contents to a finger-print database and issue a warning when they find a match to online code examples that are marked as vulnerable.

kbenson 9y ago

Well, PHP has finally come full circle in the lifecycle. It's fully following in the footsteps of Perl. There was a big push and a lot of talk in the Perl community around 2010-2012 to find and remove old and poor quality Perl tutorials so people searching didn't end up with bad information. Part of this push included writing new and better tutorials and trying to get them placed higher in results for old tutorials that could not or would not be removed. Since we all saw and remember how Perl regained it's top spot as most popular programming language, I'm sure this will work out wonderfully. :/

lkrubner 9y ago
I almost wrote a similar comment, but I figured I would be downvoted. I realize it sounds cynical, but why should this effort be made for PHP? I loved PHP back in the year 2000, and at that time it had advantages that no other language had, but those days are long gone. There are many better languages now. I wrote about this in my essay "PHP is obsolete" and there was a fairly good conversation about that essay on Hacker News: https://news.ycombinator.com/item?id=9598309 https://news.ycombinator.com/item?id=9598309
- CiPHPerCoder 9y ago
  > but why should this effort be made for PHP? See https://w3techs.com/technologies/overview/programming_language/all https://w3techs.com/technologies/overview/programming_langua... Anyone who wants a more secure Internet must necessarily be interested in improving the security of PHP.
  - code_duck 9y ago
    The figures on that page don’t mean that 83% of developers use PHP... Just that some things written in PHP are very popular. I’m sure that most of that figure is packages like WordPress.
    - CiPHPerCoder 9y ago
      Most of the Internet (5 out of 6 websites) is powered by PHP. This is true despite people saying "don't use PHP". I didn't imply that 83% of developers use PHP. I'm sorry if anyone read it that way. I'm zeroed-in on the "what powers the Internet" statistic.

banhfun 9y ago

A better idea would be to make PHP a thing of the past.

astrodust 9y ago
A laudable goal, but you know, destined for failure.
sumedh 9y ago
Companies are still using Cobol

stcredzero 9y ago

Golang community, please take the history of the PHP community as a series of models for 1) what to do and 2) what not to do! Also do this for Java, Ruby, Javascript, LISP, C++, and Smalltalk! And if you think the history of PHP isn't applicable, then go and find the Golang library authors who are advocating filtering as a defense against SQL injection!

wcr3 9y ago

or just php in general. just a thought.

deanclatworthy 9y ago

Hi Scott, thanks for all the great efforts. This is a good start, and baseline but security is so much harder once you get past these basics. Once you get into the realm of timing attacks and all the ways to fuck up password recovery for example, it becomes a mine field. What can we do about that, short of “use framework X or Y” as they are the only ones peer reviewed?

fernly 9y ago

> we can raze the mountains of collective technical debt that have accumulated over the past decade. Not likely when professionally written code is full of errors, many security-related (e.g. attempting to load and execute .gifs). I recently presented a compilation[1] of the errors produced by one widely-used commercial ad function. If this is how a professionals write commercial code, I don't want to imagine what amateurs have been doing. [1] https://www.reddit.com/r/web_programming/comments/7o8dzf/copious_and_varied_errors_from/ https://www.reddit.com/r/web_programming/comments/7o8dzf/cop...

avenius 9y ago
Sounds like an intentionally malicious function to me - just waiting for a proper payload.

EGreg 9y ago

I want to recommend another technique these days: 1) Sign (HMAC) all the session ids that your server issues. This allows requests with bogus session ids to be rejected at the network borders without doing any I/O or hitting the database. 2) Use web crypto (now supported by all major browsers) to have clients generate a private key with which to sign all requests. Using session keys as bearer tokens opens users up to attacks. 3) Do NOT send passwords to the server! Use passwords to decrypt the private key, and do not expose the decrypted key to external Javascript. And make sure the key can't be exported. 4) Clients authenticate new devices using two-factor authentication. If the person is using a previously authorized device and knows their password this may be considered two factors already. Unless the password was saved, in which case they better have a password on their device. Ultimately you gotta trust the OS. 5) Authentication and authorization for data may be done automatically by a side-channel (QR code via camera, or bluetooth) with the proof submitted to the server by either device. Revocation ultimately needs a blockchain. 6) If you lost all your authorized devices, the backup should be: M of N public keys, plus a passphrase you know. This is only for rare cases and the passphrase can be weak. No more passwords except for the above!!

CiPHPerCoder 9y ago
Please tell me you've seen this before? https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- EGreg 9y ago
  I haven't seen this particular article, but having read it, I can tell you: there are different threat models. You can't be secure against them all on the Web. Of course we have to trust the server to deliver the initial code. The same is true with apps delivered via the appstore etc. But that doesn't mean you should be send and storing password hashes to the server, even if generated by PHP. It doesn't mean you should be using the session cookie alone as a bearer token to access a session. First of all, you have to agree that a security requirement in addition to a cookie doesn't make things less secure. Secondly, with Web Crypto the Web has a way to mark keys "non exportable". If the website is sending you the wrong resources then of course anything can be sent, and web-based code isn't the ultimate way to protect the user. The same is true of other approaches. However if the initial code download wasn't tampered with, then you are far more protected. Because the secret private key won't be exported from the browser website. And it won't be accessible to anyone outside the JS environment that asks for your password or finger to derive a key to decrypt the master key from the local database. And in that JS environment, you can make sure (via closures) that no one gets access to it in "userland". OH AND YOU SHOULD ALSO BE USING A PRIVATE KEY PER USER TO ENCRYPT DATA AT REST ON YOUR DATABASE, AND STORE THIS KEY IN THE DB MULTIPLE TIMES - EACH ONE ENCRYPTED BY THE USER'S DEVICE KEY. You don't store these device keys. Successfully authentication requests from the device send this key. So once again you need to obtain this key in order to unlock user's info needed for the request. And users can send permissions to unlock their information to each other in sidechannels. You can take this security VERY far... So it's strictly more secure than the server side database for passwords, even hashed and salted with key strengthening. BUT, don't advertise it because then it introduces security attacks where people over-rely on this to te detriment of the vectors mentioned in the article. PS: Oh. This was written in 2011, before the Web Crypto standard I am referring to was published and adopted by all web browsers. I do NOT recommend doing the crypto methods in JS! And yes it has a secure RNG now. https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_... Also Object.freeze() is a thing now.

ewams 9y ago

I disagree with their suggestion to comment out or remove old PHP code. People need to have a date and timestamp at their top of the articles AND state what version of PHP they are coding for. Information on older version should not be pruned as there are legitimate reasons to keep them. Not everyone is using PHP 7; what do you do when you inherit an older code base; what do you do when you just need to modify a few things on an older code base; what if you are trying to learn security based programming; what if you are trying to learn how to break into systems (to then learn how to protect them); what if PHP7 is not available or feasible for your project; etc.

leetbulb 9y ago

I've been a PHP developer for over ten years. Paragon Initiative is amazing. Their Github repos are full of useful things: https://github.com/paragonie https://github.com/paragonie