Security: Unauthenticated Privilege Escalation via Registration, Password Change Without Auth, SQL Injection, and Unrestricted File Upload

[lighthousekeeper1212]

Security Vulnerability Report

This report documents 13 security vulnerabilities (4 CRITICAL, 6 HIGH, 1 MEDIUM) identified during an authorized security audit of LaraAdmin. Findings are grouped by severity.

---

CRITICAL Severity

1. Privilege Escalation via Registration

File: app/Http/Controllers/Auth/RegisterController.php:108-209

The registration endpoint POST /register trusts the user-supplied context_type field. The view-level check User::count() == 0 controls whether the registration form is displayed, but the controller does not enforce this server-side. By submitting a POST request with context_type=Employee, an attacker can create a SUPER_ADMIN user at any time, completely bypassing the intended restriction that only the first user can self-register.

Impact: Unauthenticated attacker gains SUPER_ADMIN access to any LaraAdmin instance.

---

2. Password Change Missing Authorization

File: app/Http/Controllers/LA/EmployeesController.php:521-551

The endpoint POST /admin/change_password/{id} performs zero authorization checks. Any user with access to the admin panel can change any employee's password by supplying an arbitrary {id}, including the SUPER_ADMIN account.

Impact: Any low-privilege admin panel user can take over the SUPER_ADMIN account.

---

3. SQL Injection in save_permissions

File: app/Http/Controllers/LA/PermissionsController.php:440

The $id parameter from the URL is directly interpolated into a raw SQL DELETE statement:

DB::delete('delete from permission_role where permission_id = "'.$id.'"...');

No parameterized query or input sanitization is applied.

Impact: Authenticated attacker can execute arbitrary SQL, leading to data exfiltration, modification, or deletion.

---

4. Unrestricted File Upload

File: app/Http/Controllers/LA/UploadsController.php:134-214

File type validation is entirely commented out in the upload handler. Any file type, including .php files, can be uploaded. If the upload directory is web-accessible, this leads directly to remote code execution.

Impact: Authenticated attacker can upload a PHP webshell and achieve remote code execution on the server.

---

HIGH Severity

5. Systemic Mass Assignment

All 11 models plus the generated model stub use $guarded = [] (empty guarded array). Combined with CRUD operations that pass request data directly, this allows attackers to set any database column including role fields, permissions, and internal flags.

Impact: Attackers can modify protected fields on any model through crafted requests.

---

6. RBAC Bypass via dtajax

All dtajax methods across all controllers skip the LAModule::hasAccess() authorization check. Any admin panel user can fetch data for ANY module via the DataTables AJAX endpoint, regardless of their RBAC role permissions.

Impact: Complete bypass of the role-based access control system for read operations.

---

7. checklist_update RBAC Bypass

The checklist_update method performs no hasAccess() check. Any admin panel user can modify checklist (boolean/toggle) data in any module's database table, regardless of their assigned permissions.

Impact: Unauthorized data modification across all modules.

---

8. Insecure Code Generation

The controller stub and model stub used by the code generator produce code with the same vulnerabilities documented above — no dtajax authorization checks and $guarded = []. Every auto-generated module inherits these security flaws.

Impact: The vulnerability propagation mechanism ensures all generated modules are insecure by default.

---

9. World-Writable Files

The CodeGenerator sets chmod 0777 on all generated files, making them world-readable and world-writable on the server filesystem.

Impact: Any local user or compromised process can read or modify application code.

---

MEDIUM Severity

10. Plaintext Password Logging

When the mail system is not configured, passwords are logged in plaintext. These logs may be accessible to unauthorized parties or persisted in log aggregation systems.

Impact: Credential exposure through log files.

---

Recommended Fixes

1. Registration: Enforce the User::count() == 0 check server-side in the controller, not just the view. Remove or ignore the context_type field from user input.
2. Password Change: Add authorization — verify the authenticated user is either the target user or has explicit permission to manage employees.
3. SQL Injection: Use parameterized queries: DB::delete('delete from permission_role where permission_id = ?', [$id]).
4. File Upload: Implement server-side file type validation with an allowlist of permitted extensions and MIME types.
5. Mass Assignment: Define explicit $fillable arrays on all models instead of using $guarded = [].
6. RBAC in dtajax: Add LAModule::hasAccess() checks to all dtajax methods, consistent with other controller methods.
7. checklist_update: Add the same hasAccess() authorization check.
8. Code Generation: Update stubs to include proper authorization and mass assignment protection.
9. File Permissions: Use 0644 for files and 0755 for directories instead of 0777.
10. Password Logging: Never log plaintext passwords. Log only that a password event occurred.

---

This report was produced during an authorized security audit. All findings were identified through source code review. No exploit code is included. The goal is to help improve the security of the project.