21. februar 2003 - 15:02Der er
16 kommentarer og 1 løsning
Adgangsbeskyttelse - test sikkerheden i mit script
Jeg har skrevet dette script, som skal beskytte mit administrationssystem på mine to store sider, men hvor sikkert er det?:
<?php if ($_COOKIE['admin'] != "md5krypteretstreng") { if (isset($_POST['username']) && isset($_POST['password'])) { $encrypted = md5("$_POST[username]:$_POST[password]"); if ($encrypted == "md5krypteretstreng") { setcookie("admin", "$encrypted", time()+86400); } else { echo "Log ind informationerne var ugyldige!"; exit; } } else { echo "<form action=\"index.php\" method=\"post\">\n"; echo "Brugernavn: <input type=\"text\" name=\"username\">\n"; echo "Adgangskode: <input type=\"password\" name=\"password\">\n"; echo "<input type=\"submit\" value=\"Log ind\">\n"; echo "</form>\n"; exit; } } else { if ($_GET['logout'] == "1") { setcookie("admin", "", time()+86400); echo "Du er nu logget ud"; exit; } } ?>
På nuværende tidspunkt benytter jeg samtidig htaccess, sammen med en lidt ældrere udgave af dette script, men vil I mene at jeg med dette script kan droppe htaccess og kun benytte dette? Da jeg har fast IP, kunne jeg eventuelt implementere en funktion, som sender en e-mail til mig, hvis det ikke er min egen IP, men det skal selvfølgelig vedligeholdes hvis IP ændres, men vil I overhovedet mene at dette er nødvendigt?
- 100 point er udlovet, i håb om at sikkerheden vil være i top ;) - mere afsættes hvis nødvendigt -
du kan vælge at lade din cookie kun sende over ssl, ved at tilføje et parameter til setcookie() derudover er der en potentiel fare for at en brugers password kan opsnappes når han indtaster/sender det fra sin browser til din server (forudsat at du kører over alm. http protokol, hvad du jo nok gør) ... det kan du undgå på to måder ; enten kører du alt over ssl (eller ihvertfald login-delen) ... eller også smider du et javascript på din login-side, der md5 krypterer password'et inden det sendes. (jeg ved at jeg har set såddan et script engang, men kan ikke lige huske hvor ... brug google)
men alt det er selvf. udslag af paranoia ... vi taler om folk, der virkeligt er ihærdige, hvis de skulle bruge de "huller"
iøvrigt skal du lige huske på at dit script kun beskytter php-scripts ... dvs. at billeder mv. ikke beskyttes. desuden er der et lille problem i at hvis php-parseren på din server pludselig ikke virker, så vises dinne php-scripts alligevel (men det sker vist ikke bare såddan lige ... selvom jeg har hørt om det)
1: Det er jo ikke nogle specielt store sider faktisk, men jeg har det bedst hvis jeg ved at sikkerheden er i orden. SSL er jeg dog ikke så glad for, da jeg mener at man får poppet noget op på skærmen, som man skal svare ja til. Jeg er udemærket opmærksom på at det kan opsnappes når det sendes til serveren, men det er også derfor jeg har valgt at kryptere alt hvad der lægges i cookien.
2: Ja, det er selvfølgelig paranoia, men det er altid mere betryggende at vide at man har gjort det på den bedste måde, med de mest almindelige "værktøjer".
3: Det vil der selvfølgelig altid kunne ske, men det skulle være utroligt at det sker lige samtidig med at en eventuel hacker er i gang. :P
Men du mener ikke mit nuværende script på nogen måde kan forbedres ellers? I den lidt ældrere version, krypterede jeg kun adgangskoden og splittede delene op når det skulle tjekkes, men nu har jeg altså valgt at samle det under én krypteret streng, da der kun er det ene brugernavn og adgangskode. Denne gang jeg har også valgt at benytte $_XXX systemet, som jo skulle give meget bedre sikkerhed - i sidste version kunne man være heldig at finde brugernavn og krypteret adgangskode i cookien og samle det i adressebaren og via GET kunne logge ind.
jeg går ud fra at du også har noget kode, der henter bruger+password ud fra db ... den kunne også indeholde nogle sikkerhedshuller. prøv lige at smide den op engang
Hvis du kun vil bruge det fra din IP, kan du jo starte med at lade en .htacces bestemme at KUN din IP må komme ind:
Order Deny,Allow Deny from all Allow from din-faste-ip Options None
Options None forbyder browsing af dirs. dernæst, vælg at kalde dine filer for "noget helt vildt", f.eks. sukos.php :O) altså IKKE noget med index, admin, include o.s.v. Skift gerne dine dir/filnavne ud, indimellem.
Og hvorfor kun bruge cookies? sessions synes jeg er klart er at foretrække! Evt. mixet med cookies
Hvis du så vil bruge sessions, så brug en ini_set til at definere et underdir i dir'et, hvor sessiondata skal gemmes, altså IKKE serverens default dir
Og hvis det er din egen server, så lav et subdomæne, som har server-root uden for det normale server-root. Altså ikke bruge et underdir man kan komme ind i via ip-adressen
hmm, det var så lidt forslag, men det kører jo så osse kun på http! :O)
swaxi -> Nej, det har jeg jo netop ikke, da jeg kun har det ene brugernavn og adgangskode. Derfor har jeg krypteret det orginale brugernavn:adgangskode, som jeg så tester brugerinput på. :)
sukos -> Meningen er jo netop at slippe af med htaccess og så skulle jeg gerne kunne logge ind fra enhver computer, men laver jeg så jeg modtager en e-mail når det ikke er min egen IP der besøges med, så vil jeg jo ikke modtage så mange e-mails alligevel. Men selvfølgelig, det ville måske være en mulighed at lade være med at bruge index.php som filnavn, men det gør det jo noget lettere at komme til siden, hvis jeg ikke skal skrive filnavn. Men det jeg jo også har tænkt mig er jo netop at lave et godt og sikkert PHP loginsystem. Ja, sessions ville selvfølgelig være en mulighed, men jeg synes allerede jeg er godt trær af at jeg skal logge ind med htaccess hver gang :/
Men tak for dine forslag, men du synes altså ikke der er noget at forbedre i mit nuværende script? (Dette gælder også jer andre!;)
Jeg har tænkt over det med sessions og tror måske nok jeg kan leve med at skulle logge ind for hvert besøg, men er det korrekt forstået at det eneste den besøgendes computer modtager, er et unikt ID som ændrer sig for hver sidevisning? Dataene gemmes så midlertidigt på serveren? I så fald kan en given cracker jo ikke bruge det til meget, hvis overhovedet noget...
Kom gerne med argumenter for og imod cookies og sessions ;)
ved en session, modtager klienten et unikt id. dette id sender den (automatisk) til serveren hver gang den henter en ny side (og indtil browseren lukkes == sessionen stoppes). id'et ændrer sig ikke sålænge session'en kører. typisk vil serveren beholde en session i et foruddefineret tidsrum (jeg vil tro en times tid oder so) før den glemmes/slettes fra serveren. serveren gemmer data i en fil som kun den selv/phpscriptet har adgang til og bruger det unikke id til at finde denne fil.
derfor _kan_ en hacker opfange et session-id ved at lytte til kommunikationen mellem klient og server (det sendes jo med hver gang klienten laver en forespørgelse) ... men som sagt ... det kræver 1) at en hacker har interesse nok i at hacke dig til at han gider at overvåge din server og 2) at han véd hvordan man så gør det (jeg aner det faktisk ikke selv ...)
iøvrigt tror jeg nok at serveren yderligere kun vil acceptere en session fra den IP som den oprindligt kom fra, men der er jeg nu ikke helt sikker i min sag. hvis det _ikke_ er tilfældet, kunne du jo gøre det at du ved hver visning checker at klientens IP er den samme. (men det kan vist iøvrigt også maskeres på en eller anden måde ... såeh ...)
det korte af det lange er ... med mindre du bruger en envejskryptering af alle data, der sendes mellem server og klient (dvs. SSL) så er du ikke home-free ... men det er næppe sandsynligt at det vil være et problem for dig, idét det trods alt kræver mere end de almindlige drengerøve at hacke sig ind og du vil næppe tiltrække de "rigtige" hackere ...
swaxi -> Det vil vel heller ikke sådan lige være muligt for crackeren at bruge dette ID til noget, da han jo ikke bare kan lægge det ind i en URL, da PHP kun accepterer det fra $_SESSION
Indtil videre har jeg ændret mit script til dette:
#1: Hvad siger I til den så? - kan I se nogle sikkerhedshuller? (Grundigt - det er derfor jeg giver alle de point for det jo - kan sagtens sætte den op på 200) #2: Må man tjekke om en variabel har en bestemt værdi, hvis den ikke eksisterer, eller SKAL man køre isset() først? (Rent "teknisk")
Hermed oppe på 200 point og så håber jeg snart der sker noget her... #3: Der er noget med at man skulle kunne skrive PHP koder i login-felterne, men efter hvad jeg har fundet ud af, så fortolkes det ikke af PHP, så er det sikkert nok?
Det er da utroligt... Jeg laver nogle rimelig klare spørgsmål og sætter 100 point mere af og alligevel er der ingen reaktion. Så nu gider jeg ikke mere; har fået svar på mine spørgsmål på en nyhedsgruppe i steden og derfor trækker jeg de 200 point i mig igen! Nu har I fået chancen; sådan er det bare.
Synes godt om
Ny brugerNybegynder
Din løsning...
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.