>> Hvorfor er web-sikkerhed blevet et vigtigt sikkerhedsområde? >> Hvad er konsekvenserne af et angreb mod en virksomheds web-systemer? >> Hvilke problemstillinger eksisterer overordnet inden for web-sikkerhed? >> Hvad kan man som virksomhed gøre for at opnå en høj web-sikkerhed? >> Hvilke fire områder er de største problemområder inden for web-sikkerhed? >> Hvad er de typiske programmeringsfejl i web-applikationer? >> Hvad er SQL injections, og hvordan kan man undgå det? >> Hvad er cross site scripting, og hvordan kan man undgå det? >> Hvad er input-manipulation, og hvordan kan man undgå det? >> Hvad er parameter tampering, og hvordan kan man undgå det? >> Hvad er cookie poisoning, og hvordan kan man undgå det? >> Hvad er hidden field manipulation, og hvordan kan man undgå det? >> Hvilke sårbarheder finder man ofte på web-servere? >> Hvad er buffer overflow, og hvordan garderer man sig mod det? >> Hvordan kan man undgå de vigtigste sårbarheder i web-applikationer? >> Hvad er input-validering, og hvordan gør man? >> Hvad er code review, og hvorfor er det vigtigt? >> Hvilke værktøjer findes, som kan anvendes for at øge web-sikkerheden? >> Hvad får man ud af at benytte et testværktøj? >>  Hvilke erfaringer har danske virksomheder med at anvende web-sikkerhedsværktøjer? >> Hvem forhandler web-skanningsværktøjer i Danmark? >> Hvordan får man nemmest fat i et godt web-skanningsværktøj? >> Hvordan kan FortConsult bidrage til at øge en virksomheds web-sikkerhed? >> Hvad har fastslået FortConsults førende position inden for web-sikkerhed? >> Hvordan får man yderligere informationer?   Hvorfor er web-sikkerhed blevet et vigtigt sikkerhedsområde? Websites er i stigende grad blevet et yndet mål for hackerne de seneste år. Mange virksomheder har indtil for nylig ikke taget det så tungt med hackerangrebene, fordi der primært har været tale om, at hjemmesider er blevet overskrevet med web-grafitti. Men det er i færd med at ændre sig, i takt med at flere og flere virksomheder baserer en stigende del af deres kundeservice og omsætning på web-services - og derfor kan risikere tabt omsætning som følge af et hackerangreb. Læs mere om, hvorfor web-sikkerhed er vigtigt, nedenfor.   Flere it-systemer er blevet web-baserede Det er i dag ikke længere kun hjemmesider og portaler, der er web-baserede. Også selvbetjeningssystemer og interne systemer som Intranet- og Extranet-systemer og dokumenthåndteringssystemer udvikles på web-teknologi i dag i stigende grad. Det hele skal foregå via nettet – det er en nem måde at stille ydelser til rådighed for kunder, medarbejdere, etc. og i mange tilfælde en lønsom måde at udbygge forretningen på. Men jo flere systemer, jo mere kodningsarbejde skal der laves, og jo større bliver risikoen for at lave sikkerhedsfejl i applikationen, når den udvikles eller vedligeholdes.   Web-systemerne integreres med interne systemer Web-systemerne bliver i dag i højere grad integreret med virksomhedernes interne it-systemer, hvor der ofte ligger dybt fortrolige data. Hvis en web-applikation bliver hacket, kan man risikere, at web-systemet bliver lagt ned. Eller at hackerangrebet medfører, at ordrer bliver slettet, eller at forhandler A kan se forhandler B’s rabat. Eller at en hacker kan få adgang til virksomhedens interne adressebog, i tilfælde af at man har gjort det muligt at sende e-mails via web-applikationen. Eller at en hacker kan få adgang til hospitalernes operationsplanlægning og ændre i de data, der beskriver, hvad hver person skal opereres for. Dette er blot eksempler, men de illustrerer, at konsekvensen af et angreb kan være ret alvorlig.   Hackerne går efter web-applikationerne Hackerne har fattet en stigende interesse for web-applikationerne. På det sidste er hackerne generelt begyndt at fokusere mere på at få økonomiske gevinster ud af angrebene frem for blot at vise, hvad de kan, hvilket gør konsekvensen af angrebene langt alvorligere. Samtidig har vi for nylig oplevet en stigende tendens til, at der er kommet flere hackere om budet, fordi de såkaldte script kiddies – eller på dansk "dåsemadshackere" – er kommet i besiddelse af scripts, som de kan bruge til at hacke web-applikationerne med. Script kiddies er amatørhackere, der benytter en færdiglavet kode til at hacke med, som andre, mere udspekulerede hackere, har udviklet. Eksempelvis er SQL injections, som typisk benyttes til at angribe web-applikationer med, nu også så småt begyndt at blive brugt af amatørhackere. Det betyder, at virksomheder ikke længere er tilstrækkelig beskyttede mod angreb mod web-applikationerne, selvom de har firewalls og systemer, der er patchet op. Det indebærer i sig selv en væsentlig større risiko for, at web-applikationer bliver hacket, da der i så fald bliver mange flere hackere om buddet.   Web-applikationer indeholder dobbelt så mange sikkerhedshuller som andre systemer Web-systemer tilhører i dag den kategori af systemer, som er vanskeligere at sikre end så mange andre systemer på grund af deres høje kompleksitet, samtidig med at de i sagens natur skal være meget åbne mod nettet for at fungere. Siden FortConsult blev grundlagt i 2002, har vi fundet langt de fleste sårbarheder i web-systemerne. I dag finder vi i gennemsnit dobbelt så mange sårbarheder i web-applikationer sammenlignet med andre it-systemer.   Hvad er konsekvenserne af et angreb mod en virksomheds web-systemer? Der er overordnet set tre forskellige konsekvenser, man, som virksomhed, ville kunne opleve efter et succesfuldt angreb på sine web-servere eller web-applikationer. Den mest kendte og hidtil mest anvendte er web-graffitien, men også ude-af-drift-angreb og "avancerede angreb" er i stigende grad blevet populære over de seneste år. Her er en gennemgang af de tre typer angreb.   Defacement Den mest hyppige handling en hacker vil udføre, når han/hun har kompromitteret web-serveren, er et såkaldt "defacement" eller web-graffiti. Heri erstatter hackeren den oprindelige hjemmeside helt eller delvist med noget andet. Sådanne angreb bliver oftest udført for "sportens" skyld fx af dåsemadshackere eller for at fremsætte en mening fx af aktivister. Heldigvis er det ofte det visuelle, der er vigtigst for hackeren i dette tilfælde og ikke fx at stjæle eller ændre data på web-serveren.   Ude-af-drift En anden typisk konsekvens er ude-af-drift-angreb - eller Denial of Service, DoS. Formålet med denne type angreb er at få web-serveren eller –applikationen til at stoppe med at svare på lovlige forespørgsler, eller at få den til at svare meget langsomt. Til nu har DoS-angrebene i høj grad været udført på grund af fjendtlige politiske holdninger mod websitet. Vi er dog begyndt at se en stigende tendens til, at angrebene er et resultat af organiseret kriminalitet, hvor nogen ønsker at skade bestemte firmaer eller organisationer. Mange af disse angreb rettes mod finansielle virksomheder og online gambling og bookmakere.   Avancerede angreb Hvis en hacker er ude efter fortrolige data på en web-applikation, fx kreditkortnumre, vil han/hun prøve at skjule sin tilstedeværelse og spor. Derfor er et defacement usandsynligt i dette tilfælde. Avancerede angreb forekommer ikke så ofte, men den skade, de forvolder, kan være stor. Ud over at stjæle data kan en hacker også have slettet eller ændret vigtige data.   Hvilke problemstillinger eksisterer overordnet inden for web-sikkerhed? Det er ofte en stor opgave for virksomheder at sikre deres applikationer – ikke kun fordi de typisk har mange komplekse web-systemer, men også på grund af den måde web-applikationer traditionelt er blevet udviklet på. De udviklingsfolk, der programmerer web-systemerne, har været vant til, at det var deres opgave at sørge for, at den endelige funktionalitet kom til at leve op til kravspecifikationen, og at web-løsningen blev tilstrækkelig brugervenlig. Og når systemerne var programmeret færdig, blev de netop testet for disse forhold. Sikkerhed blev enten adresseret til allersidst - eller slet ikke. Web-udviklerne har ikke været vant til at arbejde med sikkerhed, og der er sjældent blevet stillet krav til dem om at være fokuserede på at kode sikkert. Oveni har udviklerne haft fokus på at programmere deres egen del af systemet og ikke været opmærksomme på den tværgående sikkerhed. De fleste har heller ikke haft den store viden om sikkerhed og været klar over, hvad de har skullet være specielt opmærksomme på i programmeringsarbejdet for at indbygge den fornødne sikkerhed.   Hvad kan man som virksomhed gøre for at opnå en høj web-sikkerhed? Det er nødvendigt at starte med at ændre på den måde, som web-udviklere traditionelt har programmeret web-applikationer på. Web-udviklingsprocessen skal udbygges, så sikkerhed kan blive indarbejdet, og det kræver både en holdningsændring og en oplæring i it-sikkerhed for udviklerne. Herudover er det vigtigt, at man også etablerer en procedure, der sikrer, at man tester applikationerne for at finde ud af, om de lever op til sikkerhedskravene, når de er helt færdigudviklede. Man skal altså sørge for både at kode så sikkert som muligt fra starten, teste sikkerheden undervejs i programmeringsarbejdet og til allersidst, inden applikationen bliver erklæret færdig.   Det er ekstremt vigtigt at få skabt en holdningsændring og sat web-applikationssikkerhed på dagsordenen, så udviklerne kan begynde at indbygge sikkerhed i programmeringsarbejdet, lige fra de påbegynder en opgave. Det er ikke noget, man får implementeret på kort tid, så det gælder om at få sat gang i forandringsprocessen. Enten i ens egen virksomhed, hvis man selv udvikler sine web-applikationer, eller ved at stille krav til web-leverandøren om at se dokumentation for at sikkerheden er i orden og applikationen testet igennem med sikkerhedsbriller på, efter at den er færdigudviklet.   Hvilke fire områder er de største problemområder inden for web-sikkerhed? De vigtigste web-relaterede sikkerhedsproblemer er:   1. Programmeringsfejl Udviklerne har ikke skrevet koden til web-serveren sikkerhedsmæssigt forsvarligt.   2. Manglende opdateringer De sidste patches og sikringer er ikke lagt på. Der vil blive fundet omkring 4500 nye sårbarheder alene i år 2006, og en stor del af disse er desværre web-sårbarheder.   3. Fejlopsætning af operativsystem og web-server Der er fx ikke lavet en ordentlig grundlæggende sikkerhedsmæssig "hærdning" af systemet, inden det er sat i produktion.   4. Fejl i netværksdesignet Web-serveren er ikke ordentligt beskyttet i netværket. Der er som bekendt mange andre måder at bryde ind i en maskine på end blot via HTTP- og HTTPS-portene.   Hvad er de typiske programmeringsfejl i web-applikationer? Programmeringsfejl i web-koden er det absolut sværeste at sikre sig imod, viser erfaringerne. Hele problemstillingen kan som udgangspunkt også være vanskelig at forstå, hvis ikke man selv er programmør. Men hvis man skal web-sårbarhederne ordentligt til livs, bliver man nødt til proaktivt at tage fat ved nældens rod, nemlig i selve programmeringen.   De mest almindelige af typer angreb er: SQL injections Cross site scripting Input-manipulation Parameter tampering Cookie poisoning Hidden field manipulation   Hvad er SQL injections, og hvordan kan man undgå det? Mange web-udviklere bruger i dag databaser og SQL (Structured Query Language) til dynamisk opbygning af web-sider ved hjælp af database-forespørgsler (queries). Web-serveren foretager SQL-kald i en database-server for at udtrække og efterfølgende præsentere de ønskede data.   Ved at manipulere i de web-inputfelter som anvendes, fx direkte i et SQL-kald, kan en angriber læse følsomme oplysninger, ændre data, foretage ude-af-drift angreb, udføre kommandoer og andre ubehagelige ting. Det gøres ved at tilføje ikke-godkendt SQL-kode, således at man fx kan ændre datastrukturen i databasen eller skaffe sig administratorprivilegier på den angrebne databaseserver. Sikkerhedshullet opstår, når webapplikationer anvender data fra brugeren direkte til databaseforespørgsler.   SQL injections er de seneste år blevet en meget populær angrebsmetode mod web-servere. Alle web-applikationer, der anvender SQL-databaser er potentielt sårbare (DB2, MS SQL, Oracle, Sybase, MySQL osv.)   Eksempel http://www.site.com/webapp.asp?id=12’ UNION SELECT CreditCard FROM Kunder WHERE ’1’=’1   Eksemplet ovenfor illustrerer grundprincippet. Og med "SQL Server stored procedures" på en SQL-database bliver det naturligvis endnu mere festligt for angriberen, hvis han kan kalde en kommando via web-applikationen fx i stil med ; EXEC+master.dbo.xp_cmdshell(cmd.exe+/c);--   Eksempel på hvordan man kan misbruge SQL statements   Lad os sige, at web-applikationen har følgende kode:   SQLQuery = "SELECT Username FROM Users WHERE Username = '" & strUsername & "' AND Password = '" & strPassword & "'" strAuthCheck = GetQueryResult(SQLQuery) If strAuthCheck = "" Then boolAuthenticated = False Else boolAuthenticated = True End If   Hvis strUsername and strPassword hentes direkte fra en web-form, vil det i dette eksempel kunne lades sig gøre for en angriber at konstruere noget input, som omgår hele ideen med programmet.   Først et eksempel på uskadelig opførsel, hvor brugeren fra en web-form indtaster følgende: Login: Ulf Password: Hemmeligt   Det resulterer i SELECT Username FROM Users WHERE Username = 'Ulf' AND Password = 'Hemmeligt' hvilket jo er meget fint. Men hvad så med følgende indtastning:   Login: ' OR ''=' Password: ' OR ''='   Som resulterer i SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''='' hvilket betyder, at udtrykket altid er sandt, og at brugeren dermed altid bliver valideret! Ups.   Løsningen er forebyggelse via input-validering i koden - vel at mærke ikke mængden af data (antal tegn), men validering af de data, der er blevet indtastet. Det vil sige, man skal sørge for, at input ikke indeholder "farlige" tegn for web-serveren. Fjern fx "plinger", anførselstegn, semikolon, slash, backslash og andre unødvendige tegn. Det bedste er at lave en streng positiv-liste med tilladte tegn og droppe alle de tegn, der ikke er med i listen.   Læs mere om SQL injections her: http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf   Hvad er cross site scripting, og hvordan kan man undgå det? En web-applikation som er sårbar over for cross site scripting tillader i realiteten at udføre et script (noget kode), som den enten får med i UR’Len eller henter fra et helt andet website. Fx hvis www.godt-site.dk er villig til at hente og udføre scripts fra www.ondt-site.dk.   For at udnytte denne sårbarhed vil en angriber sende et tilsyneladende uskyldigt link, som starter med www.godt-site.dk, men som længere henne i URL’en også refererer til www.ondt-site.dk. Brugeren klikker på linket, fordi han eller hun stoler på www.godt-site.dk, men på grund af cross site scripting-sårbarheden på dette site får brugeren nu afviklet en stump kode, som faktisk kommer fra www.ondt-site.dk. XSS er således ikke et angreb på selve web-applikationen men på web-brugeren, som stoler på den site, der har sårbarheden.   Eksempel:http://www.site.com/webapp.asp?id=<script>"ondsindet kode"</script>   Hvad er input-manipulation, og hvordan kan man undgå det? Under SQL-injection står beskrevet, hvordan en angriber arbejder, når han eller hun udfører manipulation af input-data. Samme problemstilling gælder også i mange andre tilfælde, når man som udvikler skal behandle bruger-input på web-serveren.   Et eksempel er den klassiske Unicode-sårbarhed på IIS, som i virkeligheden er en fejl i input-valideringen på server-niveau. I følgende eksempel svarer %C0%AF fx til slash (/) i Unicode i det latinske tegnsæt: http://www.fortconsult.net/scripts/..%C0%AF../winnt/system32/cmd.exe?/c+dir+c:\   Som med SQL-injection er det bedste forsvar mod input-manipulation at foretage omfattende og grundig input-validering af alt bruger-input. Fjern alle tegn undtagen de specifikke tegn, som programmet absolut skal acceptere.   Når man foretager input-validering, skal man sørge for, at det altid foregår på web-serveren. Det må ikke ske i HTML-koden, java-scripts og lignende, som afvikles på klienten. En angriber kan blot gemme koden lokalt, fjerne begrænsningen i antal tegn eller typen af tegn og kalde de samme scripts eller programmer, som den oprindelige kode side gjorde - men denne gang uden begrænsningerne.   Hvad er parameter tampering, og hvordan kan man undgå det? Parameter tampering er at manipulere URL’er for at skaffe sig informationer. Det kan fx være for at se kildekoden i en .asp-fil, der blandt andet kan indeholder brugernavn og password til database serveren, udviklerens kommentarer og andre detaljer om applikationen, der normalt kun er tilgængelige internt.   Eksempel: http://www.site.com/webapp.asp?ValidParameter&debug=true   Visse sprog fx Java er for resten nemme at lave til reverse engineering på. Det vil sige, at en eksekverbar fil "tilbagekompileres", således at den oprindelige source-kode er helt eller delvist synlig. Løsninger til dette er at sørge for, at debug-informationer er fjernet i den kompilerede kode og helt at fjerne fortrolige informationer fra source-koden, så de ikke kan findes med reverse engineering.   Hvad er cookie poisoning, og hvordan kan man undgå det? Cookie poisoning er at ændre indholdet i en cookie. En angriber kan fx få web-applikationen til at opføre sig sikkerhedsmæssigt uheldigt, hvis applikationen ukritisk henter informationer fra cookien og bruger dem til at hente og vise fortrolige data. Det kan fx være et sessionsnummer, som måske er så forudsigeligt, at angriberen kan forudsige det næste sessionsnummer ved at kigge på indholdet af den cookie, han eller hun selv har modtaget.   Indholdet i en sådan session-cookie bør være unik og helt uforudsigelig. Ellers vil en angriber kunne overtage en anden brugers session. Dette gøres ved at gætte eller opsnappe det session ID, der er skrevet i cookien. Løsningen er at bruge fuldstændig tilfældige ID og at kryptere trafikken (fx med SSL).   Hvad er hidden field manipulation, og hvordan kan man undgå det? Hidden field manipulation er at ændre værdierne i skjulte felter, som normalt ikke burde ændres af web-brugere. Det simple råd er: Lad være med at bruge hidden felter i sikkerhedsmæssig sammenhæng. I forbindelse med en sikkerhedstest oplevede FortConsult eksempelvis en web-shop, som overførte beløbet, som skulle betales, i et hidden field. Det tog os derefter 30 sekunder at manipulere med feltet således, at vi i realiteten selv kunne bestemme prisen på det, vi købte.   Hvilke sårbarheder finder man ofte på web-servere? Web-sårbarheder er ikke kun forbeholdt applikationerne. Her følger nogle af de hyppigst forekommende sårbarheder, som kan findes på den web-server, som web-applikationen afvikles på.   Backup files Backup af server scripts bliver normalt ikke afviklet af web-serveren, hvilket betyder, at man udefra kan læse sourcekoden direkte.   Eksempler: http://www.site.com/webapp.asp.bak http://www.site.com/global.asa.old   Standardfiler Der kan også ligge forskellige former for ”standard”-filer på web-serveren, som ikke bør være tilgængelige udefra, fx. logfiler og include-filer.   Eksempler: http://www.site.com/logs/visitors.log http://www.site.com/mystuff.inc   Directory enumeration/URL guessing Directory enumeration er en kvalificeret forudsigelse/gæt om directories og filers placering, som fx "admin", "test", "secret". Man kan nogle gange blive overrasket over, hvor meget man kan få adgang til på web-serveren, hvis blot man kan gætte den rigtige URL.   Path manipulation Path manipulation er at manipulere URL’er for at få adgang til fortrolige data eller til at kunne udføre kode.   Eksempler: http://www.site.com/../../../../../data/customers.txt http://www.site.com/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir   Buffer overflow Se beskrivelsen i næste afsnit.   Hvad er buffer overflow, og hvordan garderer man sig mod det? Buffer overflow finder sted, når et program eller en proces gemmer flere data i en computers hukommelse, end der er reserveret plads til, fx når der skal udfyldes data i web-formularer. Andre data bliver derved overskrevet, fx returadressen i en subrutine, hvilket kan betyde, at instruktionspointeren kommer til at pege et helt forkert sted hen - måske på ondsindet kode, som er konstrueret til formålet. Hvis ikke programmet er skrevet således, at overskydende data faktisk kan håndteres, vil der opstå mulighed for buffer overflow. Konsekvenserne er nedbrud, adgang til data eller udførsel af kommandoer.   Buffer overflows er den mest hyppigt forekommende sårbarhedstype generelt og er typisk ret alvorlige. De kan forekomme i alle programmer, applikationer og operativsystemer, hvor der ikke er taget højde for problemet i kildekoden. Vi har dog valgt at medtage denne fejltype under web-server-sårbarheder, da det oftest er her, vi har set den frem for i selve applikationen.   Eksempel: http://www.site.com/webapp.asp?ValidParameter=XXXXXXXXXXXXXXXXX[10000...]XXX   Hvordan kan man undgå de vigtigste sårbarheder i web-applikationer? It-sikkerhed og specielt web-sikkerhed er en meget dynamisk størrelser, og derfor bør man i et web-projekt altid være opmærksom på nye sårbarhedstyper.   At undgå sikkerhedsfejl allerede når man udvikler sin web-kode, er den mest effektive måde at forbedre web-sikkerheden på. Det resulterer typisk også i en mere proaktiv sikkerhedsmæssig holdning i organisationen, som kan gavne virksomheden på mange andre fronter end blot ved web-udvikling.   De to vigtigste ting man bør fokusere på for at undgå de vigtigste sårbarheder i web-applikationer er input-validering og code review.   Hvad er input-validering, og hvordan gør man? En meget stor andel af de sårbarheder, man ser i web-applikationer i dag, kan undgås ved at sætte begrænsninger på, hvilke karakterer (tegn) som applikationen accepterer, at brugeren indtaster og ved at sætte begrænsninger på den datamængde, der må sendes til web-applikationen.   Dette kaldes input-validering og indebærer, at web-applikationen aldrig bør stole på de informationer, browseren sender til applikationen.   Den bedste form for input-validering er en løsning, hvor applikationen kun accepterer de specifikke tegn, som der forventes (fx 4 tal i et postnr.). Denne form kan dog besværliggøre det indledende kodningsarbejde og det efterfølgende vedligeholdelsesarbejde. Den næstbedste form for input-validering er en løsning, hvor applikationen fjerner de tegn, som den ikke kan acceptere (fx amperesang, semi-kolon, kommategn, apostroffer og andre specielle tegn).   Kopier heller ikke noget web-input ind i de variable, der bruges i applikationen, uden at have 100 procent styr på mængden af data, der kopieres! I C og C++ gør en strncpy fx underværker i stedet for en strcpy.   Hvad er code review, og hvorfor er det vigtigt? Alle laver programmeringsfejl, uanset hvor dygtige de er. Derfor er det en god idé at foretage et sikkerhedstjek af kodningen, det vil sige såkaldte code reviews, inden man går i produktion med hjemmesiden. Koden skal simpelthen kigges igennem for sikkerhedsfejl. Code reviews bør foretages af en tredje part, som ikke har været med til at skrive koden – fx en kollega eller ekstern samarbejdspartner.   Hvilke værktøjer findes, som kan anvendes for at øge web-sikkerheden? Det er i dag muligt at anskaffe sig et web-applikationsskanningsværktøj til at assistere sig i kodningsprocessen og til at sikkerhedsteste de færdige applikationer. De to bedste på markedet udvikles og vedligeholdes i dag af henholdsvis SPI Dynamics og Watchfire.   Hvad får man ud af at benytte et testværktøj? Et værktøj giver en unik mulighed for at teste, om sikkerheden er i orden i applikationsarbejdet. Det er imidlertid meget vigtigt ikke kun at bruge værktøjet til slut i processen men at bruge det undervejs for at finde ud af, om programmeringsarbejdet er udført tilstrækkeligt sikkert i alle faser af udviklingsarbejdet. På den måde bliver det billigst muligt at rette de sikkerhedsmæssige kodningsfejl, man måtte finde.   De fleste web-skanningsværktøjer er indrettet således, at de kan benyttes af ikke-sikkerhedsfolk. Derfor er de ofte en god løsning, da man undgår at skulle investere i at oplære udviklerne inden for it-sikkerhed. Man kan blot udstyre dem med skanningsværktøjet, som de typisk kan lære at bruge i løbet af nogle få timer.   Hvilke erfaringer har danske virksomheder med at anvende web-sikkerhedsværktøjer? Et stigende antal danske virksomheder er i fuld gang med at fokusere på web-applikationssikkerhed. Nogle danske virksomheder har allerede indarbejdet it-sikkerhed som en fast bestanddel i deres udviklingsprocedure og sikret sig, at ingen af deres udviklingsfolk er i tvivl om, at virksomheden tager it-sikkerhed meget seriøst. Andre - og det gælder de fleste - har stadigvæk langt igen   End2End er et eksempel på en virksomhed i Danmark, som er kommet langt i deres arbejde med at indbygge sikkerhed i deres web-applikationer. Virksomheden leverer tjenester til mobiloperatører - eksempelvis en tjeneste, der gør det muligt at downloade spil på mobiltelefoner. De nyder i dag, at det web-skanningsværktøj, de benytter, kan håndtere en meget stor procentdel af deres web-sikkerhedsproblemer. Og at det samtidig er så let at bruge, at de udviklere og testere, der benytter det, ikke behøver at være sikkerhedseksperter.   Efter at de fik værktøjet, har End2End altid testet web-sikkerheden i de applikationer, de har udviklet til deres kunder, allerede i udviklingsfasen. På den måde kan de rette de sikkerhedsmæssige fejl, de finder, hurtigst muligt i processen. Det er ganske enkelt for dyrt kun at teste sikkerheden til sidst i processen, har de fundet ud af. Eksempelvis vil en fejl, der koster 1 krone at rette i udviklingsprocessen koste 1000 kroner at rette, når systemet kører i driftsmiljøet, viser deres beregninger.   Hvem forhandler web-skanningsværktøjer i Danmark? FortConsult forhandler web-skanningsværktøjet WebInspect fra amerikanske SPI Dynamics. Efter vores mening er det et af markedets allerbedste værktøjer til at sikkerhedsskanne web-applikationer. Læs mere om WebInspect her.   Hvordan får man nemmest fat i et godt web-skanningsværktøj? Det nemmeste er at tage kontakt til FortConsult på telefon 7020 7525 og spørge os om mulighederne. Er I interesserede i at høre mere om andre værktøjer end WebInspect, kan vi også rådgive jer om dette, da vi løbende vurderer alle eksisterende web-skanningsværktøjer på markedet.   Hvordan kan FortConsult bidrage til at øge en virksomheds web-sikkerhed? Ud over at tilbyde virksomheder licenser til web-skanningsværktøjet WebInspect kan vi udføre en grundig test af jeres web-systemer, både af selve web-serverne og af applikationerne der ligger derpå. FortConsult finder i gennemsnit dobbelt så mange sårbarheder i web-systemer sammenlignet med andre it-systemer, så det er ofte en god idé at overveje at få udført en test mod web-systemerne. Læs mere om vores testydelse, StaySolid™, her.   Ud over web-sikkerhedstest kan FortConsult tilbyde sikkerhedsrådgivning, hvor I kan trække på vores viden og mangeårige erfaringer omkring web-sikkerhed, enten ved at benytte os som sparringspartner og/eller projektleder i konkrete projekter, fx i tilfælde af at I skal designe en ny web-løsning. I kan også nyde godt af vores erfaringer på løbende sparringsmøder, hvor vi rådgiver jer om web-sikkerhed - eller andre sikkerhedsemner - baseret på jeres aktuelle problemstillinger.   Hvad har fastslået FortConsults førende position inden for web-sikkerhed? FortConsult har gennem årene opbygget en speciel ekspertise inde for web-sikkerhed.   Vi har siden virksomhedens start i 2002 udført mere end 1800 omfattende test af større web-systemer for mere end 60 større og sikkerhedsbevidste virksomheder. Vi anvender markedets mest avancerede testmetodikker og værktøjer sammen med vores egenudviklede sårbarhedsdatabaser, som indeholder de mest opdaterede informationer om alle eksisterende web-sårbarheder.   FortConsult holder løbende konferencer, seminarer og workshops om web-sikkerhed og arrangerer gerne en workshop i jeres virksomhed, hvis I kunne tænke jer at vide mere om emnet.   Hvordan får man yderligere informationer? Hvis I ønsker at få uddybet fordelene ved at samarbejde med FortConsult omkring web-sikkerhed og drøfte mulighederne for jeres virksomhed, er I velkomne til at kontakte os på telefon 7020 7525. Det gælder også, hvis I vil have flere informationer om web-skanningsværktøjer. Tilbage >