Mit VMS1 26 Milliarden Lose aus dem Nichts..

[Gothicman1]

Hallo,

also ich weiss das es wohl am Besuchertausch von dude32 liegt. Dort kann man wohl beliebig Punkte in Lose tauschen..mehr kann ich dazu noch nicht sagen weiss bloss aus dem access.log das es über den Besuchertausch passiert ist.

[marcaust]

Ich hab mir die Datei bei Losekeller mal angesehen und dabei bemerkt das die Funktion: buchungsliste nicht korrekt ausgeführt wird und zum Abbruch des Scripts führt. Dadurch erklärt sich auch ds in den Buchungen kein Buchungstext vorhanden ist.

Abhilfe:
Die 2 Vorhandenen Zeilen die die Funktion: buchungsliste aufrufen entsprechend berichtigen.

Das Problem liegt bei:
...id,'+'.$kosten.' (BeTauPunkteVerkauf)',$schnittste.... wo aus dem +, $kosten und (BeTauPunkteVerkauf) dann ein +100(BeTauPunkteVerkauf) wird. Also ein text wo eine Zahl erwartet wird.
Das kann nicht gehen da an der Stelle eine Zahl erwartet wird.

Eine korrektur nach:
_id,'-'.$kosten, '(BeTauPunkteVerkauf)'

sollte das Problem beheben. (Vergesst nicht das Vorzeichen (+ und - entsprechend an den Stellen zu setzen)

[marcaust]

Original von ztk-hosting
ich würde einfach mal alle db_querys und mysql_querys prüfen. Alle Angaben aus Variablen mal mit mysql_real_escape_string bearbeiten.

Falls jemand Probleme hat... Sollte jemand das VMS2 benutzen habe ich eine Modifikation der Klassen-Datei parat... nicht von unabhängigen Usern erprobt.

www.php.net/mysql_real_escape_string

Was mich daran stört ist das in den Beispielen da alles mit sprintf Formatiert wird.
Das find ich kompliziert und unleselich.

Würde das auch gehen wenn man die bsiherige schreibweise in dem Script beibehält?

[Benutzer1699]

Natürlich ginge das auch, wers mag

xyz_query("UPDATE wicht SET kontostand='". mysql_real_escape_string($_GET['wiesoauchimmer']) ."' WHERE xyz");

Ich finde die %-Schreibweise übersichtlicher da Fehler im SQL-Syntax so sehr schnell zu erkennen sind.

[VMS1]

Hallo,
ich weiß nicht ob es derselbe Bug ist, aber es hört sich ganz danach an. Das Problem ist wenn man eine Kommazahl mit Komma statt Punkt eingibt, dann werden zwar die Lose gutgeschrieben, aber keine Punkte abgezogen. Bei manchen ist das gefixt, bei manchen nicht. Eigentlich ist dieser Bug aber altbekannt.
Trotzdem dickes PFUI! wer das ausnutzt!

Das hier sollte Abhilfe schaffen:

if (ereg("[^0-9]", $HIER_NAME_DES_EINGABEFELDS)) $error .= 'Der Betrag muß aus ganzen Zahlen bestehen!<br>';

Und dann vor der Kontobuchung:

if (!$error) {
kontobuchung.....
} else {
echo ''.$error.'';

So in der Art. Den genauen Inhalt der Datei kenn ich leider nicht, sonst wär´s ein wenig ausführlicher.

Gruß
Marco

[Gnarf]

vorsicht auch beim sparbuchaddon von Shandra wenn du das drin hast...

[marcaust]

Original von VMS1
Hallo,
ich weiß nicht ob es derselbe Bug ist, aber es hört sich ganz danach an. Das Problem ist wenn man eine Kommazahl mit Komma statt Punkt eingibt, dann werden zwar die Lose gutgeschrieben, aber keine Punkte abgezogen. Bei manchen ist das gefixt, bei manchen nicht. Eigentlich ist dieser Bug aber altbekannt.
Trotzdem dickes PFUI! wer das ausnutzt!

Das hier sollte Abhilfe schaffen:

if (ereg("[^0-9]", $HIER_NAME_DES_EINGABEFELDS)) $error .= 'Der Betrag muß aus ganzen Zahlen bestehen!<br>';

Und dann vor der Kontobuchung:

if (!$error) {
kontobuchung.....
} else {
echo ''.$error.'';

So in der Art. Den genauen Inhalt der Datei kenn ich leider nicht, sonst wär´s ein wenig ausführlicher.

Gruß
Marco

Das werd ich nachher mal testen.
Evtl. ist es Sinvoll die Funktion kontobuchung das machen zu lassen.....

Wobei sich auch die Frage stellt ob man anstelle von "ereg..." nicht besser ein is_int oder is_numeric macht. Ich denke mal das ist schneller als mit regulärer Ausdrücken zu arbeiten.

[VMS1]

Hallo.

Stimmt. is_numeric oder is_int ist etwas schneller. Allerdings erlauben diese wieder Komma-Zahlen und Vorzeichen. z.B. -0.001 wäre auch numeric. Ich glaube zwar nicht, das das noch eine Hintertür für Faker auf läßt, allerdings weiß ich bei der ereg-Lösung, das wirklich nur noch ganze Punkte getauscht werden können. Alle Eingaben außer 0-9 sind dann halt sicher Eingabefehler.

Was deinen Vorschlag mit der kontobuchung angeht: Sehr gute Idee! Evtl. sollte man mal schaun ob man das da direkt einbauen kann.
Dazu hätte ich auch noch einen Vorschlag, wobei man allerdings etwas mehr umbauen müßte: Man könnte z.B. mit mysql_affected_rows den Wert 0 oder 1 zurückgeben. So das der Rest (z.B. buchungsliste, refumsatz, Kampagne einbuchen...), nur noch ausgeführt wird, wenn tatsächlich eine Kontobuchung ausgeführt wurde. Ich werd´s mir mal anschaun.

Gruß
Marco

[marcaust]

Original von VMS1
Hallo.

Stimmt. is_numeric oder is_int ist etwas schneller. Allerdings erlauben diese wieder Komma-Zahlen und Vorzeichen. z.B. -0.001 wäre auch numeric. Ich glaube zwar nicht, das das noch eine Hintertür für Faker auf läßt, allerdings weiß ich bei der ereg-Lösung, das wirklich nur noch ganze Punkte getauscht werden können. Alle Eingaben außer 0-9 sind dann halt sicher Eingabefehler.

Was deinen Vorschlag mit der kontobuchung angeht: Sehr gute Idee! Evtl. sollte man mal schaun ob man das da direkt einbauen kann.
Dazu hätte ich auch noch einen Vorschlag, wobei man allerdings etwas mehr umbauen müßte: Man könnte z.B. mit mysql_affected_rows den Wert 0 oder 1 zurückgeben. So das der Rest (z.B. buchungsliste, refumsatz, Kampagne einbuchen...), nur noch ausgeführt wird, wenn tatsächlich eine Kontobuchung ausgeführt wurde. Ich werd´s mir mal anschaun.

Gruß
Marco

Wobei man da versuchen könnte das Ergebnis von mysql_affected_rows in den einzelnen Funktionen zu prüfen. Die Änderungen sich dann lediglich auf die funktions.php beziehen und man nicht das ganze Script abarbeiten must.

Mal sehen, wenns meine zeit zu lässt, werd ichs auch mal versuchen.