How to Design Secure Web Applications 

SySmox

Coldfusion security

Secure web application design is not product-specific: it is helpful in securely designing and implementing any Web application, regardless of the platform. but many of these concepts are relevant to any application development cycle, including non-Web applications.

secure application security

What is the ‘Security Mindset’?

•     Risk Assessment
•     Policies
•     Platform Research, Modular Architecture and Delegation (Layering)
•     Validation (Formal Trust)
•     Vigilance

Keeping computer security issues at bay is a full-time job. These columns provide general education, point out common security issues in implementations, and can aid you in both design and troubleshooting. However, they are not a substitute for a full-time security specialist individual or group in your organization.

Bear in mind that individual links are provided for reference; they may not be applicable to your specific architecture or configuration. Be sure to carefully check whether the procedures suggested or described apply to your configuration before implementing them. Also, be sure to test any change to your current configuration or process in a testing environment prior to applying them in any production environment.

What is the ‘Security Mindset’?

The ideal security architect is very cautious, even paranoid, diligent, suspicious, obsessive-compulsive and impossibly humble. In reality, they tend to be a little more human – which can be both a good and a bad thing – but in terms of ideal qualities, this description is closer to the truth than you might prefer to think.

Generally, it’s a good idea for a security specialist to be suspicious and aggressively inquisitive about new things. She should be suspicious enough so that she’ll feel comfortable prying into how new things work, how inherently secure new tools are, and how much she can trust these new things to keep her data safe. She should also be cautious about programming, configuration, and implementation, both her own and others’. Being this way helps her keep her edge, stay alert, and helps her identify and analyze subtle and tricky situations. It’s often said that the same kinds of people who automatically case every store they enter, but never use the knowledge to steal, are perfect for the security field.

The security world demands vigilant discipline. Security, on the largest level, can easily slip through the cracks without the constant combined effort of many determined, perceptive minds paying attention to design and implementation. Passing data from one application or storage medium to another can easily threaten data safety and security. Unless architects for both applications and storage drivers pay careful attention to well-designed security protocols, no one but the perpetrator might be the wiser about data theft.

Most security vulnerabilities occur in areas of coding and design where secure design or implementation has lapsed. Sometimes the lapse comes from ill-considered design, sometimes it is the product of a rushed implementation, and sometimes it’s the product of designer or developer arrogance. Regardless of how lapses occur, these vulnerabilities are consistently the most popular – and most devastating – openings for attacks. Attention to detail, combined with intelligent and careful design, can do a great deal to improve the security of every byte. This is a vital element of the security mindset.

An additional important aspect of the ideal security architect’s mindset is humility. This trait can be in direct conflict with pride in all the knowledge and experience the ideal architect earns, but humility is her most important personality trait. Humility allows her to learn from other security-oriented experts and mentors. With humility, the security architect will seek peer review of her designs and implementations, and research secure starting points and design methodologies to round out her careful and meticulous planning.

Risk Assessment

Risk assessment should be among the first steps in your design process, and will help you frame your further efforts to design a secure system. Making risk assessment a priority will also help you make sure your executive officers are both informed about and integral to the beginnings of your securely designed project. During the risk assessment phase of design, you may find important supporters and champions among the executive officers: you should actively recruit their participation if they’re not already involved.

Business majors  already know about the managerial aspects of risk assessment. This methodology is heavily used in most business plans, especially with respect to business planning. Risk assessment is no less important in secure, well-designed software or applications development projects. Take advantage of the fact that your managers and executives are probably already familiar with risk assessment methodology. Armed with a common language and methodology, you can inform your managers of the relative risks to which the application exposes you or your customers, and you can additionally leverage their involvement and buy-in. This will help you in the end: if there should ever be an attack on your application, you will already have a champion to go to bat for the integrity of your application and the care with which it was designed.

The basic steps of risk assessment are as follows:

•     Identify protected resources
•     Assign relative value
•     Identify possible attackers
•     Estimate relative frequency of each kind of attacker
•     Carry out attack tree analysis / Identify possible attack routes
•     Protect all possible attack routes / Protect most likely attack routes

Protected resources include things like your customer database, customer credit card information, or personal information. Your risk assessment process will depend a great deal on the policies regarding the privacy, disposition and handling of customer information and other social and legal issues. Your executive managers must be involved in deciding these policies.

For each resource, assign it a relative value (i.e. your customer credit card database will probably be more valuable than your vendor contact list). Next, identify possible attackers. Frequent examples are the bored teenager, the disgruntled ex-employee, the corporate spy, or the government intelligence agent.

Estimation of the skill, frequency and methods of the attacker all belong to a related process to risk assessment which Bruce Schneier calls ‘attack tree analysis’. This process helps to formalize what’s otherwise a significantly subjective process of analysis and assessment, and can help prioritize your project’s security goals.

Once you know what routes or attack you should be protecting (from your attack tree analysis), you already have organized information about the kind of security you will need to implement in your design. You may also find that this information will be helpful in writing security and privacy policies to accompany your application design efforts.

Please be very careful when carrying out your own research about risk assessment. It is very easy to confuse this process with another process, usually called ‘security assessment’. A risk assessment is a process that people undertake (sometimes aided by organization-enhancing software) to determine risks surrounding their specific efforts. On the other hand, there are many software tools available for security assessments that will analyze your network and servers for known vulnerabilities. (Three tips for using these kinds of software tools:

1) research the producing company carefully so you will be sure you can trust them with the necessary access privileges before setting the software up on your network,2) test the tool in an isolated testing environment before applying it, and 3) strongly consider petitioning your internal Information Technology department or Help Desk for permission to run this kind of tool on your company’s internal networks.) Security assessment tools can be useful, but cannot be 100% effective, and though they may help you do risk assessment for extant problems with existing software, they will not be able to do the job for you in regard to designing and developing new software and applications.

The process of risk assessment is part of the security and auditing professions as well as being a common topic in MBA coursework. For more information about the topics of risk assessment and starting points in further research.

These links are provided for reference only and may not be applicable to your architecture or configuration. You are responsible for ascertaining whether any procedure suggested or described applies to your configuration, and for testing it in a testing environment before implementing it.

Policies

If you do some reading about security in general, eventually you will encounter the concept of security policies. Do not take this aspect of security lightly. Ideally, you and your team should create and update a security policy integral with the rest of your development process.

A policy, aside from giving you the ability to reassure your customers by publishing it on your Web site, will help you think out and plan your application design specifically with security in mind. Each time your requirements change, someone on your team should be responsible for reviewing the policy with executive team members and seeing to necessary changes in the document. This makes it easier to effect changes in your code that honor and protect your security policy’s requirements.

Policy is more important than you may think. One of the more subtle but pernicious causes of security and privacy policy violation within a company comes from changing business requirements in the middle of a development cycle, or after an application has been deployed. For example, imagine a hypothetical company that makes its money from advertisement revenue generated by draw from downloads of top 40 song tracks. They start out with a solid privacy and security policy, but during their web application development, this hypothetical company switches business plan to a partnership with a tape and CD mail-order store that draws potential customers with preview song tracks. The hypothetical company’s revenue now consists mainly of getting a cut of sales.

In this kind of situation, not only might earlier privacy policies be potentially violated if mailing lists and other customer contact information were shared with the new partner, but the previously secure architecture could be hacked to pieces for the sake of facilitating the new partnership. For example, suppose the hypothetical company above ended up having to modify its secure distributed architecture, opening more liberal access from the Internet so that the new partner could access the back-end databases. This sort of hasty change to architecture and application happens a lot more often than it should in order to accommodate the quickly shifting technology market, sometimes with disastrous consequences. One systematic way of reducing the chances that this will happen to your company is to make sure that policies are always considered, updated and designed in parallel with the applications to which they apply.

If you have time and resources to carry out this kind of effort, it is worth it. Security does not happen spontaneously, and it requires careful thinking and planning to design and implement security well. Policies can help bridge the gap between risk assessment and implementation.

You are responsible for ascertaining whether any procedure suggested or described applies to your configuration, and for testing it in a testing environment before implementing it.

Platform Research, Modular Architecture and Delegation (Layering)

One security term for in this type of design consideration is called ‘layering’, referring to the idea that most hardware and software combinations are designed in layers.

From this point of view, each module of the machine comprises a layer. It can be a bit tricky to visualize properly, and there’s usually a lot of debate about how to divide any particular system, because each system architect visualizes the borders differently. From a high level, if you visualized the layering of a server, one person might divide it into categories of mandatory and optional hardware, drivers, and software, whereas another might divide it up into functional roles, like input, storage, display, processing and output.

The reason that layering is important — no matter how you slice it — is that ignoring it is incredibly facile and common. We all have a tendency to think that we can implement a certain function better than the people who came before us. However, in doing so, we may be compromising carefully designed security architecture that supports existing functions.

Delegation is very important in design and development. Ideal security architecture efforts involve doing research about the systems on which your applications and architecture are based. Once you know your platform(s), you delegate, and simply let it do its job. Trying to outthink and out-code your platform can have disastrous results.

Security specialists who do implementation earn their stripes. Successful developers who do security-related coding learn proper implementation by experience, enduring many years of failures and criticism. If security is your priority, and it should be, then you should respect the experience that these skilled specialist developers have invested in the platform by using their implementations wherever you can. This means that you should delegate functions in your application to pre-existing layers in your platform, and circumvent existing implementations provided by your platform only when there is no other choice.

The other important aspect of layering is that if done correctly, your properly secure implementations allow other programmers and developers to rely on your application (layer) to keep their data safe. This means that if you get data from somewhere else, it becomes your job, from a layering standpoint, to handle that data securely: making sure the data is protected from prying eyes or processes.

Validation (Formal Trust)

The simple summary of validation and its relation to the security term, ‘formal trust’, is that security professionals have a formalized process of defining and analyzing the act of trusting a person or thing.

This sounds like a foreign concept to those new to security. After all, most people just do a boolean equation with trust: “Do I or do I not trust something or someone?”

Security specialists, on the other hand, have a formal process for identifying what entities should be trusted. This formal trust carries no social or personal meaning. If a security process or specialist doesn’t trust you, it doesn’t mean that she thinks you are personally untrustworthy. Generally, it simply means that she has procedurally determined that your policies and procedures are not stringent enough for the formal trust standard she uses.

This process means that formal trust is very closely related to policy. Security policies often define what requirements must be satisfied for a certain resource or entity to be trusted. This means that the specific policies that define any company’s formal trust process are mutable, and may depend strongly on the requirements set forth by that company’s legal, executive and marketing departments.

But back to validation: what we learn from formal trust is that unless incoming data comes from a ‘trusted resource’ (a resource that passes all the tests of formal trust set forth by the policy), that data is not trustworthy. If data are not trustworthy, then validation is required.

Validation simply means verifying that input is what it says it is or is what it is supposed to be. If your application is expecting name and address information, but it gets SQL commands, for instance, it is remotely possible that the SQL commands can and will be executed in the middle of a CFQUERY call. A validation mechanism in your application, on the other hand, would check for and filter out SQL-specific characters and strings before passing the data to the CFQUERY tag.

Vigilance

Many people think of the security field as a battlefield, a constant struggle between efforts to increase security and attempts to break through that security. Most security specialists believe that there will never be a silver bullet absolutely ensuring absolute, permanent security in any system. Because security will always be a struggle, vigilance will always be part of your job. There are constant improvements in the security field, and constant improvements in the way attackers analyze and defeat defenses.

As a web developer, you do not have to be directly involved in the war, but it behooves you to monitor the situation. One of the best ways to monitor security as it develops is to subscribe to vendor notification services. If you have time, subscribing to security discussion lists is very helpful, but many of such discussion lists are very high-traffic. If you find you do not have time to keep up even with the vendor notification services, however, you may want to consider contracting a security consulting firm to help you track risks and plan appropriate responses.