46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# Security
|
|
|
|
## Authentication Model
|
|
|
|
TurboRFQ delegates authentication entirely to MariaDB:
|
|
|
|
- Credentials (host, port, user, password) are submitted once at login.
|
|
- The backend tests them by opening a real PDO connection.
|
|
- On success, credentials are stored in a **server-side PHP session**.
|
|
- Every subsequent API request recreates a PDO instance from the session — no credentials are ever cached in the DB layer.
|
|
|
|
**There is no separate application user store.** Access control is fully governed by MariaDB's own permission system.
|
|
|
|
---
|
|
|
|
## What Users Can See and Do
|
|
|
|
Because every query runs under the session user's MariaDB identity:
|
|
|
|
- A user sees only the schemas and tables their MariaDB account has `SELECT` on.
|
|
- INSERT/UPDATE/DELETE operations fail at the DB level if the user lacks the corresponding privilege.
|
|
- No privilege escalation is possible through the application layer.
|
|
|
|
---
|
|
|
|
## Session Handling
|
|
|
|
- Sessions are managed by PHP's default session handler (file-based by default).
|
|
- Credentials are stored in `$_SESSION` and never sent to the browser.
|
|
- Session expiry follows PHP's `session.gc_maxlifetime` setting.
|
|
|
|
---
|
|
|
|
## SQL Injection Prevention
|
|
|
|
- All user-supplied values in SELECT, INSERT, UPDATE, DELETE are passed as **PDO bound parameters** — never interpolated into SQL strings.
|
|
- Table and column names are taken from `information_schema` (not from user input) and used as structural identifiers — they are quoted with backticks where needed.
|
|
|
|
---
|
|
|
|
## Known Limitations
|
|
|
|
- No CSRF protection on state-changing endpoints.
|
|
- No rate limiting on the login endpoint.
|
|
- The PHP built-in server (development mode) has no TLS — do not expose it over a network.
|