Section_J-Section_C.8_IRS_Application_Development_TPCS-extract-20160916-V1.pdf

IRS Enterprise Portals Program

Internal Revenue Service

Solicitation Number: TIRNO-16-R-00026 IRS Integrated Enterprise Portal 1.5 (IEP 1.5)

IRS Enterprise Portals Program IRS Application Development Third Party Coding Standards

Version #: 2.0 Date: 12/10/14

Section J- Attachment C.8

Table of Contents

1.0 INTRODUCTION

1.1 Purpose

1.2 Objectives

2.0 ENVIRONMENT STRUCTURE

2.1 Present Application Infrastructure

2.2 Future Application Infrastructure

2.3 Application Technology

2.4 N-Tier Approach

2.5 Server Sessions

2.6 OpenText CMS

2.7 JBOSS Application Server

2.8 Database

2.9 Apache Web Server

3.0 SECURE CODING

3.1 Server-Side Validation

3.2 Request Parameters

3.3 Parameterized Java SQL Queries

3.4 Log Spoofing

3.5 HTML

3.6 Exception Handling

3.7 Dead Code

3.8 Race Conditions

3.9 System Calls

3.10 Site Exit Disclaimer

4.0 DEPLOYMENT

4.1 Ant and Make

4.2 Compiler Warnings

4.3 WAR File

4.4 Context Path

4.5 Database Applications

4.6 Session Dependency

4.7 Session Cookies

5.0 COMMON AND COMMON NAVIGATION

6.0 GOOGLE ANALYTICS

6.1 Java Script Insert to the IRS.gov Website

6.2 Sample URL Generated with Parameter Names and Values ........................... Error! Bookmark not defined.

6.3 IRS.gov Website Traffic Tracking URL ............................................................. Error! Bookmark not defined.

7.0 GENERAL APPLICATION PORTING MODIFICATIONS

7.1 Middleware compliance

7.2 Code Modifications

8.0 REFERENCES

9.0 REVISION HISTORY

IRS Enterprise Portals

1.0 Introduction

1.1 Purpose

This document is intended to define the new IRS Portals environment for third party developers of IRS.gov applications. Third party developers of applications must adhere to the minimum system and middleware requirements to operate applications within the IRS Portals environment. This document provides general coding standards and best practices for application development to assist third party developers in developing secure applications for the IRS Portals environment. In addition, third party developers will also need to adhere to the IRS style guide when developing applications for the IRS Portals environment. The secure coding section is informed by secure development standards from OWASP and WASC, as well as NIST 800-64, 800-37, and 800-53.

1.2 Objectives

The objectives of this document are:

Provide environment structure overview

Provide standards for basic security considerations

Provide a guideline for deployment requirements

Additional standards for Java Coding, UI Style Guides, Security, Deployment Descriptors, HTTP Error Handling & Logging are located in section 5(References)

2.0 Environment Structure

2.1 Legacy PUP Application Infrastructure

The current IRS PUP application infrastructure operates on a Solaris SPARC architecture platform. The middleware is comprised of Oracle database, Oracle Weblogic, Oracle Java System Web server, Vignette Content Management, Vignette Application Portal, and Autonomy Ultraseek search.

2.2 IEP PUP Application Infrastructure

The IRS PUP application infrastructure is designed to be vendor agnostic. The operating systems are split between Microsoft Windows and Red Hat Enterprise Linux x64 architecture platform. The middleware will be comprised of Microsoft SQL server database, Red Hat Enterprise JBOSS, Apache web server, OpenText Content Management System, OpenText Portal, and Google Search Appliance.

Below is a high level visual summary of the migration from the present to future technology platform.

Applications on the PUP are deployed in a farm, and share the same application servers. Performance testing is required for each application to confirm it will not negatively impact the other applications on the shared infrastructure.

For all third party applications deployed to the PUP infrastructure, the MSP is required to perform the following tests for each iteration of the .war file. Results will be provided to the business.

Browser Testing

Section 508 Testing

Look and Feel Standards Testing

W3C HTML 4.01 Coding Standards Validation

P3P Testing

Reporting Javascript Tag Validation

The following are the current software versions:

Vendor/Source Software Version

RedHat RHEL 5.10

Microsoft SQL Server 2008 R2

RedHat JBOSS 5.0.1

Apache Software Foundation Apache 2.2.3

OpenText Web Experience Management 8.1

SpringSource Grails 1.3.7

Google Search 7.2.0.G.252

Google Analytics N/A

Intelliegent Converts Software OraDump to MSSQL 4.1

Oracle Java 1.6.0 update 60

Apache ANT 1.8.1

2.3 Application Technology

The following technologies were identified to meet the goals of quicker delivery, maintaining high quality, and increasing reuse. The technologies below have been identified for developing new applications on the IRS Portals environment. The table highlights the major technology frameworks or solutions to meet the IRS goals in the new platform. The list below is not a complete list of technologies which could be leveraged in the new environment, however as new applications are presented to MSP for integration into the IRS.gov infrastructure, MSP will continue to analyze and determine the most applicable technology suited to meet the application needs for the IRS.

Technology Definition Optimal Use

Grails Is a dynamic full stack framework building on established Java technology to reduce the complexity of building web applications

Is a high productivity framework following the coding by convention paradigm

Uses Java technologies in conjunction with Spring and Hibernate

Consistent framework for persistence, views, and controllers for applications

Rapid development for creating prototype applications quickly

Search Powerful search index coupled with providing relevant information by allowing users to search as they already do through the Internet

Google Search

Use the power of the Google search engine to provide results from database results

Lightweight location based lookup and integrate with Google Maps (e.g. office locator, e-File provider search)

Custom Search

Grails to complete complex searches which require application logic

OpenText Application Portal / Portlets/Builder

Creates websites that delivery customer centric web experiences

Used for generating sites for users to customize commonly used features

Has the ability to pull information from multiple sources of data into a single organized page

2.4 N-Tier Approach

IRS.gov is designed with N-Tier Architecture with applications consisting of presentation, business and data access layers or tiers. The presentation layer interacts with the user through GUIs (Graphic User Interfaces) and with the application and the application server. The presentation tier uses a web browser for creating a request. In addition to initiating the request, the web browser also receives and displays code in dynamic HTML (Hypertext Markup Language). The business tier performs validation and processes the necessary business rules.

A database stores the data received from the web tier and provides data to the application server.

The data layer consists of the components to interact with the database. Additional processing of the data can be required and is done by Backend Servers and may interact with the database.

2.5 Server Sessions

A session object is created on the application server in a Java Server Page. The object is stored on the application server and a unique identifier called a session ID is assigned to it. The session object and session ID are handled by a session manager on the application server. Each session ID assigned by the application server has zero or more key/value pairs tied to it. The values are objects that you place in the session. Assign each of those objects a name, and each name must have an object with it because a null is not allowed.

2.6 OpenText CMS

OpenText CMS (Content Management System) is used by IRS.gov for Presentation layer objects.

Web pages are stored in a database and managed by CMS. CMS provides a way to create, edit, manage and publish content to Web sites.

2.7 JBOSS Application Server

The current application server is JBOSS 5.0. The JBOSS server is clustered and runs on a Red Hat Enterprise Linux server. Server environments include; Production, User Acceptance Testing, Performance Testing, System Testing (QA), and Development. Production servers run in two data center locations.

2.8 Database

MS SQL Server 2008 R2 database is used to manage data using different schema’s for each application. Each schema contains various objects for storing and retrieving data according to application requirements.

2.9 Apache Web Server

Apache 2.2.3 Web Server is the HTTP server used by IRS.gov applications. The Apache Web Server is a multi-process, multi-threaded, secure web server built on industry standards.

Requests are initially sent to the Apache web server then sent to the JBOSS server for processing.

2.10 Akamai Caching

The Akamai caching service is used by the PUP to cache all managed content and several applications. Development of an application to take advantage of kamai caching can be accomplished, with the primary focus to be on unique URLs for each page / set of results, possibly using parameters in the URL. Note that these parameters must be securely coded.

Examples of applications which use kamai caching are the general IRS.gov Search results and the Forms and Publications List (https://apps.irs.gov/app/picklist/list/formsPublications.html). The FATCA FFI Lookup application also uses caching for the download files made available through the application due to size.

Portal (OpenText)

MS SQL Server

Application

Database

JBoss Backend

Server

Apache

MS SQL Server

CMS

Database

IRS.gov High Level Environment

User

Request

3.0 Secure Coding

Note that it is the responsibity of the application owner to have the source code reviewed and approved by IRS cyber security prior to delivery to MSP for testing and deployment

3.1 Server-Side Validation

Input validated by client-side code should never be trusted as it can be easily bypassed. All input must be validated on the server side. The preferred method of input validation is verifying against a white-list of accepted values or characters. In the case that a white-list is not practical for the given field, a blacklist of invalid values and characters should be defined and checked against. If a white-list or a blacklist is not used, justification must be provided to and approved by the IRS Application Security team.

https://apps.irs.gov/app/picklist/list/formsPublications.html

3.2 Request Parameters

All http GET and POST parameters must be sanitized before being used by the application.

When possible, white-list validation of accepted values/characters should be the preferred method of sanitization. Otherwise, input must validate against a blacklist of characters including (but not limited to) angle brackets (< >) and double quote (“) characters to prevent cross-site scripting attacks. If a white-list or a blacklist is not used, justification must be provided to and approved by the Security team.

3.3 Parameterized Java SQL Queries

When using Java to explicitly constructing SQL queries, always use the Prepared Statement type rather than Statement.

All query values must be set as a parameter. This will automatically take care of escaping special/malicious characters and prevent SQL injection.

Example:

String company = request.getParameter (“COMPANY”);

int profit = Integer.parseInt(request.getParameter (“PROFIT”));

// bad way

Statement stmt = “UPDATE COMPANIES SET PROFIT = “

+ profit + “WHERE NAME = “+ company;

// good way

PreparedStatement pStmt = “UPDATE COMPANIES SET PROFIT =? “

+ “WHERE NAME =?”

pStmt.setInt(1, profit);

pStmt.setString(2, company);

3.4 Log Spoofing

Do not allow unsanitized user input to be logged. Strip the user input of any carriage return or newline characters to prevent user input from clearing the current line in the log or creating a new log entry.

Example:

String userInput = request.getParameter (“USER_INPUT”);

try {

/* do something */

} catch (SomeException se) {

String sanitizedInput = userInput.replaceAll(“\n|\r”,“”);

logger.error (“Failed on userInput = “+ sanitizedInput);

3.5 HTML

Prefer JSP comments to HTML. IRS.gov HTML pages are all interpreted as JSPs so there is no issue with using JSP comments

Do not use HIDDEN input fields for any sensitive or trusted data

Avoid hardcoded domains when specifying resource locations. Never hardcode a domain that is outside IRS.gov. Instead, use a properties file to define these locations

3.6 Exception Handling

Where possible, use exceptions to report all error conditions

Avoid logging the exception message verbatim (such as invoking Exception.getMessage () in

Java) or logging/printing the stack trace. These will give an attacker valuable insight into the system build should the log files ever become compromised

Be cognizant of all exceptions that can be thrown in your code and catch those that should be handled in your code

If a method is using exceptions to report error conditions, do not return a status value Check every call that returns a status

A method should never throw the generic Exception object; it should throw a specific exception such as IOException

Refer to IRS_Webapp_HTTP_Errors.doc for exceptions and friendly error pages

3.7 Dead Code

The code should not contain any unused methods or files when ready to deploy to production

The code should not contain any unreachable code

3.8 Race Conditions

All static member variables should always be declared as final. Not declaring a static member variable final allows potential race conditions in which one class object modifies the value of the variable, thereby changing its expected value for all objects of that class. Static data should only be used as constants and/or immutable data.

3.9 System Calls

System calls to the OS are only permissible in backend code that is never deployed to the server.

3.10 Site Exit Disclaimer

The application is not permitted to link or perform a redirect to an URL that is outside of the IRS.gov domain. If an outside link is determined necessary, the application must use the Site Exit Disclaimer utility.

Ensure the application header includes the following reference if using the dynamic header:

<script src=”/static_assets/js/exit.js” type=”text/javascript”></script>

Site Exit Disclaimer is used for informing individuals using the IRS.gov website that if they select a link that is external to the IRS.gov domain that they will be redirected to an external site. This application is a Groovy Server Page that will display a disclaimer to the user on two criteria.

The first criterion is whether the individual selected a link that is to be routed to an external site or to an external site within the federal government

The other criterion is whether the user was coming from the English or Spanish version of the IRS.gov website. This page forwards the request to the redirector.jsp with the destination as a parameter

If using the static application fragments, ensure that every external link in the application has the exit disclaimer prepended to it. Example below

A link to http://www.treasury.gov should be written into the application as https://apps.irs.gov/app/scripts/exit.jsp?dest=http://www.treasury.gov

3.11 File Redirect Application

The File Redirect application is used in conjunction with the Site Exit application. This application is a Java Server Page HTTP response redirector. This page takes the destination as a parameter and tries to redirect the user to the intended file destination.

Link urls should take the form of the following:

https://apps.irs.gov/app/scripts/mapper.jsp?page=name_of_application_link ex: https://apps.irs.gov/app/scripts/mapper.jsp?page=amt2013_link1

Upon delivery please provide intended link destination.

Ex: amt2013_link1=https://www.irs.gov/pub/irs-pdf/some.pdf

4.0 Deployment

4.1 Ant and Make

IRS.gov uses Ant to compile and build Java applications and GNU make to build C applications.

An Ant build script or make script must be written and should include separate targets to build to local, DEV, QA, UAT, PERF, and PROD environments.

Third Party Developers will provide the following:

Pre-packaged war files.

If supporting application code is needed, third parties will provide application source code for compilation by MSP.

Third Party Application Developers typically provide fully packaged war files. If there are any specific additional deployment steps needed for the application, those should be delivered with the initial version of the .war file.

http://www.treasury.gov/ https://apps.irs.gov/app/scripts/exit.jsp?dest=http://www.treasury.gov https://apps.irs.gov/app/scripts/mapper.jsp?page=name_of_application_link https://apps.irs.gov/app/scripts/mapper.jsp?page=amt2013_link1

4.2 Compiler Warnings

The application must compile without any warnings.

4.3 WAR File

To deploy a Java application on irs.gov site, the web components in particular should be packaged in a web application archive (WAR) file. Each WAR file contains servlets and/or JSP, a deployment descriptor, and related resource files. Each application should follow J2EE standards for structuring and packaging a WAR file.

4.4 Context Path

Third Party Developers will provide the application context path prior to 02/29/2012 for evaluation and integration into system environment.

4.5 Database Applications

JBOSS provides the facilities for robust connection pooling including growing, shrinking, verification and reconnection of connections within the database pool. Applications should refer to a JNDI named data source and let JBOSS manage the connections to the database unless an exception is approved. Connections string information, including username and password cannot be embedded into source code.

All database loads must be automated via a script. The process is for the IRS to SFTP the file to the PUP backend, where an automated script, set to a schedule, will retrieve the file and load it into the database. Email confirmation of the successful load, or any errors must be configurate with the script.

4.6 Session Dependency

If applications are developed with a session-dependency, reach out to IRS.gov development team for implementation details. If the application is not session dependent, then it could be hosted on www.irs.gov domain and application would be load balanced in the run time.

4.7 Session Cookies

In addition if the application being deployed is using persistent session cookies, the following set of rules and standards must be adhered to.

The cookie name cannot be JSESSIONID since the apps cluster uses that and it is also mapped to apps.irs.gov (e.g. the RRCC application used RRSESSIONID)

Example:

Alternative Minimum Tax: abbreviated application name + year + sessoinid.

<session-config id=”AMT2010SESSIONID”>

<session-timeout></session-timeout>

</session-config>

The application would be deployed within apps.irs.gov domain http://www.irs.gov/

5.0 Common and Common Navigation

Common and Common Navigation folders contain the HTML and CSS for the top, left, and footer navigation of IRS.gov applications. The HTML will also contain the Google Analytics tags used for reporting statistics for each application. Include statements will provide a common look and feel for the Left, Top and Footer UI navigation. MSP will provide common navigation components to the development team for the CSS, top, left, and footer navigation elements to incorporate into third party applications.

These files should have all the information and references that are required. If futher additions are needed, or if references are missing, please contact the O&M – Application Development Team.

Header, Footer, and Left Nav are to be included in the jsps of all the pages of the application.

<%@ include file=”/fragments/header.html” %>

<%@ include file=”/fragments/leftnav.html” %>

<%@ include file=”/fragments/footer.html” %>

Be sure to include the MSP-provided files in your build.xml. Examples:

<copy todir=”${dir.dist }/fragments” file=”../../common_navigation/fragments/header.html”/>

<copy todir=”${dir.dist}/fragments” file=”../../common_navigation/fragments/footer.html”/>

<copy todir=”${dir.dist}/fragments” file=”../../common_navigation/fragments/leftnav.html”/>

6.0 Dynamic Navigation

Dynamic Navigation fragments consist of a head.hml, header.html, and footer.html fragments. The head fragment contains HTML Markup that goes into the head section of an html page. This includes links to CSS/JavaScript files for the styling of the Dynamic Navigation. The header fragment contains HTML Markup for the top navigation that is displayed on each page. The footer fragment contains HTML Markup with quick links and the copy right insignia.

The HTML fragments are downloaded to the FTP server by Dynamic Navigation Back-End scripts from the friendly URLs provided by CMS/WEM. The HTML fragments are linked between the FTP server and Application Servers via a network file share system (NFS Mount Point). The front-end web applications read each fragments content into memory (Application Scope: Java Bean) to incorporate the html fragments into the application.

Use the ‘IRS Portals – TO3 Dynamic Application Fragments’ document for additional information

1. Add the dynamic navigation package to your project.

7. Add quartz-all-2.1.6.jar to the project classpath

7. Update build scripts to include quartz-2.1.6.jar so it is copied in the lib folder during build.

7. Include the following to the appropriate ant task in your build.xml

7. <file name=”quartz-all-2.1.6.jar” />

4. Place navigationTag.tld that I have attached in your WEB-INF folder

5. Update web.xml in <jsp-config> section to include the following <taglib>

<taglib-uri>navigationTag</taglib-uri> <taglib-location>/WEB-INF/navigationTag.tld</taglib-location> </taglib>

6. Update your jsp pages to include that taglib.

a. <%@ taglib uri=”/navigationTag” prefix=”navigation” > b.

7. Update your head, header, and footer DIVs to include the following where necessary

<navigation:fragment name=”<%= NavigationConstants.TAG_HEAD %>” /> <navigation:fragment name=”<%= NavigationConstants.TAG_HEADER %>” /> <navigation:fragment name=”<%= NavigationConstants.TAG_FOOTER %>” />

Example:

- Filename: YOURJSPNAME.jsp

<%@ page pageEncoding=”UTF-8”%>

<%@ page contentType=”text/html; charset=UTF-8”%> <%@ page import=”gov.irs.navigation.NavigationConstants” %> <%@ taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core” %> <%@ taglib prefix=”fmt” uri=”http://java.sun.com/jsp/jstl/fmt” %> <%@ taglib prefix=”spring” uri=”/spring” %> <%@ taglib prefix=”navigation” uri=”/navigationTag” %> <%@ page import=”gov.irs.navigation.FileBean”%>

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

<html>

<head>

<title><spring:message code=”title” /></title> <link rel=”P3Pv1” href=”/w3c/p3p.xml”> <link rel=”shortcut icon” href=”/static_assets/img/icons/favicon.ico” type=”image/x-icon”> <navigation:fragment name=”<%= NavigationConstants.TAG_HEAD %>” /> <script type=”text/javascript” src=”/static_assets/js/reporting/iep-reporting.js”></script> </head> <body> <div class=”container_10”> <navigation:fragment name=”<%= NavigationConstants.TAG_HEADER <div id=”content” class=”band body”> //code goes here <navigation:fragment name=”<%= NavigationConstants.TAG_FOOTER </div> </body> </html>

7.0 Google Analytics

This section contains technical design for IRS.gov website tagging strategy. The finalized Google Analytics tag information will be provided by MSP to the development team to incorporate tag information into the third party applications.

7.1 Java Script reference to the IRS.gov Website

The application must reference the Google-Analytics reporting javascript file in the static_assets folder /static_assets/js/reporting/iep-reporting.js. This file contains the reference to the google-analytics.js file needed for reporting web traffic. Examples:

<script src=”/static_assets/js/reporting/iep-reporting.js” type=”text/javascript”></script>

Note: The above includes to the google-analytics.js file. Do not include a duplicate reference.

7.2 Download Tracking

Ensure the application includes a reference to the following in the application footer:

<!—Start NEW GA AutoTracker Code

<script s’c=’/static_assets/js/libs/jquery.min’js’ ty’e=’text/javascr’pt’></script>

<script ty’e=’text/javascr’pt’ s’c=’/static_assets/js/reporting/AutoTracker’js’></script>

<script ty’e=’text/javascr’pt’> addLinkerEvents();</script>—!—End AutoTracker Code

7.3 Event Tracking

If the application will include event tracking from Google Analytics please use the following javascript syntax:

ga('send', 'event', 'category', 'action', 'label', value);

Where

Value Type Required Description

Category String Yes Typically the object that was interacted with (e.g.

button)

Action String Yes The type of interaction (e.g. click)

Label String No Useful for categorizing events (e.g. nav buttons)

Value Number No Values must be non-negative. Useful to pass counts (e.g. 4 times)

Example using JQuery:

$('#button').on('click', function() { ga('send', 'event', 'button', 'click', 'nav-buttons');

More information can be found here.

(https://developers.google.com/analytics/devguides/collection/analyticsjs/events)

8.0 General Application Porting Modifications

8.1 Middleware compliance

Application will need to integrate with the JBOSS 5 Application Server

Application will need to integrate with the Apache web server

The IRS portals environment will required Apache web server integration with JBOSS 5

Applications will need to integrate with MS SQL DB Server https://developers.google.com/analytics/devguides/collection/analyticsjs/events

8.2 Code Modifications

Update CSS, Header, Footer and Left Navigation – MSP will provide include statements for importing top, left, and footer navigations for third parties to incorporate into the application (the include statements reference the CSS). The Header includes will reference HTML which will also contain Google Analytics tags.

Application Database schemas will be migrated to a MS SQL 08 database and SQL will need to be modified for data retrieval or updates as need ed

Perform Security Scan with IBM security tool and modify code to address new security findings

Perform 508 compliance validation and modify code to address identified issues

Perform HTML compliance validation and modify code to address identified issues

Perform P3P compliance validation and modify code to address identified issues

9.0 References

Document

IRS.gov Application Development Security.doc

IRS.Gov Deployment Descriptors Standards.doc

IRS_Webapp_HTTP_Errors.doc

10.0 Revision History