I de senere år har der været en drastisk udvikling. For 5-10 år siden var 60-70% af sikkerhedshullerne på netværk/firewall siden og 30-40% var i web-applikationer. I dag er det omvendt ca. 65% af alle sikkerhedshuller ligger i web-applikationerne og omkring 35% i netværk/server.
Derfor er det vigtigt at kende nogle metoder til at sikre sine web-applikationer mod angreb. Jeg har herunder listet en række af de mest almindelige angreb og beskrevet hvordan man undgår dem.
CROSS SITE SCRIPTING (XSS):
XSS går kort sagt ud på at en hacker får mulighed for at køre scripts på din server. Det kan for eksempel være et script der sender brugerinformation på alle der besøger sitet videre til hackeren.
Al data der kommer fra querystrings, formularer, cookies osv. skal valideres. F.eks. skal et telefonnummer kun indeholde tal og der skal være 8 cifre.
Metoderne htmlspecialchars(), htmlentities() og strip_tags() skal benyttes på alle data som føres gennem systemet. Vær dog opmærksom på at htmlentities fjerner alle danske tegn (som f.eks. æ ø å) fra teksten.
Hvis man laver links eller benytter sig af querystrings bestående af dynamisk data skal urlencode() og urldecode() metoderne benyttes.
if (!eregi("^[0-9]{8}", $tlf)){
echo = "Det indtastede tilfnummer: ".strip_tags($tlf)." er ikke gyldigt";
} else {
echo "<a href=nextpage.php?tlf=".urlencode($tlf)."/>Gå til næste side</a>" ;
}
SQL INJECTION:
SQL injection opstår når en hacker får mulighed for at eksekvere kode på din database. Konsekvenserne ved et SQL injection angreb kan være lige fra at hele din database bliver downloadet til at hackeren får mulighed for at eksekvere filer på din webserver.
For at undgå SQL Injection skal magic_quotes_gpc være slået fra i din php.ini fil. Desuden bør alle DB forespørgsler benytte mysql_escape_string() hvis der er dynamisk data indeholdt i forespørgslen. Desuden skal alt dynamisk indhold omsluttes af -> ´
Man bør altid lave dobbelt tjek på om den nu også er den rigtige bruger der henter informationer. I eksemplet overfor vil man, som bruger kunne sende et telefonnummer afsted, som ikke er ens eget, og udfra det få alle informationer fra tabellen "users" om en anden bruger end en selv. Hvis man udvider det ovenstående kald med en "AND userID = $loggedInUser" vil man sikre sig mod det problem.
COOKIE POISONING OG SESSION HIGHJACKING
Cookie poisoning og session highjacking går ud på at en hacker manipulerer eller stjæler dine cookies/sessions. Cookies og session id's benyttes ofte til at gemme på informationer om brugeren. Disse informationer kan give adgang til en hacker, hvis man ikke håndterer dem rigtigt.
Generelt set så gælder de samme regler som beskrevet under Cross Site Scripting, valider indholdet! Du bør dog kryptere indholdet af cookies og session id's hvis de indeholder informationer om den besøgende.
INITIALISER VARIABLE:
Det er fornuftigt at initialisere sine variable. Hvis register_globals ikke er slået fra i din php.ini fil initialiserer PHP automatisk variable. Hvis en given variabel ikke er blevet initialiseret før den bliver brugt kan der opstå situationer, hvor brugeren kan kaste en uønsket værdi på den variabel. F.eks. kan med en querystring kaste en værdi på en variabel som ikke bliver initialiseret. Forestil dig at $superuser variablen herunder ikke bliver initialiseret, så vil man i visse tilfælde kunne skaffe sig adgang blot ved at benytte en querystring: /filename.php?superuser=true
if( logged_in() ){
$superuser = true;
}
FILHÅNDTERING:
Include, require samt alle andre metoder til at åbne eller læse filer kan udnyttes hvis de åbnes vha. dynamisk data. I dette tilfælde bør man benytte sig af en kombination funktionerne realpath() og basename() for at sikre sig at det er den korrekte fil man er ved at åbne.
$temp = basename(realpath($filename));
if ($filename != $temp){
echo "BAD file!";
} else {
echo "GOOD file!";
}
Desuden bør man ved fil-uploads benytte sig af funktionerne: is_uploaded_file() og filesize() for at sikre at filen der behandles rent faktisk er en uploaded fil og at filens størrelse er rigtig.
Det er en dårlig ide at oprette/uploade/kopiere en fil og først bagefter sætte adgangsrestriktioner på. Der kan opstå situationer, hvor en given bruger får adgang til filen i det øjeblik hvor den stadig ikke er skrivebeskyttet. Løsningen på dette er at benytte funktionen umask(), som sørger for at sætte adgangsrettighederne før filen oprettes/uploades/kopieres. Man skal dog være forsigtig med umask(), da man kan slette filer vha. denne funktion. Hvis man kalder umask() med dynamisk indhold er det derfor meget vigtigt at lave validering af input. Kig eventuelt på chmod() funktionen, den er i mange henseender et godt alternativ.
FORNUFTIGE LINKS:
Følgende sider indeholder supplerende oplysninger og dokumentation af nogle af de ting jeg ikke har gennemgået her.
- http://www.php.net/ (...)
Online dokumentation for PHP - For at få yderligere information om alle de funktioner der er nævnt i denne artikel så søg efter funktionsnavnet på denne side.
- http://www.php.net/ (...)
Documentation for regular expressions i PHP.
- http://phpsec.org/ (...)
Mere grundig gennemgang af sikkerhed i php.
- http://dk.php.net/ (...)
Mere grundig gennemgang af sikkerhed i php.
- http://www.webcafe.dk/ (...)
En side med en grundlæggende beskrivelse af .htaccess og lidt om hvordan man krypterer.
- http://www.php.net/ (...)
God gennemgang af file-uploads, der er også eksempler på validering.
IØVRIGT:
Tak for kommentarerne! Jeg vil løbende forbedre denne artikel og lave nogle af de udvidelser og rettelser som i foreslår.
Jeg har valgt ikke at gennemgå de forskellige funktioner, de er beskrevet meget grundigt på php.net og andre sites og der er ingen grund til at jeg gentager noget der allerede er godt beskrevet.


