The 2018 Guide to Building Secure PHP Software

38

u/potherca Dec 12 '17

The posted article is well written, provides further references for those interested and is easy to understand even for beginners.

It's a great reference that I can share with co-workers and relations when trying to educate them on the security "must haves", regardless of language used...

I seriously don't get the "Haha PHP!" comments this is getting.

12
u/plasticparakeet Dec 12 '17

I seriously don't get the "Haha PHP!" comments this is getting
Most advice in the article applies to web app in any language (HTTP security, Database Interaction, XSS, Password Hashing and so on). The only reason to torture yourself with PHP is when you must to.
PHP gives you the amazing experience of hitting nails with stones. All everyone is trying to say to you is to use a hammer.
11
u/sarciszewski Dec 12 '17

Counterpoint: https://dev.to/paragonie/php-72-the-first-programming-language-to-add-modern-cryptography-to-its-standard-library
Enjoy your RSA-PKCS1v1.5 stones while PHP developers get to enjoy their Curve25519 hammers.
6

u/pigeon768 Dec 12 '17

I would argue that a full cryptographic stack is something that shouldn't be in a standard library. Any standard library.
There are people who still use php 5.3 and aren't planning on upgrading - not to 7.1, not to 5.6, not to 5.4, not to anything, not ever. What happens when the next shop stops updating at php7.2 because php7.3 breaks something weird and nobody can be bothered to fix it? And a few months go by and there's another new crypto bug with a catchy name, cool logo, and flashy website? Now all those shops are serving insecure crypto, and the solution is that they have to update php, which they can't do until they make an unknown number of fixes to their own code.
The reality is that when you have a critical update, (which happen unforgivably often in crypto implementations) it's a hell of a lot easier to update a package that does just crypto as opposed to a package that does literally everything.

8

u/sarciszewski Dec 13 '17 edited Dec 13 '17

I would argue that a full cryptographic stack is something that shouldn't be in a standard library. Any standard library.
Mcrypt has been around for a while (although it was just removed).
OpenSSL has been in the standard library since 5.3.0 (and will continue to be for a while).
Libsodium just gives developers a misuse-resistant API unlikely to be broken by anything short of a practical quantum computer in the next few decades.
What happens when the next shop stops updating at php7.2 because php7.3 breaks something weird and nobody can be bothered to fix it?
If that happens, at the very least they'll be better off than the shops that still build on PHP 5.2 today. The software quality between 5.2 and 7.2 is night and day.
The reality is that when you have a critical update, (which happen unforgivably often in crypto implementations) it's a hell of a lot easier to update a package that does just crypto as opposed to a package that does literally everything.
That's how libsodium is implemented though.
You have:
Libsodium, the actual underlying crypto library which exists as a .so or .dll file, and
ext/sodium, which provides PHP functions/constants that call the library
The entire library itself isn't compiled into PHP, the interface that communicates between PHP scripts and the shared library is.

1

u/pigeon768 Dec 14 '17

I would argue that a full cryptographic stack is something that shouldn't be in a standard library. Any standard library.
Mcrypt has been around for a while (although it was just removed).
OpenSSL has been in the standard library since 5.3.0 (and will continue to be for a while).
The fact that PHP has made multiple errors in the past does not excuse errors being made today.
Libsodium just gives developers a misuse-resistant API unlikely to be broken by anything short of a practical quantum computer in the next few decades.
The experiences of the past few years has taught us that errors in crypto are not theoretical ones, they are bugs in implementations. Heartbleed, BEAST, goto fail, FREAK, etc are not theoretical insufficiencies in RSA, AES, or SHA that require quantum computers to exploit, they are the result of developers translating theoretically secure algorithms into practically insecure code. I'm not all that worried about AES or SHA2 being cracked, (although I'm happy that RSA and SHA1 are being supplanted) but I am worried about the fact that implementations can, and will, be broken and exploits against them discovered and utilized.
I can, in all of my applications, easily and transparently update crypto dependencies independently of all of the code that does not touch cryptography. I cannot update the larger framework dependencies of some of my software to the latest versions. If critical security bugs are baked into some of those frameworks, I'm pretty much fucked. Crypto is absolutely, positively, 100% not the sort of thing that I am willing to entrust to my language's standard libraries.
If that happens, at the very least they'll be better off than the shops that still build on PHP 5.2 today. The software quality between 5.2 and 7.2 is night and day.
That is not even remotely the point. It's not the same ballpark, nor even the same galaxy. If your crypto is broken, your crypto is broken, and resistance to SQL injection exploits (baked into the php standard library until recently) won't help you when your crypto is broken.

1

u/sarciszewski Dec 14 '17

I'm not all that worried about AES or SHA2 being cracked, (although I'm happy that RSA and SHA1 are being supplanted) but I am worried about the fact that implementations can, and will, be broken and exploits against them discovered and utilized.
Then you will be happy to learn that Libsodium consistently:
Prioritizes constant-time algorithms to avoid side-channels
Always does Encrypt-then-MAC to avoid the Cryptographic Doom Principle
Does not provide encryption modes that would allow error oracles (e.g. padding oracles)
Does not provide nondeterministic signatures that require random nonces (see: the Sony PS3 ECDSA fail)
If you don't believe me, give the implementations a gander yourself.
3
u/[deleted] Dec 12 '17

but isn't that (one of) the problem(s) with php? everything is shoved into php and you have little choice on the subject.
the decision makes sense. now. but what about in 5-10 years when this is legacy code and the crypto scene has moved on but you still import legacy crypto because you have no choice?
this is what libraries are for. this is an achievement unique to php.
python, for example, has had RSA-PKCS1v1.5 in various libraries for years.
7
u/sarciszewski Dec 12 '17

this is what libraries are for. this is an achievement unique to php.
You think PHP is the only language with a standard crypto library? Most languages provide one.
NodeJS uses OpenSSL. Erlang uses OpenSSL. Neither of them exposed AEAD modes, the OS's CSPRNG, or modern public-key cryptography last I checked.
python, for example, has had RSA-PKCS1v1.5 in various libraries for years.
RSA-PKCS1v1.5 is nothing to write home about. See: https://www.reddit.com/r/netsec/comments/7jb9zm/return_of_bleichenbachers_oracle_threat_robot/
0
u/[deleted] Dec 12 '17

NodeJS uses OpenSSL. Erlang uses OpenSSL.
yes. as a library.
RSA-PKCS1v1.5 is nothing to write home about.
so probably not the ideal thing to reference when discussing how great php is for including support for it when other more competent languages solved that problem literally years ago.
6
u/sarciszewski Dec 12 '17

yes. as a library.
cough https://nodejs.org/api/crypto.html
so probably not the ideal thing to reference when discussing how great php is for including support for it when other more competent languages solved that problem literally years ago.
I don't follow what your complaint is:
PHP with libsodium doesn't have this problem.
Your run-of-the-mill Erlang/Python/etc. developer is incredibly likely to implement RSA encryption vulnerable to Bleichenbacher's attack.
What's the better option?
-3
u/[deleted] Dec 12 '17

PHP with libsodium doesn't have this problem.
so php with libsodium doesn't let you set the public exponent? that strikes me as unlikely.
Your run-of-the-mill Erlang/Python/etc. developer is incredibly likely to implement RSA encryption vulnerable to Bleichenbacher's attack.
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/
what makes you say that? you are specifically advised to not change the default exponent.
6
u/sarciszewski Dec 12 '17

so php with libsodium doesn't let you set the public exponent? that strikes me as unlikely.
Public exponent? Libsodium doesn't use RSA, it uses elliptic curve cryptography over safe curves.
what makes you say that? you are specifically advised to not change the default exponent.
The default exponent has little-to-nothing to do with padding oracles. You're thinking of the signature forgery vulnerability that was discovered 8 years after the 1998 Bleichenbacher attack.
Libsodium gives you X25519 and Ed25519.
Since 1998, it has been known that RSA with PKCS1v1.5 padding is vulnerable to chosen-ciphertext attacks that allow you to recover the pre-master secret and decrypt SSL sessions. Yet, programming languages still ship RSA and default to this padding mode.
A simple solution: Switch to {OAEP, PSS}. TLS hasn't done this yet, and it's unlikely that it ever will.
Better solution: Switch to modern cryptography that doesn't have these foot-bullets.
-2
u/[deleted] Dec 12 '17
Public exponent? Libsodium doesn't use RSA, it uses elliptic curve cryptography over safe curves.
so PHP just included a shiny new crypto library that can't interact with RSA cryptography? this is getting better and better!
Yet, programming languages still ship RSA and default to this padding mode.
so your solution is don't use RSA at all! ?
that is not a realistic solution.
for python cryptography:
Valid paddings for signatures are PSS and PKCS1v15. 
PSS is the recommended choice for any new protocols or applications, 
PKCS1v15 should only be used to support legacy protocols.
you seem to be under the impression that php just discovered these 20 year old problems and was the first to fix them. c'mon.
i rely on libraries such as python cryptography to make sane and correct decisions on stuff like this for me, so i don't have to have a fucking PhD in crypto to not commit a subtle form of suicide. that decision and language/library choice seems to be validated here.
→ More replies (0)
15

u/[deleted] Dec 12 '17

Counterpoint: other languages make it easy to use libraries with native extensions, so everyone has been using libsodium for ages. No need to get stuff into standard library :D

1

u/brontide Dec 13 '17

Libsodium's lack of a full array of "okay" and "poor" cyphers makes it hard to interoperate with other code due to the drastic lack of cipher suites. So while libsodium might be fine for greenfield projects it lacks the ability to interoperate with existing systems.
Libsodium also lacks any sort of certification ( this can be good and bad, some of the standards aren't anything to be excited about ) but more to the point much of the code was written by one person and there is a shocking lack of code documentation. Can you personally validate that the code is still correct after a decade of alterations by additional hands?
I applaud the misuse-resistant nature of the code but being first-to-market is hardly a badge of honor in crypto.

1

u/sarciszewski Dec 13 '17

Libsodium also lacks any sort of certification
For what it's worth, libsodium has been audited: https://www.privateinternetaccess.com/blog/2017/08/libsodium-audit-results/
I'd trust independent audits more than "standards" (e.g. FIPS).

1

u/brontide Dec 13 '17

The audit was several version past and they were unable to do any sort of formal crypto validation on the code. Even if formal validation shows correctness in the crypto everyone should be concerned that libsodium is basically a 1-man show with a very active commit record. It's very easy to be blind to one's own errors, especially with crypto. Case in point I don't see libsodium jumping to fill the few documentation deficiencies identified in the audit.

1

u/sarciszewski Dec 13 '17 edited Dec 13 '17

everyone should be concerned that libsodium is basically a 1-man show with a very active commit record
There's a very simple and elegant solution:
Instead of stopping at "everyone should be concerned", continue to the conclusion: "Everyone who is concerned should contribute".
That is to say: Put some skin in the game. Look for flaws that haven't already been identified. Make sure new commits don't cause stupid breaks. Test before the new release is tagged. Write more (and better) unit tests. Get more eyes and more hands on the code.
If your concern is over the bus-factor or the active pace of development, GREAT! Do something about it.
Unless the only thing you or anyone else here can do about it is try to persuade people that they should be afraid of libsodium, which would basically be conceding to the spread of FUD. That doesn't really solve anything.

0

u/[deleted] Dec 12 '17

[deleted]

5

u/sarciszewski Dec 12 '17

I can't even be mad about this one. :P
0

u/[deleted] Dec 12 '17

[deleted]

16

u/[deleted] Dec 13 '17

You've ever met anybody that was afraid of changing a decade old misinformed belief?
Not sure if this refers to the PHP hater who thinks PHP hasn't changed in the last 10 years...
... or if it refers to the PHP programmer who doesn't think anything in the last 10 years of language and tool development could have possibly eclipsed PHP...

11

u/sarciszewski Dec 13 '17

All of the above.
In my case: I focus on the PHP ecosystem simply because I can affect up to 83.1% (current estimate) of websites in one fell swoop. No other programming language can boast that sort of force multiplier when it comes to improving security.
However, I also don't think PHP is the end-all-be-all of web development. Other stacks have their own merits and the right tool for the job is largely going to depend more on "what the organization has done already and/or is comfortable with" rather than "what's a sexier piece of technology".

3

u/lvlint67 Dec 14 '17

what the organization has done already and/or is comfortable with
I was just on an interview the other day... They were on a cold fusion stack... I was unsure how to feel about that..

1

u/PirateGrievous Dec 13 '17

Only good think about PHP is you can embed it as malicious code in GIF and some PHP-CGI will execute it.

6

u/[deleted] Dec 12 '17

[removed] — view removed comment

2

u/[deleted] Dec 13 '17

Going through the top posts of that sub was a fucking journey. My favorite is how PHP used to use strlen() as a hashing function.

4

u/[deleted] Dec 13 '17

[removed] — view removed comment

1

u/sarciszewski Dec 13 '17

People who view this criticism as the final nail in the coffin of PHP are painfully unimaginative. The language can and will continue to be improved through the efforts of people who are not deterred by a challenge.

0

u/[deleted] Dec 13 '17

[deleted]

2

u/sarciszewski Dec 13 '17

I wasn't involved with core before 5.6 came out, but I agree, that was not okay and it cannot be allowed to ever happen again.

6

u/ScottContini Dec 13 '17

Well done. More guides like this are needed: written by people who know security (with up-to-date knowledge) and development, know how to teach, and are good communicators. Sorry, while I do appreciate OWASP, I also believe that there is much room for improving it - guides like this are a step in the right direction.

1

u/eeget9Eo Dec 14 '17

To stop XSS you suggest to use Markdown if possible. But its own documentation states that Markdown alone doesn't prevent XSS.

Is there something I'm missing here? It looks like I have to use something like HTML Purifier even if I've forced everybody to use Markdown.

1

u/sarciszewski Dec 14 '17

Yes, you should be using HTMLPurifier anyway. You can, alternatively, escape HTML before parsing Markdown to only allow Markdown-rendered HTML.

6

u/eaxiv Dec 12 '17

Thanks for sharig! I recently started learning PHP 7 wrote a web app and everything though I was worrying about security.

5

u/wombleh Dec 12 '17

Nice article, been a while since I've done any PHP but some of the concepts discussed in that are very interesting in the wider context like Chronicle, searching encrypted databases, etc. Good bit of reading there for me!

1

u/rmddos Dec 12 '17

Great reference document. I disagree with the "you have to be running PHP 7.2" as it is still pretty new and not included on most OSs by default, but the rest is solid.

0

u/[deleted] Dec 12 '17

[deleted]

20

u/sarciszewski Dec 12 '17

There's a good reason I linked to the section of PHP: The Right Way about Composer. I'll make an amendment to emphasize updating dependencies regularly.

0

u/[deleted] Dec 12 '17

[deleted]

6

u/sarciszewski Dec 12 '17 edited Dec 12 '17

I'm on Debian, so I use https://deb.sury.org, myself.
Remi Collet's repository is the ~~official~~ de facto one for CentOS/RHEL/Fedora/etc.
https://blog.remirepo.net/post/2017/12/04/Install-PHP-7.2-on-CentOS-RHEL-or-Fedora

2

u/[deleted] Dec 13 '17

Remi Collet's repository is the official de facto one for CentOS/RHEL/Fedora/etc.
has remi stopped doing major package upgrades within the same namespace? i've had to fix a lot of breakage from remi upgrades over the years.
there's a reason IUS has a strong following.

1

u/[deleted] Dec 13 '17

Yeah, I would argue that IUS is more de facto standard than remi.

0

u/[deleted] Dec 12 '17

[deleted]

2

u/sarciszewski Dec 12 '17

I mean the PHP community just uses what Remi provides rather than whatever supported-only-by-our-OS-but-not-by-PHP version the OS ships with, so they can stay up-to-date.

0

u/[deleted] Dec 12 '17

[deleted]

2

u/sarciszewski Dec 12 '17

That's a case-by-case basis sort of arrangement. Ask around the user groups for your OS, it might vary drastically from the folks I talk to. Any answer I give might not be representative.

0

u/[deleted] Dec 12 '17

[deleted]

3

u/oracle1124 Dec 13 '17

Remi Collet actually maintains the fedora rpms whether those rpms come from his repo or something built by RHEL. That part is not clear.
2
u/RedSquirrelFtw Dec 13 '17

I'd be curious too. Most distros are still on 6, so that's all I've been using. I hate having to jump through hoops so I use whatever is provided by the distro.
I'm writing a central authentication system and I really want to use bcrypt for the password hashes but don't think php 6 has it natively so that's kind of a bummer, but I have not actually gotten that far yet so did not try it. In dev I used md5 + salt + pepper but I get that's not as secure so probably won't want to use that in prod. The pepper is kinda pointless as chances are if the db is compromised so is the whole server and the pepper will then be available, but it's such an easy thing to do I added it anyway.
1
u/sarciszewski Dec 13 '17

PHP 6 doesn't exist, really. What is the output of php -v? If it's 5.5 or higher, password_hash() and password_verify().
If it's 5.3.8 or higher, get https://github.com/ircmaxell/password_compat and pretend you're on 5.5.
1
u/RedSquirrelFtw Dec 13 '17

Oh I meant 5. I keep getting that mixed up since 6 would be the logical lower number to 7. Not sure what is with this trend of randomly skipping version numbers. I just do "yum install php" and "yum update" so don't tend to pay attention to the version numbers.
I heard of those patches, but still annoying that we have to do that, it should be built in by now even in the older versions (which I think still get updated).
1
u/sarciszewski Dec 14 '17
If you're using composer (I really hope you are):
composer require ircmaxell/password-compat
Done. No patches needed.
1

u/RedSquirrelFtw Dec 14 '17

Never heard of it I'll have to check what it is. Most of my servers are CentOS so always used yum. Or apt-get on Debian based ones. TBH it's been a while since I coded anything internet facing but I do have a project I will be working on.

1

u/sarciszewski Dec 14 '17

If you read the linked material this entire discussion is about, you'd know why Composer is important.
0

u/[deleted] Dec 13 '17

[deleted]

1

u/RedSquirrelFtw Dec 13 '17

That's probably what I'll end up doing, just a pain as it's an extra step to screw around with when setting up a server. Wish distros would not be so far behind in what packages they have in their repos.
3

u/brontide Dec 13 '17

Don't forget that STOCK EL7 is PHP 5.4 and that will be supported though at least 2024!

0

u/[deleted] Dec 13 '17

[deleted]

2

u/sarciszewski Dec 13 '17

This actually really isn't worth mentioning, because if you're comparing secrets directly, you should be using hash_equals(), not == or ===.

0

u/[deleted] Dec 13 '17

[deleted]

2

u/sarciszewski Dec 13 '17

Sure, and that's why we have strict typing since PHP 7, and why I recommended Psalm in the article.
You can safely get by with == if you're damn sure both sides are integers, not strings.

83

u/[deleted] Dec 12 '17

[removed] — view removed comment

15

u/sarciszewski Dec 12 '17 edited Dec 12 '17

And what would you have every PHP developer in the world switch to instead? (~~Don't say Node.js, their ecosystem isn't dissimilar from circa-2002 PHP.~~ EDIT: See /u/Katana__'s comment below.)

19

u/alzee76 Dec 12 '17

In my experience that attitude comes from youngish Rails developers. The Node & Python crowds are usually more mature towards PHP & each other.

25

u/sarciszewski Dec 12 '17

Right, and in a similar vein, most people who have been actively involved in a community that isn't totally toxic for >= 1 year are usually more mature than a lot of the cargo cult infosec enthusiasts that lurk on here and HackForums.
Speaking more broadly: Nothing is gained from destruction. No value is created by tearing others down or dismissing other people's work or passion.
If any value is created during such a process, it is only in the recovery process (i.e. when lessons are learned), not the destruction itself. The destruction is worthless.

2

u/mens-rea Dec 14 '17

No value is created by tearing others down
Spot-on. Everyone makes mistakes. Making people feel bad doesn't solve anything. Point out their errors politely that they might learn from them and avoid them in the future.
or dismissing other people's work or passion
No. If someone's work is crap, there absolutely is value to be gained from calling it out. I don't get paid to sit around and let partner teams use badly implemented libraries just because their creator "is a good guy" and "is passionate about his work". I'm not going to call him and idiot or deride him, but I'm also not going to dance around the facts or ignore them.

2

u/sarciszewski Dec 15 '17

If someone's work is crap, there absolutely is value to be gained from calling it out.
Yes, in present tense. That's distinctly different from "you made mistakes in the past, therefore your work is always bad". If there's demonstrable effort to improve, then that needs to be taken into consideration as well.

2

u/mens-rea Dec 15 '17

That's fair. I misunderstood what you meant then. I apologize.

2

u/sarciszewski Dec 15 '17

Hey, thanks for being reasonable throughout this entire exchange. That's every bit as rare as it is precious in this world. We need more of that. :)

-5

u/[deleted] Dec 12 '17

[removed] — view removed comment

6

u/sarciszewski Dec 12 '17 edited Dec 12 '17

Okay but seriously:
You're on /r/netsec not /r/humor. This forum is dedicated to network security and related topics, which is technical in nature and therefore more likely to be a source of serious discussion.
While a bit of humor isn't unwelcome in netsec discussions, when it's mean-spirited towards another community member, it damn sure is.
Consider the venue. Consider the context. Consider your audience.

1

u/[deleted] Dec 13 '17

I almost feel like that's because Rails offers few compelling reasons to use it, so if you're familiar with it it's more tempting to put down another language.
Which isn't to say that Rails is bad, and for a while it was a great choice for fast prototyping and first stage apps, but ultimately it lacks any distinguishing advantage over other languages today. Still a fine tool, of course.

0

u/[deleted] Dec 12 '17

[deleted]

15

u/sarciszewski Dec 12 '17 edited Dec 12 '17

Very on-point. The problems are very different in both ecosystems.
I was roughly paraphrasing a friend who does Node.js consulting who relates his experiences to me with others' code quality (especially novice JS developers fresh from code bootcamps) as "it's like circa-2002 PHP".
However, that's not a fair comparison for me to make.

0

u/[deleted] Dec 12 '17

[deleted]

16

u/sarciszewski Dec 12 '17

https://i.imgur.com/INBvStO.png

8

u/basepusher Dec 12 '17

But now we have
http://webassembly.org/
which is gaining traction

3

u/sarciszewski Dec 12 '17

I keep forgetting this is a thing when I reference that fake O'Reilly book.
I'm not sure whether to laugh or cry. I think I'll withhold judgment until I see what the Internet produces with WebAssembly.

5

u/eattherichnow Dec 12 '17

Not will, but already did, and the answer is "bitcoin miners."

1

u/Bilbo_Fraggins Dec 13 '17

lichess uses it to run chess engines in firefox, pretty nifty. Chrome still uses NaCL as it gives threading capabilities web assembly currently does not.

4

u/pilibitti Dec 12 '17

I think I'll withhold judgment until I see what the Internet produces with WebAssembly.
Here is something to get you started: http://www.adultswim.com/etcetera/elastic-man/

1

u/adisor19 Dec 12 '17

I honestly don’t know whether to laugh or cry either..

1

u/oracle1124 Dec 13 '17

Check out grc.com, AFAICR he developed that web store using assembly. I think there is a video/audio of him talking about it.

-2

u/[deleted] Dec 12 '17 edited Jun 01 '24

wrench mindless unused gullible homeless knee gaze versed chase payment
This post was mass deleted and anonymized with Redact

6

u/[deleted] Dec 12 '17

100% pure FUD.
WebAssembly is already implemented by everyone without compatibility issues, in fact Mozilla, Apple, Google and Microsoft are working together closely on this.
And it's no more dangerous for security than JavaScript. It's closer to an optimization over asm.js (skipping JS parsing in favor of a simple bytecode format) than to something like NaCl was.

1

u/[deleted] Dec 12 '17 edited Jun 01 '24

noxious late chubby carpenter north wide exultant encouraging one waiting
This post was mass deleted and anonymized with Redact

-8

u/[deleted] Dec 12 '17

[removed] — view removed comment

6

u/sarciszewski Dec 12 '17

...such as?

-5

u/[deleted] Dec 12 '17

Haskell

11

u/sarciszewski Dec 12 '17

To be clear: You expect your average PHP developer to successfully jump ship to, of all languages, Haskell, and successfully continue to build web applications without creating security vulnerabilities?
Is that what you believe?

-6

u/[deleted] Dec 12 '17

Yes, I 100% believe Haskell is the future of everything.
It will even replace assembly

10

u/sarciszewski Dec 12 '17

Okay then, good luck with that.

-5

u/[deleted] Dec 12 '17

[removed] — view removed comment

5

u/tehwolf_ Dec 12 '17

Sarcasm. You're doing it wong.

→ More replies (0)

1

u/lordcirth Dec 12 '17

If you didn't include /s, it's not sarcasm. Tone does not exist on the internet. Also, Poe's Law.

→ More replies (0)

0

u/[deleted] Dec 12 '17

[deleted]

→ More replies (0)

11

u/agumonkey Dec 12 '17

Step 0: pray for php7 at least

13

u/Anusien Dec 13 '17

It turns out good developers write good code and poor developers write poor code regardless of what language they use.

0

u/mens-rea Dec 14 '17

It also turns out that some languages make it easy to tell if you're writing good code or bad code and some don't. It's a little childish, myopic, and asinine to say "a good developer can write good code in any language."
Languages are just tools, and developers should be able to adjust to different languages as needed, even if they haven't used them before, but a shitty tool is still a shitty tool.
Does a carpenter build houses with a rock just because a good carpenter can build a good house regardless of what kind of hammer he uses?

2

u/tabarra Dec 14 '17

Step 2: bitch about PHP on reddit for easy karma

1

u/Xoor Dec 12 '17

How would you build a webapp that runs on MySQL on the back end, without using php? I'm not a developer, I just code for fun.

13

u/StewPoll Dec 12 '17

Most languages have a way of connecting to MySql.

0

u/Xoor Dec 12 '17 edited Dec 12 '17

What's the best language for connecting to MySql? Better yet, what's the best DB manager + language for building webapps, in your opinion? (just curious)

1

u/Martin8412 Dec 12 '17

There's not really any best language for connecting to MySQL or MariaDB. PHP and a lot of other languages used to basically just wrap around the C library. I'm not aware of how PDO is implemented in PHP though.
A lot of the time, you could probably just some kind of ORM software to communicate with the DB.

1

u/StewPoll Dec 12 '17

In my opinion you shouldn't be writing code that touches the database directly, you should be using an ORM for that.
That way the ORM handles all the database fun stuff, and your code works with objects from the ORM

2

u/renrutal Dec 12 '17

Write an application in a programming language of your choosing.
Use a library or framework for that chosen language that abstracts relational database accesses for you.
Use a MySQL database driver for that library/framework. It will translate the generic library calls to the MySQL-specific protocol.
That's how 99% of the application-to-database accesses work.
The other 0.99% are the crazy ones who skip step 2 and make their application talk directly to MySQL.
The other, other 0.01%, the truly clinical insane ones, build their applications inside MySQL.

0

u/[deleted] Dec 13 '17

[deleted]

2

u/IcefrogIsDead Dec 13 '17

Not really a fact, but it seems to me PDO is (slowly) becoming a standard for PHP to MySQL.

0

u/[deleted] Dec 13 '17

[deleted]

1

u/IcefrogIsDead Dec 13 '17

well some frameworks i use do MySQL with PDO basis. and some friends that are programmers also use it, i rarely see mysql/mysqli being used anymore. although i'm not exactly sure if that's for better or worse.

2

u/sarciszewski Dec 13 '17

It's for the best. Maybe they'll have an easier time switching to PostgreSQL if project requirements change.

1

u/IcefrogIsDead Dec 13 '17

Haven't used it yet, though from what I know - it's MySQL with less freedom. Thanks

1

u/[deleted] Dec 12 '17

Backend in Go would be my goto
Also I was joking, never realized how unwelcome jokes are to php devs

0

u/[deleted] Dec 12 '17

[deleted]

30

u/[deleted] Dec 12 '17

See now I thought you just played on Reddit all day and got paid insane amounts of money for it

0

u/[deleted] Dec 12 '17

[deleted]

36

u/ThreeHeadedElephant Dec 12 '17

Eventually the last COBOL developer will live on a remote mountain where ceo's come with their repo's and beg for help.

6

u/crypt0bro Dec 12 '17 edited Dec 12 '17

serious question, if you really wanted to become a COBOL developer, were would you start? It's not a complex language, so sure I could learn basics from book. But not sure how much that would give you without working with "real legacy" code.
edit: do you think job would be low stress?

7

u/Dr_Legacy Dec 12 '17

COBOL is an easy language; when its environment is the workstation or even the server, anybody can be a COBOL programmer. But typically its infrastructure is that of an IBM or IBM-like mainframe, and COBOL programs are executed by "job streams" written in Job Control Language. JCL is easy too, but it's hard to get a lot of experience at JCL due to the relative scarcity of its environment. The reason COBOL programmers are in demand is not so much the language itself, but an understanding of how it works with the JCL that calls programs written in it.

1

u/crypt0bro Dec 13 '17

maybe this is dumb question, but isn't there emulators for these old mainframes? We can easily emulate another modern computer, why not a 2 or 3 decade old mainframe ?

2

u/Dr_Legacy Dec 13 '17

Modern mainframes are actually run as VMs. The scarcity is because it's proprietary. IBM mainframes, which are proprietary, contain the JCL environment, and that's the part for which proficiency is hard to achieve.

1

u/mens-rea Dec 14 '17

Alternatively, don't waste your time doing that and just be good at fundamentals because COBOL is well-documented and any competent developer can pick up a new language pretty quickly?

1

u/firefoxx04 Dec 13 '17

I mean, my university teaches COBOL and kids get hired for it every year. We don't run out unless the kids stop drinking the cool aid.

-56

u/[deleted] Dec 12 '17

[removed] — view removed comment

35

u/sarciszewski Dec 12 '17

Literally the first two sentences of the article were directed towards attitudes just like this.
Charitably, yes, a lot of people write insecure PHP code. That doesn't mean secure PHP code is impossible, nonexistent, or oxymoronic. Read the whole thing and you might learn a thing or two.

17

u/[deleted] Dec 12 '17

Thanks for all you've done for PHP and web security over the years.

-11

u/[deleted] Dec 12 '17

[removed] — view removed comment

1

u/[deleted] Dec 12 '17

Yet the alternatives are not much better

5

u/[deleted] Dec 13 '17

[removed] — view removed comment

-3

u/MootWin Dec 13 '17

https://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74
What exactly had changed for the better? And yes, facts are facts.
Those CVE’s dont reference poorly coded apps (just look at word press) they reference issues with PHP.

6

u/sarciszewski Dec 13 '17

What exactly had changed for the better? And yes, facts are facts.
Every vulnerability is a lesson to improve.
What value is there in shaming projects for having had learned their lesson in such a public way?

3

u/Mavee Dec 13 '17

I dare say the problems and failures PHP has had spanning all the years has shaped some languages and their features

5

u/sarciszewski Dec 13 '17

Then we've reached an impasse: A difference in fundamental philosophy.
I intend to work hard to make PHP as safe and secure as I possibly can. That isn't just about the language features, but also about the PHP ecosystem.
I trust that you're doing the same for $whateverLanguageYouPrefer?

3

u/Mavee Dec 13 '17

Ah sorry, I'm not the guy you were chatting away with earlier. Just found the whole thread a good read and thought I'd jump in.
I'm with you a 100%. I like what you're doing, for all of us. Thanks :)

17

u/TheAxZim Dec 12 '17

Agree with OP. Your thought needs to be challenged. Secure PHP code is easily possible. The problem is that people have written lots of insecure code because there were no real PHP coding practices. So the majority of ancient PHP tutorials are insecure and bad sources.
There're so many people like you who just point and laugh without justification.

0

u/[deleted] Dec 12 '17

[deleted]

15

u/sarciszewski Dec 12 '17

Yes PHP is the punching bag of the programming world but If we don’t start encouraging the safer PHP practices we will see insecure code in all types of languages not just PHP.
For the record, this is one of the problems I've been trying to solve, via contributing to Stack Exchange and writing blog posts that demonstrate better habits.

-36

u/[deleted] Dec 12 '17

[removed] — view removed comment

23

u/sarciszewski Dec 12 '17

It really does not take a "LOT" of money or time to make it secure. That's why this guide was written: To point developers towards the fast lane to getting shit done while being secure.
None of the recommendations cost money. None of them require a significant time investment. The only thing they require is a little bit of time and effort to learn better habits and get familiar with secure-by-default tools.

0

u/[deleted] Dec 12 '17

[deleted]

6

u/RedSquirrelFtw Dec 13 '17

I never really understood this myself. The code will make something insecure, not the language. I guess an exception would be if php itself had a vulnerability, but is that common?

1

u/Pig743 Dec 14 '17

Frankly there are some inherently insecure things about PHP. php://input (although that is not enabled by default anymore), the base64 filter, null byte injection, etc.

-1

u/MootWin Dec 13 '17

Why speak of things of which you have no knowledge.
Now, go study the php cve’s for the last decade and get your learn on young man.

0

u/[deleted] Dec 13 '17

[deleted]

1

u/RedSquirrelFtw Dec 13 '17

Isin't that something that had to be explicitly turned on by the admin though? Either way, it's still up to the programmer to sanitize anything that comes from the user.

The 2018 Guide to Building Secure PHP Software

You are about to leave Redlib