81–90 of 139 posts
I'm sure a lot of PHP 7.0 installations are still in production and will not receive a patch...
Earlier quoted context omitted.
Mailinabox as well.
According to [1] mailinabox seems to be not affected. [1] https://github.com/mail-in-a-box/mailinabox/issues/1663#issu...
Does anyone know if this exploit has any lasting effects? After this, you can start appending ?a= to all PHP scripts (you may need multiple retries). I'd love some way to confirm that my mitigations have worked and that I am no longer vulnerable but, y'know, running random slavic exploits against the server seems a bit sketchy.
As good a time as any to be reminded.. if you have to run any kind of PHP app, always keep it in its own VM and preferably with no access to anything except its own databases, and ideally with minimal outbound Internet access. PHP security has improved markedly over time (especially app security, not just the runtime), but it's still.. well.. stuff like this. This time around I'm lucky that the sole app I run was usi…
My job used to include writing PHP webpages that were exposed to the internet, and looking after the webservers they were running on. I'm, not responsible for any public-facing webservers any more. My life is much better. [Edit: I reckon using a well-designed functional language might reduce the risk - like, PHP was never designed at all, it grew by accretion]
Earlier quoted context omitted.
I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is something like noway pizde and so on. Then dont share your links publicly.
How does Let's Encrypt "hide" anything? Quite the contrary—the list of certs granted is publicly available (as it is for all CAs, I believe).
As good a time as any to be reminded.. if you have to run any kind of PHP app, always keep it in its own VM and preferably with no access to anything except its own databases, and ideally with minimal outbound Internet access. PHP security has improved markedly over time (especially app security, not just the runtime), but it's still.. well.. stuff like this. This time around I'm lucky that the sole app I run was usi…
You sound like PHP is somehow particularly bad in this regard. While this issue is nothing to be proud of, same kind of issues (and other RCE-causing issues too) are regularly found in many major products and libraries. There's no reason to specifically shame PHP for something that happens everywhere. Good defense is depth practices are always good idea, but no need to motivate it by casting PHP as some kind of parti…
Earlier quoted context omitted.
You sound like PHP is somehow particularly bad in this regard. While this issue is nothing to be proud of, same kind of issues (and other RCE-causing issues too) are regularly found in many major products and libraries. There's no reason to specifically shame PHP for something that happens everywhere. Good defense is depth practices are always good idea, but no need to motivate it by casting PHP as some kind of parti…
App security is still not on a par with other language ecosystems.. I don't think for example I've heard of a Python based SQL injection in many years. Stuff like that seems to still crop up regularly in PHP land
> I don't think for example I've heard of a Python based SQL injection in many years. Stuff like that seems to still crop up regularly in PHP land
This is an extremely subjective statement based on your personal experience of what you heard and didn't. As such, it's not verifiable and not useful. What is useful is to know that, obviously, PHP, as well as Python, has SQL implementations that eliminate injections for decades. And as in Python, there could be people that ignore it and stuff query params directly into strings. This has nothing to do with anything but these people being ignorant. There are of course tons of web apps in PHP, much more than in Python, so among them inevitably would be crappy ones. If you run one of them, do take precautionary measures.
Earlier quoted context omitted.
It probably comes down to the environment for other work. If the company will "pay the price" then that's okay, but if you will "pay the price" i.e. if a need to nuke everything from orbit and rebuild from backup will simply result in a lot of unpaid overtime for you, that sucks, but in that case you might prefer to do less unpaid work in your off time today instead of more unpaid work in your off time throughout the…
Well sure, if restoring from backups means you will be working unpaid overtime then it'd be worth working less overtime to stave off more, but in practice restoring from backups is a time-consuming process for computers, not for people. Realistically though, enjoying your Sunday and digging into work issues on Monday is probably not going to be a big deal.
My job used to include writing PHP webpages that were exposed to the internet, and looking after the webservers they were running on. I'm, not responsible for any public-facing webservers any more. My life is much better. [Edit: I reckon using a well-designed functional language might reduce the risk - like, PHP was never designed at all, it grew by accretion]
If anyone is following standard "recommended" practice, like in Nextcloud case, they get burned. This is true for all languages and frameworks. If you dont practice defense-in-depth, you get rekt eventually. I just checked my installation, its safe, since I didnt follow their "recommended" settings at all. Since its a PHP app, what I do is put an extra nginx proxy infront of it, so there is nginx 1 (this one runs in…
Only if you looked up their instructions for nginx did you get burned.