Securing Web Application

Securing web application is a not an easy task. But it must be done. Here are some pointers to get you in the right direction:

This brings us to a thorny and topical issue: administrator privileges.

It has long been assumed that developers should have very broad administrator privileges, because they need to be able to attach their debuggers to running processes, install and uninstall applications, install various tools and libraries, and so on.

But – having viewed this from both the developer side and the view of a vendor who has come across some horror stories in the marketplace – I reckon that developers need to consider their often unrestricted administrator privileges as a double-edged sword that they might want to revise.

The admin meltdown syndrome

Not only do admin privileges open up vulnerabilities on the developer’s workstation (over 70% of known vulnerabilities in Windows 7 require admin privilege to be exploited) but they can also introduce additional problems for security down the road.

An example scenario is a piece of software that needs to write or modify files in a privileged folder, for example Program Files on a Windows system or /etc on a *nix box.

This software would run without issue on the developer’s system, probably pass all its tests and be passed onto the operational team for deployment. The application has carried with it the need for admin privilege, the developer has most likely moved onto other projects and so the operational team is left with the need to modify the user privilege to enable it to run.

This is undoubtedly going to involve weakening the system security, either by adding admin privilege to the user, or by lowering the file system security. Both of these actions introduce vulnerability into the system.

The privileged API route

Another scenario would involve the use of a privileged API call that similarly works for the developer but requires additional privilege for every user of the software. Compilers produce errors and warnings when code isn’t correct or following best practices; if we could have a way of doing the same for the examples described then we can prevent these vulnerabilities from being introduced.

Nor is giving developers ‘standard privileges’ in line with other users in anyone’s best interests: sure, the code would then be unable to write to the privileged folder or call the privileged API, but debugging and installing would also be hampered.

The solution is the principle of ‘least privilege’, in other words the granting of only the privileges essential to the user’s work.

For developers, this means granting specific rights such as “Debug Programs” and the ability to install specified applications, tools or libraries. The developer is then able to write his or her software in a context that is close – if not identical – to that of the target user.

This leads to fewer vulnerabilities being introduced and a safe operating environment for the developer.

The principle of ‘least privilege’

Of course, where there is a legitimate need, for example for privileged API calls, then least privilege processes and tools can identify the specific admin privileges necessary, enabling the developer to provide an appropriate policy or rule to the operations team along with the application. This ensures that the principle of ‘least privilege’ is followed through to deployment and without the developer needing to become a security expert.

Of course, there are other security measures that developers could get themselves involved in, but better management of privileges goes a long way towards preventing all kinds of vulnerabilities further down the line.

Starting security from a position of privilege and attempting to manage that down means that control breaks down maximum privilege levels are exposed, whereas, least-privilege always defaults to the safest and most secure scenario of the standard user.

I can summarise it by saying that admin rights shouldn’t be inherently implicit and instead, they should be explicit (in other words, only applied where needed), something that applies not just to developers, but the whole organisation. Small steps, but ones in the right direction.

Source: Computer Weekly

A great table listing potential problems during design:

The design guidelines in this chapter are organized by application vulnerability category. Experience shows that poor design in these areas, in particular, leads to security vulnerabilities. Table 4.1 lists the vulnerability categories, and for each one highlights the potential problems that can occur due to bad design.

Table 4.1   Web Application Vulnerabilities and Potential Problem Due to Bad Design

Vulnerability Category Potential Problem Due to Bad Design
Input Validation Attacks performed by embedding malicious strings in query strings, form fields, cookies, and HTTP headers. These include command execution, cross-site scripting (XSS), SQL injection, and buffer overflow attacks.
Authentication Identity spoofing, password cracking, elevation of privileges, and unauthorized access.
Authorization Access to confidential or restricted data, tampering, and execution of unauthorized operations.
Configuration Management Unauthorized access to administration interfaces, ability to update configuration data, and unauthorized access to user accounts and account profiles.
Sensitive Data Confidential information disclosure and data tampering.
Session Management Capture of session identifiers resulting in session hijacking and identity spoofing.
Cryptography Access to confidential data or account credentials, or both.
Parameter Manipulation Path traversal attacks, command execution, and bypass of access control mechanisms among others, leading to information disclosure, elevation of privileges, and denial of service.
Exception Management Denial of service and disclosure of sensitive system level details.
Auditing and Logging Failure to spot the signs of intrusion, inability to prove a user’s actions, and difficulties in problem diagnosis.

Source: MSDN

The topic of securing web application is huge and this article only covered some of it. We will talk more about securing application in the next few weeks.