Web application security is something that requires the collaboration between coders, designers, system admins, hosting providers, webmasters and businesses/organisations decision makers.
If security is not carefully planned at every level we could end up with a very secure operating system and network but a vulnerable app, or we could be running a super secure web app on a system with a vulnerable FTP server that we are not aware of and compromise the whole system. In the same way we could build a secure system and then start adding new features and components without following documented design guidelines and create new vulnerabilities as the project evolves.
A web application will always be “vulnerable”, because of its own nature. The question is: how do we manage this risk? Three complementary strategies should be implemented in parallel to ensure that we not only mitigate risk, but also prevent foreseeable problems and provide a clear disaster recovery strategy to minimise down-time.In the normal operation of a web service there are many things that could go wrong, but the unwanted results are always the same: exposing or loosing confidential data and service disruption.
Like in any risk management effort, we face a problem for which there is no perfect solution. We need to start from the principle that web applications can not be 100% bullet proof. The job of securing a system is a matter of creating barriers and preventing avoidable problems, but never totally eradicating the possibility of something going unexpectedly wrong. At this point we need to ask ourselves “How important is the data we need to protect” and “How much downtime can we afford”. The amount of effort we make in securing our system will depend on this two fundamental questions.
In the context of a web application, security concerns will normally originate from two sources, either an intentional attack on your app or server, or a human error made by a programmer, a system admin or even a power user in the wider system.
Security threats:
- Malicious Attacks
- Human Error
Before we start thinking about solutions we need also to understand the different levels at which security needs to implemented. I have tried to make a quick list, but this list is by no means a comprehensive analysis.
Different layers involved in web application security:
- Premises / Physical Location
- Network
- Operating System
- Other services (FTP, SSH, Telnet, …)
- Web Server
- Apache configuration
- Filesystem permissions
- Security Certificate (SSL Encryption)
- Web Application (PHP/MySQL)
- PHP Configuration
- Input Filtering / Escaping output
- Spoofed Forms
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgeries (XSRF)
- Database Security
- Session Security
- Filesystem Security
- Remote Code Injection
- Command Injection
This list pays special attention to the app itself (and the language its written in – PHP) as this is my field of expertise. The first two items in the list (premises and network) are the hosting providers responsibility. At this level you normally look at the possibility of fire or theft, redundant servers, clustering and both on-site and off-site backups. The operating system is also the host’s responsibility, but only to a certain extent. The system administrators (that being users with admin rights on the system) are ultimately responsible for the operating system, the packages that are installed on the system and the network servers that will run on the system (FTP, SSH, HTTP, …).
We will look at the web server separately because this is the core infrastructure component in a web application. The web server is the point at which the web application interacts with the OS. In fact, the application on the server is “run as” the web server’s user, and all data coming into and leaving the system is exchanged with the web server. At this level you would want to look at hardening the Apache server and using a server certificate to encrypt communication in and out of the server. A security certificate guarantees the identity of the server and provides user confidence as well as encrypting the packages being transferred over the internet, but it does not make a server “secure”, but rather offers an improved level of security. This is a strongly recommended measure and an industry standard 256bit security certificate can be purchased for around £100/year (on a per sub-domain basis).
The web application layer is where we look at PHP issues as well as application design and coding practice. This is where the development of phpFrame and Extranet Office is responsible for the secure and reliable running of the app. This involves addressing common web application exploits (XSS, XSRF, …) and enforcing design and coding practices that guarantee the filtering of input and escaping of output, as well as the correct operation of the application, with special attention to the correct handling of user’s access rights.
Security measures at large can be summarised as:
- Appropriate backup/restore routines
- Local backups (on disk and an on tape)
- Mirrors/Clusters
- Off-site backups
- Disaster recovery plan
- Regular testing
- Documentation of the system
- Attack prevention
- Coding practices
- Server configuration (SSL, SSH, HTTP, …)
- Testing
- Penetration tests
- Monitoring
Tags: PHP, Security, Web Application Security
