With Adobe InContext Editing you can create, manage, and control editable web pages that authorized users can update via their browsers—without learning HTML, installing software, or compromising the design.

This tutorial details a set of best practices for securing web pages that you have made editable using the Adobe InContext Editing service. In this tutorial, you will learn how to:

• Apply best practices for using the service securely
• Set up your server to block malicious or accidental but harmful operations
• Register your website safely
• Maintain control of user actions as they edit page content
• Enable secure editing of website content

A detailed discussion of the specific markup necessary to integrate with the service or how to use the service is beyond the scope of this article. For more information on these topics, refer to InContext Editing help.

Following the principles described in this article will help you avoid potential security problems that may arise while using the Adobe InContext Editing service.

Requirements

In order to make the most of this article, you need the following software:

Dreamweaver CS4

• Try
• Buy

Prerequisite knowledge

In order to complete this tutorial, you need to have knowledge of how to apply the necessary markup that will allow your website pages to be edited. Also, you should be familiar with InContext Editing website management capabilities and with using the service for basic browser-based editing.

Creating the InContext Editing site

Before creating your InContext Editing site, make sure you have defined the site in Adobe Dreamweaver with a testing server or remote server. For instructions on properly defining a site, see Setting up a site in Dreamweaver help. For the purposes of this tutorial, your website does not have to use server-side technology. The remote server should be outside of a firewall; that is, it should be accessible from the Internet as well as from the Adobe InContext Editing server.

InContext Editing markup can be applied to static HTML pages as well as pages generated dynamically with server-side scripting languages such as ColdFusion, PHP, ASP, JSP, and others. In either case, however, the content to be edited must be statically saved in the source code of your page.

Whenever possible, limit the use of the InContext Editing capabilities to static HTML pages and avoid using them in dynamic pages. With server-side generated pages there is a risk that a user with editorial permission will inject some server-side dynamic code inside the editable content. This code is saved into the page, and the next time the page is accessed, the code will execute in the context of that page, potentially providing unauthorized access to sensitive information including database data, session details, or files on the server.

Linking to external resources on your web pages is also strongly discouraged. Changes to external JavaScript code, cascading style sheets, and images are beyond your control, and malicious code can be introduced without your knowledge. JavaScript code in particular has been used to breach security and gain access to user credentials, in some cases without raising the suspicion of the end users or the website administrators. When using InContext Editing, limit the use of resources from external resources or avoid them altogether.

Configuring your web server to allow server-side scripting code in HTML pages can cause similar security problems. Most web servers use the file extension of the requested page to determine how the request should be handled. Typically the web server will automatically handle HTML and HTM files as static content, whereas dynamic content (files with CFC or PHP extensions, for example) requires server-side script processing. Some web administrators, however, configure the web server to allow HTML files to contain dynamic scripting code. When using InContext Editing, this presents a security vulnerability, because malicious users can save scripting code into HTML pages, which will then be executed the next time the page is loaded. For this reason, configuring the web server to process server-side scripting code in HTML pages is not advised.

Special care must also be taken when using forms in your website. Malicious users may use blog comments, forum posts, or other forms, to inject code into a page. This code would later be executed by the browser of any user viewing the page. Moreover, users editing the page using the InContext Editing service could inadvertently execute the code in the editor context. In this case, the code would have access to the user's credentials and could overwrite editable content on the page.

Securing the FTP connection

When registering a website for the InContext Editing service and configuring the connection details, administrators should use SSH File Transfer Protocol (SFTP) instead of FTP whenever possible.

Note: SFTP should not be confused with the old and obsolete Simple File Transfer Protocol.

SFTP provides a secure environment for the transfer of data, enabling you to upload and download files safely. SFTP connections also encrypt the username and password used for authentication to your website server. In contrast, FTP encrypts neither the authentication information nor the data being transferred, which puts your information at risk of being intercepted.

The SSH encryption mechanism is one of the safest methods available for transport of any kind of information between servers over unsecured networks, including the Internet. Transfers are slightly slower with SFTP compared to FTP, but the difference is insignificant when compared to the security advantages. For these reasons, SFTP is the preferred method of registering with InContext Editing service and configuring it for your website.

Configuring your site in InContext Editing

When setting up InContext Editing, you need to configure two folder paths in the Site Configuration window: the host directory and the media upload folder.

The host directory is the folder on the FTP/SFTP server that contains the files that you will allow to be edited with InContext Editing. The media upload folder is a special folder on the host where media files (JPG, GIF, PNG, AVI, MPEG, and SWF files among others) will be uploaded.

To avoid security breaches do not create any symbolic links in the host directory. Symbolic links to other directories provide an avenue for users to gain access to other information on the server. Instead, create actual copies of these directories in the host directory.

You can further enhance the security of your host directory by setting file permissions appropriately for editable and non-editable content. Some of the pages, media, documents, and files in the host directory are designed to be editable or replaceable using the Adobe InContext Editing service, whereas others should be read-only to avoid possible accidents. To put this into practice, create two separate users on your system and assign ownership of the files in the host directory to them. One of the users, the one that will be used through the remote connection by the InContext Editing service, should have write permissions for the only files that are meant to be modified by the editors of the website. This user should also have permission to create new files or folders to ensure that other functions, such as creating a page copy, work correctly. The second user should have write permissions for all files via FTP/SFTP. This identity will be used by the website developers in their development and maintenance activities. This user, however, should not be used to register the website for the Adobe InContext Editing service.

Although you are not required to specify and use a media upload folder, it is a good idea from a security perspective. If you do not specify a media upload folder, files can be uploaded directly to the site host directory or any of its subfolders. Users will also be able to browse the host directory using the Asset Manager and add or update images all over the website. This setup offers unnecessary access to users to all the folders and resources in the host directory.

When you create a special folder in the host directory where all the media uploaded files will be directed, you can control the assets to be uploaded so they don't interfere with the designed structure of the website. After you specify this folder as the media upload folder in the InContext Editing configuration, all media files will be uploaded into only that folder or one of its subfolders.

Using InContext Editing securely

After you configure your website for the Adobe InContext Editing service you can start inviting users to join your website editorial team. For more information on how to invite users to edit a website, refer to InContext Editing help.

New users can subscribe to the service using their preferred e-mail address; they are not required to use the one by which they received the invitation. This allows users to select the work or personal e-mail address that they want to use for InContext Editing.

Although it is possible to assign Editor, Administrator, or Publisher permissions to new users as you invite them, it is safer to always start with the most limited permission, Editor. When the invited user finishes the registration workflow, the administrator receives an e-mail confirming the user has joined the website content management team. At that time, the administrator can verify that the person who joined the service was truly the person to whom the invitation was extended and then assign a new permission setting such as Publisher or Administrator.

In the event that an e-mail invitation is intercepted, this workflow ensures that malicious users would not be able to alter live content. Because users with Editor privileges can create only draft pages and are unable to publish them to the live site, the impact of this kind of security breach would be minimized.

When editing a page using InContext Editing, users should be careful when copying and pasting content from other websites, pages, or documents. Selected text from a browser or Microsoft Word may also include hidden elements that can cause security problems when pasted to your web page. Invisible CSS or JavaScript code can change the way your page looks and operates. After the page is saved and published, the code will be executed by everyone who visits the page, exposing them to potentially malicious code.

There is a safe way to copy and paste code into editable pages. Begin by opening a simple text editor that does not support styling or rich text, for example Notepad on Microsoft Windows or TextEdit on Mac OS X (be sure to choose Format > Make Plain Text in TextEdit). Select and copy the text from the desired location, but instead of pasting the code directly into your browser, paste the text into the text editor. Because the text editor supports only plain text, any hidden code that was unintentionally copied will be ignored. Now the editor simply contains only the text with no hidden code that may damage your website. Next, re-select the text from the text editor, copy it, and paste it into your InContext Editing browser window.

The newly inserted text will be free of any hidden code and your page should be safe to format and save.

Where to go from here

For more information and help with InContext Editing, check out these resources:

• InContext Editing help for developers
• Enable your site for InContext Editing
• InContext Editing (on Adobe Labs)

About the author