Company: {{ mycompany }}
+ + ``` + + +## 2. Project Manager Users +- **Description:** + + 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 +Project Managers:
+-
+ {% for user in projectmanagers %}
+
- {{ user.full_name }} - {{ user.position }} + {% endfor %} +
Customer Users:
+-
+ {% for user in customeruser %}
+
- {{ user.full_name }} - {{ user.position }} + {% endfor %} +
Vulnerability Report for {{ project.name }}
+Total Vulnerabilities: {{ totalvulnerability }}
+Critical Issues: {{ ciritcal }}
+High Severity Issues: {{ high }}
+ ``` + + + + + +3. **Dynamic Content**: + - Use loops and conditionals to dynamically render data. For example: + ```html +-
+ {% for vuln in vuln %}
+
- {{ vuln.vulnerabilityname }} - Severity: {{ vuln.vulnerabilityseverity }} + {% endfor %} +
{{ mycomany }} - Vulnerability Report
+Project: {{ project.name }}
+Total Vulnerabilities: {{ totalvulnerability }}
+Critical Issues: {{ ciritcal }}
+High Severity Issues: {{ high }}
+Medium Severity Issues: {{ medium }}
+Low Severity Issues: {{ low }}
+Informational Issues: {{ info }}
+ +Vulnerability Breakdown
+ {{ pie_chart|safe }} + +Vulnerabilities
+-
+ {% for v in vuln %}
+
- {{ v.vulnerabilityname }} - Severity: {{ v.vulnerabilityseverity }} + {% endfor %} +
Total Vulnerabilities: {{ totalvulnerability }}
+ ``` + +## 2. Severity Count +- **Description:** + Shows the count of vulnerabilities that have a severity of Critical or High, Medium, Low, None. +- **Usage Example:** + You can display the severity count. + + ```html +Critical Vulnerabilities: {{ critical }}
+High Vulnerabilities: {{ high }}
+Medium Vulnerabilities: {{ medium }}
+Low Vulnerabilities: {{ low }}
+Informational Vulnerabilities: {{ info }}
+ ``` + + +## 3. Report Standard +- **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 seperated by comma. +- **Usage Example:** + Display the methodology or standard used in the vulnerability report. + + ```html +Report Standard: {{ standard|join:", " }}
+ ``` + + +## 4. Report Type +- **Description:** + Specifies the type of report being generated. This can include types like "Audit" or "Re-Audit". +- **Usage Example:** + Show the type of the report (Audit or Re-Audit). + + ```html +Report Type: {{ Report_type }}
+ ``` + +## 5. Chart Image +- **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 +{{ pie_chart|safe }}
+ ```
\ No newline at end of file
diff --git a/docs/custom-report/pdf/pdf.md b/docs/custom-report/pdf/pdf.md
new file mode 100644
index 0000000..54dd356
--- /dev/null
+++ b/docs/custom-report/pdf/pdf.md
@@ -0,0 +1,56 @@
+# Customized PDF Report Documentation
+
+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.
+
+### How It Works
+The system is designed so you don’t 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.
+
+### File Structure for Customization
+Within the project root directory, there is a subdirectory named `APTRS`. This contains the following important folders for report customization:
+
+1. **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.
+
+2. **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.
+
+### Key Files for Customization
+1. **`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.
+
+2. **`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.
+
+3. **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.
+
+### Fonts
+
+The project uses the **Fira Sans** font by default, stored in the `static/fonts` folder. You can:
+
+ - Add new fonts to the `fonts` folder.
+ - Update the CSS in the `report-page.css` file to use your fonts.
+
+### Customization Tips
+- Modify **HTML** files to change content layout, add new sections, or reorder components.
+- Edit **CSS** files to change colors, fonts, or styles for specific sections.
+- Use the modular structure to quickly locate and modify styles for individual components.
+- For global styles or formatting (e.g., page numbers, headers, footers), update `report-page.css`.
+
+### Important Notes
+- 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.
+
+
+
+
diff --git a/docs/custom-report/pdf/project.md b/docs/custom-report/pdf/project.md
new file mode 100644
index 0000000..3c934dd
--- /dev/null
+++ b/docs/custom-report/pdf/project.md
@@ -0,0 +1,104 @@
+
+
+## Project Model Variables for Template Customization
+
+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.
+
+### Available Variables and Their Usage
+
+1. **`project.name`**
+ - Represents the name of the project.
+ - Example usage in HTML:
+ ```html
+ Project Name: {{ project.name }}
+ ``` + +2. **`project.companyname`** + - A foreign key to the `Company` model, representing the company associated (Customer Company) with the project. + - Example usage: + ```html +Company Name: {{ project.companyname.name }}
+ ``` + +3. **`project.description`** + - A detailed description of the project. + - Example usage: + ```html +Description: {{project.description|clean_html}}
+ ``` + - It uses CKeditor HTML data, using ``|clean_html`` allow to render html data securely instead of as text. + +4. **`project.projecttype`** + - Specifies the type of project. + - Example usage: + ```html +Project Type: {{ project.projecttype }}
+ ``` + +5. **`project.startdate`** + - The start date of the project. + - Example usage: + ```html +Start Date: {{ project.startdate }}
+ ``` + - You can also modify the date format + ```html +Start Date: {{project.startdate|date:"d/m/Y" }}
+ ``` + +6. **`project.enddate`** + - The end date of the project. + - Example usage: + ```html +End Date: {{ project.enddate }}
+ ``` + - You can also modify the date format + ```html +End Date: {{project.enddate|date:"d/m/Y" }}
+ ``` + +7. **`project.testingtype`** + - The type of testing performed for the project (e.g., White Box, Black Box). + - Example usage: + ```html +Testing Type: {{ project.testingtype }}
+ ``` + +8. **`project.projectexception`** + - Notes or exceptions for the project, if any. + - Example usage: + ```html +Exceptions: {{ project.projectexception|clean_html }}
+ ``` + - It uses CKeditor HTML data, using ``|clean_html`` allow to render html data securely instead of as text. + - 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. + ```html + {% if project.projectexception %} +Exceptions: {{ project.projectexception|clean_html }}
+ {% endif %} + ``` + + +9. **`project.owner`** + - A many-to-many relationship representing users associated as owners of the project. + - To display all owners: + ```html +-
+ {% for owner in project.owner.all %}
+
- {{ owner.username }} +
- {{ owner.full_name }} +
- {{ owner.number }} +
- {{ owner.position }} + {% endfor %} + + ``` + +10. **`project.status`** + - The current status of the project, based on `PROJECT_STATUS_CHOICES` (e.g., Upcoming, In Progress, Delay, Completed). + - Example usage: + ```html +
- {{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }} + + {% for owner in retest.owner.all %} + {{ owner.full_name }} + + {% endfor %} + + {% endfor %} +
- {{ retest.startdate }} - {{ retest.enddate }} | Status: {{ retest.status }} + + {% for owner in retest.owner.all %} + {{ owner.full_name }} + + {% endfor %} + + {% endfor %} +
- {{ scope.scope }} - {{ scope.description }} + {% endfor %} +
Status: {{ project.status }}
+ ``` + + diff --git a/docs/custom-report/pdf/retest.md b/docs/custom-report/pdf/retest.md new file mode 100644 index 0000000..9847e3c --- /dev/null +++ b/docs/custom-report/pdf/retest.md @@ -0,0 +1,41 @@ +# Context Variable for Project Retests + +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 +Project Retests:
+-
+ {% for retest in totalretest %}
+
Project Retests:
+-
+ {% for retest in totalretest %}
+
Project Scope:
+-
+ {% for scope in projectscope %}
+
Vulnerability Name: {{ vulnerability.vulnerabilityname }}
+ {% endfor %} + ``` + +2. **`vulnerability.vulnerabilityseverity`** + - The severity of the vulnerability (e.g., "High", "Medium"). + - Example usage: + ```html + {% for vulnerability in vuln %} +Severity: {{ vulnerability.vulnerabilityseverity }}
+ {% endfor %} + ``` + +3. **`vulnerability.cvssscore`** + - The CVSS score associated with the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +CVSS Score: {{ vulnerability.cvssscore }}
+ {% endfor %} + ``` + +4. **`vulnerability.cvssvector`** + - The CVSS vector associated with the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +CVSS Vector: {{ vulnerability.cvssvector }}
+ {% endfor %} + ``` + +5. **`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 %} +Status: {{ vulnerability.status }}
+ {% endfor %} + ``` + +6. **`vulnerability.vulnerabilitydescription`** + - A description of the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +Description: {{ vulnerability.vulnerabilitydescription|clean_html }}
+ {% endfor %} + ``` + +7. **`vulnerability.POC`** + - The proof of concept (POC) for the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +POC: {{ vulnerability.POC|clean_html }}
+ {% endfor %} + ``` + +8. **`vulnerability.vulnerabilitysolution`** + - The recommended solution for the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +Solution: {{ vulnerability.vulnerabilitysolution|clean_html }}
+ {% endfor %} + ``` + +9. **`vulnerability.vulnerabilityreferlnk`** + - A reference link related to the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +Reference Link: {{ vulnerability.vulnerabilityreferlnk|clean_html }}
+ {% endfor %} + ``` + +10. **`vulnerability.created`** + - The timestamp when the vulnerability was created. + - Example usage: + ```html + {% for vulnerability in vuln %} +Created: {{ vulnerability.created }}
+ {% endfor %} + ``` + +11. **`vulnerability.created_by`** + - The user who created the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +Created By: {{ vulnerability.created_by.username }}
+ {{ vulnerability.created_by.full_name }} + {% endfor %} + ``` + - Similar to project owner, you can use other filed as well like email, number or postion etc. + +12. **`vulnerability.last_updated_by`** + - The user who last updated the vulnerability. + - Example usage: + ```html + {% for vulnerability in vuln %} +Last Updated By: {{ vulnerability.last_updated_by.username }}
+ {% endfor %} + ``` + +### Available Variables for Vulnerableinstance Model + +1. **`instance.vulnerabilityid`** + - The `Vulnerability` object associated with the instance. + - Example usage: + ```html + {% for instance in instances %} +Vulnerability Name: {{ instance.vulnerabilityid.vulnerabilityname }}
+ {% endfor %} + ``` + +2. **`instance.project`** + - The project associated with the vulnerable instance. + - Example usage: + ```html + {% for instance in instances %} +Project: {{ instance.project.name }}
+ {% endfor %} + ``` + +3. **`instance.URL`** + - The URL of the vulnerable instance. + - Example usage: + ```html + {% for instance in instances %} +URL: {{ instance.URL }}
+ {% endfor %} + ``` + +4. **`instance.Parameter`** + - The parameter of the vulnerable instance. + - Example usage: + ```html + {% for instance in instances %} +Parameter: {{ instance.Parameter }}
+ {% endfor %} + ``` + +5. **`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 %} +Status: {{ instance.status }}
+ {% endfor %} + ``` + +### Displaying Vulnerable Instances for a Specific Vulnerability in a Template +The instances query set or list does not associte with the vulnerability name, instances variable contain all instances for the project, In most cases we need all instances for a vulnerabiltiy. 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: + +```html +{% for vulnerability in vuln %} + +Vulnerability Name: {{ vulnerability.vulnerabilityname }}
+ +{{ vulnerability.vulnerabilitysolution|clean_html }}
+ +{{ vulnerability.vulnerabilityreferlnk|clean_html }}
+ +POC: {{ vulnerability.POC|clean_html }}
+ +Description: {{ vulnerability.vulnerabilitydescription|clean_html }}
+ +Status: {{ vulnerability.status }}
+ +CVSS Vector: {{ vulnerability.cvssvector }}
+ +Severity: {{ vulnerability.vulnerabilityseverity }}
+ + {% for instance in instances %} + + {% if instance.vulnerabilityid.id == vulnerability.id %} +
\ No newline at end of file
diff --git a/docs/getting-started/demo.md b/docs/getting-started/demo.md
new file mode 100644
index 0000000..78adc31
--- /dev/null
+++ b/docs/getting-started/demo.md
@@ -0,0 +1,20 @@
+## Live Demo Instance
+
+Explore the features of APTRS through our live demo instance:
+
+- **Live Demo**
+ - Username: [sourav.kalal@aptrs.com](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.
+
+!!! tip ""
+
+ > 🌨️ Huge thanks to DigitalOcean for their support of the APTRS project.
+
+
+!!! warning
+
+ 🚧 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.
+
+
diff --git a/docs/getting-started/license.md b/docs/getting-started/license.md
new file mode 100644
index 0000000..a12d109
--- /dev/null
+++ b/docs/getting-started/license.md
@@ -0,0 +1 @@
+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
diff --git a/docs/image/1.0/logo.png b/docs/image/1.0/logo.png
new file mode 100644
index 0000000..731d41e
Binary files /dev/null and b/docs/image/1.0/logo.png differ
diff --git a/docs/index.md b/docs/index.md
index 4c0add9..1f449de 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,22 +1,12 @@
-# APTRS
+# Automated Penetration Testing Reporting System
+
+
+
-
+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 (Automated Penetration Testing Reporting System) is an automated reporting tool in Python and Django. The tool allows Penetration testers to create a report directly without using the Traditional Docx file. It also provides an approach to keeping track of the projects and vulnerabilities.
-### Sponsor
-[](https://github.com/sponsors/Anof-cyber)
+
+
+
-### Team
-##### [Sourav Kalal](https://twitter.com/ano_f_)
-
-### Documentation
-- #### [Prerequisites](Prerequisites.md)
-- #### [Installation](installation.md)
-- #### [Running APTRS Server](Running.md)
-- #### [Company](Company.md)
-- #### [Customer](Customer.md)
-- #### [Vulnerability Database](Vulnerability-Database.md)
-- #### [Setting](Setting.md)
-- #### [Project](Project.md)
-- #### [Report Template](Report-Template.md)
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/installation.md b/docs/installation.md
deleted file mode 100644
index 61bf667..0000000
--- a/docs/installation.md
+++ /dev/null
@@ -1,26 +0,0 @@
-
-# Installation
-
-**Tested with Python 3.8.10 on Windows 10/11, Kali Linux 2022.2/3, Ubuntu 20.04.5 LTS**
-
-
-!!! info "Note"
- Please make sure that all the [prerequisites](Prerequisites.md) mentioned are installed first.
-
-!!! info "Note"
- it is recommended to delete the `db.sqlite3` file and then run the install file.
-
-## Linux
-```bash
-git clone https://github.com/Anof-cyber/APTRS.git
-cd APTRS
-bash install.sh
-```
-***
-
-## Windows
-```batch
-git clone https://github.com/Anof-cyber/APTRS.git
-cd APTRSF
-install.bat
-```
\ No newline at end of file
diff --git a/docs/installation/certificate.md b/docs/installation/certificate.md
new file mode 100644
index 0000000..c17f073
--- /dev/null
+++ b/docs/installation/certificate.md
@@ -0,0 +1,3 @@
+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:
+
+[https://github.com/APTRS/APTRS/tree/main/Certificate](https://github.com/APTRS/APTRS/tree/main/Certificate)
\ No newline at end of file
diff --git a/docs/installation/docker.md b/docs/installation/docker.md
new file mode 100644
index 0000000..55cf625
--- /dev/null
+++ b/docs/installation/docker.md
@@ -0,0 +1,28 @@
+
+
+## Linux
+
+```bash
+git clone https://github.com/APTRS/APTRS
+cd APTRS
+cp env.docker .env
+nano .env
+docker-compose up
+
+```
+
+## Windows
+```shell
+git clone https://github.com/APTRS/APTRS
+cd APTRS
+copy env.docker .env
+notepad .env
+docker-compose up
+```
+
+
+
+!!! note
+
+ The **.env** file contains all the environment variables, such as passwords for JWT, Database credentials, Cloud S3 bucket details, etc. It’s important to update the default passwords and details before deploying the application. For more information, refer to the **[Environment Variables](/installation/env/)** section.
+
diff --git a/docs/installation/env.md b/docs/installation/env.md
new file mode 100644
index 0000000..bdf0908
--- /dev/null
+++ b/docs/installation/env.md
@@ -0,0 +1,17 @@
+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 Setup
+| ------------------| ----------------------------- | ------------------------------------ | ------------------------------------ |
+| `SECRET_KEY` | This key is used by Backend including JWT, Should be secured and random. | Manually need to be updated in env file| Auto Generated no need to update it. |
+| `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 | Auto Generated but 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 | Auto Generated but 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 | Auto Generated but 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. | Auto Generated no need to update it. |
+|`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 | Auto Generated no need to update it. |
+|`POSTGRES_HOST` | Postgres host name | Should not be updated. | Auto Generated no need to update it. |
+|`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_ID` `AWS_SECRET_ACCESS_KEY` `AWS_STORAGE_BUCKET_NAME` `AWS_S3_REGION_NAME` `AWS_S3_CUSTOM_DOMAIN` `AWS_S3_ENDPOINT_URL` | Bucket details if `USE_S3` is set to `True`|Optional| Optional|
\ No newline at end of file
diff --git a/docs/installation/frontend.md b/docs/installation/frontend.md
new file mode 100644
index 0000000..b33498b
--- /dev/null
+++ b/docs/installation/frontend.md
@@ -0,0 +1,110 @@
+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
+cd APTRS
+cd Frontend
+cp env.example .env
+npm run build
+```
+
+!!! 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.
+
+
-### Team
-##### [Sourav Kalal](https://twitter.com/ano_f_)
-
-### Documentation
-- #### [Prerequisites](Prerequisites.md)
-- #### [Installation](installation.md)
-- #### [Running APTRS Server](Running.md)
-- #### [Company](Company.md)
-- #### [Customer](Customer.md)
-- #### [Vulnerability Database](Vulnerability-Database.md)
-- #### [Setting](Setting.md)
-- #### [Project](Project.md)
-- #### [Report Template](Report-Template.md)
\ No newline at end of file
+> + + + + + +### Hosting the Frontend and API Together + +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 + +VITE_APP_API_URL = http://backend-api.com/api/ +npm run build +``` + +However, it is not recommended to host the API and frontend on separate domains, IPs, or ports. Here's why: + +1. 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. + +2. 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. + +4. 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. + +4. 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 ``
+ ```
+
+### Challenges with Hosting the API and Frontend on Separate Domains
+
+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.
+
+### Benefits of Hosting API and Frontend on the Same Domain
+
+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
+ 
+```
+
+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.
+
+
+
+### Recommendation
+For best results:
+
+1. Host Both API and Frontend on the Same Domain
+
+ - 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.
+
+2. 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.
\ No newline at end of file
diff --git a/docs/installation/install.md b/docs/installation/install.md
new file mode 100644
index 0000000..a773400
--- /dev/null
+++ b/docs/installation/install.md
@@ -0,0 +1,9 @@
+APTRS can be installed using two methods:
+
+- Docker (Recommended for most users)
+- Manual (User with Knowledge of Ngnix 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.
\ No newline at end of file
diff --git a/docs/installation/manual.md b/docs/installation/manual.md
new file mode 100644
index 0000000..2a66d95
--- /dev/null
+++ b/docs/installation/manual.md
@@ -0,0 +1,255 @@
+# Manual Installation
+
+If you prefer to install the APTRS without docker and have more control over each serive like Redis, Postgresql, Ngnix etc, Or you want to host Data base on diffrent server, redis on diffrent etc. You can follow the below process on deplying the APTRS on a server without doceker, The steps mentieod below were testing on below setup.
+
+
+- OS - Ubutnu 24.10
+- Python - 3.12.7 (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
+
+## PostgreSQL Setup
+
+Run the below command to install PostgreSQL.
+
+```bash
+sudo apt-get install postgresql postgresql-contrib
+```
+
+Once the installation is completed we can access the PostgreSQL shell with below command.
+
+```bash
+sudo -u postgres psql
+```
+
+From the PostgreSQL shell Create new database for APTRS project (Change the name you want recocmend to keep relenvet name to the project)
+
+```bash
+CREATE DATABASE aptrsdb;
+```
+
+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';
+```
+
+We are setting the default encoding to UTF-8 and change other settings. Make sure to update the Time zone as per your choise, also we need to make sure we use the same timezone the APTRS as well.
+
+```bash
+ALTER ROLE aptrsdb_user SET client_encoding TO 'utf8';
+ALTER ROLE aptrsdb_user SET default_transaction_isolation TO 'read committed';
+ALTER ROLE aptrsdb_user SET timezone TO 'UTC';
+
+\c aptrsdb;
+GRANT USAGE ON SCHEMA public TO aptrsdb_user;
+GRANT ALL PRIVILEGES ON SCHEMA public TO aptrsdb_user;
+GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO aptrsdb_user;
+GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO aptrsdb_user;
+ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON TABLES TO aptrsdb_user;
+GRANT ALL PRIVILEGES ON DATABASE aptrsdb TO aptrsdb_user;
+\q
+```
+
+
+Once we are done, we make sure the postgresql service is running and always up with reboot.
+
+```bash
+sudo systemctl start postgresql
+sudo systemctl enable postgresql
+```
+
+
+
+
+## Redis Setup
+
+
+Run the below command to install Redis.
+
+```bash
+sudo apt install redis-server
+```
+
+Once redis is installed, we want to make sure we change the `supervised` and add password to our redis service.
+
+```bash
+sudo nano /etc/redis/redis.conf
+```
+
+Within `redis.conf` file add the below contenxt, Make sure to update the password to a new secure password
+
+```bash
+supervised systemd
+requirepass s!!D%AriPB-MO~5
+```
+
+Once we are done, we make sure the redis service is running and always up with reboot.
+
+```bash
+sudo systemctl restart redis.service
+sudo systemctl restart redis
+sudo systemctl enable redis
+```
+
+
+
+
+## APTRS Django APIs Setup
+
+
+Run the below command to install Python and other requirements for the APTRS.
+
+```bash
+sudo apt install python3-venv python3-dev libpq-dev weasyprint
+```
+
+Its better to seperate the API and webserice from other users in the machine, Its good to create a seperate account for it.
+
+```bash
+sudo adduser aptrs
+sudo usermod -aG sudo aptrs
+sudo su - aptrs
+```
+
+APTRS make use of Python Poetry to manage the dependices we make sure we install it.
+
+```bash
+curl -sSL https://install.python-poetry.org | python3 -
+```
+
+By default Poetry will not be added into the user or system enviment. Make sure to add it to the enviment.
+
+```bash
+export PATH="/home/aptrs/.local/bin:$PATH"
+```
+
+Once done we can download the APTRS from the GitHub, install the dependicies, and make copy the example .env file.
+
+```bash
+cd /home/aptrs
+git clone https://github.com/APTRS/APTRS
+cd APTRS
+poetry install
+cp env.docker APTRS/.env # The .env file should be located in the same directory as the manage.py file.
+cd APTRS
+
+```
+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](/installation/env/)** 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’t 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](/installation/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.
+
+```bash
+poetry shell
+python3 manage.py makemigrations accounts
+python3 manage.py makemigrations configapi
+python3 manage.py makemigrations customers
+python3 manage.py makemigrations project
+python3 manage.py makemigrations vulnerability
+python3 manage.py makemigrations
+python3 manage.py migrate
+python3 manage.py first_setup
+exit
+```
+
+
+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
+$> poetry run which gunicorn
+
+##We might get the full path like below, this will be different for all users
+/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn
+```
+
+Once we have full path for gunicorn we can setup the `gunicorn.service` with below command:
+
+
+```bash
+sudo nano /etc/systemd/system/gunicorn.service
+```
+
+In the nano file editor paste the below context. Make sure to update the full path of the gunicorn in the below file for `gunicorn.socket`.
+
+
+
+```bash
+[Unit]
+Description=gunicorn daemon to serve APTRS
+Requires=gunicorn.socket
+After=network.target
+
+[Service]
+User=aptrs
+Group=www-data
+WorkingDirectory=/home/aptrs/APTRS/APTRS
+ExecStart=/home/aptrs/.cache/pypoetry/virtualenvs/aptrs-h1P6HTQN-py3.12/bin/gunicorn --workers 3 --access-logfile - --bind unix:/run/gunicorn.sock APTRS.wsgi:application
+
+[Install]
+WantedBy=multi-user.target
+```
+
+
+
+Now we can setup the `gunicorn.socket` with below command:
+
+```bash
+sudo nano /etc/systemd/system/gunicorn.socket
+```
+
+```bash
+[Unit]
+Description=gunicorn socket
+
+[Socket]
+ListenStream=/run/gunicorn.sock
+
+[Install]
+WantedBy=sockets.target
+
+```
+
+With all set We can start the gunicorn service with below command
+
+```bash
+sudo systemctl start gunicorn.socket
+sudo systemctl enable gunicorn.socket
+sudo systemctl enable gunicorn
+sudo systemctl daemon-reload
+sudo systemctl restart gunicorn
+```
+
+You can verify if APTRS APIs are up and running with below command
+
+```bash
+curl --unix-socket /run/gunicorn.sock localhost/api/config/ping/
+
+{"status":"ok","message":"Server is up and running!"}
+```
+
+In case some error you can check if the socket and service has any error or not with below command
+```bash
+sudo systemctl status gunicorn.socket
+sudo systemctl status gunicorn
+```
+
+
+
+### Frontend ViteJs Setup
+
+## Nginx Setup
\ No newline at end of file
diff --git a/docs/logo.png b/docs/logo.png
new file mode 100644
index 0000000..731d41e
Binary files /dev/null and b/docs/logo.png differ
diff --git a/mkdocs.yml b/mkdocs.yml
index 1d43757..c51ee04 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -4,15 +4,19 @@ theme:
logo: https://i.ibb.co/BsfwzSf/download.png
favicon: https://i.ibb.co/LY6gbtW/android-chrome-512x512.png
features:
+ - toc.integrate
+ - toc.follow
+ - navigation.path
+ - navigation.indexes
- navigation.tabs
- navigation.tabs.sticky
- navigation.path
+ - search.suggest
- navigation.sections
- navigation.tracking
- navigation.instant
- - navigation.indexes
- - toc.follow
- content.tabs.link
+
palette:
@@ -30,17 +34,62 @@ theme:
icon: material/brightness-4
name: Switch to system preference
+plugins:
+ - glightbox
+ - search:
+ enabled: true
+
nav:
- - Home: index.md
- - Prerequisites: Prerequisites.md
- - Installation: installation.md
- - Running APTRS Server: Running.md
- - Company: Company.md
- - Customer: Customer.md
- - Vulnerability Database: Vulnerability-Database.md
- - Setting: Setting.md
- - Project: Project.md
- - Report Template: Report-Template.md
+ - Getting Started:
+ - index.md
+ - Features: getting-started/Features.md
+ - Project Contribution: getting-started/Contribution.md
+ - Sponsors: getting-started/Sponsors.md
+ - Demo: getting-started/demo.md
+ - License: getting-started/license.md
+ - Installation:
+ - installation/install.md
+ - Docker: installation/docker.md
+ - Manual: installation/manual.md
+ - Environment Variables: installation/env.md
+ - Frontend: installation/frontend.md
+ - Secure Certificate: installation/certificate.md
+ - Features:
+ - Features/index.md
+ - Dashboard: Features/dashboard/dashboard.md
+ - Users: Features/Users/users.md
+ - Company: Features/company/company.md
+ - Customer: Features/company/customer.md
+ - Groups and Permissions: Features/permission/permission.md
+ - Vulnerability DB: Features/vulnerabilityDB/vulnerability.md
+ - Configuration: Features/configuration/configuration.md
+ - Project:
+ - Project View: Features/project/project-view.md
+ - Project Vulnerability: Features/project/Vulnerability.md
+ - Project Scope: Features/project/scope.md
+ - Project Retest: Features/project/retest.md
+ - Project Report: Features/project/report.md
+ - Report Customization:
+ - PDF:
+ - custom-report/pdf/pdf.md
+ - Context Variable: custom-report/pdf/context-variable.md
+ - Project: custom-report/pdf/project.md
+ - Vulnerability: custom-report/pdf/vulnerability.md
+ - Company User: custom-report/pdf/company-user.md
+ - Project Scope: custom-report/pdf/scope.md
+ - Project Retest: custom-report/pdf/retest.md
+ - Additional: custom-report/pdf/other.md
+ - DOCX:
+ - custom-report/docx/docx.md
+ - Project: custom-report/docx/project.md
+ - Vulnerability: custom-report/docx/vulnerability.md
+ - Company User: custom-report/docx/company-user.md
+ - Project Scope: custom-report/docx/scope.md
+ - Project Retest: custom-report/docx/retest.md
+ - Additional: custom-report/docx/other.md
+ - API Documentation: API.md
+ - Change Log: https://github.com/APTRS/APTRS-Changelog/blob/main/README.md" target="_blank
+
markdown_extensions:
@@ -48,6 +97,7 @@ markdown_extensions:
- pymdownx.details
- pymdownx.superfences
- def_list
+ - tables
- pymdownx.tasklist:
custom_checkbox: true
- pymdownx.superfences
@@ -56,10 +106,36 @@ markdown_extensions:
slugify: !!python/object/apply:pymdownx.slugs.slugify
kwds:
case: lower
-
+ - pymdownx.highlight:
+ pygments_lang_class: true
+ auto_title: true
+ line_spans: __span
+ - pymdownx.critic
+ - pymdownx.caret
+ - pymdownx.keys
+ - pymdownx.mark
+
+
extra:
version:
provider: mike
+ social:
+ - icon: fontawesome/brands/twitter
+ link: https://twitter.com/ano_f_
+ - icon: fontawesome/brands/github
+ link: https://github.com/Anof-cyber/
+ - icon: fontawesome/brands/linkedin
+ link: https://www.linkedin.com/in/sourav-kalal
+ - icon: fontawesome/brands/medium
+ link: https://medium.com/@Ano_F_
+
+extra_javascript:
+ - https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.7.2/highlight.min.js
+ - https://cdnjs.cloudflare.com/ajax/libs/prism/9000.0.1/prism.min.js
+
+extra_css:
+ - https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.7.2/styles/default.min.css
+ - https://cdnjs.cloudflare.com/ajax/libs/prism/9000.0.1/themes/prism-dark.min.css
-repo_url: https://github.com/Anof-cyber/APTRS
-repo_name: Anof-cyber/APTRS
\ No newline at end of file
+repo_url: https://github.com/APTRS/APTRS
+repo_name: APTRS/APTRS
\ No newline at end of file
diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 0000000..acaf3ac
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,2 @@
+mkdocs-material==9.5.44
+mkdocs-glightbox==0.4.0