[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

Also, "die" Lösung hab ich auch nicht, aber wenn du dir mal

$test = "123.3";

echo $test.":
";
echo "String: ".is_string($test).", Länge: ".strlen($test)."
";
echo "Bool: ".is_bool($test)."
";
echo "Numeric: ".is_numeric($test)."
";
echo "Integer: ".is_integer($test)."
";
echo "Long: ".is_long($test)."
";
echo "Float: ".is_float($test)."
";
echo "Double: ".is_double($test)."
";
echo "Real: ".is_real($test)."
";
echo "Scalar: ".is_scalar($test)."
";

anschaust, wirst du sehen, dass zumindest, numeric und skalar zutreffen. Vielleicht reicht es dir, wenn is_numeric true ist und strlen <= attributslänge ist...

Hi.

Danke erst einmal für die Antwort.

Genau den gleichen Code habe ich auch schon getestet, was auch super in dieser Art und Weise funktioniert hat.

Allerdings nicht wenn deine "123.3" z.B. durch ein Formular per $_Post an die Methode / Funktion weitergegeben wird!

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.

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

Allerdings ist mir gerade eine Idee eingefallen - werds mal versuchen und bei ner Lösung diese dann hier posten.

Gruß

Chris

[MrMarco]

Kurze Anmerkung am Rande... PHP ist Typneutral...

Der Inhalt bestimmt den Datentyp.

Kurze Anmerkung am Rande... PHP ist Typneutral...
Der Inhalt bestimmt den Datentyp.

Ähhhmm... das wissen wir glaub ich alle!?
Du hast das Problem wohl nicht erkannt

Also meine Lösung besteht darin, wenn du weisst, daß ein Integer per POST gesendet wird, kannste auch den dann entstandenen String einfach in die DB reinhauen, MySql merkt schon, wenn ein "echter" String in ein INT-Feld reingekloppt werden soll (und macht es nicht), ein vermeintlicher String (125.1 zB) wird als echter INT (Sry, Double oder Float natürlich! ) erkannt, und auch so gespeichert...

Grüße,
LaLop

Kurze Anmerkung am Rande... PHP ist Typneutral... Der Inhalt bestimmt den Datentyp.

Ähhhmm... das wissen wir glaub ich alle!?
Du hast das Problem wohl nicht erkannt

Du hast damit wohl auch Probleme.

Bevor man MySQL Uservariable zum Fraß vorwirft, sollte man die Inhalte testen. "Alles, was der Client schickt, ist böse!"

Bevor man MySQL Uservariable zum Fraß vorwirft, sollte man die Inhalte testen. "Alles, was der Client schickt, ist böse!"

Der Moderator hat gesprochen!

Sorry, im Kontext vom Verfasser war meine Aussage absolut ok!
Aber ich leg mich nicht mit der Obrigkeit an, die hat immer Recht und ich nicht! Also -> sinnlose Diskussion (für mich)

Bevor man MySQL Uservariable zum Fraß vorwirft, sollte man die Inhalte testen. "Alles, was der Client schickt, ist böse!"

Der Moderator hat gesprochen!

Nein. Meikel hat gesprochen. Den Moderator lasse ich meist nur dann "raushängen", wenn die Frage nicht zu den Regeln dieses Forum paßt.

Sorry, im Kontext vom Verfasser war meine Aussage absolut ok!

Ich hatte den OP so verstanden, daß er nach Möglichkeiten sucht, die Eingangsdaten auf Plausibilität zu prüfen. Der Vorsatz ist gut. Leider bietet PHP diesbezüglich recht wenig, so daß man einiges selbst zusammenbauen muß.

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

12.11. Prüfe importierte Parameter. Traue niemandem
http://www.dclp-faq.de/q/q-sicherheit-parameter.html

Der Moderator hat gesprochen!

Nein. Meikel hat gesprochen. Den Moderator lasse ich meist nur dann "raushängen", wenn die Frage nicht zu den Regeln dieses Forum paßt.

Sorry, im Kontext vom Verfasser war meine Aussage absolut ok!

Ich hatte den OP so verstanden, daß er nach Möglichkeiten sucht, die Eingangsdaten auf Plausibilität zu prüfen. Der Vorsatz ist gut. Leider bietet PHP diesbezüglich recht wenig, so daß man einiges selbst zusammenbauen muß.

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

12.11. Prüfe importierte Parameter. Traue niemandem
http://www.dclp-faq.de/q/q-sicherheit-parameter.html

Da bin ich dann ja nochmal mit einem blauen Auge davongekommen hrhr

Der 2. Link bezieht sich aber auf "gefälschte" Inhalte, bzw. manipulierte...
Der tenor ist ja "GET und HIDDEN - Variablen sind nicht fälschungssicher" etc. Darüber hinaus gibts dort auch eine Falschaussage:
"Stattdessen sind Sessionvariablen zu verwenden. Nur die Session-ID wird von einer Seite an eine andere Seite weitergereicht."

Das Problem wird (wurde) ja hier: http://www.phpfriend.de/ftopic16919.html schon behandelt!

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!!

Nur wenn die abgeschickten Werte von der eigenen Seite kommen, sind sie vertrauenswürdig... man kann auch mit den neusten IE-Exploits sowas NICHT verändern (hacken sag ich mal )!!!

Und somit ist auch garantiert, daß die übergebenen Variablen dem entsprechen, was man "erwartet".

Damit macht mein 1. Posting evtl auch mehr Sinn

Grüße,
Lopez

Kurze Anmerkung @LaLop: REFERER zu überprüfen ist zwar ganz geschickt, wird aber bei allen Usern, die in ihren Browsern (Opera kann das beispielsweise) den Referer ausgeschaltet haben _nicht_ funktionieren. Man kann ausserdem mit etwas Aufwand den REFERER auch fälschen, weil er vom Client gesendet wird.

Und ein allgemeiner Hinweis zum Thema REQUEST-Sicherheit: die gibt es nicht wirklich. Jeder, der etwas HTML versteht ist in der Lage sämtliche Request-Variablen die in einem Skript ausgewertet werden zu fälschen.
Will man lediglich den Inhalt der Daten vor Dritten schützen, hilft hier nur noch SSL.

Grüsse

Lev

Hi,

Kurze Anmerkung @LaLop: REFERER zu überprüfen ist zwar ganz geschickt, wird aber bei allen Usern, die in ihren Browsern (Opera kann das beispielsweise) den Referer ausgeschaltet haben _nicht_ funktionieren. Man kann ausserdem mit etwas Aufwand den REFERER auch fälschen, weil er vom Client gesendet wird.

ETWAS Aufwand ist da sicherlich ETWAS untertrieben! Da bedarf es schon mehr als was der "Normaluser" kann...

Und da wären wir doch wieder bei der Kosten-Nutzen Frage!!
Klar kann man Kleinkariert über Sicherheitsmängel diskutieren, aber selbst WENN man einen gefälschten Wert übernehmen würde, was macht das dann aus? Dann steht halt an der Stelle in der DB NIX - weil STRING _NICHT_ nach INT konvertiert wurde! - oder es steht dort zB eine verfälschte Zahl (16 statt 16,9)... und dafür so einen Aufwand machen?

Aus meiner langjährigen Erfahrung kann ich wirklich sagen, daß es viel viel schlimmere Sicherheitslecks gibt als einen falschen Wert in einer Tabelle! Als Beispiel was aus der Anfänger-Schublade:
SQL-Statements per GET übergeben

Und wenn es um "böse" Variablen geht... wer sicher gehen will, daß der Absender vertrauenswürdig ist, findet andere Wege als eine "einfache" Typenprüfung )

In _allen_ meinen Projekten, vom kleinen Forum bis zum Mega-CORP-CMS musste ich nie prüfen, ob INT wirklich INT war Weder bei den normalen, noch bei den sicherheitsrelevanten Projekten!

Daher auch meine 1. Antwort:
MySQL packt eh nur das rein, was auch passt! Wenns nicht passt, wird kein Datensatz geschrieben (bei NOT NULL - Spalten)!

Die Frage, ob der Absender vertrauenswürdig ist, oder evtl Fehler provozieren will, steht garnicht im Kontext zu der Frage!!!

Will man lediglich den Inhalt der Daten vor Dritten schützen, hilft hier nur noch SSL.

Grüsse
Lev

...was auch schon geknackt wurde LOL...
Aber wer nun paranoid ist, dem ist angeraten:
Nutze SSL, Sessions, und validierte User mit Logins, und schon ist man auf der sicheren Seite in 99% aller Fälle, und die anderen GANZ WIRKLICH sicherheitsrelevante Fälle sollte man sowieso nicht mit MySQL realisieren *ROFL*

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

[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.

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]

@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.