6 sikkerhedsråd til dit Laravel-projekt

Mange digitale løsninger lider af legacy-kode, tidspres og generelt manglende fokus på sikkerheden. Det åbner små sikkerhedshuller, som er nemme at gå til for IT-kriminelle. Her giver vi 6 sikkerhedsråd til dit Laravel-projekt.

Af Jens Just Iversen

I takt med den øgede digitalisering, bliver IT-kriminalitet et stadigt voksende problem. Mange digitale løsninger lider af legacy-kode, tidspres og generelt manglende fokus på sikkerheden. Det åbner små sikkerhedshuller, som er nemme at gå til for IT-kriminelle.

Også som website-indehaver er man skrøbelig overfor angreb og man bliver nødt til at tænke det ind i sin udvikling. Jeg vil her give 6 bud på sikkerhedsråd, der er nemme at komme i gang med.

Rådene er møntet på udvikling med PHP frameworket Laravel, som er det vi beskæftiger os mest med hos ephort. Rådene kan dog også bruges generelt indenfor webudvikling.

#1 Brug de rigtige HTTP methods

Når du designer routing af dine web eller api-endpoints i dit projekt, skal du angive hvilken HTTP-metode de skal blive kaldt med. Du kender sikkert de mest normale GET, POST, PUT og DELETE metoder, men hvorfor er det vigtigt at bruge de rigtige?

Udover en række fordele ift. caching, webcrawlers håndtering af links og de fordele det giver ved navngivning af RESTful routes er der vigtige sikkerhedshensyn at tage.

Hvis du for en nemheds skyld vælger at lave routen til at slette sin egen bruger på en side som en GET-route til URL’en /user/delete, for hurtigt at kunne lave en knap på brugerens profil, der blot linker til URL’en, åbner det allerede for nogle problemer.

Selvom controller-metoden kun kan slette den aktuelle autoriserede bruger på den URL, vil det være nemt for andre brugere, at slette andres profiler. Det eneste det kræver er, at få andre brugere til at indlæse den givne URL, bevidst eller ubevidst.

Er det et forum, kunne du skrive et indlæg med et <img>-tag, der i stedet for en billedurl i src-parametren, kalder https://minside.dk/user/delete. Når andre brugere vil læse indlægget, slettes deres bruger idet deres browser prøver at vise billedet.

Man kan også sende et kamufleret link den givne bruger med teksten “Hej Per, ser lige denne sjov kattevideo: http://bit.ly/2CR5eKZ“. Den forkortede URL linker så til minside.dk/user/delete. HTTP metoder sikrer mod denne slags misbrug.

#2: Slå debug information fra på offentlige sites

Debug information er ligeså uundværlig, mens man udvikler et site, som det bør være undværligt, når et site er live.

Det er nemt at trigge en fejl på en side, og skrives en hel stacktrace til skærmen, så har angriberen en stor indsigt i sidens struktur og i nogle tilfælde kan adgangsoplysninger, så som brugernavne, adgangskoder, hemmelige nøgler og password salts, blive skrevet på skærmen direkte til angriberen.

I Laravel er det nemt at opsætte genkendelse af forskellige server-miljøer, sådan at man ikke skal tænke på at manuelt slå debug-information fra, når koden går fra et udviklingsmiljø til et produktionsmiljø.

#3: Beskyt forms med CSRF-tokens

CSRF står for cross-site request forgeries, og beskriver en situation, hvor angriberen udfører en handling på vegne af en autoriseret bruger. Det er for eksempel et sådant angreb, der er beskrevet i råd #1, hvor angriberen misbruger offerets autoriserede browser-session, til at slette brugeren via en GET url.

Det samme kan i princippet ske for POST forms, og det er derfor vigtigt, at man beskytter sig mod disse CSRF angreb.

Laravel kommer som udgangspunkt med beskyttelse i form af CSRF-tokens, der skal medsendes alle form forespørgsler.

Blade direktivet @csrf tilføjer automatisk et hidden input felt med CSRF-tokenet.

Når Laravel modtager en form forespørgsel tjekker middlewaret VerifyCsrfToken, om dette unikke token matcher det token, der er udstedt til den givne brugersession.

Middlewaret er tilknyttet middlewaregruppen “web". Selvom middlewaret kan ekskluderes i specifikke kald, er det vigtigt, at det er aktiveret i så vidt muligt omfang, og at der i øvrige tilfælde er tilstrækkelig sikkerhed på anden måde.

#4: Beskyt logins mod brute force angreb

Brute force logins er et sikkerhedsangreb, hvor man ved at “gætte" på alle kombinationer af et password opnår adgang til en andens person konto. Disse gæt foretages automatiseret.

I august 2014 blev Apple udsat for et sådant angreb, hvor flere kendtes private billeder blev offentliggjort, da det igennem en API var muligt at lave brute force angreb mod iCloud konti.

Siden Laravel 5.1 har trait’et ThrottlesLogins været tilknyttet LoginController, der kommer med den standard LoginController, der håndterer login til web applikationen. Dette trait sikrer, at det kun er muligt at lave begrænsede forkerte loginforsøg i streg og dermed umuliggører brute force login.

Tilbyder du login på andre måder end gennem LoginController, skal du derfor sikre dig, at der også tages højde for brute force angreb i disse indgange. Det kan for eksempel være, hvis din Laravel applikation har mange år på bagen, og derfor har været igennem Laravel opgraderinger for at krydse Laravel version 5.1, hvis du har måtte åbne for bruger autorisering for andre programmer eller lignende.

#5: Vær kritisk overfor eksterne pakker

Eksterne pakker installeret igennem f.eks. composer eller npm kan være en stor hjælp og lette arbejdet med projektet betydeligt. Oftest findes der pakker til netop den problemstilling du står overfor og i løbet af få minutter har du installeret pakken i projektet og er i gang med at bruge den.

Pakkerne kan ligeledes bero på andre pakker, og det betyder i praksis, at du ved at bruge en ekstern pakke tilknytter rigtig mange forskellige personers arbejde i din kode. De fleste pakker er sikkert sikkerhedsmæssigt i orden, men nogle pakker er ikke og det vil derfor åbne et sikkerhedshul i dit projekt uden du er klar over det.

Et sådan scenarie er beskrevet her https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5, hvordan en ekstern pakke kan indeholde skadeligt kode, der høster uvidende brugeres kreditkortoplysninger på de sider, den bliver brugt - direkte som indirekte igennem andre eksterne pakker.

Det kan derfor være en rigtig god idé, at læse koden til den eksterne pakke igennem, gå igennem pakkens repository for at se, hvordan pull requests bliver accepteret og tjekke de pakker, som den eksterne pakke afhænger af, ud, inden en pakke ukritisk importeres til dit projekt.

#6 Content Security Policy

Content Security Policy er en sikkerhedsstandard, der sikrer, at kun de domæner du angiver kan bliver kaldt af browseren. Det beskytter derfor mod angreb, der kalder eksterne sider som for eksempel beskrevet i forrige råd.

Content Security Policy - eller bare CSP - er indskrænkende for din sides bevægelighed, og det kræver derfor en vis grundighed og test-arbejde ved konfigurationen af din CSP, for at din side fortsat kan kalde eksterne services så som Google, CDN’s osv.

Vil du opsætte CSP, giver den danske udvikler Ole Michelsen her en grundig guide til de fleste setups, som kan være en god hjælp: https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html.

Afslutning

Selvom sikkerhed i Laravel-projekter oftest ligger til højrebenet er frameworket ikke stærkere end dem der bruger det. Det er derfor vigtigt løbende at have sikkerheden i mente, når et projekt udvikles og ikke mindst udvides.

Har man ingen fjender er man sikkert ikke i farezonen, men at have godt styr på sikkerheden sikrer alligevel, at uheldige episoder sker i fremtiden - hvis ikke af fjender, så af automatiske bots og scripts. Og så giver det bare en bedre nattesøvn :-)