Selbstprogrammierte Board-Software

[Andavos]

Hallo,
ich möchte euch meine Board-Software vorstellen, und bitte um eure Kritik.

Hierbei handelt es sich um das Command Board:
http://www.php-einfach.de/downloads_command_board.php

Dies ist eine MySQL basierte Board-Software, mit einer template basierten Benutzeroberfläche.
Wert bei der Entwicklung wurde auf die einfache Bedienung gelegt, und dass es nicht durch zuviele Zusatzfunktionen überladen wirkt.
Man soll es benutzen können, ohne HTML, PHP o.ä. Vorkenntnisse.

Wie findet ihr die Board-Software, was sollte ich noch verbessern, oder was ist unverständlich.

P.S. Ich weiß das viele hier ein Forum einem Board vorziehen ;)

MFG
Andavos

[Ludger]

Hi,

ich möchte euch meine Board-Software vorstellen, und bitte um eure Kritik.

stell doch mal das Back-End hier vor. das kann man ja nicht sehen und so ...  :-)

Gruss,
Ludger

[Andavos]

Haööp.

ich möchte euch meine Board-Software vorstellen, und bitte um eure Kritik.

stell doch mal das Back-End hier vor. das kann man ja nicht sehen und so ...  :-)

Du kannst dir die gesamte Board-Software herrunterladen und dann auf deinem eigenen Server einsetzen.
Damit erhält man ja auch gleichzeitig den Quellcode.

Grüße
Andavos

[Ludger]

Hi,

Du kannst dir die gesamte Board-Software herrunterladen und dann auf deinem eigenen Server einsetzen.
Damit erhält man ja auch gleichzeitig den Quellcode.

gibts auch eine System-Dokumentation?

Gruss,
Ludger

[Andavos]

Hallo,

Du kannst dir die gesamte Board-Software herrunterladen und dann auf deinem eigenen Server einsetzen.
Damit erhält man ja auch gleichzeitig den Quellcode.

gibts auch eine System-Dokumentation?

Ich bin immoment gerade dabei diese zu schreiben. Bisher gibt es nur die FAQ.

Grüße
Andavos

[sungirl2005]

Hallo und guten Tag,

hab mir gerade das ganze mal runter geladen und auch installiert. Ich muss sagen die Installation ist echt sehr einfach. So dann wollte ich das ganze mal aufrufen, dann bekomme ich folgede Meldungen:

Warning:  
Datei: template.class.php (Zeile: 12)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 13)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 14)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 15)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 16)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 17)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 21)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 22)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 23)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 26)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 27)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 28)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 29)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 30)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 31)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 32)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers  
  
Warning:  
Datei: template.class.php (Zeile: 33)  
Fehler: var: Deprecated. Please use the public/private/protected modifiers

Habe ich da ein Felher gemacht oder ist da noch ein Felher von deiner Seite drin?

Gruß sungirl2005

[Fabian St.]

Hi!

hab mir gerade das ganze mal runter geladen und auch installiert. Ich muss sagen die Installation ist echt sehr einfach. So dann wollte ich das ganze mal aufrufen, dann bekomme ich folgede Meldungen:

»»Warning:

Datei: template.class.php (Zeile: 12)
Fehler: var: Deprecated. Please use the public/private/protected modifiers

Du verwendest wohl PHP5, während unter PHP4 die Deklaration von Klassenvariablen mittels »var« vorgenommen wurde, was sich jedoch unter PHP5 aufgrund der breiteren und besseren OOP-Unterstützung geändert hat.

Grüße,
Fabian St.

[sungirl2005]

Hallo und guten Tag,

Du verwendest wohl PHP5, während unter PHP4 die Deklaration von Klassenvariablen mittels »var« vorgenommen wurde, was sich jedoch unter PHP5 aufgrund der breiteren und besseren OOP-Unterstützung geändert hat.

Hmm ob ich PHP5 verwende kann ich dir so gar nicht sagen, hab mir gestern den Xampp runter geladen. Muss mal schauen ob da PHP5 dabei ist. Aber sollte es so sein, heißt ich muss das ganze erst mal anpassen oder kann man da was umstellen oder so?

Gruß sungirl2005

[Andavos]

Hallo,

hab mir gerade das ganze mal runter geladen und auch installiert. Ich muss sagen die Installation ist echt sehr einfach.

Das freut mich :)

So dann wollte ich das ganze mal aufrufen, dann bekomme ich folgede Meldungen:

Habe ich da ein Felher gemacht oder ist da noch ein Felher von deiner Seite drin?

Nein das ist eigentlich mein Fehler.

Ich habe in dem Board einen eigenen Error-Handler, diese soll eigentlich NOTICE Meldungen unterdürcken.
Warum das jetzt nicht bei dir geht, weiß ich nicht.

Darum mach mal bitte folgendes:

In der admin/include/funktion.inc.php
error_reporting(7);
set_error_handler("error");

Kommentiere bitte das set_error_handler("error"); aus und versuche es dann nochmal.

Werde mich solange auf die Suche nach einer Lösung machen.

Gruß
Andavos

[sungirl2005]

Hallo und guten Tag,

Kommentiere bitte das set_error_handler("error"); aus und versuche es dann nochmal.

Ok hab das mal raus genommen und siehe da es geht :-) danke für deine schnelle Hilfe.

Gruß sungirl2005

[Andavos]

Hallo,

Kommentiere bitte das set_error_handler("error"); aus und versuche es dann nochmal.
Ok hab das mal raus genommen und siehe da es geht :-) danke für deine schnelle Hilfe.

Ok ich habe den Fehler gefunden. Und zwar ab PHP5 werden Verbesserungen zum Code ausgegeben.
Zwar unterdrücke ich Notice, aber keine Code-Vorschläge.

Aber irgendwie gibt sie mir mein PHP5.0.3 nicht aus ^^

Danke für den Hinweis.

Grüße
Andavos

[sungirl2005]

Hallo und guten Tag,

Danke für den Hinweis.

kein Problem habe ich doch gerne gemacht *fg* aber sag mal das ganze erinnert mich doch sehr an das PHPBB Bord hast du das dort abgescrhieben oder kommt das alles von dir allein?

Gruß sungirl2005

[Andavos]

Hallo,

Danke für den Hinweis.

kein Problem habe ich doch gerne gemacht *fg* aber sag mal das ganze erinnert mich doch sehr an das PHPBB Bord hast du das dort abgescrhieben oder kommt das alles von dir allein?

Also ich habe die Board-Engine zu 100% selber programmiert. Nur beim Aussehen/Struktur der Ausgabe habe ich mich an den führenden Board-Lösungen orientiert.

Gruß
Andavos

[sungirl2005]

Hallo und guten Tag,

Also ich habe die Board-Engine zu 100% selber programmiert. Nur beim Aussehen/Struktur der Ausgabe habe ich mich an den führenden Board-Lösungen orientiert.

achso :-) ist aber echt sehr gut geworden :-)

Gruß sungirl2005

[Thomas J.S.]

Hallo,

aber sag mal das ganze erinnert mich doch sehr an das PHPBB Bord

gibt's überhapt ein Board das nicht einem beliebigen anderen Board ähnelt?

Grüße
Thomas

[Andavos]

Hallo,

aber sag mal das ganze erinnert mich doch sehr an das PHPBB Bord

gibt's überhapt ein Board das nicht einem beliebigen anderen Board ähnelt?

Der Aufbau von alle (mir bekannten) Boards beruhen auf dem uBB.classic. Dies gibt es seit 1996.
Ob es davor noch andere Boards gab, weiß ich nicht.

Beispiel Board

Gruß
Andavos

[Thomas J.S.]

Hallo,

gibt's überhapt ein Board das nicht einem beliebigen anderen Board ähnelt?
Der Aufbau von alle (mir bekannten) Boards beruhen auf dem uBB.classic. Dies gibt es seit 1996.

Meine Frage war ironisch gemeint. ;-)

Grüße
Thomas

[Dennis]

Hi Thomas,

gibt's überhapt ein Board das nicht einem beliebigen anderen Board ähnelt?

Hehe, full ACK!! ;-)

MfG, Dennis.

[Fabian St.]

Hi!

Ok hab das mal raus genommen und siehe da es geht :-) danke für deine schnelle Hilfe.
Ok ich habe den Fehler gefunden. Und zwar ab PHP5 werden Verbesserungen zum Code ausgegeben.
Zwar unterdrücke ich Notice, aber keine Code-Vorschläge.

Aber irgendwie gibt sie mir mein PHP5.0.3 nicht aus ^^

Dein PHP 5.0.3 wird dir diese E_STRICT Meldungen auch ausgeben, wenn du es dazu überredest: Setze in deiner php.ini für die Direktive error_reporting den Wert E_ALL | E_STRICT:

;Zeige wirklich alle möglichen Fehlerquellen und Kompatibilitätsmeldungen an:
error_reporting = E_ALL | E_STRICT

Möglich wäre ferner auch der Integer-Wert 4095. Siehe auch http://de.php.net/manual/de/ref.errorfunc.php#e-strict

Grüße,
Fabian St.

[Eternius]

Hallo,

durch was besticht es denn?
  durch das hier?

oder doch eher durch sowas:

  
$username = trim($_POST['username']);  
  
$check_abfrage = "SELECT id, username, passwort, aktiv, lastvisit, cookie_modus, cookie_zufall, pw_update FROM $userdb WHERE username = '$username'";  

ich weiss ja nicht wie das bei php5 jetzt läuft und ich habe auch nicht weiter nachgeschaut, ob du die variablen vorher noch überarbeitet hast, aber das wäre so ein schönes Ding für SQL Injection.

gruss

[Andavos]

Hallo,

durch was besticht es denn?
  durch das hier?

oder doch eher durch sowas:

$username = trim($_POST['username']);

$check_abfrage = "SELECT id, username, passwort, aktiv, lastvisit, cookie_modus, cookie_zufall, pw_update FROM $userdb WHERE username = '$username'";

>   ich weiss ja nicht wie das bei php5 jetzt läuft und ich habe auch nicht weiter nachgeschaut, ob du die variablen vorher noch überarbeitet hast, aber das wäre so ein schönes Ding für SQL Injection.  

Alle Variablen vom User (post, get etc.) werden vorher per addslashes(); maskiert.  
  
Bzw. ein Script simuliert magic\_quotes\_gpc => ON sofern es auf Off steht.  
Dadruch sind SQL-Injections nicht möglich.  
  
Grüße  
Andavos  

[Dennis]

Hi Andavos,

Alle Variablen vom User (post, get etc.) werden vorher per addslashes(); maskiert.

Das ist nicht ganz der richtige Lösungs-Weg - mysql_escape_string() bzw. noch besser mysql_real_escape_string() wäre die richtige[tm] Lösung.

MfG, Dennis.

[Andavos]

Hallo,

Alle Variablen vom User (post, get etc.) werden vorher per addslashes(); maskiert.

Das ist nicht ganz der richtige Lösungs-Weg - mysql_escape_string() bzw. noch besser mysql_real_escape_string() wäre die richtige[tm] Lösung.

Wo ist denn genau der Unterschied zwischen mysql_escape_string(); und addslashes()?

Also addslashes():

Die behandelten Zeichen sind das einfache und der doppelte Anführungszeichen (' und "), der Backslash selbst () sowie NUL (das Null-Byte).

Also: ', ", , NULL

mysql_real_escape_string:

diese stellt den folgenden Zeichen einen Backslash voran: NULL, \x00, \n, \r, , ', " und \x1a.

Der Unterschied ist also minimal und irrelevant, und mir ist keine Attacke bekannt, die den Unterschied ausnutzen kann.
Desweiteren müsste ich zuerst das addslashes(); von magic_quotes_gpc entfernen.
Da es aber per default auf ON ist, wäre dies Performance intensiver also meine Variante.

MFG
Andavos

[wahsaga]

hi,

Wo ist denn genau der Unterschied zwischen mysql_escape_string(); und addslashes()?

Der Unterschied ist der, das ersteres für den zur Diskussion stehenden Zweck gedacht ist, und letzteres nur oftmals fälschlicherweise als "Ersatz" dafür missb^H^H^H^H^Hverwendet wird.

gruß,
wahsaga

[Andavos]

Hallo,

Der Unterschied ist der, das ersteres für den zur Diskussion stehenden Zweck gedacht ist, und letzteres nur oftmals fälschlicherweise als "Ersatz" dafür missb^H^H^H^H^Hverwendet wird.

Und welche folge hätte dies, wenn man anstatt mysql_escape_string() => addslashes(); benutzt?

Mir ist bei der Verwendung im Board, auch mit den nicht maskierten Zeichen (0x1A), kein Unterschied zwischen den beiden Varianten aufgefallen.
Die Ausgabe & Speicherung bleibt identisch.

Gruß
Andavos

[wahsaga]

hi,

Und welche folge hätte dies, wenn man anstatt mysql_escape_string() => addslashes(); benutzt?

Das der Programmierer von Leuten mit Erfahrung ernster genommen würde ;-)

gruß,
wahsaga

[Andavos]

Hallo,

Und welche folge hätte dies, wenn man anstatt mysql_escape_string() => addslashes(); benutzt?

Das der Programmierer von Leuten mit Erfahrung ernster genommen würde ;-)

Damit kann ich leben ;)
Aber gäbe es noch andere, Sicherheitsrelevante folgen?
Denn nur die sind Intressant.

P.S. Das Woltlab Burning Board (wBB) benutzt z.B. auch addslashes(); anstatt mysql_escape_string();

Gruß
Andavos

[Christian Kruse]

你好 Andavos,

Aber gäbe es noch andere, Sicherheitsrelevante folgen?
Denn nur die sind Intressant.

Die Escaping-Mechanismen von MySQL können sich mit jeder Version ändern.

P.S. Das Woltlab Burning Board (wBB) benutzt z.B. auch addslashes();
anstatt mysql_escape_string();

„Fresst Scheisse! 8 Milliarden Fliegen können nicht irren!“

再见,
 克里斯蒂安

[Christian Kruse]

你好 Andavos,

Und welche folge hätte dies, wenn man anstatt mysql_escape_string() =>
addslashes(); benutzt?

mysql_real_escape_string() kann sich jederzeit ändern und inkompatibel zu
addslashes() werden.

再见,
 克里斯蒂安

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Desweiteren müsste ich zuerst das addslashes(); von magic_quotes_gpc entfernen.

Ja. Da siehst du mal, was für ein Blödsinn magic_quotes ist.
Eine Atacke aufgrund der fehlerhaften Maskierung ist AFAIK möglich,
mysql_real_escape_string ist im Gegensatz zu addslashes darauf ausgelegt,
solchen MySQL-Injections zu verhindern.

Da es aber per default auf ON ist, wäre dies Performance intensiver also meine Variante.

Eine Durchschnitts-Query dauert AFAIK 8ms, stripslashes auf alle Werte in $_REQUEST
ist normalerweise nicht messbar.

Gruß
Alexander Brock

[Christoph Zurnieden]

Hi,

Alle Variablen vom User (post, get etc.) werden vorher per addslashes(); maskiert.

Das reicht nicht, aber das ist auch nicht das Problem.
Was mich bei fast allen Anti-SQL-Injections-Tutorials ($PHP/manual/en/security.database.sql-injection.php ist da eine zwar erfreuliche aber auch noch nicht weit genug gehende Ausnahme), die ich eben auf dis Schnelle durchging stört, ist der Umstand, das niemand darauf eingeht, das das Hauptproblem darin besteht, jeden Mist zuzulassen und dann rauszusieben, was man _nicht_ haben möchte. Das ist verkehrtherum.

Richtig herum wäre es nur das zuzulassen, was man benötigt. Erwartet man eine Nummer, prüft man, ob eine Nummer angekommen ist, erwartet man einen String, der nur aus Buchstaben besteht, schaut man anch, ob der auch nur aus Buchstaben besteht. Was eine Nummer ist oder ein Buchstabe bestimmst Du dabei und nicht irgendjemand anderes.
Im speziellem Beispiel oben wären das $userdb und $username. Ich habe jetzt nicht in den Code geschaut, nehme aber an, das hier nur $username von außen kommt. Ein Benutzername benötigt numal nur Buchstaben. Ideal wäre hier ein Beschränkung auf ASCII, wenn man sich unsicher ist wie die DB z.B. auf UTF-16 reagiert.
Problematisch bei einem Board sind natürlich die einzelnen Postings, da mag sich keiner irgendwelchen Beschränkungen unterwerfen lassen und auch UTF-8 ist hier ein praktische Erfindung. Trotzdem kannst und sollst Du auch genauso verfahren: nur das an Zeichen zulassen, was Du geprüft und als ungefährlich eingestuft hast. Als ungefährlich gilt natürlich auch, was Du sicher(!) entschärfen kannst. Alle DB-spezifischen PHP-Funktionen gelten hier _nur_ für die zur Drucklegung aktuellen Versionen eben jener spezifischen DB.
Wirklich sicher sind hier eigentlich nur Mappings auf ASCII wie z.B. base64() o.ä., wie auch in einigen Artikeln tatsächlich vorgeschlagen. Aber sowas kostet natürlich nicht nur Rechenzeit (die man zur Not auch mit ordentlich Chuzpe und ein wenig Javascript auf den Client abwälzen könnte ;-) sondern selbstverständlich auch 30% mehr Platz. Es ist dann aber auch völlig egal, welche Codierung vorne reingeht und welche DB hinten dran hängt.

so short

Christoph Zurnieden

[wahsaga]

hi,

Wirklich sicher sind hier eigentlich nur Mappings auf ASCII wie z.B. base64() o.ä., wie auch in einigen Artikeln tatsächlich vorgeschlagen. Aber sowas kostet natürlich nicht nur Rechenzeit (die man zur Not auch mit ordentlich Chuzpe und ein wenig Javascript auf den Client abwälzen könnte ;-)

Den Vorschlag, als sicherheitsrelevant erachtete Transformationen der Daten _clientseitig_ durchführen zu lassen, meinst du jetzt aber nicht ernst, oder?

gruß,
wahsaga

[Christoph Zurnieden]

Hi,

Wirklich sicher sind hier eigentlich nur Mappings auf ASCII wie z.B. base64() o.ä., wie auch in einigen Artikeln tatsächlich vorgeschlagen. Aber sowas kostet natürlich nicht nur Rechenzeit (die man zur Not auch mit ordentlich Chuzpe und ein wenig Javascript auf den Client abwälzen könnte ;-)

Den Vorschlag, als sicherheitsrelevant erachtete Transformationen der Daten _clientseitig_ durchführen zu lassen, meinst du jetzt aber nicht ernst, oder?

Sowas würde ich nie tun und das wird hier auch nicht gemacht.
Weiter oben hatte ich ja erwähnt, das nur das durchgelassen werden darf, was auch erwartet wird. Bei base64-Codierung sind das [A-Za-z0-9+/=] und das kann z.B. mit eben diesem Ausdruck gefiltert werden. Sicherheitstechnisch liegt also kein Problem vor, die base64-Codierung kann auf dem Client erfolgen.

so short

Christoph Zurnieden

[Eternius]

Hallo,

Das reicht nicht, aber das ist auch nicht das Problem.
Was mich bei fast allen Anti-SQL-Injections-Tutorials ($PHP/manual/en/security.database.sql-injection.php ist da eine zwar erfreuliche aber auch noch nicht weit genug gehende Ausnahme), die ich eben auf dis Schnelle durchging stört, ist der Umstand, das niemand darauf eingeht, das das Hauptproblem darin besteht, jeden Mist zuzulassen und dann rauszusieben, was man _nicht_ haben möchte. Das ist verkehrtherum.

sehe und handhabe ich schon lange so. Ist eigentlich auch recht einfach umzusetzen: Ich transportiere die Information über die Variablen im Variablen Namen: z.B.
name="int_10_formularfeld" oder
name="str_255_test" oder
name="txt_comment".

für kleine Projekte ist das ganze natürlich nicht nötig, da kann man das auch für alle Variablen per Hand festlegen.

dann geh ich jetzt her und splitte den namen auf:
(variablen, die nicht dort hineinpassen, werden gelöscht, oder es wird gestorben (die))
für int_10_forumlarfeld ergibt das:
type='int';
length=10
regexp="/[^0-9]/";

danach wird das ganze überprüft ob diese sachen auch zutreffen.
unterschiedliches Verhalten bei nichtzutreffen lässt sich ja implementieren, wie variable löschen, variable cleanen (gefahrenträchtig), oder das skript gar abbrechen.

der trick daran ist eigentlich das die variable auch im program per $hash{'int_10_formularfeld'} angesprochen werden muss, das heisst die sache lässt sich nicht umgehen, wenn jemand jetzt z.b. einfach int_25_formularfeld als name schickt, hat das keine auswirkung (weil die variable nirgendwo benutzt wird).
natürlich fordert das auch disziplin vom programmierer.

Das Ganze habe ich noch auf "trust" klassen verteilt, also z.b. darf "getrusteter" user andere zeichenklassen benutzen als ein als "untrusted" eingestufter.

gruss

[Christoph Zurnieden]

Hi,

»»[...] das das Hauptproblem darin besteht, jeden Mist zuzulassen und dann rauszusieben, was man _nicht_ haben möchte. Das ist verkehrtherum.

sehe und handhabe ich schon lange so. Ist eigentlich auch recht einfach umzusetzen: Ich transportiere die Information über die Variablen im Variablen Namen: z.B.
name="int_10_formularfeld" oder
name="str_255_test" oder
name="txt_comment".

Wenn das beim Client liegt, kann es da auch verändert werden. Ich halte dieses Vorgehen -- wenn so implementiert ist, wie ich das verstanden habe -- für problematisch.

für kleine Projekte ist das ganze natürlich nicht nötig, da kann man das auch für alle Variablen per Hand festlegen.

Würde ich vorziehen.

der trick daran ist eigentlich das die variable auch im program per $hash{'int_10_formularfeld'} angesprochen werden muss, das heisst die sache lässt sich nicht umgehen, wenn jemand jetzt z.b. einfach int_25_formularfeld als name schickt, hat das keine auswirkung (weil die variable nirgendwo benutzt wird).

Na gut, dann geht's so halbwegs, wenn man von perfekter Implementation ausgeht.

natürlich fordert das auch disziplin vom programmierer.

Das ist nicht unbedingt eine leicht einzuhaltende Voraussetzung ;-)

Das Ganze habe ich noch auf "trust" klassen verteilt, also z.b. darf "getrusteter" user andere zeichenklassen benutzen als ein als "untrusted" eingestufter.

Dafür müßte ich wohl erst den Code sehen, um zu verstehen warum Du Dir ein eigenes Rechtesystem zusammengebastelt hast.

so short

Christoph Zurnieden

[Eternius]

Hui,

Wenn das beim Client liegt, kann es da auch verändert werden. Ich halte dieses Vorgehen -- wenn so implementiert ist, wie ich das verstanden habe -- für problematisch.

nein, das liegt ausschlieslich beim server.

der trick daran ist eigentlich das die variable auch im program per $hash{'int_10_formularfeld'} angesprochen werden muss, das heisst die sache lässt sich nicht umgehen, wenn jemand jetzt z.b. einfach int_25_formularfeld als name schickt, hat das keine auswirkung (weil die variable nirgendwo benutzt wird).

Na gut, dann geht's so halbwegs, wenn man von perfekter Implementation ausgeht.

nicht wirklich, es fordert nur namenskonventionen für <input oder etc., werden diese nicht eingehalten, existieren die variablen im (servserseitigen) skript nicht.

natürlich fordert das auch disziplin vom programmierer.

Das ist nicht unbedingt eine leicht einzuhaltende Voraussetzung ;-)

hmmm. was sonst, bzw macht das ein IDE leichter? (ich sage nein)

Dafür müßte ich wohl erst den Code sehen, um zu verstehen warum Du Dir ein eigenes Rechtesystem zusammengebastelt hast.

das ist ja gar nicht relevant, das warum. das war eigentlich auch nur ein (weiterdenkender) zusatz.

gruss

[Christoph Zurnieden]

Hi,

Wenn das beim Client liegt, kann es da auch verändert werden. Ich halte dieses Vorgehen -- wenn so implementiert ist, wie ich das verstanden habe -- für problematisch.

nein, das liegt ausschlieslich beim server.

Ja, das kommt davon, wenn man die Postings linear beantwortet, 'tschuldigung.

der trick daran ist eigentlich das die variable auch im program per $hash{'int_10_formularfeld'} angesprochen werden muss, das heisst die sache lässt sich nicht umgehen, wenn jemand jetzt z.b. einfach int_25_formularfeld als name schickt, hat das keine auswirkung (weil die variable nirgendwo benutzt wird).

Na gut, dann geht's so halbwegs, wenn man von perfekter Implementation ausgeht.

nicht wirklich,

Mit "perfekt" meine ich eher die Bedeutung wie in "perfekter Hash", nicht die allgemeine Bedeutung.
Es wäre hier also stets zuerst zu prüfen, ob die Variable existieren darf. Erst dann kann damit gearbeitet werden.
Es gibt also kein "ungefähr", statistische Wahrscheinlichkeiten reichen nicht aus und ein Fallback existiert nicht.

es fordert nur namenskonventionen für <input oder etc., werden diese nicht eingehalten, existieren die variablen im (servserseitigen) skript nicht.

Das alles schützt natürlich nur eine Manipulation innerhalb der Namenskonvention also nur innerhalb des Variablen_namens_ nicht innerhalb der Variable selber also dem Inhalt der Variable. Deine Version der ungarischen Notation stellt nur den Typ des Inhaltes sicher.
Nicht das ich das schlechtmachen möchte -- bewahre! -- aber Du stehst dabei immer noch vor dem Problem der Dir fast (Typ ist ja einschränkbar) völlig unbekannten Daten selber, die mußt Du immer noch prüfen.

natürlich fordert das auch disziplin vom programmierer.

Das ist nicht unbedingt eine leicht einzuhaltende Voraussetzung ;-)

hmmm. was sonst, bzw macht das ein IDE leichter? (ich sage nein)

Ich weiß nicht ob eine IDE das leichter macht, ich habe schon lange keine für mehr als nur das Zusammenklicken von GUIs in der Hand gehabt.
Aber ich spitzte ja auch nur scherzhaft auf die Kombination von "Disziplin" und "Programmierer" in einem Satz, mehr nicht.

Dafür müßte ich wohl erst den Code sehen, um zu verstehen warum Du Dir ein eigenes Rechtesystem zusammengebastelt hast.

das ist ja gar nicht relevant, das warum. das war eigentlich auch nur ein (weiterdenkender) zusatz.

Ja, aber gräme Dich nicht, mitunter erwische ich mich auch noch dabei, das ich das Rad neu erfinde. Aber es erfordert halt Disziplin, vor _jedem_ neuem Ansatz nachzuschauen, ob das nicht schon jemand anderes gebastelt hat und das meist auch noch besser ;-)

so short

Christoph Zurnieden

[Eternius]

Moin,

Mit "perfekt" meine ich eher die Bedeutung wie in "perfekter Hash", nicht die allgemeine Bedeutung.
Es wäre hier also stets zuerst zu prüfen, ob die Variable existieren darf. Erst dann kann damit gearbeitet werden.
Es gibt also kein "ungefähr", statistische Wahrscheinlichkeiten reichen nicht aus und ein Fallback existiert nicht.

hmm, ist es nicht ziemlich egal, ob eine variable existieren darf oder nicht?

  
<form action="bla.pl">  
<input type="text" name="blub" />  
<input type="text" name="fred" />  
</form>  

  
#!/perl  
%formdaten=&hole_form_daten;  
print $formdaten{'blub'};  
__END__  

da ist doch jetzt völlig egal ob die variable/hasheintrag fred existiert oder nicht, weil sie nicht verwendet wird.

Das alles schützt natürlich nur eine Manipulation innerhalb der Namenskonvention also nur innerhalb des Variablen_namens_ nicht innerhalb der Variable selber also dem Inhalt der Variable. Deine Version der ungarischen Notation stellt nur den Typ des Inhaltes sicher.
Nicht das ich das schlechtmachen möchte -- bewahre! -- aber Du stehst dabei immer noch vor dem Problem der Dir fast (Typ ist ja einschränkbar) völlig unbekannten Daten selber, die mußt Du immer noch prüfen.

ich glaube wir reden aneinander vorbei ;):

~~~html

<input type="text" name="int_5_test" value="200" />

  
  würde im skript zu anfang folgendermaßen verarbeitet werden (die kurzform):  
~~~perl
  
#[..]  
  $REGS{int}='[^0-9]';  
  $original_name='int_5_test';  
  #der name wird auseinander genommen und den variablen type und length zugeordnet, der inhalt wird der variable inhalt zugeordnet  
  $type='int';  
  $length=5;  
  if (length($inhalt > $length) || $inhalt=~/$REGS{$type}/){  
    die "fehler, ungültige länge oder zeicheneingabe";  
  }  
  else  
  {  
    $erlaube_variablen{$original_name}=$inhalt;  
  }  
 

es wird vorher natürlich auch geprüft, ob der variablenname selbst in ordnung ist. Ob! der int dann im endeffekt in der funktion, in der er später benutzt wird, im gültigen wertebereich liegt, dass muss und kann (nur) die funktion selber prüfen.

Ja, aber gräme Dich nicht, mitunter erwische ich mich auch noch dabei, das ich das Rad neu erfinde. Aber es erfordert halt Disziplin, vor _jedem_ neuem Ansatz nachzuschauen, ob das nicht schon jemand anderes gebastelt hat und das meist auch noch besser ;-)

selber lernen macht schlau ;)

gruss

[Eternius]

Ähem,

if (length($inhalt > $length) || $inhalt=~/$REGS{$type}/){

  
    if (length($inhalt) > $length || [..])  

gruss

[Christoph Zurnieden]

Hi,

#!/perl
%formdaten=&hole_form_daten;
print $formdaten{'blub'};
END

>   
> da ist doch jetzt völlig egal ob die variable/hasheintrag fred existiert oder nicht, weil sie nicht verwendet wird.  
  
Ja, aber es ist nicht egal, ob die Variable 'blub' existiert und das meinte ich.  
  

>   ich glaube wir reden aneinander vorbei ;):  
  
Das ist nicht unwahrscheinlich ;-)  
  

>   ~~~html
  

>   <input type="text" name="int_5_test" value="200" />  
>   

würde im skript zu anfang folgendermaßen verarbeitet werden (die kurzform):

#[..]
  $REGS{int}='[^0-9]';
  $original_name='int_5_test';
  #der name wird auseinander genommen und den variablen type und length zugeordnet, der inhalt wird der variable inhalt zugeordnet
  $type='int';
  $length=5;
  if (length($inhalt > $length) || $inhalt=~/$REGS{$type}/){
    die "fehler, ungültige länge oder zeicheneingabe";
  }
  else
  {
    $erlaube_variablen{$original_name}=$inhalt;
  }

  
Aha, Du machst ds alos genau umgekehr, wie von mir angegeben.  
Ich hatte es so vermutet und auch als logisch empfunden:  
Wenn der Variablenname erlaubt ist  
  parse Variablenname  
  parse Variableninhalt  
    wenn der Variableninhalt den Vorgaben enstpricht  
      benutze Variable  
    sonst  
      gebe Fehler aus  
Sonst  
  gebe Fehler aus.  
  
"Vorgaben" sind hier die Typisierung laut Variablennamen und die sonstigen üblichen Checks (nur ASCII im String o.ä.)  
  
Die allererste Prüfung hier ist also, ob der Variablenname eine Entsprechung in einer Liste der erlaubten Variablennamen findet. Dann erst folgt das Parsen des Variablennamens und die Anwendung der so gefundenen Tests des Inhaltes. Laut Deinem Beispiel 'int\_5\_test' wäre ein Integer der Länge 5 zu erwarten. 'test' ist hier der individuelle Bezeichner und '\_' ein Trennzeichen. Das nötige Vorwissen ist hier, das alles als String ankommt, der Integer ist dezimal in ASCII codiert und Länge bezeichnet die maximal Anzahl der Oktetts (das habe ich mal Deinem Code entnommen bei stillschweigender Korrektur).  
Das wäre dann eine schöne Bequemlichkeit, mehr zwar nicht, aber immerhin.  
So wie Du das machst fehlt die Nutzung der Kontrollmöglichkeit, die so eine Namenskonvention bietet.  
  
  
so short  
  
Christoph Zurnieden

[Eternius]

Hi,

Ja, aber es ist nicht egal, ob die Variable 'blub' existiert und das meinte ich.

klär mich auf?! (nein, nicht den witz mit den bienchen und blümchen)

[..] pseudo code

wenn variablenname entspricht vorgabe: '[^0-9a-zA-Z_]'
  wenn variable lässt sich in schema einteilen (z.B.!!) [typ]_[length]_[rest]
    wenn Vorgaben treffen auf variablen inhalt zu
      übernehme variable in das ergebnishash
    sonst die
  sonst die
sonst die

"Vorgaben" sind hier die Typisierung laut Variablennamen und die sonstigen üblichen Checks (nur ASCII im String o.ä.)

ja, was sonst? bzw. klär mich auf :)

Die allererste Prüfung hier ist also, ob der Variablenname eine Entsprechung in einer Liste der erlaubten Variablennamen findet.

nein. das ist für die funktion gar nicht entscheidbar. Die funktion ist eine der ersten, die aufgerufen wird, daher kann sie nicht wissen, welche variablen ein modul/plugin ganz am ende benötigt.

Das wäre dann eine schöne Bequemlichkeit, mehr zwar nicht, aber immerhin.

was heisst bequemlichkeit? man kommt ja gar nicht drumherum.

So wie Du das machst fehlt die Nutzung der Kontrollmöglichkeit, die so eine Namenskonvention bietet.

die da wären?

gruss

[Christoph Zurnieden]

Hi,

Ja, aber es ist nicht egal, ob die Variable 'blub' existiert und das meinte ich.

klär mich auf?! (nein, nicht den witz mit den bienchen und blümchen)

Ist ein Problem der Braunbärenpopulation.

[..] pseudo code

wenn variablenname entspricht vorgabe: '[^0-9a-zA-Z_]'

Ja, genau heir gehen unsere Vorstellungen auseinander. Sinnvoll wäre eine Liste mit einzig zulässigen Variablennamen gegen die dann geprüft wird. Du überprüfst ja direkt im Anschluß bereits, ob die Syntax des Variablennamens korrekt ist:

wenn variable lässt sich in schema einteilen (z.B.!!) [typ]_[length]_[rest]

Wenn Du die Variable aus einer Liste überprüfst kannst Du Dir mithin eine Prüfung schenken.

wenn Vorgaben treffen auf variablen inhalt zu
      übernehme variable in das ergebnishash

Anstatt die Variable in den Ergebnishash zu übernehmen könntest Du sie auch direkt bearbeiten.

"Vorgaben" sind hier die Typisierung laut Variablennamen und die sonstigen üblichen Checks (nur ASCII im String o.ä.)

ja, was sonst? bzw. klär mich auf :)

Das ist nur eine Definition, keine Kritik.

nein. das ist für die funktion gar nicht entscheidbar.

Warum nicht? Wo kommt der Variablenname denn her?

Die funktion ist eine der ersten, die aufgerufen wird, daher kann sie nicht wissen, welche variablen ein modul/plugin ganz am ende benötigt.

Das dürfte wohl irgendeines oder vielleciht auch gar keines der gegebenen Variablen benötigen. Und die sind zu dem Zeitpunkt bekannt. Sind sie das wirklich nicht ist die ganze Sache deutlich anders konstruiert als Du hier verraten hast.

Das wäre dann eine schöne Bequemlichkeit, mehr zwar nicht, aber immerhin.

was heisst bequemlichkeit? man kommt ja gar nicht drumherum.

Ach, man kommt immer drumherum, ist nur meist aufwendiger ;-)

So wie Du das machst fehlt die Nutzung der Kontrollmöglichkeit, die so eine Namenskonvention bietet.

die da wären?

Das der Variablenname vorher bekannt ist und so früher gesiebt werden kann.

so short

Christoph Zurnieden

[Eternius]

Hai,

  
#!/usr/bin/perl  
use strict;  
  
package AssertVars;  
{  
  use CGI::Lite;  
  my $dbg=1;  
  my $FATAL=0;  
  my $VALID_NAME='[^0-9a-zA-Z_]';  
  my $BOUNDARY=1;  
  my %REGS;  
  
####regs  
  $REGS{'b'}='[^0-1]';   #bool  
  $REGS{'i'}='[^0-9]';   #int  
###/regs  
  
  sub spawn{  
    warn ('spawn') if $dbg;  
    my $c=shift;  
    my $self={};  
    $self->{cgi}=new CGI::Lite;  
    bless ($self,$c);  
    return (defined $self->{cgi})?$self:undef;  
  }  
  
  sub get_fd  
  {  
    my $self=shift;  
    warn('get_fd') if $dbg;  
    my %_fd=$self->{cgi}->parse_form_data;  
    foreach (keys(%_fd))  
    {  
      if ($self->is_valid_name($_))  
      {  
        #nix array  
        if(ref($_fd{$_})){$_fd{$_}=$_fd{$_}[0];}  
        my $chk=$self->is_valid_value($_,$_fd{$_});  
        if (not defined $chk)  
        {  
          die if $FATAL;  
          warn('  value is not valid') if $dbg;  
          delete $_fd{$_};  
        }  
        else{  
          warn('  var passed: '.$_);  
        }  
      }  
      else  
      {  
        die if $FATAL;  
        warn('  name is not valid') if $dbg;  
        delete $_fd{$_};  
      }  
    }  
    return \%_fd;  
  }  
  
  sub is_valid_value  
  {  
    my $self=shift;  
    my $n=shift;  
    my $v=shift;  
    my $v_id=substr($n,0,$BOUNDARY);  
    if (defined $n && defined $v_id && defined $REGS{$v_id})  
    {  
      return ($v=~/$REGS{$v_id}/)?undef:1;  
    }  
    else  
    {  
      return undef;  
    }  
  }  
  
  sub is_valid_name{  
    shift and return (shift =~/$VALID_NAME/)?0:1;  
  }  
}  
  
#initialisiere nötiges System  
print "Content-type: text/html\n\n";  
my $a=spawn AssertVars();  
my $fd=$a->get_fd;  
use Data::Dumper;  
print Dumper($fd);  
#rufe sonstiges modul/plugin/sub auf, bzw beginne die eigentliche arbeit  

Eine einfache Version die nur anhand von (einfachen) regulären ausdrücken den inhalt prüft.

Es (sollte) funktionieren. Kannst es gerne ausprobieren und dir angucken was es macht.

gruss

[Christian Kruse]

你好 Andavos,

Alle Variablen vom User (post, get etc.) werden vorher per addslashes();
maskiert.

Damit fällst du bei PostGreSQL oder DB2 oder [… setze DB-System ein …] auf
die Schnauze. Benutze die entsprechenden Escaping-Funktionen der DB-API,
z. B. mysql_real_escape_string() oder pg_escape_string().

再见,
 克里斯蒂安

[Andavos]

Hallo,

Alle Variablen vom User (post, get etc.) werden vorher per addslashes();
maskiert.

Damit fällst du bei PostGreSQL oder DB2 oder [… setze DB-System ein …] auf
die Schnauze. Benutze die entsprechenden Escaping-Funktionen der DB-API,
z. B. mysql_real_escape_string() oder pg_escape_string().

Danke für den Hinweis, allerdings ist es nur für MySQL gedacht.

Und wie gesagt, die Test mit den nicht maskierten Zeichen von addslashes(); brachten keine Probleme zum Vorschein.

Sonst nennt dochmal bitte ein Query, wo addslashes() "versagen" würde, aber mysql_escape_string(); diesen korekt maskieren würde.

Aber ich denke mal für die nächsten Versionen darüber nach.

Grüße
Andavos

[Jeena Paradies]

Hallo,

durch das hier?

Naja, das kann man schon fast nicht als Fehler bezeichnen, da ich absolut keinen Browser kenne, der damit nicht umgehen kann. Außerdem ist das ja auch schnell behoben indem man aus & einfach &amp; macht. Ansonsten fand ich da überhaupt keine anderen Fehler (außer jetzt DOCTYPE)

Was wegen HTML Code viel wichtiger auffällt ist das Tebellendesign und Sachen wie <font>, aber dazu muss man sagen, dass dies wohl nicht zum Programm gehört, sondern eine Sache der Templates ist, die man ja nach seinen Wünschen erstellen kann.

$username = trim($_POST['username']);
$check_abfrage = "SELECT id, username, passwort, aktiv, lastvisit, cookie_modus, cookie_zufall, pw_update FROM $userdb WHERE username = '$username'";

Das dagegen ist schon ein sehr böser Fehler und darf so nicht vorkommen. Solche Leichtsinns Sicherheitslücken bringen nämlich diese ganze BB-Software immer wieder in Verruf, so dass [Provider sich gezwungen fühlen diese Software auf ihren Servern gar nicht mehr zuzulassen](http://unblogbar.com/weblog/1284/).  
  
Grüße  
Jeena Paradies

-- 
[Wohin mit Pingback?](http://jeenaparadies.net/weblog/2005/sep/pingback) Oder wie wichtig ist es? | [Jlog](http://jeenaparadies.net/webdesign/jlog/) | [Gourmetica Mentiri](http://jeenaparadies.net/gourmetica-mentiri/)

[Andavos]

Hallo,

$username = trim($_POST['username']);
$check_abfrage = "SELECT id, username, passwort, aktiv, lastvisit, cookie_modus, cookie_zufall, pw_update FROM $userdb WHERE username = '$username'";

> Das dagegen ist schon ein sehr böser Fehler  

Durch das simulieren von magic\_quotes\_gpc(); sofern es auf Off steht, ist es nicht möglich (afaik), diese Abfrage zu manipulieren.  
  
Bei der Entwicklung wurde auch auf die Sicherheit geachtet.  
  
Der Code, der magic\_quotes\_gpc(); simuliert:  
~~~php
  
//Wird in jeder Datei am Anfang aufgerufen  
if(get_magic_quotes_gpc() == 0)  
   {  
   on_gpc();  
   }  
  
function makeon($v) {  
   return is_array($v) ? array_map('makeon', $v) : addslashes($v);  
 }  
  
 function on_gpc() {  
   foreach (array('POST', 'GET', 'REQUEST', 'COOKIE', 'SERVER') as $gpc)  
   $GLOBALS["_$gpc"] = array_map('makeon', $GLOBALS["_$gpc"]);  
 }  

(Code aus dem PHP-Manual)

Grüße
Andavos

[Sven Rautenberg]

Moin!

Hallo,

$username = trim($_POST['username']);
$check_abfrage = "SELECT id, username, passwort, aktiv, lastvisit, cookie_modus, cookie_zufall, pw_update FROM $userdb WHERE username = '$username'";

> > Das dagegen ist schon ein sehr böser Fehler  
> Durch das simulieren von magic\_quotes\_gpc(); sofern es auf Off steht, ist es nicht möglich (afaik), diese Abfrage zu manipulieren.  
  
Du sollst nicht magic\_quotes\_gpc() simulieren, ganz im Gegenteil. magic\_quotes\_gpc() sollte sogar wenn möglich AUSGESCHALTET sein, und wenn es eingeschaltet ist, sollten die Eingaben in den superglobalen Variablen \_GET, \_POST und \_COOKIE mit stripslashes() zurückgewandelt werden.  
  
Zur Behandlung von potentiell "bösem" Code zur Verwendung in MySQL-DB-Abfragen existiert mysql\_escape\_string() und mysql\_real\_escape\_string(). Diese Funktion macht nur \_scheinbar\_ das Gleiche, wie addslashes(), tatsächlich aber sorgt sie GARANTIERT dafür, dass alle für MySQL bösen Zeichen escapet werden - und das sind mehr, als addslashes() behandelt.  
  

> Bei der Entwicklung wurde auch auf die Sicherheit geachtet.  
  
Kann ja nicht sein, wenn du mysql\_escape\_string() nicht in deinen SQL-Abfragen benutzt.  
  
 - Sven Rautenberg

-- 
My sssignature, my preciousssss!

[Andavos]

Hallo,

durch was besticht es denn?
  durch das hier?

Danke für den Hinweis, allerdings sind das eher "unwichtige" Fehlermeldungen.

Schau dir mal z.B. diese Fehlermeldungen an:

Warning  Line 123 column 141: cannot generate system identifier for general entity "PHPSESSID".
<a href="member.php?was=list&PHPSESSID=284a ...

Ich habe hier ein & anstatt &amp benutzt, aber das ist doch eigentlich kein Problem für moderne Browser (oder doch?).

Aber ich weiß jetzt was ich in den nächsten Versionen noch verbessern muss.

MFG
Andavos