Anwendungssicherheit: Validierung von Eingabedaten - Seite 2

27.12.2011, 13:35

Zitat:

Zitat von dr. ?

Mein Gott, wie ich solche pauschalen Statements liebe...

Danke für die Disteln, Onkel Doktor.

Ich bin schlicht und einfach schreibfaul, aber nicht denkfaul. Allerdings fällt mir auf Anhieb kein vernünftiger Grund ein, Strings wie zB. "viele Grüße" via GET durch die Botanik zu schicken. Sowas würde ich in die Session packen und "drei Seiten später" bei Bedarf wieder rauskramen. Sicher ist das alles wieder viel zu simpel...

nedelin · 27.12.2011, 13:38

Zitat:

Zitat von dr.e.

"vorvalidieren" ist ein bischen wie "halbschwanger" [...]

Da ich ebenfalls davon sprach, möchte ich mich gern dazu äussern. Du beschreibst mit

Zitat:

Zitat von dr.e.

In einer Bootstrap, einem Input-Filter oder einer Front-Controller-Action lassen sich allgemeingültige, Anwendungs-übergreifende Dinge validieren [...]

nichts anderes, auch wenn Du keine "abenteuerlichen" Termini verwendest. Der Op hat (wie ich auch) das Ganze lediglich unter der Bezeichnung "Vorvalidierung" zusammengefasst.

Zitat:

Zitat von dr.e.

Aus Usability-Gesichtspunkten möchte der Benutzer doch keine globale Fehler-Seite angezeigt bekommen, wenn er statt einer "1" eine "5" eingegeben hat.

Soweit ich den Op verstanden habe, steht das auch gar nicht zur Disposition.

Viele Grüße,
dr.

nedelin · 27.12.2011, 13:43

Zitat:

Zitat von meikel

Allerdings fällt mir auf Anhieb kein vernünftiger Grund ein, Strings wie zB. "viele Grüße" via GET durch die Botanik zu schicken.

Das sehe ich ebenso. Und gerade deshalb brauche ich bei Beschränkung auf ascii kein url en- bzw. decoding

dr.

dr.e. · 27.12.2011, 17:49

Wenn "Vorvalidierung" gleich "Anwendungs-übergreifend" und damit nicht die Validierung konkreter Werte darstellt, kann ich mit dem Begriff leben - auch wenn ich ihn nicht besonders treffend finde.

Renner · 28.12.2011, 11:57

Ein Securitycheck sollte an zentraler Stelle richtig positioniert sein. Stichwort: Intrusion Detection.

https://phpids.org/

dr.e. · 28.12.2011, 13:56

Security-Check: ja, konkrete Validierung: nein. Genau das ist meine Aussage.

drsoong · 01.01.2012, 18:27

Ich stelle mir gerade mal den nicht so unüblichen Fall eines Adressformulars vor. Der User tippt bei PLZ statt 81479 irrigerweise München ein, da er in der Zeile verrutscht ist.

Jetzt fragst Du: Soll ich das säubern und mit dem gesäuberten Wert weiterarbeiten oder lieber die Anwendungslogik abbrechen und eine Fehlerseite anzeigen.

Frage: Wie willst Du solche Sachverhalte säubern oder in validen Input transformieren?
Ich denke generell kann das nur schiefgehen, wenn man hier versucht, für jedwede Userdummheit eine säubernde Transformation zu coden.

Was bleibt ist eigentlich nur die Fehlerseite, wobei ich mit Fehlerseite hier das Affenformular meine mit entsprechender Markierung der Fehlerquelle und einem Hinweis für den User.

Säubern würde ich bestenfalls anhand einer Blacklist von malignen Codeelementen, wobei der Blacklistansatz ja auch nicht gerade als "preferable" propagiert wird. Statt säubern könnte man allerdings auch - je nach Anwendungsart - die komplette Session entwerten und den User/Hacker vor die Tür setzen.

advanced_phpler · 15.04.2012, 19:15

du musst so oder so alle daten einzeln anschauen. wenn du sicherheitstechnisch strenge reglen setzt, kannst du auch gleich alles rausparsen. Der anwender wird dann naber keine freude haben gibt er z.b. mal eine Telefonnummer "+536/ 456 455 53 " ein.

du kommst also nicht drum rum alle werte einzeln zu betrachten und sie kurz vor Verwendung zu parsen. es gibt keine Zentrale lösung.. ausser ev. das hochkomma vernichten. (+ individuell noch schauen)

bei nummern ist es eigentlich einfach -> was keine zahl ist fliegt raus.
entweder typecasting oder noch besser preq_prepleace "alles was keine zahl ist" .. somit würde auch eine zahl "12-34!ç5*sf6" korrekt interpretiert.
mach ich z.b. so.. kann ja sein das der benutze sich vertippt.

tr0y · 16.04.2012, 00:43

Zitat:

Zitat von advanced_phpler

du musst so oder so alle daten einzeln anschauen. wenn du sicherheitstechnisch strenge reglen setzt, kannst du auch gleich alles rausparsen. Der anwender wird dann naber keine freude haben gibt er z.b. mal eine Telefonnummer "+536/ 456 455 53 " ein.

du kommst also nicht drum rum alle werte einzeln zu betrachten und sie kurz vor Verwendung zu parsen. es gibt keine Zentrale lösung.. ausser ev. das hochkomma vernichten. (+ individuell noch schauen)

bei nummern ist es eigentlich einfach -> was keine zahl ist fliegt raus.
entweder typecasting oder noch besser preq_prepleace "alles was keine zahl ist" .. somit würde auch eine zahl "12-34!ç5*sf6" korrekt interpretiert.
mach ich z.b. so.. kann ja sein das der benutze sich vertippt.

Ich glaub nach 4 Monaten hat der das Problem im Griff. Und dir empfehl ich mal die Filter-Mechaniken von PHP zu studieren. preg_* ist meist mit Kanonen auf Spatzen ballern.

drsoong · 16.04.2012, 11:23

Zitat:

bei nummern ist es eigentlich einfach -> was keine zahl ist fliegt raus.

Das ist auch nur eine Wunschvorstellung. Leider gibt es in Praxis reine Nummern, die als Userinput kommen, nur selten. Telefonnummern, Postleitzahlen, Hausnummern, Geldbeträge können alle nicht oder nur bedingt mit diesem Ansatz bearbeitet werden. Das einzige was mir da im Moment einfällt sind Mengenangaben, z. B. Anzahl bei Warenkörben.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Erweiterung um Autologin - Validierung, Logik ?	hausl	PHP Einsteiger	36	30.11.2011 10:22
Meine Formular Validierung (4)	elf	PHP Tipps 2010	36	15.11.2010 18:18
Meine Formular Validierung (3)	elf	PHP Tipps 2010	17	01.11.2010 12:32
Meine Formular Validierung (2)	elf	PHP Tipps 2010	7	20.10.2010 22:14
[Erledigt] Meine Formular Validierung	elf	PHP Tipps 2010	23	17.10.2010 15:23
Validierung	Sascha Ahlers	Wiki Diskussionsforum	5	17.06.2010 14:43
[Erledigt] HTML Validierung meckert über link	tkausl	PHP Tipps 2010	21	07.03.2010 22:31
[Erledigt] Bitte um Hilfe bei Validierung meines Scriptes	ePole	PHP Tipps 2010	22	24.02.2010 16:11
utf-8 validierung mit reg. Expr.	nikosch	PHP Tipps 2010	6	27.01.2010 15:53
Validierung !is_array($_POST['Vorname']) testen	kurtmos	PHP Tipps 2009	16	30.12.2009 19:48
[Erledigt] Mail Validierung MX Record Abfrage sinnvoll?	Ennosuke	PHP Tipps 2009	7	21.10.2009 17:55
dynamischer Bildupload + -validierung	Knutschi	PHP Tipps 2009	12	11.05.2009 22:28
Formulargenerierung + Validierung	cp_toby	Software-Design	11	01.03.2009 22:02
[Erledigt] Validierung mit Arrays	vyo	PHP Tipps 2008	4	27.12.2008 18:39
Formular und fehlermeldung--> Eingabedaten weg	nieselfriem	PHP Tipps 2005-2	8	16.06.2005 10:38


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

27.12.2011, 17:49
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Wenn "Vorvalidierung" gleich "Anwendungs-übergreifend" und damit nicht die Validierung konkreter Werte darstellt, kann ich mit dem Begriff leben - auch wenn ich ihn nicht besonders treffend finde. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

28.12.2011, 11:57
Renner Benutzer Registriert seit: 25.01.2011 Beiträge: 59 PHP-Kenntnisse: Fortgeschritten	Ein Securitycheck sollte an zentraler Stelle richtig positioniert sein. Stichwort: Intrusion Detection. https://phpids.org/

28.12.2011, 13:56
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Security-Check: ja, konkrete Validierung: nein. Genau das ist meine Aussage. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

01.01.2012, 18:27
drsoong Erfahrener Benutzer Registriert seit: 05.08.2008 Beiträge: 1.127	Ich stelle mir gerade mal den nicht so unüblichen Fall eines Adressformulars vor. Der User tippt bei PLZ statt 81479 irrigerweise München ein, da er in der Zeile verrutscht ist. Jetzt fragst Du: Soll ich das säubern und mit dem gesäuberten Wert weiterarbeiten oder lieber die Anwendungslogik abbrechen und eine Fehlerseite anzeigen. Frage: Wie willst Du solche Sachverhalte säubern oder in validen Input transformieren? Ich denke generell kann das nur schiefgehen, wenn man hier versucht, für jedwede Userdummheit eine säubernde Transformation zu coden. Was bleibt ist eigentlich nur die Fehlerseite, wobei ich mit Fehlerseite hier das Affenformular meine mit entsprechender Markierung der Fehlerquelle und einem Hinweis für den User. Säubern würde ich bestenfalls anhand einer Blacklist von malignen Codeelementen, wobei der Blacklistansatz ja auch nicht gerade als "preferable" propagiert wird. Statt säubern könnte man allerdings auch - je nach Anwendungsart - die komplette Session entwerten und den User/Hacker vor die Tür setzen. __________________ Es ist schon alles gesagt. Nur noch nicht von allen.

15.04.2012, 19:15
advanced_phpler Benutzer Registriert seit: 25.03.2010 Beiträge: 85 PHP-Kenntnisse: Fortgeschritten	du musst so oder so alle daten einzeln anschauen. wenn du sicherheitstechnisch strenge reglen setzt, kannst du auch gleich alles rausparsen. Der anwender wird dann naber keine freude haben gibt er z.b. mal eine Telefonnummer "+536/ 456 455 53 " ein. du kommst also nicht drum rum alle werte einzeln zu betrachten und sie kurz vor Verwendung zu parsen. es gibt keine Zentrale lösung.. ausser ev. das hochkomma vernichten. (+ individuell noch schauen) bei nummern ist es eigentlich einfach -> was keine zahl ist fliegt raus. entweder typecasting oder noch besser preq_prepleace "alles was keine zahl ist" .. somit würde auch eine zahl "12-34!ç5*sf6" korrekt interpretiert. mach ich z.b. so.. kann ja sein das der benutze sich vertippt.