[Erledigt] "Typecasting"

Hi.

Habe ein "kleines" und wahrscheinlich untypisches PHP-Problem, aber vielleicht hat ja jemand von euch schon mal was ähnliches gelöst.

Ich möchte vor dem Ablegen von Daten in der Datenbank prüfen, ob diese auch dem erforderlichen Datentyp entsprechen.

Aus diesem Grund muss ich also herausfinden, welchen Datentyp der übergebene Wert besitzt, nur leider ist das - im vergleich zu anderen Sprachen - gar nicht so einfach.

Hatte mehrere Ansätze, die aber alle nicht so 100% "sauber" waren:

1) prüfen mit den is_*()-Funktionen:

Funktioniert super, allerdings wenn die Werte einmal über $_POST kommen sollten, stehen intern auch alle übergebenen Integer auf String

2) mittels settype() umwandeln:

Naja, hier waren die Ergebnisse auch sehr überraschend, da die Funktion nämlich Strings auch in Int umwandelt ?!?

3) mittels preg_match() nach Zahllen suchen:

Die einzige Methode die vernünftig funktioniert, allerdings meiner Meinung nach für mein Problem einen kleinen "Overkill" bedeutet.


Also nochmals meine Frage:

Hat jemand von euch etwas änliches schon einmal gelöst? Bin auch für "Denkanstösse" sehr dankbar.

Gruß

Chris

[lazydog]

UPADATE:jetzt gehts auch mit double

Und sogar mit der "Zahl" "4.5.6.2". Aber selbst Werte wir "ghjhjghjg" sind eine Zahl (weil der Punkt für jedes Zeichen steht. Für Integer-Werte müsstest du deinen Code in

ereg("^[[:digit:]]+$", $variable, $regs)

ändern. Für float- oder doubel-Werte wirds etwas komplizierter.

ereg("^[[:digit:]]*\.?[[:digit:]]*$", $variable, $regs)

funktioniert zwar, gibt aber leider auch bei einem einzelnen Punkt TRUE zurück. Der folgende Ausdruck sollte die Möglichkeiten abdecken:

ereg("^([[:digit:]]*\.?[[:digit:]]+$|^[[:digit:]]+$)", $variable, $regs)

Die Bedingung ist, falls ein Dezimalpunkt vorhanden ist, muss mindestens eine Stelle folgen

[Waq]

Wenn ich dann also nochmals deinen Code laufen lasse, bekomme ich für is_string() ein true, weil PHP es intern einfach so interpretiert

Das ist richtig. PHP-intern sind das alles Strings, und die meisten aufgeführten Funktionen wie is_int() oder is_string() beschäftigen sich nur mit diesen PHP-internen Typen, doch die sind hier reichlich irrelevant.

is_numeric() prüft nicht (nur) den Typ der Variable, sondern den Inhalt, und ist deswegen hier richtig.

[Waq]

Klarstellung

Soll also heißen, dass es seltsamerweise im $_POST-Array alle übergebenen Datentypen als String interpretiert werden. Also selbst wenn nur eine "1" oder eben die "123.4" übergeben würden.

Das liegt nicht an PHP. Das Formular im Browser kennt keine Variablentypen, gewöhnliche HTML-Formulare kennen nur Strings, und der Browser schickt nur Strings an PHP.
Dass in dem String nur Zahlen drin stehen hat PHP hier nicht zu interpretieren, dazu ist der Programmierer da, und dem wird mit is_numeric() ein wunderbares Hilfsmittel zur Verfügung gestellt (braucht höchstens Hilfe bei "," und ".").

Ändern wird sich das mit XForms, die kennen nämlich Typen, aber bis die sich durchsetzen dauert es noch ne Weile... PHP kommt aber AFAIK schon damit zurecht.

PHP Typecasting

Hallo,

ich habe das Problem mit Unverträglichkeiten bei Datentypen auch manchmal. Z.B. wenn man per GET Werte bekommt, werden diese in Variablen eingelesen vom Interpreter immer erst als String behandelt. Braucht man einen GET-Wert in einer Funktion aber explizit als Integer, kann das so aussehen:

$get_wert = $_GET["wert"];
$wert = (int) $get_wert;

Und schon hat man einen Integerwert, vorausgesetzt, der mit GET gelieferte Wert besteht nur aus Ziffern und eventuellem Trennzeichen für Kommazahlen.

Ich hoffe, damit geholfen zu haben. :wink:

versuchs mal mit:

ereg("([[:digit:]]|,|.){".strlen($variable)."}", $variable, $regs)

ergibt false wenn keine Zahl, ansonsten ist das result strlen($variable)! (UPADATE:jetzt gehts auch mit double)

Hi.

Ne, leider nicht - ist hier genau die selbe "Kleinigkeit" die ich oben beschreibe:

"123hallo" wird zu (int)123 - und nicht wie ich das eigentlich gerne hätte zu 0 / False.

Gruß

Chris

zu dem tertiären Operator:
tuts nicht auch:

intval($var);

da wird eigentlich dasselbe gemacht, oder

Hi meikel.

Muss mich bei dir entschuldigen, vor lauter "seltsamer" Beiträge habe ich deinen sinnvollen dann ganz überlesen.

Kann mich nun wenigstens rausreden, dass du dann unter den restlichen 10% warst

Werde das mal testen - hört sich interessant an. Was hältst du von meiner Methode? Kritik?

Weil eigenltich mach ich in meiner Methode was sehr ähnliches wie du beschreibst, nur verwende ich die settype()-Funktion.

Denn momentan finde ich dass bei meiner jetzigen Version dein Beispiel "123abc" nämlich auch zu null und nicht - wie bei dir - zu "123" wird.
Allerdings bin ich mir mit der Zuverlässigkeit meiner Methode auch noch nicht zu 100% sicher. Werde mir mal anschauen, ob man die beiden Modelle vielleicht kombinieren kann.

Gruß

Chris

PS: Habe deine Links noch nicht ganz durchgelesen, werde dass aber morgen nachholen!

Irgendwie bekomm ich gerade zu 90% Antworten zu Fragen die ich gar nicht gestellt habe, bzw. die mich gar nicht wirklich interessieren.

Ich hatte Dir folgenden Link gegeben
12.1. Wie unterscheide ich böse Variablen von guten?
http://www.dclp-faq.de/q/q-security-variablen.html

in dem ua. folgendes zu lesen ist:

3. Variablen, die eine numerische Form haben müssen.
Numerische Variablen können durch eine einfache Konvertierung erzwungen werden. Danach muss eine Überpruefung des Wertebereiches erfolgen:

$checkedvar = isset($_GET["numericvar"]) ? $_GET["numericvar"]+0 : 0;
Durch die Addition von 0 wird eine Konvertierung auf Integer erzwungen. Der Wert ist hinterher entweder Wert des numerischen Prefix von $_GET["numericvar"] oder 0. "123abc" wird also zu 123, "fasel" zu 0. Ein fehlender Wert wird durch das isset() ebenfalls zu 0.

Was hatte Dir daran nicht gefallen?

Hi.

Irgendwie bekomm ich gerade zu 90% Antworten zu Fragen die ich gar nicht gestellt habe, bzw. die mich gar nicht wirklich interessieren.

Habs jetzt momentan so gelöst, und nach meinen ersten Tests funktionierts es auch. Nur hätte ich nun nochmals die Frage an euch, ob es bei dem Code vielleicht doch eine "Schwachstelle" gibt die Ihr sofort erkennt oder ob es ok ist ?!?

Hier also mein momentaner Code für INT und DOUBLE-Werte

// In Deutschland und anderen Ländern wird für den Datentyp Float
				// oft das Komma als Trennzeichen verwendet, welches allerdings nicht
				// SQL-Konform ist -> umwandeln in einen Punkt
				$data["$feld"] = str_replace(",",".",$data["$feld"]);
				
				
				if (!$data["$feld"] || $data["$feld"] == '') {
					$sql .= '`'.$feld.'`=\'\', ';
				}
				// Da die nächste Funktion settype() beim Casten von Strings in
				// Int als Rückgabe "0" liefert, muss INT-Wert 0 hier als
				// zusätzliche Weiche vorhanden sein
				elseif ($data["$feld"] == 0) {
					$sql .= '`'.$feld.'`=\'0\', ';
				}
				// Datentyp ist Double bzw. Float, falls ein Punkt existiert
				elseif (settype($data["$feld"],'double') && ereg('\.',$data["$feld"])) {

  // DIVERSER CODE

}
				elseif (settype($data["$feld"],'double')) {

// DIVERSER CODE

}

Gruß

Chris

[MrMarco]

@LaLop:

Ich verstehe auch nicht, warum einige Scriptkiddis meinen sowas machen zu müssen. Ehrlich nicht... Bin wohl zu alt dafür

Wenn ich wirklich sicher gehen will, dann benutze ich das SSL-Zertifikat was für meinen Server gekauft wurde. Logischerweise habe ich Sicherheitsfunktionen, die das ganze noch mehr schützen, auch ohne SSL.

Aber ein Beispiel für deinen Fall kann ich dir nicht liefern. Dafür müßte ich mich in deine Anwendung reinknien, prüfen ob es Sinn machen würde und was ich für Vorteile daraus habe. Aber so ein Typ bin ich nicht

Wir sind jetzt auch (teilweise durch meine Schuld) so stark vom Thema abgekommen, das wir das langsam splitten sollten.

Was ich bezüglich deiner Frage vermute, ist das es Unterschiede zwischen GET und POST gibt, welche über den Kommunikationsweg hinaus vorhanden sind.

Probiere doch mal die Daten auf beiden Wegen zu übertragen und dann deine Prüfungen auszuführen.

Hmmm... ich hatte die Tage eine Seite gesehen, wo ein Source mit Doku und Beispielen dabei war, wie man einen Client mittels PHP nachbauen kann.
Das ganze benötigte für den User nur wenige Zeilen. AFAIk 5 oder 6 Zeilen waren es und schon hatte man alles, um Unfug bauen zu können.

Natürlich!! PHP beherrscht alles, um TCP/IP-Programme zu "emulieren", sind ja auch nur Zeichen und Regeln die man beachten muss!
Nun, aber was kann man damit erreichen? Könnte mir mal jmd ein ECHT praxisnahes Beispiel geben, wie man durch spoofing IRGENDWAS erreichen kann?
Sorry, also wenn eine Falscheingabe in einer MySQL-DB ein derart schweres Sicherheitsproblem darstellt, dann liegts eindeutig am ganzen Konzept der Anwendung!
Wie gesagt, ich bitte um ein praxisnahes Beispiel, wo der "Hacker" einen Nutzen durch Manipulation hat, und zwar im Hinblick auf das hier dargestellt Szenario, das interessiert mich wirklich ernsthaft!

Und das Thema SQL-Injections... hach je... besonderst bei Browsergames gibt es immer wieder Spielkinder... im Moment protokoliere ich von ein paar Usern jede Aktion mit. Wenn ich mal Zeit habe, werde ich das ganze Analysieren und Gegenmaßnahmen ergreifen. Ihr glaubt gar nicht, wie kreativ manche User sein können.

Browsergames... LOL... das war zufälligerweise auch mein erster Gedanke, als ich an Manipulation gedacht hatte, und das sind vermutlich auch die Haupt"angriffsziele" für solche Aktionen
Aber in meinen Augen nicht sicherheitsrelevant - vllt reden wir hier aneinander vorbei!? )

Also ich habe auch ziemlich zu Anfang meiner PHP-Zeit eine Highscore-Funktion (PHP/MySQL) geschrieben, die müsste nun mittlerweile 5 Jahre laufen... und soweit ich weiss, hat dort NIEMALS jemand es versucht, oder es geschafft die Tabelle zu manipulieren...

Ojeee, da können wir uns vermutlich noch tagelang drüber unterhalten

Greetz,
LaLop

[MrMarco]

Hmmm... ich hatte die Tage eine Seite gesehen, wo ein Source mit Doku und Beispielen dabei war, wie man einen Client mittels PHP nachbauen kann.

Das ganze benötigte für den User nur wenige Zeilen. AFAIk 5 oder 6 Zeilen waren es und schon hatte man alles, um Unfug bauen zu können.

Und das Thema SQL-Injections... hach je... besonderst bei Browsergames gibt es immer wieder Spielkinder... im Moment protokoliere ich von ein paar Usern jede Aktion mit. Wenn ich mal Zeit habe, werde ich das ganze Analysieren und Gegenmaßnahmen ergreifen. Ihr glaubt gar nicht, wie kreativ manche User sein können.

Nein, ich denke was DU (meikel) meinst ist, man sollte vorsichtig sein beim WOHER die Daten stammen. Zugegeben, GET und HIDDEN-Variablen sind eindeutig fälschbar, es sei denn, man checkt auf der Auswertungseite den REFERER!!

Auch der Referer stammt vom Client