Church Application Security Requirements

Community Development Best Practices edit

This document introduces guidelines for secure programming techniques that will help developers build an appropriate level of protection into Church applications.


Executive Summary

This document contains specific guidance for securely coding Church applications. Adhering to the guidance will protect Church and customer data and facilitate alignment with Church information security policies. Threats to applications are real and exploited vulnerabilities have been observed. Successful defenses require adopting the principles that follow.


Secure programming practices are essential to protecting an organization against current and future threats. It is here that security can have the most significant impact, by employing principles that reduce the number and severity of possible attacks against an application. By identifying coding practices with known exploits and following recommended guidelines, development teams can substantially reduce the number of security vulnerabilities in production applications (see CERT Secure Coding).

This document provides a list of fundamental secure coding practices in the form of security requirements. These requirements are based on Church IT policies, industry best practices and recommendations from the Open Web Application Security Project (OWASP). Those responsible for designing and maintaining Church-owned web applications should become familiar with and apply the recommendations outlined in this document.

One of the key principles of successful application defense is that the application must regard the client as a potentially hostile entity. Request tampering, social engineering, hijacked computers, and reflected attacks change the way that applications should treat input. Developers should plan accordingly to address these issues.

Please see the Additional Resources section for additional secure coding information.

Data Validation

Data Validation techniques counter identity spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks. Validating input and output information is one of the most effective means of protecting a website as it directly affects communications between the client and the web application.

Input Validation

Input validation techniques ensure that data entered by the client fall within accepted parameters. The following are methods used to implement input validation:

  • Use strong input validation mechanism to check and validate all input data for length, type, syntax and business rules before input data is processed
  • Ensure that final validation of input is performed server-side. Do not rely strictly on client-side validation

If possible, adopt an “accept known good” or ‘white list’ approach

  • At a minimum, ensure that dangerous characters are URL encoded or blocked (e.g., &, <, >, “, ‘, and /)
  • Ensure that canonicalization occurs before validation. Canonicalization refers to the process of standardizing or normalizing communications.

The following OWASP examples provide commonly used cases of ‘white list’ regular expressions (see OWASP White List Input Validation):

White List Regex Examples

Validating Data from Free Form Text Field for Zip Code (5 digits and optional plus 4)
Validating Data from Fixed List Drop-Down Box For U.S. State Selection
Validating a Free Form Text Field for allowed chars (numbers, letters, whitespace, .-_)
^[\s\w.-]+$ (Any number of characters)
^[\s\w.-]{1-100}$ (This is better, since it limits this field to 1 to 100 characters)
Non-negative integer
^[\d]+$ (Any number of digits)
^[\d]{16}$ (Exactly 16 digits)

Note: \s matches any whitespace character (i.e., space, tab, carriage return, or linefeed, [ \t\r\n]). \w matches alphanumeric characters along with the underscore. \d matches just numerical digits (0-9).

Additional examples are available at the OWASP Validation Regex Repository.

Java Regex Usage Example

Example validating the parameter “zip” using a regular expression.

private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");
public void doPost( HttpServletRequest request, HttpServletResponse response) {
    try {
        String zipCode = request.getParameter( "zip" );
        if ( !zipPattern.matcher( zipCode ).matches() {
            throw new YourValidationException( "Improper zipcode format." );

        ... do what you want here, after it has been validated ...
    } catch( YourValidationException e ) {
      response.sendError( response.SC_BAD_REQUEST, e.getMessage() );

Output Encoding

Output encoding is primarily used to defend against Cross-Site Scripting (XSS) attacks. It involves a standardized way of escaping output to prevent user supplied data from executing improperly.

  • Use strong output encoding to ensure that all user input is entity encoded before rendering for display
  • Ensure that characters that could be used in a scripting attack (e.g., &, <, >, “, ', ‘, and /) are encoded (or removed)

The following are language-specific recommendations to apply output encoding from OWASP:

Use LDS Tech Stack Security Web Module

Please see the excellent documentation provided on the Stack Security Web Module.

Java: Use Struts output mechanisms

  • Use <bean:write ... > or the default JSTL escapeXML="true" attribute in <c:out ... >.
  • Do NOT use <%= ... %> unnested (that is, outside of a properly encoded output mechanism)

.NET: Use the Microsoft Anti-XSS Library

  • Latest version is freely available from Microsoft.
  • Do not assign form fields data directly from the Request ( object: username.Text = Request.QueryString("username"); ) without using this library.
  • Understand which .NET controls automatically encode output data (e.g., TextBox control)

PHP: Ensure output is passed through htmlentities() or htmlspecialchars()

  • Evaluate the soon to be released OWASP PHP Anti-XSS library.
  • Disable register_globals if it is not already disabled

Parameterized Queries

Parameterized queries protect against SQL injection attacks by creating structured queries that limit the scope of the command and create boundaries around escape sequences. Use parameterized queries or parameterized stored procedures to prevent user-supplied input from being directly executed in queries. Here are some examples from the OWASP SQL Injection Prevention Cheat Sheet:

Java “Vulnerable” Example

The following code is vulnerable to SQL injection because it accepts a non-validated string from the user and passes it into the query.

    string query = "SELECT account_balance FROM user_data WHERE user_name = "
        + request.getParameter("customerName");

    try {
        Statement statement = connection.createStatement( ... );
        ResultSet results = statement.executeQuery( query );

To correct, follow one of the following examples:

Java “Safe” Example

    String selectStatement = "SELECT * FROM User WHERE userId = ?;
    PreparedStatement prepStmt = con.prepareStatement(selectStatement);
    prepStmt.setString(1, userID);
    ResultSet rs = prepStmt.executeQuery();

C# .NET “Safe” Example

    string query = "SELECT account_balance FROM user_data WHERE user_name = ?";
    try {
        OleDbCommand command = new OleDbCommand(query, connection);
        command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));
        OleDbDataReader reader = command.ExecuteReader();
        // ...
    } catch (OleDbException se) {
        // error handling
    } (OWASP)

Hibernate Note

In most cases, using an ORM mapper such as Hibernate will provide adequate protection against SQL injection. However, the protections provided by an ORM mapper can be negated by improper usage. For example, the following code is vulnerable:

    Query q = session.createQuery("SELECT * FROM Table WHERE Value = '" + user_input + "'");

To take advantage of the protections provided by Hibernate, the developer must use binding syntax as illustrated below:

    Query q = session.createQuery("SELECT * FROM Table WHERE Value = :foo");
    q.setString(":foo", user_input);

Cross-site Request Forgery

Sensitive transactions or actions that update sensitive information must verify that the transactions are actually submitted by a user (and not maliciously initiated from their browser by a third-party). Two options are to either require the user to enter their current password or include a randomly-generated token (in a hidden form field) that is validated on the server before the sensitive action occurs. For example, when updating users' passwords it is customary to require that users enter their current password. Other sensitive actions include updating email address (especially if the application uses email addresses on file for resetting passwords), transferring funds, deleting audit data, modifying user roles/permissions, and so forth.


The LDS Tech 3.x IDE for Java provides a Cross Site Request Forgery protection mechanism. To enable this protection mechanism a developer needs to add the following filter definition to the web.xml file. This filter will generate a token in the form of a cookie which the server will check to ensure the request originated from the user.


The developer then needs to add a servlet filter to protect the resources that may be susceptible to XSRF attacks. An example of this is as follows:


Please see the following resources for more information:


Good authentication techniques counter identity spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks (see Terms and Definitions). It is one of the most visible and targeted aspects of web application security.

Usernames & Passwords

  • Use LDS Account for authentication wherever possible
  • Ensure that passwords meet Church policy requirements
  • Ensure the system does not have shared accounts (administrative or otherwise)
  • Ensure that accounts are locked after no more than 6 incorrect attempts
  • Publicly accessible applications should require new passwords on a periodic basis
  • Ensure that usernames do not default to known values (e.g., partial or full email addresses, first initial+last name)
  • Allow the user to specify a username and validate that it does not match the email address on record for the account
  • New accounts should default to no-privilege or low-privilege

Administrative Interfaces

Ensure the system does not have publicly accessible administrative interfaces (e.g., Apache Tomcat’s Manager, custom developed administrative interfaces).

Transport Encryption

Ensure that all authenticated portions of the application use TLS v1.2 or SSL v3. Ensure that the application infrastructure will not accept connections using older SSL or TLS versions with known security vulnerabilities. Do not pass usernames and passwords unencrypted.

Session Invalidation

Ensure that every authenticated page has a logout link which destroys all server side session state and client side cookies. Logout functionality should not require additional human intervention (e.g., closing browser window or clicking OK/Cancel).

Session Tokens

Use a session timeout period to automatically log out an inactive session. The inactivity threshold should be consistent with the value of the data or application it protects (shorter timeout periods are more secure). Session timeouts in excess of 60 minutes should not be used.

Avoid passing session tokens as part of the URL. This helps avoid leaking session credentials to third party sites via referrer headers and more targeted attacks. If session tokens are used on both unauthenticated and authenticated pages, be sure to refresh the users' session token as part of the login process. This helps avoid session fixation attacks.

Username Enumeration

Ensure that feedback from the authentication mechanism does not reveal whether or not a username is valid. This feedback may manifest itself in many forms including the following:

  • Error messages (e.g., instead of “Invalid username” use “Invalid username or password”)
  • Processing time (e.g., invalid user accounts receive error messages immediately but valid user accounts take longer for the error message to display)
  • Information rich URLs or URL redirections

Sensitive URL Portions

Do not expose session identifiers, username, or password in the URL or logs. Use POST requests for sensitive data or to perform sensitive value transactions.


Password Autocomplete

Do not implement “remember my password” mechanisms. Set the autocomplete property for all password fields to off.

Example: <INPUT TYPE=”password” AUTOCOMPLETE=”off”>


Appropriate authorization architectures will counter identity spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks. Proper authorization techniques require that users access only the information that is appropriate for their role.

Role Based Access Control

Implement strong, server-side Role Based Access Control (RBAC) mechanisms to prevent unauthorized access to sensitive data. After authentication, do not place user credentials (or similar) in the URL, in POST parameters, or in cookie parameters even if they have been encrypted. Ensure that users having privileged access are audited from time to time.

Least Privilege

Ensure that database connection accounts are granted the least amount of privileges necessary to the fewest number of resources (e.g., tables/columns) required for the task.

Audit Logging

Implement sufficient logging to detect abuse and misuse of data and privileges.

Restrict URL Access

Ensure that administrative or high privilege actions are protected using strong access control mechanisms. Do not rely strictly on hidden URLs or form fields. Authorization checks should occur for each protected page.

Parameter Tampering

Ensure that persons cannot gain access to restricted data by manipulating parameters in the URL, post parameters, or cookies.

Bad Example:

Wherever possible, avoid passing state information via GET and POST parameters, non-session cookies, etc in the first place. Use server-side sessions to manage/store important data.

Configuration Management

Proper patching and resource configuration is critical to the security of the entire application and affects all threat vectors.

Path Traversal on Object References

To protect against path traversal vulnerabilities, avoid exposing private object references (e.g., primary keys or filenames) to users whenever possible. When this is not possible, ensure that private object references are validated extensively with an “accept known good” approach. For example, the following code could be attacked using a string such as “../../../../etc/passwd%00” to gain unauthorized access to the /etc/passwd file (example from OWASP):

Vulnerable Example

<select name="language"><option value="fr">Français</option></select>
require_once ($_REQUEST['language’]."lang.php");

Directory Browsing

Ensure that web server directory browsing and relative paths (../) are not allowed.

Code Comments

Ensure that comments which reveal information about the application or infrastructure are removed from client-side, production code.

HTTP Methods

Disable the TRACE, OPTIONS, CONNECT, PUT and DELETE, and other custom/developer defined HTTP methods on web servers.

Secure Server Configuration

Ensure the public facing web servers and application servers have been securely configured based on an industry recognized standard.

Secure Database Configuration

Ensure the database servers have been securely configured based on an industry recognized standard.

Patch Management

Ensure that application server, development frameworks, and database components are regularly evaluated for new security vulnerabilities. Appropriate patches must be applied at least quarterly.

Data Protection

Sensitive data is often the target of an attacker’s attention and should be properly safeguarded throughout its lifecycle. Developers and application designers should consider data protection techniques anywhere information is stored, processed, or transmitted. Strong encryption should be used whenever sensitive data is stored or transmitted. Passwords and credit card numbers must be encrypted whenever stored (in a database or otherwise). Avoid displaying sensitive data to users; use data masking (applied server-side) wherever possible.

Secure Disposal

Ensure that documents and storage media containing Social Security Numbers (SSN), Personally Identifiable Information (PII), Protected Health Information (PHI), or other restricted information are securely disposed of. Documents should be cross-cut shredded prior to disposal. Computers, storage components, and removable storage media that have ever contained sensitive information should be disposed of only after using a secure media sanitization technique which overwrites all addressable locations with random, non-sensitive data. (See NIST SP800-88 for further details.)

Cached Data

Ensure that all pages that display sensitive information implement the ‘Cache-Control: no-store’ and ‘Cache-Control: no-cache’ HTTP directives. [1]

Cryptographic Algorithms

Use public algorithms which have been approved under FIPS 140-2 such as AES for symmetric encryption, RSA for for asymmetric encryption, and the SHA-2 family for data hashing.

Never write your own cryptographic algorithm. Use well-established public libraries instead.

Key Management

Ensure that private keys are encrypted and managed securely. Never transmit private keys over insecure channels. Email is not an acceptable method for private key exchange.

Error Reporting

Ensure that detailed error messages, debug information, stack traces, path information, and application vendors and versions are not displayed to the user. Replace default error pages with customized pages consistent with the application.


Session attacks primarily involve value tampering to enable identity spoofing and escalation of privilege.

Session IDs

Session IDs should be large, random numbers generated by an acceptable source (e.g., /dev/random or /dev/urandom on Linux systems), and have at least 128 bits of entropy.

Session Management

New session IDs must be created (or updated) after user authentication and destroyed on the server after session timeout or logout. User supplied session IDs must never be accepted. Session credentials and tokens must never be transmitted in the URL.

Good Example

    // Invalidate session after successful login
    // Create new session

Secure Cookies

Implement the ‘domain’, ‘path’, ‘secure’ and ‘HttpOnly’ cookie attributes for all cookies which contain session credentials. Never store other forms of sensitive information in cookies.

Authorization/Role Data

Ensure that authorization and role data is only stored server-side.

Automated Code Analysis

Running an automated code analysis tool can help uncover hidden security vulnerabilities or unconsidered attack vectors, and help individuals better identify issues during the development process.

.NET Framework Tools

  • CAT.NET is a Microsoft code analysis tool for .NET. It is only a Community Technology Preview (CTP) at this time; however, it does an excellent job of identifying hidden issues. It is available in 32 bit or 64 bit. This tool can run integrated with Visual Studio or run in stand-alone mode. CAT.NET will scan for the following issues:
    • Cross Site Scripting
    • SQL Injection
    • Process Command Injection
    • File Canonicalization
    • Exception Information
    • LDAP Injection
    • XPATH Injection
    • Redirection to User Controlled Site
  • FxCop is a Microsoft code analysis tool for .NET. It is primarily used to enforce specific coding practices; however, it contains a security rule-set that should be addressed in each .NET release. FxCop will scan for the following coding practices (listed here for the security benefit):
    • Library design
    • Globalization
    • Naming conventions
    • Performance
    • Interoperability and portability
    • Usage
    • Security (expanded here for convenience, full documentation here). Please see the full documentation for reference on how to correctly implement coding pattern.
      • Aptca methods should only call aptca methods
      • Aptca types should only extend aptca base types
      • Array fields should not be read only
      • Call GC.KeepAlive when using native resources
      • Catch non-CLSCompliant exceptions in general handlers
      • Do not declare read only mutable reference types
      • Do not indirectly expose methods with link demands
      • Method security should be a superset of type
      • Override link demands should be identical to base
      • Pointers should not be visible
      • Review declarative security on value types
      • Review deny and permit only usage
      • Review imperative security
      • Review sql queries for security vulnerabilities
      • Review suppress unmanaged code security usage
      • Review visible event handlers
      • Seal methods that satisfy private interfaces
      • Secure asserts
      • Secure GetObjectData overrides
      • Secure serialization constructors
      • Secured types should not expose fields
      • Security transparent assemblies should not contain security critical code
      • Security transparent code should not assert
      • Security transparent methods should not call non-public members
      • Specify marshaling for pinvoke string arguments
      • Static constructors should be private
      • Type link demands require inheritance demands
      • Wrap vulnerable finally clauses in outer try

C/C++ Tools

  • BinScope "is a Microsoft verification tool that analyzes binaries on a project-wide level to ensure that they have been built in compliance with Microsoft's Security Development Lifecycle (SDL) requirements and recommendations." It also "checks that SDL-required compiler/linker flags are being set, strong-named assemblies are in use, up-to-date build tools are in place, and the latest good ATL headers are being used. BinScope also reports on dangerous constructs that are prohibited by SDL."


These recommendations and examples represent proven practices for mitigating web application vulnerabilities and preventing attacks. Appropriate and consistent implementation will ensure that the Church adequately protects its resources and sensitive information. Building security into the application is the right way to do business and will enable technology to assist the Church as it spreads throughout the earth (Daniel 2: 44-45).

Appendix A: Terms and Definitions

Spoofing (identity) 
A spoofing attack describes a situation in which a person or program masquerades as another by falsifying data and gaining access.
Tampering with data 
“Data tampering involves the malicious modification of data.” [1]
“Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations.”[1]
Information disclosure 
“Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it.”[1]
Denial of Service 
“Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable.“[1]
Elevation of privilege 
“In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself....”[1]


  1. 1.0 1.1 1.2 1.3 1.4 Microsoft Developer Network. March 2010.

Appendix B: Additional Resources

  1. Open Web Application Security Project (OWASP)
  2. Microsoft Security Developer Center
  3. SANS (SysAdmin, Audit, Network, Security) Institute

Works Cited

CERT. (n.d.). Secure Coding. Retrieved 06 1, 2009, from Cert Website:

OWASP. (n.d.). SQL Injection Prevention Cheat Sheet. Retrieved May 29, 2009, from OWASP:

OWASP. (n.d.). Top 10 2007-Cross Site Scripting. Retrieved June 1, 2009, from

OWASP. (n.d.). Top 10 2007-Insecure Direct Object Reference. Retrieved May 29, 2009, from

The STRIDE Threat Model. (2010). Retrieved March 2010, from Microsoft Developer Network:


This article is based on the Web Application Security Requirements document, version 0.4, released 22 March 2010 by the ICS Security & Compliance Division.

This page was last modified on 21 June 2012, at 09:22.

Note: Content found in this wiki may not always reflect official Church information. See Terms of Use.