Author Topic: Sicherheitsverletzung kein Zugriff  (Read 819 times)

Offline gottfried

  • Posts: 1339
Sicherheitsverletzung kein Zugriff
« on: January 08, 2017, 10:50:36 AM »
Hallo!
Ich bekomme auf einem wb 2.8.3 mit sp7 diesen Fehler "Sicherheitsverletzu ng - kein Zugriff" in rosa.

(mpform 1.3.1 bei hinzufügen Feld)
 
Kenn ich ja eigentlich, da konnte man doch im Adminbereich was umstellen, das finde ich aber nicht mehr ?


Offline jacobi22

  • Posts: 5836
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitsverletzung kein Zugriff
« Reply #1 on: January 08, 2017, 11:30:09 AM »
Ich vermute mal, das dem Script hier die Prüfmethode FTAN fehlt- jede Action, die über die Core-Dateien läuft, wird mit einer einmaligen ID abgesichert.
Wundert mich aber, das da jetzt erst jemand drüber stolpert, das ist schon seit SP6 so

Quote
da konnte man doch im Adminbereich was umstellen, das finde ich aber nicht mehr ?
ja, die alte Methode, die viel Trouble gemacht hat, ist verschwunden, übrigens auch schon im SP6 ;-)
mit der aktuellen SecureToken kann man davon ausgehen, das eine angezeigte Sicherheitsverletzu ng auch eine ist, rein technisch gesehen.

Habe mir das Script mal angeschaut - diesen Weg (wo er dann die FTAN benötigt) - soll er nur gehen, wenn ein Fehler beim Anlegen des neuen Feldes aufgetreten ist.
Tritt kein Fehler auf, wird aus der field_id des angelegten Feldes eine solche FTAN generiert.

Vielleicht könntest du mal kontrollieren, ob ein solch neues Feld in der Datenbank angelegt wurde. Das hilft, in etwa den Ausstiegspunkt des Scriptes zu definieren. Andere Fehlermeldungen treten nicht noch auf in Zusammenhang mit dem Anlegen von Feldern?

Ich werd mal eine Installation upgraden und am live-Objekt testen
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline gottfried

  • Posts: 1339
Re: Sicherheitsverletzung kein Zugriff
« Reply #2 on: January 09, 2017, 09:44:20 AM »
Hallo Jacobi!

Es ist kein Datensatz für ein neues Feld angelegt worden.

Ich rücke nun mit der ganzen Wahrheit raus. Ich hatte  einen PC mit Xampp ausgerüstet zwecks experimentieren. Ich konnte über FTP den aktuellen 2.8.3 nicht über FTP installieren (ging schief) sondern habe eine ältere Version eines 2.8.4 draufgespielt. In der Konstellation kamen öfter Sicherheitsverletzu ngen, aber eher beim Versuch eine Seite aus dem Backend aufzurufen. Da drauf habe ich nun ein aufwändiges Formular mit mpform 1.3.1 über paar Tage mit ca 100 Feldern gebastelt. (parallel zu Martin Hecht hab ich etwas anders html vor und nach dem Feld eingebaut, damit es nicht noch unübersichtlicher wird).
Das hat dann ganz gut funktioniert. (Natürlich auch Felder zufügen).

Das wollte ich dann bei Strato hosten. Dazu habe ich aber dort ein neues 2.8.3 SP7 installiert und nach Installation von mpform des leicht modifizierten mpform 1.3.1 die wb_mpform_fields Tabelle nach ändern des Tabellenvorspannes und der Sectionid's in der sql-Datei importiert.

Dann habe ich ein paar Tage ohne Problem weitergearbeitet allerdings ohne ein Feld anzulegen.
Ändern geht.


Mir ist nicht ganz plausibel, wo in dem Zusammenhang eine FTAN eine Rolle spielen könnte,
aber FTAN ist mir eh ein Rätsel. 

Das 2.8.4 war u.U FTAN mäßig anders gestrickt?   :|

Offline jacobi22

  • Posts: 5836
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitsverletzung kein Zugriff
« Reply #3 on: January 09, 2017, 12:37:33 PM »
Quote
Das 2.8.4 war u.U FTAN mäßig anders gestrickt?

das Grundprinzip ist das Gleiche, aber seither hat sich einiges geändert. Du mußt auch sehen, das die FTAN-Lösung der 2.8.4 eher ein Vorgänger der jetzigen Lösung ab SP6 war, die seit der Umstellung eigentlich auch problemlos läuft.

Quote
Mir ist nicht ganz plausibel, wo in dem Zusammenhang eine FTAN eine Rolle spielen könnte,
aber FTAN ist mir eh ein Rätsel. 

ich versuch es nochmal...  ;-)
so fast jede Seite im Backend ist ein Formular, ein paar kleine Ausnahmen wie z.b. ne Modulhilfe, die man per Mausklick wieder schließt, gibt es
Jedes dieser Formulare sendet einen Code mit, z.b. die modify.php and die save.php. Dieser Code wird beim Empfang kontrolliert. Durch verschiedene Methoden zur Erstellung dieses Codes ist sichergestellt, das nur das Browserfenster den Inhalt der save.php verarbeiten kann, das es selbst über die modify.php abgeschickt hat. Es kann also auch keiner von außen einfach mal Daten zum speichern senden, weil der dann diesen Code nicht hätte.

back to mpform - Hinzufügen eines Feldes - die Theorie
du klickst den Button "Feld hinzufügen", dieser sendet den Befehl zur add_fields.php
Diese Datei erstellt das Feld für die Datenbank in Tabelle fields, macht einen Eintrag für die Results, wo die Inhalte des Feldes später gespeichert werden,

Sind diese Vorgänge erfolgreich, wird diese FTAN aus der Field-ID des neu angelegten Feldes erstellt. In dem Fall heißt es IDKEY, weil es sich auf eine bestimmte ID bezieht.
Mit dieser IDKey geht es dann zurück zur modify_fields.php, wo du jetzt Namen des Feldes usw eintragen kannst

Die Frage wäre jetzt, wo in diesem Vorgang steigt dein Script aus. Nach dem Anlegen der Felder in der DB, nach der ersten Weiterleitung zur modify_fields oder erst hinterher beim Speichern?
Gibt es einen Abbruch beim Anlegen der Felder, soll die Seite mit Fehlermeldung zurückschalten auf die modify-Seite vom mpform, also die Übersicht. In dem Fall hättest du theoretisch eine Fehlermeldung wie
- Could not add field to database oder
- could not add results table oder
- could not add field to results table

Es empfiehlt sich, für die Fehlersuche die automatische Weiterschaltung von WB zu deaktivieren. Z.B würden bei einem Abbruch in der add_fields.php zwei Meldungen erscheinen, man sieht aber nur eine
Zum Abschalten in die WB-Optionen -> erweiterte Optionen und dort bei "Weiterleitung nach..." den Wert auf minus 1 setzen (-1)



Das erfordert dann bei jeder weiterschaltung eine Bestätigung auf dem jeweiligen OK-Feld und nervt auch etwas, hilft aber, solche Probleme zu lokalisieren.

Zur besseren Lokalisation des Problems würde ich jetzt die Fehlerausgaben für diese Sicherheitsverletzu ngen so anpassen, das man genau weiß, an welcher Stelle sie auftritt, dazu müßte man die Fehlermeldungen in der modify_fields.php ändern

Zeile 44 der aktuellen Version 1.3.3 / Datei modify_fields.php
Code: [Select]
$admin->print_error($MESSAGE['GENERIC_SECURITY_ACCESS']ändern auf
Code: [Select]
$admin->print_error('IDKEY_'.$MESSAGE['GENERIC_SECURITY_ACCESS']
Zeile 52 der gleichen Datei
Code: [Select]
$admin->print_error($MESSAGE['GENERIC_SECURITY_ACCESS'],$sUrlToGo);ändern auf
Code: [Select]
$admin->print_error('FIELD_ID '.$MESSAGE['GENERIC_SECURITY_ACCESS'],$sUrlToGo);
ggf sind die Zeilennummern unterschiedlich
Theoretisch sollte deine Warnung dann mit einer WB 2.8.3 SP7 so aussehen
Quote
IDKEY Sicherheitswarnung. ...
wenn der Abbruch bei der Weiterleitung von der add_fields.php zur modify_fields.php erfolgt

Nächster Vorgang wäre das Speichern der Daten zum neuen Feld - hier sehe ich ein Problem-Potential, weil FTAN und IDKEY zusammen übergeben werden. Ich habe mich in meinen Modulen darauf beschränkt, nur eine Methode zu übergeben - beide sind gleich sicher.
Braucht man, wie hier, die Field_ID - würde ich die FTAN weglassen

Der Vorgang zum Prüfen ist der gleiche wie oben

Datei save_field.php
Zeile 54 // FTAN
Code: [Select]
$admin->print_error($MESSAGE['GENERIC_SECURITY_ACCESS']ändern in
Code: [Select]
$admin->print_error('SAVE-FTAN '.$MESSAGE['GENERIC_SECURITY_ACCESS']
Das müßtest du bitte mal durchführen, es wäre auch kein Problem, diese Änderungen im Code zu belassen, im Core wird auch schrittweise dazu übergegangen, diese Medldungen genauer zu spezifizieren, damit man weiß, wo genau sie auftreten.

Zur FTAN allgemein nochmal: die Systeme in 2.8.4 und 2.8.3 kann man praktisch nicht vergleichen. Nur das Grundprinzip ist das gleiche geblieben. Während in den alten Versionen 2.8.3 vor SP6 und 2.8.4 jede TAN beim nächstem Vorgang verfiel, können mit der neuen Klasse unendlich viele dieser FTANs oder IDKEYs gleichzeitig benutzt werden, was die Benutzung des früheren SecureFormSwitchers (SingleTab vs MultiTab) überflüssig macht. Das ist gerade für Installationen wichtig, wo ein oder mehrere Redakteure gleichzeitig im Backend arbeiten.
Weil das aber eine gravierende Änderung ist, kann man das Verhalten der 2.8.4 im Bezug auf FTAN auch nicht mehr vergleichen, es ist immerhin auch schon wieder 5 Jahre alt




« Last Edit: January 09, 2017, 12:45:45 PM by jacobi22 »
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline gottfried

  • Posts: 1339
Re: Sicherheitsverletzung kein Zugriff
« Reply #4 on: January 09, 2017, 04:33:14 PM »
Hallo Jacobi!

Also - nach
Quote
ändern auf
Code: [Select]

$admin->print_error('IDKEY_'.$MESSAGE['GENERIC_SECURITY_AC CESS']

kommt die von dir da erwartete Meldung IDKEY_Sicherheitsve rletzung .....
also aus Zeile 44 von modify_field.php

 :-)

(was mich nur wundert ist, daß die add_field.php anscheinend kein neues Feld "inserted" hat)

Offline jacobi22

  • Posts: 5836
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitsverletzung kein Zugriff
« Reply #5 on: January 09, 2017, 05:58:09 PM »
was mich mehr wundert, ist, das sie keinen Fehler dafür ausgibt
ich habe aber die Version 1.3.1 nicht, soll da so ein unterschied sein?

Ich meine, diese Zeile hier sollte anders lauten, statt

Code: [Select]
$field_id = $admin->checkIDKEY('field_id', false, 'GET');
Code: [Select]
$field_id = $admin->checkIDKEY($iFID, false, 'GET');
ist aber Version 1.3.3 und erklärt auch nicht, wo die Felder geblieben sind und funktioniert ja bei mir

Vielleicht sollten wir Martin dazu holen
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline gottfried

  • Posts: 1339
Re: Sicherheitsverletzung kein Zugriff
« Reply #6 on: January 09, 2017, 09:16:25 PM »
Schön guten Abend!

Ich glaub, Martin ist in Urlaub.

Ich meine nicht, daß da viel verändert ist.

Wenn es bei dir (2.8.3v7 mit mpforms1.3.?)  geht, könnte es was doofes wie PHP version sein.

Oder ich habe übersehen eine Tabelle mit zu importieren oder so ..

Ich nehm den Abschnitt einfach mal raus und schau was passiert. Falls nichts, war's das nicht.

Die Idee mit "FTAN" ist echt gut. Ich bin mal auf einer joomla site von islamischen Terroristen gehackt worden. Haben die ein ähnliches Konzept?

Ich kann auch mit phpmyadmin oder import ein passendes feld einfügen, einstweilen um weiterzubasteln.

Mir ist nicht eilig. Ich will trotzdem voreilig <styles> in den <head> einer email aus mpform bekommen, eher der Präsentation, als des Inhalts wegen.


 :-)



Offline gottfried

  • Posts: 1339
Re: Sicherheitsverletzung kein Zugriff
« Reply #7 on: January 10, 2017, 10:52:14 AM »
Hallo Jacobi!

Neugierig bin ich schon.

Seltsam ist, daß kurz eine Meldung aufflackert - "new record was added succesfully", bevor die Sicherheitsverletzu ng kommt.

der $sTokenName ist 16 stellig hex und existiert in $this->aTokens, hat aber einen [value] 0.

Was bedeutet dieser Wert, wo kommt er her? Der muß ja kurz vorher geschrieben worden sein.

Wie kann der 0 sein?

Offline jacobi22

  • Posts: 5836
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitsverletzung kein Zugriff
« Reply #8 on: January 10, 2017, 11:09:23 AM »
diese Meldung für von Ajax generiert an der Stelle, wo die drei Einträge gemacht sind und er mit der field_id dann zur Umschaltung nach modify_fields.php geht

das wäre hier

Code: [Select]
$iFID = $field_id;
if(method_exists($admin, 'getIDKEY')){
    $iFID = $admin->getIDKEY($iFID);
}

// Say that a new record has been added, then redirect to modify page
$sUrlToGo =  WB_URL
    . '/modules/mpform/modify_field.php'
    . '?page_id='.(int)$page_id.'&section_id='
    . (int)$section_id.'&field_id='.$iFID.'&success=add';

der erste Teil liest die benutzte field-id draus und macht damit eine IDKEY
der Zweite Teil ist die Definition der Rückleitungsadresse . Durch den Zusatz success=add wird dann der Ajax-Vorgang angeschupst und die Meldung erscheint oben im Fenster für 1,5 sec (definiert in backend_body.js ganz oben) oder dem Wert aus den erweiterten WB-Optionen

diese field_id holt er sich aus dem Insert oben in der add_fields.php

Code: [Select]
"INSERT INTO `".TP_MPFORM."fields`"
mit dieser Zeile
Code: [Select]
$field_id = $database->get_one("SELECT LAST_INSERT_ID()");
ich würde mir danach mal ein echo reinsetzen, etwa so
echo "Neue Field-ID ".$field_id;

Wenn du ganz unten die Zeile mit $admin... und die mit header... auskommentierst, schaltet er danach nicht um und man kann direkt in der add_fields.php das oder die echos lesen
etwa so
Quote
if(headers_sent())
      #$admin->print_success($TEXT['SUCCESS'],$sUrlToGo);
    else
      #header("Location: ". $sUrlToGo);
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline jacobi22

  • Posts: 5836
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitsverletzung kein Zugriff
« Reply #9 on: January 10, 2017, 11:16:07 AM »
achso.... wenn die field_id nicht vorhanden ist, weil der Eintrag schief geht, ist die IDKEY dazu natürlich Null (0), weil er ja nichts zum verschlüsseln hat
Und die Null ist dann bei der späteren Prüfung ein ungültiger Wert und Auslöser der Sicherheitsverletzu ng

Frage oben wegen Joomla: zu meiner Joomla-Zeit gab es das noch nicht. Weiß nicht, welches System die aktuell verwenden.
Die meisten Angriffe kommen bei allen CMS aber immer durch offene Zugänge (Passwort zu einfach, Passwort ver- oder erraten, Passwort mit Script getestet, da gibt es Scripte für, die lassen im Web verfügbare Passwort-Listen durchlaufen bis ein Treffer kommt)
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline gottfried

  • Posts: 1339
Re: Sicherheitsverletzung kein Zugriff
« Reply #10 on: January 10, 2017, 11:40:04 AM »
Hallo Jacobi!

So richtig verstehe ich das nicht. Der Fehler war einfach der, daß beim Import der Felder in die neue Datenbank irgendwie das Autoincrement der Feld_ID verschwundibust ist.

Frag mich nur, warum keine sql-fehlermeldung gekommen ist im add_field.php

Etzt geht's

Offline jacobi22

  • Posts: 5836
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitsverletzung kein Zugriff
« Reply #11 on: January 10, 2017, 11:50:35 AM »
Quote
So richtig verstehe ich das nicht

einfach erklärt

das Feld field_id ist autoincrement, brauch und darf also nicht im Insert gesetzt werden

der Insert macht das was er soll, kann danach aber keine field_id auslesen, weil das Feld nicht da ist. Man könnt nun streiten, ob man schon in der add_fields.php einen Abbruch erzwingt, wenn diese ID nicht da ist, macht aber die IDKEY-Prüfung auf der Folgeseite dann eh.
Wie oben schon mal gesagt, durch die reine Standard-Meldung "Sicherheitsverletzu ng...." kennt man die Ursache nicht und sucht eine Weile -

Code: [Select]
// Insert new row into database
$database->query(
    "INSERT INTO `".TP_MPFORM."fields`"
    . " SET"
    . " `section_id` = '".$section_id."', "
    . " `page_id` = '".$page_id."', "
    . " `position` = '".$position."', "
    . " `required` = '0', "
    . " `value` = '', "
    . " `extra` = ''"
    );
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline gottfried

  • Posts: 1339
Re: Sicherheitsverletzung kein Zugriff
« Reply #12 on: January 10, 2017, 03:09:46 PM »
Tja .. manchmal sucht man sich narrisch

So richtig verstehe ich nicht, warum kein entsprechender Datensatz in der Tabelle ist.
Dann kann doch der insert nicht geklappt haben.

 

postern-length