Zugriffsluecken und SQL-Injection in intern/ und admin/ beheben
Ergebnis der Durchsicht beider Bereiche (47 Dateien). Patientendaten ohne Anmeldung abrufbar -------------------------------------- admin/mailtemplate.php hatte keine Zugriffspruefung. Der Endpunkt liefert gerenderte Mailvorlagen und damit Vorname, Nachname, Geburtstag, Adresse, Medikamente, Anfragetext und den Anfragen-Link mit dem hash. Ein anonymer POST wurde bis in die Datenbank verarbeitet (geprueft mit ungueltiger templetid, es sind keine Daten geflossen). Jetzt check_admin_user() mit HTTP 401. Ausserdem ging die Exception-Meldung an den Aufrufer zurueck - sie geht jetzt ins Log. intern/meineanfragen.php filterte beim Detailaufruf ausschliesslich auf die anfrageid aus $_POST, ohne Bezug zum angemeldeten Benutzer - und setzte sie unmaskiert ins SQL. Jeder registrierte Patient konnte damit fremde Anfragen samt Geburtstag, Adresse und Telefonnummer lesen. Jetzt Prepared Statement und zusaetzlich an die E-Mail des angemeldeten Benutzers gebunden, wie in der Listenansicht derselben Datei. SQL-Injection ------------- admin/togoadmin.php: 14 Abfragen bauten $_GET/$_POST direkt in das SQL. Ganzzahlige Spalten bekommen einen (int)-Cast, damit die umgebenden mysqli-Schleifen unveraendert bleiben; alle INSERT- und UPDATE-Anweisungen mit Textwerten sind auf Prepared Statements umgestellt. create_time dort jetzt per NOW() statt PHP-date(). Ein abschliessender Scan ueber intern/, admin/ und zeiterfassung/ findet keine verkettete Nutzereingabe in SQL mehr. Zugriffspruefung ohne Wirkung ----------------------------- admin/anrufbeantworter.php und admin/kalender.php riefen check_admin_user() auf, werteten den Rueckgabewert aber nie aus. Die Funktion liefert bei fehlender Anmeldung nur null, sie bricht nicht ab - beide Seiten rendered fuer anonyme Besucher weiter. Daten flossen nicht ab, aber die Oberflaeche war sichtbar. Jetzt gleiches Muster wie admin/index.php. Tokens ohne Ablauf ------------------ Die Tabelle securitytokens hatte keine Ablaufspalte: ein erbeutetes Admin-Cookie galt unbegrenzt. Der Patientenbereich setzt 30 Tage. securitytokensHatAblaufspalte() prueft die Spalte zur Laufzeit, damit der Code vor und nach der Migration laeuft; admin/login.php setzt den Ablauf beim Anlegen, check_admin_user() beruecksichtigt ihn beim Lesen. Migration in admin/sql/. Die Cookie-Laufzeit war auf 365 Tage gesetzt und ist jetzt deckungsgleich mit dem Token. Entfernt -------- admin/phpinfo.php lieferte ohne Anmeldung 102 KB Serverkonfiguration. intern/admin.php, admin/admin.php sowie mailtemplatebody.php und mailtemplatebetreff.php in beiden Verzeichnissen waren tot (falscher relativer require-Pfad, HTTP 500) - die mailtemplate-Vorgaenger enthielten zudem rohe SQL-Injection mit Patientendaten. Keine der sechs Dateien wird irgendwo aufgerufen. admin/sql war als leere Datei statt als Verzeichnis angelegt. Kleinere Korrekturen -------------------- intern/authentifizierung.php und admin/passwortzuruecksetzen.php verglichen das Ergebnis von fetch() mit null statt false und pruefen den Ablauf des Codes jetzt in SQL statt mit strtotime()/time() - dieselbe Zeitzonenfalle wie bei den 2FA-Codes, hier in die harmlose Richtung. Ein toter password_hash()-Aufruf auf einer nie gesetzten Variablen ist entfallen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -54,10 +54,25 @@ include("templates/header.inc.php");
|
||||
if(check_mailreg() && check_userdatenvorhanden() ){
|
||||
if($_POST["aktion"] == "11"){
|
||||
|
||||
$sqlstring = "SELECT * FROM anfragen INNER JOIN persons ON anfragen.requester_person_id = persons.person_id INNER JOIN anfrageart ON anfragen.anforderungart = anfrageart.artid WHERE anfrageid='" . $_POST["anfrageid"] . "'";
|
||||
$query = mysqli_query($con,$sqlstring);
|
||||
// Zwei Fehler auf einmal: die anfrageid kam ungeprueft aus $_POST in das
|
||||
// SQL, und gefiltert wurde ausschliesslich danach - jeder angemeldete
|
||||
// Patient konnte so fremde Anfragen mitsamt Name, Geburtstag, Adresse
|
||||
// und Telefonnummer abrufen. Jetzt Prepared Statement und zusaetzlich
|
||||
// an die E-Mail des angemeldeten Benutzers gebunden, wie in der
|
||||
// Listenansicht weiter unten.
|
||||
$statementAnfrage = $pdo->prepare("
|
||||
SELECT * FROM anfragen
|
||||
INNER JOIN persons ON anfragen.requester_person_id = persons.person_id
|
||||
INNER JOIN anfrageart ON anfragen.anforderungart = anfrageart.artid
|
||||
WHERE anfragen.anfrageid = :anfrageid
|
||||
AND persons.email = :email
|
||||
");
|
||||
$statementAnfrage->execute([
|
||||
'anfrageid' => (int)($_POST["anfrageid"] ?? 0),
|
||||
'email' => $user["email"]
|
||||
]);
|
||||
// Ticket und Antwort ansehen.
|
||||
while ($row = $query->fetch_assoc()) {
|
||||
while ($row = $statementAnfrage->fetch(PDO::FETCH_ASSOC)) {
|
||||
|
||||
|
||||
$anfrageid = $row["anfrageid"];
|
||||
|
||||
Reference in New Issue
Block a user