Denne artikel er baseret udfra mine egne oplevelser med nogle sider jeg har programmeret i PHP. Jeg har været ude for at nogle brugere på siderne misbrugte funktionerne som de ikke havde lov til, og derfor har jeg nu besluttet mig for at skrive denne artikel om ting du skal huske hvis du vil lave en sikker hjemmeside.
Jeg ved godt at artiklen er lidt overfladisk, men den er også mere tænkt som en slags huskeliste. Desuden er der sikkert andre metoder til at sikre siden, men disse nedenstående metoder har sikret mine sider imod misbrug.
SERVEREN ER NR. 1
Vil du lave en sikker side så skal du starte med at konfigurere opsætningen på serveren. For at undgå sql-injection er der en funktion ved navn "magic_gpc" som skal slås til. Når denne er slået til så er det ikke længere muligt at bruge '-tegnet. Et kendt sql-injection eksempler er brugen af: 1' OR '1' = '1.
Dvs. har man ikke sikret sig imod sql-injection så kommer der til at stå dette hvis man prøver at logge ind:
//database_forbindelse_inden
$result = mysql_query("SELECT * FROM tabel WHERE brugernavn = '1' OR '1' = '1' && kodeord = '1' OR '1' = '1'");
exit;
?>
Dvs. Misbrugeren kan nu logge sig ind på din side, uden egentlig at have oprettet en bruger eller angivet korrekt brugernavn og kodeord.
En anden vigtig ting er at rette register_globals til OFF. Ved at sætte denne funktion på OFF, så specificerer man sine variables. Dvs. $_POST['felt'] kun kan komme fra en form med method med POST. Havde register_globals derimod stået på ON, så ville $felt kunne indeholde information fra forms, arrays og meget andet.
SESSIONS ELLER COOKIES?
Session og cookies er begge en slags små "pakker" som kan gemme information. I almindelig login-scripts, er det meget normalt at folk enten benytter sig af Cookies eller Session - Men det ene er mere sikkert end det andet!
Session og cookies har altså det samme formål, minder meget om hinanden, men alligevel er der forskel. Den største forskel er at cookies bliver gemt på din egen computer som små filer, og sessions bliver gemt på selve serveren som du er inde på. Man skal så vidt muligt enhver brug af cookies når det kommer til login-scripts, da man kan manipulere med cookies, og det er muligt at se indholdet af en cookie.
Vil du der imod lave et "gem login" eller på anden måde genkende brugeren selvom browseren er lukket ned og startet op igen, så er det cookies du skal have fat i. Cookies har den fordel at de kan sættes til først at blive automatisk fjernet fra din computer efter et vis antal tid/dage/år osv. MEN! Samtidigt vil jeg sige, at skal man lave et en cookie i forbindelse med "gem login"-funktionen, så skal man altid først md5 (eller på anden måde) skjule sit kodeord.
Eksempel på md5-envejskryptering:
$str = 'hej hej';
$str_md5 = md5($str);
echo "Her er hej hej med md5: $str_md5";
exit;
?>
XSS (Cross Server-Scripting)
XSS er et andet "hul" som folk ofte glemmer at sikre sig imod. Løsningen på XSS er heldigvis ret simpel, men har man nu en hjemmeside bestående af mange 100 sider kan det godt være et større arbejde. Men det er jo bl.a. derfor at jeg har skrevet denne artikel, så folk netop husker at lave sikker programmering lige fra starten.
Navnet "Cross Server Scripting", siger lidt om hvad dette hul handler om. Her har "misbrugeren" nemlig mulighed for at gemme et script i din database/tabel, og når det aktuelle felt bliver trukket ud i en ganske ren echo-streng som fx:
//database_forbindelse_inden
$result = mysql_query("SELECT * FROM tabel");
$row = mysql_fetch_array($result);
echo $row['xss-feltet'];
exit;
?>
I $row['xss-feltet'] kunne misbrugeren evt. have tilføjet dette javascript som ved åbning straks vil åbne en alert/popup med teksten "Din sikkerhed er ikke i top":
alert ("Din sikkerhed er ikke i top")
</script>
Når brugeren åbner denne side hvor dette database-udtræk finder sted, så kan det være at misbrugeren har indtastet en kode så din egen bruger bliver slettet, sender ufrivilligt informationer til misbrugeren, sletning af hjemmesiden og mere andet. Kortsagt så er dette noget som man skal være særlig opmærksom på.
Løsning var som sagt simpel, og det handler om at få PHP til ikke at udføre HTML/programmering som bliver udskrevet via echo.
Her er et eksempel på en løsning:
//database_forbindelse_inden
$result = mysql_query("SELECT * FROM tabel");
$row = mysql_fetch_array($result);
//strip_tags fjerner alt kode fra database udtrækket, undtagen <br> og (I dette eksempel)
$renset_echo = strip_tags($row['xss-felt'],"<br>[i]");
echo $renset_echo;
exit;
?>
[i]Man kan også bruge htmlentities() og nogle andre funktioner.
SIKRE SIG IMOD IFRAME-HACK (SPECIFIK XSS)
Er misbrugeren rigtig slem, så kan personen finde på at oprette en side på en anden server som indeholder en skjult iframe. Denne iframe kunne fx se således ud:
Her skal man forestille sig, at brugeren allerede har logget sig ind på din hjemmeside, og lige nu er der en session som indeholder brugeren unikke id fra databasen.
Kigger man i iframe-koden, så kan man se at "misbrugeren" prøver at henvise brugeren til "http://www.din-egen-side.dk/ (...) Herinde kan det være at man har lavet en DELETE som ser således ud:
//database_forbindelse_inden
mysql_query("DELETE FROM tabel WHERE id = ‘$_SESSION[id]'");
exit;
?>
Dvs. Man kan ikke slette en andens bruger, og man kan selvfølgelig heller ikke slette sin egen bruger, medmindre at du er logget ind ($_SESSION[id] er sat).
Når brugeren er logget ind og $_SESSION[id] er sat for brugeren, så lad os forudsige at han på en eller anden måde modtager et link som han bare ikke kan modstå. Det kan være at der står noget med "http://www.misbrugerens-hjemmeside.dk/ (...) Alle som vil have mange penge tryk på linket". Måske er brugeren naiv (de fleste folk kender vel til når nysgerrigheden tager overhånd :), og trykker/indtaster linket og pludselig uden at vide af det, så har han rent faktisk slettet sin egen bruger.
I dette eksempel er jeg gået udfra at det var dette mål som misbrugeren havde, men det kan jo sagtens være andre funktioner på siden som han misbruger på denne måde.
Løsningen er lige rundt om hjørnet! For at sikre sig din side ikke bliver vis/udført på en andens side, så er løsningen desværre lidt mere besværlig end det foregående eksempel med XSS-hullet. Ved at lave unikke id's i links for hver enkelt bruger på siden (eller dig selv), så kan du på den måde undgå at dine funktioner bliver udført på en anden side.
Her er eksempel på et script som tjekker om brugerens session_id fra da han loggede ind er identisk med session_id i linket:
//database_forbindelse_inden
if (session_id() <> $_GET[‘session_id']) {
//fejl
} else {
//Lav funktionen
}
?>
I linket hen til funktionen skal du evt. lave det sådan her:
echo "<a href='slet_bruger.php?session_id=session_id()'>Slet din bruger, hvor du ved det!</a>";
?>
Dvs. ved at lave dette "større" arbejde, så kan misbrugeren umuligt gætte dit unikke genererede session_id fra da du loggede ind på siden/din bruger.
Synes man at session_id er lidt for langt i sine links, så kan man evt. bruge substr().
AFSLUTNINGEN
Jeg håber at denne artikel giver et lidt indblik i hvad der er specielt vigtigt at have med i sine koder, når man vil lave et rimeligt sikkert site. Har du rettelser eller noget jeg har glemt at tilføje, så er du selvfølgelig velkommen til at skrive.
Og HUSK NU! Dette er som sagt bare en slags huskeliste hvor jeg har givet små meget simple eksempler som man bedre forstår hvad jeg snakkede om.
SVAR PÅ KOMMENTARER
HVIS DU IKKE HAR EN KOMMENTAR TIL DINE POINTS OG EVT. GIVER MIG DÅRLIG KARMA - SÅ SKRID UNDERMÅLER!
FÅ DIG ET LIV, OG KOM FREM I LYSET, ISTEDET FOR AT KOMME MED NOGET KONSTRUKTIVT. LÆNGE LEVE ARROGANCE @ EKSPERTEN.DK
OG ROS TIL DEM SOM GIVER KONSTRUKTIV KRITIK!


