Bare for headstuffs skyld (så du får en ide om, hvorfor Fred -ii- sagde ikke at bruge denne kode) - Jeg vil skille det lidt ad, i rækkefølge, efterhånden som jeg går igennem det (det er ikke en personlig udgravning af den person, der stiller spørgsmålet - men bare for at give en idé om, at forsøg på at bygge en halvvejs sikker applikation på LAMP-stakken kræver en lille smule omhu og omtanke ... og blodigt sind kynisme parret med at antage det værste i menneskeheden hjælper):
Punkt 1
Ikke noget stort - men virkelig, hvis du skal starte en session, bør du starte en session, uanset om der er $_POST data eller ej. Du skal nok kræve din konfigurationsfil og starte sessionen øverst før noget andet.
Ikke en terminalfejl (da du ikke har nogen sessionsvalidering) - bare underligt.
Punkt 2
Du har output i denne fil (echo ) derfor skal den være under dokumentroden og tilgængelig i webtræet.
include("config.php");
Dette er ikke rigtig skrevet korrekt, det burde sandsynligvis være require_once 'config.php'; (forudsat at det er en påkrævet programfil og ikke en valgfri inkludering, der kan tillades at mislykkes), men det er ikke fejlen. Fejlen er, at du har din konfigurationsfil inde i din dokumentrod. En serverfejlkonfiguration eller simpel tastefejl i den fil kunne teoretisk set tillade, at indholdet af den fil bliver udskrevet til skærmen i almindelig tekst, hvilket potentielt afslører dine databaseforbindelsesstrenge (og hvem ved hvad ellers) for verden + hund.
Konfigurationsfiler bør eksistere uden for webtræet eller, hvis det ikke er tilfældet, inde i en mappe, der er beskyttet med noget som .htaccess Deny from all . De bør aldrig være tilgængelige via HTTP.
Punkt 3
mysql biblioteket er forældet og bør slet ikke bruges; MySQLi eller PDO er vejen at gå, ideelt set med bundne parametre/værdier:
Personligt ville jeg gå efter PDO.
Punkt 4 og 5
$password = mysql_real_escape_string(stripslashes(md5($_POST['password'])));
For det første er rækkefølgen af dette forkert. Du hasher $_POST['password'] og derefter forsøger at fjerne skråstreg - der vil ikke være nogen skråstreg, når først det er blevet hash. Men hvis du forsøger at forhindre folk i at bruge skråstreger (eller hvad som helst) i adgangskoder, skal du fjerne dem, før du hashgør strengen.
Næste md5 bør ikke bruges som en hashing-algoritme for adgangskode, den har vist sig at være svag og kan være brutalt tvunget til at skabe strengkollisioner langt hyppigere, end den burde.
Ja, du skal gem kun hashes eller "fingeraftryk" af adgangskoderne i stedet for selve adgangskoden, men ideelt set vil du salte og hash (med mindst sha1 ) disse adgangskoder i stedet for blot at smide dem ind i en md5() funktion.
Se:http://uk3.php.net/mcrypt for eksempel
Og lav en søgning på "password salting hashing" ved hjælp af din foretrukne søgemaskine.
Punkt 6
SELECT id FROM $table
WHERE username = '" . $username . "'
and password = '" . $password . "';
Jeg tilføjede = der manglede i det oprindelige spørgsmål, men alligevel svarer ikke brugernavn og adgangskode i din forespørgsel ... hvis det lykkedes nogen at få en SQL-injektion i dit brugernavn, ville adgangskoden aldrig blive tjekket. Forestil dig:
SELECT user.id
FROM user WHERE user.username = 'fred' OR 1 = 1
-- AND user.password = 'abc123'
Det er bedre at vælge bruger-id og adgangskodefingeraftryk fra databasen og derefter evaluere adgangskoden i applikationen i stedet for at stole på en adgangskodekontrol i databaselaget. Det betyder også, at du kan bruge en dedikeret hash- og saltingalgoritme i selve applikationen til at validere dine adgangskoder.
Punkt 7
$_SESSION['user'] = $_POST["username"];
Dette er blot at gemme brugernavnet i sessionen? Dette bør på ingen måde bruges som en "loginbekræftelse", især da der (tilsyneladende) intet er i din session, der forhindrer kapring .
Sessions-id'et kunne nemt sniffes fra cookien af en live-session, og det er alt, hvad der kræves for at "låne" en andens login. Du bør i det mindste forsøge at mindske chancen for, at sessionen bliver kapret ved at tilknytte brugerens IP-adresse, UserAgent-streng eller en anden kombination af relativt statiske data, som du kan sammenligne med på hver side... der er dog ulemper ved praktisk talt enhver tilgang (især, som jeg har fundet ud af, hvis du har besøgende, der bruger AOL) - men du kan lave et sandsynligvis 99+ % effektivt sessionsfingeraftryk for at afbøde kapring med meget lille chance for, at brugerens session fejlagtigt bliver dumpet.
Ideelt set ønsker du måske også at oprette et token til sessionen for at afbøde CSRF angreb, når brugeren skal udføre en "privilegeret" handling på databasen (opdatere deres detaljer eller hvad som helst). Tokenet kunne være en fuldstændig tilfældig og unik kode, der er gemt i databasen og/eller i en SSL-cookie, når brugeren logger på (forudsat at brugeren ikke kan udføre nogen handling, der opdaterer databasen uden for HTTPS, da det blot ville overføre dataene i klartekst på tværs af internettet - hvilket ville være en dårlig idé ).
Tokenet sættes i et skjult formularfelt for enhver/alle formularer og kontrolleres mod værdien, der er gemt i cookien (eller sessionen eller databasen), hver gang formularen indsendes. Dette sikrer, at den person, der indsender formularen, som minimum har en live-session på dit websted.