23. marts 2009 - 15:15Der er
18 kommentarer og 1 løsning
Integrering af SSL kryptering på min hjemmeside
Hej Eksperter,
Jeg har en hjemmeside som man kun kan få adgang til via en email og dertil tilknyttet password. Denne hjemmeside råder over en række persondater, og derfor skal hjemmesiden leve og til persondatalovigningen.
Mit problem er nu at jeg har fundet ud af at siden skal være SSL-krypteret.
Hvordan og hvor svært er det at Integrerer på ens hjemmeside? Lige nu sikre at uvedkommene ikke kan få adgang til min hjemmeside ved brug af Sessions.
SSL har for det første ikke noget med PHP at gøre. Det foregår het nede på netværksniveau under din webserver så hvordan det skal sættes op afhænger af dit OS.
Generelt må jeg påpege at jeg på dine brugeres vegne er meget utryk ved din tilsyneladende lave erfaring med sikkerhed. Jeg vil klart anbefale dig at lade håndtering og opbevaring af personfølsomme data op til professionelle der ved hvad de laver. Det er ikke for at være negativ, det er bare et godt råd.
Desuden har SSL kryptering heller ikke noget at gøre med at uvedkommende kan få adgang til hjemmesiden. SSL bruges blot til at kryptere data mellem klient og server.
Okay ja, så jeg skal tage fat i min web udbyder for at få ordnet dette her problem?
Man kan jo ikke lærer det hele på en dag. Alle startede vel et sted, og det samme gør jeg. Men har du nogle forslag til hvad jeg kan gøre, for at øge sikkerheden på de data som jeg har liggende på mit websted så?
Når du skriver at jeg skal lave professionelle der ved hvad de laver om at håndterer og opbevarer de personfølsomme dataer, hvad mener du så med dette?
Det jeg mener er f.eks. at du aldrig bør have personfølsomme data på en server hvor du ikke kan kontrollere hvem der har adgang til den. F.eks har din udbyder jo frit adgang til alt du gemmer så hvia du skal have personfølsom data skal du have en server du også kan sikre rent fysisk.
Det er svært at sige hvad du skal bruge til login for det er ikke så meget et spørgsmål om hvad du gør men mere om hvordan det er implementeret. En løsning er ikke bedre end de fejl der forekommer når man skriver den.
function hashpassword($password, $salt){ return md5($password.$salt); }
$finalpassword = hashpassword($password,$salt);
mysql_query("UPDATE bruger SET `password` = '$finalpassword', `salt` = '$salt' WHERE `usersid` = '$usersid'") or die(mysql_error());
--- slut ---
På denne måde omdannes brugers password til 2 x MD5 krypterede koder, som så gemmes ned på brugeres 'konti' på databasen.
Når brugeren så skal logge sin ind på siden sker der følgende:
--- start ---
$query = "SELECT `email`, `password`, `salt` FROM bruger WHERE `email` = '$email'"; $result = mysql_query($query) or die ("MySQL fejl: ". mysql_error()); $log = mysql_fetch_array($result);
function hashpassword($password, $salt) { return md5($password.$salt); }
$finalpassword = hashpassword($password,$salt);
if (strtolower($_POST['email']) == $log['email'] && $finalpassword == $log['password']){ // Får tilsendt nogle $_SESSION['xxx'] som giver adgang til siden. } else { // Bliver smidt ud. }
--- slut ---
Hvad synes du om denne måde så?
Mht. Hvem der har adgang til de personfølsomme data, så har jeg snakket med min udbyder om at få lavet en databahandler aftale, som skal inkl. følgende:
Alle mine data'er skal placeres på en dedikeret server hvor der skal være en driftaftale indkluderet.
Adgangen til websiderne skal SSL krypteres.
Og så skal de lige vide hvordan jeg agter tilgangen til mine data skal sikres rent programmeringsmæssigt.
Du behøver ikke købe et SSL certifikat hvis du bare skal have krypteringen. Så kan du nøjes med bare at generere dine egne nøgler til det. Det du køber er at et andet firma bekræfter over for brugeren hvem du er hvilket jeg også helt klart vil anbefale dig.
I din løsning ser jeg allerede 2 store fejl som jeg frygtede.
1. Du udskriver fejl. Dette kan give hackere og andre onde mennesker en masse dejlige informationer om dit system.
2. Du har ikke engang de mest basale checks for SQL injections. Dette betyder at din loginløsning er fuldstændig ligegyldig og enhver der har bare lidt forstand på sql ville kunne logge ind.
Hvad ville der f.eks. ske hvis jeg nu istedet for min email skrev: ' OR 1 == 1 #
Så ville jeg få adgang som den første bruger i din database. Jeg kunne også finde på andre mere spidsfindige sætnigr så jeg kunne hive en masse dejlige informationer ud om dine brugere. Og jeg håber virkeligt ikke at den kode du har postet her er den der køres på din server for nu har du lige udleveret hele sikkerheden bag dit system til alle der kommer forbi eksperten. Du bør som minimum sløre navne på tabeller og atributter i databasen.
Så igen når du har med personfølsomme data at gøre vil jeg råde dig til at overlade det til professionelle. Og jeg mener det er for din egen skyld så du ikke kommer ud i rigtigt store problemer når nogle stjæler fra din side.
@dkfire Du har ret, jeg havde ikke tjekket variablen i hele koden. Men som du siger er min pointe bare at databasen på ingen måde er beskyttet.
Men om ikke andet kunne man bare oprette sin egen bruger via den forespørgsel og så få adgang til resten af systemnet (hvor der sikkert er nogle endnu nemmere forespørgsler).
@alex15 Du kan jo istedet for din email skrive:
'; INSERT INTO bruger (email, password, salt) VALUES ('me@example.com', 'password', 'passende_salt_værdi');
; tegnet bruges til at adskille komandoer. Du kan sagten køre flere komandoer på en gang så her opretter jeg en bruger hvor du kun regner med at jeg vil logge ind.
Hvis du skal gøre noget omkring sikkerhed er det ikke nok at nogle ser din kode igennem. Det skal være med i hele løsningen helt fra strukture af databasen og hvem der har adgang til hvad i den, til validering af brugerinputs osv.
Hvem du skal kontakte ved jeg ikke. Jeg har ikke nok er faring med hvem der er gode så det må du få nogle andre til at hjælpe dig med.
Og når der oprettes en bruger, indtastes følgende af brugerens informationer:
Fornavn Efternavn email
Derefter bliver der autogenereret en password som salt som jeg beskrev tidligere..
og bliver indsat på følgende måde:
mysql_query("INSERT INTO bruger (`fornavn`, `efternavn`, `password`, `salt`, `email`) values ('$fornavn', '$efternavn', '$finalpassword', '$salt', '$mail')") or die (mysql_error());
Er det ikke den samme måde som du beder mig om at gøre dette på?
PS. er den eneste måde hvorpå man kan få adgang til databasen, via de forskellige <form> rundt på siden?
hvordan beskytter man normalt en database så?
"Det skal være med i hele løsningen helt fra strukture af databasen og hvem der har adgang til hvad i den, til validering af brugerinputs osv."
Validering: Alle de steder hvor brugerne har mulighed for at indtaste data, bliver det sendt via en <form> som så modtager det via POST på denne måde:
Igen bliver jeg kun mere bekymret over din uvidenhed. Undskyld, det er virkeligt ikke for et genere dig men bare for at hjælpe dig med ikke at komme ud i store problemer.
Du kan jo tilgå din kode gennem alt muligt f.eks. variabler i din url eller cookies. Desuden har jeg lige demonstreret for dig hvordan man kan oprette en bruger igennem din login formular.
En smart ting ville jo være at den normale databasebruger der står for at tjekke login kun har rettigheder til SELECT og alle andre komandoer kun udføres af specielle databasebrugere specielle steder.
Før du kaster dig ud i dette projekt bør du som minimum læse alle disse artikler (bare roligt de er ikke så lange): http://www.addedbytes.com/php/ Dave Child har rimeligt godt styr på det og har skrevet nogle rigtigt fornuftige artikler.
Det genere mig på ingen måde, synes som sagt kun er det er fedt at der er folk som gider gøre mig opmærksom på disse 'problemer'. Så det skal du have tak for.
De gange jeg bruger url som en variabel, benytter jeg mig kun af tal som selve variabel fx:
?id=123
Hvis nogle ændre dette til andet end tal, bliver de smidt ud til login siden.
jeg benytter mig ikke af cookies på siden, da brugerne selv kunne gå ind og ændre i disse cookies.
Derfor jeg valgte kun og arbejde med sessions.
En smart ting ville jo være at den normale databasebruger der står for at tjekke login kun har rettigheder til SELECT og alle andre komandoer kun udføres af specielle databasebrugere specielle steder.
Alle brugere skal jo kunne kommenterer på forum'et?
Igen vil jeg lige påpege at fordi du regner med at en variabel kun er et tal betyder det ikke at den er det. Det kunne jo lige så godt være SQL kode.
Det er ret dumt at sige at du ikke benytter dig af cookies da de udgør et sikkerhedsproblem og at du derfor bruger sessions. En session styres jo af en session cookie der placeres på brugeren og derved giver anledning til 'session hijacking'. Dvs. at en hacker bare kan gætte løs til han rammer samme sessionværdi som en bruger og så har han nøjagtigt samme adgang som din bruger, helt uden at skulle tænke på nogle af dine sikkerhedssystemer. Det er ikke for sjov at f.eks. betalingssider ikke må bruge sessions hvis de skal håndtere kortdata.
Igen jeg håber du får noget ud af Dave Child, det gjorde jeg i hvert fald.
Ellers vil jeg anbefale dig at alliere sig i dit projekt med nogle med lidt mere erfaring.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
