intern/ enthaelt dieselben Patientendaten wie der Adminbereich und war
bisher genauso ungeschuetzt. config.inc.php aktiviert den Token-Filter
jetzt fuer beide Verzeichnisse. Eigenen AJAX-Code oder Nicht-HTML-Ausgaben
gibt es dort nicht, die Umstellung betrifft nur Formulare.
intern/login.php rief nach dem Include ein zweites session_start() auf und
setzte danach session.gc_maxlifetime und session.cookie_lifetime per
ini_set(). Beides lief ins Leere, weil die Sitzung zu dem Zeitpunkt schon
laeuft, und erzeugte Warnungen. Die Lebensdauer kommt aus
session_set_cookie_params() in config.inc.php.
13 Dateien begannen mit einem UTF-8-BOM. Die drei Bytes gehen vor dem
Include raus, womit die Header gesendet sind und
session_set_cookie_params() sowie session_start() in config.inc.php
scheitern - genau die Flags, um die es hier geht. Sichtbar wird das nur
ohne output_buffering, aber darauf sollte sich die Sitzungssicherheit
nicht verlassen.
Nachgeprueft mit output_buffering=0 und error_reporting=E_ALL: admin/ und
intern/ melden keine Header- oder Sessionwarnungen mehr, POSTs ohne Token
liefern 403, mit Token laufen sie durch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stored XSS
Die Anfrageuebersicht und das Antwortformular haben Nachricht, Medikamente,
Dateiname und Adressdaten des Patienten roh in HTML-Strings gesetzt.
Gespeichert wird der Text nur mit trim(), ein Patient konnte darueber
Skriptcode in den Browser der Mitarbeiterin einschleusen - mit deren
Sitzung. Die Werte laufen jetzt beim Auslesen durch e(). Der dritte Zweig
(Antwort einsehen) maskierte bereits bei der Ausgabe und bleibt, wie er
ist.
SQL-Injection
togoadmin.php interpolierte $_GET["id"] an drei Stellen ungecastet in
UPDATE-Statements, waehrend die Nachbarzeilen bereits (int) verwenden.
Dazu drei reflektierte Ausgaben desselben Wertes in Formularfelder.
Beides auf (int) umgestellt.
Formularziele
$_SERVER['PHP_SELF'] enthaelt bei Aufrufen wie /admin/anfragen.php/"><script>
auch den angehaengten Pfad und landete an 72 Stellen ungeprueft im HTML.
Ersetzt durch self_action() aus inc/security.inc.php, das den Basisnamen
des Skripts maskiert zurueckgibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Abfrage in aktion=10 stammte noch aus der Zeit der user-Tabelle und
selektierte p.mail, p.jahrgang sowie a.timeid. Keine dieser Spalten
existiert: persons fuehrt email und geburtstag, anfragen hat kein timeid.
Die Abfrage warf damit eine PDOException, und da der Block kein try/catch
hat, brach das Skript vor dem UPDATE ab - "Anforderung loeschen (ohne
Mail)" war komplett wirkungslos.
Spaltennamen korrigiert und die uebrig gebliebene Debug-Ausgabe von
timeid entfernt, die als einzige Stelle den Wert genutzt hat. Ein Scan
aller persons-Aliasse gegen das Schema zeigt keine weiteren Fundstellen.
Der Fehlertext beim fehlgeschlagenen Mailversand in aktion=3 behauptete,
es sei nichts gespeichert worden. Tatsaechlich laeuft das UPDATE vorher.
Die Meldung benennt jetzt den echten Zustand und bittet darum, den
Vorgang erneut auszufuehren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Button "Telefonisch beantwortet" (aktion=20) hat bisher die Mailvorlage
42 an die private Mailadresse des Patienten geschickt. Telefonisch erledigte
Anfragen duerfen die Praxis nie per Mail verlassen, der Versand entfaellt
daher ersatzlos.
Die Bestaetigungstexte benennen jetzt den tatsaechlichen Vorgang statt
faelschlich von einer Loeschung mit schriftlicher Mailbestaetigung zu
sprechen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
clemensandClaude Opus 5