Today I was told “PHP is not secure on Windows” and “if you ran PHP on a windows server your server would get hacked“. To add insult to injury, it was then implied that running PHP on your server would steal resources on your server that would otherwise be available to your ASP or ASP.net applications and that if you wanted to operate a serious website you would never run PHP on a windows server.
This article will hopefully provide you details on how to better configure your IIS6 shared hosting servers so that your server isn’t as vulnerable to being attacked and can run not only PHP but also ASP, ASP.net, PERL and any other scripting language you want while remaining secure, stable and fast! At Applied Innovations we’ve supported ASP & PERL on windows since our inception in 1998, PHP on windows since 1999 and ASP.net since the early pre 1.0 betas. We’ve watched these technologies all mature and develop and we’re proud to say that not only can you run these all on a windows based server but you can do it while remaining secure, stable and offering best in class reliability when run on Windows 2003 and IIS6.
The biggest problem with IIS6 and that everyone believes the Microsoft marketing (afterall, if Microsoft says it, it must be true) that “IIS6 is secure out of the box”. They then proceed to create their websites all sharing a single application pool and all running as “Network Service” the default identity for the default application pool. This IIS6 configuration may be secure for a single site on a single server out of the box and is without question more secure than it’s predecessors. However, for shared hosting where hundreds of websites share (read compete for) a single physical machine’s resources, then this base configuration needs a little work. Fortunately, Microsoft is committed to seeing it’s hosting partners excel in the hosting marketplace and provides us with the information on just how to do this.
Creating a secure shared hosting environment in IIS6
1. Application Isolation on Windows 2003 & IIS6. IIS6 allows for you to run each site in a separate application pool. By running each site in a unique application pool you’re able to isolate one site’s executing code from another. The advantage here is if each site is in a unique pool and something happens on one site that causes that pool to fail, only that pool is affected and meanwhile the rest of the sites on the server continue to run as if nothing every happened. An outstanding paper by Microsoft is available on this topic here: Configuring Application Isolation using Windows Server 2003 and IIS 6.0. This paper also explains how to take advantage of the new reliability and resource control features built into IIS6, such as rapid fail protection, memory limitations, automatic application shutdown and recycling, etc. You should read this paper before continuing. Did you finish reading it? Good now go back and read it again. There’s alot of information there.
2. User Permission Isolation to Secure Applications. The second step to securing IIS is to not use the default application pool identity “Network Service” and instead create a unique user for each application pool. You’ll find that it’s still very common for most hosts to run IIS using the “Network Services” account. In fact still today almost every ASP.net developer when requesting you to adjust file permissions ask you to grant permissions to ASPNET (the user ASP.net runs under in Windows 2000 by default) or “network service” the Windows 2003 default user. The correct instructions should be “grant permissions to the user your Application Pool executes as”. The secure way to isolate your applications/sites is to create a unique user for each application pool and execute the pool as that user. This user will ONLY be used for executing this application pool and will not be used for anything else. You would then grant that user access controls (or ACLs) to only the files, directories and resources on the server that are absolutely required access by this user. The easiest way to do this is to assign the users as members of the IIS_WPG group and grant or deny permissions to the IIS_WPG group on the server resource. By tightening ACLs should one of your application pools be compromised and a hacker use it to attack the file system on your server they would be sandboxed and only allowed access to those areas on the server that the user of that application pool runs as or has access to. The key is is limiting the area exposed to being compromised. Additionally, by running each website as a unique user and only granting access to the website files for that particular website then should that one pool be compromised they would not be able to access the files of the other websites on that server. NOTE: you should never grant IIS_WPG access to a website’s wwwroot and instead grant it on a per user basis. Details on how to properly configure ACLs and what steps need to be taken can be found here: Using Isolation to Secure Applications (IIS 6.0).
If you followed the two steps above you’ll have isolated every website into their own application pool and you’ll have each site running as a unique user that only has access to it’s own files and minimum system resources, effectively sandboxing every website. You now have your server configured so that no one website can access the files or resources of any other website on your server. Should any one website become hacked and a hacker execute code, that code would not be able to affect any other site on the server and not be able to further compromise your server. This is a secure, sandboxed, hosting environment and anything less than this is not secure for shared hosting. Once you have a secure hosting environment you can then safely allow ASP, ASP.net, PHP, Perl or any other scripting engine you want (Provided you properly configure it). The key is that you’ll want these applications to run within the isolated application pool as the isolated application user for that site so that they remain sandboxed.
Unfortunately doing all of this will not make you invulnerable to getting hacked but will help to reduce the number of attack vectors that could result in your hosted websites getting hacked. Additionally, should a site get hacked you have now limited the impact on your server, regardless of what scripting language your web applications run under.
You’re also probably wondering what this has to do with running PHP under Windows securely? You see, it’s not the PHP programming language that gives PHP a bad name, it’s not Microsoft trying to slander PHP either, it’s the web developers that use PHP to write insecure web applications that are then executed on insecure web servers. It’s these insecure scripts on insecure servers that make people say PHP is not secure on Windows. If a website running a PHP application is hacked and the user that this site runs as has full access to all the other sites on that server, then you don’t have one compromised website but dozens of compromised websites!! This also isn’t a Windows only issue. These hackers know that web developers are lazy and like to grant world writeable to all folders and all files instead of specific pages or subfolders (Linux guys take note: CHMOD 777 -R is not a good thing!). Thus, I wrote this article because it’s widely assumed that PHP is not secure on windows hosting, when the truth is nothing is secure on windows hosting (even ASP and ASP.net) unless the hosting is secured first.
So is it the system administrator, the webmaster, the application developer, the language developers, the OS developers or the hacker squirreled away in the basement in his mommy’s house that’s at fault?
It’s everyone’s fault!
- the system administrator needs to secure his server and audit it regularly, keeping the scripting languages, OS, etc all patched and up to date.
- the webmaster needs to use secure passwords, maintain secure file permissions, keep his scripts and applications up to date.
- the application developer needs to keep his scripts secure and not vulnerable to common issues like SQL injection and cross site scripting attacks.
- the language developers need to always stay ahead of hackers, paying attention to hacking trends and not only fixing bugs and security holes but finding them and trying to compromise their own platforms before the hackers do.
- the hacker, well not much we can do with him but if we all do our part then these guys aren’t going to have sites to hack and eventually they’ll leave that basement and go find something useful to do with their time. World peace could be a start!
I’d love to hear what other’s have to say and welcome any and all feedback. My next article will address just why a windows web server running PHP and ASP.net is not just for hobbyists and can be done in a production web environment reliably, securely and still remain extremely stable. In the meantime if you’re looking for proof of this concept and want a stable, reliable windows hosting platform that allows you to run PHP4, PHP5, PERL, ASP, ASP.net 1.1 and ASP.net 2.0 , please visit Applied Innovations at www.appliedi.net .
A common mistake among PHP users of open source PHP applications is storing PHP session information within publically browsable folders. It's an easy hack for anyone familiar with the common applications (Oscommerce, PHPnuke, PHPbb, etc) to look for these folders within web reachable folders. Store sessions in database tables or folders outside of any normal root or publically accessible content.