LIVE ANTIVIRUS SOFTWARE IN PHP

LIVE ANTIVIRUSPROGRAM I PHP

LIVE ANTIVIRUS SOFTWARE IN PHP

EXAMENSARBETE INOM HUVUDOMRÅDET DATAVETENSKAP GRUNDNIVÅ 30 HÖGSKOLEPOÄNG

HENRY HUYNH

Sammanfattning

Syftet med detta arbete är att undersöka hur WordPress påverkas i prestanda med plugin installerade med ett live-antivirusprogram som körs i bakgrunden. Live- antivirusprogrammet söker igenom koder i webbsidan efter säkerhetsrisken base64.

Säkerhetsriskerna visas senare detaljerade i en lista vart i sökvägen samt fil som blivit infekterad. Dessutom med hjälp av en tidtagarur beräknas start-sluttid för varje mätning av svarstid.

Resultatet från experimentet visar att live-antivirusprogrammet inte har sådan stor påverkan hos prestandan då plugin är syftet till att svarstider blir olika.

Nyckelord: [Antivirus, Live, CMS-verktyg, PHP]

Innehållsförteckning

1. Introduktion...3

2. Bakgrund ...5

2.1 CMS (Content Management System)...5

2.3 Plugins... 7

2.4 Sårbarheter, Datavirus och Antivirus...8

2.5 Base64 - Säkerhetsrisk...10

3. Problemformulering...11

3.2 Problem... 11

3.3 Syfte... 11

3.4 Frågeställning...12

3.5 Hypotes...12

4. Metodbeskrivning...13

4.1 Utvärderingsmetod...14

4.2 Alternativa Metoder...14

4.3 Forskningsetiska Aspekter...14

5.Genomförande/Implementation/ Projektbeskrivning ...16

5.1 Förstudie...16

5.1.1 Säkerhetsrisker ...17

5.2 Implementation av program ...17

5.2.1 Genomsökning av kod...17

5.3 Progression...18

6.Pilotstudie...20

6.1 Svarstidmätning...20

6.2 Experimentell Miljö...21

6.3 Test av mätning...21

6.4 Presentation av experimentet...24

7. Utvärdering...36

7.1 Sammanfattning...36

7.2 Analys... 36

7.3 Resultat ...36

7.4 Slutsatser...37

8. Avslutande diskussion...38

8.1 Diskussion...38

8.2 Framtida arbete...38

Referenser ...39

1. Introduktion

CMS-verktyg används dagligen av bland annat bloggare och även verksamheter som driver e-handel. Det finns säkerhetsrisker bland CMS-verktyg och deras insticksprogram vilket togs upp av Shar, Hee, och K.T (2011) i sin artikel. I artikeln beskrivs det att säkerhetsrisker är ett stort problem bland datoranvändare. Problemet som ligger bakom detta är att folk med goda intrångskunskaper kan utnyttja situationen och på så sätt påverka användaren på olika sätt. Målet för utvecklare är att är att minimera riskerna för användarna vid användning av CMS-verktygen och deras insticksprogram med hjälp av ett säkrare alternativ som ett antivirusprogram. Ett säkrare alternativ skulle kunna exempelvis vara ett antivirusprogram som är skapad med programmeringsspråket PHP. Det är inte många antivirusprogram som används inom CMS-verktyg som kan hitta säkerhetsrisker som kan vara främst hot mot användare.

Problemet med att använda sig av CMS och insticksprogram är att de är alltid ständigt uppdaterade, vad som behövs göras att tillämpa en egen injektion av en säkerhetsrisk. En funktion kommer att skapas som ser till att hämta all kod som finns. Funktionen kommer att gå igenom koden, rad för rad för att försöka hitta funktioner eller metoder som har att göra med säkerhetsriskerna.

Genom att kolla noga och gjort flera testfall på samma plugin ett fåtal gånger kommer det en fundering om det kan bero på antal rader kod (inom filer) på plugin som kan ha påverkat svarstiderna.

2. Bakgrund

2.1 CMS-verktyg (Content Management System)

Ett CMS-verktyg är ett färdigutvecklat idé av en hemsida där programmeringsspråk och design redan är skapade från grunden, vilket man kan se i figur 1. Enligt Rainville-Pitt, D

´amour och J-M.(2009) används CMS-verktyg (Content management system) för att underlätta för en utvecklare att administrera en hemsida och dess innehåll. De utmaningar som kan förekomma med ett CMS-verktyg är att utveckla kreativa, användarvänliga lösningar enligt Rainville-Pitt et al (2009).

Figur 1: Administrativ panel inom CMS-verktyg verktyget WordPress

Ett annat problem med CMS-verktyg är att det inte går att anpassa webbsidan för människor med svårigheter till att använda sig utav internet det vill säga personer med någon form funktionshinder.

HyperText Markup Language(HTML) är ett annat sätt att utveckla webbsidor på, som även har andra skillnader i jämförelse med CMS-baserade webbsidor.

Utifrån Patel, Rathod, V.R, och Patrikh(2011) forskning med CMS är det enkelt att utveckla och inte så tidskrävande att skapa webbsidor om man tar och jämför det med HTML som byggs från grunden. CMS har som tidigare nämnt alltid redan förprogrammerat så det enda utvecklaren behöver ha är en vision av hur användaren vill att hemsidan ska se ut. Det behövs inga förkunskaper inom programmering då alla funktioner är färdigimplementerade.

CMS-verktyg är med andra ord det bästa alternativet för att skapa stora hemsidor med applikationer som kan generera flera sidor. Exempel på CMS-plattformar är Wordpress, Drupal eller Joomla med mera.

Figur 2: Default tema i WordPress

CMS-verktyg kan anses som ett billigare alternativ för att skapa en hemsida. Men om en inte vet så kan det finnas dolda kostnader som kan göra att det i slutändan blir samma slutsumma som om någon annan hade gått till en professionell webbyrå. Anledningen till att summan kan bli högre än väntat är för att genom att implementera applikationer så som , t.ex. betalning, kassa och beställningsfunktioner kostar. Om du är en person som driver en verksamhet via nätet är det viktigt att ha en professionell webbsida som ger dina besökare en känsla av trygghet.

Enligt Tian och Li's (2009) artikel om kundens bemötande och hur dem interagera med en webbsida har kunderna och besökarna en bild av hur en webbsida ska vara. Den ska ge ett seriös intryck, vara innehållsväckande, ha korta svarstider vid navigering och tjänster som kunderna har behov av. Möter webbsidan dessa förväntningar som ställs av besökaren så utvecklas det en trygghetskänsla mellan kunden och verksamheten. Här har CMS-verktyg en klar fördel gentemot HTML eftersom CMS-verktyg är redan färdigbyggt och att utvecklaren knappt behöva lägga tid på att utveckla sidor. Om vi utgår från att bygga en hemsida från grund genom att använda sig av HTML kan det även bli svårigheter när det kommer till design. Det krävs mer tid att designa en sida genom att använda sig av HTML men med CMS är det enkelt att ladda upp bilder och placera de hur man vill genom att använda sig av administrativ panel(Se figur 1)

Figur 3: Exempel på WordPress med färdiginstallerad tema

Koskinen, Petri och Ville (2012) gick in djupare i CMS-plattformen WordPress. WordPress går att likna vid Windows-programmet Microsoft Word. Både Wordpress och Microsoft Word har färdiga färdiga mallar för dokument där radavståndet är färdigt och förprogrammerat för att det ska vara lättare att läsa ett dokument. Man kan skriva text, lägga in bilder och även länkar. Med Wordpress publicera sina dokument på nätet direkt vilket gör Wordpress till ett populärt verktyg bland bloggare och sociala medier.

Patel, Rathod, V.R, och Patrikh (2011) skrev in liknande artikel som Koskinen, Petri och Ville (2012) om att WordPress var en grundplattform för bloggare. På senare år så har WordPress har en större målgrupp, där bland annat e-handelsbutiker ingår. E- handelsbutiker kan använda/installera WordPress färdiga insticksprogram, exempelvis betalningssystem. Möjligheterna är oändliga med WordPress tack vare deras insticksprogram som kan gynna alla användare.

2.3 Plugins

Plugins, på svenska även kallat för insticksprogram är moduler i datorprogram som installeras i efterhand. Plugins gör är att en hemsida får fler olika funktioner istället för bara text, exempelvis betalningssystem som Paypal(se figur 4). Plugins går att ladda ner gratis eller mot betalning.

WordPress har ett brett sortiment med plugins som är enkla att installera. I vissa fall kan ett plugin fungera som en länk. Vilket är ofta fallet e-handel, i en e-handelsplugin kan användaren exempelvis bli omdirigerad när användaren skall betala via sin bank eller annan betalningstjänst.

Figur 4: PayPal plugin

Det finns även andra plugins med olika funktioner. Exempelvis på en annan plugin kan vara en klocka som gör en nedräkning för start av en rea inom e-handel eller en vanlig klocka inom en hemsida som visar lokala tiden som kan ses i figur 5.

Figur 5: Exempel på vad för plugins som finns i WordPress

Koskinen et al.(2012) säger att plugins som finns tillgängliga via WordPress är kända för att ha säkerhetsluckor. I dagsläget finns det inget program i WordPress som söker igenom säkerhetsluckor när man laddar ner ett plugin, så som i ett antivirusprogram.

2.4 Sårbarheter, datavirus och antivirus

I Koskinen et al. (2012) artikel om säkerhetsluckor inom plugin beskriver de om vilka skador som kan åstadkommas av ett plugin om man inte är skyddad. Dessa skador visar sig genom skadliga koder som kan leda till att privat information om dig och din dator kan hamna i fel händer. Även Shar et al. (2011) diskuterar om säkerhetsriskerna hos plugins som har bra betygsättning eller recensioner kan vara vilseledande. Plugins med hög användarbetyg betyder inte att det är verifierat som ett säkert plugin. Dock finns det även nackdelar med användarrescenioner eftersom många förlitar sig alldeles för mycket på dem.

Ibland kan ”inkräktarna” själva använda sig av ”forumet” och skriva väldigt positiva saker om programmet för att lura användare att ladda ner och det finns även fall där konkurrerande företag skriver negativt om utvecklarens program bara för att få mer användare av sitt egna program. Det som menas är att det alltid kommer finnas personer som skriver negativt för sin egen vinning och ibland för att varna de andra användarna för något oroväckande. Mudambi och Schaff(2010) skriver de om användarbetyg som fungerar ungefär som ett forum där personer kan recensera de olika plugins som finns tillgängliga för nedladdning. I artikeln så skriver det att dessa användarbetyg ger en slags trygghet för potentiella användare. Eftersom de kan läsa om hur andra användare upplever insticksprogrammet, samt om några har upptäckt något som kan vara oroväckande med programmet. Detta är ett problem då användaren oftast är omedveten om vad plugins kan innehålla.

Med åren som går utvecklas fler datavirus och det blir allt mer komplicerad att skydda sig emot, exempelvis trojaner som är program som finns dolt inom ett annat program eller plugin. Förändringar kommer att ske men vi som användare märker inget förrän långt efter smitt tillfället. När din dator smittas av virus så lagras sig viruset i ett program i hårddisken.

Vilket gör att när programmet exekveras så smittas viruset vidare till andra program och på så sätt förökar det sig. Datorn kan då bli långsammare, få längre svarstid och kan till slut frysa sig. Vilket gör att användaren inte kan använda sig av datorn. Till slut kraschar datorn

och är då obrukbar. I vissa fall räcker det med en omformatering av datorn och i värsta fall måste datorn slängas.

Ett exempel på ett virus med samma funktion som beskrivs i texten är, Acme. När program som har blivit smittade överförs en infektion till en annan exekveringsfil som finns i samma mapp som den smittade filen. Acme skapar en dold COM fil med identiskt namn som exekveringsfilen. I vissa fall kan viruset visa sig synligt via obegränsade och upprepande pop- ups. För att skydda sig mot dessa hot går det att installera ett antivirusprogram.

Ett antivirus är ett klientprogram som skyddar klienten. Antivirusprogrammet utför skanningar för att kolla igenom datorns lista, program, filer och media som sedan utför en inspektion som tar reda på om det finns hot eller inte.

Reis, et al.(2007) . Artikeln handlade om Browsershield som är en form av ett antivirusprogram som skyddar webbläsare mot hot. Programmet exekveras vid användning av internet och läser av alla HTML-sidor samt inbäddade script som kan vara exempelvis virus. Genom att programmet verifierar HTML-sidor och även de inbäddade scripten för att senare genomgå en säkrare process för webbläsaren. Programmet körs i bakgrunden och märks inte av användaren. Om användare besöker en hemsida med en skadlig kod så varnas användaren om att hot har upptäckts och skyddar användaren från att ta sig in i hemsidan.

Det finns ett annat antivirusprogram som har samma funktion som BrowserShield vid namn RIPS. Enligt Koskinen, et al.(2012) används webbapplikationen RIPS för att genomsöka CMS-sidor samt deras plugins. Genomsökningen sker individuellt för varje plugin, vilket gör att programmet utför en säkrare genomsökning efter hot som kan finnas i en plugin.

Figur 6: RIPS, en källkods analytiker

Enligt Ely och Adam(2010) är det viktigt att hålla insticksprogram och webbläsare uppdaterade. Det är viktigt att känna till säkerhetsriskerna i programvaror som installeras.

Är inte webbläsaren eller insticksprogrammet uppdaterade finns det en högre risk att angriparen får tillgång till användarens information. Anledningen till att det lättare förekommer angripare på äldre programvaror som saknar uppdatering är för att angriparen har fått mer tid på sig att förstå och lära sig hur de ska gå till väga.

Att förstöra lagrad data är en av det besvärligaste typer av attacker. Motivet för attackerna är inte alltid bedrägeri. Det finns de som vill förstöra för andra på grund av deras illvilja det finns också de som vill spionera på användare genom deras data. En sådant attack är även kallad för en trojansk häst enligt McDermott (1998). Trojaner är en typ av malware som oftast gömmer sig eller förklär sig till ett annat program. Trojaner ger angriparen full kontroll av datorsystemet, men eftersom angriparen inte vet att de har drabbats så manipulerar angriparen systemet genom att be offret om t.ex. upprepa sig inloggningsuppgifter fler gånger. När offret sedan fyller i sina användaruppgifter för andra gången så har angriparen fått allt de behöver.

2.5 Base64

Aw-snap beskriver på sin hemsida Aw-snap.info(hämtad 2017/06/23), säkerhetsrisker som kan förekomma i programmeringsspråket PHP. PHP är ett kraftfull programmeringsspråk som är öppet för alla att ändra. Nackdelen med PHP är att det har inbyggt base64 encode/decode kapacitet, vilket gör det lättare för angripare att ändra programkoden i ett insticksprogram. Några exempel på Base64 hot kan vara spam-meddelande, DoS attacker, nedladdning av okända filer eller exekvera Shell kommandon. Base64 kan däremot lätt upptäckas av ett antivirusprogram men det kan även räcka med att använda sig av en brandvägg. Ett av det mest förekommande problemen av Base64 finns inom CMS-verktyg, WordPress, Joomla, Drupal och med mera där plugins är ett av de lättare metoderna för angripare att injektera sin skadliga kod.

3. Problemformulering

Base64 förekommer rätt ofta bland insticksprogram, vilket vi kanske aldrig märker av när man laddar ner. För att minska riskerna för användaren så finns det något som kallas för användarbetyg där användarna recenserar insticksprogrammet. Enligt Shar et al.(2011) så ökar chanserna för att drabbas av hackers vid användning av CMS-verktyg då det enkelt går att ändra koderna i plugin till skadliga koder genom att utnyttja sig av säkerhetsrisken Base64.

3.2 Problem

Problemet med att använda sig av CMS är att det inte finns tillräckligt med säkerhet att skydda sig mot risker så som Base64 säkerhetsrisker. Ett bra skydd mot säkerhetsriskerna är att använda sig av ett kontinuerligt antivirusprogram, ett program som exekveras 24/7 i bakgrunden som blir mycket mer effektivare då det söker igenom insticksprogrammen innan nedladdningen, vilket resulterar i att programmet varnar dig för säkerhetsriskerna innan det är för sent.

Ett problem är att prestandan påverkas negativt av antivirusprogram vilket kan påverka svarstiderna negativt.

3.3 Syfte

Syftet med denna studie är att hitta säkerhetsrisker såväl som att skapa ett antivirusprogram och överse till vilken grad prestanda påverkas av att man introducerar live-antivirus som testar plugins vid varje exekvering för de WordPress-plugins som används. För att nå studien syfte ska följande frågeställning besvaras.

3.4 Frågeställning

• Hur kommer live antivirusprogrammet att påverka WordPress med fokus på prestandan?

• Hur kommer storleken på insticksprogram påverka på live-antivirusprogrammets prestanda?

3.5 Hypotes

Hypotesen är att genomsökning med live-antivirus är så snabb att svarstiderna inte påverkas. Men det kan innebära att live-antivirusprogrammet inte kommer att fånga upp alla säkerhetsrisker i en plugin, därför vill man ha en kort svarstid som möjligt.

Enligt Rajamony och Elnozahny(2001) skrev de om att sökningar i en sida oftast fördröjer svarstiden, om sökningen sker i realtid. De anser att en sådan fördröjning kan påverka användarupplevelsen negativt.

Tolia och Andersen(2006) tar de upp olika undersökningar som har gjorts av olika användare där under undersökningens gång visade det sig att användarna föredrar att svarstiden ligger under en sekund. Svarstider som är över en sekund kan få användarna att

bli missnöjda för att hemsidorna uppfattas som långsamma. För att användarupplevelsen inte ska påverkas negativt, bör därför svarstiden inte överstiga en sekund.

4. Metodbeskrivning

Genom att utföra ett experiment, kommer delar av det Koskinen et al. (2012) arbetade med från deras artikel att återupprepas. Allt detta har Koskinen et al. (2012) redan utfört och experimenterat med. De utförde experimentet genom att ladda ner ett antal plugins under användning av live-antivirus för att kontrollera säkerheten på hemsidan. Verktyget de använde sig utav var live-antivirusprogrammet vid namn RIPS. I detta arbetet kommer det att skapas ett inbäddad live-antivirusprogram i CMS-verktyget WordPress. Arbetet kommer granska säkerhetsriskerna som finns i ett plugin. Även identifiera säkerhetsriskerna och visa källan till dom i en lista. Det kommer även att finnas med en graf som visar svarstiderna vid användning av live-antivirusprogram.

Enligt Wohlin et al.(2012), så är experiment viktiga för att undersöka sin hypotes. Om de nya experimenten stödjer hypotesen, innebär det att vi har mer bevis att det går att utföra.

Metoden som kommer att skapas för att motbevisa hypotesen inom detta arbete är experiment.

Ett antivirusprogram skapad genom antingen PHP kommer att implementeras. Detta arbete inspirerades av Koskinen, et al (2012) forskning. Detta kommer vara baseline med ett live- antivirus som genomsöker säkerhetsrisker. Enligt Koskinen, et al.(2012) användes en experimentell metod där de genomsökte CMS-verktyg – sidan med en webbapplikation som heter RIPS. Enligt Koskinen, et al.(2012), så användes mjukvaran RIPS (som nämns tidigare i arbetet). Koskinen, et al.(2012) använde sig av 322 plugins som fanns med i WordPress, samt att de även körde RIPS programmet för varje enskild plugin.

Skillnaden mellan detta arbete och arbetet som Koskinen, et al (2012) utfört är att ett live antivirusprogram med programmeringsspråket PHP kommer att skapas. På detta sätt kan en detaljerad information om risken hos insticksprogrammet visas. Mätningar kommer att utföras för att visa en statistisk överblick hos CMS-verktyget svarstider. För att undersöka prestandan om det påverkas när live-antivirus är igång. En annan skillnad mellan detta arbete och Koskinen, et al (2012) är att de utförde skanningarna i offline-läge. Programmet körs en gång per plugin. Nackdelen med detta är att när programmet körs igenom en gång kan det leda till att programmet kan ha glömt kollat igenom ett par enstaka plugins. Vilket betyder att en säkerhetsrisk kan ha finnas i insticksprogrammet. Till skillnad från Koskingen, et al (2020) så kommer arbetet utföras live. Vilket gör så att den körs hela tiden under bakgrunden. Fördelen med detta till skillnad från att exekvera scanning Offline är att den inte kommer att stoppas. On-line scanning av säkerhetsrisker betyder att användaren kan få kontinuerlig feedback om säkerhetsrisker.

Exempelvis, ett klientbaserad antivirusprogram fångar upp hot. Men när det sker en uppdatering i plugins så kan inte det klientbaserade antiviruset göra något åt det. Det är då detta egen skapade live-antivirus virus kommer in för att fånga upp.

Problem som lär förekomma när man mäter svarstiden är att resultat varierar från svarstid till svarstid. Därför utförs mätningarna regelbundet. Skillnaden mellan live och offline är att nya säkerhetsrisker inte kan utvärderas vid offline-läge.

Att skapa sig av PHP som testfall, så kommer det att ge en annan överblick på hur skillnaden kan vara mellan Javascript och PHP. Ett hot mot conclusion-validitet enligt Wohlin, et al.

(2012) är om ett test får en låg statistisk styrka när testfallet utförs. Kan det förekomma en

stor risk att en felaktig slutsats dras. Genom att köra varje testfall många gånger ökar den chansen mer för ett bra resultat. Därför kommer testfall att utföras flera gånger och inte bara en gång, oavsett antal plugin.

4.1 Utvärderingsmetod

Utvärderingar kommer att utföras för att genomföra tester ett flertal antal gånger för att få fram skillnad i svarstider. Metoden kommer att användas för att få en överblick om det är storleken i plugin som gör att svarstiden varierar eller beror det på antal kodrader som söks igenom. Därför utförs en experiment för att ta reda på resultatet.

4.2 Alternativa Metoder

En alternativ metod skulle kunna vara fallstudie. Med en fallstudie, kan man i arbetet kunna gå in djupare i WordPress, genom att söka igenom alla plugins som läggs upp i deras bibliotek samt att kunna mäta svarstiden. Dock finns det nackdelar med fallstudie. Om fokus med fallstudie sker inom WordPress skulle det påverka alla skapare samt administratören.

Ett annat problem kan vara när koden blir genomsökt, detta kan leda till att det påverkar hemsidans svarstid. Enligt Berndtsson et al (2007), kan en fallstudie vara lämplig att skapa när man vill förstå och förklara fenomen i ett viss område som ännu inte har förståelse inom något. Det räcker med att en genomsökning efter säkerhetsrisken sker. Som existerar.

Huruvida någon sådan existerar spelar inte någon roll för frågeställningen. Att använda kända säkerhetsrisker som faktiskt existerar är att kännedomen av algoritmen fungerar för att hitta säkerhetsrisker.

En annan metod kan vara att skapa sig av enkäter. Det finns fördelar och nackdelar med att skapa sig av enkäter. Enligt Berndtsson et al.(2007), går det snabbt att få feedback från olika individer och verksamhet. Nackdelen är att enkäter har inte alltid varit det mest engagerade metoden, då deltagande är rätt så låg, då enkäter riskerar låga svarsfrekvenser. Och detta skulle ha varit en risk med tiden, om valet av denna metoden skulle väljas.

Anledning till att enkät valdes som en alternativ metod kan vara att fråga användarna om exekveringen samt prata med utvecklarna om deras plugins om vad de har för tankar kring ett live-antivirus.

4.3 Forskningsetiska Aspekter

För att arbetet ska medverka ett pålitligt resultat så kommer all kod, verktyg och hårdvara som används eller skapats att publiceras så att andra kan återskapa. Arbetet kommer att använda sig av CMS-verktyg-verktyget WordPress med programmeringsspråket PHP. Samt det experimentella metoderna som användes finns även tillgänglig. Det innebär att inga andra programmeringsspråk kommer att användas under detta arbete. Testpersoner kommer inte vara nödvändiga under detta arbete vilket betyder att etiska problem på samma sätt som lagring av personlig data inte kommer att publiceras.

Om riktiga säkerhetsrisker hittas kan det skapa problem för användarna och användarnas data. Viktig information som personuppgifter med liknande kan spridas på grund att användarna kan riskera exekvera skadlig kod .

5.Genomförande/Implementation/

Projektbeskrivning

5.1 Förstudie

För att kunna göra en implementation måste en förstudie ha gjort innan. Som metoden beskrev, var detta arbete inspirerad av flera andra arbeten (referenser). Inspiration av artikeln skriven av Koskinen, et al (2012) där de utförde genomsökningar av WordPress plugins. Detta arbete inspirerades även av en före detta studentstudie där personen arbetade med något liknande med Browser Shield.

Boken ”Programming PHP” skriven av Ledor et.al (2006) gav även inspiration och idéer om hur ska byggas upp. De beskriver grunden till PHP programmering samt hur funktioner ska användas och hur arrayer anropas. Det räcker inte med att använda sig av en bok, då det förekommer mer avancerad programmering när det gäller attacker mot webbsidor. För att kunna identifiera och söka efter det som letas finns det oftast ett mönster som kopplas till säkerhetsrisker. Boken Mastering Regular Expressions skriven av Friedl (2002) beskriver om hur manipulering sker av data och text.

Hur avgörs det om en plugin är säker eller inte. Enligt Stackoverflow (2012) , hade de en diskussion om vad som avgör att en plugin är säker eller inte. Om en användare laddar ner en plugin med en 4-5 i rating, är personen förmodligen utsatt för en mindre risk än om plugin har 1-2 i rating inom säkerhetszonen. Men eftersom plugins är ett open-source projekt finns det inga garantier att undvika från hackers.

Då allt hänger på ett live-antivirus program måste det undersökas hur den ska köras live.

Enligt PHP – manualen används en funktion som kallas för exec(). Vad exec() gör är att den kommer att exekvera det angivna kommandot som har implementerat.

5.1.1 Säkerhetsrisker

Genom att skapa en kod som genomsöker ett insticksprogram rad för rad, är det viktigt att veta hur en säkerhetsrisk identifieras. Enligt aw-snap.info(u.å.) används Base64 kod oftast för att attackera webbsidor. Vad som sker är att personen som gör intrång injekterar sin kod i första eller sista raden i en fil, i detta fall en Plugin.

Att använda sig utav en ”grep” kommando kan vara användbar för detta, men problemet är att det kommer att visa många falska-positivet av säkerhetsrisk. När det arbetas med base64 så kommer det i olika former, vilket även kallad för kommandomönster.

Kommandomönster som man kan hitta i en base64 aktivitet:

• base64_decode

• gzinflate(base64_decode

• eval(gzinflate(base64_decode

• eval(base64_decode

aw-snap.info(årtal saknas) nämner om att det som används vanligt bland hackers är, eval(base64_decode.

När hackers använder sig av eval(base64_decode är det oftast:

• eval(gzinflate(base64_decode('...');

• eval(gzuncompress(base64_decode('...);

• eval(gzinflate(str_rot13(base64_decode('...');

PHP koden kommer att exekveras på servern och det som resulteras från exekveringen är det som kommer att implementeras i koden. När webbsidan ska inspekteras via ”sidkälla” eller inspekterar sidan så kommer inte koden att synas. För att inspektera koden måste det ske manuellt.

5.2 Implementation av program

I denna del beskrivs PHP – programmet som implementerades. Arbetet med applikationen kommer vara uppdelad i olika delar för att tydliggöra för läsaren hur programmet är uppbyggt. Programmet består av programmeringsspråket PHP. All kod som programmeras av mjukvaran kommer att vara tillgänglig.

5.2.1 Genomsökning av kod

En funktion kommer att skapas som ser till att hämta all kod som finns. I figur 8 visas det ett exempel på hur hämtning samt genomsökning av kod utförs. Funktionen kommer att gå igenom koden, rad för rad för att försöka hitta funktioner eller metoder som har att göra med säkerhetsriskerna.

Eftersom base64 kod är vanligt bland attacker inom plugin kommer det att skapas en funktion som söker igenom efter base64.

Figur 8: Strängar som identifierar base64_decode

Då fokus ligger inom PHP och base64 skapas en funktion som ser till att hitta php, txt och javascript-filer (se figur 9)

Figur 9: Funktionen ser efter filer som har PHP som filformat

Om inte detta implementeras blir det svårare att hitta de rätta filerna. Filernas sökväg kan då inte identifieras och inte heller möjliga säkerhetsrisker.

5.3 Progression

Det första som skulle göras var att implementera en funktion som skulle söka enbart efter base64. Men eftersom denna funktion enbart letade efter en fil som kan ha en infektion blev det för svårt. Syftet med skriptet är att leta igenom alla filer oavsett PHP eller Javascript (se figur 10). Att implementera en preg_match ser till att sökningen matchar det som finns implementerat i skriptet. I preg_match gjordes förändringar, istället för att leta efter base64 i preg_match sågs det till att implementera in filformat istället (se figur 11).

Figur 10: Första problemet som uppstod under progression

Istället för att ha preg_match för base64, är det bättre att skapa individuella strängar för varje base64 säkerhetsrisk (se figur 11)

Figur 11: Funktionen ser till att identifiera filer med ändelser som .php och med hjälp av strängar hitta base64 hot.

Under progressionen användes även MySQL anslutning men det existerade databasen som var tillgänglig för alla i Högskolan i Skövde inte fungerade. Ett utbyte är det enda alternativet vid installation för WordPress. För att lösa problemet användes en gratisversion av MySQL från db4free.net. Där skapades en helt ny databas för testning med databasinformationen:

Figur 12: Den nya databasen. (Lösenord: Tomten2009)

Under progessionen fanns det ett problem med live-antivirusprogrammet. Programmet kördes aldrig i bakgrunden. Problemet med detta var att se till att implementera koden i WordPress,. Det fanns olika val möjligheter att välja mellan. Det första var att exempelvis skapa en nya sida med WordPress administrativa panel där vi själva implementerar PHP koden. Dock fanns det problem med detta alternativ då PHP funktionen som skulle användas gick inte att implementera i denna nya sida som skapades. Idén skrotades och gick över till en annan alternativ.

Ett plugin vid namn av Insert-PHP var lösningen till problemet. Detta plugin kunde man lätt implementera sin egen funktion och låta den köra igång hela tiden i en post-page eller vanlig sida.

Svarstiden som visades först stämde inte. Problemet bakom detta var att implementationen av svarstiden var fel implementerad. Start och sluttid kördes då först innan live- antivirusprogrammet kördes vilket blev att tidtagaren inte räknade med när live- antivirusprogrammet exekverades. Genom att lägga start-tid först i koden och sedan slut-tid allra sist i koden löste det problemet.

6.Pilotstudie

6.1 Svarstidmätning

För att kunna utföra mätningar samt se tidskillnaden på ett korrekt sätt, så implementerades en funktion som kallas för microtime(). Microtime är rätt likt funktionen i javascript, performance.now .

Figur 13: Exempel på ett ”microtime()” script inom PHP

När antivirusprogrammet har utfört sitt jobb är det bra att få ut ett resultat på tiden. En funktion kommer att anropas samt spara resultatet i ett textdokument.

Figur 14: Exempel på hur man sparar resultat

Tiden kommer att hämtas med hjälp av microtime() funktionen. Vad microtime gör är att den returnerar Unix klockan i millisekunder. Dock fungerar bara denna funktion i operativsystem som stödjer gettimeofday() system kallelse enligt Padilla, A., et.al (2010) som skrev boken PHP Code Optimization. Genom att använda sig av microtime() funktionen kan man enklare att ta reda på hur snabbt det tar för att få fram resultatet för tiden.

6.2 Experimentell Miljö

För experimentet användes det en bärbar dator samt programmet som programmerades i en lokal server. Nedan visas en tabell med detaljerad information om den experimentella miljön.

Experimentell Miljö

Komponent Information

Operativsystem Windows 10 Home 64-bitars

Processor AMD A10-7300 Radeon R6, 10 compute Cores 4C+6G 1,90 Ghz

RAM 8,00 GB

Övrigt WordPress version 4.5 & MySQL 5.7

Tabell 1: Specifikationer inom det experimentella miljön

Programmet testades i följande CMS-verktyg:

• WordPress med slumpmässig plugins

• WordPress med inga Plugins

6.3 Test av mätning

Med de första mätningarna som utförs kommer det att bli enklare i slutändan när de riktiga mätningar görs. Första testet kommer att utföras på en slumpmässig plugin. Syftet med testet är att kolla hur snabbt det tar för programmet att exekveras och ser efter om programmet påverkar svarstiderna. Svarstiderna kommer att mätas inom millisekunder.

Test #1 – Utan Plugin

Första testet är att se till om live-antivirus påverkar prestandan generellt med eller utan plugin.

Test#2 – Med Plugin (Wordfence Security)

Andra testet används insticksprogrammet Wordfence Security version 6.1.6 av Wordfence.

Detta testet ska bevisa att det kan ta längre tid för live-antiviruset att skanna igenom då det kan bero på filstorleken inom detta plugin eller antal filer den genomsöker då denna plugin är 3,04 MB vilket är rätt stort.

Pilotstudie

Test #1 Utan Plugin (ms) Test #2 Wordfence Security (ms)

0.14885187149048 0.18457818031311

0.15070390701294 0.17370295524597

0.14697408676147 0.17080998420715

0.15187191963196 0.16889691352844

0.15131688117981 0.17132806777954

Tabell 2: Svarstiderna utifrån de två första testfallen inom pilotstudien

Tabell 2 visar resultatet från de två första testfallen hos pilotstudien. Det som visas är att med plugin så kan det påverka svarstiderna, men inte relativt mycket för att det ska gå långsamt. För båda testfallen utfördes fem iterationer för att kolla om det fanns stora skillnaden mellan varannan iteration.

Varje iteration låg inte över en sekund, för varje ökning som skedde mellan iterationen var motsvarande ungefärlig 0,01... i millisekunder. I figur 15 nedan visas en tabell mellan dessa två testfallen tillsammans för att visa skillnad.

Figur 15: Jämförelsetabell mellan de två testfallen

Diagrammet visar skillnaden mellan de två testfallen i pilotstudien. Skillnaden är inte stor, utan låg runt 0,03 millisekunder. Detta kan nog bero på WordFence – plugins storlek eller

antal filer som programmet måste genomsöka. Dock påverkades inte Live- antivirusprogrammet. Programmet kunde som vanligt fånga upp säkerhetsrisker och visas i en form av en lista (se figur 16) som identifierar att det kan finnas hot/risker.

Figur 16: Base64 identifierad vid test av Testfall#2 med plugin

I listan visas det vart i filens sökvägar där den har identifierat en Base64 säkerhetsrisk. Den visar detaljrikt vart och vilken fil som innehåller en Base64 kod i sig.

6.4 Presentation av experimentet

Testerna utfördes i webbläsaren Google Chrome med CMS-verktyget WordPress installerad.

Tjugo iterationer genomfördes för varje testfall där fem olika testfall av olika plugin med olika storlekar samt en med en säkerhetsrisk testades på.

Programmet som kommer att att användas är samma som användes inom pilotstudien, inga ändringar har utfört. Svarstid kommer att exekveras direkt när sidan har påbörjat att ladda samt allt som körs i bakgrunden användes WordPress-plugin ”Insert-PHP” för att implementera PHP inom CMS-verktyg.

För varje mätserie som utförs kommer ett diagram av resultat att visas samt en liten analys om vad diagrammet innefattar. Alla plugins kommer variera i filstorlek.

Testfall#1 - Google Analystic Counter Track

Version: V.3.1.2

Filstorlek: 1,71 MB Antal filer: 81 filer

Tabell 3: Specifikation av plugin Google Analystic Counter Track

Som tidigare nämndes kommer varje testfall utföras på plugin med olika filstorlekar för att undersöka om det kan bero på filstorlek eller antal filer (även antal kod i fil) som mappen innehåller. Första testet började med att testa en mindre plugin. Till hjälp användes Google Analystic Counter Track – plugin med filstorlek 1,71 MB. Tabell 4 visar svarstiden efter att tjugo iterationer har utförs på samma plugin.

0.1690628528595 0.16467595100403 0.15885019302368 0.16332983970642 0.16402006149292 0.16152000427246 0.16318082809448 0.16514706611633 0.16367101669312 0.16153192520142 0.16746497154236 0.16179800033569 0.16342687606812 0.16231799125671 0.16272902488708 0.16082096099854 0.16165900230408 0.16244792938232 0.16032099723816 0.15911412239075

Tabell 4: Google Analystic Counter Track, svarstid(ms) från tjugo iterationer

Figur 17 visas en tydligare bild på hur iterationerna skiljer sig åt för varje iteration som utförs.

Figur 17: Mätning #1 (Google Analystic Counter Track(V.3.1.2))

Det som visas i diagrammet är iterationer som har utförs på plugin. Vad är det som gör så att svarstiden nästan motsvarar testfall #2 i pilotstudien. Beror det på filstorleken eller är det anal filer som existerar i plugin. Genom att använda sig av standardavvikelse med hjälp av formler, =STDEV(A2:A21). Medelvärdet ligger på 0.00249401507 millisekunder.

Nästa testfall kommer utföras på en plugin som har en mellanstor storlek.

Testfall #2 WP Super Cashe

Version: V.1.4.8

Filstorlek: 2,71 MB

Antal filer: 50 filer

Tabell 5: Specifikation av plugin WP Super Cashe

Testfall nummer två kommer utföras med plugin WP Super Cashe. I jämförelse med Google Analystic Counter Track, har denna plugin en filstorlek på 2,71 MB och innehåller 50 filer.

Det innebär att denna plugin är större i storlek men har färre filer än Google Analystic.

0.15768599510193 0.15977883338928

0.15073680877686 0.15086722373962

0.15232801437378 0.15531301498413

0.15805006027222 0.15478205680847

0.1567530632019 0.15290498733521

0.15197682380676 0.15577006340027

0.15354108810425 0.15308904647827

0.15701699256897 0.15679216384888

0.15291285514832 0.16365098953247

0.15925002098083 0.15381407737732

Tabell 6: WP Super Cashe, svarstid(ms) från tjugo iterationer

Efter tjugo iterationer kan det analyseras lite djupare. Vad som visas i tabell 6 är svarstiden från plugin WP Super Cashe från de totala tjugo iteration som gjordes. Jämförelse med Google Analytics, så är WP Super Cashe 0,01.... Millisekunder snabbare än Google Analystic.

Detta kan nog bero på att WP Super Cashe har färre filer än Google Analystic vilket underlättar för live-antivirusprogrammet att genomsöka. En slutsats kan inte dras ännu, då fler tester måste utföras. Figur 18 visar en tydligare bild på iterationerna sida vid sida.

Mellan varje iteration visade det säg att mätningen var stabil runt 0,15... Millisekunder.

Figur 18: Mätning #2 (WP Super Cashe(V.1.4.8))

Medelvärdet ligger runt 0,003311498601 millisekunder. För nästa test kommer testfall #3 att använda sig av en större plugin.

Testfall #3 All In One SEO Pack

Version: V.2.3.4.2

Filstorlek: 5,23 MB

Antal filer: 163 filer

Tabell 7: Specifikation av plugin All In One SEO Pack

Testfall #3 kommer att utföras på en större plugin än de föregående testerna. Plugin som kommer att användas för detta testfall är All in One SEO Pack. Storleken för All in One SEO Pack är 5,23 MB och innehåller 163 filer. Jämförelse med de andra två testfallen, testfall #1 och testfall #2 är storleken dubbelt så stor i filstorlek och antal filer.

Vad som var intressant med testfallen var svarstiderna för varje iteration. Tabell 8 visar tydligt varför det är intressant.

0.16463994979858 0.15606307983398

0.15429902076721 0.1574170589447

0.15697693824768 0.161297082901

0.15771508216858 0.15597581863403

0.15704107284546 0.15539383888245

0.15528893470764 0.1557309627533 0.15733003616333 0.15549111366272 0.15724301338196 0.1555700302124

0.15687108039856 0.15396904945374

0.15906000137329 0.15644407272339

Tabell 8: All In One SEO Pack, svarstid(ms) från tjugo iterationer

Kollar man noga ligger alla svarstid för varje iteration runt 0,15.... millisekunder. Denna testfall visar att svarstiden liknar det svarstid WP Super Cashe som också låg på 0,15....

millisekunder. Oavsett filstorlek och antal filer SEO plugin hade, tog det samma tid att iterera. På figur 19 visas en mer detaljerad graf för varje iteration som utfördes.

Figur 19: Mätning #3 (All In One SEO Pack (V.2.3.4.2))

Medelvärde på testfall #3 ligger på 0,002429046447 millisekunder.

Testfall #4 Theme Check med Base64 injektion

Version: V.20160523.1

Filstorlek: 127kb

Antal filer: 54 filer

Tabell 9: Specifikation av plugin Theme Check

Testfall #4 kommer att utföras på ett annorlunda sätt. I detta test kommer en injektion av skadlig kod baserat på Base64 att injekteras. Syftet med detta test är att se om vi kan fånga upp Base64 säkerhetsrisker. Detta test kommer att försöka fånga upp en eval(base64_decode säkerhetsrisk. Som tidigare testfall kommer detta program att itereras tjugo gånger bara för att vara säker så att vi kan fånga upp säkerhetsrisken och även kolla om injektionen med eval(base64_decode även påverkar prestandan. Tabell 10 nedan visar iterationen för Theme check med Base64 injektion.

0.15566086769104 0.16030192375183

0.15623903274536 0.15260887145996

0.15583801269531 0.15568590164185

0.15639114379883 0.15321111679077

0.15568804740906 0.15017008781433

0.15642094612122 0.15545296669006

0.15271091461182 0.15421581268311

0.15386915206909 0.15271806716919

0.14968490600586 0.15417790412903

0.15665602684021 0.15000295639038

Tabell 10: Theme Check, svarstid(ms) från tjugo iterationer

Med en eval(base64_decode injektion blev svarstiden rätt identiskt med SEO Pack och WP Super Cashe. Injektion påverkade inte prestandan då svarstiden låg rätt stabilt från föregående tester. Dock var denna fil betydligt mycket mindre än alla plugins som har testats i detta arbete. Dock var svarstiden jämnlikt med testfall #2 och testfall #3.

Andra syftet med detta test var att identiera om eval(base64_decode kunde identifieras. Det visade sig att live-antivirusprogrammet kunde hitta base64 injektion för varje iteration som utförs. En detaljerad lista (se figur 20) visar att Theme Check har blivit infekterad av ett eval(base64_decode.

Figur 20: En detaljerad lista över genomsökning efter varje iteration.

Denna lista bevisar att ett eval(base64_decode säkerhetsrisk har identifierats. Programmet hänvisar användaren i vilken sökväg samt fil som har blivit infekterad av detta säkerhetsrisk.

För att identifiera hur koden/injektionen av base64 ser ut är det bäst för utvecklaren att manuellt öppna filen och se efter (se figur 21)

Figur 21: Här identifieras en base64 injektion

När filen öppnas kommer klient antivirusprogrammet att varna användaren för skadlig kod.

Klientens antivirusprogram kommer att automatiskt ta bort det skadliga koden.

Allmänt så påverkades inte prestandan när injektion av base64 var medverkat i testfall #4.

Live-antivirusprogrammet kunde utan problem fånga upp säkerhetsrisken och identifiera vad för slags säkerhetsrisk det var. Ned på figur 22 visas ett diagram på hur varje iteration påverkades. Svarstiden låg stabilt vid 0,15.... millisekunden.

Figur 22: Mätning #4 Theme Check (V.20160523.1) med säkerhetsrisk

Medelvärdet för detta testfall låg på 0,0026112584 millisekunder.

Testfall #5 Prestanda test med alla Plugins

I testfall #5 kommer prestandan att testas. Alla plugins som används under detta experiment kommer att att köras igång samtidigt. Live-antiviruset uppgift kommer vara som vanligt.

Den kommer att köras i bakgrunden medan webbsidan ska arbeta så gott den kan med alla plugins installerade samtidigt. Tabell #11 kommer att visa hur pass mycket det har påverkat svarstiden.

0.18442010879517 0.1778028011322

0.17583608627319 0.17719101905823

0.17736792564392 0.17398619651794

0.17729496955872 0.1821300983429

0.17769885063171 0.17842602729797

0.17676210403442 0.17951393127441

0.17744994163513 0.1786801815033

0.17666697502136 0.17828106880188

0.17682814598083 0.17804288864136

0.17632913589478 0.17868399620056

Tabell 11: Alla plugins körs igång samtidigt, svarstid(ms) från tjugo iterationer Tabell #11 visar att det har skett en ökning i svarstid med alla plugins körandes samtidigt.

Det har skett en ökning med ungefär 0,02 – 0,03... millisekunder. Detta är en fördel då testet ligger fortfarande under en sekund. Även med alla plugins körande samtidigt kunde live-antivirusprogrammet fortfarande identifiera injektionen (testet utförde en ny injektion på samma fil för att undersöka om programmet kan fånga upp samma säkerhetsrisk.). På figur 23 visar diagrammet mer i detalj.

Figur 23: Mätning #5 Alla plugins körs samtidigt

Vi kan se att vid första iterationen går det några millisekunder långsammare, men efteråt håller den sig i en stabil mätningsresultat. Medelvärdet för detta test låg på 0,002200389533 millisekunder.

För att kunna utföra en mer detaljerad analysering gjordes en sammansatt diagram med alla mätningsresultat tillsammans med standardavvikelse. På figur 24 visas en mer detaljerad diagram på hur prestandan varierade med alla testfall.

Figur 24: Ett diagram på alla mätningsresultat

Punktsdiagrammet visar mätningsresultat över alla testfall som gjorts. Den visar att testfall

#5, vilket var alla plugins samtidigt, tog lite längre tid än de andra plugin. Testfall #1 var Google Analystic Counter Track. Filen låg på 1,71 MB, till skillnad från de andra testfallen (räknar inte med testfall #4) så tog det lite längre tid än testfall#2 och testfall#3.

7. Utvärdering

7.1 Sammanfattning

Vad som kunde göras bättre är att testa olika webbläsare för att se om det blir skillnad mellan svarstiden. Eftersom denna test utfördes på en dator med ett operativsystem samt en webbläsare kunde man utöka variationen lite med att testa på andra mjukvaror.

Testerna som utfördes påverkade inte antiviruset då programmet kunde köras som vanligt i bakgrunden utan att svarstiden påverkade så mycket. Alla tester låg under 1 sekunds gränsen vilket är positivt då användaren föredrar svarstider som är under 1 sekund.

7.2 Analys

Analysen av mätserierna tyder på att det är olika svarstider på olika plugins med olika storlekar. Vad som beror på dessa olika svarstider är givet att antal kod som programmet genomsöker har ett stort beroende på varför det blir olika svarstider. Google Analystic Counter Track som är betydligt mindre än testfall #2 och testfall #3 har fått ett längre svarstids. Detta beror på att Google Analystics filer innehåller mer kod än de andra testfallen. De större filerna har fler filer på grund av att de delar upp alla funktioner i små koder så det underlättar för utvecklarna att identifiera fel. Samt att det tar snabbare för live- antivirusprogrammet att genomsöka alla filer med korta kodstycken.

På testfall #1 samt testfall #2 kan man se en stor skillnad i svarstiden (se figur 24). Båda har olika storlekar. Testfall #1 vad betydligt mindre än testfall #2 i storlek. Dock hade den en långsammare svarstid. Om filerna grävs djupare kan det analyseras att testfall #1 hade fler filer. Vilket innebär mer kod. Detta gör att programmet måste skanna enskilt varje fil för att identifiera en säkerhetsrisk. Ju fler filer desto längre tid tar det att genomsöka efter säkerhetsrisker.

En annan analys kan exempelvis göras i andra webbläsare/webbläsarmiljöer. Om testfallen utförs i en annan webbläsarmiljö skulle antagligen resultatet av mätningarna ändras. Då alla testfall utfördes i en Google Chrome miljö så blev alla resultat anpassad för Google Chrome.

7.3 Resultat

Resultatet visar att antivirus programmet kunde identifiera Base64 hot genom att visa en lista på vart och vilken fil där risken finns. Svarstiden påverkade inte antiviruset samt att alla svarstider låg under 1 sekund.

Utifrån mätningsresultat visar det att alla hade olika svarstider beroende på deras filstorlek.

Resultat av alla tester visar att storlek inte har betydelse när det gäller att mäta svarstiden för antivirusprogrammet. Det är nämligen antal kod som varje fil har i en plugin som spelar mest roll.

Har ett plugin flera filer, och inuti filen är det tusentals kodrader, då kommer detta att påverka resultatet.

7.4 Slutsatser

Tolia, N., et. Al (2006) berättar om att när det gäller svarstid, så föredrar användarna att svarstiden ska ligga under 1 sekund och att om det är över en sekund så kan det innebära frustration för användaren när de ska vänta på att webbsidan ska svara. Då testerna som gjorts på olika plugins har legat under 1 sekund, så kan en slutsats dras att detta live- antivirusprogrammet inte kommer att påverka användarna på ett negativt sätt.

Är en plugin stor i filstorlek påverkar det inte svarstiden. Vad som påverkar svarstiden är antal filer som en plugin har. Programmet skannar igenom filer där den kollar igenom all kod vilket påverkas mer än filstorlek.

8. Avslutande diskussion

8.1 Diskussion

Genom att kolla noga och gjort flera testfall på samma plugin ett fåtal gånger kommer det en fundering om det kan bero på antal rader kod (inom filer) på plugin som kan ha påverkat svarstiderna.

Det forskningsetiska aspekterna tar upp så kan detta arbete återupprepas. Då all information som är nödvändigt för detta arbete finns med. All kod som gjort för live- antivirusprogrammet kommer att finnas med. Information om vilket CMS-verktyg som användes samt hårdvara kommer att finnas tillhands.

Problemet med plugin är att de är alltid ständigt uppdaterade, vad som behövdes göra i detta experiment var att tillämpa en egen injektion av en base64 säkerhetsrisk. Vad som kunde ha gjorts bättre är att antivirus programmet tar bort säkerhetsrisken och inte att användaren själv måste gå in manuellt i filen för att hitta risken. Detta är något som kan tänkas inom det framtida arbetet.

Det finns samhälleliga aspekter kring detta antivirusprogram. Nyttan med detta antivirus program är att "samhället" det vill säga användarna, har tillgång att genomsöka sin webbplats efter säkerhetsrisk. Det påverkar inte samhället, då programmet inte tar emot personlig information från användaren. Detta klargör att syftet med programmet är att programmet kommer bara att söka igenom webbplatsen och dess mappar efter säkerhetsrisk.

Detta arbete visar även att det är möjligt att upptäcka säkerhetsrisker. Genom att visa samt implementera ett program som ser till att utföra arbetet genom att identifiera säkerhetsrisk.

8.2 Framtida arbete

Vad som kunde förbättras med detta arbete är att testa programmet i olika webbläsare och ser om det blir en skillnad mellan Google Chrome och andra webbläsare inom svarstid.

Operativsystem kan också ha en betydelse då vissa program är anpassade till olika OS. Då Windows 10 är relativt ny, kan svarstiden skilja kanske mellan Windows 7 eller 8, med mera.

Att inte bara fånga upp Base64 säkerhetsrisker kan också vara en förbättring för detta program då det finns fler säkerhetsrisker än bara Base64. Samt testa på andra CMS-verktyg för att se om det också kan stödja andra CMS-verktyg.

Referenser

Berndtsson, M., Hansson, J., Olsson, B., & Lundell, B. (2007). Thesis projects: a guide for students in computer science and information systems. Springer Science & Business Media.

Christodorescu, M., & Somesh, J. (2004) "Testing malware detectors." ACM SIGSOFT Software Engineering Notes 29.4: 34-44.

Ely, A. (2010) "Browser As Attack Vector." Information Week 1275 : 31-33.

Friedl, J.EF., (2002). Mastering regular expressions. " O'Reilly Media, Inc."

Koskinen, Teemu, Petri I., & Ville K.(2012). "Quality of WordPress Plug-Ins: An Overview of Security and User Ratings." Privacy, Security, Risk and Trust (PASSAT), 2012 International Conference on and 2012 International Confernece on Social Computing (SocialCom). IEEE.

Lerdorf, R., Tatroe.K., & MacIntyre.P.. (2006) Programming Php. " O'Reilly Media, Inc.".

McDermott, J. (1998) "Prolepsis on the problem of Trojan-horse based integrity attacks (position paper)." Proceedings of the 1998 workshop on New security paradigms. ACM, 1998.

Mudambi, Susan M., and David S. (2010) "What makes a helpful review? A study of customer reviews on Amazon. com." MIS quarterly 34.1 (2010): 185-200.

Patel, Shital K., Rathod, V. R., & B. Prajapati. J. (2013) "Comparative analysis of web security in open source content management system." Intelligent Systems and Signal Processing (ISSP), 2013 International Conference on. IEEE, 2013.

Patel, Savan K., Rathod, V. R., & Parikh, S. (2011) "Joomla, Drupal and WordPress-a statistical comparison of open source CMS-verktyg." Trendz in Information Sciences and Computing (TISC), 2011 3rd International Conference on. IEEE, 2011.

Padilla,A., & Tim,H.,(2010) "PHP Code Optimization." Pro PHP Application Performance.

Apress.

Rajamony, R. & Elnozahy, M. (2001) Measuring client-perceived response times on the www. Proceedings of the Third USENIX Symposium on Internet Technologies and Systems (USITS).

Rainville-Pitt, S., & D’amour, J-M. (2009) "Using a CMS-verktyg to Create Fully Accessible Web Sites." Journal of Access Services 6.1-2 (2009): 261-264.

Reis, C, Dunagan, J., Wang, H.J., Dubrovsky, O., & Esmeir, S. (2007) "BrowserShield:

Vulnerability-driven filtering of dynamic HTML." ACM Transactions on the Web (TWEB) 1.3 (2007): 11.

Shar, L.K., & Hee Beng, K.T. (2011) "Defending against cross-site scripting attacks."

Computer 3 (2011): 55-62.

Stackoverflow[2](2014) ”Base64 encoded string in every php files, seams like malicious”

Tillgänglig:http://stackoverflow.com/questions/23679220/base64-encoded-string-in- every-php-files-seams-like-malicious Hämtad: 13/04/16

Tian, Y., & Li, Z.(2009) "Anatomic model on web customer satisfaction based on customer behavior." Proceedings of the 2nd International Conference on Interaction Sciences:

Information Technology, Culture and Human. ACM, 2009.

Tolia, N., Andersen, D. & Satyanarayanan, M. (2006) Quantifying interactive user experience on thin clients. Computer, 39, 46-52.

Tabrez.A., (2012) ”How to know if a wordpress plugin is safe” Tillgänglig:

http://stackoverflow.com/questions/9476826/how-to-know-if-a-wordpress-plugin-is- safe Hämtad: 15/04/16

Van A., Nikiforakis,S., Desmet,N., Piessens,L., F., & Joosen, W.(2014) "Monkey-in-the- browser: malware and vulnerabilities in augmented browsing script markets."

Proceedings of the 9th ACM symposium on Information, computer and communications security. ACM, 2014.

Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A.

Experimentation in software engineering. Springer Science & Business Media, 2012.

Appendix