Secure Your Application – PCI DSS Specifications

Monday, 26th January 2009 in Development, Technology by Simon | 5 comments

PCI DSS stands for Payment Card Industry Data Security Standard, and is a worldwide security standard assembled by the Payment Card Industry Security Standards Council (PCI SSC). The PCI security standards are technical and operational requirements that were created to help organizations that process card payments prevent credit card fraud, hacking and various other security vulnerabilities and threats. The standards apply to all organizations that store, process or transmit cardholder data – with guidance for software developers and manufacturers of applications and devices used in those transactions. A company processing, storing, or transmitting cardholder data must be PCI DSS compliant.

Types of Data on a Payment Card

The PCI SSC (Council) is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. Non-compliant companies who maintain a relationship with one or more of the card brands, either directly or through an acquirer risk losing their ability to process credit card payments and being audited and/or fined.

All in-scope companies must validate their compliance annually. This validation can be conducted by Qualified Security Assessors, i.e. companies that have completed a three-step certification process by the PCI SSC which recognises them as being qualified to assess compliance to the PCI DSS standard. However, smaller companies have the option to use a Self-Assessment Questionnaire. Whether this questionnaire needs to be validated by a QSA depends on the requirements of the card brands in that merchant’s region.

The current version of the standard specifies 12 requirements for compliance, organised into 6 logically related groups, which are called “control objectives.”

  1. Build and Maintain a Secure Network
    • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
    • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
  2. Protect Cardholder Data
    • Requirement 3: Protect stored cardholder data
    • Requirement 4: Encrypt transmission of cardholder data across open, public networks
  3. Maintain a Vulnerability Management Program
    • Requirement 5: Use and regularly update anti-virus software
    • Requirement 6: Develop and maintain secure systems and applications
  4. Implement Strong Access Control Measures
    • Requirement 7: Restrict access to cardholder data by business need-to-know
    • Requirement 8: Assign a unique ID to each person with computer access
    • Requirement 9: Restrict physical access to cardholder data
  5. Regularly Monitor and Test Networks
    • Requirement 10: Track and monitor all access to network resources and cardholder data
    • Requirement 11: Regularly test security systems and processes
  6. Maintain an Information Security Policy
    • Requirement 12: Maintain a policy that addresses information security

Compliance with these requirements can be summarized into 3 main stages:

  • Collecting and storing: Secure collection and tamper-proof storage of all log data so that it is available for analysis.
  • Reporting: Being able to prove compliance on the spot if audited and present evidence that controls are in place for protecting data.
  • Monitoring and alerting: Have systems in place such as auto-alerting, to help administrators constantly monitor access and usage of data. Administrators are warned of problems immediately and can rapidly address them. These systems should also extend to the log data itself –- there must be proof that log data is being collected and stored.

What does this actually mean for web application developers?

It is considerably more expensive and more time-consuming to recover from a security incident than to take preventative measures ahead of time. If you follow the guidelines below, you will go along way to securing you application in line with the PCI DSS regulations. Many of the measures apply to general application security, but since PCI DSS is all about security, they are worth mentioning.

Server-level Security:

  • Separate web- and database-servers on to different physical machines.
  • Secure the web- and database-servers with traditional techniques. Only authorised accounts should have the capabilities to run tasks on the machine. That means not giving admin-rights to the user account.
  • Keep servers up-to-date with the latest patches and software releases.
  • Minimise the number of services running on the server. This means limiting the services to only those required for the web- or database-servers to function.
  • Secure information in transit between servers. This may mean physically securing the network to prevent evesdropping via encryption or obfuscating the data amongst innocuous ‘noise’.
  • Secure the database server behind a firewall.

Application-level Security:

  • Separate ColdFusion, the webserver and database server user accounts. They should never be under the same system account.
  • Create a database user specifically for your ColdFusion datasource and restrict it to only the activities required for the application. The user should not have database-owner rights, access to databases not relating to the application or access to the system tables.
  • Revoke privileges in the ColdFusion datasource definition to prevent the SQL commands CREATE, DROP, GRANT, REVOKE and ALTER.
  • General settings in the ColdFusion Administrator:
    • Check the Disable access to internal ColdFusion Java components option.
    • Check the Enable Global Script Protection option.
    • Add a Missing Template Handler.
    • Add a Site-wide Error Handler.
    • Reduce the Maximum size of post data from 100MB.
    • Enable Timeout Requests, and set to 60 seconds or less.
    • Disable Robust Exception Handling on production servers.

Web Application-level Security:

  • Use secure HTTP to transfer data and/or when logged into ‘administration’ secutions of your web application.
  • Timeout sessions after 15 minutes and on browser close.
  • Provide multi-level login processes. For example, lock the application after 3 failed attempts for a period of 10 minutes.
  • Do not identify whether the username or password are incorrect, simply notify the user that their login failed and that they must try again.
  • Encrypt passwords stored in the database with a standard such as SHA-256 or ’stronger’.
  • Use CAPTCHAs (textual and aural) to prevent automated robots hacking into your application.
  • Run regular penetration tests on your application to identify potential problems.
  • Encrypt credit card information held in the database or other storage mechanism. Only store credit card data in line with the PCI DSS regulations.

Code-level Security:

  • Application.cfc – Set the scriptProtect Application variable to true to enable application-wide cross-site script protection.
  • CFQueryParam – This tag, importantly, verifies the data type of a query parameter and, for RDBMSs that support bind variables, enables ColdFusion to use bind variables in the SQL statement. Bind variable usage enhances performance when executing a cfquery statement multiple times. There are limitations to the use of the cfqueryparam tag. In ColdFusion 7 for example, you cannot use them in queries using the cachedWithin attribute. Similarly, they cannot be used in ORDER BY clauses, although the use of conditional logic should resolve the need for order by variables.
  • Functions – As a rule of thumb, validate all the data being passed into a query prior to it being used. ColdFusion MX 7 saw the introduction of the isValid() function. This function tests whether a value meets a validation or data type rule and can be used to replace a large number of type-specific functions such as isArray(), isBinary(), isBoolean(), isDate(), isNumeric() and isSimpleValue() etc.
  • Stored Procedures – I often favour the use of stored procedures over standard queries. Not only do they add an additional level of performance, they provide an additional level of security; ColdFusion does not do any raw processing of queries in the web code, it simply passes variables down the wire to the database server.

Conclusion

The goal of the PCI Data Security Standard is to protect cardholder data that is processed, stored or transmitted by merchants. The security controls and processes required by PCI DSS are vital for protecting cardholder account data, including the PAN – the primary account number printed on the front of a payment card. Merchants and any other service providers involved with payment card processing must never store sensitive authentication data after authorisation. This includes sensitive data that is printed on a card, or stored on a card’s magnetic stripe or chip – and personal identification numbers entered by the cardholder.

By following the points made above, you will go a long way to meeting the PCI DSS guidelines, whilst also securing your infrastructure and applications in a more general sense.

Caveat: The views and comments written in this article are provided as a guideline. I hold no responsibility for the security of your applications and data based upon the information provided.

JavaScript Frameworks – Let There Be Light

Wednesday, 16th July 2008 in Development by Simon | No comments

For many web developers, whenever JavaScript is mentioned it provokes a rye smile; JavaScript is one of those programming languages that is rather avoided than embraced. This is not the fault of the language itself, but rather the browsers. A few years ago, the landscape of client-side scripting was a bleak scene. Browser inconsistencies, particularly with the dominant Internet Explorer, implementation bugs and numerous target platforms made developing client-side JavaScript a tricky undertaking.

To the consternation of these same developers, the landscape changed and Web 2.0 hit the mainstream. Almost overnight, every website on the internet wanted to use or was using AJAX. Marketers joined the bandwaggon and every feature requested had to involve something dynamic and revolutionary. Thus JavaScript development quickly hit the forefront of peoples minds and became as important as any server-side technology available at the time.

Over the next few blog posts, I will be using the popular frameworks jQuery, Yahoo! User Interface Library (YUI), ExtJS and Adobe’s Spry with ColdFusion to demonstrate various techniques, such as autocomplete and form validation.

Poor Man’s HTTP Compression with ColdFusion

Saturday, 17th March 2007 in Development by Simon | 8 comments

An interesting article I read in the CFDJ recently was entitled Poor Man’s HTTP Compression with ColdFusion. Almost every web application will benefit from the compression of content. A compression filter optimises the size of the content that is sent from a webserver to a web browser via the Internet. Since generating content and serving pages via the World Wide Web is the core behind web applications, it is simple components that aid these processes that are incredibly useful. This is where servlet filters come into play.

Servlet filters are tools available to web application developers. They are designed to be able to manipulate the request and responses that are sent to a web application, without manipulating the servlets, static pages like HTML and, in this case, CFM pages that are being used by the web application (unless of course that is the desired response). Servlet filters act like a chain of steps that a request and response must go through before reaching the page in the application.

Compressing Content Using a Servlet Filter

Compression is a process that reduces the number of bytes required to define a document in order to save disk space or transmission time. It is extremely useful for sending information across the web, because the speed at which people receive information from a web application is dependent upon how much data you are trying to send. The smaller the amount of information that is to be sent, the faster it can be sent. Therefore, compression and the associated responsiveness is a key component to retaining users and generating revenue from those retained users.

Compression can be effectively achieved by having a servlet filter conditionally pipe the produced content to a GZip-compressed file. GZip is supported by the HTTP protocol and almost all modern browsers (hence the servlet filter conditionally compresses the content).

GZip compression usually results in a 6:1 compression ratio, although this depends on how much content is being sent and what the content is.

Setting up the Servlet Filter in ColdFusion

Using the ColdBeans servlet filter found at the following URL:

http://www.servletsuite.com/servlets/gzipflt.htm

  • Download the GZipFilter.jar
  • Save GZipFilter.jar in the WEB-INF/lib folder in the ColdFusion Server wwwroot.
  • Edit the web.xml file in the WEB-INF folder in the ColdFusion Server wwwroot with the following code: 
    <filter>
<filter-name>GzipFilter</filter-name>
<filter-class>com.cj.gzipflt.GzipFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>*.cfm</url-pattern>
</filter-mapping>
  • Restart the ColdFusion Service

Now, when you invoke any .cfm page the GzipFilter will check out client’s browser settings. If the browser does not support gzip, the filter invokes resource normally. If the browser does support gzip, output will be compressed.

onTap – Web Application Framework

Wednesday, 19th October 2005 in Development by Simon | No comments

The onTap framework is an Open Source Framework for quickly developing powerful web applications using Macromedia’s ColdFusion application server. The framework itself bears a marked resemblance to the recently buzzy Ruby on Rails.

The onTap Framework can be downloaded at the following url:

http://www.fergusonhouse.com/?netaction=download

Fusebox – Web Application Framework

Wednesday, 19th October 2005 in Development by Simon | No comments

Application developers face a daunting task: they must translate the often fuzzily-defined requirements for a new application into the rigid language of computers. While the Fusebox Lifecycle Process (FLiP) offers help in managing the project management aspects of creating a new application, what help is there available to developers approaching the technical challenges of creating and maintaining applications?

Application frameworks answer this question, offering pre-built (and pre-tested) code — a collection of services that can provide the architectural underpinnings for a particular type of application. Web-based applications are increasingly the choice for new application development in which the browser becomes the “universal client”. As web development matures, web-based application frameworks allow the developer to concentrate more on meeting the business needs of the application and less on the “plumbing” needed to make that application work.

Fusebox is, by far, the most popular and mature web framework available for ColdFusion and PHP developers. The architecture of a Fusebox application is divided into various sections (“circuits” in Fusebox parlance), each of which has a particular focus. For example, the responsiblity for ensuring that only authorized users have access to all or part of the application might fall under a Security circuit.

The Fusebox application architect defines these circuits, as well as the individual actions (“fuseactions”) that may be requested of it. When a fuseaction request is made of the application, the Fusebox machinery (the “Fusebox”) routes the request to the appropriate circuit, where the fuseaction is processed. This idea of encapsulation of responsibilities makes it easy for different functional circuits to be “plugged” into an application, making it possible to reuse code.

Within the individual circuit responsible for carrying out the requested fuseaction, the Fusebox architect specifies the individual files (“fuses”) needed to fulfill the fuseaction request. Thus, the Fusebox acts like a good manager, delegating tasks to appropriate departments where it is decomposed into individual tasks, each of which can be assigned to individuals to carry out.

Mach-II – Web Application Framework

Wednesday, 19th October 2005 in Development by Simon | No comments

Mach-II is a web-application framework focused on easing software development and maintenance developed by Hal Helms and Ben Edwards.

http://www.mach-ii.com

Model-Glue – Web Application Framework

Wednesday, 19th October 2005 in Development by Simon | No comments

Model-Glue is:

  • An Implicit Invocation framework simplifying use of the Model View Controller design pattern in ColdFusion applications. It’s designed to be easy to use and play well with others, like Tartan.
  • Released under the Lesser GPL, meaning that it’s free to download, use, and alter.
  • A framework encouraging clear seperation of Model, View, and Controller
  • Lightweight enough to play well with others: it comes with out-of-the-box connectors to Paul Kenney’s Tartan Framework.
  • Akin to Mach-II, another II, MVC framework, but with slightly simpler functionality, and more clearly defined boundaries between Model and Controller.
  • Written by Joe Rinehart, a quasi-popular ColdFusion blogger with an interest in developing better OO applications in ColdFusion, with constant feedback provided by Doug Hughes of Alagad, Inc.

TheHub – Web Application Framework

Wednesday, 19th October 2005 in Development by Simon | No comments

TheHUB, like other application development frameworks, utilizes the notion of a central hub template that all requests for the application pass through. That cental hub is the point or place within the application that the processing of all code hinges upon. The code simply checks for a query string and then reads the parameters passed to handle template loading and screen rendering.

The concept is that each request passes a unique set of keys that relate one-to-one with a site or application directory and template within the named directory. In applications and websites that utilize TheHUB, the query string looks like “?dsp=the_hub…”. This indicates to the “framework hub” template… the “index.cfm” that it should include the “the_hub.cfm” template from the “dsp” directory.

Download the code at this url http://www.codesweeper.com/index.cfm?code=main

Tartan – Web Application Framework

Wednesday, 19th October 2005 in Development by Simon | No comments

Tartan is a command-driven service framework for ColdFusion. It was built to help produce the service layer within a larger application architecture which relies on strict separation or layering of functionality.

All access to the underlying business logic is controlled by public services which are available locally as CFCs and remotely via Flash Remoting and SOAP web services. A service can be composed of any number of commands, each of which implements a discreet operation within the application. These contain the core logic for the application. Commands can communicate with databases via DAOs, manipulate values received from the client, execute other commands and even communicate with services available on other remote servers.

At the center of Tartan are 6 Core classes : LocalServiceProxy, LocalService, Command, DAO, ValueObject and ExceptionHandler. They provide most of the functionality of the framework, and must be extended by the application developer.

Overview and Explanation

The driving need behind Tartan was a production application that needed to transfer data between 5 different databases and 3 different applications. There was a complex set of DAO classes and a faade class that provided access. Each fa ade class had a single public method called “execute” that would simply take arguments and return a result.

This concept worked well, but obviously had its limitations. So Tartan was created to be able to quickly and easily add new commands to services, and new services to the system.

Tartan is described as a “command-driven service framework.” What does that mean? In this context a “service” is a set of commands that have commonality, and a “command” is a method that executes any number of other methods and returns a result. It’s that simple. A service such as “televisionViewer” could include a command such as “getListings” which would, based on locality data provided either by a config file or a method argument, check local listings and return a collection of data regarding current television listings.

To further explain the concept of “commands,” we could offer that method a second argument such as “returnType” and return the listings as an array of structures, a CF query object, or an XML file. By adding commands from granular to broad, we can incorporate them into sequences. For instance, if we wanted to offer the findMyShow command, we could have it first execute getListings, then parse the resulting data and determine if our show is on soon or not.

By doing this carefully and with some planning, we develop a very simple interface between our application and any persistant storage mechanism and/or business objects, with the ability to filter, alter, or convert our results before they’re returned to the caller. If we start with granular and move to broad commands, we maintain the flexibility and encapsulation of an OO design, but gain the convenience and natural-thinking appeal of procedural programming.