Overview
XCG comprises of several security packages that are distributed as Python packages. Each package, when installed and enabled in Django, either:
- defends your Django application against one or more vulnerability types, i.e. Defensive Packages or
- provides convenient access to functionality that further enhance the security of your application, i.e. Enhanced Security Packages.
Defensive Features
Defensive packages, when installed, defend your Django application against one or more vulnerability types.
The following common web application vulnerabilies are addressed by Defensive packages: click on the package name to read the complete documentation for the package.
Cross-Site Scripting (XSS)
Package: govtech-csg-xcg-dangerousfunctions
XSS vulnerabilities allow an attacker to compromise and masquerade the interactions a user has with the server-sided application by introducing malicious JavaScript to the user. The attacker can carry out actions and access data a user can perform and access. XSS is particularly damaging if the victim has privileged access on the application.
XCG removes unsafe template filters or functions from Django. All HTML, including JavaScript that originates from server-side variables, will always escape before it is returned to the client, with further client-side mitigations.
Remote Code Execution
Package: govtech-csg-xcg-dangerousfunctions
Remote Code Execution or OS command injection vulnerabilities allow attackers to execute arbitrary commands in the application or operating system (OS). This typically compromises the application and all its data completely.
XCG removes unsafe command injection functions from Django.
SQL injection (SQLi)
Package: govtech-csg-xcg-dangerousfunctions
SQLi vulnerabilities are when an attacker interferes with the queries that an application makes to its database. This allows the attacker to access data they are not normally able to retrieve. In some cases, they can even modify or delete data, causing persistent changes to the application's behavior.
XCG removes unsafe SQL functions from Django as all interactions with the database are performed securely through the Object-Relational Mapper (ORM) to mitigate the risk.
Insecure Direct Object Reference (IDOR)
Package: govtech-csg-xcg-securemodelpkid
IDOR is a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. If no other controls are in place, an attacker can simply modify the input value to perform actions on other records that they should not have access to.
XCG modifies Django model objects to use random object identifiers with high entropy, enabling it to harden against IDOR attacks from sequential or guessable identifiers.
Malicious File Upload
Package: govtech-csg-xcg-securefileupload
Malicious File Upload vulnerabilities are when users are allowed to upload files without sufficiently validating file properties such as type, contents, or size. The failure to properly enforce restrictions could allow an attacker to misuse a basic upload function to upload arbitrary and potentially dangerous files that execute on the server when uploaded, or when opened by another user.
XCG validates magic bytes, or inspects file type headers of all uploaded files to match the file-extension of the uploaded file. In addition, XCG also checks against a predefined file-extension whitelist, as well as filename sanitisation, file size limits, and optional anti-virus scans and malicious signature checks.
Server-Side Request Forgery (SSRF)
Package: govtech-csg-xcg-dangerousrequests
SSRF vulnerabilities allow an attacker to induce the server-sided application into requesting access to an unintended location such as internal-only services within the organisation's infrastructure. It can also force the server to connect to external systems, potentially leaking sensitive data such as authorisation credentials.
XCG requires the use of secure request composition, allowing downstream HTTP requests to backends or third-party APIs. Only whitelisted domains/IPs, paths, and methods can be called, eliminating the possibility of attacker-controlled destinations.
Broken Access Control
Package: govtech-csg-xcg-viewpermissions
Broken Access Control vulnerabilities are when a user is allowed access to some resource or perform some action that they are not supposed to. This is typically due to missing authorisation checks before allowing access.
XCG modifies all Django views to be inaccessible by default. Each view must be explicitly annotated by a decorator with a specific role or permission that should be allowed access.
Enhanced Security Features
Enhanced security packages, when installed, provide convenient access to functionality that further enhance the security of your application.
The following functionality are availed to your Django application by Enhanced security packages: click on the package name to read the complete documentation for that package.
Database Credentials and Django Secret Key Rotation with AWS Secrets Manager
Package: govtech-csg-xcg-secretsmanager
Sensitive values such as database credentials and the Django secret key should be stored in a dedicated secret store rather than as environment variables. Such values should also be rotated regularly in order to mitigate against the damage caused by leakage.
The secretsmanager XCG package integrates Django with AWS Secrets Manager such that database connection credentials and the Django secret key can be automatically and transparently retrieved from AWS Secrets Manager. If these secrets are rotated (a feature that AWS Secrets Manager offers), the secretsmanager package is able to gracefully handle the change in values to prevent application downtime (e.g. due to mismatching database credentials). These features ease adoption of AWS Secrets Manager, thereby improving security of secrets storage and retrieval.
Role-Based Access Control (RBAC) for Model Records
Package: govtech-csg-xcg-modelpermissions
Enforcing permissions on views is a good start, but on its own it can only provide coarse-grained access control. Ideally, we would want to enforce permissions at the database record level, to be able to say that user A is allowed access to only records 1, 2, and 3, for example.
Model Permissions enables the assignment and enforcement of such record-level permissions for targeted models, which helps to promote the principle of least privilege when accessing data.
Summary Table
The following table summarises the current XCG packages:
| XCG Package Name | Defensive Feature(s) Supported | Stage of Defensive Measure |
|---|---|---|
| govtech_csg_xcg_dangerousfunctions | Remote Code Execution (RCE), Cross-Site Scripting (XSS), SQL injection (SQLi) | Prevention of exploitation on RCE, XSS, SQLi |
| govtech_csg_xcg_securemodelpkid | Insecure Direct Object Reference (IDOR) | Prevention of exploitation on IDOR |
| govtech_csg_xcg_securefileupload | Malicious File Upload | Detection of malicious file uploads |
| govtech_csg_xcg_dangerousrequests | Server-Side Request Forgery (SSRF) | Prevention of exploitation on SSRF |
| govtech_csg_xcg_viewpermissions | Broken Access Control | Protection of Django views |
| govtech_csg_xcg_secretsmanager | AWS Secrets Rotation | Protection of credentials |
| govtech_csg_xcg_modelpermissions | Role-Based Access Control (RBAC) | Protection of Django models |