Contexto Municipal

Solutions in this chapter:

■ Cross-Site Scripting ■ Validating Browser Input

■ Validating Consistently from the “Hit List” ■ Web-Based File Upload Issues

■ URL Session Variables

Chapter 4

109

; Summary

; Solutions Fast Track

Introduction

Securing your ColdFusion applications is a big job. It’s easy to think about what you need to protect when you are writing a simple data-driven template that doesn’t do much. However, security for your application becomes more complex as the application itself becomes more complex, because you need to guard access not only to your application, but also to the database and other systems with which your application communicates. As Web application development in gen- eral—and ColdFusion Markup Language (CFML) development specifically— move toward a “Web-services” model utilizing the Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and other text-based network messaging, application security will become increasingly important.

This chapter explains a general methodology of coding your ColdFusion applications to maximize security. In addition, we will apply this methodology to a specific list of challenges that ColdFusion developers typically face when attempting to develop applications with a high degree of security.

Your methodology for developing ColdFusion applications should include techniques to secure your applications as a core competency.The task of securing your ColdFusion applications is easier if you keep the following concepts in mind as you are designing your code and writing your applications:

■ _{Validate input. Always make sure that you are receiving the kind of}

input you think you are. Hackers might try to use the ways that your application receives information to attack other systems connected to your Web server.

■ _{Don’t hard-code values. If you require specific key values for your}

application, you should place these values in a custom tag or included file to ease deployment of the application.This technique will also mini- mize the chance of typos, security holes, and so-called “temporary” hacks that become permanent and annoying fixtures in your code. Application.cfm is an excellent place to set global values for your appli- cation; if you use the request scope for these variables, the global values will be available for the length of the server request and will not need to be locked using the <CFLOCK> tag.

■ _{Think like a hacker. When building your application, you should}

assume that certain users will try to use your system in unintended ways. By trying to break your ColdFusion application, you will find bugs and perhaps better ways to structure your business processes and applications.

■ _{Encapsulate your code. Use <CFINCLUDE> to include commonly}

used files so that you can update a file in one place and see your changes cascade to many points in your application.You can also use ColdFusion’s custom tag framework and <CFMODULE>, which allows you to call custom tags more elegantly.That said, any structured methodology that promotes modular code would be helpful in securing your ColdFusion applications. One such methodology is Fusebox (you can find more infor- mation on this strategy at www.fusebox.org).

■ _{Test your code.} Write a test plan to show other people in your orga-

nization and yourself what the application does, and how you are plan- ning to test it.This task will help you to identify weak points in your application and to fix them quickly.

■ _{Protect your pages. Important pages, such as templates that delete}

information from a database, should be coded so that they can only be called by certain other pages, rather than invoked from any URL on your Web site or elsewhere on the Internet.

■ _{Authenticate your user. Use external validation such as encrypted}

cookies in conjunction with database records to authenticate a valid user, rather than just relying on the default CFID and CFTOKEN values cre- ated by ColdFusion’s <CFAPPLICATION> tag. Hide valuable informa- tion, and use URL and form variables only as pointers to other

information, rather than passing this valuable information in URL or form variables openly.

This chapter explains this methodology for securing ColdFusion applications in the context of the following potential hacker attacks against your ColdFusion applications:

■ _{Cross-site scripting} An attack where a JavaScript snippet or other

scriptable program is inserted into a form field or other input so that when the dynamic page on which this bit of code is displayed, the rogue program might execute with the privileges of the template being executed.

■ _{Validating browser input An attack to exploit the way in which your}

application accepts input from the user. Certain techniques of accepting input are less secure than other techniques, particularly when interacting with databases.

■ _{Validating consistently from the “hit list” Identify commonly mis-}

used ColdFusion tags and the vulnerabilities you might find in the code produced by developers using these tags.

■ _{Web-based file upload issues The process of uploading a file in}

ColdFusion is very easy. Securing and validating that upload can be more challenging.

■ _{URL session variables Finally, the default setting used by the}

<CFAPPLICATION> tag identifies a unique user with two query

string variables (CFID and CFTOKEN). If cached by a search engine, these query string variables can be used as part of a hack against your Web application to impersonate a valid user.

This list of hacks and potential attacks against your Web site is by no means comprehensive.The point of compiling this list is to introduce you to the mode of thinking you must do when you are trying to secure your ColdFusion applica- tions. After you have learned about these attacks, you might approach new and dif- ferent attacks in a new way when considering how to design and build your code.