PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Sessions und HTTP Auth


Serathil
03.11.2010, 09:32:39
Guten Morgen ,
ich habe eine Homepage auf der sich Benutzer einloggen können um in einen internen Bereich zu gelangen.
Das funktioniert mit Sessions ganz gut.
Das Problem ist nun, dass ich Dateien habe, die nur von bestimmten internen Bneutzern geladen werden dürfen, bzw Ordner in die auf keinen Fall nicht-eingeloggte Leute hineindürfen.
Damit auch Google nicht durch die Ordner läuft habe ich eine .htaccess angelegt, welche die Nutzerdaten aus einer SQL-DB ausliest und denn Nutzer dann zulässt oder nicht.

Mein Problem ist nun, dass die User genervt sind, dass sie sich beim HTAccess noch einmal anmelden müssen.
Nun möchte ich aber auch nicht das gesamte Konzept über den Haufen werfen sondern die Sessions behalten.
Eine Zuweisung der SERVER-Variablen geht ja leider auch nicht und wie ich finde ist nur das htaccess unschön zum einloggen.
Hat jemand von euch da eine Idee?

Lg

cortex
03.11.2010, 10:00:56
Hat jemand von euch da eine Idee?

nutze php zur authentifizierung; http-auth ist für komplexere umgebungen - wie du selbst bemerkst - gänzlich ungeeignet. nutze dazu entsprechende module eines php-frameworks, suche nach skripten / tutorials im netz und / oder schreib das ganze selbst zusammen.

cx

R4Zz0R
03.11.2010, 11:12:19
Eine empfehlung hätte ich für dich.

-> Das script is frei verfügbar und von einem kollegen von mir geschrieben mit dem ich zusammen bei dem projet arbeite.

http://webdesign.sarkkan.de/moonweb/SichererLoginMitWenigAufwand.htm

Ziemlich sicher auserdem leicht zu integrieren finde ich.

LG
R4Zz0R

cortex
03.11.2010, 12:19:40
Ziemlich sicher [...] finde ich.

wie kommst du zu dieser einschätzung? ist dein kollege der meinung? hast du selbst ausreichend erfahrung, das zu beurteilen?

anmerkungen zum skript:

Zusätzlich wenden wir noch htmlentities() und trim() [auf] Benutzernamen sowie Passwort an, um gefährliche Zeichen zu maskieren und unnötige Leerzeichen zu entfernen:

das ist unsinn.

1. htmlentities( ) dient zur maskierung besonderer zeichen bei der ausgabe von daten in html. darüber hinaus würde man nicht die originären daten in der db speichern, sondern eine (willkürliche / spezifische) maskierung.

2. um eingabedaten in richtung db zu maskieren, wird mysql_real_escape_string (http://de.php.net/manual/de/function.mysql-real-escape-string.php) benutzt.

ich kann R4Zz0R's empfehlung leider nicht teilen; das ganze ist nicht ausgereift.

cx

CPCoder
03.11.2010, 14:40:54
Ich kann der Empfehlung ebenfalls keine Zustimmung erteilen.

Schon alleine der Loginvorgang wird durchgeführt ohne die übergebenen POST-Parameter zu maskieren und direkt in das SQL-Query einzubinden:

$user = $_POST['loginName'];
$pass = $_POST['loginPass'];

$sql = "SELECT id FROM accounts WHERE
username = '". $user ."' AND
password = '". $pass ."' LIMIT 1;";

Stichwort: SQL-Injection

cortex
03.11.2010, 15:22:37
Schon alleine der Loginvorgang wird durchgeführt ohne die übergebenen POST-Parameter zu maskieren [...]

naja... dazu haben die autoren auch angemerkt:

Dieser Login kann ausgetrickst werden

cx

Ckaos
03.11.2010, 23:39:51
Hi


2. um eingabedaten in richtung db zu maskieren, wird mysql_real_escape_string (http://de.php.net/manual/de/function.mysql-real-escape-string.php) benutzt.

ich kann R4Zz0R's empfehlung leider nicht teilen; das ganze ist nicht ausgereift.

cx
Sehe ich genauso.

Und bitte nicht mehr auf magic_quotes_gpc setzen das is ab 5.3 DEPRECATED.

Daten die nicht in Richtung DB gehen kann man sich easy ne
Funktion schreiben die alle POST, GET usw Daten von nicht
gewünschten befreit und gefährliches maskiert.

Ich persönlich maskiere durch eine solche funktion alles bevor
es meine scripte betritt egal welche ziele sie haben!

mfg

CKaos

R4Zz0R
04.11.2010, 00:18:03
Zu dem script muss ich anmerken das da vor einiger zeit noch mehr zu dem beitrag stand..
Wurde wohl überarbeitet sorry für den ausrutscher ...

O.T
@ Ckaos:
meinst du etwa sowas wie (pseudocode *sollte aber gehen ;) )


<?php
$geta = array_merge($_GET);
foreach ( $geta as $varx => $val ) {
$geta[$varx] = preg_replace('/[^a-z0-9 \\/?=&]/Usi','',$val);
}
?>


Was natürlich jetzt meine variante wäre sowas zu lösen. (und was auch auf post anwendbar wäre)

Ckaos
04.11.2010, 02:59:33
Hi

so oder ähnlich ;)

$outlow=array(";",":","<",">","%","$");
foreach($_GET as $key=>$val){
$_GET[$key] = str_replace($outlow,"",$val);
}
foreach($_POST as $key=>$val){
$_POST[$key] = str_replace($outlow,"",$val);
}

Jedenfalls fing ich so mal an....dann paranoider später / heute
habe ich ne Klasse die je Seite nur vorher per Formularklasse
oder Tempklasse zugelassene/registrierte/Typ bestimmte Daten
prüft und durchlässt andere ignoriert und mir nur zur
Prüfung ablegt. So lassen sich "versuche" relativ schnell
entdecken und im Keim ersticken.

mfg

CKaos

R4Zz0R
04.11.2010, 14:54:57
Ähhm ... du entfernst die zeichen einfach ... dh. du machst das selbe wie ich mir str_replace
wobei eine regex warscheinlich performanter ist ...

bei post ist es auserdem weniger sinnvoll wenn du alles filterst und gegen nichts ersetzt also in dem fall es aus dem string löschst da der benutzer ja sicher auch gerne zeichen eingeben würde um seinen text zu formatieren oder code auf der seite zu präsentieren ...

da würde ich es dan eher mit mysql_real_escape_string maskieren ( dafür hab ich mir mal ne gute funktion gebastelt :D )


<?php
function cleanQuery($array) {
foreach( $array as $varx => $val ) {
$array[$varx] = mysql_real_escape_string($val);
}
return $array;
}
?>


so habe ich immer ein eigenstädiges array was nur für sql querys bereitsteht, und das laut meiner ausgabe ( & sql inject me :) ) auch recht sicher ist.

cortex
04.11.2010, 15:22:48
wobei eine regex warscheinlich performanter ist

klares statement meinerseits: nein.



$outlow=array(";",":","<",">","%","$");



kein semikolon, doppelpunkt, prozent- und dollar-zeichen...? sind doch alles bestandteile unserer "normalen" schriftsprache. und die spitzen klammern sind nur im html-kontext gefährlich. also... wie bereits gesagt:

mysql_real_escape_string (http://de.php.net/manual/de/function.mysql-real-escape-string.php) zur maskierung in richtung db und htmlentities (http://de.php.net/manual/de/function.htmlentities.php) / htmlspecialchars (http://de.php.net/manual/de/function.htmlspecialchars.php) zur ausgabe in html.

cx

Ckaos
04.11.2010, 15:46:27
Hi

Ähhm ... du entfernst die zeichen einfach ... dh. du machst das selbe wie ich mir str_replace
wobei eine regex warscheinlich performanter ist ...
Kannst du das belegen?

bei post ist es auserdem weniger sinnvoll wenn du alles filterst und gegen nichts ersetzt also in dem fall es aus dem string löschst da der benutzer ja sicher auch gerne zeichen eingeben würde um seinen text zu formatieren oder code auf der seite zu präsentieren ...

Wie gesagt das waren die Anfänge...
Heute geht nix durch was nicht angefordert/registriert wurde.
Und was der Benutzer möchte oder nicht ist Sache der Aufgabe
und des Auftraggebers. Wenn ein Benutzer nach Rezeptnamen
suchen kann/darf brauch er nicht alle Zeichen oder?
Hab jedenfalls noch kein Kartoffel<;&%auflauf gelesen ;)

so habe ich immer ein eigenstädiges array was nur für sql querys bereitsteht, und das laut meiner ausgabe ( & sql inject me :) ) auch recht sicher ist.
Is ja bei mir ebenso nur muss ich keine "arrays'" erfinden sie sind ja da
...........gesäubert ;)

kein semikolon, doppelpunkt, prozent- und dollar-zeichen...? sind doch alles bestandteile unserer "normalen" schriftsprache.
Wie gesagt Heute definier ich schon bei Erstellung eines Formularfelds
was es beinhalten darf und alles was nicht A-Z0-9 ist geht dann ->
mysql_real_escape_string zur maskierung in richtung db und htmlentities / htmlspecialchars zur ausgabe in html.
Logisch und nicht diskutierbar.

mfg

CKaos

vt1816
04.11.2010, 16:42:24
[..]
Wie gesagt Heute definier ich schon bei Erstellung eines Formularfelds
was es beinhalten darf und alles was nicht A-Z0-9 ist geht dann ->


Was ist mit kleinen Buchstaben, Satzzeichen, ÄÖÜ, äöü und ß?

Ckaos
05.11.2010, 01:12:17
Hi

Was ist mit kleinen Buchstaben, Satzzeichen, ÄÖÜ, äöü und ß?
Keine Ahnung was willst du nun hören oder meinst du mich gar nicht?
Hoffe du beziehst dich nicht auf mein
und alles was nicht A-Z0-9 ist geht dann ->
denn das war nur ein Beispiel und nicht regex bezogen [A-Z]

mfg

CKaos