Security aspects for project and template development

The creation, generation, and delivery of content is protected within the FirstSpirit environment by comprehensive security measures (e.g., authentication procedures, access permissions, etc.).

However, this does not relieve FirstSpirit developers from their duty to protect pages generated using FirstSpirit from unauthorized access. Various potential weaknesses and security problems in websites can be prevented from occurring in the first place if the design of the project has been well thought-out and the FirstSpirit templates have been implemented correctly.

The examples below describe common targets and weaknesses with respect to programming websites and provide simple solutions for dealing with them.

The examples shown do not cover all security aspects in their entirety and are not intended to be a substitute for an individual and detailed security analysis of a project (if necessary). They are to be used simply as a guide during the development of a project and to set out examples of potential weaknesses.

Preventing cross-site scripting (XSS)

With cross-site scripting, the attacker uses script languages in conventional input options (e.g., forms) to attempt to reach a confidential location where he or she can then access confidential data and information (e.g., passwords) or manipulate applications. Successful XSS attacks on web applications can occur, for example, when entries made by users from the web application are forwarded unchecked to the browser. If the attacker enters a script in a simple form field and transfers this input to the web application, the application can transfer this call unchecked to the browser. In this case, an XSS security vulnerability arises. However, behavior of this nature can be prevented if you plan for attacks such as this when developing templates.

Example: Replacing special characters with HTML-compliant characters

The names of pages and menu levels are assigned using input forms and can reach the HTML output of the page unfiltered (e.g., via a navigation function within the HTML template), meaning that they represent a potential weak point for XSS attacks.

Solution: Within the HTML template, this security vulnerability can be prevented relatively easily by converting characters. The page and menu names are output in the $CMS_VALUE(#nav.label)$ HTML channel. If the string is output unfiltered, script calls can be written to the name fields, e.g.,:

<script>alert('XSS');</script>

To prevent this security vulnerability, the template developer can use the .convert2() method (in Bean syntax: .convert2), i.e., $CMS_VALUE(#nav.label.convert2)$. The convert2 function replaces non-HTML-compliant characters with HTML-compliant characters using the Conversion rules (→Documentation for Administrators). In addition, HTML and / or XML-specific characters can be quoted. The developer should make sure that at least characters:

• < and >
• ' and "

are quoted and / or included in the conversion rule used (for the template set).

The script call is then converted in the HTML output to:

<script>alert('XSS')</script>

Example of a navigation function with character conversion:

<CMS_FUNCTION name="Navigation" resultname="pt_subNavigation"> 
   <CMS_ARRAY_PARAM name="unselectedHTML"> 
     <CMS_ARRAY_ELEMENT index="1..4"><![CDATA[<li><a href="$CMS_REF(#nav.ref)$">$CMS_VALUE(#nav.label.convert2)$</a></li>]]></CMS_ARRAY_ELEMENT> 
   </CMS_ARRAY_PARAM> 
</CMS_FUNCTION>