PHP EF 1011 // Anzahl nicht zulässig

[MiD]

Hi,

ich habe eine Funktion geschrieben, die die Lose einzieht

function sendLose($klammid, $losepw, $anzahl, $betreff)
{
	global $ef_id, $ef_pw, $ef_kennung, $fehler;
	$check = @file("https://www.klamm.de/engine/lose/get.php?ef_id=$ef_id&ef_pw=$ef_pw&k=$ef_kennung&k_id=$klammid&l_pw=$losepw&s=$betreff&n=$anzahl");
	$return = split("[|]",$check[0],9);
	
	switch($return[0])
	{
		case 1001 : $fehler = ""; break;
		case 1002 : $fehler = "EF-Account existiert nicht."; break;
               //...Weitere Abfragen
	}
	return $fehler;
}

Diese Funktion rufe ich auf

sendLose($_POST["benutzername1"], $_POST["passwort1"], $_SESSION["anzahl"], "Betreff");

Doch mir wird folgender Fehler ausgegeben

Anzahl nicht zulässig.

Ich habe kontrolliert, ob die $_SESSION["anzahl"] auch den Wert erhält und das tut sie.
Doch wo habe ich den Fehler?

Ich hoffe, ihr könnt mir helfen.
Gruß

 

[Benutzer-2472]

Du speicherst in der Session-Var die Losemenge?

Gibt doch einfach mal den Inhalt aus und schau was da drin steht bzw. prüf deine Variablen im formbereich ob das überhaupt dir richtige ist, $_SESSION sieht sehr merkwürdig aus.

 

[theHacker]

Keiner der Parameter ist encodet. Das führt sehr wahrscheinlich zu Fehlern und kann u.A. zu dem hier beschriebenen Fehlercode führen.
Programmiert halt mal ordentlich, dann passiert sowas nicht

P.S. Mit ner Klasse kann man sich das böse global sparen.

 

[MiD]

Du speicherst in der Session-Var die Losemenge?

Deine Augen machen mich stutzig. Gibt es da ein Sicherheitsproblem, wenn ein User lediglich eine Losemenge in einem Formbereich eintippt? Ich habe das mit Session gelöst, sodass ich im übernächsten Schritt nochmal darauf zurück greifen kann.

Gibt doch einfach mal den Inhalt aus und schau was da drin steht bzw. prüf deine Variablen im formbereich ob das überhaupt dir richtige ist, $_SESSION sieht sehr merkwürdig aus.

Wird alles richtig übertragen und es spielt bei ihm keine Rolle ob ich 100 oder 1000 Lose transferieren möchte.

Keiner der Parameter ist encodet. Das führt sehr wahrscheinlich zu Fehlern und kann u.A. zu dem hier beschriebenen Fehlercode führen.

Ist das ausschlaggebend für eine Zahl?

Programmiert halt mal ordentlich, dann passiert sowas nicht

Bisher habe ich noch kein Code gesehen (bzw. nicht bewusst wahr genommen), dass jemand encodet. Hast du dafür zufällig irgendein Bericht, wo ich mich mit der Materie mal einlesen kann

P.S. Mit ner Klasse kann man sich das böse global sparen.

Werde ich mich drum kümmern

 

[DaPhreak]

Bisher habe ich noch kein Code gesehen (bzw. nicht bewusst wahr genommen), dass jemand encodet. Hast du dafür zufällig irgendein Bericht, wo ich mich mit der Materie mal einlesen kann

All input data is evil!

(Der Artikel geht zwar um ASP, aber der Satz selbst sagt eigentlich schon alles....)


*edit* Auch zur Lektüre empfohlen: Michael Howard's Secure Habits.

 

[MiD]

Ich habe jetzt urlencode() verwendet. Ich hoffe, so encode ich dies korrekt zumindestens ist die Beschreibung im Handbuch einleuchtend.
Encoden, werde ich ab sofort alles. Aber dies hat leider nicht meinen Fehler "Anzahl ist nicht zulässig" behoben

 

[theHacker]

Bisher habe ich noch kein Code gesehen (bzw. nicht bewusst wahr genommen), dass jemand encodet. Hast du dafür zufällig irgendein Bericht, wo ich mich mit der Materie mal einlesen kann

Nur, weil jeder es falsch macht und irgendwann aufs Maul fliegt, musst du es ja nicht nachmachen Programmierung, die man hier im klamm-Forum findet, ist zu 99,99% nicht zu empfehlen, sich diese als Beispiel zu nehmen.

Ist das ausschlaggebend für eine Zahl?

Es ist keine Zahl, sondern ein String - zumindest beim Zusammensetzen der URL.
Was is wohl, wenn als Betreff "&n=42.4711Test" verwendet wird?

Is aber hier egal. Usereingaben sind böse! Immer! Grundsätzlich! Und ohne Ausnahme! Und du als Programmierer läufst immer Gefahr, dass was schief geht (von komischem Verhalten, über unseriöse Fehlermeldungen für den Benutzer sichtbar, über zu Abstürzen und Sicherheitsproblemen, bis hin zur Übernahme ganzer Server und überspitzt dem Gefängnisaufenthalt, weil über deinen Server 9stellige Anzahl an Spam-Mails versandt worden sind). Deshalb hast du jede Eingabe von außen zu prüfen.

Wegen der Session: Is zwar nicht bedenklich, wenn sonst alles ok is, aber für die meisten Zwecke scheint es irgendwie falsch zu sein. Erhebt du die Losemenge nicht auf der Unterseite, die das hier diskutierte Script ausführt? Falls nein, warum?

 

[MiD]

Wegen der Session: Is zwar nicht bedenklich, wenn sonst alles ok is, aber für die meisten Zwecke scheint es irgendwie falsch zu sein. Erhebt du die Losemenge nicht auf der Unterseite, die das hier diskutierte Script ausführt? Falls nein, warum?

Welche Unterseite? Den Teil verstehe ich nicht ganz von deinem Post, ich stehe irgendwie auf dem Schlauch
Es gibt 3 Schritte:

1. Eingabe der Losemenge
2. Eingabe der Userdaten (KlammID, Losepasswort)
3. Einzahlung der Losemenge

Und im 2. Schritt speichere ich die Losemenge als Session ab, um im 3. Schritt darauf nochmal zugreifen zu können.

 

[DaPhreak]

Eine Alternative wäre es, das Ergebnis aus Schritt 1 in dem Form für Schritt 2 als verstecktes Formfeld abzulegen (<input type="hidden">), so brauchst Du die Session nicht.

Validieren musst Du die eingegebenen Daten natürlich trotzdem.

 

[MiD]

Ich habe doch nichts zu verbergen
Vielen Dank für all eure Hilfe. Ich habe so gerade eben einfach aus Frust das "&n=465" vor das "&s=betreff" getan und es hat funktioniert. Aber wieso spielt die Reihenfolge eine so wichtige Rolle?

 

[Biehler]

Lass dir doch mal den GET String ausgeben und kopiere den String manuell in den Browser, was dann passiert.

Du könntest auch mal die Reihenfolge der GET Variablen ändern
Hat den Sinn, dass, wenn (aus welchem Grund auch immer) der GET String durch ein nicht encodetes Leerzeichen getrennt ist, die Abfrage nen Fehler produziert.
Wäre dies der Fall ergäben sich andere Fehlermeldungen bei vertauschten Parametern.

//Edit
Zu Spät

Wird der Betreff denn korrekt angezeigt im Transfer?

 

[MiD]

Wird der Betreff denn korrekt angezeigt im Transfer?

Und das fällt mir jetzt auf: Nein
Eigentlich sollte er: "ABC ist das Alphabet" ausgeben, doch gibt er nur "ABC" aus.

 

[Biehler]

Wie verwendest du denn urlencode()?

//Edit:
Wenn in nem GET Parameter ein Leerzeichen drin ist, wird der Rest vom GET String abgeschnitten.
Deshalb muss der GET String in den meisten Fällen encodiert werden.

Was hier nicht geschah.

 

[MiD]

	sendLose(urlencode($_POST["benutzername2"]), urlencode($_POST["passwort2"]), urlencode($_SESSION["preis"]), urlencode("ABC ist das Alphabet"));

Edit: Hab jetzt nochmal gecheckt und es funktioniert alles einwandfrei Mein Kopf glüht anscheinend schon. Vielen Dank an alle.

 

[CrazySash]

Schau dir mal die die PHP Klasse an.

https://code.google.com/p/exportforce-class-php/

Vielleicht findest du da noch die ein oder andere Anregung