ENTERPRISE DATA CENTER APPLICATION DEVELOPMENT GUIDELINES

(1)

ENTERPRISE DATA CENTER

APPLICATION DEVELOPMENT GUIDELINES

Version 1.10 Date: 05/14/2014

SECURITY WARNING

The information contained herein is proprietary to the Commonwealth of Pennsylvania and must not be disclosed to un-authorized personnel. The recipient of this document, by its retention and use, agrees to protect the information contained herein. Readers are advised that this document may be subject to the terms of a non-disclosure agreement.

DO NOT DISCLOSE ANY OF THIS INFORMATION WITHOUT OBTAINING PERMISSION FROM THE MANAGEMENT RESPONSIBLE FOR THIS DOCUMENT.

(2)

EDC APPLICATION DEVELOPMENT GUIDELINES PAGE 2 OF 14

Version History

Date Version Modified By / Approved By Section(s) Comment

01/12/2004 1.0 John Suknaic All Initial draft 01/07/2005 1.1 - 1.5 Vincent Cheong All Updated content.

10/19/2007 1.6 Connie Reber All Updated to new template design. Updated URLs. 11/06/2008 1.7 C. Reber Cover page Insert new OA logo onto cover page

03/18/2009 1.8 C. Reber All Updated URLs. Inserted Security notice on cover page.

11/14/2011 1.9 C. Reber All Change ESF to EDC

(3)

1 Web Application Development Introduction

1.1 O

VERVIEW

Creating a durable, secure, and safe Application begins with including the following design features in the initial design:

 General Web Site

 Database

 Logging and Auditing

 Email

 DSF Specific

 User Base Security

 Input Security

 Input Validation

 Session Management

Attempting to add safety and security to an existing application without these features is usually so prohibitively costly that it is easier to start over.

Similarly, truly distributed applications must be designed with security in mind. This document provides an overview of Best Practices and Guidelines for those who develop applications that will be hosted in the Enterprise Data Center Managed Services.

(5)

2 General Web Site Design

 Avoid Absolute Path: Absolute Path references pointing to local site (ex.

"http://www.state.pa.us/default.asp" in ASP code of www.state.pa.us should not be used in active code. They turn into broken links when site is relocated to another URL. They may also become a security concern when production references are retained in staging, and vice versa.

 Avoid Document-Relative Path: This type of reference is relative to the directory containing the current document (). These links may break when

documents are moved within the site structure. They can also end up pointing to files with the same name, but different location within the site, which is a security problem. This is difficult to troubleshoot and manage.

 Use Root-Relative Path: This type of reference (ex.) allows resources to be accessed from a "top down" approach rather than from a document relative approach. This ensures that all references within the site are strongly defined and easy to correct.

 Create Application Variables to Hold Data: Create and define application variables that can be used by multiple pages. These would include database connection strings, library paths, SMTP relay server, etc. These should be enumerated in a single location, such as global.asa or web.config.

 Error Handling: All errors and exceptions should be captured and handled appropriately. Development teams should craft custom error pages. These should perform two functions: First, present the client generating the error with a “friendly” error notification. Secondly, perform comprehensive logging and reporting so that support staff can be aware of the incidence of the error and possible causes of the incidence.

 Administrative Pages: Remote administration of web content is inherently less secure than fully managed content. However, if some form of web-based administration is necessary, it should be done in an entirely different security zone. This can be accomplished in a separate virtual directory / application, but it is better to use a separate web site altogether. This should be configured on an internal web site with Integrated Security only, administrators should utilize Active Directory accounts, and NTFS permissions on the administration pages should be set to allow only the designated Active Directory accounts to have permission to execute.

 Avoid Writing Files to the Hard Disk: The files constituting the web site should be set with NTFS permissions allowing the anonymous user “read” permissions only. There should be no writing of files on the web server itself. This is not only secure, but is antithetical to our clustered environment. All data writes performed by the anonymous user should be written to fields in the database, using defined stored procedures, as detailed within this document.

(6)

 Create a Site Test Page: EDC Managed Services requires that all applications provide as part of their functionality a comprehensive test page. This page should programmatically attempt to perform all critical tasks needed by the application, such as connect to the relevant database, run a stored procedure, etc. This allows the management team to monitor the application for failure, as well as troubleshoot the application when there is an issue. Ideally, this page should be able to return a Boolean (logical) result: If the page is successful, there is no issue with the application; if it is not successful, there is a problem that must be resolved. It is far easier to design this page along with the application than to add it after the application is written.

 Use Role Based Security: If an application enables various functions to be performed by different users, then such a configuration should use the concepts of roles and groups to simplify rights administration.

 Do Not Use Shares: Using Windows Networking “shares” to map to file systems using NetBIOS is not supported in EDC Managed Services.

 Least Possible Permissions: It is important that when assigning permissions to users and/or groups that permissions are limited to the least amount of permissions necessary to perform the designated task. EDC Managed Services does not recommend or permit Service accounts for web site and business layer to execute under local or domain administrator account privilege.

(7)

3 Database Design

 Least Possible Permissions: It is important that when assigning permissions to users and/or groups, that permissions are limited to the least amount of permissions necessary to perform the designated task. For example, if a user/group is only allowed to view particular information they should have the permission to READ, not WRITE to the database. Giving elevated privileges to users/groups that do not require those privileges is a security risk and should be avoided. The service account under whose context the application runs should also have the least required permissions. DBO access is not recommended or provided for service accounts and agency administrators.

 Use Stored Procedures: When making database calls it is a recommended that stored procedures are used for this task. The reason for this is two fold: the first being Security and the second being Performance. For Security reasons; since stored procedures are compiled code, they cannot be manipulated or executed as SQL code; thus providing a secure way of modifying and/or accessing data or objects. For Performance reasons; since stored procedures are on the SQL server, they do not need to be compiled each time they are executed. If you are sending your T-SQL statements from the client application to the SQL server the statement has to be recompiled by the SQL server thereby sacrificing performance.

 Use Database Roles: It is recommended that Database Roles be used whenever possible to give users access to data. Use of roles in SQL is very similar to the use of Groups in system

administration. Using roles allows for a more streamlined administration. The creation of roles in SQL in the Enterprise Data Center can be done in one of two ways: They can be manually created by EDC support personnel or the application development team can provide T-SQL scripts for the same. If using T-SQL scripts, the group name and permissions must be defined and coordinated with EDC personnel prior to implementation. This is to avoid possible naming conflicts as well as establishing the level of permission needed.

 Avoid Using Default Roles: Because default roles can contain elevated permissions it is recommended that separate roles are created for the application based on required access. Users will be added to these roles as dictated by application documentation.

 Public Role: This is a special role that all database users belong to. It contains all the default permissions for users in the database. It is available in all user databases, master, msdb, tempdb, and model database. When assigning permissions it is a best practice to not use this role.

 Sensitive Data: Sensitive information should preferably not be accessible by via a web page. For example, you should not be able to view personal information such as someone’s social security number via a web page. These types of fields should not be accessible because of inherent security risks that are associated with web exploits. This information should be encrypted within the database and only accessible to authorized individuals. Queries from web pages should be done by creating special views or by using stored procedures that only display information that should be seen by the viewing party.

 Database Grooming: Be considerate when designing your database. If not properly maintained a database can grow extremely large which can lead to poor performance. Make sure that it is groomed regularly via scheduled stored procedures that are used to purge data that is no longer required. Running these jobs will ensure that databases perform more efficiently especially when complex T-SQL statements are being used to extract and display data.

(8)

4 Logging and Auditing Design

 Log Logon Failure to Detect Brute Force/Dictionary Attacks: Logging failed logon attempts is essential when trying to detect brute force or dictionary attacks. Brute Force attacks are when someone is trying to break your password by using every possible combination of letter, number, and/or special character. This is normally done by using some type of password cracking

software. Normally, a hacker will have gained access to your encrypted password file and have it loaded locally on their machine. From there, they have all the time necessary to try and crack the passwords. However, some hackers are not as sophisticated and try to crack passwords over the web. Dictionary attacks are very similar to brute force attacks except the hacker uses ordinary dictionary words for passwords. This is why it is important to use strong passwords incorporating letters (upper and lower case), numbers, and special characters.

 Append Logging: How logs are kept is an important aspect of management. As a best practice logs should be appended too instead of overwritten day-to-day. By appending log data we can produce reports and track events over a course of time. Do not make your logs viewable via the web. If you can view your logs via the web it is only reasonable to assume that a skilled hacker will be able to read your logs as well.

 Event Logs for System Events: Windows provides us with event logs and categories for these event logs (System, Application, and Security for most servers). Some applications require that additional logging be done. This can be done several ways. The two most prevalent are as follows: Create a custom log that is written as a standard event log format. It can be viewed through Event Viewer just like the other aforementioned logs that are created by default. Secondly and the preferred method is to perform logging that is stored in a database. In general, both MS SQL and Oracle both do a great job of storing data. If you are going to perform custom logging then it is best to write these logs to a backend database. A backend database, like MS SQL or Oracle has less chance of corruption then an event log file on the hard disk. Your data is also stored in a more secure fashion.

(9)

5 Email Design

 Use the PPTMAIL Object when using DSF: We have found that the best email solution when working within the confines of DSF is the PPTMAIL Object. This is a proven solution that is fully supportable in the Enterprise Data Center Managed Services. We have a dedicated SMTP cluster that is used to handle all outbound traffic generated by these objects. The method is reliable and secure in nature.

 Collaboration Data Objects for NT Servers (CDONTS): This older technology is not supported in the Enterprise Data Center Managed Services. This object was and is often used for feedback forms, newsletters, and alerts. However, CDONTS can be easily compromised and the result is Email Spoofing. Email spoofing is the practice of changing your name in email so that it looks like the email came from somewhere or someone else. Using the proper SMTP tags and new lines you can also easily change the email subject and contents.

 CDO For Windows: For ASP applications, we recommend using CDO for Windows. We will leverage our SMTP cluster for relaying the email. The FQDN of the SMTP cluster needs to be configured as a parameter in the Global.ASA file. Please note anonymous authentication will be leveraged for SMTP. Reference: http://www.aspfaq.com/show.asp?id=2026.

 System.Web.Mail: You can leverage System.Web.Mail namespace for adding email functionality to .Net applications. We will leverage our SMTP cluster for relaying the email. The FQDN of the SMTP cluster need to be configured as a parameter in the Web.Config file. Reference:

http://msdn2.microsoft.com/en-us/library/system.web.mail(vs.71).aspx

 SMTP Relay Server: This should be a site wide variable that can be change by Enterprise Data Center staff. Do not hard code any IP Address information.

(10)

6 DSF Specific Design

 DSF Editor: Do not put server side code in the DSF Editor. Make a separate sub-folder for holding asp and use <dsf header>, <left navigation>, <right navigation> etc to build the framework. This can all be found in the DSF DIG. Although putting code directly in the DSF editor functionally works, it is not a recommended approach. Coding in this form makes moving the application very difficult in the event of a failure. In addition it also has a negative

performance impact on the site itself.

 Custom Application Uploads: If you plan on writing your own application that uses a file upload feature other then DSF File Manager you will need to incorporate the appropriate code from the PPT ClusterSync Guide so that folders and files are properly created and replicated to each node in the cluster. Refer to the PPT ClusterSynce Guide.

 Custom Data: Custom data should not be stored in the DSF database. This makes it difficult to update DSF and increases debugging overhead. Custom data should be stored in a separate database and referenced within the code.

 Technical Documentation for DSF Refer to:

(11)

7 User Base Security Design

 Credential Storing: If your code requires storing user credentials, do not store them in plain text. This is considered as security vulnerability and should be avoided at all costs. Stay away from “home-grown” encryption methods that are not industry standards and that can be reversed to get the decrypted credentials.

 Password Storing: If you need to store passwords, store the hash, not the value. A hash is a one-way transformation that cannot be reversed. Hash functions are very popular with digital

signatures because they reduce the amount of information that has to be encrypted. The most common implementation of hash functions is MD5.

 Industry Standard Cryptography: As stated above, do not deviate from Industry Standards as these have been well tested and are deemed secure. Use these methods for your encryption and refrain from using a “home-grown” method.

(12)

8 Input Security Design

 Pass Forms Authentication over HTTPS: With any type of authentication, the information should be passed in a secure manner. Form based authentication sends the user id and password via clear text. Depending on the sensitivity of the data, it is recommended that form based

authentication be done over HTTPS. This provides the necessary encryption and protection to the individual supplying the credentials.

 Sensitive Data and GET Requests: When you have to pass sensitive data do not do it via a GET request. Query strings can be watched and the sensitive data can be compromised.

(13)

9 Input Validation Design

 Never Trust Any Input: As a simple rule, do not trust any information returned from a browser session or other system.

 Server Side Validation: Do not rely on client side validation. Client side scripts that validate user input can increase application performance by reducing the number of requests to the server. However, hackers can easily bypass client side rules, sending invalid data to the server. If client side validation is performed, it will need to be followed by the same validation check at the server.

 Validate Input First: Always validate the input before performing any other logic. Input fields can be used to corrupt data and cause system outages if not properly handled.

 Centralize Input Validation: Many variables will use the same validation rules. For instance, many fields will simply check to ensure that all characters are alpha-numeric. If all pages that need to validate input utilize the same code, it will be easier to manage validation and produce a more consistent environment.

 HTML Encoding: HTML encode all input before returning the information to a client. HTML encoding is a process of converting a variable to a HTML display string. If a hacker attempts to send scripts to the server they will be converted to plain text.

(14)

10 Session Management Design

 Caching Data: Avoid caching sensitive data in your session. For instance, if you have a shopping cart site, do not hold the users credit card number. This will reduce the chances that sensitive data is presented to a user who hijacks a session.

 Hidden Variables: If you need to pass session information between pages, do not use hidden form fields for storing sensitive information. The fields will be hidden from normal users, but can be easily displayed by most browsers by selecting "view source". This data can also be changed before it is sent back to the server.

 IIS 5.0 Session State: IIS 5.0 provides native support for session state management. This works for stand-alone servers, but does not support clustering.

 Session ID and Query String: If you use a session ID to maintain state, do not pass the session ID in the querystring. Querystring data can be intercepted even when SSL is used. If intercepted, users can hijack another users session which may have elevated privileges, sensitive information, or allow them to execute requests on their behalf.

 Keep Session Times Short: If you maintain a session, keep the timeout period as short as possible. This will decrease the chances of a user hijacking another user’s session.

 Cookies: Avoid using cookies to store sensitive session data. Hackers can easily manipulate data in the cookie. If you must store sensitive information in a cookie, then encrypt the data.

 ASP.Net State Management: EDC supports session state for ASP.NET applications and

maintains it with mode of “SQL Server” for scalability, availability, and load balancing purposes. This is an out-of-process session state maintenance mode.

 All objects stored in out-of-process session state must be serializable (binary serialization). In development, ASP.NET projects meant for deployment at EDC should be fully tested in SQLServer, or, if SQL is unavailable, StateServer out-of-process mode.

 Keep session state small, as all state data is read and written back to SQL with every page hit.

 Consider other state maintenance technologies, such as Cache object (not synched across cluster), Viewstate, depending on type and scope of information stored. There are caveats to using the ASP.NET caching mechanisms.

First, do not cache too many items. There is a cost for caching each item, especially in memory utilization. Items that are easily recalculated or rarely used should not be cached. Second, do not assign cached items a short expiration. Items that expire quickly cause unnecessary turnover in the cache and frequently cause more work for cleanup code and the garbage collector. If this is a concern, monitor the Cache Total Turnover Rate performance counter associated with the ASP.NET Applications performance object. A high turnover rate could indicate a problem, especially when items are removed before their expiration. This is also known as memory pressure.

ENTERPRISE DATA CENTER APPLICATION DEVELOPMENT GUIDELINES