String prüfen...

Hi...

Ich möchte einen String prüfen und sicher stellen das er nur alfanumerische Zeichen enthält.

Derzeit mit preg_match und

define('PWD_PREG', '#^[a-z0-9]+$#i');

Da das bei nahezu jedem Seitenaufruf stattfindet, habe ich mich gefragt ob es nicht eine performantere Lösung gibt, als jedes mal die preg engine anzuwerfen ??!

Wer kann helfen ?
Danke schonmal.

MfG rahq

Ich weiss nicht, ob PHP dies auch unterstützt, aber in anderen regular expression enabled Sprachen kann man sich den matcher, also den compilierten regulären Ausdruck abspeichern und wiederholt auf Strings anwenden. Dies sollte dann eigentlich ziemlich performant sein, da regexes üblicherweise in ziemlich fixe Statemachines übersetzt werden.

Ansonsten wüsste ich auch nichts - ausser vielleicht deine Programmlogik derart umstricken, dass diese Überprüfung nicht mehr pro Seitenaufruf erforderlich ist. Beispielsweise könntest du deinen string in eine Tabelle hauen, die dann per int indiziert wird. Dann müsstest du die Usereingaben (ich denke darum geht es?) nur noch auf int ja/nein checken und den string dann aus der Tabelle (array) holen.

mfG,
Sören

Es geht ums Session- und Useronlinesystem.

startSession() wird immer ausgeführt.

Dort wird falls $_COOKIE['xxx_sid'] gesetzt ist,
die SID ( um die dreht es sich ) mit hilfe von preg_match gecheckt.

warum zum .... willst du sowas machen?

wenn die session nicht existiert passiert doch nichts...
und wenn jemand eine valide session eingibt dann stimmt natürlich auch der preg_match...

dadurch wird das sessionmanagement eigendlich kein bisschen sicherer, falls das deine absicht war.

reg4rds
chojin

Verstehe ich auch nicht. Was würde denn passieren, wenn da ein falsches Zeichen drin steht?

Ganz einfach...

Ich verzichte momentan auf PHP Sessionfunktionen.

Die SID muss valide sein, weil dazu ein SQLquery gehört,
das in der WHERE Klausel sid = SID als Parameter nutzt.
Wäre fahrlässig das nicht zu prüfen...

Also ganz grob:

if (isset($_COOKIE['c4w_sid']) || isset($_COOKIE['c4w_data'])) {

$sessiondata = isset($_COOKIE['c4w_data']) ? unserialize(stripslashes($_COOKIE['c4w_data'])) : array();
$sid = isset($_COOKIE['c4w_sid']) ? $_COOKIE['c4w_sid'] : '';
}
else {
$sessiondata = array();
$sid = '';
}
if (!preg_match('/^[A-Za-z0-9]*$/', $sid)) {
$sid = '';
}

Wenn du das so machen willst....
und denkst das macht so sinn für dich...
dann musst du wohl auch das "preg_match" in kauf nehmen.

Ich seh programmiertechnisch allerdings keinerlei logik, sich für eine lösung wie deine zu entscheiden.

reg4rds
chojin

Lass den String doch durch http://de2.php.net/manual/de/function.mysql-real-escape-string.php laufen, dann hast du keine Probleme mit MySQL.

Ich frage mich auch, was gegen normale PHP Sessions spricht... ?

Apropos Sessions - kurz hier gefragt dann brauche ich keinen extra Thread auf zu machen

Bremst es das System aus wenn man "viel" in der Session speichert?
Können schonmal 1-2 Kb sein.

Bei wie viel Usern und bei welcher Speichermethode (Standard Festplatte, etc.)?

@Klaus, ja das wär schon mal ne Möglichkeit, thx...

Eine Möglichkeit wäre vielleicht noch den String mit
if (substr_count($string, $search) != 0),
auf das Vorkommen bestimmter Zeichen zu prüfen.
Ist eine ganze Ecke schneller als preg_match()...

Ich hatte auch schonmal einen ähnlichen Thread gestartet.
galaxy-news.de/forum/viewtopic.php?t=1082&highlight=
Wollte da mal auf eine Sicherheits bezogene Diskussion hinaus.

Warum überhaupt der ganze Stress, wos doch so einfach geht ?
session_start();
session_destroy();

Ich schaue halt hin und wieder bei der Opensourcecommunity rein um zu sehen wie die gewisse Probleme gelöst haben...
Zum Beispiel Foren, PHPBB, Woltlab, VBulletin.
Software die Tag täglich gestresst und gestestet wird, von Usern weltweit.
secunia.com/search/?search=phpbb
Die verzichten zum Beispiel vollkommen auf PHP Sessions...

Mein Bedenken war, das der Filezugriff auf ein Ordner mit nur wenigen und kleinen Files sehr schnell ist...
Das ändert sich aber dramatisch, wenn es mehr Files werden ( viele Sessions ).
Ein Zugriff auf eine HEAP Tabelle in der die Sessions getrackt werden ist auch bei einer grossen Anzahl an Sessions verdammt schnell.
Und den mysql_connect mach ich ja sowieso...

Bitte kritisert mich, verbessert mich, informiert mich...
deswegen hab ich ja gefragt.

MfG

@knalli - mal noch Festplattenbezogen, User sollten es mit der neuen runde so um die 3-4K sein.

@rahq - wenn du das als HEAP laufen lassen willst dann kannst du einfach die Sessions im Speicher anlegen lassen. Ist halt ein frage des Rams. Ansonsten wüßte ich auch nicht was gegen die Sessions spricht. Ich gehe viel von der Datenbank auf die Sessions denn bei mir hat wegen den ganzen Zugriffen der MySQL Server schlapp gemacht. Und was performanter ist (Heaptabelle oder Sessions im Ram) wäre mal ein Test wert aber einfacher (und meiner Meinung auch sicher genug mit einem IP check zur Session) ist die normale Session.

Finde die php session auch am einfachsten und sinnvollsten.

Die lassen sich doch sicher auch im Ram, statt auf der platte speichern.. und der Overhead einer mysql verbindung (die du sonst u.U. nicht brauchst), ist ja auch nicht ohne.

Wenn du wirklich Dauerlogin moechtest, dann aendere deine Sessioneinstellungen doch, aber ich habe z.B. kuerzlich einen festen autologout nach 4h implementiert. Die normale Session Lifetime ist 1h. Einfach schon als Ansatz gegen Bots, die den Login umgehen wollen.

Original von The_Alien
@knalli - mal noch Festplattenbezogen, User sollten es mit der neuen runde so um die 3-4K sein.

@rahq - wenn du das als HEAP laufen lassen willst dann kannst du einfach die Sessions im Speicher anlegen lassen. Ist halt ein frage des Rams. Ansonsten wüßte ich auch nicht was gegen die Sessions spricht. Ich gehe viel von der Datenbank auf die Sessions denn bei mir hat wegen den ganzen Zugriffen der MySQL Server schlapp gemacht. Und was performanter ist (Heaptabelle oder Sessions im Ram) wäre mal ein Test wert aber einfacher (und meiner Meinung auch sicher genug mit einem IP check zur Session) ist die normale Session.

... weil es dann schlecht ist. Die Geschwindigkeit ist bei Sessions enorm wichtig, man sollte dort sowohl Overhead als auch Anbindung stark beachten.

Empfehlen würde ich also, wie schon angesprochen eine Mischung aus Mysql HEAP (Struktur der DB auf der Festplatte, Inhalt im Arbeitsspeicher ==> super schnell, Datenverlust bei Restart des Mysqlservers (was bei Sessions ja nicht schlimm ist => Logout) und ggf eigenem Sessionmanagment. Prinzipiell reicht es doch, wenn man die phpsession funktionen durch entsprechende mysql select befehle der heap überlädt.

Ein Wort zu dem Vorschlag, Daten in die Session zu speichern (prinzipiell). Ich würde dies in einer extra Tabelle machen, die z.b. relativ zu der Session ID aufgebaut ist - der Hauptzugriff zu der Session ist dann wie gewohnt schnell, und Extra daten können dennoch geladen werden - muss man halt einen (globalen) Handler aufbauen (ala xy->getSessionVar(key)), der bei Erstzugriff die Daten komplett holt.
Spontan meine Idee..

Hab mal noch ein wenig gelesen...

Die einzige Möglichkeit die Sessiondaten im RAM zu halten
und gleichzeitig die standard php sessions zu nutzen,
ist glaube ich session_set_save_handler();

Das ist an sich auch ne feine Sache...
Da man session_start(); usw wie gewohnt nutzen kann.
Und wie ich so gelesen habe nutzen das auch nicht wenige coder.

Stellt sich mir aber die Frage, wenn ich die handler funktionen selbst
schreibe, kann ich doch auch gleich alles selbst machen ?!

Und PHP muss ja intern auch die sid validieren usw warscheinlich
nutzt es dazu auch pregs... ( war ja der Grund des Threads )

Ehrlich gesagt bin ich zwar jetzt ziemlich gut über
gängige Möglichkeiten informiert, aber wie ich mich nun
entscheide weiss ich immer noch nicht...

Na ja vielleicht finden sich ja hier noch ein paar hilfreiche Posts...

MfG

Warum überhaupt validieren. Einfach in der Session-Tabelle gucken, obs den key gibt, davor ein ganz normaler Dscape. Das ist alles. Wenns die Session halt net gibt, kommt halt raus, dass die Session nicht läuft.
PHP wird das mit seiner Session-Verwaltung ähnlich machen.

Ich habe eine Session-Klasse über die PHP-Session gelegt, so kann ich die darunterliegende Session austauschen, und z.B. das Sessionsystem vom PHPBB nutzen, was ich auch schon getan habe. Am Interface hat sich dabei nichts verändert. Natürlich kann man in der Klasse dann auch ein Session-Management über MySQL-Heap aufbauen.

Gruß

Khoernchen

ctype_alnum($string); gibt true zurück,
wenn nur alfanumerische Zeichen enthalten sind.
Nachher mal testen wie schnell / langsam das ist...

@Kh also einfach nur addslashes($string) und gut ?
Ich glaube so langsam das ich vorerst mal bei meinem
DB Ansatz bleibe.
Ne schöne Klasse die ein wenig Flexibilität erlaubt,
schustere ich mir sicher noch drum herum...

klar, z.B.
'SELECT * FROM mysession WHERE "'.mysql_real_escape_string($_REQUEST['sid']).'";'
Da kann kommen was will, wenns die Session net gibt, gibts die halt net.

So, hier mein kleines Script...

// add slashes to global arrays

function secureGlobal($global) {
if (is_array($global)) {
foreach ($global as $key => $val) {
if (is_array($val)) {
$global[$key] = secureGlobal($val);
}
else {
$val = addslashes($val);
$global[$key] = trim($val);
}
}
}
return $global;
}

$_GET = secureGlobal($_GET);
$_POST = secureGlobal($_POST);
$_COOKIE = secureGlobal($_COOKIE);
$_REQUEST = secureGlobal($_REQUEST);

//

Ist klar, addslashes für alle globalen arrays, auch mehrdimensional.

Das reicht ja ??!

Also wäre es schon paranoid, wenn ich da jetzt noch n preg_match() oder sonstwas drüber laufen lasse vor:

"SELECT * FROM c4w_sessions WHERE sid = '$sid'"

MfG

Warum willst du unbedingt Eingaben sichern?

Du nimmst dir damit selbst die Möglichkeit Quotes direkt zur Ausgabe zu nutzen:

echo ( "Dein Name: {$_REQUEST [ 'name' ]}" );

Eingaben gehören direkt an der Schnittstelle zur Datenbank gesichert und nicht mal prophylaktisch im Voraus.

PDO unterstützt dich dort ungemein, oder schau dir die Datenbankklasse aus dem Shared Source-Projekt von GN an.

Original von rahq
So, hier mein kleines Script...

// add slashes to global arrays

function secureGlobal($global) {
if (is_array($global)) {
foreach ($global as $key => $val) {
if (is_array($val)) {
$global[$key] = secureGlobal($val);
}
else {
$val = addslashes($val);
$global[$key] = trim($val);
}
}
}
return $global;
}

$_GET = secureGlobal($_GET);
$_POST = secureGlobal($_POST);
$_COOKIE = secureGlobal($_COOKIE);
$_REQUEST = secureGlobal($_REQUEST);

//

Ist klar, addslashes für alle globalen arrays, auch mehrdimensional.

Das reicht ja ??!

Also wäre es schon paranoid, wenn ich da jetzt noch n preg_match() oder sonstwas drüber laufen lasse vor:

"SELECT * FROM c4w_sessions WHERE sid = '$sid'"

MfG

Mach es doch nicht so kompliziert.

function slash($val)
{
return mysql_real_escape_string(htmlentities($array,ENT_QUOTES));
}

$_POST = array_map('slash',$_POST);
$_GET = array_map('slash',$_GET);
//etc.


Wenn du nur addslashes benutzt aktivier doch einfach magic_quotes_gpc.

Warum ich die Eingaben unbedingt sichern will ?
Versteh ich nicht...
Halte das für recht elementar, die sid dient eh keiner Ausgabe.
Die Sicherung ist ja auch nicht prophylaktisch im Vorraus,
sondern wirklich elementar...

Also die PDO Funktionen sind mir wohl ein wenig zu umständlich...

Die DB Klasse hab ich mir angesehen...
Halte ich aber auch nicht für der Weisheit letzten Schluss.
Was ist an escape(); und descape(); besonderes ?

Zu magic_quotes:

"Simply calling on the escaping functions (like addslashes()) at runtime is more efficient."

Steht nicht zur Diskussion...

Na ja ich danke allen Postern für ihre Anregungen...
Ich glaube ich komme dem für mich geeigneten System so langsam nahe...

MfG

Selbstgeschrieben ist eigentlich immer besser.

Aber obs auch effizienter ist? Die selbstgeschirbenen Funktionen werden bei jedem aufruf neu interpretiert, dabei läuft die PHP-Interne Lösung auf einer ganz anderen Ebene.

E-Accellator

hmm andere frage:
die PHP-Session Daten werden ja in einzelnen Dateien gespeichert.
Liegen diese Dateien nicht nach mehrmaligen Aufrufen automatisch im Filecache?

Also performancemäßig geben sich Heap-Tabellen / PHP-Sessions net viel. Deswegen denke ich auch, dass die Files im RAM liegen (kommt aber wahrscheinlich auch auf die Rechnerausstattung an)

Da es reicht die Files zu loeschen um eine bestehende Session zu zerstoeren (bzw. mir kein Weg bekannt ist, eine andere als die eigene Session zu zerstoeren), kann es nicht sein, dass gecached wird.

Ich denke nur, bei nicht zu hohem load und keiner zu grossen Filegroesse, merkt man den Unterschied einfach nicht.