Once you deploy APTRS using either the manual method or Docker, follow these steps to ensure everything is set up correctly:
+
1. Company
+
Upon the first deployment, APTRS automatically creates a default company named APTRS PVT. This company is designated as the internal company, representing the organization using APTRS to generate reports for clients.
+
+
Key Details:
+
The internal company cannot be deleted or added via the frontend or API.
+
You can edit its name, address, and logo to match your organization’s details.
+
Any additional companies you create will be treated as client companies.
+
+
+
+
2. Groups
+
APTRS includes predefined user groups to facilitate report generation and role management.
+
+
Default Groups:
+
Manager and Project Manager groups are used to include manager details in the reports.
+
It is recommended not to rename or delete these groups, as doing so may cause errors during report generation.
+
+
+
+
3. User and Admin
+
During the first deployment, APTRS creates a default admin user associated with the internal APTRS company.
+
+
Key Details:
+
Do not delete this user, as it is essential for system functionality.
+
You can update the admin user’s profile details, such as:
+
Email address
+
Photo
+
Name
+
Password
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/1.0/search/search_index.json b/1.0/search/search_index.json
index 3e5449f..0553b24 100644
--- a/1.0/search/search_index.json
+++ b/1.0/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Automated Penetration Testing Reporting System","text":"
APTRS (Automated Penetration Testing Reporting System) is a Python, Django and ViteJS-based automated reporting tool designed for penetration testers and security organizations. This tool streamlines the report generation process by enabling users to create PDF, Docx and Excel reports directly, eliminating the need for manual approaches. Additionally, APTRS offers a systematic way to monitor and manage vulnerabilities within various projects. Keep your penetration testing projects organized and efficient with APTRS.
APTRS offers various features and configurations, including the management of companies, customers, projects, retests, different types of reports, configurations, templates, and more. The Features Documentation provides detailed information on the different setups, features, and use cases.
"},{"location":"Features/Users/users/","title":"User Management in APTRS","text":"
APTRS provides robust user management capabilities, allowing you to add, edit, and delete users. Each user can log in to the APTRS platform using their credentials, and they have the option to set a profile photo through the Edit Profile feature. In version 1.0, users are also able to change their passwords.
Internal Users (Staff Users): By default, all users added to the system are marked as staff users, indicating they are internal users of the APTRS.
External Users (Non-Staff Users): External users are designated as non-staff users. For details on managing non-staff users, please refer to the Customer section.
This structured approach to user management ensures that you can effectively manage access levels and user capabilities within the APTRS platform.
"},{"location":"Features/Users/users/#important-note-on-deleting-users","title":"Important Note on Deleting Users","text":"
All projects in APTRS must have an owner. Deleting a user will cause errors, as projects assigned to that user will no longer have an owner. If you need to disable a user\u2019s account, it is recommended to set the account to \"inactive\" rather than deleting it. If you choose to delete the user, be aware that you will need to manually reassign ownership of all the projects associated with that user to avoid issues.
"},{"location":"Features/company/company/","title":"Company Management in APTRS","text":"
APTRS allows you to add and manage companies, with two types of companies supported: Internal Companies and External (Non-Internal) Companies.
APTRS assumes that your company, the one deploying and using APTRS, is the internal company. When you deploy APTRS for the first time, an internal company is automatically created. This company is assigned to you and cannot be deleted or replaced. However, you can rename it to reflect your actual company name.
Key details about internal companies:
Internal Company Setup: The internal company is auto-created during the initial setup, and no additional internal companies can be added afterward.
User Assignment: All users added through the User Management page will automatically be part of the internal company.
Reports: Users and data from the internal company will be reflected in your reports as staff or internal users.
All companies manually added after the initial setup are classified as External Companies. These are typically client companies or third-party organizations.
Key details about external companies:
User Management: You cannot add users to external companies through the User Management page. Any user added through this page will be assigned as a staff member of the internal company.
Assigning Users to External Companies: To assign users to external companies, you need to go through the Customer section, which manages external users.
Projects: You can create projects for both internal and external companies, allowing you to track and manage work for client companies separately from your own.
This setup ensures a clear distinction between your internal users and external client companies, making it easier to manage access, projects, and reports within APTRS.
Warning
Deleting a company will also delete all associated users. Make sure to reassign or handle any users before deleting a company.
"},{"location":"Features/company/customer/","title":"Customer Management in APTRS","text":"
Customers in APTRS are external users who belong to external (non-internal) companies. You can manage these users from the Customer page, where external users are added and tracked, and they are included in reports as customer users.
When adding a customer, you will need to provide the following information:
Email: The customer's email address.
Company: The external company they belong to.
Password: A password is required as part of the future functionality.
Though passwords are required during customer creation, as of version 1.0, external users do not yet have access to login, API, or dashboard features. These features are planned for future releases, where customers will be able to log into the APTRS dashboard, view ongoing and past projects, download reports, and more.
This allows APTRS to lay the groundwork for future functionality while managing customer data and ensuring they are accurately represented in reports.
The Configuration section allows admin users or users with the Manage Configurations permission to add and manage various settings. In APTRS, users can define Project Types, such as \"Mobile Application Testing,\" which are used when creating projects and are also referenced in PDF and DOCX reports. Multiple project types can be added to suit different testing needs.
In addition to project types, users can also create Report Standards. When generating a report, users are required to select the applicable testing standard, such as OWASP for web application testing. Users can add additional standards here, which can then be used in the generated reports.
The Dashboard provides a personalized view of projects based on the logged-in user\u2019s ownership and project status. Unlike the Projects View Page, which lists all projects within APTRS, the Dashboard only displays projects where the logged-in user is the owner and the project is not marked as completed. The Dashboard shows projects with the following statuses: Delay, In Progress, or Upcoming, as long as the user is the owner of those projects.
In addition to active or upcoming projects, the Dashboard also displays completed projects if the project has an active retest. Even if a project is marked as completed, it will be shown in the Dashboard if it has any upcoming, in-progress, or delayed retests where the logged-in user is the owner of the retest task.
This also applies in cases where the user is the owner of the retest task for a completed project, even if the user is not the owner of the original project. In such cases, the project will still appear on the Dashboard, allowing the user to view and manage their active retest tasks.
"},{"location":"Features/permission/permission/","title":"Groups and Permissions in APTRS","text":"
APTRS uses permissions to control access to certain APIs and restrict features to specific users. To streamline this process, APTRS allows you to create groups and assign permissions to those groups. Once a group is created, you can assign users to one or more groups. A user assigned to multiple groups will inherit all the permissions from those groups.
Permissions are pre-defined within APTRS to regulate access to various functionalities. These permissions cannot be modified or created from the user interface, as they are hard-coded in the backend. However, you can create custom groups and assign these predefined permissions to the groups. When users are assigned to a group, they will automatically gain all the permissions associated with that group.
"},{"location":"Features/permission/permission/#admin-users-and-permissions","title":"Admin Users and Permissions","text":"
Admin users in APTRS are not restricted by permissions or group assignments. This means that even if an admin user has no group assigned or is assigned to a group with limited permissions, they will still have full access to all features and APIs in the system. Admin users are always granted full control, regardless of group membership or assigned permissions.
When you first deploy APTRS, several default groups are created with specific permissions. The most important groups are Project Manager and Manager. These groups are crucial for report generation, as they are used to add project manager and manager details to reports.
While you can edit the permissions assigned to these groups, it is important to retain the group names (\"Project Manager\" and \"Manager\") if you want APTRS to correctly include project manager and manager details in the reports. Removing or renaming these groups may cause issues with report generation and prevent the correct user details from being added to reports.
"},{"location":"Features/permission/permission/#list-of-permissions-as-of-version-10","title":"List of Permissions (as of version 1.0)","text":"
Manage Users: Users with this permission can add, edit, and delete users, manage groups, and assign permissions to groups. They can also create and delete groups.
Manage Projects: Users with this permission can create, edit, and delete projects. They can add vulnerabilities or retests within a project, generate reports, and add scope to projects. By default, users cannot select project or retest owners; projects and retests created by users with this permission will automatically mark the creator as the owner.
Assign Projects: This permission allows users to select and assign project or retest owners. Users with this permission can assign any user as the owner of a project or retest.
Manage Vulnerability Data: Users with this permission can add, edit, and delete entries in the vulnerability database or templates.
Manage Customers: Users with this permission can add, edit, and delete customers.
Manage Companies: Users with this permission can add, edit, and delete companies.
Manage Configurations: Users with this permission can manage various application configurations.
Each project can have associated vulnerabilities. You can navigate to the Vulnerability tab within a project to manage its vulnerabilities. This tab allows you to add, edit, or remove vulnerabilities specific to that project, providing a dedicated space to document identified security issues, their descriptions, solutions, CVSS scores, and other relevant details.
Using the Vulnerability Database, you can quickly import common vulnerabilities with pre-filled information, saving time when adding recurring or well-documented issues across multiple projects.
APTRS provides multiple ways to add vulnerabilities to a project, offering flexibility in how you manage and document security issues.
Search and Add: This feature allows you to search for vulnerabilities by title or name from the Vulnerability DB or Template. Once you select a vulnerability from the search results, a new entry is created within the project, automatically populated with the title, description, solution, reference link, and CVSS score from the Vulnerability DB. This approach allows for efficient reuse of information with pre-filled details, saving time on repetitive entries.
Add New: Selecting \"Add New\" will create a blank vulnerability entry within the project. All fields are initially empty except for the title, which is set to \"New Vulnerability.\" This option is ideal if you need to manually document unique vulnerabilities not in the database. You can fill in all required details such as description, solution, and severity.
Upload CSV: This option is designed specifically for importing vulnerabilities from Nessus scan outputs. You can upload a Nessus vulnerability scan CSV report, which APTRS will parse to extract details such as URL or IP, port, title, description, and more. Parsed vulnerabilities are then added directly to the project, saving time on data entry for larger assessments.
This feature can also be used for other, non-Nessus scan reports. As long as the CSV file contains the required columns with matching names, APTRS will process it just like a Nessus report, making it a versatile option for importing vulnerabilities from various sources.
To ensure that vulnerabilities are parsed correctly, your CSV file should include the following columns:
Host: The IP address or URL of the affected system.
Port: The network port where the vulnerability was found.
Name: The title of the vulnerability, providing a brief identifier.
Description: A detailed explanation of the vulnerability, including its nature and potential impact.
Solution: Recommended actions or patches to mitigate or resolve the vulnerability.
Risk: The severity level of the vulnerability (e.g., Info, Low, Medium, High, Critical). APTRS uses this to assign a default CVSS score and vector.
"},{"location":"Features/project/Vulnerability/#cvss-score-and-vector","title":"CVSS Score and Vector","text":"
As of version 1.0, APTRS does not accept CVSS scores and vectors from CSV imports because default Nessus reports do not include them. Instead, APTRS assigns a default CVSS score and vector based on the Risk level provided in the CSV file.
"},{"location":"Features/project/Vulnerability/#default-cvss-scores-and-vectors-cvss-31","title":"Default CVSS Scores and Vectors (CVSS 3.1)","text":"
These default values are automatically assigned based on the risk level when the CSV is parsed:
Severity Base Score Vector Critical 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H High 7.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L Medium 5.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L Low 3.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N Informational 0.0 CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:N
These defaults ensure consistency in reporting for imported vulnerabilities, even if specific CVSS details aren\u2019t included in the CSV file.
Each vulnerability in a project is required to have an instance. An instance represents the specific URL, parameter, IP address, and port number of the affected vulnerability. Each instance within a vulnerability can have its own status, allowing for more granular tracking and resolution.
"},{"location":"Features/project/Vulnerability/#vulnerability-and-instance-status","title":"Vulnerability and Instance Status","text":"
The status of each vulnerability and its instances is tracked individually to provide clear insights into the resolution progress. Below are the details on how the status is managed and calculated for both vulnerabilities and their instances.
The status of a vulnerability and its instances are interconnected. There are three possible statuses for both vulnerabilities and instances:
Vulnerable: The vulnerability or instance has unresolved security issues.
Confirmed Fix: The vulnerability or instance has been resolved and no longer has security issues.
Accepted Risk: The vulnerability or instance remains unresolved, but the customer or client has accepted the associated risk.
These statuses function as follows:
Changing Vulnerability Status: If you change the status of a vulnerability, all instances associated with that vulnerability will automatically be set to the same status. For example, setting a vulnerability to Accepted Risk will update all instances within that vulnerability to Accepted Risk as well.
Changing Instance Status: When modifying the status of individual instances within a vulnerability, the overall vulnerability status is recalculated based on its instances' statuses. The rules are as follows:
Confirmed Fix: For a vulnerability to be marked as Confirmed Fix, all instances must be set to Confirmed Fix. Even a single instance with a different status prevents the vulnerability from being marked as Confirmed Fix.
Vulnerable: If any instance is marked as Vulnerable, the entire vulnerability is marked as Vulnerable, regardless of other instances\u2019 statuses.
Accepted Risk: If all instances are marked as Accepted Risk, the vulnerability status will also be set to Accepted Risk.
In short, for a vulnerability to be considered Confirmed Fix, all instances must be Confirmed Fix. To be marked as Accepted Risk, all instances must have that status. Any instance marked as Vulnerable will cause the vulnerability itself to be marked as Vulnerable.
APTRS allows users to create and manage projects, which are typically created when conducting a pentest for a company. When setting up a project, you can associate it with a specific company, select multiple internal users as project owners, and define key details such as project type, start and end dates, and a brief description.
Once the project is created, you can later add vulnerabilities, generate reports, and track progress within the project. This feature helps organize pentesting efforts efficiently, ensuring clear project ownership and structure.
The project status is automatically calculated based on the project\u2019s start and end dates:
Upcoming: If the start date is in the future.
In Progress: If the start date has passed or is today, but the end date is still in the future.
Delayed: If the end date has passed.
Completed: If the project is marked as completed.
If your project is completed, you can manually mark it as Completed from the project summary. To do this, navigate to the project from the project table or dashboard, and you\u2019ll find an option to mark it as completed on the project summary page.
Once a project is created, it is not possible to change the associated company. However, you can still edit other details, such as project type, dates, description, and owners.
In Version 1.0, APTRS supports assigning multiple project owners, allowing you to add as many project owners as needed. Assigning or selecting a project owner requires admin privileges or the Assign Projects permission. Otherwise, the user creating the project is automatically added as the project owner.
Once your project is ready, you can generate a report for the identified vulnerabilities. APTRS version 1.0 provides options to generate reports in PDF, Excel, and DOCX formats. Navigate to the report section within the project, select the desired report type and standard, and download the report directly.
As of version 1.0, the DOCX report generation feature is experimental. It may be removed or enhanced with more customization options in future versions. Once validated for full customization and consistent presentation, this feature will become permanent.
PDF Reports: APTRS uses the WeasyPrint Python library to convert HTML into PDF. You can modify the HTML and CSS files used in report generation to match your requirements.
DOCX Reports: APTRS leverages the python-docxtpl library to create DOCX files. The CKEditor WYSIWYG editor is used for entering vulnerability and project details. CKEditor\u2019s HTML output is then converted into DOCX format using the html2docx library, and integrated with docxtpl to generate the final report.
The HTML and DOCX report templates are available here: - HTML and DOCX Report Templates
CSS files for HTML-to-PDF reports can be customized here: - CSS for PDF Reports
PDF Reports: APTRS uses the WeasyPrint Python library to generate PDF reports. However, WeasyPrint does not support JavaScript execution, which limits the ability to include custom, interactive charts directly within the PDF. Instead, APTRS generates charts using a Python library and embeds them as static images in the PDF. This approach restricts customization of charts via HTML and CSS.
DOCX Reports: APTRS generates DOCX reports using a combination of python-docx, python-docxtpl, and html2docx. While python-docxtpl enables dynamic content insertion into documents, it does not support updating or dynamically modifying charts. As a result, charts included in DOCX reports cannot be automatically updated with dynamic values by APTRS.
Each project can have a retest task created and assigned to a user. Similar to a project, each retest includes a start and end date and has a designated retest owner. Retests allow you to specify the revalidation of the project\u2019s vulnerabilities, ensuring that fixes have been applied as expected. Within a project, users can initiate a retest to start this process.
Similar to project ownership, the retest owner is automatically set to the user creating the retest if they do not have admin privileges or the Assign Projects permission. Users with admin access or Assign Projects permission can select the retest owner. Once a retest task is created, it cannot be edited, though you can still delete the retest task if needed.
Project Completion Requirement: A retest task cannot be created if the project is not marked as completed. Retests are only applicable to projects that have been fully executed, as retests aim to validate resolved vulnerabilities. Therefore, a project must be completed before any retest can be initiated.
Single Active Retest Restriction: Even if the project is completed, you cannot create a new retest task if there is an existing retest task that is not marked as completed. Only one active retest can be associated with a project at a time.
Each project includes scopes, allowing you to define the list of IPs, URLs, or application names that are part of the engagement. Starting from version 1.0, each project can have multiple scopes. Within the project page, you can navigate to the Scope section to manage the specific scope of the project.
"},{"location":"Features/vulnerabilityDB/vulnerability/","title":"Vulnerability DB (or Template)","text":"
The Vulnerability DB or Template feature in APTRS allows you to add and manage a database of vulnerabilities that can be reused across different projects. When adding a vulnerability to a project, you can specify all necessary details such as the title, description, solution, CVSS score, and more.
If you encounter the same vulnerability in multiple projects, such as IDOR or SQL Injection, the Vulnerability DB allows you to save time by reusing the same information without needing to write it again for each project. This helps streamline reporting and ensures consistency across projects.
By creating templates for common vulnerabilities, you can easily import them when adding vulnerabilities to new projects, reducing redundant work and improving efficiency.
"},{"location":"custom-report/docx/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/docx/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
Description:
This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
Usage Example:
Python
Project Managers:\n\n {% for user in projectmanagers %}\n {{ user.full_name }} {{ user.position }} {{ user.email }}\n {% endfor %}\n
"},{"location":"custom-report/docx/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
Description:
This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
Usage Example:
Text Only
Customer Users:\n\n {% for user in customeruser %}\n {{ user.full_name }} {{ user.position }} {{ user.email }}\n {% endfor %}\n
APTRS provides the ability to generate detailed DOCX reports using customizable templates. You can use Jinja2 template tags within your .docx templates to dynamically populate project and vulnerability data. This guide explains how to customize your template and use available context variables.
Syntax: {% if condition %}...{% else %}...{% endif %}
Example: To check if a project has vulnerabilities:
Python
{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n
"},{"location":"custom-report/docx/docx/#available-context-variables","title":"Available Context Variables","text":"Variable Description project The project object for which the report is being generated. Contains all project details. owners User details of All Project Owners project_exception Project Exceptions project_description Project Description vulnerabilities Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). mycomany The name of the internal (your company) company. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. projectscope Queryset of all project scopes for the project. totalretest List of retest schedules and owners. totalvulnerability Total count of vulnerabilities for the project. Report_type The type of report being generated (e.g., Audit, Re-Audit). standard The standard or methodology being used for the report. currentdate Get Current Date if needed in the report page_break Allows you to add page break in the docx report such as page break after each vulnerability details new_line Allows you to add a new line if needed"},{"location":"custom-report/docx/docx/#docx-formatting-with-jinja2","title":"Docx Formatting with Jinja2","text":"
By default, Jinja2 adds blank lines with conditions or loops, which can be problematic for Docx formatting. Unlike HTML, where empty lines have minimal impact, in Docx, this can lead to extra rows in tables or increased table width.
APTRS uses the docxtpl library, based on Python-docx and Jinja2, for template-based rendering. To reduce blank lines, you can use Jinja2's whitespace control.
However, this method doesn't always work flawlessly; it may inadvertently remove important elements like tables along with extra spaces. A simpler solution can involve using a single line of code.
You can modify the code like this:
Python
##Instead of new line for code\n{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n\n\n## you can change it to like this on a single line \n\n{% if vulnerabilities %} Vulnerabilities are present. {% else %} No vulnerabilities found. {% endif %}\n
"},{"location":"custom-report/docx/docx/#color-and-conditions","title":"Color and Conditions","text":"
Each severity level in the report is represented by different colors: low or informational is often green or light blue, while high severity is red. Status can also be color-coded, with fixed vulnerabilities in green and open ones in red or orange.
In HTML reports, you can add severity values to the tag's class attribute and create CSS to apply the colors.
For DOCX reports, colors cannot be applied to undefined elements, limiting customization. To assign colors based on severity\u2014like red for critical and orange for high\u2014include them directly in the conditional statements within your DOCX template.
Python
{% if severity == 'Critical' %} severity with red color. {% elif severity == 'Low' %} severity with green color. {% endif %}\n
Note
Adding Jinja2 White Space control to this will remove the color.
What if instead of just color for the text, we want to add color for the cell in the table like below
Name Status Severity SQL Injection Vulnerable Confirm Fixed
We can do that as well with cellbg in the table, with hex color code like below:
Python
{% cellbg 'FF491C' if vulnerability.vulnerabilityseverity== 'Critical' else 'F66E09' if vulnerability.vulnerabilityseverity== 'High' else 'FBBC02' if vulnerability.vulnerabilityseverity== 'Medium' else '20B803' if vulnerability.vulnerabilityseverity== 'Low' else '3399FF' %}{{ vulnerability.vulnerabilityseverity}}\n
"},{"location":"custom-report/docx/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/docx/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
Description: Provides the total count of vulnerabilities associated with a project.
Usage Example: You can display the total number of vulnerabilities for the project.
Description: The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
Usage Example: Display the methodology or standard used in the vulnerability report.
Python
Report Standard: {{ standard|join(', ') }} \n
"},{"location":"custom-report/docx/other/#4-current-date","title":"4. Current Date","text":"
Description: Get the current date if needed in the report.
"},{"location":"custom-report/docx/project/","title":"Project","text":""},{"location":"custom-report/docx/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report Docx, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/docx/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
project.name
Represents the name of the project.
Example usage in HTML: Python
Project Name: {{ project.name }}\n
project.companyname
A foreign key to the Company model, representing the company associated (Customer Company) with the project.
Example usage: Python
Company Name: {{ project.companyname.name }}\n
project_exception
A detailed description of the project.
Example usage: Python
Description: {{p project_exception}}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
Project End Date: {{project.enddate.strftime(\"%d/%m/%Y\") }}\n
project.testingtype
The type of testing performed for the project (e.g., White Box, Black Box).
Example usage: Python
Testing Type: {{ project.testingtype }}\n
project_exception
Notes or exceptions for the project, if any.
Example usage: Python
Exceptions: {{p project_exception }}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
In most cases if you don't have exceptions and in your report you only this if exception is there you are also do it with conditions. Python
{% if project_exception %}\nExceptions: {{p project_exception }}\n{% endif %}\n
project.owner
Note: This is not available, due to issues with the method provided by django to loop many to many database relation, it does not work with the jinja2.
project.status
The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).
Example usage: Python
Status: {{ project.status }}\n
In order to get Project owner details, APTRS provide a seperate context and tag owners which contain user details for project owners. In order to use it you have to loop through details like below:
Python
{% for owner in owners %}\n {{ owner.full_name}}\n {{ owner.email}}\n {{ owner.position}}\n {{ owner.number}}\n {% endfor %}\n
"},{"location":"custom-report/docx/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status.
Usage Example: You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
Python
Project Retests:\n\n {% for retest in totalretest %}\n {{ retest.startdate }} {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owners %}\n {{ owner }}\n {% endfor %}\n\n {% endfor %}\n
Note
The {{ owner }} will only show the full_name of the owner, as of now its limited to full name only.
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
HTML
{% if Report_type == 'Re-Audit' %}\n Project Retests:\n\n {% for retest in totalretest %}\n {{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owners %}\n {{ owner }}\n {% endfor %}\n\n {% endfor %}\n\n{% endif %}\n
"},{"location":"custom-report/docx/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
Usage Example:
Python
Project Scope:\n\n {% for scope in projectscope %}\n {{ scope.scope }} {{ scope.description }}\n {% endfor %}\n</ul>\n
"},{"location":"custom-report/docx/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/docx/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. APTRS provide {{vulnerabilities}} tag with list of all vulnerabilities and its instances. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/docx/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
vulnerability.vulnerabilityname
The name of the vulnerability (e.g., \"SQL Injection\").
Example usage: Python
{% for vulnerability in vulnerabilities %}\nVulnerability Name: {{ vulnerability.vulnerabilityname }}\n{% endfor %}\n
vulnerability.vulnerabilityseverity
The severity of the vulnerability (e.g., \"High\", \"Medium\").
Example usage: Python
{% for vulnerability in vulnerabilities %}\nSeverity: {{ vulnerability.vulnerabilityseverity }}\n{% endfor %}\n
vulnerability.cvssscore
The CVSS score associated with the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCVSS Score: {{ vulnerability.cvssscore }}\n{% endfor %}\n
vulnerability.cvssvector
The CVSS vector associated with the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCVSS Vector: {{ vulnerability.cvssvector }}\n{% endfor %}\n
vulnerability.status
The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).
Example usage: Python
{% for vulnerability in vulnerabilities %}\nStatus: {{ vulnerability.status }}\n{% endfor %}\n
vulnerability.vulnerabilitydescription
A description of the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nDescription: {{p vulnerability.vulnerabilitydescription }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.POC
The proof of concept (POC) for the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nPOC: {{p vulnerability.POC }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.vulnerabilitysolution
The recommended solution for the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nSolution: {{p vulnerability.vulnerabilitysolution }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.vulnerabilityreferlnk
A reference link related to the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nReference Link: {{p vulnerability.vulnerabilityreferlnk }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.created
The timestamp when the vulnerability was created.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCreated: {{ vulnerability.created }}\n{% endfor %}\n
vulnerability.created_by
The user who created the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCreated By: {{ vulnerability.created_by.username }}\n{{ vulnerability.created_by.full_name }}\n{% endfor %}\n
Similar to project owner, you can use other filed as well like email, number or postion etc.
vulnerability.last_updated_by
The user who last updated the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nLast Updated By: {{ vulnerability.last_updated_by.username }}\n{{ vulnerability.last_updated_by.full_name }}\n{% endfor %}\n
vulnerability.instances_data
Acess all instaces of the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\n\n {for instance in vulnerability.instances_data %}\n ## This give all instances for vulnerabiltiy in current loop\n\n URL: {{ instance.URL }}\n Parameter: {{ instance.Parameter }}\n Parameter: {{ instance.Status }}\n\n {% endfor %}\n\n{% endfor %}\n
"},{"location":"custom-report/pdf/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/pdf/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
Description:
This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
Usage Example:
HTML
<h3>Project Managers:</h3>\n <ul>\n {% for user in projectmanagers %}\n <li>{{ user.full_name }} - {{ user.position }}</li>\n {% endfor %}\n </ul>\n
"},{"location":"custom-report/pdf/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
Description:
This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
Usage Example:
HTML
<h3>Customer Users:</h3>\n <ul>\n {% for user in customeruser %}\n <li>{{ user.full_name }} - {{ user.position }}</li>\n {% endfor %}\n </ul>\n
This document describes how to customize the HTML templates used to generate PDF reports using the GetHTML function in your Django application. Below are the available context variables that can be used in the HTML templates and their respective details.
The following context variables are passed to the HTML template (report.html) during PDF generation. Users can use these variables to dynamically customize the content of the PDF report.
Variable Name Description project The project object for which the report is being generated. Contains all project details. vuln Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). instances Queryset of all vulnerable instances associated with the project. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. mycomany The name of the internal (your company) company. projectscope Queryset of all project scopes for the project. totalretest Queryset of all retests for the project. totalvulnerability Total count of vulnerabilities for the project. ciritcal Count of vulnerabilities with severity \"Critical\". high Count of vulnerabilities with severity \"High\". medium Count of vulnerabilities with severity \"Medium\". low Count of vulnerabilities with severity \"Low\". info Count of vulnerabilities with severity \"Informational\" or \"None\". standard The standard or methodology being used for the report. Report_type The type of report being generated (e.g., Audit, Re-Audit). pie_chart Rendered pie chart data showing the vulnerability distribution by severity."},{"location":"custom-report/pdf/context-variable/#how-to-customize-templates","title":"How to Customize Templates","text":"
Locate the HTML Template:
The report template is located at templates/*. You can modify this file or create a new one for different report types.
Use Context Variables:
Insert the context variables into the template using Django's template syntax. For example: HTML
<h1>Vulnerability Report for {{ project.name }}</h1>\n<p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n<p>Critical Issues: {{ ciritcal }}</p>\n<p>High Severity Issues: {{ high }}</p>\n
Dynamic Content:
Use loops and conditionals to dynamically render data. For example: HTML
<ul>\n{% for vuln in vuln %}\n <li>{{ vuln.vulnerabilityname }} - Severity: {{ vuln.vulnerabilityseverity }}</li>\n{% endfor %}\n</ul>\n
Styling and Charts:
Use {{ pie_chart|safe }} to embed the rendered pie chart in the HTML. Ensure that the safe filter is applied to include raw HTML safely.
"},{"location":"custom-report/pdf/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/pdf/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
Description: Provides the total count of vulnerabilities associated with a project.
Usage Example: You can display the total number of vulnerabilities for the project.
Description: The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
Usage Example: Display the methodology or standard used in the vulnerability report.
Description: This variable holds the rendered data for a pie chart showing the distribution of vulnerabilities by severity.
Usage Example: Use this to display a pie chart visualizing vulnerability severity distribution.
HTML
<div>{{ pie_chart|safe }}</div>\n
"},{"location":"custom-report/pdf/pdf/","title":"Customized PDF Report Documentation","text":"
APTRS uses the WeasyPrint library to generate PDF reports from HTML and CSS. The Django template engine dynamically passes data to the HTML template using context variables.
"},{"location":"custom-report/pdf/pdf/#how-it-works","title":"How It Works","text":"
The system is designed so you don\u2019t need to edit the Django code that handles report generation unless you are familiar with Django and Python. The recommended approach is to customize the layout and styling by modifying the HTML and CSS files provided with the project.
"},{"location":"custom-report/pdf/pdf/#file-structure-for-customization","title":"File Structure for Customization","text":"
Within the project root directory, there is a subdirectory named APTRS. This contains the following important folders for report customization:
Static Folder:
Located inside the APTRS directory.
Contains a CSS subfolder where all CSS files for the report are stored.
Includes predefined styles that you can customize to adjust the appearance of the report.
Templates Folder:
Located in the same directory as the static folder.
Contains all the HTML templates used for generating reports.
Templates are modular, with the main report layout in report.html and additional reusable components loaded using Django's {% include %} tag.
"},{"location":"custom-report/pdf/pdf/#key-files-for-customization","title":"Key Files for Customization","text":"
report.html:
The main HTML file for the report.
Includes the overall structure, head tags, and references to CSS files.
Dynamically includes other HTML components for better modularity.
report-page.css:
The primary CSS file applied to all report pages.
Handles global styles such as font loading, page numbering, table styles, and default styles for HTML tags.
Defines general formatting applied across the entire report.
Component Files:
Each HTML file has a corresponding CSS file for specific styles.
For example, styles specific to an HTML section like vulnerability.html will be defined in vulnerability.css.
This structure ensures easy identification and modification of styles tied to specific sections.
Avoid editing the Django code unless necessary, as it handles the logic for passing variables and generating the PDF.
All changes to the static files (CSS) or templates (HTML) will reflect in the next report generated.
"},{"location":"custom-report/pdf/project/","title":"Project","text":""},{"location":"custom-report/pdf/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report HTML, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/pdf/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
project.name
Represents the name of the project.
Example usage in HTML: HTML
<h1>Project Name: {{ project.name }}</h1>\n
project.companyname
A foreign key to the Company model, representing the company associated (Customer Company) with the project.
The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).
Example usage: HTML
<p>Status: {{ project.status }}</p>\n
"},{"location":"custom-report/pdf/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status.
Usage Example: You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
HTML
<h3>Project Retests:</h3>\n <ul>\n {% for retest in totalretest %}\n <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owner.all %}\n {{ owner.full_name }}\n\n {% endfor %}\n </li>\n {% endfor %}\n </ul>\n
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
HTML
{% if Report_type == 'Re-Audit' %}\n <h3>Project Retests:</h3>\n <ul>\n {% for retest in totalretest %}\n <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owner.all %}\n {{ owner.full_name }}\n\n {% endfor %}\n </li>\n {% endfor %}\n </ul>\n{% endif %}\n
"},{"location":"custom-report/pdf/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
Usage Example:
HTML
<h3>Project Scope:</h3>\n<ul>\n {% for scope in projectscope %}\n <li>{{ scope.scope }} - {{ scope.description }}</li>\n {% endfor %}\n</ul>\n
"},{"location":"custom-report/pdf/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/pdf/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
vulnerability.vulnerabilityname
The name of the vulnerability (e.g., \"SQL Injection\").
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Vulnerability Name: {{ vulnerability.vulnerabilityname }}</p>\n{% endfor %}\n
vulnerability.vulnerabilityseverity
The severity of the vulnerability (e.g., \"High\", \"Medium\").
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Severity: {{ vulnerability.vulnerabilityseverity }}</p>\n{% endfor %}\n
vulnerability.cvssscore
The CVSS score associated with the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>CVSS Score: {{ vulnerability.cvssscore }}</p>\n{% endfor %}\n
vulnerability.cvssvector
The CVSS vector associated with the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>CVSS Vector: {{ vulnerability.cvssvector }}</p>\n{% endfor %}\n
vulnerability.status
The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Status: {{ vulnerability.status }}</p>\n{% endfor %}\n
vulnerability.vulnerabilitydescription
A description of the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Description: {{ vulnerability.vulnerabilitydescription|clean_html }}</p>\n{% endfor %}\n
vulnerability.POC
The proof of concept (POC) for the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>POC: {{ vulnerability.POC|clean_html }}</p>\n{% endfor %}\n
vulnerability.vulnerabilitysolution
The recommended solution for the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Solution: {{ vulnerability.vulnerabilitysolution|clean_html }}</p>\n{% endfor %}\n
vulnerability.vulnerabilityreferlnk
A reference link related to the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Reference Link: {{ vulnerability.vulnerabilityreferlnk|clean_html }}</p>\n{% endfor %}\n
vulnerability.created
The timestamp when the vulnerability was created.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Created: {{ vulnerability.created }}</p>\n{% endfor %}\n
vulnerability.created_by
The user who created the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Created By: {{ vulnerability.created_by.username }}</p>\n{{ vulnerability.created_by.full_name }}</p>\n{% endfor %}\n
Similar to project owner, you can use other filed as well like email, number or postion etc.
vulnerability.last_updated_by
The user who last updated the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Last Updated By: {{ vulnerability.last_updated_by.username }}</p>\n{% endfor %}\n
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerableinstance-model","title":"Available Variables for Vulnerableinstance Model","text":"
instance.vulnerabilityid
The Vulnerability object associated with the instance.
Example usage: HTML
{% for instance in instances %}\n<p>Vulnerability Name: {{ instance.vulnerabilityid.vulnerabilityname }}</p>\n{% endfor %}\n
instance.project
The project associated with the vulnerable instance.
Example usage: HTML
{% for instance in instances %}\n<p>Project: {{ instance.project.name }}</p>\n{% endfor %}\n
instance.URL
The URL of the vulnerable instance.
Example usage: HTML
{% for instance in instances %}\n<p>URL: {{ instance.URL }}</p>\n{% endfor %}\n
instance.Parameter
The parameter of the vulnerable instance.
Example usage: HTML
{% for instance in instances %}\n<p>Parameter: {{ instance.Parameter }}</p>\n{% endfor %}\n
instance.status
The status of the vulnerable instance, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).
Example usage: HTML
{% for instance in instances %}\n<p>Status: {{ instance.status }}</p>\n{% endfor %}\n
"},{"location":"custom-report/pdf/vulnerability/#displaying-vulnerable-instances-for-a-specific-vulnerability-in-a-template","title":"Displaying Vulnerable Instances for a Specific Vulnerability in a Template","text":"
The instances query set or list does not associate with the vulnerability name, instances variable contain all instances for the project, In most cases we need all instances for a vulnerability. We can do that as well, you can check in the original vulnerabilities.html in the template or you can use this:
To display the instances for a specific vulnerability within a loop for vulnerabilities, you can use the following approach:
Yonathan johnson Started creating the frontend using React. Although he could not complete the development due to certain circumstances, his initiative and effort are greatly appreciated.
Automated Report Generation: APTRS automates creating comprehensive penetration testing reports, saving time and ensuring consistency.
PDF Docx, and Excel Reports: Generate professional-looking PDF, Docx and Excel reports with ease, providing clients and stakeholders with clear insights into security assessments.
Vulnerability Management: APTRS helps you keep track of vulnerabilities across different projects, allowing for efficient management and mitigation.
User-Friendly Interface: The tool is designed with a user-friendly interface, making it accessible for both novice and experienced penetration testers.
Customization: Tailor your reports to meet specific project requirements, ensuring that the generated reports align with your organization's standards.
Project and Customer Management: Manage all your projects, retest, and customer all in one place. The user and project tracking allows you to monitor the user's project allocation, plans, and status.
Explore the features of APTRS through our live demo instance:
Live Demo
Username: sourav.kalal@aptrs.com
Password: I-am-Weak-Password-Please-Change-Me
Feel free to interact with the tool and see how APTRS can streamline your penetration testing workflows.
\ud83c\udf28\ufe0f Huge thanks to DigitalOcean for their support of the APTRS project.
Warning
\ud83d\udea7 APIs related to user profiles and user management, such as adding, editing, deleting users, and changing passwords, are disabled on the cloud-hosted demo instance.
The APTRS project is released under the MIT License, which is a permissive open-source license allowing anyone to use, modify, and distribute the software freely. This license ensures that the software remains open and accessible while permitting both personal and commercial use, provided that the original copyright notice and license terms are included in all copies or substantial portions of the software
APTRS uses HTTPS with a self-signed certificate. If you would like to replace the self-signed certificate with your own, you can do so by updating the certificate and key files located at:
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncopy env.docker .env\nnotepad .env\ndocker-compose up \n
Note
The .env file contains all the environment variables, such as passwords for JWT, Database credentials, Cloud S3 bucket details, etc. It\u2019s important to update the default passwords and details before deploying the application. For more information, refer to the Environment Variables section.
The APTRS backend uses the .env file to store credentials such as S3 bucket information, database credentials, secret keys, whitelisted IPs/domains, and more.
If you are deploying the application with Docker, make sure to update the details in the .env file from the project root.
If you are deploying the application without Docker, you will need to update specific details like the S3 bucket and whitelisted IPs.
ENV Description Docker Linux Server Manual Setup SECRET_KEY This key is used by Backend including JWT, Should be secured and random. Manually need to be updated in env file Manually need to be updated in env file WHITELIST_IP This allows to set whitelisted IP/domain with port number to allow loading resource during PDF report to prevent SSRF vulnerability. Manually need to be updated in env file, make sure to keep the https://nginx as its required to connect with nginx within Docker Manually need to be updated in env file based on your domain name, IP etc. ALLOWED_HOST Whitelist allowed host to prevent host header injection attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. CORS_ORIGIN Whitelist allowed origin to prevent cross origin attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. REDIS_URL Redis Server Details including IP, Port and password Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Do not update other details except password Manually need to be updated in env file for REDIS password, IP and Port details REDIS_PASSWORD Redis Server password for Redis image in docker Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Password in REDIS_URL and REDIS_PASSWORD should be same Not needed and no need to update/add. POSTGRES_USER , POSTGRES_PASSWORD, POSTGRES_PORT, POSTGRES_DB Postgres DB username, password, port, and DB names Manually need to be updated in env file Manually need to be updated in env file. POSTGRES_HOST Postgres host name Should not be updated. Manually need to be updated in env file. USE_S3 If you want to use Cloud S3 bucket Digital Ocean or AWS s3 bucket. Default False, you can change it to True Optional Optional AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_STORAGE_BUCKET_NAMEAWS_S3_REGION_NAMEAWS_S3_CUSTOM_DOMAINAWS_S3_ENDPOINT_URL Bucket details if USE_S3 is set to True Optional Optional USE_DOCKER Used by APTRS Django code to validate if application deployed on Docker or Not Optional, It is already declared as True in Docker file Required to set to FalseUSER_TIME_ZONE Used by APTRS Django code and Background task schedule time using celery Required to set the local time zon or UTC Required to set the local time zon or UTC
APTRS now includes the source code of the Vite.js frontend by default, instead of a pre-built version. This change allows you greater flexibility to customize the frontend as needed. If you are deploying the application using Docker, the build process is handled automatically, so you don't need to worry about creating a production build manually.
However, if you choose to manually deploy APTRS, you will need to manually build the production version of the frontend and serve it using Nginx or any other reverse proxy.
To build the production version from the Vite.js source code, follow these steps:
Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncd Frontend\ncp env.example .env\nnpm run build\n
Note
The .env file contains settings like the backend API domain and app environment. You can modify these as needed.
By default, APTRS serves both the backend and frontend on the same server, meaning they share the same IP/domain and port. The .env file uses just /api/ in docker build for the backend API domain. This setup is recommended to avoid issues with image uploads in the CKEditor within APTRS and to prevent conflicts related to Same-Origin policies.
"},{"location":"installation/frontend/#hosting-the-frontend-and-api-together","title":"Hosting the Frontend and API Together","text":"
If you wish to host the frontend on a separate domain, IP, or port from the backend API, you can configure the backend API's domain in the .env file within the Frontend folder. For example:
Bash
nano .env\n\nVITE_APP_API_URL = http://backend-api.com/api/\nnpm run build\n
However, it is not recommended to host the API and frontend on separate domains, IPs, or ports. Here's why:
JWT Token Authentication and Cookies:
The API uses a combination of JWT tokens in headers and cookies for authentication and access control.
Cookies are domain-specific and cannot be shared across different domains unless explicitly configured with a domain-wide scope. This can lead to complexities in maintaining secure cross-domain authentication.
Static Image Loading Issues:
Browsers do not allow custom headers, such as JWT tokens, for loading static resources like images.
APTRS addresses this by using cookies for authentication, allowing images protected by the API to be loaded by authenticated users. However, this setup is difficult to manage across separate domains, as it relies on cookies being available in the same domain scope.
Unified Image Path Management:
APTRS supports storing images locally or on S3. Using the API for image access ensures consistency, as images are accessed through the same API endpoint regardless of their storage location.
This approach prevents exposing hardcoded S3 bucket URLs in CKEditor or frontend code. Additionally, if the S3 bucket URL changes or signed URLs expire, the API path remains consistent.
Image Management with CKEditor:
APTRS manages images uploaded through CKEditor by serving them directly via the backend API, rather than using a web server. This design ensures that sensitive images, such as those used for proofs of concept (POCs), are accessible only to authenticated users. These images are protected by authentication tokens and are not publicly exposed.
CKEditor uses <img> tags with a src attribute pointing to the API's image path. For example:
"},{"location":"installation/frontend/#challenges-with-hosting-the-api-and-frontend-on-separate-domains","title":"Challenges with Hosting the API and Frontend on Separate Domains","text":"
When the API is hosted on a separate domain from the frontend:
CKEditor hardcodes the API domain in the src attribute of the images.
If the API domain name, IP, or port changes, previously uploaded images will fail to load, as CKEditor cannot dynamically update the src attribute.
Additionally, browsers loading static resources like images do not support custom headers (e.g., JWT tokens), which can complicate access control for images requiring authentication.
"},{"location":"installation/frontend/#benefits-of-hosting-api-and-frontend-on-the-same-domain","title":"Benefits of Hosting API and Frontend on the Same Domain","text":"
If both the API and frontend are hosted on the same domain, the frontend can be built with VITE_API_URL=/api/. This approach allows CKEditor to generate image paths relative to the frontend's base domain, such as:
HTML
<img src=\"/api/path/to/image.jpg\" />\n
This configuration provides several advantages:
Domain Independence: The image path (/api/path/to/image.jpg) remains valid even if the domain name, IP address, or port changes, as long as the API and frontend share the same base domain.
Simplified Image Access: The relative path ensures that images are seamlessly accessible without hardcoding the API domain, reducing the risk of broken links if deployment configurations change.
Consistent User Experience: End users can load images securely without encountering authentication or cross-domain issues.
Use a reverse proxy, such as Nginx, to host both the API and frontend on the same domain.
Configure the frontend to use VITE_API_URL=/api/.
This setup improves maintainability and ensures robustness against deployment changes, as the relative paths remain valid even if the domain name, IP, or port changes.
Deploying Frontend and Backend on Separate Servers
If you require separate servers for the frontend and backend (e.g., for scalability, load balancing, or easier maintenance), you can still serve both on the same domain or IP and port for users by using a reverse proxy.
For example, you can deploy the frontend on one server and the backend on another, but configure your reverse proxy to route requests based on the path:
Requests to /api/*, media/*, static/* are proxied to the backend server.
Other requests (e.g., for the frontend) are served by the frontend server.
Manual (User with Knowledge of Nginx and Little Python and Nodejs)
Note
APTRS does not natively support Windows installations and setting it up on Windows is not recommended. While it's possible to manually install certain components (such as the APTRS Backend, Frontend, and Database) on Windows, key dependencies like Redis require a Linux environment. Instead, you can use the Docker setup for Windows, which is the preferred option for Windows users.
Note
Default creds are sourav.kalal@aptrs.com & I-am-Weak-Password-Please-Change-Me
Note
APTRS uses cookie attributes such as Secure, HttpOnly, and Lax. For users with a Docker setup, these attributes will not have any effect. However, users with a manual setup need to ensure that they use HTTPS and that both the front end and back end are on the same domain or IP address.
If you prefer to install the APTRS without Docker and have more control over each service, such as Redis, Postgresql, Nginx, etc., or if you want to host the database on a different server, Redis on a different server, etc., you can follow the below process for deploying the APTRS on a server without Docker.
The steps mentioned below were tested on the below setup:
OS - Ubuntu 24.10
Python - 3.12.7 \u00a0(3.9+ is required)
Python Poetry - 1.8.4
PostgreSQL - 16.4 (Ubuntu 16.4-1build1)
Redis Server - 7.0.15
Nginx - 1.26.0
NodeJS - 20.16.0 (18+ is required)
NPM - 9.2.0
Note
While we have provided detailed steps for manual installation and deployment, please note that this method is more prone to errors. Variations in software versions, updates, system configurations, and other factors may result in unexpected issues. Manual installation is intended for individuals who have a solid understanding of Linux, some level of development experience, or expertise in application deployment, and are comfortable troubleshooting potential errors that may arise.
After the installation is complete, we can access the PostgreSQL shell using the command below.
Bash
sudo -u postgres psql\n
From the PostgreSQL shell, create a new database for the APTRS project. Change the name to something relevant to the project.
Bash
CREATE DATABASE aptrsdb;\n
Next, create a database user for our project. Make sure to select a secure password:
Bash
CREATE USER aptrsdb_user WITH PASSWORD 's!!D%AriPB-MO~5';\n
We will set the default encoding to UTF-8 and adjust other settings. Please update the time zone according to your preference, and ensure we use the same time zone as the APTRS.
Bash
ALTER ROLE aptrsdb_user SET client_encoding TO 'utf8';\nALTER ROLE aptrsdb_user SET default_transaction_isolation TO 'read committed';\nALTER ROLE aptrsdb_user SET timezone TO 'UTC';\n\n\\c aptrsdb;\nGRANT USAGE ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO aptrsdb_user;\nALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON TABLES TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON DATABASE aptrsdb TO aptrsdb_user;\n\\q\n
After completing our tasks, we ensure that the PostgreSQL service is running and set to start automatically on reboot.
By default, Poetry is not added to the user or system environment. Ensure you add it to the environment.
Bash
export PATH=\"/home/aptrs/.local/bin:$PATH\"\n
Once completed, we can download the APTRS from GitHub, install the dependencies, and copy the example .env file.
Bash
cd /home/aptrs\ngit clone https://github.com/APTRS/APTRS\ncd APTRS\npoetry install\ncd APTRS\ncp env.example .env \u00a0# The .env file should be located in the same directory as the manage.py file.\n
After obtaining the .env file from the demo environment file, ensure that you update it with the following details: the password for Redis, the PostgreSQL hostname or IP address, the Redis hostname or IP address, the secret key, and any other necessary information. It's important to review all the details in the .env file carefully. For more information on configuring the .env file and the various data it contains, please refer to the Environment Variables section.
Few Important details for .env file:
WHITELIST_IP: Add the server domain name if you're using one; if using a public IP, include that as well. For local network access, add the server's internal IP to the whitelist. Specify the protocol (HTTP or HTTPS) and use Nginx instead of the Django default port (8000). You don\u2019t need to specify a port if using HTTP on 80 or HTTPS on 443. If using S3 buckets, include the bucket URL.
CORS_ORIGIN: Since the frontend and backend will be on the same server, simply allow the server's public or local IP, along with the appropriate protocol and port, if necessary. Both frontend and backend should be accessible via the same domain or IP using Nginx reverse proxy. For more details, check the Frontend documentation.
ALLOWED_HOST: Set this only for the server's domain name or public/internal IP, based on how APTRS will be accessed.
SECRET_KEY: Make sure to update it with a secure key; the same key will be used to generate a JWT token.
From the directory where manage.py is located, run the command below.
Once we have completed the required setup, we need to start the server. APTRS uses Gunicorn for this purpose, which should already be installed through the steps we have completed so far. Since we are using Poetry, we need to locate the full path of Gunicorn for the APTRS project using the command below:
Bash
$> cd /home/aptrs/APTRS\n$> poetry run which gunicorn\n\n##We might get the full path like below, this will be different for all users\n/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn\n
Once we have the full path for gunicorn, we can set up the gunicorn.service with the command below:
Bash
sudo nano /etc/systemd/system/gunicorn.service\n
In the nano file editor, paste the following text. Ensure to update the full path for gunicorn in the gunicorn.service file.
After installing NPM and Node.js, we need to create a .env file for the front end. This .env file will contain the URL for the backend Django API. Since we plan to deploy both the API and the frontend on the same server and they will be accessible through the same domain or IP address using Nginx, we will specify the backend URL as /api/. For more details, please refer to the Frontend documentation.
Bash
cd /home/aptrs/APTRS/frontend\ncp env.example .env\nnano .env\n
In the Nano editor, modify the content to reflect the following changes:
We have everything set up, and our APIs are running with Gunicorn. Now, we need to configure the frontend to serve static files with Nginx and connect Gunicorn to Nginx. To get started, we first need to install Nginx using the command below:
Bash
sudo apt install nginx\n
Since our frontend and backend are in the user directory, we will encounter a permission error from Nginx. To resolve this, we will grant access to the www-data user group with the command below:
Bash
sudo chown -R aptrs:www-data /home/aptrs\n
To complete the setup, we can assume the domain name for our web server is demo.aptrs.com. The configuration below will have the nginx configuration files or folder names based on the domain, which users should replace with their actual domain.
Next, we will create a new server block in the Nginx sites-available directory using the following command:
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Automated Penetration Testing Reporting System","text":"
APTRS (Automated Penetration Testing Reporting System) is a Python, Django and ViteJS-based automated reporting tool designed for penetration testers and security organizations. This tool streamlines the report generation process by enabling users to create PDF, Docx and Excel reports directly, eliminating the need for manual approaches. Additionally, APTRS offers a systematic way to monitor and manage vulnerabilities within various projects. Keep your penetration testing projects organized and efficient with APTRS.
APTRS offers various features and configurations, including the management of companies, customers, projects, retests, different types of reports, configurations, templates, and more. The Features Documentation provides detailed information on the different setups, features, and use cases.
"},{"location":"Features/Users/users/","title":"User Management in APTRS","text":"
APTRS provides robust user management capabilities, allowing you to add, edit, and delete users. Each user can log in to the APTRS platform using their credentials, and they have the option to set a profile photo through the Edit Profile feature. In version 1.0, users are also able to change their passwords.
Internal Users (Staff Users): By default, all users added to the system are marked as staff users, indicating they are internal users of the APTRS.
External Users (Non-Staff Users): External users are designated as non-staff users. For details on managing non-staff users, please refer to the Customer section.
This structured approach to user management ensures that you can effectively manage access levels and user capabilities within the APTRS platform.
"},{"location":"Features/Users/users/#important-note-on-deleting-users","title":"Important Note on Deleting Users","text":"
All projects in APTRS must have an owner. Deleting a user will cause errors, as projects assigned to that user will no longer have an owner. If you need to disable a user\u2019s account, it is recommended to set the account to \"inactive\" rather than deleting it. If you choose to delete the user, be aware that you will need to manually reassign ownership of all the projects associated with that user to avoid issues.
"},{"location":"Features/company/company/","title":"Company Management in APTRS","text":"
APTRS allows you to add and manage companies, with two types of companies supported: Internal Companies and External (Non-Internal) Companies.
APTRS assumes that your company, the one deploying and using APTRS, is the internal company. When you deploy APTRS for the first time, an internal company is automatically created. This company is assigned to you and cannot be deleted or replaced. However, you can rename it to reflect your actual company name.
Key details about internal companies:
Internal Company Setup: The internal company is auto-created during the initial setup, and no additional internal companies can be added afterward.
User Assignment: All users added through the User Management page will automatically be part of the internal company.
Reports: Users and data from the internal company will be reflected in your reports as staff or internal users.
All companies manually added after the initial setup are classified as External Companies. These are typically client companies or third-party organizations.
Key details about external companies:
User Management: You cannot add users to external companies through the User Management page. Any user added through this page will be assigned as a staff member of the internal company.
Assigning Users to External Companies: To assign users to external companies, you need to go through the Customer section, which manages external users.
Projects: You can create projects for both internal and external companies, allowing you to track and manage work for client companies separately from your own.
This setup ensures a clear distinction between your internal users and external client companies, making it easier to manage access, projects, and reports within APTRS.
Warning
Deleting a company will also delete all associated users. Make sure to reassign or handle any users before deleting a company.
"},{"location":"Features/company/customer/","title":"Customer Management in APTRS","text":"
Customers in APTRS are external users who belong to external (non-internal) companies. You can manage these users from the Customer page, where external users are added and tracked, and they are included in reports as customer users.
When adding a customer, you will need to provide the following information:
Email: The customer's email address.
Company: The external company they belong to.
Password: A password is required as part of the future functionality.
Though passwords are required during customer creation, as of version 1.0, external users do not yet have access to login, API, or dashboard features. These features are planned for future releases, where customers will be able to log into the APTRS dashboard, view ongoing and past projects, download reports, and more.
This allows APTRS to lay the groundwork for future functionality while managing customer data and ensuring they are accurately represented in reports.
The Configuration section allows admin users or users with the Manage Configurations permission to add and manage various settings. In APTRS, users can define Project Types, such as \"Mobile Application Testing,\" which are used when creating projects and are also referenced in PDF and DOCX reports. Multiple project types can be added to suit different testing needs.
In addition to project types, users can also create Report Standards. When generating a report, users are required to select the applicable testing standard, such as OWASP for web application testing. Users can add additional standards here, which can then be used in the generated reports.
The Dashboard provides a personalized view of projects based on the logged-in user\u2019s ownership and project status. Unlike the Projects View Page, which lists all projects within APTRS, the Dashboard only displays projects where the logged-in user is the owner and the project is not marked as completed. The Dashboard shows projects with the following statuses: Delay, In Progress, or Upcoming, as long as the user is the owner of those projects.
In addition to active or upcoming projects, the Dashboard also displays completed projects if the project has an active retest. Even if a project is marked as completed, it will be shown in the Dashboard if it has any upcoming, in-progress, or delayed retests where the logged-in user is the owner of the retest task.
This also applies in cases where the user is the owner of the retest task for a completed project, even if the user is not the owner of the original project. In such cases, the project will still appear on the Dashboard, allowing the user to view and manage their active retest tasks.
"},{"location":"Features/permission/permission/","title":"Groups and Permissions in APTRS","text":"
APTRS uses permissions to control access to certain APIs and restrict features to specific users. To streamline this process, APTRS allows you to create groups and assign permissions to those groups. Once a group is created, you can assign users to one or more groups. A user assigned to multiple groups will inherit all the permissions from those groups.
Permissions are pre-defined within APTRS to regulate access to various functionalities. These permissions cannot be modified or created from the user interface, as they are hard-coded in the backend. However, you can create custom groups and assign these predefined permissions to the groups. When users are assigned to a group, they will automatically gain all the permissions associated with that group.
"},{"location":"Features/permission/permission/#admin-users-and-permissions","title":"Admin Users and Permissions","text":"
Admin users in APTRS are not restricted by permissions or group assignments. This means that even if an admin user has no group assigned or is assigned to a group with limited permissions, they will still have full access to all features and APIs in the system. Admin users are always granted full control, regardless of group membership or assigned permissions.
When you first deploy APTRS, several default groups are created with specific permissions. The most important groups are Project Manager and Manager. These groups are crucial for report generation, as they are used to add project manager and manager details to reports.
While you can edit the permissions assigned to these groups, it is important to retain the group names (\"Project Manager\" and \"Manager\") if you want APTRS to correctly include project manager and manager details in the reports. Removing or renaming these groups may cause issues with report generation and prevent the correct user details from being added to reports.
"},{"location":"Features/permission/permission/#list-of-permissions-as-of-version-10","title":"List of Permissions (as of version 1.0)","text":"
Manage Users: Users with this permission can add, edit, and delete users, manage groups, and assign permissions to groups. They can also create and delete groups.
Manage Projects: Users with this permission can create, edit, and delete projects. They can add vulnerabilities or retests within a project, generate reports, and add scope to projects. By default, users cannot select project or retest owners; projects and retests created by users with this permission will automatically mark the creator as the owner.
Assign Projects: This permission allows users to select and assign project or retest owners. Users with this permission can assign any user as the owner of a project or retest.
Manage Vulnerability Data: Users with this permission can add, edit, and delete entries in the vulnerability database or templates.
Manage Customers: Users with this permission can add, edit, and delete customers.
Manage Companies: Users with this permission can add, edit, and delete companies.
Manage Configurations: Users with this permission can manage various application configurations.
Each project can have associated vulnerabilities. You can navigate to the Vulnerability tab within a project to manage its vulnerabilities. This tab allows you to add, edit, or remove vulnerabilities specific to that project, providing a dedicated space to document identified security issues, their descriptions, solutions, CVSS scores, and other relevant details.
Using the Vulnerability Database, you can quickly import common vulnerabilities with pre-filled information, saving time when adding recurring or well-documented issues across multiple projects.
APTRS provides multiple ways to add vulnerabilities to a project, offering flexibility in how you manage and document security issues.
Search and Add: This feature allows you to search for vulnerabilities by title or name from the Vulnerability DB or Template. Once you select a vulnerability from the search results, a new entry is created within the project, automatically populated with the title, description, solution, reference link, and CVSS score from the Vulnerability DB. This approach allows for efficient reuse of information with pre-filled details, saving time on repetitive entries.
Add New: Selecting \"Add New\" will create a blank vulnerability entry within the project. All fields are initially empty except for the title, which is set to \"New Vulnerability.\" This option is ideal if you need to manually document unique vulnerabilities not in the database. You can fill in all required details such as description, solution, and severity.
Upload CSV: This option is designed specifically for importing vulnerabilities from Nessus scan outputs. You can upload a Nessus vulnerability scan CSV report, which APTRS will parse to extract details such as URL or IP, port, title, description, and more. Parsed vulnerabilities are then added directly to the project, saving time on data entry for larger assessments.
This feature can also be used for other, non-Nessus scan reports. As long as the CSV file contains the required columns with matching names, APTRS will process it just like a Nessus report, making it a versatile option for importing vulnerabilities from various sources.
To ensure that vulnerabilities are parsed correctly, your CSV file should include the following columns:
Host: The IP address or URL of the affected system.
Port: The network port where the vulnerability was found.
Name: The title of the vulnerability, providing a brief identifier.
Description: A detailed explanation of the vulnerability, including its nature and potential impact.
Solution: Recommended actions or patches to mitigate or resolve the vulnerability.
Risk: The severity level of the vulnerability (e.g., Info, Low, Medium, High, Critical). APTRS uses this to assign a default CVSS score and vector.
"},{"location":"Features/project/Vulnerability/#cvss-score-and-vector","title":"CVSS Score and Vector","text":"
As of version 1.0, APTRS does not accept CVSS scores and vectors from CSV imports because default Nessus reports do not include them. Instead, APTRS assigns a default CVSS score and vector based on the Risk level provided in the CSV file.
"},{"location":"Features/project/Vulnerability/#default-cvss-scores-and-vectors-cvss-31","title":"Default CVSS Scores and Vectors (CVSS 3.1)","text":"
These default values are automatically assigned based on the risk level when the CSV is parsed:
Severity Base Score Vector Critical 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H High 7.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L Medium 5.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L Low 3.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N Informational 0.0 CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:N
These defaults ensure consistency in reporting for imported vulnerabilities, even if specific CVSS details aren\u2019t included in the CSV file.
Each vulnerability in a project is required to have an instance. An instance represents the specific URL, parameter, IP address, and port number of the affected vulnerability. Each instance within a vulnerability can have its own status, allowing for more granular tracking and resolution.
"},{"location":"Features/project/Vulnerability/#vulnerability-and-instance-status","title":"Vulnerability and Instance Status","text":"
The status of each vulnerability and its instances is tracked individually to provide clear insights into the resolution progress. Below are the details on how the status is managed and calculated for both vulnerabilities and their instances.
The status of a vulnerability and its instances are interconnected. There are three possible statuses for both vulnerabilities and instances:
Vulnerable: The vulnerability or instance has unresolved security issues.
Confirmed Fix: The vulnerability or instance has been resolved and no longer has security issues.
Accepted Risk: The vulnerability or instance remains unresolved, but the customer or client has accepted the associated risk.
These statuses function as follows:
Changing Vulnerability Status: If you change the status of a vulnerability, all instances associated with that vulnerability will automatically be set to the same status. For example, setting a vulnerability to Accepted Risk will update all instances within that vulnerability to Accepted Risk as well.
Changing Instance Status: When modifying the status of individual instances within a vulnerability, the overall vulnerability status is recalculated based on its instances' statuses. The rules are as follows:
Confirmed Fix: For a vulnerability to be marked as Confirmed Fix, all instances must be set to Confirmed Fix. Even a single instance with a different status prevents the vulnerability from being marked as Confirmed Fix.
Vulnerable: If any instance is marked as Vulnerable, the entire vulnerability is marked as Vulnerable, regardless of other instances\u2019 statuses.
Accepted Risk: If all instances are marked as Accepted Risk, the vulnerability status will also be set to Accepted Risk.
In short, for a vulnerability to be considered Confirmed Fix, all instances must be Confirmed Fix. To be marked as Accepted Risk, all instances must have that status. Any instance marked as Vulnerable will cause the vulnerability itself to be marked as Vulnerable.
APTRS allows users to create and manage projects, which are typically created when conducting a pentest for a company. When setting up a project, you can associate it with a specific company, select multiple internal users as project owners, and define key details such as project type, start and end dates, and a brief description.
Once the project is created, you can later add vulnerabilities, generate reports, and track progress within the project. This feature helps organize pentesting efforts efficiently, ensuring clear project ownership and structure.
The project status is automatically calculated based on the project\u2019s start and end dates:
Upcoming: If the start date is in the future.
In Progress: If the start date has passed or is today, but the end date is still in the future.
Delayed: If the end date has passed.
Completed: If the project is marked as completed.
If your project is completed, you can manually mark it as Completed from the project summary. To do this, navigate to the project from the project table or dashboard, and you\u2019ll find an option to mark it as completed on the project summary page.
Once a project is created, it is not possible to change the associated company. However, you can still edit other details, such as project type, dates, description, and owners.
In Version 1.0, APTRS supports assigning multiple project owners, allowing you to add as many project owners as needed. Assigning or selecting a project owner requires admin privileges or the Assign Projects permission. Otherwise, the user creating the project is automatically added as the project owner.
Once your project is ready, you can generate a report for the identified vulnerabilities. APTRS version 1.0 provides options to generate reports in PDF, Excel, and DOCX formats. Navigate to the report section within the project, select the desired report type and standard, and download the report directly.
As of version 1.0, the DOCX report generation feature is experimental. It may be removed or enhanced with more customization options in future versions. Once validated for full customization and consistent presentation, this feature will become permanent.
PDF Reports: APTRS uses the WeasyPrint Python library to convert HTML into PDF. You can modify the HTML and CSS files used in report generation to match your requirements.
DOCX Reports: APTRS leverages the python-docxtpl library to create DOCX files. The CKEditor WYSIWYG editor is used for entering vulnerability and project details. CKEditor\u2019s HTML output is then converted into DOCX format using the html2docx library, and integrated with docxtpl to generate the final report.
The HTML and DOCX report templates are available here: - HTML and DOCX Report Templates
CSS files for HTML-to-PDF reports can be customized here: - CSS for PDF Reports
PDF Reports: APTRS uses the WeasyPrint Python library to generate PDF reports. However, WeasyPrint does not support JavaScript execution, which limits the ability to include custom, interactive charts directly within the PDF. Instead, APTRS generates charts using a Python library and embeds them as static images in the PDF. This approach restricts customization of charts via HTML and CSS.
DOCX Reports: APTRS generates DOCX reports using a combination of python-docx, python-docxtpl, and html2docx. While python-docxtpl enables dynamic content insertion into documents, it does not support updating or dynamically modifying charts. As a result, charts included in DOCX reports cannot be automatically updated with dynamic values by APTRS.
Each project can have a retest task created and assigned to a user. Similar to a project, each retest includes a start and end date and has a designated retest owner. Retests allow you to specify the revalidation of the project\u2019s vulnerabilities, ensuring that fixes have been applied as expected. Within a project, users can initiate a retest to start this process.
Similar to project ownership, the retest owner is automatically set to the user creating the retest if they do not have admin privileges or the Assign Projects permission. Users with admin access or Assign Projects permission can select the retest owner. Once a retest task is created, it cannot be edited, though you can still delete the retest task if needed.
Project Completion Requirement: A retest task cannot be created if the project is not marked as completed. Retests are only applicable to projects that have been fully executed, as retests aim to validate resolved vulnerabilities. Therefore, a project must be completed before any retest can be initiated.
Single Active Retest Restriction: Even if the project is completed, you cannot create a new retest task if there is an existing retest task that is not marked as completed. Only one active retest can be associated with a project at a time.
Each project includes scopes, allowing you to define the list of IPs, URLs, or application names that are part of the engagement. Starting from version 1.0, each project can have multiple scopes. Within the project page, you can navigate to the Scope section to manage the specific scope of the project.
"},{"location":"Features/vulnerabilityDB/vulnerability/","title":"Vulnerability DB (or Template)","text":"
The Vulnerability DB or Template feature in APTRS allows you to add and manage a database of vulnerabilities that can be reused across different projects. When adding a vulnerability to a project, you can specify all necessary details such as the title, description, solution, CVSS score, and more.
If you encounter the same vulnerability in multiple projects, such as IDOR or SQL Injection, the Vulnerability DB allows you to save time by reusing the same information without needing to write it again for each project. This helps streamline reporting and ensures consistency across projects.
By creating templates for common vulnerabilities, you can easily import them when adding vulnerabilities to new projects, reducing redundant work and improving efficiency.
"},{"location":"custom-report/docx/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/docx/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
Description:
This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
Usage Example:
Python
Project Managers:\n\n {% for user in projectmanagers %}\n {{ user.full_name }} {{ user.position }} {{ user.email }}\n {% endfor %}\n
"},{"location":"custom-report/docx/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
Description:
This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
Usage Example:
Text Only
Customer Users:\n\n {% for user in customeruser %}\n {{ user.full_name }} {{ user.position }} {{ user.email }}\n {% endfor %}\n
APTRS provides the ability to generate detailed DOCX reports using customizable templates. You can use Jinja2 template tags within your .docx templates to dynamically populate project and vulnerability data. This guide explains how to customize your template and use available context variables.
Syntax: {% if condition %}...{% else %}...{% endif %}
Example: To check if a project has vulnerabilities:
Python
{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n
"},{"location":"custom-report/docx/docx/#available-context-variables","title":"Available Context Variables","text":"Variable Description project The project object for which the report is being generated. Contains all project details. owners User details of All Project Owners project_exception Project Exceptions project_description Project Description vulnerabilities Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). mycomany The name of the internal (your company) company. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. projectscope Queryset of all project scopes for the project. totalretest List of retest schedules and owners. totalvulnerability Total count of vulnerabilities for the project. Report_type The type of report being generated (e.g., Audit, Re-Audit). standard The standard or methodology being used for the report. currentdate Get Current Date if needed in the report page_break Allows you to add page break in the docx report such as page break after each vulnerability details new_line Allows you to add a new line if needed"},{"location":"custom-report/docx/docx/#docx-formatting-with-jinja2","title":"Docx Formatting with Jinja2","text":"
By default, Jinja2 adds blank lines with conditions or loops, which can be problematic for Docx formatting. Unlike HTML, where empty lines have minimal impact, in Docx, this can lead to extra rows in tables or increased table width.
APTRS uses the docxtpl library, based on Python-docx and Jinja2, for template-based rendering. To reduce blank lines, you can use Jinja2's whitespace control.
However, this method doesn't always work flawlessly; it may inadvertently remove important elements like tables along with extra spaces. A simpler solution can involve using a single line of code.
You can modify the code like this:
Python
##Instead of new line for code\n{% if vulnerabilities %} \nVulnerabilities are present. \n{% else %} \nNo vulnerabilities found. \n{% endif %}\n\n\n## you can change it to like this on a single line \n\n{% if vulnerabilities %} Vulnerabilities are present. {% else %} No vulnerabilities found. {% endif %}\n
"},{"location":"custom-report/docx/docx/#color-and-conditions","title":"Color and Conditions","text":"
Each severity level in the report is represented by different colors: low or informational is often green or light blue, while high severity is red. Status can also be color-coded, with fixed vulnerabilities in green and open ones in red or orange.
In HTML reports, you can add severity values to the tag's class attribute and create CSS to apply the colors.
For DOCX reports, colors cannot be applied to undefined elements, limiting customization. To assign colors based on severity\u2014like red for critical and orange for high\u2014include them directly in the conditional statements within your DOCX template.
Python
{% if severity == 'Critical' %} severity with red color. {% elif severity == 'Low' %} severity with green color. {% endif %}\n
Note
Adding Jinja2 White Space control to this will remove the color.
What if instead of just color for the text, we want to add color for the cell in the table like below
Name Status Severity SQL Injection Vulnerable Confirm Fixed
We can do that as well with cellbg in the table, with hex color code like below:
Python
{% cellbg 'FF491C' if vulnerability.vulnerabilityseverity== 'Critical' else 'F66E09' if vulnerability.vulnerabilityseverity== 'High' else 'FBBC02' if vulnerability.vulnerabilityseverity== 'Medium' else '20B803' if vulnerability.vulnerabilityseverity== 'Low' else '3399FF' %}{{ vulnerability.vulnerabilityseverity}}\n
"},{"location":"custom-report/docx/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/docx/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
Description: Provides the total count of vulnerabilities associated with a project.
Usage Example: You can display the total number of vulnerabilities for the project.
Description: The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
Usage Example: Display the methodology or standard used in the vulnerability report.
Python
Report Standard: {{ standard|join(', ') }} \n
"},{"location":"custom-report/docx/other/#4-current-date","title":"4. Current Date","text":"
Description: Get the current date if needed in the report.
"},{"location":"custom-report/docx/project/","title":"Project","text":""},{"location":"custom-report/docx/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report Docx, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/docx/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
project.name
Represents the name of the project.
Example usage in HTML: Python
Project Name: {{ project.name }}\n
project.companyname
A foreign key to the Company model, representing the company associated (Customer Company) with the project.
Example usage: Python
Company Name: {{ project.companyname.name }}\n
project_exception
A detailed description of the project.
Example usage: Python
Description: {{p project_exception}}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
Project End Date: {{project.enddate.strftime(\"%d/%m/%Y\") }}\n
project.testingtype
The type of testing performed for the project (e.g., White Box, Black Box).
Example usage: Python
Testing Type: {{ project.testingtype }}\n
project_exception
Notes or exceptions for the project, if any.
Example usage: Python
Exceptions: {{p project_exception }}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
In most cases if you don't have exceptions and in your report you only this if exception is there you are also do it with conditions. Python
{% if project_exception %}\nExceptions: {{p project_exception }}\n{% endif %}\n
project.owner
Note: This is not available, due to issues with the method provided by django to loop many to many database relation, it does not work with the jinja2.
project.status
The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).
Example usage: Python
Status: {{ project.status }}\n
In order to get Project owner details, APTRS provide a seperate context and tag owners which contain user details for project owners. In order to use it you have to loop through details like below:
Python
{% for owner in owners %}\n {{ owner.full_name}}\n {{ owner.email}}\n {{ owner.position}}\n {{ owner.number}}\n {% endfor %}\n
"},{"location":"custom-report/docx/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status.
Usage Example: You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
Python
Project Retests:\n\n {% for retest in totalretest %}\n {{ retest.startdate }} {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owners %}\n {{ owner }}\n {% endfor %}\n\n {% endfor %}\n
Note
The {{ owner }} will only show the full_name of the owner, as of now its limited to full name only.
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
HTML
{% if Report_type == 'Re-Audit' %}\n Project Retests:\n\n {% for retest in totalretest %}\n {{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owners %}\n {{ owner }}\n {% endfor %}\n\n {% endfor %}\n\n{% endif %}\n
"},{"location":"custom-report/docx/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
Usage Example:
Python
Project Scope:\n\n {% for scope in projectscope %}\n {{ scope.scope }} {{ scope.description }}\n {% endfor %}\n</ul>\n
"},{"location":"custom-report/docx/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/docx/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. APTRS provide {{vulnerabilities}} tag with list of all vulnerabilities and its instances. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/docx/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
vulnerability.vulnerabilityname
The name of the vulnerability (e.g., \"SQL Injection\").
Example usage: Python
{% for vulnerability in vulnerabilities %}\nVulnerability Name: {{ vulnerability.vulnerabilityname }}\n{% endfor %}\n
vulnerability.vulnerabilityseverity
The severity of the vulnerability (e.g., \"High\", \"Medium\").
Example usage: Python
{% for vulnerability in vulnerabilities %}\nSeverity: {{ vulnerability.vulnerabilityseverity }}\n{% endfor %}\n
vulnerability.cvssscore
The CVSS score associated with the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCVSS Score: {{ vulnerability.cvssscore }}\n{% endfor %}\n
vulnerability.cvssvector
The CVSS vector associated with the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCVSS Vector: {{ vulnerability.cvssvector }}\n{% endfor %}\n
vulnerability.status
The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).
Example usage: Python
{% for vulnerability in vulnerabilities %}\nStatus: {{ vulnerability.status }}\n{% endfor %}\n
vulnerability.vulnerabilitydescription
A description of the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nDescription: {{p vulnerability.vulnerabilitydescription }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.POC
The proof of concept (POC) for the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nPOC: {{p vulnerability.POC }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.vulnerabilitysolution
The recommended solution for the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nSolution: {{p vulnerability.vulnerabilitysolution }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.vulnerabilityreferlnk
A reference link related to the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nReference Link: {{p vulnerability.vulnerabilityreferlnk }}\n{% endfor %}\n
It uses CKeditor HTML data, its converted into the docx format from HTML, hence its required to use p at the start of the tag.
vulnerability.created
The timestamp when the vulnerability was created.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCreated: {{ vulnerability.created }}\n{% endfor %}\n
vulnerability.created_by
The user who created the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nCreated By: {{ vulnerability.created_by.username }}\n{{ vulnerability.created_by.full_name }}\n{% endfor %}\n
Similar to project owner, you can use other filed as well like email, number or postion etc.
vulnerability.last_updated_by
The user who last updated the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\nLast Updated By: {{ vulnerability.last_updated_by.username }}\n{{ vulnerability.last_updated_by.full_name }}\n{% endfor %}\n
vulnerability.instances_data
Acess all instaces of the vulnerability.
Example usage: Python
{% for vulnerability in vulnerabilities %}\n\n {for instance in vulnerability.instances_data %}\n ## This give all instances for vulnerabiltiy in current loop\n\n URL: {{ instance.URL }}\n Parameter: {{ instance.Parameter }}\n Parameter: {{ instance.Status }}\n\n {% endfor %}\n\n{% endfor %}\n
"},{"location":"custom-report/pdf/company-user/","title":"Context Variables for Company and Users","text":""},{"location":"custom-report/pdf/company-user/#1-internal-company-name","title":"1. Internal Company Name","text":"
Description:
This variable will provide the name of the internal company (your own company) that is linked to the APTRS. It fetches the company name from the Company model where the internal field is set to True.
This variable gives access to all the internal users who are part of the \"Project Manager\" group. You can loop through this list to display details like the name of the project managers working on the project.
Usage Example:
HTML
<h3>Project Managers:</h3>\n <ul>\n {% for user in projectmanagers %}\n <li>{{ user.full_name }} - {{ user.position }}</li>\n {% endfor %}\n </ul>\n
"},{"location":"custom-report/pdf/company-user/#3-customer-company-users","title":"3. Customer Company Users","text":"
Description:
This variable provides access to the users who belong to the customer\u2019s company for the project. It retrieves the list of active users associated with the project\u2019s customer company.
Usage Example:
HTML
<h3>Customer Users:</h3>\n <ul>\n {% for user in customeruser %}\n <li>{{ user.full_name }} - {{ user.position }}</li>\n {% endfor %}\n </ul>\n
This document describes how to customize the HTML templates used to generate PDF reports using the GetHTML function in your Django application. Below are the available context variables that can be used in the HTML templates and their respective details.
The following context variables are passed to the HTML template (report.html) during PDF generation. Users can use these variables to dynamically customize the content of the PDF report.
Variable Name Description project The project object for which the report is being generated. Contains all project details. vuln Queryset of vulnerabilities for the project, ordered by CVSS score (higher to lower). instances Queryset of all vulnerable instances associated with the project. projectmanagers Queryset of users in the \"Project Manager\" group. customeruser Queryset of customer users associated with the project's customer company. mycomany The name of the internal (your company) company. projectscope Queryset of all project scopes for the project. totalretest Queryset of all retests for the project. totalvulnerability Total count of vulnerabilities for the project. ciritcal Count of vulnerabilities with severity \"Critical\". high Count of vulnerabilities with severity \"High\". medium Count of vulnerabilities with severity \"Medium\". low Count of vulnerabilities with severity \"Low\". info Count of vulnerabilities with severity \"Informational\" or \"None\". standard The standard or methodology being used for the report. Report_type The type of report being generated (e.g., Audit, Re-Audit). pie_chart Rendered pie chart data showing the vulnerability distribution by severity."},{"location":"custom-report/pdf/context-variable/#how-to-customize-templates","title":"How to Customize Templates","text":"
Locate the HTML Template:
The report template is located at templates/*. You can modify this file or create a new one for different report types.
Use Context Variables:
Insert the context variables into the template using Django's template syntax. For example: HTML
<h1>Vulnerability Report for {{ project.name }}</h1>\n<p>Total Vulnerabilities: {{ totalvulnerability }}</p>\n<p>Critical Issues: {{ ciritcal }}</p>\n<p>High Severity Issues: {{ high }}</p>\n
Dynamic Content:
Use loops and conditionals to dynamically render data. For example: HTML
<ul>\n{% for vuln in vuln %}\n <li>{{ vuln.vulnerabilityname }} - Severity: {{ vuln.vulnerabilityseverity }}</li>\n{% endfor %}\n</ul>\n
Styling and Charts:
Use {{ pie_chart|safe }} to embed the rendered pie chart in the HTML. Ensure that the safe filter is applied to include raw HTML safely.
"},{"location":"custom-report/pdf/other/","title":"Context Variables for Vulnerabilities and Report Data","text":""},{"location":"custom-report/pdf/other/#1-total-vulnerabilities","title":"1. Total Vulnerabilities","text":"
Description: Provides the total count of vulnerabilities associated with a project.
Usage Example: You can display the total number of vulnerabilities for the project.
Description: The standard or methodology being used for generating the report (e.g., OWASP, NIST). It will be in the list format, you can use below example to get in a text separated by comma.
Usage Example: Display the methodology or standard used in the vulnerability report.
Description: This variable holds the rendered data for a pie chart showing the distribution of vulnerabilities by severity.
Usage Example: Use this to display a pie chart visualizing vulnerability severity distribution.
HTML
<div>{{ pie_chart|safe }}</div>\n
"},{"location":"custom-report/pdf/pdf/","title":"Customized PDF Report Documentation","text":"
APTRS uses the WeasyPrint library to generate PDF reports from HTML and CSS. The Django template engine dynamically passes data to the HTML template using context variables.
"},{"location":"custom-report/pdf/pdf/#how-it-works","title":"How It Works","text":"
The system is designed so you don\u2019t need to edit the Django code that handles report generation unless you are familiar with Django and Python. The recommended approach is to customize the layout and styling by modifying the HTML and CSS files provided with the project.
"},{"location":"custom-report/pdf/pdf/#file-structure-for-customization","title":"File Structure for Customization","text":"
Within the project root directory, there is a subdirectory named APTRS. This contains the following important folders for report customization:
Static Folder:
Located inside the APTRS directory.
Contains a CSS subfolder where all CSS files for the report are stored.
Includes predefined styles that you can customize to adjust the appearance of the report.
Templates Folder:
Located in the same directory as the static folder.
Contains all the HTML templates used for generating reports.
Templates are modular, with the main report layout in report.html and additional reusable components loaded using Django's {% include %} tag.
"},{"location":"custom-report/pdf/pdf/#key-files-for-customization","title":"Key Files for Customization","text":"
report.html:
The main HTML file for the report.
Includes the overall structure, head tags, and references to CSS files.
Dynamically includes other HTML components for better modularity.
report-page.css:
The primary CSS file applied to all report pages.
Handles global styles such as font loading, page numbering, table styles, and default styles for HTML tags.
Defines general formatting applied across the entire report.
Component Files:
Each HTML file has a corresponding CSS file for specific styles.
For example, styles specific to an HTML section like vulnerability.html will be defined in vulnerability.css.
This structure ensures easy identification and modification of styles tied to specific sections.
Avoid editing the Django code unless necessary, as it handles the logic for passing variables and generating the PDF.
All changes to the static files (CSS) or templates (HTML) will reflect in the next report generated.
"},{"location":"custom-report/pdf/project/","title":"Project","text":""},{"location":"custom-report/pdf/project/#project-model-variables-for-template-customization","title":"Project Model Variables for Template Customization","text":"
The Project model in APTRS contains the following fields that can be used as template variables in your custom report templates. These variables are passed as part of the context to the report HTML, allowing you to display or manipulate project-related data in your custom reports.
"},{"location":"custom-report/pdf/project/#available-variables-and-their-usage","title":"Available Variables and Their Usage","text":"
project.name
Represents the name of the project.
Example usage in HTML: HTML
<h1>Project Name: {{ project.name }}</h1>\n
project.companyname
A foreign key to the Company model, representing the company associated (Customer Company) with the project.
The current status of the project, based on PROJECT_STATUS_CHOICES (e.g., Upcoming, In Progress, Delay, Completed).
Example usage: HTML
<p>Status: {{ project.status }}</p>\n
"},{"location":"custom-report/pdf/retest/","title":"Context Variable for Project Retests","text":"
The totalretest variable gives access to the retests associated with a project. It allows you to display details of a project retest, including start and end dates, owners, and status.
Usage Example: You can loop through totalretest to display the retests for a project. However, it is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
HTML
<h3>Project Retests:</h3>\n <ul>\n {% for retest in totalretest %}\n <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owner.all %}\n {{ owner.full_name }}\n\n {% endfor %}\n </li>\n {% endfor %}\n </ul>\n
It is possible to conditionally display the retests based on the Report_type, e.g., showing retests only when the report type is \"Re-Audit\".
HTML
{% if Report_type == 'Re-Audit' %}\n <h3>Project Retests:</h3>\n <ul>\n {% for retest in totalretest %}\n <li>{{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }}\n\n {% for owner in retest.owner.all %}\n {{ owner.full_name }}\n\n {% endfor %}\n </li>\n {% endfor %}\n </ul>\n{% endif %}\n
"},{"location":"custom-report/pdf/scope/","title":"Context Variable for Project Scope","text":"
The projectscope variable gives access to the scope of a project. It allows you to retrieve and display details of the project's scope, including any specific tasks, requirements, or exceptions related to the project. You can loop through this context variable to show the scope items associated with a project.
Usage Example:
HTML
<h3>Project Scope:</h3>\n<ul>\n {% for scope in projectscope %}\n <li>{{ scope.scope }} - {{ scope.description }}</li>\n {% endfor %}\n</ul>\n
"},{"location":"custom-report/pdf/vulnerability/","title":"Vulnerability","text":""},{"location":"custom-report/pdf/vulnerability/#vulnerability-and-instance-model-variables-for-template-customization","title":"Vulnerability and Instance Model Variables for Template Customization","text":"
In APTRS, the Vulnerability and Vulnerableinstance models are used to manage and track vulnerabilities and their instances across various projects. Below is an overview of the variables available for use in templates when working with these models.
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerability-model","title":"Available Variables for Vulnerability Model","text":"
vulnerability.vulnerabilityname
The name of the vulnerability (e.g., \"SQL Injection\").
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Vulnerability Name: {{ vulnerability.vulnerabilityname }}</p>\n{% endfor %}\n
vulnerability.vulnerabilityseverity
The severity of the vulnerability (e.g., \"High\", \"Medium\").
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Severity: {{ vulnerability.vulnerabilityseverity }}</p>\n{% endfor %}\n
vulnerability.cvssscore
The CVSS score associated with the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>CVSS Score: {{ vulnerability.cvssscore }}</p>\n{% endfor %}\n
vulnerability.cvssvector
The CVSS vector associated with the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>CVSS Vector: {{ vulnerability.cvssvector }}</p>\n{% endfor %}\n
vulnerability.status
The status of the vulnerability, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Status: {{ vulnerability.status }}</p>\n{% endfor %}\n
vulnerability.vulnerabilitydescription
A description of the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Description: {{ vulnerability.vulnerabilitydescription|clean_html }}</p>\n{% endfor %}\n
vulnerability.POC
The proof of concept (POC) for the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>POC: {{ vulnerability.POC|clean_html }}</p>\n{% endfor %}\n
vulnerability.vulnerabilitysolution
The recommended solution for the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Solution: {{ vulnerability.vulnerabilitysolution|clean_html }}</p>\n{% endfor %}\n
vulnerability.vulnerabilityreferlnk
A reference link related to the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Reference Link: {{ vulnerability.vulnerabilityreferlnk|clean_html }}</p>\n{% endfor %}\n
vulnerability.created
The timestamp when the vulnerability was created.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Created: {{ vulnerability.created }}</p>\n{% endfor %}\n
vulnerability.created_by
The user who created the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Created By: {{ vulnerability.created_by.username }}</p>\n{{ vulnerability.created_by.full_name }}</p>\n{% endfor %}\n
Similar to project owner, you can use other filed as well like email, number or postion etc.
vulnerability.last_updated_by
The user who last updated the vulnerability.
Example usage: HTML
{% for vulnerability in vuln %}\n<p>Last Updated By: {{ vulnerability.last_updated_by.username }}</p>\n{% endfor %}\n
"},{"location":"custom-report/pdf/vulnerability/#available-variables-for-vulnerableinstance-model","title":"Available Variables for Vulnerableinstance Model","text":"
instance.vulnerabilityid
The Vulnerability object associated with the instance.
Example usage: HTML
{% for instance in instances %}\n<p>Vulnerability Name: {{ instance.vulnerabilityid.vulnerabilityname }}</p>\n{% endfor %}\n
instance.project
The project associated with the vulnerable instance.
Example usage: HTML
{% for instance in instances %}\n<p>Project: {{ instance.project.name }}</p>\n{% endfor %}\n
instance.URL
The URL of the vulnerable instance.
Example usage: HTML
{% for instance in instances %}\n<p>URL: {{ instance.URL }}</p>\n{% endfor %}\n
instance.Parameter
The parameter of the vulnerable instance.
Example usage: HTML
{% for instance in instances %}\n<p>Parameter: {{ instance.Parameter }}</p>\n{% endfor %}\n
instance.status
The status of the vulnerable instance, based on STATUS_CHOICES (e.g., Vulnerable, Confirm Fixed, Accepted Risk).
Example usage: HTML
{% for instance in instances %}\n<p>Status: {{ instance.status }}</p>\n{% endfor %}\n
"},{"location":"custom-report/pdf/vulnerability/#displaying-vulnerable-instances-for-a-specific-vulnerability-in-a-template","title":"Displaying Vulnerable Instances for a Specific Vulnerability in a Template","text":"
The instances query set or list does not associate with the vulnerability name, instances variable contain all instances for the project, In most cases we need all instances for a vulnerability. We can do that as well, you can check in the original vulnerabilities.html in the template or you can use this:
To display the instances for a specific vulnerability within a loop for vulnerabilities, you can use the following approach:
Yonathan johnson Started creating the frontend using React. Although he could not complete the development due to certain circumstances, his initiative and effort are greatly appreciated.
Automated Report Generation: APTRS automates creating comprehensive penetration testing reports, saving time and ensuring consistency.
PDF Docx, and Excel Reports: Generate professional-looking PDF, Docx and Excel reports with ease, providing clients and stakeholders with clear insights into security assessments.
Vulnerability Management: APTRS helps you keep track of vulnerabilities across different projects, allowing for efficient management and mitigation.
User-Friendly Interface: The tool is designed with a user-friendly interface, making it accessible for both novice and experienced penetration testers.
Customization: Tailor your reports to meet specific project requirements, ensuring that the generated reports align with your organization's standards.
Project and Customer Management: Manage all your projects, retest, and customer all in one place. The user and project tracking allows you to monitor the user's project allocation, plans, and status.
Explore the features of APTRS through our live demo instance:
Live Demo
Username: sourav.kalal@aptrs.com
Password: I-am-Weak-Password-Please-Change-Me
Feel free to interact with the tool and see how APTRS can streamline your penetration testing workflows.
\ud83c\udf28\ufe0f Huge thanks to DigitalOcean for their support of the APTRS project.
Warning
\ud83d\udea7 APIs related to user profiles and user management, such as adding, editing, deleting users, and changing passwords, are disabled on the cloud-hosted demo instance.
The APTRS project is released under the MIT License, which is a permissive open-source license allowing anyone to use, modify, and distribute the software freely. This license ensures that the software remains open and accessible while permitting both personal and commercial use, provided that the original copyright notice and license terms are included in all copies or substantial portions of the software
APTRS uses HTTPS with a self-signed certificate. If you would like to replace the self-signed certificate with your own, you can do so by updating the certificate and key files located at:
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncopy env.docker .env\nnotepad .env\ndocker-compose up \n
Note
The .env file contains all the environment variables, such as passwords for JWT, Database credentials, Cloud S3 bucket details, etc. It\u2019s important to update the default passwords and details before deploying the application. For more information, refer to the Environment Variables section.
The APTRS backend uses the .env file to store credentials such as S3 bucket information, database credentials, secret keys, whitelisted IPs/domains, and more.
If you are deploying the application with Docker, make sure to update the details in the .env file from the project root.
If you are deploying the application without Docker, you will need to update specific details like the S3 bucket and whitelisted IPs.
ENV Description Docker Linux Server Manual Setup SECRET_KEY This key is used by Backend including JWT, Should be secured and random. Manually need to be updated in env file Manually need to be updated in env file WHITELIST_IP This allows to set whitelisted IP/domain with port number to allow loading resource during PDF report to prevent SSRF vulnerability. Manually need to be updated in env file, make sure to keep the https://nginx as its required to connect with nginx within Docker Manually need to be updated in env file based on your domain name, IP etc. ALLOWED_HOST Whitelist allowed host to prevent host header injection attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. CORS_ORIGIN Whitelist allowed origin to prevent cross origin attack Manually need to be updated in env file Manually need to be updated in env file based on your domain name, IP etc. REDIS_URL Redis Server Details including IP, Port and password Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Do not update other details except password Manually need to be updated in env file for REDIS password, IP and Port details REDIS_PASSWORD Redis Server password for Redis image in docker Should replace the default password q8N8HwlaOWqOl1hG7rdmBsm7oT52fLKHZXFwOB4VM7SXFDV8wg to a new strong random password. Password in REDIS_URL and REDIS_PASSWORD should be same Not needed and no need to update/add. POSTGRES_USER , POSTGRES_PASSWORD, POSTGRES_PORT, POSTGRES_DB Postgres DB username, password, port, and DB names Manually need to be updated in env file Manually need to be updated in env file. POSTGRES_HOST Postgres host name Should not be updated. Manually need to be updated in env file. USE_S3 If you want to use Cloud S3 bucket Digital Ocean or AWS s3 bucket. Default False, you can change it to True Optional Optional AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_STORAGE_BUCKET_NAMEAWS_S3_REGION_NAMEAWS_S3_CUSTOM_DOMAINAWS_S3_ENDPOINT_URL Bucket details if USE_S3 is set to True Optional Optional USE_DOCKER Used by APTRS Django code to validate if application deployed on Docker or Not Optional, It is already declared as True in Docker file Required to set to FalseUSER_TIME_ZONE Used by APTRS Django code and Background task schedule time using celery Required to set the local time zon or UTC Required to set the local time zon or UTC
APTRS now includes the source code of the Vite.js frontend by default, instead of a pre-built version. This change allows you greater flexibility to customize the frontend as needed. If you are deploying the application using Docker, the build process is handled automatically, so you don't need to worry about creating a production build manually.
However, if you choose to manually deploy APTRS, you will need to manually build the production version of the frontend and serve it using Nginx or any other reverse proxy.
To build the production version from the Vite.js source code, follow these steps:
Bash
git clone https://github.com/APTRS/APTRS\ncd APTRS\ncd Frontend\ncp env.example .env\nnpm run build\n
Note
The .env file contains settings like the backend API domain and app environment. You can modify these as needed.
By default, APTRS serves both the backend and frontend on the same server, meaning they share the same IP/domain and port. The .env file uses just /api/ in docker build for the backend API domain. This setup is recommended to avoid issues with image uploads in the CKEditor within APTRS and to prevent conflicts related to Same-Origin policies.
"},{"location":"installation/frontend/#hosting-the-frontend-and-api-together","title":"Hosting the Frontend and API Together","text":"
If you wish to host the frontend on a separate domain, IP, or port from the backend API, you can configure the backend API's domain in the .env file within the Frontend folder. For example:
Bash
nano .env\n\nVITE_APP_API_URL = http://backend-api.com/api/\nnpm run build\n
However, it is not recommended to host the API and frontend on separate domains, IPs, or ports. Here's why:
JWT Token Authentication and Cookies:
The API uses a combination of JWT tokens in headers and cookies for authentication and access control.
Cookies are domain-specific and cannot be shared across different domains unless explicitly configured with a domain-wide scope. This can lead to complexities in maintaining secure cross-domain authentication.
Static Image Loading Issues:
Browsers do not allow custom headers, such as JWT tokens, for loading static resources like images.
APTRS addresses this by using cookies for authentication, allowing images protected by the API to be loaded by authenticated users. However, this setup is difficult to manage across separate domains, as it relies on cookies being available in the same domain scope.
Unified Image Path Management:
APTRS supports storing images locally or on S3. Using the API for image access ensures consistency, as images are accessed through the same API endpoint regardless of their storage location.
This approach prevents exposing hardcoded S3 bucket URLs in CKEditor or frontend code. Additionally, if the S3 bucket URL changes or signed URLs expire, the API path remains consistent.
Image Management with CKEditor:
APTRS manages images uploaded through CKEditor by serving them directly via the backend API, rather than using a web server. This design ensures that sensitive images, such as those used for proofs of concept (POCs), are accessible only to authenticated users. These images are protected by authentication tokens and are not publicly exposed.
CKEditor uses <img> tags with a src attribute pointing to the API's image path. For example:
"},{"location":"installation/frontend/#challenges-with-hosting-the-api-and-frontend-on-separate-domains","title":"Challenges with Hosting the API and Frontend on Separate Domains","text":"
When the API is hosted on a separate domain from the frontend:
CKEditor hardcodes the API domain in the src attribute of the images.
If the API domain name, IP, or port changes, previously uploaded images will fail to load, as CKEditor cannot dynamically update the src attribute.
Additionally, browsers loading static resources like images do not support custom headers (e.g., JWT tokens), which can complicate access control for images requiring authentication.
"},{"location":"installation/frontend/#benefits-of-hosting-api-and-frontend-on-the-same-domain","title":"Benefits of Hosting API and Frontend on the Same Domain","text":"
If both the API and frontend are hosted on the same domain, the frontend can be built with VITE_API_URL=/api/. This approach allows CKEditor to generate image paths relative to the frontend's base domain, such as:
HTML
<img src=\"/api/path/to/image.jpg\" />\n
This configuration provides several advantages:
Domain Independence: The image path (/api/path/to/image.jpg) remains valid even if the domain name, IP address, or port changes, as long as the API and frontend share the same base domain.
Simplified Image Access: The relative path ensures that images are seamlessly accessible without hardcoding the API domain, reducing the risk of broken links if deployment configurations change.
Consistent User Experience: End users can load images securely without encountering authentication or cross-domain issues.
Use a reverse proxy, such as Nginx, to host both the API and frontend on the same domain.
Configure the frontend to use VITE_API_URL=/api/.
This setup improves maintainability and ensures robustness against deployment changes, as the relative paths remain valid even if the domain name, IP, or port changes.
Deploying Frontend and Backend on Separate Servers
If you require separate servers for the frontend and backend (e.g., for scalability, load balancing, or easier maintenance), you can still serve both on the same domain or IP and port for users by using a reverse proxy.
For example, you can deploy the frontend on one server and the backend on another, but configure your reverse proxy to route requests based on the path:
Requests to /api/*, media/*, static/* are proxied to the backend server.
Other requests (e.g., for the frontend) are served by the frontend server.
Manual (User with Knowledge of Nginx and Little Python and Nodejs)
Note
APTRS does not natively support Windows installations and setting it up on Windows is not recommended. While it's possible to manually install certain components (such as the APTRS Backend, Frontend, and Database) on Windows, key dependencies like Redis require a Linux environment. Instead, you can use the Docker setup for Windows, which is the preferred option for Windows users.
Note
Default creds are sourav.kalal@aptrs.com & I-am-Weak-Password-Please-Change-Me
Note
APTRS uses cookie attributes such as Secure, HttpOnly, and Lax. For users with a Docker setup, these attributes will not have any effect. However, users with a manual setup need to ensure that they use HTTPS and that both the front end and back end are on the same domain or IP address.
If you prefer to install the APTRS without Docker and have more control over each service, such as Redis, Postgresql, Nginx, etc., or if you want to host the database on a different server, Redis on a different server, etc., you can follow the below process for deploying the APTRS on a server without Docker.
The steps mentioned below were tested on the below setup:
OS - Ubuntu 24.10
Python - 3.12.7 \u00a0(3.9+ is required)
Python Poetry - 1.8.4
PostgreSQL - 16.4 (Ubuntu 16.4-1build1)
Redis Server - 7.0.15
Nginx - 1.26.0
NodeJS - 20.16.0 (18+ is required)
NPM - 9.2.0
Note
While we have provided detailed steps for manual installation and deployment, please note that this method is more prone to errors. Variations in software versions, updates, system configurations, and other factors may result in unexpected issues. Manual installation is intended for individuals who have a solid understanding of Linux, some level of development experience, or expertise in application deployment, and are comfortable troubleshooting potential errors that may arise.
After the installation is complete, we can access the PostgreSQL shell using the command below.
Bash
sudo -u postgres psql\n
From the PostgreSQL shell, create a new database for the APTRS project. Change the name to something relevant to the project.
Bash
CREATE DATABASE aptrsdb;\n
Next, create a database user for our project. Make sure to select a secure password:
Bash
CREATE USER aptrsdb_user WITH PASSWORD 's!!D%AriPB-MO~5';\n
We will set the default encoding to UTF-8 and adjust other settings. Please update the time zone according to your preference, and ensure we use the same time zone as the APTRS.
Bash
ALTER ROLE aptrsdb_user SET client_encoding TO 'utf8';\nALTER ROLE aptrsdb_user SET default_transaction_isolation TO 'read committed';\nALTER ROLE aptrsdb_user SET timezone TO 'UTC';\n\n\\c aptrsdb;\nGRANT USAGE ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO aptrsdb_user;\nALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON TABLES TO aptrsdb_user;\nGRANT ALL PRIVILEGES ON DATABASE aptrsdb TO aptrsdb_user;\n\\q\n
After completing our tasks, we ensure that the PostgreSQL service is running and set to start automatically on reboot.
By default, Poetry is not added to the user or system environment. Ensure you add it to the environment.
Bash
export PATH=\"/home/aptrs/.local/bin:$PATH\"\n
Once completed, we can download the APTRS from GitHub, install the dependencies, and copy the example .env file.
Bash
cd /home/aptrs\ngit clone https://github.com/APTRS/APTRS\ncd APTRS\npoetry install\ncd APTRS\ncp env.example .env \u00a0# The .env file should be located in the same directory as the manage.py file.\n
After obtaining the .env file from the demo environment file, ensure that you update it with the following details: the password for Redis, the PostgreSQL hostname or IP address, the Redis hostname or IP address, the secret key, and any other necessary information. It's important to review all the details in the .env file carefully. For more information on configuring the .env file and the various data it contains, please refer to the Environment Variables section.
Few Important details for .env file:
WHITELIST_IP: Add the server domain name if you're using one; if using a public IP, include that as well. For local network access, add the server's internal IP to the whitelist. Specify the protocol (HTTP or HTTPS) and use Nginx instead of the Django default port (8000). You don\u2019t need to specify a port if using HTTP on 80 or HTTPS on 443. If using S3 buckets, include the bucket URL.
CORS_ORIGIN: Since the frontend and backend will be on the same server, simply allow the server's public or local IP, along with the appropriate protocol and port, if necessary. Both frontend and backend should be accessible via the same domain or IP using Nginx reverse proxy. For more details, check the Frontend documentation.
ALLOWED_HOST: Set this only for the server's domain name or public/internal IP, based on how APTRS will be accessed.
SECRET_KEY: Make sure to update it with a secure key; the same key will be used to generate a JWT token.
From the directory where manage.py is located, run the command below.
Once we have completed the required setup, we need to start the server. APTRS uses Gunicorn for this purpose, which should already be installed through the steps we have completed so far. Since we are using Poetry, we need to locate the full path of Gunicorn for the APTRS project using the command below:
Bash
$> cd /home/aptrs/APTRS\n$> poetry run which gunicorn\n\n##We might get the full path like below, this will be different for all users\n/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn\n
Once we have the full path for gunicorn, we can set up the gunicorn.service with the command below:
Bash
sudo nano /etc/systemd/system/gunicorn.service\n
In the nano file editor, paste the following text. Ensure to update the full path for gunicorn in the gunicorn.service file.
After installing NPM and Node.js, we need to create a .env file for the front end. This .env file will contain the URL for the backend Django API. Since we plan to deploy both the API and the frontend on the same server and they will be accessible through the same domain or IP address using Nginx, we will specify the backend URL as /api/. For more details, please refer to the Frontend documentation.
Bash
cd /home/aptrs/APTRS/frontend\ncp env.example .env\nnano .env\n
In the Nano editor, modify the content to reflect the following changes:
We have everything set up, and our APIs are running with Gunicorn. Now, we need to configure the frontend to serve static files with Nginx and connect Gunicorn to Nginx. To get started, we first need to install Nginx using the command below:
Bash
sudo apt install nginx\n
Since our frontend and backend are in the user directory, we will encounter a permission error from Nginx. To resolve this, we will grant access to the www-data user group with the command below:
Bash
sudo chown -R aptrs:www-data /home/aptrs\n
To complete the setup, we can assume the domain name for our web server is demo.aptrs.com. The configuration below will have the nginx configuration files or folder names based on the domain, which users should replace with their actual domain.
Next, we will create a new server block in the Nginx sites-available directory using the following command:
Upon the first deployment, APTRS automatically creates a default company named APTRS PVT. This company is designated as the internal company, representing the organization using APTRS to generate reports for clients.
Key Details:
The internal company cannot be deleted or added via the frontend or API.
You can edit its name, address, and logo to match your organization\u2019s details.
Any additional companies you create will be treated as client companies.
APTRS includes predefined user groups to facilitate report generation and role management.
Default Groups:
Manager and Project Manager groups are used to include manager details in the reports.
It is recommended not to rename or delete these groups, as doing so may cause errors during report generation.
"},{"location":"installation/post-deploy/#3-user-and-admin","title":"3. User and Admin","text":"
During the first deployment, APTRS creates a default admin user associated with the internal APTRS company.
Key Details:
Do not delete this user, as it is essential for system functionality.
You can update the admin user\u2019s profile details, such as:
Email address
Photo
Name
Password
"}]}
\ No newline at end of file
diff --git a/1.0/sitemap.xml.gz b/1.0/sitemap.xml.gz
index d7c33b0..c64834c 100644
Binary files a/1.0/sitemap.xml.gz and b/1.0/sitemap.xml.gz differ