Security: SQL injection in extendsql() and API authorization gaps

[lighthousekeeper1212]

Summary

Systemic SQL injection via extendsql() function affects 15+ classes, and multiple API endpoints have inconsistent authorization checks compared to the web UI.

Key Findings (10 total, 1 CRITICAL + 4 HIGH + 5 MEDIUM)

CRITICAL

1. SQL injection in extendsql() (misc.inc.php:234) — direct string interpolation in search queries across Device, Cabinet, Department, PowerPanel, and 11 more classes

HIGH

2. API /powerport DELETE — no authorization check before deleting power ports
3. API /powerport POST — only global WriteAccess check, no device ownership validation
4. API /audit PUT — no authorization, any user creates audit logs for any device
5. Device Transfer API — insufficient per-device ownership validation

MEDIUM

6-10. SensorReadings/PDUStats DELETE missing per-resource ownership, cabinet bulk reassignment gap, missing output sanitization, weak API session handling, no rate limiting

Root Cause

Web UI properly uses $person->canWrite($cab->AssignedTo) but API endpoints only check global WriteAccess flags. extendsql() builds SQL via string concatenation instead of parameterized queries.

Fix

1. Use parameterized queries in extendsql()
2. Add per-device/per-resource ownership checks in API endpoints matching web UI enforcement