5 ms·

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 usabl

• 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.
    • feld 12y ago
      Once they have a shell they're free to do what they want. Local root exploits, etc are all fair game -- and there are plenty of 0-days out there. In fact, removing the compiler doesn't help; a lot of attackers and bots run a script to detect the system environment and auto-download what they need to move on. Remember: jails can still be broken out of, and there is some really neat work in the research space of attacking hypervisors... There are numerous things you could remove from an OS install to make their lives a bit harder (dtrace, systemtap anyone? you can sniff passwords easily...), but once they have a shell and a directory with write access it's game over. You're better off leaving the tools there but having your auditing throw a serious fit when a compiler, etc is executed unexpectedly on a production box. So yes, I think it's bunk to claim that removing a compiler will provide meaningful security benefit. In fact, I believe this has been suggested a few times to FreeBSD by users (don't install compilers, etc by default!) and was dismissed as ineffective for the same reasons. Work harder to prevent the bad guys from getting that far. Keep your systems well patched. Have a thorough auditing and monitoring system in place. Use containerization and segregation everywhere possible. Limit scope of access. Some points you made apply here as well. Maybe once you've mastered all of those arts you can play with the obscurity angle. edit: and L7 firewalls... I'm on the fence there. There has been some movement in that area by security researchers equating them to antivirus... they're only as good as their definitions, and a targeted attack will bypass it. They also seem to give a false sense of security and let people be lazy. Security in layers is important, though. edit2: don't get me wrong, you should be hardening your production boxes (and dev... so the environments match...) but removing a compiler is not high on my list
• spacemanmatt 12y ago
  Would you say that there is 'limited proof' that C is inherently more dangerous than Java? I would estimate PHP is inherently more dangerous than C.
  • ukigumo 12y ago
    I would say it is easier to shoot yourself in the foot with C than with Java or other managed runtimes. PHP code can be as secure as anything else, in my experience, but the end state solution has to take into account the possible risks and mitigate them accordingly. Putting it in another way, would you say it's more dangerous to have a DB and java appserver running on the same "server" or having a PHP application in one box in one network segment and a DB server in another box, different network segment and with different privileged credentials?
  • sanswork 12y ago
    Why would you say that? What does C offer as a language that makes it more secure in your mind than php?
    • tveita 12y ago
      There are no systems to my knowledge where the server will compile and execute a .c file from a directory when accessed. Yet that seems to be the default configuration for many PHP installations unless you specifically guard against it it. A common PHP vulnerability is just the user uploading a php file and then accessing it.
      • ukigumo 12y ago
        This is what I mean with knowing what risks your application / framework / language will bring and mitigating them accordingly. (edited for clarity)
      • sanswork 12y ago
        So you're saying the issue isn't with the php it is with all interpreted languages? Then compile your php before upload. >A common PHP vulnerability is just the user uploading a php file and then accessing it. A common PHP vulnerability is allowing uploads to a folder where code is allowed to be executed. That isn't a fault with the language but with lazy developers and admins.