GO-ITS 25.13 Security Requirements for Web Applications

Document history

Foreword

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the guidelines, preferred practices, standards and technical reports adopted under delegated authority of the Management Board of Cabinet (MBC). These publications support the responsibilities of the Treasury Board Secretariat (TBS) for coordinating standardization of Information & Information Technology (I&IT) in the Government of Ontario. Publications that set new or revised standards provide enterprise architecture guidance, policy guidance and administrative information for their implementation. In particular, GO-ITS describe where the application of a standard is mandatory and specify any qualifications governing the implementation of standards.

1. Introduction

1.1. Background and purpose

This document describes security requirements, software development rules, and principles for engineering/implementing Web Applications for the Government of Ontario and is intended to ensure that the use of Web Applications will not result in undue or unmitigated risk that jeopardizes the electronic delivery of Government services.

The primary audience for this document includes application developers, implementers, application architects, production management staff, and Program Managers. It is intended to influence the design, development, and deployment of applications operated on behalf of the Government of Ontario.

This document also includes detailed recommendations for secure development techniques in section 4.

1.2. Scope

1.2.1. In Scope

The GO-ITS 25.13 Security Requirements for Web Applications apply to:

• All ministries of the Ontario Government and any organization that uses a ministry’s or I&IT Cluster’s information technology infrastructure;
• Any organization that uses ministry or I&IT Cluster information technology infrastructure;
• Any third party organizations (and their staff) that connect to the Government of Ontario integrated network for business purposes, unless exempted in a Memorandum of Understanding; and
• All components of Web Applications that support the processing of transactions involving Government information. In the case of backend databases, it only includes requirements relating to access to the database services.

For security involving sensitive information^{footnote 1[1]}, if it becomes known that sensitive information is deemed at serious risk, then immediate remedial action must be taken to mitigate the risk by applying the tools, controls, methods, procedures, etc. as per the relevant GO-ITS security document.

The Strategy, Policy and Enterprise Architecture Branch (SPEAB) of the I&IT Strategy and Cyber Security Division (SCS), or a successor division/branch, maintains this standard, and should be contacted if the requirements in this document require clarification, or if it is not clear whether this standard applies to a given situation.

1.2.2. Out of Scope

This standard does not apply to:

• Internet web sites that only present static information to the public, or Intranet services; and
• Internet sites that do not connect to additional services or servers within the Government of Ontario integrated network, or similar services or servers operated elsewhere on behalf of the Government of Ontario.

1.3. Applicability statements

1.3.1. Organization

Government of Ontario IT Standards and Enterprise Solutions and Services apply (are mandatory) for use by all ministries/clusters and to all former Schedule I and IV provincial government agencies under their present classification (Advisory, Regulatory, Adjudicative, Operational Service, Operational Enterprise, Trust or Crown Foundation) according to the current agency classification system.

Additionally, this applies to any other new or existing agencies designated by Management Board of Cabinet as being subject to such publications, i.e., the GO-ITS publications and enterprise solutions and services – and particularly applies to Advisory, Regulatory and Adjudicative Agencies (see also procurement link, OPS paragraph). Further included is any agency which, under the terms of its Memorandum of Understanding with its responsible Minister, is required to satisfy the mandatory requirements set out in any of the Management Board of Cabinet Directives (cf. Operational Service, Operational Enterprise, Trust, or Crown Foundation Agencies).

As new GO-ITS standards are approved, they are deemed mandatory on a go-forward basis (Go-forward basis means at the next available project development or procurement opportunity).

When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries and I&IT Cluster must follow their organization’s pre-approved policies and practices for ensuring that adequate change control, change management, risk mitigation, and control selection mechanisms are in place and employed.

For the purposes of this document, any reference to ministries or the Government includes applicable agencies.

1.4. Requirements levels

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

Must – This word, or the terms "REQUIRED" or "SHALL", means that the statement is an absolute requirement.

Should – This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, cost) must be understood and carefully weighed before.

1.5. Contact information

1.5.1. Roles and responsibilities

Accountable role definition

The individual ultimately accountable for the process of developing this standard. There must be exactly one accountable role identified. The accountable person also signs off as the initial approver of the proposed standard before it is submitted for formal approval to ARB. (Note: in the OPS this role is at a CIO/Chief or other senior executive level, e.g. Head, Director or higher).

Accountable role:

Title: Manager, Security Policy and Standards Unit
Ministry/Cluster: Ministry of Government and Consumer Services
Division: Cyber Security Division
Branch: Cyber Security Strategy, Risk Management & Architecture Branch
Section: Security Policy and Standards Unit
Phone: 647-982-5216
Email: Alex.Fanourgiakis@ontario.ca

Responsible role definition

The organization responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization provides the resource(s) to develop the standard).

Responsible organization:

Ministry/Cluster: Ministry of Government and Consumer Services
Division: Cyber Security Division
Branch: Cyber Security Strategy, Risk Management & Architecture Branch

Support role definition

The support role is the resource(s) to whom the responsibility for actually completing the work and developing the standard has been assigned. There may be more than one support role identified. If there is more than one support role identified, the following contact information must be provided for each of them. If there is more than one support role, the first role identified should be that of the editor – the resource responsible for coordinating the overall effort.

Support role (editor):

Ministry/Cluster: Ministry of Government and Consumer Services
Division: Cyber Security Division
Branch: Cyber Security Strategy, Risk Management & Architecture Branch
Section: Security Policy and Standards Unit
Job Title: Senior Security Policy Advisor
Name: Tim Dafoe
Phone: 416-327-1260
Email: Tim.Dafoe@ontario.ca

Consulted

Please indicate who was consulted as part of the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups. (Note: consulted means those whose opinions are sought, generally characterized by two-way communications such as workshops):

Informed

Please indicate who was informed during the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups. (Note: informed means those who are kept up-to-date on progress, generally characterized by one-way communication such as presentations):

1.6. Recommended versioning and/or change management

Changes (i.e. all revisions, updates, versioning) to the standard require authorization from the “responsible” organization. Once a determination has been made by the responsible organization to proceed with changes, the Strategy, Policy and Enterprise Architecture Branch, OCCS, will coordinate and provide assistance with respect to the approvals process. The approval process for changes to standards will be determined based on the degree and impact of the change. The degree and impact of changes fall into one of two categories:

Minor changes – requiring communication to stakeholders, ARB endorsement required. Changes are noted in the “Document History” section of the standard.

Major changes – requiring a presentation to ARB and ITELC for endorsement.

Below are guidelines for differentiating between minor and major changes:

Minor:

• represents incremental version changes to one or more specifications
• does not impact procurement (other than informational)
• does not require configuration changes to current solutions
• does not impact other standards
• is not related to legislative, policy, or procurement changes

Major:

• represents a major version change to one or more specifications
• impacts procurement
• requires configuration changes to current solutions
• impacts other standards
• responds to legislative, policy or procurement changes

1.7. Publication details

All approved Government of Ontario IT Standards (GO-ITS) are published on the OPS Intranet. Please indicate with a checkmark below if this standard is also to be published on the public, GO-ITS Internet Site.

Standard to be published on both the OPS Intranet and the GO-ITS Internet web site (available to the public, vendors etc.)

1.8. Compliance requirements

This document is intended to guide the design, development, deployment and operation of all new Web Applications. Compliance with this document is mandatory due to the high degree of vulnerability and impact associated with applications that are deployed and operated without careful security planning and appropriate safeguards.

2. Technical specification

Web Applications are a source of significant security exposure and technical vulnerability; effective management of these services requires careful development and adherence to security requirements.

Ministries and agencies must be assured that Web Applications are secure and that Government I&IT resources are not jeopardized by their use. This assurance is expressed in terms of accountability, confidentiality, integrity, availability, reliability and the opportunity for audit.

The implementation of security measures for Web Applications does not diminish the need for Program Managers to ensure that formal, documented risk assessments (e.g. TRAs) are conducted, developers are appropriately qualified and trained, new technology is assessed for risk, and physical/logical access controls are implemented to protect Government assets.

2.1. Security and privacy assessments

Privacy Impact Assessment (PIA) pre-screening and a Threat/Risk Assessment (TRA) must be undertaken for any Government of Ontario project involving Web Applications. Peer-review of project development and design efforts should also occur, to validate practices prior to the completion of a TRA.

A TRA (in conjunction with the Government of Ontario’s information sensitivity classification Policy and associated guidelines) must be used to determine the degree of risk associated with the project. TRA and PIA work products must be revisited as additional information becomes available or when the project is significantly changed prior to deployment. Any new unacceptable risk or other exposure must be mitigated prior to deployment in a production environment.

When recommended by a TRA, when time-critical services are deployed or changed, or when a Web Application will process or present sensitive information, Security Testing and Evaluation (STE) must be conducted (typically in the form of Vulnerability Assessment and Penetration Testing). Web Applications with time-critical status, that process or present High Sensitivity information, or have been identified as code review candidates via a TRA, must be subject to source code security review (where technically possible) by the Cyber Security Branch (CSB), or a vendor endorsed by CSB.

Remedial action resulting from STE findings during development must be completed prior to production use of the web application. STE must also be performed if the application is significantly changed. Testing should also be performed within the production environment.

2.2. Deployment of Web Applications

Government of Ontario Web Applications must be deployed in accordance with GO-ITS 25.11 Security Design Requirements. Typical locations for web application components include:

• Access Zone DMZ or Presentation Zone (presentation of UI, web pages, portals);
• Logic Zone (business rules, processing, parsing of input and queries); and
• Data Zone (database query handling, organized information storage).

Non-standard deployment may be accommodated according to GO-ITS 25.11 (subject to TRA recommendations).

2.3. Management of production Web Applications

The management of production Web Applications must include:

• Ensuring that such applications are deployed in accordance with the requirements in this document, Government policies and standards, and applicable industry best practices;
• Arranging for Security Testing and Evaluation every two years (e.g., vulnerability assessments, penetration testing, application testing), unless major/ongoing changes or TRA recommendations mandate more frequent or immediate assessment (as per section 3.1);
• Ensuring that IT infrastructure services (e.g., network, servers, desktops, data communications, directories, etc.) are kept current and that recommended security patches are promptly applied;
• Running applications and supporting services with the least privilege principle enforced as per GO-ITS 25.11, to control access to infrastructure and networked resources;
• Ensuring that changes to network security (e.g., changes to firewall deployment or rules) do not jeopardize the security of Government applications and services;
• Monitoring for unauthorized changes to production software and services;
• Ensuring that backup and restore functions are implemented and tested for Web Applications;
• Ensuring that time-critical Web Applications have business continuity and disaster recovery plans, and that these plans are kept current;
• Establishing procedures to monitor for attacks when applications are deemed time-critical or when sensitive information is involved; and
• Establishing and reviewing audit logs, with prompt reporting and remediation of suspected security breaches, non-compliance with security requirements, or other incidents, in accordance with the GO-ITS 37.0 Enterprise Incident Management standard.

2.4. Administration of production Web Applications

The administration of production Web Applications must include:

• Access to administrator ^{footnote 2[2]}(e.g., privileged operating system access) accounts must be provided on a least privilege basis, and restricted to individuals who have been authorized by the Cluster Chief Information Officer (or his/her delegate);
• Assigned privileged accounts must be monitored and audited to detect misuse and/or security violations;
• Each administrator must have his or her own account with a specific administrative role and limited privileges. The number of administrative roles may vary due to the complexity and sensitivity of the information processed, or a documented requirement for separation of duties;
• Administrator accounts must be promptly terminated^{footnote 3[3]} (e.g., by next business day) when the authorized account holder no longer requires access, or locked when it is suspected that the account has been compromised. In the case of administrators responsible for High Sensitivity applications, these actions must be immediate (e.g., performed upon initial notification without delay);
• All administrators must sign an agreement that sets out their responsibilities including the protection of Government information, and the use and protection of their identity credential;
• Administrators responsible for applications processing High Sensitivity transactions must have an OPS Personnel Screening Clearance or equivalent;
• Administrator accounts must never be accessed using an insecure computer^{footnote 4[4]} ;
• Appropriate operational and/or physical security measures must be in place to protect administrative consoles and/or management networks, as required by the applicable Government standards and policies. In high-risk situations, consideration should be given to organizational and/or physical separation of administrators from other staff;
• Direct operating system access to application components (e.g., web servers, business logic) and management interfaces must be provided via VPN and/or a management segment of the network;
• Application development staff should not be granted administrative/privileged access to production systems; and
• Auditors should be provisioned with unique accounts, with access restricted to the minimum needed to conduct audits.

2.5. Development environment

Development and test environments must be managed in a manner consistent with GO-ITS 25.0 General Security Requirements. Application development must be managed in a manner consistent with the GO-ITS 54.0 Application Development Standard.

Information stored and/or processed within a development environment must be appropriately classified according to the Government of Ontario’s information sensitivity classification Policy and associated guidelines.

Must avoid the use of sensitive information in accordance with Government of Ontario’s information sensitivity classification Policy and associated guidelines for test and development instances; where this is not technically feasible, determine exposure via risk assessment, and deploy an appropriate mitigation technique (e.g., additional safeguards, data masking, strong industry de-identification techniques, etc.).

Privileged access^{footnote 5[5]} to the development environment for a given application must be restricted to authorized individuals (developers) as assigned by the Cluster Chief Information Officer (or his/her delegate).

Access to the development environment must be terminated when no longer needed (e.g., by next business day). Termination of access must be immediate and without delay in instances involving sensitive information (e.g., dismissal of an employee developing a High Sensitivity application).

The development team must be aware of and adhere to the I&IT Security Directive, the Freedom of Information and Privacy Directive, Government of Ontario information sensitivity classification Policy and associated guidelines, the security requirements set out in this standard, other Government policies and standards, and applicable industry best practices (see References in this document).

Development staff must understand the development environment (e.g., software development tools) and the development process (e.g., system and software development life cycles, change control, testing, secure software design and coding best practices). For more information on secure development practices, see sections 5.1 and 5.2 in the Appendix of this document.

The software supporting the development environment should be kept current. In particular, updates to address serious security issues must be promptly tested and applied.

If a Threat/Risk Assessment (TRA) determines that the development environment presents unacceptable risk, consideration should be given to additional security measures, such as:

• OPS Personnel Screening Clearance^{footnote 6[6]}for development staff;
• Physical separation of development staff from other staff (e.g., additional physical access controls);
• Increased use of approved cryptography to protect sensitive material;
• Separation of duties within the development team and more restrictive access controls; and/or
• Independent security audit/review and testing of application code.

2.6. Authentication requirements

Minimum requirements

Web Applications providing access to sensitive information (as determined by the Government of Ontario information sensitivity classification Policy or a TRA) must authenticate individuals (e.g., clients, users,  or authorized administrators).

The authentication mechanism for a Web Application that provides access to sensitive information must at a minimum:

• Enforce GO-ITS 25.0 access control and password requirements, and other requirements from applicable Government standards and best practices;
• Protect identity credentials as High Sensitivity information as per applicable Government standards and policies;
• Ensure the identity credentials for the authentication process are not stored by the browser (e.g., client cache);
• Never confirm valid usernames, responding to incorrect username and/or password input with the same error message;
• Lock out accounts temporarily^{footnote 7[7]} (e.g., for 30 minutes) after a maximum of five consecutive incorrect password attempts;
• Capture failed authentication attempts in security logs (the attempted password must not be logged, with logged usernames protected as they may contain password information);
• Create a session key to authenticate subsequent data transmissions in the session;
• Reject credentials that have expired or have been revoked by the issuing organization; and
• Support a secure method to recover identity credentials.

The authentication mechanism should also:

• Generate an alert for immediate follow up if more than one account is locked out within a short time; and
• Include protection against automated brute force attacks^{footnote 8[8]}.

Authentication mechanisms controlling access to Medium or High Sensitivity information must be of a strength and assurance level commensurate with the confidentiality and integrity of the information presented (or the transactions enabled) by the application. Additional safeguards beyond these requirements should be used if needed by a program to address unacceptable risk identified by a relevant TRA. These requirements also apply to system and device authentication, where deployed.

OPS and service partner user roles

Web Applications must authenticate users^{footnote 9[9]}. OPS users dealing with High Sensitivity information, and all non-OPS users dealing with sensitive information, must sign an agreement that sets out their responsibilities including the protection of Government information, and the use and protection of their identity credential.

For OPS users dealing with High Sensitivity information, a process or technology should be in place to verify that a secure computer is being used (e.g., a Government-provided computer that is properly maintained, has an approved system image and build, and has approved security safeguards in place).

Administrator roles

Before gaining access to his/her account, the identity of an administrator^{footnote 10[10]} must be authenticated using a unique electronic credential issued in accordance with applicable Government standards and policies.

Administrators must use secure computers when managing applications to limit exposure to attacks against local clients, or second-order injection attacks. A process or technology should be in place to verify that a secure computer is being used for management activity.

2.7. Session management

Session management is a key component of secure Web Applications. The following requirements apply to session management implementations:

• A unique session identifier must be securely created after the individual is successfully authenticated;
• The session identifier (e.g., session token, key, or string) must be strongly and reliably associated with the session in a way that resists attacks against the session management function;
• Session identifiers must not contain sensitive information;
• Session identifiers must not be predictable, readily reverse-engineered, or susceptible to a brute-force^{footnote 11[11]} attack;
• The integrity and authenticity of a session identifier received via the Internet must be securely verified (i.e., through the use of an approved cryptographic hash algorithm that includes the session identifier and a secret session key value);
• The application must not leave behind sensitive and/or personal information on the user/client’s computer (e.g., in a cache or cookie) upon termination of a session^{footnote 12[12]} . The user/client’s browser should be forced to discard web pages from the cache (i.e., by setting an aggressive expiry date);
• A logout facility must be provided to deactivate the session. A reminder should be displayed to remind users of the importance of promptly logging out when access is no longer required;
• Sessions must be subject to an inactivity timeout (recommended to be no longer than 20 minutes) to reduce the chance of an abandoned active session being exploited by an attacker. Shorter inactivity timeouts should be used depending on the risks involved and the sensitivity of the information related to the transactions;
• Input supplied by the client (e.g., via a browser) can never be assumed valid or correct, and must be validated;
• The session identifier should be passed to and from the user/client computer in a manner that will not result in inadvertent disclosure of the value(s) in use (i.e., the identifier should not appear in the URL itself);
• Session information saved on the user/client’s computer should be kept to a minimum (i.e., ideally only the session identifier); and
• Session state information should be retained within business logic when possible (i.e., information retained on the web server should be kept to the absolute minimum), and deleted upon termination of the session.

2.8. Access control and authorization

Web Applications must employ access control techniques in a manner consistent with GO-ITS 25.0 access control requirements.

Access to applications

• Centrally managed access controls must be in place to ensure that administrators, users and clients only have access to application functions and program information that are authorized for their specific duties and privileges.
• If a common mechanism is used to control access to applications from different ministries/program areas, the management of administrator, user and client accounts must be securely segmented such that a given ministry/program area manages the access controls for their own application(s).
• The access control process must be subject to a vulnerability assessment and penetration test prior to implementation and when there is a change with security implications.
• Internet users must not be allowed to browse directory listings for file content directly^{footnote 13[13]}, and should be prevented from viewing server-side scripts and active content.
• Programs should establish a policy to govern administrator, user and client access to program information and application functions based on the sensitivity of these resources.
• A role/rules based authorization model should be used. The roles, associated access rights and privileges, and the process for their administration should be formally documented and approved by the Program Manager.
• Prior to defining access controls for a new application, Programs should adjust the assignment of duties and privileges to address processing requirements and any unacceptable security and privacy risks relating to insufficient separation of duties^{footnote 14[14]}.
• Consideration should be given to re-authenticating individuals prior to providing access to more sensitive content/functions or completing a transaction.
• The resources allocated to individual sessions should be limited to guard against denial of service attacks. Higher resource limits should apply for authenticated and authorized individuals.

Access to databases and back-end systems

• There must be no direct traffic from a web server to a data server (e.g., only the application server should communicate directly with the data server), unless the configuration is described as permissible according to GO-ITS 25.11 Security Design Requirements.
• Users and clients must never have direct access to a database (e.g., all user/client access must be via the appropriate application), unless the configuration is described as permissible according to GO-ITS 25.11 Security Design Requirements. Administrator sessions must be restricted to the minimum access needed to fulfill their responsibilities.
• An application’s access privileges for back-end systems or databases must be restricted to the minimum required for the application’s successful operation.
• An application’s credentials and its authentication and access commands must be protected in accordance with the Government of Ontario’s information sensitivity classification Policy.
• All privileged access to databases and back-end systems must be subject to monitoring and audit.

2.9. Logging

Logging capabilities and practices for Web Application components must be consistent with those described in GO-ITS 25.0 General Security Requirements. In addition to those requirements, the following are specific to applications:

• Servers must be configured to send all logs to centralized logging servers located on secure management network;
• Logs must be available for on-line review for a minimum of 6 months;
• Server logs must be classified as per the Government of Ontario’s information sensitivity classification Policy;
• Archived logs must be maintained for 2 years and safeguarded based on the Government of Ontario’s information sensitivity classification Policy and associated guidelines;
• Archived logs must be made available for on-line review within 7 days;
• Three or more invalid access attempts within 60 seconds must generate an alarm;
• Logs must be reviewed daily for intrusion and attack attempts; and
• Privileged account activity must be captured in secure audit logs.

2.10. Time synchronization

All servers associated with Web Applications must obtain or synchronize system time with a redundant and validated reference time source in accordance with GO-ITS 25.0 General Security Requirements.

2.11. Cryptography

Cryptography must be used to protect sensitive information as required by applicable Government standards and policies, or as described in TRA recommendations. This includes transport security for information in transit.

Cryptography deployed for the purpose of protecting Web Applications or Government of Ontario information must comply with the requirements described in GO-ITS 25.12 Use of Cryptography.

The technology used to protect web sessions from interception must be enforced by the application, such that clients cannot negotiate or request unapproved methods of cryptography (e.g., transport encryption that does not comply with published requirements).

A managed certificate issued by an approved Certificate Authority must be used for secure Web Application sessions operated on behalf of the Government of Ontario.

2.12. Data validation

Data received by the application from all potential sources of input (e.g., all input/text fields, hidden fields, URL contents, client-submitted values such as HTTP_REFERER, cookies, etc.) must be validated to protect against a broad range of attacks (e.g., insertion of HTML, XML, Javascript, SQL queries, system commands, buffer overflows, cross-site scripting, directory traversal attempts, etc.).

Input data must be validated at the earliest opportunity on the server side^{footnote 15[15]} before being processed elsewhere within a Web Application.

The validation should take place against a positive specification^{footnote 16[16]} of what is allowed (e.g., data encoding methods, data type, allowed character set, syntax, minimum and maximum length, numeric ranges, specific values or patterns allowed, etc.).

Bound, parameterized views and parameterized statements should be used wherever possible, and client-submitted information must not be directly passed to command execution or SQL queries. For more information, refer to section 5.1 and 5.2 in the Appendix of this document.

2.13. Error handling

A structured error handling approach must be used to minimize information disclosure in production environments. When these applications encounter processing errors, they must respond to the user/client with a generic, sanitized message with no information that might be useful to an attacker.^{footnote 17[17]}  Developers must test the production error handling prior to deploying the application.

3. Related standards

3.1. Impacts to existing standards

Identify any Standards that reference or are referenced by this Standard and describe the impact.

3.2. Impacts to existing environment

4. Appendices

4.1. Developer guidance

Web Application security requires that applications be protected using safeguards and security services (e.g., authentication). Such protected applications then must be free of flaws and vulnerabilities in related source code. The guidance presented in this section addresses these requirements.

The guidance presented in this appendix is intended to assist in addressing both the security vulnerabilities most often observed during Government of Ontario audits and those typically documented in ongoing projects such as the Open Web Application Security Project (OWASP) initiative.

The technical guidance provided will address insecure programming techniques (e.g., security flaws or vulnerabilities) which make Web Application source code vulnerable to subversion or attack. In particular, the guidance is intended to assist developers in protecting applications from the following documented types or classes of known attack:

• Logic weaknesses;
• SQL and command injection;
• Cross-site scripting (XSS);
• Cross-site request forgery (CSRF);
• Application integrity corruption;
• Information leakage;
• Insecure communication;
• Insecure use of cryptography; and
• Runtime resource depletion.

Existing GO-ITS 25 series documentation will provide developers and Program Managers with additional guidance for functional, policy, compliance and system design requirements.

4.2. Application design guidance

The following guidance is provided to assist developers with the secure design of Web Applications.

4.2.1. Secure login / authentication

Article Code: WAS-08

Related Standards: WAS-07
References: OWASP 2007 Top Ten: A7; OWASP 2010 Top Ten: A3; OWASP 2013 Top Ten: A2

Article (Standard) Code: WAS-05

Related Standards: WAS-07
References: OWASP 2007 Top Ten: A5, A7; OWASP 2010 Top Ten: A3, A5; OWASP 2013 Top Ten: A6, A8

.NET specific recommendations:

• Use wildcard mapping mechanisms to integrate ASP.NET security with classical ASP pages.

Java specific recommendations:

• Use Container-managed Security in conjunction with programmatic security.

Article (Standard) Code: WAS-06

Related Standards: WAS-07
References: OWASP 2007 Top Ten: A5, A7; OWASP 2010 Top Ten: A3, A5; OWASP 2013 Top Ten: A6, A8

4.2.2. Secure Session Management

Article Code: WAS-07

Related Standards: N/A
References: OWASP 2007 Top Ten: A5, A7, OWASP 2010 Top Ten: A3, A5, OWASP 2013 Top Ten: A6, A8

4.2.3. Input Validation

Article Code: GS-06 Data Input Validation

Related Standards: SQL-02, GS-03
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8

4.2.4. Secure Error Handling

Article Code: GS-02 Error handling

Related Standards: IL-02, IL-06
References: OWASP 2007 Top Ten: A6; OWASP 2010 Top Ten: A6; OWASP 2013 Top Ten: A6

Article Code: GS-03

Related Standards: IL-06
References: OWASP 2007 Top Ten: A6; OWASP 2010 Top Ten: A6; OWASP 2013 Top Ten: A6

4.2.5 Strong Authorization/Access Control

Article Code: PCI-13

Related Standards: GS-01
References: OWASP 2007 Top Ten: A3; OWASP 2010 Top Ten: A3; OWASP 2013 Top Ten: A2

Article Code: GS-01

Related Standards: GS-04
References: N/A

4.2.6. Secure Audit/Event Logging

Article Code: GS-04

Related Standards: GS-01
References: N/A

4.3. Application development guidance

The following guidance is provided to assist developers in writing secure Web Applications:

4.3.1. Enforce application logic

Application logic that resists subversion and maintains strong internal rules will be more resilient when attacked. Application logic that provides attackers with a way to induce errors or unanticipated results may be vulnerable. Such attacks include:

• Bypassing access control mechanisms;
• Bypassing data validation mechanisms;
• Obtaining unauthorized access to information and/or I&IT assets;
• Unauthorized elevation of system privileges;
• Redirection of legitimate users to illegitimate and/or malicious sites; and
• Resource depletion/Denial of Service.

Logic errors can occur when decision making routines have been incorrectly implemented (or are not complete). They may also be the result of poor presentation of data to the decision-making routine. Such weaknesses can be controlled by careful development of decision making blocks and data presentation to such routines.

Article Code: COR-01

Related Standards: GC-01, GC-06
References: N/A

Article Code: COR-02

Related Standards: GC-01, GC-06
References: N/A

Article Code: COR-03

Related Standards: GC-01
References: N/A

Article Code: COR-04

Related Standards: GC-02
References: N/A

4.3.2. Ensure correct presentation of data

Article (Standard) Code: COR-05

Related standards: SQL-02
References: N/A

Article Code: COR-06

Related standards: SQL-02
References: N/A

4.3.3. Prevent malicious injection

Malicious injection is one of the leading causes of preventable information breaches and system compromises. Protection from this attack vector is critical for all Web Applications. Control over malicious injection will be addressed, including the following widely-documented injection types:

• SQL injection;
• Shell (e.g., session and command execution) injections; and
• Directory services (e.g., LDAP) injections

Detailed standards: SQL-01, SQL-02, SQL-03, SQL-04, SQL-05, SQL-06.

Article Code: SQL-01

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article Code: SQL-02

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article Code: SQL-03

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article Code: SQL-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article Code: SQL-05

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article Code: SQL-06

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

4.3.4. Prevent cross-site scripting

Controls should prevent the ability to construct cross-site scripting attacks against an application.

This weakness is well-understood, widely/easily exploited and is listed in the OWASP 2007, OWASP 2010 and OWASP 2013 Top Ten.

Detailed standards: XSS-01, XSS-02, XSS-03, XSS-04.

Article Code: XSS-01

Related Standards: GS-03, SQL-01, SQL-02
References: OWASP 2007 Top Ten: A1, A5; OWASP 2010 Top Ten: A1, A5 ; OWASP 2013 Top Ten: A1, A8.

Article Code: XSS-02

Related Standards: GS-03, SQL-01, SQL-02, SQL-03, SQL-04, SQL-05, SQL-06
References: OWASP 2007 Top Ten: A1, A5; OWASP 2010 Top Ten: A1, A5; OWASP 2013 Top Ten: A1, A8.

Article Code: XSS-03

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A5; OWASP 2010 Top Ten: A1, A5; OWASP 2013 Top Ten: A1, A8.

4.3.5 Prevent cross-site sequest forgery

Controls should prevent the ability to construct cross-site request forgery attacks against an application.

This weakness is listed in the OWASP 2007, OWASP, 2010 and OWASP 2013 Top Ten.

Detailed standards: CSRF-01, CSRF-02

Article Code: CSRF-01

Related Standards: XSS-01, XSS-02, XSS-03
References: OWASP 2007 Top Ten: A5; OWASP 2010 Top Ten: A5; OWASP 2013 Top Ten: A8.

Article Code: CSRF-02

Related Standards: WAS-06
References: OWASP 2007 Top Ten: A5; OWASP 2010 Top Ten: A5; OWASP 2013 Top Ten: A8.

4.3.6. Prevent Sensitive Information Leaks

Information leakage can provide attackers with valuable information or aid in the planning of attacks. Controls should prevent the leak of sensitive information via an application. All potential channels of information leakage should be addressed, including:

• Application memory;
• Application code; and
• Application-generated output.
• Detailed standards: IL-01, IL-02, IL-03, IL-04, IL-05

Article Code: IL-01

Related Standards: IL-02
References: N/A

Article Code: IL-02

Related Standards: N/A
References: N/A

Article Code: IL-03

Related Standards: N/A
References: N/A

Article Code: IL-04

Related Standards: N/A
References: N/A

Article Code: IL-05

Related Standards: GS-03
References: N/A

4.3.7. Preserve Application Integrity

Controls should ensure that the application code has not been deliberately modified during runtime. Therefore, controls will be applied to an application in terms of the managing application variables (e.g., buffers, arrays, cycles and iterations).

This weakness is listed in OWASP 2007, OWASP  2010 and OWASP 2013 Top Ten.

• Detailed standards: GC-01, GC-02, GC-06

Article Code: GC-01

Related Standards: N/A
References: OWASP 2007 Top Ten: A2, A3; OWASP 2010 Top Ten: A1, OWASP 2013 Top Ten: A1.

Article Code: GC-02

Related Standards: N/A
References: OWASP 2007 Top Ten: A2, A3; OWASP 2010 Top Ten: A1; OWASP 2013 Top Ten: A1.

Article Code: GC-06

Related Standards: N/A
References: OWASP 2007 Top Ten: A2, A3; OWASP 2010 Top Ten: A1; OWASP 2013 Top Ten: A1.

4.3.8. Ensure correct object access

Controls should ensure that the application resources have been properly managed. That is:

• Legitimate paths to an application objects are not misplaced;
• Legitimate object names are not misplaced; and
• All paths to the objects are controlled and/or mutually authenticated/validated.

This weakness is listed in OWASP 2007, , OWASP 2010 and OWASP 2013 Top Ten.

Detailed standards: GC-04, GC-07, GC-08, GC-09, GC-10

Article Code: GC-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8, A10; OWASP 2013 Top Ten: A4, A7, A10.

Article Code: GC-07

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4; OWASP 2013 Top Ten: A4.

Article Code: GC-08

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article Code: GC-09

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article Code: GC-10

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

4.3.9. Prevent manipulation of objects

Controls should prevent the misplacement of legitimate objects with illegitimate ones crafted to construct an attack. This includes controlling:

• Access to application objects; and
• The execution of application modules.
• This weakness is listed in the OWASP 2007, OWASP, 2010 and OWASP 2013 Top Ten.
• Detailed standards: WAS-03, WAS-04, WAS-08

Article Code: WAS-03

Related Standards: WAS-04
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article Code: WAS-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article Code: WAS-08

Related Standards: WAS-04
References: OWASP 2007 Top Ten: A10; OWASP 2010 Top Ten: A8; OWASP 2013 Top Ten: A7.

4.3.10. Secure Use of Cryptography

Controls will be used to ensure the secure use of cryptographic materials and rely on approved/endorsed cryptography. Primarily, encryption keys will be protected by an application to assure:

• Confidentiality;
• Integrity; and
• Validity.
• This weakness is listed in the OWASP 2007, OWASP, 2010 and OWASP 2013 Top Ten.
• Detailed standards: DE-01, DE-02, DE-03, DE-04, DE-05, DE-06, DE-07, DE-08, DE-09, DE-10, DE-11, DE-12, DE-13, DE-14.

Article Code: DE-01

Related Standards: N/A
References: OWASP 2007 Top Ten: A8, A9; OWASP 2010 Top Ten: A7, A9; OWASP 2013 Top Ten: A6.

Article Code: DE-02

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-03

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-05

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-06

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-07

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-08

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-09

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-10

Related Standards: IL-02
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-11

Related Standards: IL-01
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-12

Related Standards: IL-06
References: OWASP 2007 Top Ten: A6, A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-13

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article Code: DE-14

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

4.3.11. Control resource consumption

Controls should ensure that the application resources have been properly managed. This requires that:

• Resources are allocated and released by an application;
• Resources are managed during all states of an application, including failure states; and
• All resources are controlled.
• This weakness can enable other classes of security vulnerability.

Article Code: GC-03

Related Standards: N/A
References: N/A

4.4. Normative references

GO-ITS 20.1 Platform Software Standard

GO-ITS 24.0 Omnibus Web Services Standard

GO-ITS 25.0 General Security Requirements

GO-ITS 25.11 Security Design Requirements

GO-ITS 25.12 Use of Cryptography

GO-ITS 37.0 Enterprise Incident Management Standard

GO-ITS 54.0 Application Development Standard

GO-ITS 56.0 OPS Enterprise Architecture Standard

Corporate Policy on I&IT Security (OPS Intranet)

ISPC Policy

ISPC Procedures (OPS Intranet) (PDF)

Freedom of Information & Privacy Directive (OPS Intranet)

4.5 Informative references

OWASP

OWASP “Top Ten” Project:

PCI-DSS (PDF)

PA-DSS (PDF)

5. Responsibilities

5.1. Users

Users are responsible for:

• Complying with Government directives, policies and agreements when using Government applications and services;
• Safeguarding credentials for Web Applications and using only those services they are authorized to access; and
• Reporting any suspected security breaches to the OPS Service Desk.

5.2. Program Managers

Program Managers are responsible for:

• Endorsing secure development techniques for their projects;
• Completing Government of Ontario information sensitivity classification and Threat/Risk Assessments for Web Applications;
• Arrange Personnel Screening for staff and contractors as appropriate; and
• Ensure Business Continuity and Disaster Recovery Plans are developed, and kept current, for programs under their control.

5.3. Cluster Chief Information Officers:

The Cluster CIOs are responsible for:

• Authorizing appropriate individuals to be granted privileged administrative access or development access to Web Applications, or delegating this authority to an appropriate individual or area (e.g., Program Managers).

5.4. Infrastructure Technology Services (ITS)

ITS is responsible for:

• Developing, implementing and managing any Web Applications which fall outside of vendor network support contracts in accordance with this standard;
• Using secure development techniques when building and deploying new Web Applications;
• Ensuring that logs are securely maintained, available when needed for investigations and retained in accordance with this standard;
• Managing central backup and restore capabilities; and
• Ensuring infrastructure/hosting systems are hardened and patched appropriately.

5.5. Network Service Provider

The Network Service Provider is responsible for:

• Developing, implementing and managing Web Applications operated on behalf of the Government of Ontario in accordance with this standard; and
• Ensuring that logs are securely maintained, available when needed for investigations and retained in accordance with this standard.

5.6. I&IT Strategy, Policy and Enterprise Architecture Branch (SPEAB)

SPEAB, or a successor division/branch, is responsible for:

• Maintaining this standard and all other applicable IT security standards, policies, procedures and related guidance on behalf of the Government of Ontario;
• Supporting developer education efforts; and
• Monitoring the evolution of application security attack techniques.

5.7. Cyber Security Branch (CSB)

CSB is responsible for:

• Co-ordinating responses to enterprise-wide security incidents; and
• Conducting Security Testing and Evaluation (STE) (typically in the form of TRAs, Vulnerability Assessments and Penetration Testing) services for Web Applications.

5.8. Ontario Internal Audit

The Ontario Internal Audit Division is responsible for:

• Conducting periodic audits of pertinent activities to test compliance with security standards;
• Communicating with appropriate management about the risks identified and the severity of those risks; and
• Working with management to identify the needed management action plans to mitigate the risks noted during the course of an audit and conducting follow-up as required.

Glossary

Access: 

Entry to an electronic network provided by the government to its employees and other authorized individuals on or outside government premises, including telework situations.

Access Controls:

Procedures/devices designed to restrict entry to a physical area (physical access controls) or to limit use of a computer/communications system or computer stored data (logical access controls).

Application:

Software code and components that function to provide a service or process transactions.

Authentication:

To establish the validity of a claimed identity of a user prior to gaining access (e.g., passwords, access cards).

Authorization:

To grant permission to access resources according to a predefined approval scheme.

Confidentiality:

The result of safeguards enforcing access to information consistent with the sensitivity of information, competitive position, and legislative requirements (e.g., FIPPA, PIPEDA, PHIPA).

Cryptography:

The transformation of data into a form unreadable by anyone (encryption) without the correct decryption key, ensuring confidentiality by keeping the information hidden from anyone for whom it was not intended, including those who can see the encrypted data.

Data:

Any formalized representation of facts, concepts or instructions suitable for communication, interpretation or processing by a person or by automatic means.

Denial of Service (DoS):

An attempt to make a computer resource unavailable to its intended users. Although the means to, motives for, and targets of a DoS attack may vary, it generally consists of the concerted, malicious efforts of a person or persons to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.

Electronic Network:

Computers and computer systems that can communicate with each other and, without restricting the generality of the foregoing, includes the internet, networks internal to an institution, as well as closed networks external to an institution.

Firewall:

 Software or a hardware device that acts as a barrier between two networks and mediates access between those two networks according to an approved set of rules.

Information:

The meaning derived from or assigned to facts or data, within a specified context.

Information Technology Resources:

Those resources (hardware, software, data, etc.) associated with the creation, storage, processing and communication of information in the form of data, text, image and voice.

Integrity:

The authenticity, accuracy and completeness of data that can be affected by unauthorized or accidental additions, changes and/or deletions.

Mutual Authentication:

Also referred to as two-way authentication refers to two parties authenticating each other suitably. In technology terms, it refers to a client or user authenticating themselves to a server and that server authenticating itself to the user in such a way that both parties are assured of the others' identity.

Network:

IT systems that can be made of one or both of the following components:

• Local Area Network (LAN) - Network of Information technology systems wholly situated at one geographical address;
• Wide Area Network (WAN) - located over more than one geographical site.

Program:

A specific program or service within a Ministry.

Program Manager:

The person responsible for the continued development, operational control, implementation, monitoring, etc. of a specific program or service within a Ministry.

Responsibility:

The obligation to perform a given task or tasks associated with a specific role.

Risk:

  A potential opportunity or threat that may impact on an organization’s ability to meet its business objectives.

Safeguard:

  A protective and precautionary measure to prevent a security event from happening.

Sensitive Information:

Information that has been classified as Medium Sensitivity or High Sensitivity as per the Government of Ontario’s information sensitivity classification Policy and associated guidelines.

User:

A person authorized to access and use Information and Information Technology resources.

Virtual Private Network (VPN):

A logical communications “tunnel” through another network. One common VPN use case is secure communications through the public Internet, but a VPN need not have explicit security features, such as authentication or content encryption. VPNs, for example, can be used to separate the traffic of different user communities over an underlying network with strong security features.