URGENT! Hotfix - Resolve Main Branch Build Errors

src/content/docs/BACaudit/AuditReport:BAC.md → src/content/docs/BACaudit/AuditReportBAC.md

@@ -1,4 +1,6 @@
-# Web Security Audit: Broken Access Control Vulnerability Report
+---
+title: Web Security Audit Broken Access Control Vulnerability Report
+---
 
 ## Introduction
 
@@ -37,15 +39,18 @@ Our security audit focused on the following test categories:
 ### Testing Procedure
 
 1. **Setup**:
+
    - Clone the repository containing the test script
    - Make the script executable: `chmod +x broken_access_control_test.sh`
    - Configure the API_URL variable in the script (default: `http://localhost:3000`)
 
 2. **Execution**:
+
    - Run the script: `./broken_access_control_test.sh`
    - The script will output results to the console and save detailed logs to a timestamped file
 
 3. **Understanding Results**:
+
    - **PASS (Green)**: The test confirmed proper access controls are in place
    - **FAIL (Red)**: The test identified a security vulnerability that requires attention
    - **INCONCLUSIVE/SKIPPED (Yellow)**: The test requires further investigation or manual verification
@@ -78,11 +83,13 @@ After running the security audit, we identified the following issues:
 ### Critical Vulnerabilities
 
 1. **Insecure Direct Object References (IDOR)**:
+
    - Users can access other users' data by manipulating the user ID
    - Status 200 was returned with full user profile information
    - This allows any authenticated user to view sensitive information of other users
 
 2. **Missing Access Controls on Sensitive Endpoints**:
+
    - The `/api/settings` endpoint returns configuration data without authentication
    - This reveals system configuration including external integrations
 
@@ -93,10 +100,12 @@ After running the security audit, we identified the following issues:
 ### Inconclusive Results Requiring Investigation
 
 1. **Endpoints Returning Empty Results Without Authentication**:
+
    - `/api/activity_types`, `/api/campuses`, `/api/teaching_periods`, and `/api/tii_eula` return 200 status with empty arrays/null values
    - These endpoints should require authentication even when returning empty data
 
 2. **Function Level Access Controls**:
+
    - Teaching period creation attempts resulted in validation errors (400) rather than permission denial
    - The endpoint processes the request and fails on validation instead of rejecting due to insufficient permissions
 
@@ -107,6 +116,7 @@ After running the security audit, we identified the following issues:
 ### Successful Controls
 
 The application successfully implemented:
+
 - Protection against vertical privilege escalation attempts
 - Session token binding and validation
 - HTTP method restrictions (405 responses for inappropriate methods)
@@ -119,11 +129,13 @@ Based on our findings, we recommend the following actions:
 ### Immediate Actions
 
 1. **Fix IDOR Vulnerability**:
+
    - Implement proper authorization checks in the user controller
    - Ensure users can only access their own profile information
    - Add role-based access control for user data access
 
 2. **Secure Settings Endpoint**:
+
    - Require authentication for the `/api/settings` endpoint
    - Implement role-based access to configuration data
    - Consider moving sensitive configuration to a protected admin-only endpoint
@@ -136,17 +148,20 @@ Based on our findings, we recommend the following actions:
 ### Recommended Improvements
 
 1. **Consistent Authentication Checks**:
+
    - Add authentication requirements to all API endpoints, even those returning empty results
    - Implement uniform authorization checks that run before request processing
    - Return consistent 401/403 responses instead of empty data arrays
 
 2. **Enhance Function Level Controls**:
+
    - Ensure permission checks occur before parameter validation
    - Return clear authorization errors rather than validation errors for unauthorized requests
 
 3. **Implement Comprehensive Logging**:
+
    - Add detailed logging for all access control failures
-   - Set up alerts for potential authorization bypass attempts 
+   - Set up alerts for potential authorization bypass attempts
    - Include sufficient context in logs to identify potential attack patterns
 
 4. **Regular Security Testing**:

src/content/docs/injectiontest/sql-injection-report.md

@@ -1,4 +1,6 @@
-# SQL Injection Vulnerability Assessment
+---
+title: SQL Injection Vulnerability Assessment
+---
 
 ## 1. Introduction
 
@@ -7,6 +9,7 @@ SQL Injection is a code injection technique that exploits vulnerabilities in app
 ### Examples of SQL Injection
 
 **Basic Authentication Bypass:**
+
 ```sql
 -- Original intended query
 SELECT * FROM users WHERE username = 'input_username' AND password = 'input_password'
@@ -18,6 +21,7 @@ SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'password'
 This injection makes the WHERE clause always evaluate to true, potentially granting access without valid credentials.
 
 **Data Extraction:**
+
 ```sql
 -- With SQL injection input: admin' UNION SELECT username, password FROM users--
 SELECT * FROM users WHERE username = 'admin' UNION SELECT username, password FROM users--' AND password = 'password'
@@ -26,6 +30,7 @@ SELECT * FROM users WHERE username = 'admin' UNION SELECT username, password FRO
 This injection attempts to retrieve all usernames and passwords from the database.
 
 **Destructive Operations:**
+
 ```sql
 -- With SQL injection input: '; DROP TABLE users;--
 SELECT * FROM users WHERE username = ''; DROP TABLE users;--' AND password = 'password'
@@ -38,16 +43,20 @@ This injection attempts to delete the entire users table.
 The following test cases were executed to assess the application's resistance to SQL injection attacks:
 
 1. **Authentication Bypass Tests:**
+
    - Testing `' OR '1'='1` in username and password fields
    - Testing `admin' --` to comment out password verification
 
 2. **Data Extraction Tests:**
+
    - Testing `' UNION SELECT username, password FROM users --` to retrieve sensitive data
 
 3. **Destructive Operation Tests:**
+
    - Testing `' OR '1'='1'; DROP TABLE users; --` to attempt database destruction
 
 4. **Other Common Patterns:**
+
    - Testing `admin'; SELECT * FROM users; --` to execute additional queries
 
 5. **Baseline Verification:**
@@ -67,23 +76,27 @@ To execute the tests, you will need:
 ### Test Execution
 
 1. **Clone the repository:**
+
    ```bash
    git clone https://github.com/thoth-tech/doubtfire-astro.git
    cd doubtfire-astro
    ```
 
 2. **Navigate to the security test scripts directory:**
+
    ```bash
    cd docs/src/content/security/scripts
    ```
 
 3. **Make the script executable:**
+
    ```bash
    chmod +x test-sql-injection.sh
    ```
 
 4. **Review and configure the script if needed:**
    The script is pre-configured with the following settings:
+
    - API URL: http://localhost:3000
    - Client URL: http://localhost:4200
    - Admin credentials: username "aadmin", password "password"
@@ -92,11 +105,13 @@ To execute the tests, you will need:
    Modify these values in the script if your environment differs.
 
 5. **Run the script:**
+
    ```bash
    ./test-sql-injection.sh
    ```
 
 6. **Interpret the results:**
+
    - Green checkmarks (✓) indicate successful blocks of injection attempts
    - Red X marks (✗) indicate potential vulnerabilities
    - Yellow question marks (?) indicate inconclusive tests
@@ -122,21 +137,25 @@ If Nikto is installed, it will also perform a broader vulnerability scan of the
 When executing the script against our test environment, we observed the following results:
 
 #### Username Field Tests:
+
 - All injection attempts were blocked with 401 status codes
 - Error messages were properly sanitized without revealing database details
 - 6/6 tests passed, 0 failed, 0 inconclusive
 
 #### Password Field Tests:
+
 - All injection attempts were blocked with 401 status codes
 - Error messages were properly sanitized without revealing database details
 - 6/6 tests passed, 0 failed, 0 inconclusive
 
 #### Baseline Functionality:
+
 - Valid credentials test shows as "failed" in script output, but this is only because the script expects a 200 status code and specific response format
 - The application actually returns a 201 status code with valid user data, indicating the authentication system is working correctly
 - This script limitation doesn't affect the SQL injection test results
 
 #### Security Scan:
+
 - Nikto scan completed without detecting SQL injection vulnerabilities
 - Some minor HTTP header recommendations were identified (X-Frame-Options, Content-Type-Options)
 
@@ -151,22 +170,27 @@ The application demonstrated strong resistance to SQL injection attacks at the a
 Based on our findings, the following actions are recommended:
 
 1. **Documentation Update:**
+
    - Add SQL injection prevention techniques to the developer documentation
    - Create training material for new developers on secure coding practices
 
 2. **Security Headers Implementation:**
+
    - Implement X-Frame-Options header to prevent clickjacking attacks
    - Add X-Content-Type-Options header to prevent MIME type sniffing
 
 3. **Regular Security Testing:**
+
    - Implement automated SQL injection testing as part of the CI/CD pipeline
    - Schedule quarterly security audits with broader scope
 
 4. **Input Validation Review:**
+
    - Review other data entry points in the application for similar protection
    - Consider implementing a central input validation service
 
 5. **Error Handling Enhancement:**
+
    - Review error messages across the application to ensure they don't leak sensitive information
    - Implement consistent error handling patterns across all endpoints
 

src/content/docs/security/pdf-security-updates.md

@@ -1,10 +1,15 @@
-# PDF Security Updates
+---
+title: PDF Security Updates
+---
 
 ## Overview
+
 This document outlines the changes made to address a malicious code execution vulnerability related to the handling of PDFs in the Doubtfire application.
 
 ## Potential Impact if Unfixed
+
 If this vulnerability is not addressed, attackers could upload PDFs containing embedded JavaScript or other malicious payloads. When these files are viewed, the malicious code could execute in the user's browser, potentially leading to:
+
 - Unauthorized access to user data or session tokens.
 - Execution of arbitrary code in the context of the application.
 - Phishing attacks or redirection to malicious sites.
@@ -13,15 +18,19 @@ If this vulnerability is not addressed, attackers could upload PDFs containing e
 ## Changes Implemented
 
 ### 1. Sanitize Uploaded PDFs
+
 - Implemented server-side scanning for malicious JavaScript embedded in PDFs.
 - **Action Taken:** Added a validation step during PDF uploads to detect and reject files containing embedded JavaScript or other malicious content.
 
 ### 2. Restrict or Disable JavaScript Execution in PDF Viewers
+
 - JavaScript execution in PDFs is not required for the application.
 - **Action Taken:** Configured the PDF viewer to disable JavaScript execution entirely, ensuring that no embedded scripts can run.
 
 ## Affected Components
+
 The following components and files were updated as part of this security enhancement:
+
 - **doubtfire-web:**
   - Updated the PDF.js integration and disabled JavaScript execution in the file viewer.
   - **Affected file:** `file-viewer.component.html`
@@ -30,6 +39,7 @@ The following components and files were updated as part of this security enhance
   - **Affected files:** `file_helper.rb`, `file_helper_test.rb`
 
 ## Recommendations
+
 - Regularly update dependencies like PDF.js to their latest secure versions.
 - Continuously monitor for vulnerabilities in third-party libraries and implement patches promptly.
 - **Sanitization for Other File Types:**
@@ -39,10 +49,12 @@ The following components and files were updated as part of this security enhance
   - Limit file size and scan for known exploit patterns.
 
 ## References
+
 - [PDF.js Security Updates](https://github.com/mozilla/pdf.js/releases)
 - [OWASP File Upload Security Guidelines](https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload)
 
 ## Version History
+
 - **Version:** 1.0
 - **Date:** 07/05/2025
 - **Author:** Ibitope Fatoki