Skip to content

Instantly share code, notes, and snippets.

@learncfinaweek

learncfinaweek/gist:4121364

Created November 20, 2012 21:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save learncfinaweek/4121364 to your computer and use it in GitHub Desktop.
Save learncfinaweek/4121364 to your computer and use it in GitHub Desktop.
Download ZIP
Security - Introduction
Raw
gistfile1.md

Security is a broad topic area and the threats are constantly evolving. Security encompasses more than just writing secure code, but also items like the configuration and setup of the servers and network, and practices and procedures for handling sensitive data.

In this chapter, we'll focus on areas of security that you have the most control over as a ColdFusion developer in order to help you write more secure ColdFusion code and understand the security settings in the ColdFusion Administrator, making it more difficult for an attacker to exploit your web application. We say "more difficult" because no web application can be 100% secure.

There are several shifts in thought required.

  1. The web browser, be it desktop or mobile, is not the client interface to your web application; anything that can communicate with the HTTP protocol is the client interface to your web application. This includes telnet, wget, web application testing tools, or web attack tools.
  2. Do not trust any data that comes from the client. This is more than just the URL parameters and the form post data; it also includes cookies and CGI variables. Anything that originates from the client can be manipulated by an attacker.
  3. Validate all input on the server side. Client side validation is nice for the user experience, but can be circumvented.

Black List Versus White List

Black lists are lists of known "bad" patterns. Since there are always new attacks, black lists will always keep growing and are only as good as the known pattern it can detect. ColdFusion 7 introduced a feature called Script Protect that provided minimal Cross-site Scripting (XSS) prevention and is an example of a black list. It could block input that included <script> tags while allowing <iframe> because it was not included in the pattern to look for.

White lists, on the other hand, are a list of "good" values or patterns that the web application will accept for a given input, and all others are rejected. White lists have the advantage in that they are a finite set and can be used as part of the server side validation of data. An example of a white list would be a list of US States abbreviations used to check the value of the State form field on a form.

Using white lists is the preferred approach and will be shown throughout this chapter in the examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment