Let's Talk Security Part I : Application Security Primer

by Jason Dean

This article is updated from the version published in Fusion Authority Quarterly Update Volume 3 Issue 2. This is the start of a series on security. The first three articles are by Jason Dean, but others will contribute.

Application security, like documentation, is a thankless and unglamorous part of the software development. No one seems to care when you get the security of an application right. But when you screw it up, rest assured, suddenly everyone will want to know what happened.

Unfortunately, we do not typically work in an environment that fosters the design and development of secure systems. In this time of Rapid Application Development (RAD), security can seem a secondary concern, or an afterthought. It is even quite likely that most of us have not had any formal application security training. In a review of six web application development and computer science programs, I found one application security course. I know my undergraduate program did not include any. In fact, I was over a year into my web development career before I even gave a thought to application security and realized that I was making some very simple mistakes.

Many of us may struggle with getting others to take application security seriously, or perhaps we do not take it seriously ourselves. Until we get hacked, do we think it cannot happen to us? Well, I am here to tell you that it can, and will. It is simply a matter of time. You have no reason to believe that your application will never encounter an automated attack script like the one that many ColdFusion developers faced in the summer of 2008.

Application security is hard. Really hard. I don't say this to scare you, or deter you from learning. I say it to prepare you. This subject cannot be covered in a single article. It will consume much of your time, time that you would rather spend learning cool new Rich Internet Application (RIA) technologies or application frameworks. But you must take this time to ensure that the applications you create mitigate as many risks as possible. Hackers are becoming more clever by the minute, and the tools they use, more sophisticated.

What is Application Security?

An application security novice might ask how to know if an application is secure. The answer is, that if you need to ask, then it is not. Application security does not just happen. It is not built into any language, nor is it an optional component. Securing your application is a deliberate process that requires time, effort and an understanding of the problems to be solved.

Application security includes the measures we take to prevent attacks against our applications and their underlying systems, and to mitigate threats against them by limiting vulnerabilities through technological countermeasures that enforce our security policies.

That's a mouthful, but essentially, application security deals with attacks, threats, vulnerabilities and countermeasures. Vulnerabilities threaten our applications with a potential attack. For example, poor user input validation threatens our application because it opens it up to an attack. We, as developers, or network administrators, or security professionals, mitigate this risk through countermeasures, steps we take to reduce or eliminate the prevalence of threats and the effectiveness of attacks.

Vulnerabilities, Threats and Attacks

I couldn't possibly cover every existing threat to our applications in this article. So I will briefly discuss some of the common vulnerabilities that you, as developers, will face. I will also explain which attacks these vulnerabilities make possible.

Insufficient input validation

Input validation is perhaps the most tedious part of application development. I know it is one of my least favorite parts. However, it is one of the most important in the scope of security concerns. Without sufficient input validation, we open our application to several attacks, including SQL injection, cross-site scripting(XSS), path traversal, and defacement. We also run the risk of disclosing too much information through error messages resulting from invalid input.

We must validate user input to ensure that it conforms with the values that we expect. An inappropriate type, length, or value range can cause information leakage, data compromise through theft, destruction, or unauthorized changes, or unexpected effects to the application.

Poor error handling

Since input validation cannot prevent all errors, it is important to properly handle system errors to prevent information disclosure through the text of error messages. ColdFusion, in particular, excels at providing developers with extremely robust and helpful error messages. Unfortunately, those error messages also help hackers. They allow them to better understand how the application works, to discover specific details of database and system architecture, or even to learn the location of specific files. In a production system, the displayed error messages should reveal nothing more than what the user needs in order to continue using the application.

Weak authentication and poor password management

Technological limitations can prevent web developers from implementing more than one-factor authentication. Highly secure applications typically have two-factor authentication, and some can have three. The factors of authentication typically mean:

• Something you know (a password or PIN).
• Something you have (a smart card, or security token).
• Something you are (a biometric identifier, finger print, retinal scan).

In the world of web applications, we typically only have access to the "something you know" factor of authentication, because of the logistical and technical difficulties in dealing with the other factors. Therefore, we must get this factor right. We need to ensure that password creation, management and storage are handled properly and we must take care when we use and transmit authentication credentials.

Poorly implemented authorization and access control

Authentication verifies the identity of a user. Authorization and access control verify and control what a user has permission to do. Sometimes people confuse these concepts, perhaps because they all start with the letter 'A', but they are distinct concepts.

As an example, take a fictitious content management system (CMS). When I log in, I authenticate as the user 'jdean'. Do I now have on-demand access to everything in the system? Of course not. At least, I should not. I would typically only have authorization to access certain features and functions. If the authorization functionality checks to see whether I am authorized, and I am not, it will return "false", and the access controller will deny me access and reroute me to an appropriate page. If any piece of this process contains vulnerabilities that allow unauthorized access to a resource, then a privilege escalation attack becomes possible. A privilege escalation occurs when one user can change his or her identity or role to another user's and gain access that would otherwise be restricted.

Improper or insufficient encryption

Cryptography is a complicated and confusing subject that could fill a library. If your application requires cryptography, it probably will require several different kinds of it, in multiple places. We need to know when and where to use cryptographic solutions and how to implement them. We also need to know when to call in an expert.

Two general categories of data may require data encryption — data in transit and data at rest. Multiple ways exist to secure each of them, but there is no one way to secure both. So at a minimum, you will need two cryptographic solutions.

Data at rest needs different strategies for handling different types of data. Passwords in the database will have different encryption than credit card data.

Encrypting data in a cookie differs from encrypting data in the file system. To top it off, you need key and certificate management. Improper or insufficient encryption can expose your application to packet-sniffing and to the potential disclosure of sensitive data.

Session Management Flaws

Session management flaws come in many shapes and sizes, from cookie misuse, to failure to use an SSL/TLS connection, to weak authentication, to improper handling of session tokens, and more. Session management can have many vulnerabilities, hence, there are many ways to attack it.

Due to the stateless nature of the HTTP protocol, session persistence information (a session token) must pass from request to request so the server knows with which client it is communicating. Passing persistence information in every request runs the risk of someone sniffing for it. If the session token becomes compromised, then a hacker could impersonate the user to whom that session belongs, an attack called session hijacking.

Predictable session identifiers, the default behavior of ColdFusion session management, make an application vulnerable, although this can be changed. Sessions that stay valid for too long, and unencrypted transmissions sending the token between the client and server are also common session management vulnerabilities.

ColdFusion makes session management easy to implement. In fact, it almost happens automatically. Unfortunately, this can make us forget to consider whether or not our sessions are secure. Session management, in any language, must be made secure through creating strong session IDs, using encrypted transmissions(TLS/SSL), setting reasonable session time limits, rotating session IDs, and ensuring session tokens are passed securely.

Auditing, logging and tracking user activity

Big Brotherish as it may sound, applications should log what users do with them. Many developers think of application logs as a debugging resource only. In fact, those logs can give us vital information about the security of our application. User activity logs can tell us what our users do with our applications. We can see if they try brute force login using usernames not assigned to them, or if they try to access areas they should not, or if they try to inject code to exploit a vulnerability.

Application logs can help track down vulnerabilities, identify IPs to block, and even provide law enforcement with evidence of a crime.

Countermeasures

What can we do about the security issues we face as application developers? How do we fix all of these problems?

We do not necessarily need to fix ALL of these problems. A lot depends on the security policy of our application, which tells us what security means for that application.

Let's think for a moment about a real-world example. Like many of you, I live in a house. Four people and two animals live in my house, all of whom I would like to keep safe. So I need to mitigate the risk of attack through countermeasures. First, I need to determine the vulnerabilities of the house.

Vulnerabilities

• The doors and windows open.
• The garage door opens.
• The house is not monitored at all times, so someone could sneak in while we are away.
• The house is flammable.
• The dog is stupid.
• There is only one way down from the upper level.

I have probably overlooked some vulnerabilities, but these make a good start. They pose a threat to my family, exposing us to risk, anything from an accidental fire to a home invader. The security policy of my home addresses these vulnerabilities and I need countermeasures to mitigate the risk.

Countermeasures

• Put deadbolt locks on the door.
• Place a stick in the patio door to prevent it from opening.
• Put locks on the windows.
• Install a garage door lock.
• Install a security system that we can armed at night and when we leave.
• Get the upgrade to the alarm system that includes smoke and fire detection.
• Use a security company that monitors the house 24/7 for security and fire alarms.
• Train the dog to bark at home invaders or the smell of smoke.
• Install rope ladders at some of the windows on the upper level for emergencies.

These seem to me reasonable countermeasures that allow me to call my home secure. By implementing them, I can enforce my home security policy and declare my family safe.

But did I really solve every problem as well as I could have solved it? Is every vulnerability fully addressed? Could I have done more? If we think that every vulnerability needs the highest level of security possible, then I need to implement some additional countermeasures.

High Security Countermeasures

• Place armed guards at each entrance, each of whom has filled out an SF-86 background check questionnaire and has at least a secret Security clearance.
• Install access control at each entrance with fingerprint scanners, voice recognition, proximity card sensors and a PIN number entry console. No one gains entry without three-factor authentication.
• Install windows which do not open made with bulletproof glass rated to stop a .50 caliber armor-piercing round.
• Replace drywall and insulation in the house with flame-retardant foam and metal firewalls.
• Replace stupid dog with three highly-trained guard dogs.
• Add escape hatches to each of the upper-level rooms.

Obviously, these countermeasures are silly suggestions beyond the resources of my family budget and would likely inconvenience my family far beyond the worth of the additional safety they provide. I'm not saying that I do not think my family worth protecting, nor that some or all of these countermeasures would be silly in other situations, like on a military base. I am simply illustrating the point that not all situations require the most robust security possible. The same applies to our applications. If you do not implement every security feature possible, do not fear that you cannot call your application 'secure'.

Your application security policy determines how far you need to go. This means that the security policy must be part of the development process of your application from the very beginning and that it must be discussed and decided upon by all of the stakeholders and decision-makers involved in the application development process.

Conclusion

You may have noticed that many threats intersect. Solid session management requires understanding access control, encryption, and authentication. Properly implementing access control and authentication requires sufficient input validation and encryption. And logging and proper error handling get mixed into just about every aspect of application security. This means that to properly implement some countermeasures, we must understand different aspects of application security, countermeasure creation and vulnerability discovery.

I realize that this article may have raised more questions than it answered. As I said earlier, security is hard, and it cannot be addressed in a single article. I encourage you to look at the links in the resources section of this article and to do some research on your own. You can also contact me with questions at my blog, http://www.12robots.com. Finally, keep an eye out for future articles in Fusion Authority on security-related topics. Application security is finally starting to get some of the recognition and attention it deserves, and I have no doubt you will see more articles on the subject.

Resources

Wikipedia Article: Application Security

Open Web Application Security Project Development Guide

Adobe Developer Connection Security Articles

Web Application Security Consortium

Jason Dean is a Web Application Developer at Dakota County Technical College in Rosemont, MN. Jason blogs at http://12robots.com, is on the cf.Objective() steering committee and can often be found on StackOverflow, Twitter (@JasonPDean) and at ColdFusion conferneces. Jason lives in Farmington, MN with his wife and two children (almost three).

• Subscribe
• RSS

• Editorial
• Specials
• Community
• News
• Tech and Tags
• Views
• Reviews
• Techniques
• Security
• Best of ColdFusion Talk
• Knowledge Base
• Blog Watch

• Tipical Charlie