AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 6. Secure Application Development

10.8.6  Secure Application Development

10.8.6.1  (07-31-2007)
Purpose

  1. This manual provides policies and guidance to be used by IRS organizations to carry out their respective responsibilities in information systems security regarding secure application development. It provides guidance on the creation and modification of Commercial off the Shelf (COTS) and Government off-the-shelf (GOTS) program code and applications.

10.8.6.1.1  (07-31-2007)
Overview

  1. It is the policy of the IRS to protect its information resources and allow the use, access, and disclosure of information in accordance with applicable laws, policies, federal regulations, OMB Circulars, and Treasury Directives (TDs). All IT resources belonging to, or used by the IRS, shall be protected at a level commensurate with the risk and magnitude of harm that could result from loss, misuse, or unauthorized access to that IT resource.

  2. This policy delineates the security management structure, assigns responsibilities, and lays the foundation necessary to measure progress and compliance. Requirements in this policy are subdivided under three major security control areas: management, operational, and technical.

10.8.6.1.2  (07-31-2007)
Scope

  1. The provisions in this manual apply to all offices, business, operating, and functional units within the IRS, and are to be applied when IT is used to accomplish the IRS mission. This manual also applies to individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate IT systems containing IRS data.

  2. The guidance in this document is not intended to comprise a new process capability model or software development methodology. Instead, it is intended to provide information that will help the reader select and adapt, augment, or extend an existing capability model and development methodology in ways that will greatly increase the likelihood that the software produced will be not only correct, high quality, reliable, and reusable, but also secure. In addition, this Developer’s Guide provides some practical "best practices" for developers to apply throughout the System Development Life Cycle (SDLC), within the framework of whatever process and methodology they work within.

10.8.6.1.3  (07-31-2007)
Authority

  1. IRM 10.8.1, Information Technology (IT) Security Policy and Guidance, establishes the security program and the policy framework for the IRS. If there is a conflict with or variance from this IRM and IRM 10.8.1, IRM 10.8.1 shall take precedence.

10.8.6.1.4  (07-31-2007)
IRM Section Topics

  1. This manual contains information on the following topic areas:

    • General Policy

    • Management, Operational, and Technical Controls

    • Deviations;

    • Common Application Programming Flaws – Checklists (Exhibit 10.8.6-1);

    • Glossary (Exhibit 10.8.6-2);

    • References (Exhibit 10.8.6–3); and

10.8.6.2  (07-31-2007)
General Policy

  1. Recommended practices for Secure Application Development shall be implemented on all applicable platforms, in addition to the general requirements stated in this IRM and IRM 10.8.1.

  2. Programming language(s) in which an application component is written, shall not include known vulnerabilities (e.g., susceptibility to buffer overflow) that could make the application vulnerable to compromise or failure.

  3. Do not use unsafe application constructs. Developers shall not use C language constructs when there are C++ equivalents or replacements. For example, do not use the C functions malloc and free. Use new and delete instead. See IRS C ++ Programming Standards, Document Number 12384.

  4. Use effective safeguards and countermeasures (e.g., security wrappers, precompilers, application firewalls) which have been implemented during development and deployment to counteract known vulnerabilities

  5. Application(s) shall only use approved low-risk services, protocols, and technologies, unless there is a critical need for a higher-risk service, protocol, or technology.

  6. Application(s) shall have automated configuration tool(s) or script(s) that enables the administrator to set the parameters that govern the operation of the application’s security components and the characteristics of its security properties.

    1. The tool/script shall include a "feedback" capability that informs the administrator of possible security deficiencies in the configuration he/she has defined.

    2. For any application security component configuration, that cannot be automated by a tool or script; manual configuration procedures shall be documented, and training should be provided to administrators on how to perform those procedures.

  7. All non-standard, erroneous (i.e., syntax errors), and unnecessary tags shall be removed from Hypertext Markup Language (HTML) and Extensible Hypertext Markup Language (XHTML) code, that has been automatically generated by a web authoring tool.

    1. Tags that are browser-dependent (e.g., tags that are intended to optimize the code for a particular browser) shall also be removed.

  8. Program code and applications used for development purposes shall be run on separate physical hosts from production systems.

  9. Program code and applications shall not be used until they comply with this IRM.

10.8.6.2.1  (07-31-2007)
Roles and Responsibilities

  1. IRM 10.8.2, Information Technology Security Roles and Responsibilities, defines IRS-wide roles and responsibilities related to IRS information and computer security, and is the authoritative source for such information.

  2. The supplemental requirements provided below are specific to the implementation of IRS Secure Application Development. Refer to IRM 10.8.2 for additional information regarding organizational and individual responsibilities related to information and computer security.

10.8.6.2.1.1  (07-31-2007)
Information System Owner

  1. The Information System Owner is the agency official responsible for the overall procurement, development, integration, modification, and operation and maintenance of the information system as defined by IRM 10.8.2. At the IRS, the Information System Owner is the Business and Functional Unit Owner, see IRM 10.8.2 for Information System Roles and Responsibilities.

  2. In accordance with IRM 10.8.2, the Information System Owner shall ensure that development servers properly configured and managed in accordance with the requirements of this IRM.

  3. In addition, the Information System Owner shall have the following responsibilities:

    1. Work with Program Developer/Programmers to ensure proper configuration of application server software, on the operating system(s) are in accordance with this IRM.

    2. Advise the Security Specialist of any technical, operational, or security problems and recommended solutions.

  4. Information System Owner shall not have operating system Administrator privileges.

10.8.6.2.1.2  (07-31-2007)
Program Developer/Programmer

  1. In accordance with IRM 10.8.2, the Program Developer/Programmer shall be responsible for the development, test, and administration of application programs. See IRM 10.8.2 for Program Developer/Programmer Roles and Responsibilities.

10.8.6.2.1.3  (07-31-2007)
System Administrator (SA)

  1. In accordance with IRM 10.8.2 System Administrators (SAs) are technicians who design and operate IT systems. They are responsible for implementing technical security on computer systems and for being familiar with security technology that relates to their system. See IRM 10.8.2 for System Administrator Roles and Responsibilities.

  2. In accordance with IRM 10.8.2, SAs shall configure system parameters within the documented security standards of this IRM.

  3. System administrators shall install and manage application server software including development tools and libraries, software compilers, code builds, and middleware interfaces between servers and application servers and back-end storage media.

10.8.6.3  (07-31-2007)
Management Controls

  1. The IRS shall implement management security controls to mitigate risk of IT applications and electronic information loss in order to protect the organization's mission. See IRM 10.8.1 for general information on computer security management control requirements.

10.8.6.3.1  (07-31-2007)
System and Services Acquisition

  1. See IRM 10.8.1 for IT Security, System and Services Acquisition requirements.

10.8.6.3.1.1  (07-31-2007)
Developer Security Testing

  1. Establish and use appropriate security metrics during each security review/audit to measure the degree to which security criteria/requirements have or have not been satisfied.

  2. Ensure security testing is performed both on individual units/components and on the whole integrated application. A wide range of test techniques shall be combined in order to provide as broad and accurate a picture of the tested entity's security posture. This includes "white box" (source code based) and "black box" (binary based) tests of both individual units/components and of the integrated application as a whole.

  3. Misuse cases shall be developed and implemented (opposite of use case). The sole purpose of the Misuse case is to identify how a use case shall not behave. A misuse case shall capture the type of attacks that can be made on the system and how the system shall behave in such situations.

    • Note: This is a relatively new approach, but it will go a long way in addressing the security requirements of an application. A misuse case can also help prepare test cases purely to test the security strength of the system.

10.8.6.3.1.1.1  (07-31-2007)
Code Based Elements Requirements

  1. An application process shall remove temporary objects from memory or disk before it terminates.

  2. The application shall adequately validate user inputs before processing them.

  3. The application shall be tested for vulnerable buffer overflows.

  4. The application shall include an explicit error and exception handling capability. Application error and exception messages displayed to users shall not reveal information that could be utilized in a subsequent attack.

  5. An application failure shall not result in an insecure application or system state.

10.8.6.3.1.1.2  (07-31-2007)
Type Declaration and Type Checking

  1. Type Declaration and Type Checking shall declare types strictly and explicitly, including whether they should be signed or unsigned.

10.8.6.3.1.1.3  (07-31-2007)
Defenses Against Buffer Overflow

  1. Input Validation for Bounds Checking -C and C++ programmers shall write their programs to explicitly perform bounds checking, and must avoid using unsafe C/C++ calls and functions.

  2. Safe Alternatives to Dangerous Functions and Calls -Program Developer/Programmers shall specify realistic buffer sizes and implement the necessary input validations to ensure that input does not exceed those buffer sizes.

  3. Program Developer/Programmers shall ensure programs are free of overflow vulnerabilities.

  4. Disabling Stack Execution -Program Developer/Programmers shall avoid stack smashing vulnerabilities, by implementing non-executable stacks, which will prevent an attacker from being able to write and execute malicious code on the program stack.

10.8.6.3.1.1.4  (07-31-2007)
Environment Information

  1. Hardening procedures shall be defined and followed for systems.

  2. Only files and folders required for systems functionality shall be copied to the production folder(s).

  3. File upload(s) shall be are restricted, to ensure that files can only be uploaded into intended locations and to ensure the file size and type are appropriate considering the available resources.

  4. Virus scan shall be performed.

  5. Debug binaries shall not be used in production environments.

  6. The test environment shall mirror the intended production environment, in which the application will run.

  7. Test tools shall be used to support security test techniques.

  8. The application shall operate in most secure configuration of the operating system, database, framework, and middle software in accordance with application policy.

  9. The application shall not be designed or require the use of default configurations or otherwise insecure configurations of any developmental or non-developmental components, in the application itself or its environment.

  10. The application shall allow for the disabling or removing of default account names, passwords, etc., used in the application or its environment shall be changed.

10.8.6.3.1.1.5  (07-31-2007)
Secure Directory Access Control Configuration

  1. The operating system/framework access controls on the directories in which the application components are stored shall be configured to protect the application executable(s) from unauthorized access, modification, and deletion.

    1. The directories shall be configured to protect all sensitive application data, such as access control lists, security event logs, and other sensitive data used by the application (including data decrypted by the application before use)

    2. The directory configuration(s) shall also prevent the insertion of any file of any type (binary or text) by an entity that is not explicitly authorized to insert a file into the directory.

  2. All application and execution environment software executable(s) (both developmental and non-developmental), source code files, and documentation shall be placed under secure configuration management with strict access and version control.

    1. This procedure prevents any access inappropriate given the role of the person attempting the access and the life-cycle phase in which the attempt is made. For example, source code checked in prior to a code review should not be write-accessible after that; instead, if changes must be made, a new version of the code should be generated for the update (this will prevent a rogue developer from secretly inserting malicious logic into a code version that has already been approved by the reviewers).

  3. Every application process shall have a developer-defined time-out threshold. The threshold shall indicate the amount of real time during which that process can execute. If this threshold is reached by the executing process, the process shall stop running, clean up all resources (e.g., memory, cache) allocated to it by the host, and gracefully terminate.

  4. Network protocols and communication services used by the application, that default to unlimited connections shall be re-configured to allow only a finite number of simultaneous connections.

  5. All security components in the execution environment (e.g., access control systems, cryptographic components) with which the application interacts, such as procedure calls, system calls, Application Programming Interface (API), or networking protocols, shall be configured based on least privilege and least functionality principles in accordance with IRM 10.8.1.

  6. The application’s host operating system shall be configured to limit the processing resources (memory and processor time) allotted to the application’s processes.

  7. The application’s exception handling service shall be configured to recognize all operating system imposed resource limitations.

  8. All execution environment components (including host file system, databases, and other data stores) that store application executable, data, configuration, security, or include files shall be configured to prevent access to those files by any role other than the role assigned to the application itself and the role(s) assigned to the application’s administrator(s). All other roles, including user roles, shall be denied direct access to the resources.

  9. The application host’s file system shall be configured to isolate, through partitioning into separate execution domains, all security processes within the application itself and all security processes invoked by the application in other execution environment components on the same physical host.

    1. This partitioning shall be configured to ensure that the application’s security processes are kept strictly separate from its non-security processes and the application’s non-security processes are kept strictly separate from security processes in its execution environment.

    2. The application shall not be designed in a way that requires it to run both security and non-security processes in the same execution domain.

  10. Non-developmental software components in the application or its execution environment shall be the latest versions, with all security patches applied.

  11. All graphic editors, office productivity software (e.g., word processors, spreadsheet programs), etc., shall be removed from the application’s code base and execution environment before operational deployment.

  12. All default accounts (e.g., "nobody," "Administrator" ) in non-developmental server components shall be disabled or renamed unless the application absolutely cannot run without those specific account names.

  13. All default accounts shall have their default passwords changed upon installation, in accordance with IRM 10.8.1.

  14. Access controls on all directories in which system libraries, privileged programs, configuration files, and security data owned or used by the application shall be configured to prevent read, write, or delete access by unauthorized entities or processes.

  15. Access to sensitive directories should be configured as follows:

    1. Executable(s) on server:
      1. execute, write, delete access by administrator role,
      2. execute-only access by roles assigned to authorized server application components,
      3. no access by user role (user access must be gained through client or proxy agent);

    2. Executable(s) on the client:
      1. execute, write, delete access by user and administrator roles (to enable patching/updating);
      2. execute-only access by roles assigned to authorized client application components;

    3. Configuration and security files on server:
      1. read, write, delete access by administrator role;
      2. read-only access by roles assigned to authorized server application components,
      3. no access by user role;

    4. Configuration and security files on client:
      1. read, write, delete access by user and administrator roles (to enable updates);
      2. read-only access by role assigned to authorized client application components.

  16. All web server and application server default directories and files shall be renamed, unless the application absolutely cannot run without those specific directory/file names. Any directories or files that retain their default names shall have their access controls configured as restrictively as possible.

  17. Web servers and application servers that enable automatic directory indexing shall have that feature turned off before operational deployment.

  18. E-mail service shall be disabled.

  19. Backup strategies shall be captured in the design phase to ensure confidentiality, integrity, and availability of data. For example, capture frequency of data backup media and access privileges to the backup and whether the backup be encrypted.

10.8.6.3.2  (07-31-2007)
Documentation

  1. Security features, service levels, and management requirements shall be specified and documented in accordance with IRM 10.8.1.

  2. Security requirements shall be included in the overall application requirements specification and traceability matrix. A separate security requirements specification and matrix shall not be generated.

  3. The results of the application's security integration tests shall be provided as input to the security risk assessment of the application required before it can be deployed.

  4. After moving into production, the application's security posture shall be periodically reviewed to ensure that new vulnerabilities have not emerged. Specifically, impact assessments should be performed every time a significant change is made to the application itself or its execution environment, such as (but not limited to): substitution of a different product, application of a patch, change of configuration parameters, etc.

10.8.6.4  (07-31-2007)
Operational Controls

  1. The IRS shall implement operational security controls, which are primarily implemented and executed by personnel for each information system. See IRM 10.8.1 for general information and computer security operational control requirements.

10.8.6.4.1  (07-31-2007)
System and Information Integrity

  1. See IRM 10.8.1 for IT Security, System and Information Integrity requirements.

10.8.6.4.1.1  (07-31-2007)
Input Validation

  1. HTML encoding shall be used when displaying text data from external sources in a browser, to prevent Cross-site scripting (XSS).

  2. Data from external sources shall be properly validated/manipulated before embedded in Structured Query Language (SQL) statements in order to prevent SQL injections.

  3. Ensure large number input shall not cause unexpected results.

    1. Numeric input shall be properly validated to ensure that large numbers will not be used in unexpected ways. For example, 5 digit numbers can be much higher than 99999 when entered with an exponent e.g., 99e99.

  4. Extensible Markup Language(XML) shall be validated against a Document Type Definition (DTD) or XML schema.

    1. When parsing XML, the document shall be validated against a DTD or XML schema to prevent attackers from supplying malicious input.

    2. Ensure dots and slashes or other special characters used in user entered paths shall not cause unexpected results.

    3. Ensure server side code shall not rely on the client to perform input validation. The server application shall always validate any input it receives, regardless of whether that input was previously validated by a client.

    4. Implement and enforce size restrictions on XML message(s); necessary to prevent memory and CPU exhaustion of the underlying system.

    5. If a process in a medium or high robustness application cannot validate the input it has received from an external entity, that process shall:
      1. reject the input;
      2. return an error message to the entity that sent the input, reporting that the current transaction/session is being terminated due to an input error; and
      3. terminate the transaction/session.

    6. Any application function that accesses a memory buffer or array (e.g., to write data to that memory location), shall first check the size of the buffer or bounds of the array boundaries. If the function intends to write data to the buffer/array, and the size of the data exceeds the size of the buffer/array, the function should either reject (not write) the data or truncate the data to the size of the buffer/array before writing it.

    7. The application shall rejects any input containing HTML, XHTML, or XML received from an untrusted source (user or other entity).

    8. An application process shall never accept, use, act upon, or copy to a database any input (data, parameter, or argument) it receives from an external entity or library without first validating the correctness of the properties of the received input. The process should suspend processing of any new input received during the same session, until it completes validation of the input it has already received.

  5. Input properties to be validated:

    1. The following properties of input received by an application process shall be verified by that process before that process accepts/uses/acts upon the input:
      1. Input formatted as expected;
      2. Input contains only correct syntax;
      3. Character strings of values supplied for variables are valid;
      4. Size (in bytes or characters) of input falls within the expected bounds;
      5. Numeric input falls within an acceptable range of values;
      6. Input contains no numeric values that could cause a routine or calculation in the application to divide any number by zero;
      7. Input contains no parameters whose source cannot be validated as matching the identity of the input source as expressed in the source’s session token;
      8. Input cannot induce a buffer overflow;
      9. Input contains no HTML, XHTML, or XML expressions;
      10. Input contains no special characters, metacode, or metacharacters that have not been encoded (if encoding is permitted);
      11. Input contains no direct queries or command strings in Structured Query Language (SQL) or any other procedural language;
      12. Input contains no truncated pathname references;
      13. Input contains no scripting language expressions (e.g., Perl, JavaScript); and
      14. Input contains no other unexpected or executable content or invalid values.

    2. The application shall inform the user of the expected, acceptable characteristics of all data strings to be input by the user, e.g., via an HTML or XHTML form.

    3. A server application never rely on the client to perform input validation. The server application should always validate any input it receives, regardless of whether that input was previously validated by the client.

    4. The application shall not act upon instructions or inputs stored in files that originate from untrusted sources without first validating the instructions/input. The application should trust only files that:
      1. are controlled solely by trusted users;
      2. cannot be written to/modified by untrusted users; and
      3. do not reside in directories that can be write-accessed by untrusted users.

    5. Input validation of data that contains active content, such as mobile code, shall not cause that active content to execute.

    6. The application shall validate all directory pathnames, Uniform Resource Locators (URL)s, and Uniform Resource Identifiers (URI)s entered by users in order to flag:
      1. unrecognized or unsafe extensions (e.g., .exe);
      2. untrusted domains or directories which the application does allow clients to link to or download from (e.g., internet domain names ending in ".ru" , ".com" ). The application’s pathname validation function should be configured judiciously, balancing the desire to prevent downloads of potentially malicious files into the application environment against the users’ need to access certain types of files, including those with filename extensions such as .doc, .xls, .ppt, .rtf, .mpp, .vsd, .ps, .exe, and other extensions associated with files created by applications for which browser plugins are not readily available. The portal/server application should not allow any client to link to or download files from a directory or network location whose pathname contains a dubious domain name, root directory name, or filename extension. The server application should be configured to block dubious pathnames typed in by users or selected via saved bookmarks in order to prevent clients from linking to those untrusted sites and downloading potentially malicious files from them.

    7. The application shall not make use of HTTP (unsecure) requests, except only when necessary and no other options are available. A risk assessment must address this issue.

    8. The application shall not use hidden fields for sensitive or critical data.

    9. The application shall validate the URL in any redirects accepted by the application.

    10. The application canonicalize all user input (including all parts of the HTTPS Request - headers, query string, cookies, form fields, and hidden fields) prior to applying validation.

  6. File upload(s) shall be restricted.

    1. The following file upload mechanism shall be enforced:
      1. Maximum File Size
      2. Restrict Files to specific types
      3. Does not allow to specify target location
      4. Check file name to see if well formed
      5. Virus check uploaded file
      6. Ensure that the target location for uploaded files is outside the web/app server path.

    2. The application shall not execute user input.

    3. The application shall not shall allow user data to modify the intent of the database query.

    4. A server application’s or web service’s input validation processes and exception handling service should be able to:
      1. detect, recognize, and resist flood attacks;
      2. identify the attack source; and
      3. ensure that the application gracefully terminates all processing of input received from that source.

10.8.6.4.1.2  (07-31-2007)
Range and Type Errors

  1. Buffer overflows shall be prevented (e.g., Keeping up with the latest bug reports for web and application server products and other products in the infrastructure.)

  2. The latest patches shall be applied in accordance with IRM 10.8.1 and IRM 10.8.50 Service-wide Patch Management.

  3. Ensure Web sites are scanned for buffer overflow flaws in the used server products and custom web applications.

    1. For the custom application code, all the code that accepts input from users shall be reviewed to ensure it provides appropriate input size checking.,

    2. Functions that do not check the size of the destination buffers, such as gets(), strcpy(), strcat(), printf() shall be avoided.

  4. Ensure that all format string functions are passed as static string which cannot be controlled by the user and that the proper number of arguments are always sent to that function as well. Do not use the %n operator in format strings.

  5. Appropriate string management functions shall be used to prevent buffer overflows caused by conversion between multi-byte and Unicode strings.

  6. A language or compiler that performs automatic bounds checking shall be used to prevent stack overflows.

  7. An application process shall never accept or pass data blocks of invalid lengths, streams, or elements.

  8. The application shall never write input data to an allocated memory buffer or cache if the buffer cannot first be validated to ensure that it is larger (in bytes) than the input data to be written.

  9. Every data buffer allocated in the application shall be larger than the largest data element expected to be written to that buffer.

  10. Unless the application can be guaranteed to perform correct input validation with buffer truncation, an absolute value or constant shall not be used to specify the size of any buffer used by that application.

  11. The application, regardless of the programming language in which it is written, shall call only library routines and functions that are not known to be:

    1. susceptible to buffer overflows, or

    2. vulnerable to other threats and attacks.

10.8.6.4.1.3  (07-31-2007)
Error Handling

  1. Applications shall contain an exception handling service.

    1. Regardless of the cause of the exception, the exception handling service should never place the application (including its executable(s) and data/resources) into an insecure state when attempting to handle the exception.

  2. The application/component shall not enter into an insecure state when the resource exhaustion occurs

  3. Error messages shall not reveal more details than necessary about the application.

  4. Web applications shall have a default error page defined (at least) for 404 errors and 500 errors to prevent attackers from mining information from the application container's built-in error response.

  5. Error messages returned to users shall not contain any information from which an attacker could infer the type or cause of the error, the configuration of any application or environment component, the host directory structure, the application's processing state or residual vulnerabilities, or any other information that might be useful to an attacker.

    1. If it provides any information at all indicating the type of error, the error message shall include a difficult-to-decipher reference to a more detailed error message in the offline application documentation. The error message shall never include the reference to an informative error message associated with any commonly used commercial product.

  6. The application’s exception handling service shall provide the administrator with several configurable options for how the mechanisms will respond to a flagged exception. In addition, the application’s exception handling service shall be initially configured with the safest actions set as defaults. Resetting the exception handling service to perform its less safe options should require explicit re-configuration by the administrator.

    1. The set of configuration options for exception handling shall include, at a minimum:
      1. Termination of the whole application;
      2. Termination of the process in which the exception occurred; and
      3. Termination of processing which the exception occurred plus termination of other administrator-selected process(es).

  7. The application’s exception handling service shall (on an exception by exception basis), enable the administrator to configure one or more of the following pre-termination actions to be performed by the exception handling service before it terminates a process or the entire application:

    1. Notify user that termination is about to occur;

    2. Notify administrator that termination is about to occur; and

    3. Perform automatic checkpoint restart (in transaction-oriented and database applications).

  8. The exception handling service shall be able to detect failure conditions in all execution environment components with which the application inter-operates or communicates. The exception handling service shall ensure that a failure in any environment component will not cause the application to fail in an insecure state, nor cause any of the application’s executable or data files to become vulnerable to compromise.

    1. When the exception handling service detects an environment component failure it shall:
      1. notify the administrator that the component has failed; and
      2. gracefully terminate all application processes that depend on/interact with that component (or terminate the whole application), so as to ensure that the application and its resources remain in a secure state.

  9. If the mission criticality of the application requires it to continue operating after the exception handling service has detected a flagged exception condition or the unavailability of a critical resource, the application shall be designed to adjust its operation in a way that will enable it to continue processing in a restricted or degraded way (e.g., reducing resources, reducing functionality). It will continue operating until the exception/resource unavailability persists past a programmer-defined threshold, or otherwise deteriorates to a degree beyond which even degraded operation is no longer possible. Once the application reaches the point where it can no longer operate at all, the exception handling service should perform an orderly shut down of the application that preserves the secure state of the application, its data and resources.

  10. When an application process fails, the application’s exception handling service shall immediately notify the administrator of the failure. The exception handling service shall enable the administrator to pre-configure the way in which he/she will receive the notification, (at a minimum) via E-mail, console alarm, and pager alert.

  11. The application’s exception handling service checks all error conditions returned by external system calls, but shall not consume excessive resources trying to handle overly complex errors or too many simultaneous errors.

  12. As part of its startup process after a failure, the application shall perform self-diagnostic consistency checks before restoring full operation to ensure that the following application properties and resources were not corrupted by the failure:

    1. call arguments,

    2. basic state assumptions,

    3. access control permissions,

    4. security parameters,

    5. other critical parameters, data, and files.

  13. Recovery after a failure shall not cause or allow the application to re-initialize into an insecure state.

  14. A server application or web service shall enable the administrator to set a threshold indicating the amount of time the server will wait for another entity to respond to output (data, web page) sent to it by the application. If the threshold expires, the server shall release its session lock for the session with the non-responding entity.

  15. Before attempting to read or write to any file or directory, a server application/web service, first verify that the file/directory is present at its expected location in the host file system. If the file/directory is missing, the application/service shall:

    1. return an error message informing the user or requestor that access to the requested file/directory is not possible; and

    2. gracefully terminate the process that received the request for access to the missing file/directory.

  16. The application shall not contain design or implementation errors or flaws that could cause any of its executing processes to erroneously delete or overwrite data, incorrectly assign or change access permissions, or otherwise impede data availability.

  17. Transaction processing, database, and other transaction-oriented applications (including COTS and OSS applications) shall include a checkpoint restart mechanism that enables the application to ensure that, when a transaction recovers from an environmental (e.g., operating system, hardware) failure, it resumes processing at exactly the point in processing it had reached before the application failed.

    1. Checkpoint restart shall also ensure that the data processed by the transaction is rolled back to the state/version that existed at the time the transaction failed.

  18. Server applications, web services, and clients shall not contain design or coding errors or flaws that could be exploited by a malicious entity to launch a successful denial of service (DoS) attack against the application.

  19. Changes in the application’s processing state, including changes induced by errors or exceptions during initialization, abort, or failure, shall not cause the application to enter an insecure state.

  20. The application’s exception handling service shall be configurable by the administrator to recognize all resource allocation limits imposed on the application by the host operating system; as to effectively handle exceptions caused by any attempt by the application to exceed its allocated resources.

  21. The application shall be able to detect failure conditions in the execution environment components with which it interfaces and should discontinue its attempts to access or communicate with failed components.

  22. The application shall check all exceptions and error codes from calls made to services and handle them appropriately.

  23. Error messages shall not reveal implementation details (e.g., COTS components).

  24. Attacks shall not be logged without additional protection or sanitization, as it can be executed while viewing the logs.

  25. Security events shall be logged to separate files then error logs.

  26. The application shall sanitize user information before using it in log messages.

  27. In most cases, a standard error page shall be displayed in any error situation. The application shall trap all the system errors (such as missing configuration file, ODBC error, database not working, etc.) or application errors (such as invalid username/password) and redirect them to one standard error page. Ideally, the list of possible error situations and the corresponding error messages shall be identified and a generic error message for unknown or unidentified errors with no technical information shall be displayed to the user. Also, an entry in the logs shall be created with the time stamp and other relevant information.

10.8.6.4.1.4  (07-31-2007)
Synchronization and Timing

  1. An application that runs on a single-processor host shall be designed to be single-tasking and should not initiate a new task until the previous task has finished executing.

  2. In an application written to run on a multiprocessor host, multitasking and multithreading shall not create conflicts among tasks/threads in their usage of system resources. For example, the memory and disk addresses for all tasks and threads should be synchronized to prevent such resource usage conflicts.

  3. The application is designed and implemented to avoid timing and sequence errors such as race conditions, incorrect synchronization, and deadlocks. If the application is transaction-oriented (e.g., a database application), all transactions shall be designed to be atomic, and multiphase commits and hierarchical locking strategies shall be implemented to achieve asynchronous consistency within the application’s functions.

  4. If the application updates a database, all database updates shall be implemented as discrete transactions.

  5. Security testing of code units and individual components shall be performed to detect any implementation-specific vulnerabilities, such as race conditions, lack of randomness in cryptographic modules, buffer overflows, etc.

  6. An application that is used to display the content of a file or database shall also enable the time/date stamp on that file/data object to be displayed.

  7. An application that is used to create, update, or modify files or database entries shall apply a time/date stamp to every file/database entry at the time of creation, and again each time that file/entry is updated/modified.

10.8.6.4.1.5  (07-31-2007)
Sensitive Data Protection

  1. External initialization of variables critical for system's functionality/stability shall not be allowed.

  2. For applications using SSL (HTTPS), users shall not be able to access the same page with the same content using the equivalent HTTP URL. Removing the "S" from HTTPS shall not allow to bypass SSL.

  3. A web application shall not transmit confidential data using HTTPS GET transactions. The HTTPS POST transactions sent over an SSL/TLS-encrypted connection can be used instead.

  4. Sensitive data shall not be stored under Web Root.

  5. Only non-persistent, encrypted cookies shall be used for storage and transmission of confidential data. Persistent cookies (even when encrypted) and unencrypted cookies (even when non-persistent) shall never be used for this purpose.

  6. The application shall not respond to an invalid or unexpected input by revealing the file system/web server directory structure.

    1. If a user inputs an invalid, truncated, or relative file system pathname, URL, or URI, the application shall not respond by listing the contents stored in the file system/web server directory at the same level as the invalid pathname, and must not otherwise reveal the file system/web server directory structure. Instead, the application should redirect the user to a default "home" or "index" page. Before redirecting the user to a default page, the application may display an uninformative error message.

  7. The system shall be configured to save the encrypted data in a different directory from any unencrypted data it writes/stores.

  8. Client application(s) shall not store confidential data in any form, including hidden fields in HTML and XHTML forms.

    1. All confidential data shall be stored on the server side and retrieved and forwarded to the client by the server on an as-required basis.

  9. All application administrative or privileged user data shall transmitted over a secure interface.

    1. Even if other data is sent to/from the application via insecure (e.g., unencrypted) interfaces, all administrative data shall be sent to/from the application over a secure interface. The same is true of interfaces used for any other privileged role.

  10. All authentication data shall be encrypted before transmission.

    1. User-names and clear text authentication and authorization credentials, including passwords, Security Assertion Markup Language (SAML) assertions, password hints, session tokens/authentication cookies, etc., are encrypted before being transmitted between the user's system and the application. All sensitive information sent during an authentication exchange, including session tokens sent in the background, shall be encrypted before transmission.

  11. Secrets, such as passwords, SAML assertions, and sensitive information about the application itself, (e.g., known vulnerabilities, hidden file locations) shall not be stored in the application's source code.

  12. Authentication credentials/CSPs used by the application’s authentication service shall not be hard-coded into any web pages, scripts, programmable function keys, other with user-viewable source code.

    1. If the application contains any web pages, scripts, programmable function keys, or other components with user-viewable source code, the credentials/CSPs used by the application’s authentication service shall not be hard-coded into those components. Furthermore, the application shall not map any credential/CSP to a component with user-viewable source code.

  13. User-viewable source code shall not contain full pathnames.

    1. Application components with user-viewable source code, and application error messages, shall not contain any full pathnames (e.g., URLs or URIs). Pathnames in user-viewable source code files should be relative, so they can be modified without having to rewrite the user-viewable source code. Error messages should not contain pathnames.

  14. The application shall not include any confidential data in any notification, error message, or redirect message it displays or returns to users.

  15. All sensitive information that could be exploited by attackers is removed from the application’s user-viewable source code, including from code comments. All such information shall be stored in a separate file on the configuration management server, and should not be included in the user-viewable source code file on the deployed application’s host.

  16. Connection strings and Database (DB) shall not be stored in clear text in configuration files. Encryption shall be used and property/config files shall be protected with strict Access Control List (ACL)s.

  17. Sensitive information shall not be stored anywhere in response including cookies, hidden fields, URL, or headers.

  18. The clear-text passwords shall not be hard coded in the source code.

  19. The application is designed to prevent exposure/disclosure of any data it receives over a secure connection or in encrypted form.

  20. Sensitive information transmitted by the application to another entity shall be sent via a secure connection.

  21. All cryptographic algorithms and functions used in the application shall be Federal Information Processing Standards (FIPS) 140-2 (or later) compliant.

  22. If the application uses encryption as an access control method to prevent unauthorized access to data written by the application, the application shall be configured to save the encrypted data in a different directory from any unencrypted data it writes/stores (if any). In addition, the application’s host file system access controls must be configured to ensure strict separation between the directory containing the application’s encrypted data and the directory containing the application’s unencrypted data.

  23. A client application shall not store any confidential data in any form, including in hidden fields in HTML and XHTML forms. All confidential data should be stored on a server, and retrieved and forwarded to the client by the server on an as-needed basis.

  24. A server application/web service shall never return to the client any data other than or in addition to the data explicitly requested by the user/proxy agent.

  25. The application shall not return confidential or high-integrity information in response to a request or other input received from an untrustworthy entity.

  26. A web service that uses XML and Simple Object Access Protocol (SOAP) shall use standard WS-Security and XML Digital Signature protocols to sign SOAP and XML messages and documents.

  27. The application shall not store in hidden HTML or XHTML form fields on the client any high integrity data or parameter data describing any HTML/XHTML form fields. Instead, such data should always be stored on the server.

    1. The source of any update to low-integrity and non-confidential data stored in a hidden HTML/XHTML form field on the client should be validated before the update is allo