Mein Loginsystem - (Communitysystem)

Das heisst was sowas sollte ich doch so machen: "text", 6, $sdadf.. Aber wann ' '?

ja... und ob du " oder ' verwendest ist eigentlich wurst. gibt nur einen unterschied... bei " parst php den inhalt. also kannst du zb sowas wie
PHP:
$name = 'blub';
echo "hallo  $name!";
schreiben... und php würde folgendes ausgeben
PHP:
hallo blub!
wohingegen
PHP:
echo 'hallo $name!';
zu dem ergebniss führen würde
PHP:
hallo $name!
um die selbe ausgabe zu erreichen müsstest du das ganze so machen
PHP:
echo 'hallo '.$name.'!';

zb ich arbeite hauptsächlich mit '... die einzige stelle wo ich bewusst " verwende sind eigentlich sql queries. und manchmal bei solchen bsp aus faulheit "... ist aber eher selten.
 
Aso, ok dann habe ich das verstanden.. Und TheHacker hat immernoch nicht geantwortet und Actionscripter auch nicht.. HUH;)
 
Was ich in meiner neusten Version alles verbessern kann:

du sorry, aber ich hab im moment keine zeit, mir das näher anzusehen. ich lads mir mal runter und schau es mir an, wenn ich zeit dazu finde.

auf den ersten blick vielleicht ein paar worte:

1. die mysql-tabelle ist noch immer nicht optimiert und hat z.b. felder vom typ "text", wo varchar ausreicht
2. meta-tags (auch refreshs) haben nichts im body zu suchen. wenn die weiterleitung im body gemacht werden muss, dann per javascript. ansonsten erst prüfen, dann seite generieren, dann kannst du den tag auch in den head schreiben, wo er hin gehört.
3. das bringt mich zu m nächsten punkt: design und content trennen. du schreibst alle ausgaben direkt im quelltext. das mag soweit funktionieren ist aber grausam, wenn man mal ein anderes design benutzen will oder globale änderungen (farben, tabellenköpfe etc.) vornehmen muss. ein griff und das suchen beginnt...
4. alle mysql-abfragen enden mit die() ... das ist zum debuggen ganz nett, aber in der final-version solltest du fehler abfangen und entweder ins log schreiben oder dir ausgeben lassen oder per mail an dich schicken.
5. pass auf, dass du nicht zu viele files includest. jedes include ist mind. 2 filezugriffe (suchen, öffnen)
6. formularfelder vor dem absenden checken! im php musst du natürlich die sachen auch noch einmal prüfen, aber wenigstens die prüfung auf leere felder bzw. benötigte felder solltest du bereits im formular vornehmen...

soweit, was ich auf den ersten blick gesehen habe, ohne mir das erst zu installieren...
 
1. die mysql-tabelle ist noch immer nicht optimiert und hat z.b. felder vom typ "text", wo varchar ausreicht
Gemacht, ich hoffe das ist jetzt ok..
2. meta-tags (auch refreshs) haben nichts im body zu suchen. wenn die weiterleitung im body gemacht werden muss, dann per javascript. ansonsten erst prüfen, dann seite generieren, dann kannst du den tag auch in den head schreiben, wo er hin gehört.
ist nun javascripte
3. das bringt mich zu m nächsten punkt: design und content trennen. du schreibst alle ausgaben direkt im quelltext. das mag soweit funktionieren ist aber grausam, wenn man mal ein anderes design benutzen will oder globale änderungen (farben, tabellenköpfe etc.) vornehmen muss. ein griff und das suchen beginnt...
Wie denn? Wenn du jetzt sagst TemplateSys, dann mach ich das doch am sinnvollsten am ende. Oder?
4. alle mysql-abfragen enden mit die() ... das ist zum debuggen ganz nett, aber in der final-version solltest du fehler abfangen und entweder ins log schreiben oder dir ausgeben lassen oder per mail an dich schicken.
Werde ich am Ende einfach mit einem speicher Mechanissmuss versehen..
5. pass auf, dass du nicht zu viele files includest. jedes include ist mind. 2 filezugriffe (suchen, öffnen)
Ist nun reduziert..
6. formularfelder vor dem absenden checken! im php musst du natürlich die sachen auch noch einmal prüfen, aber wenigstens die prüfung auf leere felder bzw. benötigte felder solltest du bereits im formular vornehmen...
Erledigt..

Neue Version: [HIER]
 
Wie denn? Wenn du jetzt sagst TemplateSys, dann mach ich das doch am sinnvollsten am ende. Oder?

Ein Templatesystem solltest du wenn dann von Anfang an integrieren (Schon alleine wegen der Variablenzuweisung).

Allerdings kannst du auch einfach ein PHP-Template verwenden, da Templatesysteme wie Smarty mit einer Menge overhead meiner Meinung nach einfach nichts sind (ich setze es aus Gewohnheit trotzdem noch selber ein ...) Interessant zu Templatesystemen: Link 1 Link 2
 
Also was hab ich denn noch für Möglichkeiten ein Design da rein zubekommen..
Also TempSys ist nix, finde ich..

EDIT: Neue Version, [HIER] jetzt kann man vergessene PWs wiederherstellen (puh das hatte mich erst fast aus dem konzept gebracht) und das Profil mit PW ändern..
 
Zuletzt bearbeitet:
EDIT: Neue Version, [HIER] jetzt kann man vergessene PWs wiederherstellen (puh das hatte mich erst fast aus dem konzept gebracht) und das Profil mit PW ändern..

Wieso verwendest du manchmal echo 'foo' . $foo und manchaml echo "foo $foo" ?
In der user_list.php wird auf den ersten Blick $page_max nicht geprüft (woher kommt das überhaupt?), was zu einer SQL-Injection führen kann und '2' sollte man als 2 schreiben.

Gruß
 
Wieso verwendest du manchmal echo 'foo' . $foo und manchaml echo "foo $foo" ?
In der user_list.php wird auf den ersten Blick $page_max nicht geprüft (woher kommt das überhaupt?), was zu einer SQL-Injection führen kann und '2' sollte man als 2 schreiben.

Gruß
Weiß auch nicht warum gemixt..
Also $page_max ist auf der Config: $page_max = 4; (da bekomme ich sicher keine injekts..
Ja das mim '' hab ich übersehen..
 
Ok nochmal was erneuert.. Ein PN system (ja fehelen noch ein paar funktionen, aber die kommen noch..) und die Userlist wurde verbessert..
:biggrin:
Ja und kleine fehler generell:
[HIER]
 
Ok nochmal was erneuert.. Ein PN system (ja fehelen noch ein paar funktionen, aber die kommen noch..) und die Userlist wurde verbessert..
:biggrin:
Ja und kleine fehler generell:
[HIER]

:arrow: mysql_real_escape_string() verwenden
:arrow: Besser gleich beim Eintragen vor HTML-Injection o.ä. schützen - was in der Datenbank nicht dreckig ist, muss man beim Ausgeben nicht erst säubern
:arrow: Im PN-System keinen Eintrag für jeden beliebigen Empfänger in die DB vornehmen
:arrow: time() liefert keinen String zurück

Vielleicht merkst du es selber, aber bei mehreren if und else und zwischen drin wieder einiges an spezifischem Code, fängt es an unübersichtlich zu werden.
 
du musst schon sagen was du willst ;) wenn du jetzt wissen willst ob das so sinnvoll ist nein... die datentypen sind großteils fehl am platz.

`nickname` text <- wie lang sollen die nicknames werden? bin der meinung varchar(20) sollte reichen
`passwort` varchar(32) <- speicherst du die passwörter als hash ab? [...]


Dann prüfe bitte auch sämtliche Eingaben auf ihre Länge, bevor du sie abarbeiten lässt, ansonsten ist das nämlich mein Spezialgebiet, Bufferoverflow Angriffe.

Also schön defensiv programmieren, abfragen ob die Kette innerhalb der Toleranzvorgaben ist.
 
Dann prüfe bitte auch sämtliche Eingaben auf ihre Länge, bevor du sie abarbeiten lässt, ansonsten ist das nämlich mein Spezialgebiet, Bufferoverflow Angriffe.

Also schön defensiv programmieren, abfragen ob der die Kette innerhalb der Toleranzvorgaben ist.

Hmm,

Wenn ich in einer Tabelle mit varchar(10) einen String mit 30 Zeichen zum Abspeichern übergebe, wird der Rest einfach abgeschnitten und fertig.

Oder redest du gerade von Bufferoverflows seitens PHP (Was ja u.U. auch möglich sein könnte)?
 
Hmm,

Wenn ich in einer Tabelle mit varchar(10) einen String mit 30 Zeichen zum Abspeichern übergebe, wird der Rest einfach abgeschnitten und fertig.

Oder redest du gerade von Bufferoverflows seitens PHP (Was ja u.U. auch möglich sein könnte)?

Ich bin beim Verarbeiten der Daten per php, das kommt ja zuerst, wenn ich richtig informiert bin, speichert man erst die Daten zwischen um sie dann geschlossen in die DB zu speichern - oder ist das schon wieder aus der "Mode"?
 
Wenn ich in einer Tabelle mit varchar(10) einen String mit 30 Zeichen zum Abspeichern übergebe, wird der Rest einfach abgeschnitten und fertig.
Kommt auf den DB-Server und seine Konfiguration an ;) (Stichwort: MySQL5 und Strict-Mode)

So, ich hab nur wieder mal ganz kurz hingesehen und auch nicht besonders viel gefunden. Das liegt aber wohl nur an diesem unkonfortablen Editor, den ich hier an der Uni hab :biggrin:

Ein grundliegenden "Fehler", den hier wohl jeder macht, der zwar nicht toedlich ist, aber trotzdem Probleme bereiten kann, moechte ich hier einmal aufzeigen:

reg.php - Zeile 52:
PHP:
$sql = mysql_query($query) or die(mysql_error()) or die(mysql_error());
Warum wird hier gleich doppelt mit or die() gearbeitet ? :hö:

Ich beantworte das mal: Das Problem ist Copy&Paste. Und das ist zurueckzufuehren auf den ungewoehnlichen Aufbau des Scripts.

Um nicht komplett in Raetseln zu sprechen, moechte ich dir, php, eine kleine Aufgabe stellen :mrgreen: 8)
Sie werden weitergeleitet. Wenn dies nicht geschieht, klicken Sie hier.
Das hier ist dein Weiterleitungstext. Wie man sieht, hast du darin zwei kleine Zeichensetzungsfehler drinnen, die ich oben korrigiert hab.

Besser den Fehler im Script aus und dann berichte mir, was denn das Problem ist, was ich angesprochen hab ;)
 
Ich bin beim Verarbeiten der Daten per php, das kommt ja zuerst, wenn ich richtig informiert bin, speichert man erst die Daten zwischen um sie dann geschlossen in die DB zu speichern - oder ist das schon wieder aus der "Mode"?

Nein, ist nicht unbedingt aus der Mode ;)

Allerdings bestimmt PHP doch für mich, welchen Datentyp und welche Länge ich jetzt brauche, wo ist da dann das Problem (wenn dies seitens PHP richtig umgesetzt wurde)?

Gruß
 
Nein, ist nicht unbedingt aus der Mode ;)

Allerdings bestimmt PHP doch für mich, welchen Datentyp und welche Länge ich jetzt brauche, wo ist da dann das Problem (wenn dies seitens PHP richtig umgesetzt wurde)?
Gruß

Das Problem liegt darin, sagen wir du prüfst es an einer Stelle nicht, dann kann an der Stelle Fremdcode eingespeist werden.

Beispiel: (pseudocode)

Var a = eingegebener Text
Usereingabe = Steuerungszeichen zur Ausgabe von z.b. Stackdaten.

Im "angenehmsten" Fall stürzt nur die Anwendung ab.

Daher immer prüfen, ob die Variable begrenzt wird (beim eingeben) und dann beim Übergeben halt abfragen.

Gutes Beispiel sind z.B. Integerwerte

mit 3432213 geht alles gut, bei 9*10²² hast du ein Problem.
 
Das Problem liegt darin, sagen wir du prüfst es an einer Stelle nicht, dann kann an der Stelle Fremdcode eingespeist werden.

Das ist mir prinzipiell schon von C klar, allerdings habe ich dabei mit der Übertragung auf PHP Schwierigkeiten, solange im PHP-Quellcode keine Bugs in der Typisierung drin sind.

Beispiel: (pseudocode)

Var a = eingegebener Text
Usereingabe = Steuerungszeichen zur Ausgabe von z.b. Stackdaten.

Im "angenehmsten" Fall stürzt nur die Anwendung ab.

Daher immer prüfen, ob die Variable begrenzt wird (beim eingeben) und dann beim Übergeben halt abfragen.

Gutes Beispiel sind z.B. Integerwerte
mit 3432213 geht alles gut, bei 9*10²² hast du ein Problem.

Prinzipiell von der Größe des Integer-Datentyps schon - allerdings:

PHP:
<?php

// Overflow-test.php

$int1 = 454531;
$int2 = 90000000000000000000000;

echo $int1 . '<br />';
echo $int2;

?>

Ausgabe:
Code:
454531
9E+022

Das müsste ja heißen, das PHP prinzipiell mit solch großen Zahlen (wahrscheinlich durch ein internes Workaround) kein bufferoverflow-technisches Problem hat.

Bitte um etwas nähere Ausführungen :)

btw: sry 4 OT!