Annex B – Content Management System (CMS) Qualifying Procedure

Version: 1.3
Effective: November 30, 2013

Content Management System (CMS) Qualifying Procedure
This document is an annex to the Government Web Hosting Service (GWHS) Memorandum Circular.


1. Introduction
2. Security Audit Procedure
2.1 Process Description
2.1.1 Source Code Analysis and Review
2.1.2 Vulnerability Scanning and Auditing
2.1.3 Verification of Issues Found
2.1.4 Web Crawling
2.1.5 Parameter Tampering
2.1.6 SQL/OS/LDAP Injection Detection
2.1.7 Broken Authentication Detection
2.1.8 Cross Site Scripting (XSS)
2.1.9 Unsecure Direct Object Reference Audit
2.1.10 Security Misconfiguration Audit
2.1.11 Sensitive Data Exposure
2.1.12 Broken Function Access Control Check
2.1.13 Request Forgery (CSRF) Detection
2.1.14 Known Vulnerable Component Check
2.1.15 Unvalidated Redirects and Forwards
2.1.16 File Upload Vulnerability Detection
2.1.15 Report Generation

This document contains the qualifying process to allow agencies’ custom platforms to be hosted under

Specifically, this document shall cover the following:

A) Security audit procedure to allow custom platforms under the web hosting service.
B) Description for each process.

Issuing Authority
The Security Audit Procedure has been developed and issued by the Department of Science and
Technology-Information and Communications Technology Office (DOST-ICT Office) and DOST-Advance
Science and Technology Institute (ASTI), through the iGovPhil Program.

Contact Information
Policies and associated publications under iGovPhil Program can be found at
Queries, suggestions and clarifications with regard to this policy may be forwarded to

1. Introduction

Agencies may use their custom platforms under the Government Web Hosting Service (GWHS). At
the minimum, the custom platforms must meet all the functionalities and capabilities of the
approved Content Management Systems (CMSs), as identified in Annex A of GWHS. These platforms
must pass the security audit procedure.

2. Security Audit Procedure

The flowchart below demonstrates the step-by-step security audit procedure.

Security Audit Procedure - Flowchart - Annex B CMS Qualifying Procedure version 1.3_2013November30 ed


2.1 Process Description:
2.1.1 Source Code Analysis and Review
The Source Code Analysis is designed to evaluate the source code for security flaws.
With the help of particular tools, this review helps analysts zero in on the code’s
relevant portions so they can find the vulnerabilities more effectively.i

2.1.2 Vulnerability Scanning and Auditing
This is a combination of manual and automated processes that aims to seek out security
vulnerabilities of computing systems, basically to determine if and when a system can be

2.1.3 Verification of Issues Found
The analysts verify and zoom in on the found security flaws to assess their impacts to
the system and determine actions to mitigate them.

2.1.4 Web Crawling
Using tools called web robots, crawlers or spiders, web crawling is used to automate
tasks on a particular website. Such tasks include identifying all links and URLs in web

2.1.5 Parameter Tampering
A certain procedure is done to deal with a particular web-based attack in which
parameters in the Uniform Resource Locator (URL) or web page from field data entered
by the user are manipulated by performing a man-in-the-middle attack. Tampered
parameters may not be handled properly by the web application. Measures to prevent
parameter tampering include validation of all parameters to ensure that they adhere to
the standards on minimum and maximum allowable length, character sequences and
patterns, and numeric range.iv

2.1.6 SQL, OS and LDAP Injection Detection
Injection flaws, such as SQL, OS and LDAP injection, enable attackers to pass malicious
code to another subsystem through a poorly designed web application. This is where the
injection detection steps in, specifically to identify the types of injection attacks and to
eliminate the risks brought about by such flaws.v

2.1.7 Broken Authentication Detection
This procedure is performed to proficiently deal with broken authentication security
risk. Through this risk, an attacker can get the user’s important data, e.g., passwords,
impersonate an administrator or another user, or access sensitive data without proper
authentication. The risk arises when web application functions that deal with user
authentication and session management are not properly

2.1.8 Cross Site Scripting (XSS)
XSS flaws need to be checked as these allow the attacker to execute scripts in the
victim’s browser. This attack can lead to website defacement and user sessions being
hijacked. It can as well redirect the end user to a malicious website. Proper filtering and
sanitation of user inputs are recommended to minimize the risk of XSS.vii

2.1.9 Unsecure Direct Object Reference Audit
Analysts need to test web applications for unsecure direct object references to prevent
unauthorized access to data. Direct object references occur when a developer exposes a
reference to an internal implementation object, like database key, file or directory.viii

2.1.10 Security Misconfiguration Audit
Secure settings need to be defined, implemented and maintained to mitigate the risk of
security misconfiguration. This risk occurs when secure configurations for all
frameworks, platforms, and servers are not defined. This also arises when the code
libraries being used by the application are not updated.ix

2.1.11 Sensitive Data Exposure
Attackers may steal or modify weakly protected data to conduct different forms of
crimes. As such, sensitive data deserve extra protection, such as encryption on storage
or in transit.x

2.1.12 Broken Function Access Control Check
Attackers have the ability to forge requests to access functionality without proper
authorization. Hence, as a countermeasure, the broken function access control needs to
be properly checked or audited by analysts.xi

2.1.13 Request Forgery (CSRF) Detection
In this kind of security breach, attackers can send forged HTTP requests to a vulnerable
web application through a logged-on victim who is unaware of the crime.xii The web
application receiving the request has no capacity to verify if the request is sent by the
original user or by the attacker. Thus, there is a need to detect such form of security
breach using a particular tool to modify the HTTP/HTTPS and POST parameters.xiii

2.1.14 Known Vulnerable Component Check
Known vulnerable components, such as frameworks, libraries and other software
modules, need to be evaluated as these can be easily exploited. When these components
are attacked, it can result in severe data loss or, worse, server takeover.xiv

2.1.15 Unvalidated Redirects and Forwards
Unvalidated Redirects and Forwards need to be found and eradicated in the coding,
using a code analysis tool. Unvalidated redirects, in which web applications direct users
to different pages and links without any validation, can lead the end-user to websites
and pages that are malicious and unsecure.xv

2.1.16 File Upload Vulnerability Detection
Uploaded files pose threat to web server. File upload is a way for an attacker to exploit
the victim’s system by executing malicious codes. This then will result in server takeover
and serious data loss. Hence, such vulnerability needs to be detected and processed or

2.1.17 Report Generation
Generating a report of the findings is necessary as this can be used to further enhance
and tighten the security of the application or system.

Revision History

Version Releasing Date Author Status + Description
1.0 November 14, 2013 iGovPhil Program  
1.1 November 18, 2013 iGovPhil Program Revised the flowchart and added some sections
1.2 November 26, 2013 iGovPhil Program Incorporated the comments from Mr. Raymond Nunez and updated the workflow
1.3 November 30, 2013 iGovPhil Program Divided the Annex A into two: List of Approved CMSs (Annex A) and CMS Qualifying Procedure (Annex B)

FOR COMMENTS/SUGGESTIONS, please post it here.

DOWNLOAD a copy.