Gewoon voor de lol (zodat je een idee hebt waarom Fred -ii- zei deze code niet te gebruiken) - ik ga dit een beetje uit elkaar halen, in volgorde, terwijl ik het doorneem (het is niet een persoonlijke speurtocht naar de persoon die de vraag stelt - maar om een idee te geven dat het proberen om een halfveilige applicatie op de LAMP-stack te bouwen een beetje zorg en vooruitziendheid vereist ... de mensheid helpt):
Punt 1
Geen biggy - maar echt als je een sessie gaat starten, moet je een sessie starten, ongeacht of er $_POST is gegevens of niet. U moet waarschijnlijk eerst uw configuratiebestand nodig hebben en de sessie bovenaan starten.
Geen terminalfout (omdat je geen sessievalidatie hebt) - gewoon raar.
Punt 2
Je hebt uitvoer in dit bestand (echo ) daarom moet het onder de documenthoofdmap staan en beschikbaar zijn in de webstructuur.
include("config.php");
Dit is niet echt goed geschreven, het zou waarschijnlijk require_once 'config.php'; (ervan uitgaande dat het een verplicht programmabestand is en geen optionele include die mag mislukken) maar dat is niet de fout. De fout is dat u uw configuratiebestand in uw documentroot hebt. Een verkeerde serverconfiguratie of een simpele typfout in dat bestand zou er theoretisch voor kunnen zorgen dat de inhoud van dat bestand in platte tekst op het scherm wordt weergegeven, waardoor mogelijk uw databaseverbindingsreeksen (en wie weet wat nog meer) worden onthuld aan world + dog.
Configuratiebestanden moeten buiten de webstructuur staan of, als dat niet lukt, in een map die is beveiligd met iets als .htaccess Deny from all . Ze mogen nooit toegankelijk zijn via HTTP.
Punt 3
De mysql bibliotheek is verouderd en zou helemaal niet moeten worden gebruikt; MySQLi of PDO zijn de juiste keuze, idealiter met gebonden parameters/waarden:
Persoonlijk had ik voor BOB gekozen.
Punten 4 &5
$password = mysql_real_escape_string(stripslashes(md5($_POST['password'])));
Ten eerste is de volgorde hiervan verkeerd. Je hasht $_POST['password'] en toen proberen om wimpers te strippen - er zullen geen schuine strepen meer zijn als het eenmaal is gehasht. Als u echter probeert te voorkomen dat mensen slashes (of wat dan ook) in wachtwoorden gebruiken, moet u deze verwijderen voordat u de string hasht.
Volgende md5 mag niet worden gebruikt als een wachtwoord-hash-algoritme, het is zwak bevonden en kan bruut worden gedwongen om veel vaker string-botsingen te creëren dan zou moeten.
Ja, u moet sla alleen hashes of "vingerafdrukken" van de wachtwoorden op in plaats van de wachtwoorden zelf, maar idealiter wil je salt en hash (met ten minste sha1 ) die wachtwoorden in plaats van ze simpelweg in een md5() . te gooien functie.
Zie:http://uk3.php.net/mcrypt bijvoorbeeld
En zoek op "wachtwoord salting hashing" met uw zoekmachine naar keuze.
Punt 6
SELECT id FROM $table
WHERE username = '" . $username . "'
and password = '" . $password . "';
Ik heb toegevoegd in de = die ontbrak in de oorspronkelijke vraag, maar toch, kom niet overeen met gebruikersnaam en wachtwoord in uw zoekopdracht ... als iemand erin slaagde een SQL-injectie in uw gebruikersnaam te krijgen, zou het wachtwoord nooit worden gecontroleerd. Stel je voor:
SELECT user.id
FROM user WHERE user.username = 'fred' OR 1 = 1
-- AND user.password = 'abc123'
Het is beter om de gebruikers-ID en wachtwoordvingerafdruk uit de database te selecteren en vervolgens het wachtwoord in de toepassing te evalueren in plaats van een wachtwoordcontrole in de databaselaag te vertrouwen. Het betekent ook dat je een speciaal hash- en salting-algoritme in de applicatie zelf kunt gebruiken om je wachtwoorden te valideren.
Punt 7
$_SESSION['user'] = $_POST["username"];
Dit slaat alleen de gebruikersnaam op in de sessie? Dit mag op geen enkele manier worden gebruikt als een "login-verifier", vooral omdat er (blijkbaar) niets in uw sessie is om kaping .
De sessie-ID kan gemakkelijk uit de cookie van een livesessie worden gesnoven en dat is alles wat nodig is om de login van iemand anders te "lenen". Je moet op zijn minst proberen de kans dat de sessie wordt gekaapt te verkleinen door het IP-adres van de gebruiker, de UserAgent-string of een andere combinatie van relatief statische gegevens waarmee je op elke pagina kunt vergelijken, te associëren... er zijn echter nadelen aan vrijwel elke benadering (vooral, zoals ik heb ontdekt, als je bezoekers hebt die AOL gebruiken) - maar je kunt een waarschijnlijk 99+% effectieve sessievingerafdruk maken om kaping te verminderen met een zeer kleine kans dat de sessie van de gebruiker per ongeluk wordt gedumpt.
Idealiter wil je misschien ook een token voor de sessie maken om CSRF aanvallen wanneer de gebruiker een "bevoorrechte" actie op de database moet uitvoeren (de gegevens bijwerken of wat dan ook). Het token kan een volkomen willekeurige en unieke code zijn die is opgeslagen in de database en/of in een SSL-cookie wanneer de gebruiker inlogt (ervan uitgaande dat de gebruiker geen actie kan uitvoeren die de database bijwerkt buiten HTTPS om, aangezien dat alleen de gegevens zou verzenden in duidelijke tekst op internet - wat een slecht idee zou zijn ).
Het token wordt in een verborgen formulierveld geplaatst voor alle/alle formulieren en wordt vergeleken met de waarde die is opgeslagen in de cookie (of sessie of database) wanneer dat formulier wordt verzonden. Dit zorgt ervoor dat de persoon die het formulier indient in ieder geval een live sessie op uw website heeft.