No Batteries Required - Home
Web Application Security
Ray Kahn
MAR 05, 2013 07:35 AM
A+ A A-

Essentially security is about control. And control more than anything else is a process which involves people, procedures and technology. The fundamental goals of system security are to detect, recover and prevent future occurrences of a violation and there are many ways that this can be achieved. Most, if not all, involve firewalls, DMZ, IDS, IPS, DoS prevention with each having its own event management and configuration. But these control decisions are peripheral to an application and constitute additional layers built on top of one another. Of course I am not suggesting that layered defense (defense in depth) is wrong, but rather it does not address the root causes of an application’s vulnerabilities.

Web application security is a means of controlling a user’s activity in the context of business logic. What I mean is that generally an application is expected to deliver a set of information (data) to a user (request) based on applicable business rules/logic. Failure to behave as expected constitutes a control breach, after all the application failed to operate within the constraints of the controls. But why don’t security principles work all the time?

Web applications are the result of efforts by people. A software development effort, we must assume, goes through a SDLC process and gets used by its target audience. Over the years however software designs have been influenced by the need for feature rich, cheaper systems demanded by market forces. But these requirements are contradictory: on the one hand software is required to have many features and on the other it must be deployed quickly and cheaply. Somewhere during the development process people start making compromises that inevitably lead to software vulnerabilities.

Vulnerability is defined by OWASP (the Open Web Application Security Project) as “a hole or a weakness in the application, which can be a design flaw or an implementation bug that allows an attacker to cause harm to the stakeholders of an application”. Based on this definition it isn’t hard to draw a few conclusions.

We Are All Responsible

Security doesn’t happen by itself. It is a result of soundly designed and executed control processes with adequate governance and accountability. Organizations do better when security is a top-down priority: executives at the highest level understand the benefits of control procedures and demand that these measures are integrated into business and IT processes. Of course neither people nor processes will change quickly or willingly. That is why it is important to train the employees about application/system vulnerabilities and the controls to recover from and prevent them from happening or recurring. None of these efforts will yield the desired result unless there is a way to measure their effectiveness. Make security controls part of the organization’s culture and repeatedly and consistently drive the need for accountability.

Design Matters

We demand a lot from our computers which has lead to introduction of a lot of complexity into applications that run on them. Of course complexity does not mean security and in fact it violates one of OWASP security principles: Keeping It Simple.

A good application design would have security and the requirements of the security team(s) integrated in its functional specifications. It should come as no surprise that Firewalls and DMZs can’t plug every security hole an application will have. As a result close collaboration between application development and security teams during the design, development and testing phase is critical.

Complex and large web applications usually tend to be more vulnerable due to their larger input surface areas. As a result a robust and strong input validation should be implemented for every input area. And make it a positive validation: define what a valid input is and reject everything else which fails the criteria.

It is always prudent to design for human factors. In fact most security breaches are result of human mistakes. Always design with default security: users’ preference for less security ought to be a result of their action. And of course never run any of your services with root or super user privilege: that is simply bad design and implementation. In fact I have issued several warnings to my development team about this very fact: provide least amount of privilege needed for a job, nothing more and nothing less.

Common sense can help prevent security breaches. Remember it is better to be suspicious and design for worst case scenarios than rely on luck or happenstance for security.

Bugs Happen

Early in my career I recall writing a perfect and bug free piece of software. It was perfect because it never got used: my point is that all applications have flaws in them; software vulnerabilities are facts of life and to effectively investigate and remediate their root causes there need to be useful application logging. But I think most security people as well as developers would agree that standard logs, even those customized to meet the needs of development teams, are hardly adequate. That is why it is important for development and information/system security teams to work closely so that security relevant data are also included in application logs. Better still, working with security teams developers can learn how to use security control APIs in case of an abnormal behavior by the application. Remember threat decisions are better handled by applications rather than firewalls or routers with no context of the threat. The point I am trying to make is that security controls need to be part of SDLC. Security needs to be enterprise wide, ought to be cultural and emphasized at every level of SDLC.


Information security is hard to do. As IT professionals we are all familiar with many different technologies that are meant to prevent security breaches. But security mechanisms still fail. Just recently a very well know engineering organization had their member information exposed on line. Although it turned out that the breach was a result of human factor, nonetheless it highlights the nature of the problem.

IT development teams can no longer operate without IT security teams. Moving forward it is essential to design and develop web applications with close collaboration between the two teams. Such team work can remove technological weaknesses that lead to information security failures and can prevent penetration of your IT systems by malicious programs or people. It is important to remember that information security is a shared responsibility. 

[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment: