Re: [TYPO3-german] Extbase - Manipulation von Daten

[Michael Kasten]

Hallo Stephan,


Am 20.01.2017 um 19:10 schrieb Stephan Schuler:
> Ich bin mir fast sicher, dass in der konkreten Implementierung nicht zwischen 
> 1, 2, 3 und 6 unterschieden wird sondern der Zugriff auf ein Objekt mit 
> irgendeiner Aufgabe. Hier kann ich mir durchaus vorstellen, dass es 
> Situationen gibt in denen der Benutzer einfach nicht den kompletten 
> Wertebereich lesen können soll.
Wenn ich solch eine Unterscheidung anhand von durch den User eingegebenen 
Parametern treffe sind
diese immer möglicher Manipulation unterworfen.

> Was mach ich in einem Onlineshop wenn der Kunde den POST-Request der einen 
> Artikel in den Warenkorb legt manipuliert? Möglicherweise hab ich Produkte 
> deren Kaufberechtigung an Regeln gebunden sind, Altersbeschränkung bei 
> Alkohol zum Beispiel oder Gebindegrößen nur für Geschäftskunden.
Dann ist dieser Onlineshop oder dessen Berechtigungslogik schlichtweg kaputt, 
egal ob Onlineshop
oder Informationen generell, sind diese nicht öffentlich muss die Prüfung auf 
Zugriff anhand von
User-, Gruppenberechtigungen getroffen werden.

> Wenn es dann in den Checkout geht und der Kunde einen Warenkorb bestellen 
> möchte kann ich Payment-Types für Paypal, Nachnahme und Vorkassenzahlung 
> haben, und für Kunden die bereits eine erfolgreiche bezahlte Bestellung über 
> mindestens 25€ abgeschlossen haben erlaube ich auch den Payment-Type der 
> Zahlung per Rechnung.
Üblicherweise gibt es in Onlineshops entsprechende Kundengruppen, wenn ich 
nicht der Gruppe angehöre
aber durch Manipulation von Parametern die Gruppenberechtigung ändern kann ist 
dieses
Berechtigungssystem Kaputt.

> Nicht mal wenn es sich nur um GET-Requests handelt und RealURL samt cHash 
> sicherstellen, dass der Benutzer den ID-Parameter verändert bin ich sicher. 
> Ich kann mir News vorstellen die in Gruppen sortiert sind und News bestimmter 
> Gruppen sind nur für angemeldete Benutzer bestimmter Gruppen gedacht. Was 
> hindert einen angemeldeten Benutzer daran, einen gültigen Link auf eine 
> News-Seite an eine fremde Person weiterzuleiten?
Du schreibst ja selber "News bestimmter Gruppen nur für angemeldete Besucher" 
wenn jemand also einen
Link auf so eine (interne) News weiterleitet, wird bei korrekter 
Implementierung, derjenige der
diesen Link aufruft nichts zu sehen bekommen, da diese ja nicht eingeloggt ist, 
wenn sich jemand
einen Login verschafft, und sich anschließend durch Manipulation der Url sich 
News anzeigen lassen
kann die nicht für Ihn bestimmt ist, ist die Gruppenberechtigung kaputt. (Da 
man in diesem Fall
hoffentlich nicht nur nach eingeloggt und nicht eingeloggt unterscheidet)

> Grundsätzlich ist „der Benutzer kann den Link oder die ID nicht kennen“ keine 
> sinnvolles Berechtigungskonzept.
Das hat imho niemand behauptet, und kennen muss man überhaupt nichts, dafür 
gibt es genug Bots :)
Die Berechtigung anhand von Eingaben zu unterscheiden ist und bleibt ein 
architektonischer Fehler.

my2cent

-- 
Michael Kasten | http://m-kasten.de
Im wirklichen Leben gibt es kein [Strg]+[Z]
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Extbase - Manipulation von Daten

[Stephan Schuler]

Ich bin mir fast sicher, dass in der konkreten Implementierung nicht zwischen 
1, 2, 3 und 6 unterschieden wird sondern der Zugriff auf ein Objekt mit 
irgendeiner Aufgabe. Hier kann ich mir durchaus vorstellen, dass es Situationen 
gibt in denen der Benutzer einfach nicht den kompletten Wertebereich lesen 
können soll.

Was mach ich in einem Onlineshop wenn der Kunde den POST-Request der einen 
Artikel in den Warenkorb legt manipuliert? Möglicherweise hab ich Produkte 
deren Kaufberechtigung an Regeln gebunden sind, Altersbeschränkung bei Alkohol 
zum Beispiel oder Gebindegrößen nur für Geschäftskunden.
Wenn es dann in den Checkout geht und der Kunde einen Warenkorb bestellen 
möchte kann ich Payment-Types für Paypal, Nachnahme und Vorkassenzahlung haben, 
und für Kunden die bereits eine erfolgreiche bezahlte Bestellung über 
mindestens 25€ abgeschlossen haben erlaube ich auch den Payment-Type der 
Zahlung per Rechnung.

Nicht mal wenn es sich nur um GET-Requests handelt und RealURL samt cHash 
sicherstellen, dass der Benutzer den ID-Parameter verändert bin ich sicher. Ich 
kann mir News vorstellen die in Gruppen sortiert sind und News bestimmter 
Gruppen sind nur für angemeldete Benutzer bestimmter Gruppen gedacht. Was 
hindert einen angemeldeten Benutzer daran, einen gültigen Link auf eine 
News-Seite an eine fremde Person weiterzuleiten?

Grundsätzlich ist „der Benutzer kann den Link oder die ID nicht kennen“ keine 
sinnvolles Berechtigungskonzept.

Einen Validator davor zu schalten dürfte die einfachste Lösung sein, auch wenn 
ich streng genommen die Zugriffskontrolle nicht als Aufgabe der Validierung 
betrachte.

Gruß,

Am 20.01.17, 17:12 schrieb "typo3-german-boun...@lists.typo3.org im Auftrag von 
Michael Kasten" :

Never trust users
oder
User content is evil

Grundsätzlich sind alle Usereingaben als schädliche Eingaben anzusehen.
Es sollte also nur das gespeichert werden was nicht schädlich und das nicht 
nur an einer Stelle
sondern an möglichst allen Stellen bei der Strecke zur und von der 
Datenbank.

> Ein bestimmter User bekommt beim Bearbeiten eines Datensatzes in einem 
Dropdown 3 Werte zur Auswahl
> (uid 1, 2 und 3) - Mehr sieht er nicht. Er ändert vor dem Absenden den 
Value einer Option von z.B.
> value="3" auf value="6" und schickt das Formular ab.

Dieser Fall ist aus meiner Sicht wenig realistisch, was soll der User denn 
damit bezwecken können,
soweit wie das beschrieben ist ändert sich hier nur eine Zahl, das ist für 
das System uninteressant.
(Es sei den der User wählt hier sowas wie eine Berechtigung oder eine 
Gruppenzugehörigkeit, dann
aber hast du schon den ersten großen Fehler in deiner Architektur)

Interessanter wird es doch wenn dein User den Value auf irgendwas anderes 
als eine Zahl ändern kann
(Gefahr für deine DB) und das dann an anderer Stelle wieder ausgegeben wird 
(Gefahr für alle anderen)

Alle Eingaben müssen vor der Persistierung validiert werden, also immer auf 
Datentyp, ggf auch
Datenlänge und Formate. Dann sind ggf. alle bekannten schädlichen 
Steuerzeichen zu entfernen oder zu
maskieren (unterbinden von DB Anweisungen, Unterbinden von Inhalten die 
beim ausspielen XSS
erzeugen) Hierbei kann man auch serverseitig z.B. bei Verwendung von Apache 
noch eine FW Hochziehen
(mod_Security) dann findet die Prüfung nicht nur auf Anwendungsebene statt.

> Eigentlich wäre doch die einfachste Lösung bei der Update-Action nochmal 
zu prüfen ob sich der vom
> User gesetzte Wert in der Liste der "erlaubten" Werte ist, oder?

Die Valdierung findet vor dem Aufruf der jeweiligen Action insert oder 
update statt


https://docs.typo3.org/typo3cms/ExtbaseFluidBook/9-CrosscuttingConcerns/2-validating-domain-objects.html

So Freitag also my2cent

--
Michael Kasten | http://m-kasten.de
Im wirklichen Leben gibt es kein [Strg]+[Z]

Stephan Schuler
Web-Entwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: stephan.schu...@netlogix.de
Web: websolutions.netlogix.de




Neu: Wir sind Amazon Web Services Partner. Mehr erfahren:
https://websolutions.netlogix.de/technologie/amazon-web-services-aws





netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: i...@netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt



___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Extbase - Manipulation von Daten

[Michael Kasten]

Never trust users
oder
User content is evil

Grundsätzlich sind alle Usereingaben als schädliche Eingaben anzusehen.
Es sollte also nur das gespeichert werden was nicht schädlich und das nicht nur 
an einer Stelle
sondern an möglichst allen Stellen bei der Strecke zur und von der Datenbank.

> Ein bestimmter User bekommt beim Bearbeiten eines Datensatzes in einem 
> Dropdown 3 Werte zur Auswahl
> (uid 1, 2 und 3) - Mehr sieht er nicht. Er ändert vor dem Absenden den Value 
> einer Option von z.B.
> value="3" auf value="6" und schickt das Formular ab.

Dieser Fall ist aus meiner Sicht wenig realistisch, was soll der User denn 
damit bezwecken können,
soweit wie das beschrieben ist ändert sich hier nur eine Zahl, das ist für das 
System uninteressant.
(Es sei den der User wählt hier sowas wie eine Berechtigung oder eine 
Gruppenzugehörigkeit, dann
aber hast du schon den ersten großen Fehler in deiner Architektur)

Interessanter wird es doch wenn dein User den Value auf irgendwas anderes als 
eine Zahl ändern kann
(Gefahr für deine DB) und das dann an anderer Stelle wieder ausgegeben wird 
(Gefahr für alle anderen)

Alle Eingaben müssen vor der Persistierung validiert werden, also immer auf 
Datentyp, ggf auch
Datenlänge und Formate. Dann sind ggf. alle bekannten schädlichen Steuerzeichen 
zu entfernen oder zu
maskieren (unterbinden von DB Anweisungen, Unterbinden von Inhalten die beim 
ausspielen XSS
erzeugen) Hierbei kann man auch serverseitig z.B. bei Verwendung von Apache 
noch eine FW Hochziehen
(mod_Security) dann findet die Prüfung nicht nur auf Anwendungsebene statt.

> Eigentlich wäre doch die einfachste Lösung bei der Update-Action nochmal zu 
> prüfen ob sich der vom
> User gesetzte Wert in der Liste der "erlaubten" Werte ist, oder?

Die Valdierung findet vor dem Aufruf der jeweiligen Action insert oder update 
statt

https://docs.typo3.org/typo3cms/ExtbaseFluidBook/9-CrosscuttingConcerns/2-validating-domain-objects.html

So Freitag also my2cent

-- 
Michael Kasten | http://m-kasten.de
Im wirklichen Leben gibt es kein [Strg]+[Z]
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Extbase - Manipulation von Daten

[Mario T]

Hallo zusammen!

Wie verhindert ihr eine Manipulation von Daten? Beispiel:

Ein bestimmter User bekommt beim Bearbeiten eines Datensatzes in einem Dropdown 3 Werte zur Auswahl 
(uid 1, 2 und 3) - Mehr sieht er nicht. Er ändert vor dem Absenden den Value einer Option von z.B. 
value="3" auf value="6" und schickt das Formular ab.

Das ganze wird von TYPO3 einfach übernommen da ja zufällig der Datensatz mit 
der uid 6 existiert.

wie verhindert ihr so eine Manipulation?

Eigentlich wäre doch die einfachste Lösung bei der Update-Action nochmal zu prüfen ob 
sich der vom User gesetzte Wert in der Liste der "erlaubten" Werte ist, oder?

Danke für Eure Meinung.
--
LG,
 Mario
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german