We read about successful website hack attacks almost on a daily basis. Security companies claim that not enough is being done and more awareness is needed. Our article covering major security breaches in well—known companies, clearly shows that there are many gaps in web security, that are causing multi-million dollar damages to companies word-wide. A few years back web application security was a concept only security professionals thought of and understood, nowadays developers are being trained with the help of experienced programmers and 3rd party applications, to write more secure code.
Below are four principles that every web developer should follow throughout the software development lifecycle (SDLC) to help make the written code secure as possible, therefore creating secure web applications.
Principle 1: Apply Defense-in-depth
“Defense-in-depth”, also known as ‘Castle Approach’, can be described as multiple defense mechanisms. The web application is the front-end of a systems and network infrastructure, consisting of internal data, user information, systems, and networks. No single security check point is enough to protect all the different components that make up a web application. This is why multiple defenses are necessary: if one defense fails, the others will keep protecting the software and sensitive data.
For instance consider restricting access to an administrative interface to a specific IP if possible. This means attackers cannot gain access to the administrator panel, even if they know the credentials, thanks to the static IP restriction.
Principle 2: Use Whitelisting Approach
Whitelisting is a configuration that accepts defined inputs and leaves out the rest, or if you prefer: Everything that's not explicitly permitted is forbidden.This is a huge advantage when compared to blacklisting approach, where you leave everything open and block only known attacks.
Principle 3: Do Not Trust User Input
Web applications are used by end users, but they also can be targeted by the attackers. It is crucial, then, to never trust user input directly and to check data before it’s moved from an untrusted source, such as a parameter or a domain to another. And this does not just apply to development. You should always be careful what to click or access since attackers can fool even those who are well trained, as it happened when attackers gained access to the Apache Foundation servers by exploiting a cross-site scripting vulnerability.
Principle 4: Run with Least Privilege
The least-privilege principle “wherein you provide only the minimum rights, such as setting up minimum necessary access to files on the system or database”. Running with least privilege will help you avoid the nasty possibility of unauthorised users damaging your system by obtaining access to information in ways they were not intended to.
For instance, it would be unnecessary, and especially risky, to grant full privileges to a user on a database when it just needs to run a SELECT query.
How to Apply These Principles
There are a number of approaches you can use to apply these security principles. Let’s look over them, one by one.
1) Input filtering / validation:
According to the “do not trust user input” principle, no user input can be trusted, and it should be filtered before any processing is done.
2) Filter/Encode/Reject on the server side, not the client:
It’s possible to filter user input on both the client-side and the server-side. However, attackers can bypass filtering on the client-side. So, all filtering, encoding, and reject rules should be configured on the server-side.
3) Use Whitelists, not Blacklists:
The “use a positive security model” principle requires rejecting all input that’s not predefined while checking all user input. Blacklisting means that if an input matches any data previously added to the blacklist the process will be stopped, and no further action will be taken. However, the mistakes made during the preparation of the blacklist, such as missed variations, unknown attack strings and different blacklist bypassing techniques, can dramatically increase the possibility of a security breach.
Conversely, whitelisting provides more secure filtering. As in this case, all acceptable input is on the whitelist, while all other input will be rejected. For instance, if you require information on which US state users’ live in, you can list all the state codes on one line by whitelisting them and show this information via a drop-down list.
Now users won’t be able to input any data that is not predefined or listed on the whitelist.
4) Prepared statements (parameterized queries):
Use prepared statements for executing SQL queries, period!
5) Most Important Principle: It is Never Enough
We left this principle for last; you never know enough. That’s right, we never know enough. Web application security, like any other IT security related subject is evolving on a daily basis. Keep yourself informed by reading and following industry leading web application security blogs.