Web Application Security Deployment Procedure

Version 1.2

For Students, Faculty, Staff, Guests

Purpose

The purpose of this procedure is to deploy web application security controls on the University’s IT Resources.

Scope

This IT procedure, and all policies referenced herein, shall apply to all members of the Office of Information Technology staff (the “User(s)” or “you”) who use, access, or otherwise employ, locally or remotely, the University’s IT Resources, whether individually controlled, shared, stand-alone, or networked.

Procedure Statement

System/application owners are responsible for deploying appropriate Web Application Security controls1 to protect web applications per the Web Application IT Security Policy. This document provides the steps necessary to administer web application security controls and policies for all incoming traffic to the University’s web applications to filter out malicious visitors and requests (e.g., SQL injections, XSS attacks, cookie poisoning, denial-of-service attacks, brute force, credential stuffing).2

A. Authentication

  1. Verify that hard-coded credentials are not stored within the application code.
  2. Enable password reset where Central Authentication Service (CAS) cannot be implemented:
    1. Reset system passwords with challenging questions and answers.
    2. Password reset options must not reveal the validity of the account.
    3. Passwords must meet the University’s password requirements as stated in the Acceptable Uses of IT Infrastructure and Resources-Policy Statement.
  3. Lock failed account logins after five failed attempts, and accounts must be locked for a minimum of five minutes.
  4. Authentication error messages must be generic and not disclose any sensitive information regarding the account, such as the validity of the username or password.
  5. Database credentials (i.e., the authentication credentials in the business logic tier) must be stored in a secure, centralized location on the server outside of the web root. The file should only be readable by the user account running the application.
  6. Configure applications and middleware services to run with minimal privileges.
  7. The application must automatically log out the inactive User after 15 minutes unless an extended session is approved by design and accepted by an Office of Information Technology AVP.
  8. You must destroy corresponding data and session information on the server when the User logs out of the application.
  9. The logout button or link must be easily accessible to the User on every page after they have authenticated.

B. Controlled Administrative Privileges

  1. Use access control checks to mediate all requests to a standard security gateway (i.e., Mandatory Access Control), ensuring that access control checks are triggered whether or not the User is authenticated.
  2. All decisions must be based on the principle of least privilege.
  3. Grant access to newly created accounts on a need-to-know basis.
  4. Do not allow direct object references to files or parameters that can be manipulated to grant access to the system.
  5. Prevent non-validated forwards/redirects from unauthorized access and phishing by conducting access control checks before sending the User to the location.

C. Configuration and Operations

  1. Office of Information Technology’s change management process must be followed so that new software releases are tested and associated documentation is completed before going live.
  2. Configure the hardening of all infrastructure/application components to satisfy the agreed-upon levels of the vulnerability scanning tools.
  3. Draft and regularly test a thorough disaster recovery plan to minimize the impact of an incident.

D. Data Protection

  1. Disable HTTP access for all SSL-enabled resources.
  2. Disable weak SSL ciphers.
  3. Use valid SSL certificates from a reputable certificate authority.
  4. Use the Strict-Transport-Security header to ensure that the browser does not talk to the server on non-SSL per the Server Certificate Security policy.
  5. If database User passwords must be stored (e.g., files), appropriate Access Control Lists (ACLs) must be used.
  6. Perform critical establishment or exchanges over a secure channel (e.g., password manager, shared drive).
  7. Securely store keys and make them accessible to the appropriate individuals on a need-to-know basis.
  8. When appropriate, disable browser data caching using the cache control HTTP headers or Meta tags within the HTML page.
  9. Turn off the autocomplete setting for sensitive inputs (e.g., login form in the HTML form).

E. Error Handling and Logging

  1. Error messages must be generic and not reveal details about the application.
  2. Suppress default framework error messages or replace them with customized messages.
  3. Configure error handlers to handle unexpected errors without allowing unhandled exceptions to occur.
  4. Logging and storage
    1. All authentication activities, whether successful or not, must be logged, as well as privilege changes and administrative activities.
    2. All-access to sensitive data such as PII or PHI must be logged and stored centrally in the University’s log management solution (e.g., SumoLogic).
    3. Log retention must follow the retention policy set forth by the University to meet regulatory requirements per the Records Retention and Disposal Policy and the Logging Standards Policy.

F. Input and Output Handling

  1. Contextual output encoding
    1. All input functions must contextually encode data on the server side before the application accepts it.
    2. Set the encoding using HTTP headers or Meta tags for every page in the application to ensure the page’s encoding is defined, and the browser does not have to determine the encoding on its own.
  2. Allow lists/block lists
    1. Allow listing input is the preferred approach; only accept data that meets the criteria.
    2. Apply to block lists for known harmful input patterns and characteristics for more flexibility.
  3. SQL Injection
    1. Must be addressed during application development or as a last resort using a web application firewall to mitigate.
    2. Create SQL queries with User content passed into a bind variable to prevent attacks.
    3. Do not dynamically create SQL queries using string concatenation if the SQL query string is used in a bound or parameterized query.
  4. Tokens for forged requests
    1. Whenever possible, embed a random value unknown to third parties into the HTML form to prevent cross-site request forgery attacks.
    2. Require a unique, sever-issued, and randomized token for each request.

G. File/Input Validation

  1. Validate the size of the file, the file type, and the file contents (i.e., allow list, allowed file types, antivirus software, renaming files after uploading) when accepting file uploads from the User, and ensure that it is not possible to overwrite the destination path for the file.
  2. Validate that the source of the input is the authenticated User.

H. Secure Cookie Attributes

  1. The session cookie must be set with both the HTTP only and the secure flags.
  2. Set the cookie domain and path scope to the most restrictive settings for the application.
  3. Do not use wildcard domain-scoped cookies.
  4. Session cookies must have a reasonable session expiration time.
  5. Avoid non-expiring session cookies.

1 Open Web Application Security Project (OWASP) Top 10 Proactive Controls and OWASP Mobile Security Project.

2 OWASP offers best practices for addressing critical web application security risks.

Definitions

Cookie Poisoning is the modification of a cookie (personal information on a web User's computer) by an attacker to gain unauthorized information about the User for purposes such as identity theft. The attacker may use the information to open new accounts or to gain access to the User's existing accounts.

Credential Stuffing is the automated injection of breached username/password pairs to gain access to User accounts fraudulently. This is a subset of the brute force attack category: large numbers of spilled credentials are automatically entered into websites until they are potentially matched to an existing account, which the attacker can then hijack for their purposes.

Cross-Site Scripting (XSS) attacks are a type of injection in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a User within the output it generates without validating or encoding it.

Denial-of-service attack (DoS attack) is a cyber-attack where the perpetrator seeks to make a machine or network resource unavailable to its intended Users by temporarily or indefinitely disrupting the services of a host connected to the internet.

IT Resources include computing, networking, communications, application, and telecommunications systems, infrastructure, hardware, software, data, databases, personnel, procedures, physical facilities, cloud-based vendors, Software as a Service (SaaS) vendors, and any related materials and services.

SQL Injection is a code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g., to dump the database contents to the attacker).

Web Application Security is a branch of information security that deals specifically with the security of websites, web applications, and web services.

Related Policies and Procedures

Implementation Information

Review Frequency: Annual
Responsible Person: Director, Applications Security
Approved By: CISO
Approval Date: July 31, 2019

Revision History

Version: Date: Description:
1.0 07/31/2019 Initial document
  08/17/2020 Review, no changes
1.1 08/10/2022 Updated links
1.2 10/06/2023 Updated procedure

Need Help?

Walk-In Centers

McShane Center 266 | RH
Leon Lowenstein SL18 | LC

View Our Walk-In Hours