Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP Commandments

biasedphp.com

Post reply on HN
Print view View original

111–117 of 117 posts

Re: PHP Commandments

#111

Post by krapp »

EvilTerran wrote: post #110
krapp wrote: post #79

Earlier quoted context omitted.

If they aren't sanitized or validated they can generate exceptions or contain malicious data which leads to XSS or SQL injection after they've been reflected back to the user or added to a database. Since the values in these arrays come from the user, they should always be considered actively hostile and treated as such.

Ah, gotcha. So, treat them like they're "tainted", in perl parlance. I was thinking that remark was intended more along the lines of "never use $_GET and $_POST directly, only ever access them via something like Symfony's sfWebRequest::getGetParameter/getParameterHolder/etc", which struck me as a bit overzealous as such rules go.

Yeah, just make sure somewhere you're doing all the checking (type, length, character set, providing sane defaults, etc.) that other languages probably do for you.

Because users are evil and want to destroy you and PHP is only too happy to help them... :\

Re: PHP Commandments

#112

Post by PavlovsCat »

grobolom wrote: post #109
rmrfrmrf wrote: post #105

Earlier quoted context omitted.

ArrayHelpers::array_select_keys() makes it obvious that array_select_keys() is a user defined function. ArrayHelpers helps me never wonder about where to find an array convenience function. ("array_select_keys() must be in the ArrayHelpers class" vs. "Hmm...where is that function...ugh ok let me run a find on it...oh there it is, right in between create_html_tag() and get_primes()"). ArrayHelpers lets me do lazy load…

You know we've all seen helper.php files that are so monolithic Yes. This has nothing to do with flat functions vs. classes. I've seen 'helper' classes get shitted up just as much as function files. My point is that it doesn't matter. Many projects don't require heavy portability, and in either case, bootstrapping a namespaced shim next to your autoloader isn't a problem. I'm not arguing that if you have a very exten…

Never ever write your code to the taste of some random other person who wouldn't contribute anyway, that's my motto...

Re: PHP Commandments

#113

Post by EvilTerran »

krapp wrote: post #111
EvilTerran wrote: post #110

Earlier quoted context omitted.

Ah, gotcha. So, treat them like they're "tainted", in perl parlance. I was thinking that remark was intended more along the lines of "never use $_GET and $_POST directly, only ever access them via something like Symfony's sfWebRequest::getGetParameter/getParameterHolder/etc", which struck me as a bit overzealous as such rules go.

Yeah, just make sure somewhere you're doing all the checking (type, length, character set, providing sane defaults, etc.) that other languages probably do for you. Because users are evil and want to destroy you and PHP is only too happy to help them... :\

Yeah, I often feel like PHP is trying to destroy me.

/ used Haskell at uni, loved it

// first job in the real world is... web dev, on a sprawling legacy PHP codebase, with no documentation or tests

/// I miss my static guarantees :(

Re: PHP Commandments

#114

Post by Piskvorrr »

martin_ wrote: post #6

Few comments.. #3 assumes that the variable came from user input, it's not necessarily bad. In some cases (i.e. dynamically switching from ORDER BY ASC/DESC) it's quite acceptable. But PDO + prepared statements for sure. #4 no need to use a library, htmlspecialchars/htmlentities are quite enough. #5 I think many frameworks/libraries can go here - why pick on one? #7 Mailgun, sengrid etc are becoming increasingly popu…

I don't favor require, I require it (sorry for the pun).

The main issue is that include() will just emit a warning and continue if the file doesn't exist, often leading to a confusing fatal error in a completely different part of the code; in other words, On Error Continue Next, PHP version. Even worse, people who use include are even more likely to use @include().

Oh, and require_once(), while we're on the subject: "if you're purposefully trying to require() a file twice, you're doing something Very Wrong."

Re: PHP Commandments

#115

Post by Piskvorrr »

rmrfrmrf wrote: post #18

These are the "PHP Commandments"? How about we set the bar a little higher? Anyone who has had longer than 1 day's worth of training with PHP should know these things.

Should is the operative word. I keep being amazed at what people ought to know, yet don't.

Re: PHP Commandments

#116

Post by Piskvorrr »

UnoriginalGuy wrote: post #90
chacham15 wrote: post #64

Earlier quoted context omitted.

No. >MD5 was very much acceptable for the longest time. MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed. This is bad for passwords. What you should be using is the opposite: an expensive hash to compute. This is bcrypt which has been in use since 1999 (and what the PHPass is based on). This is a clear example of "Dont do your own crypto" becau…

> MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed. That's strange to hear you say that, because I remember people having huge arguments in the 1990s about how they couldn't use MD5 because it was /so/ slow and how 3DES was the only way to go! I swear people love to re-write history. > This is a clear example of "Dont do your own crypto" becaus…

You obviously have no idea how bcrypt works; go search for "bcrypt work factor". In other words, making bcrypt slower while remaining secure is a matter of changing the work factor.

(This doesn't preclude bcrypt falling from grace for having - as of yet undiscovered - other security flaws; but it is designed with Moore's Law in mind. Saying "I don't know why everyone praises bcrypt, but HEY LOOK AT ME REBELLING, BCRYPT SUXXORZ!" is not very effective.)

Re: PHP Commandments

#117

Post by Piskvorrr »

Dylan16807 wrote: post #89
Joeri wrote: post #80

Earlier quoted context omitted.

Hashcat can do 5 billion md5 hashes per second on a single gpu. Even difficult passwords are crackable in md5.

Adding six lowercase characters/numbers increases the difficulty by a factor of a billion. So if you look at a typical 8 character rule and go up to 14 random characters you're perfectly safe on md5.

...which, sadly, will lead to a proliferation of yellow stickies. Depending on the physical security of the individual workstation, this may not necessarily be a bad thing (but in the most common case "anyone has physical access" probably will be)
Post reply on HN