Zepcom tilbyder i øjeblikket sikkerhedsanalyser med 10% rabat helt indtil nytår. Zepcoms sikkerhedsanalyser er din virksomheds mulighed for at få tjekket og forhøjet sikkerhedsniveauet på alle jeres IT-systemer. En sikkerhedsanalyse består basalt set af et kontrolleret hackerangreb mod jeres systemer, men hvor en normal ondsindet hacker ville forsøge at udnytte systemet til egen vinding, så fortæller vi jer om ethvert hul vi finder og hvordan I kan løse problemet. Virksomheder som Amitech Danmark A/S og SPAMfighter Aps har tidligere fået deres systemer analyseret af Zepcom og begge har været meget tilfredse. Faktisk har de været så tilfredse, at de har skrevet en fin anbefaling, som nu kan læses på Zepcoms webside under referencer. I kan finde langt mere information og bestillingsmuligheder på:
Og så bare for at være flinke giver vi den første 2 der bestiller 30% rabat i stedet for 10%. Så skynd jer inden rabatten bliver stjålet for næsen af jer.
Hvis I har testet SpamFighter hvordan kan det så være at man stadig kan lave HTML-injections? Og når man kan det, er i så 100% sikre på man ikke også kan lave JavaScript eller SQL-injections? :)
MARTIN for helvede, jeg HAR sagt det her til dig flere gange. Få nu for beskyttet jeres site ordenligt mod den slags! :) - Og nej, jeg poster IKKE resultaterne af min lille test her - jeg kan blot konstatere at injections stadig kan lade sig gøre. Og det er bare ikke godt :)
Og dette skal ikke tages som et decideret angreb på Zepcom - I er ikke værre end alle de andre sikkerhedsfirmaer jeg har set teste websites. HVER gang jeg har set sådan en test har jeg alligevel kunne slippe igennem. Og jeg er altså ikke nogen særlig god hacker. Nærmest en latterlig amatør. Så jeg tør slet ikke tænke på hvad dem der virkelig kan, kan lave af ballade ....
Jeg har tit opfordret kunder til at få testet deres sites, men jeg er holdt op med det da de test sikkerhedsfirmaerne laver alligevel ikke dur. Det er satme sørgeligt, for der er alvorligt brug for disse tests. Jeg føler mig bare ikke kvallificeret til at lave dem selv.
Jeg kunne ikke lade være med lige at tjekke Amitech også - og her kunne jeg også eksekvere fremmed kode. Det var _lidt_ mere besværligt men ikke så meget at jeg, den glade amatør jeg er, ikke kunne komme ind. Ikke så godt ...!
Jeg skal forsøge - men nu er ER jeg som sagt blot en glad amatør-hacker. Min viden på området er ikke Så fantastisk stor, så hvis andre har bedre, eller mere detaljerede forklaringer, så bare kom med dem :)
Jeg har skrevet et par artikler om XSS på min blog - dem kan du lige starte med at få: http://www.demib.dk/xss-cross-site-scripting-157.html http://www.demib.dk/cross-site-scripting-329.html
Cross Site Scripting (som normalt bare forkortes til XSS) handler grundlæggende set om at eksekvere fremmed kode i andres applikationer. Såvidt jeg ved har den slags fundet sted lang tid før Internet og World Wide Web kom frem. Men med Internet er det bare blevet meget lettere.
En webapplikation, eller bare et helt almindeligt website som f.eks. dette, er ofte indrettet til at kunne modtage forskelligt input fra brugerne. I en debat kan man oprette profiler, skrive indlæg, søge osv. Det som brugerne inputter eksekveres på serveren, o vises (som regel) på websitet i en eller anden form. Normalt er disse input beregnet til bare at være tekst, men det er sjældent at de er begrænset til dette. Lad os tage et simpelt eksempel på en søgeboks.
Når du søger vises der på resultatsiden ofte en tekst i retning af "du søgte på XXX". Så langt så godt. Men hvad nu hvis man ikke søger med et ord, men med en lille stump HTML-kode - f.eks. et link. Hvis søgeapplikationen ikke er beskyttet mod den slags, vil der så på søgeresultatsiden optræde et link der hvor dit søgeord ellers ville blive vist. Denne teknik bruges bl.a. af SEO-hackere som gerne vil have links fra sites, der ikke frivilligt vil linke til dem :) (der mangler dog lige et par vigtige elementer i denne beskrivelse for at det dur - det er med vilje jeg har udeladt disse tips)
Men det var så bare HTML-injection. Det meste HTML-injection er forholdsvist harmløst. Men, hvis man kan injected HTML kan man som regel også injecte JavaScroipt. Og så begynder det at blive farligt. Med et JavaScript inject kan man faktisk overtae hele browseren og blandt andet omskrive hele DOM''en i IE. Det betyder i praksis at du kan skabe din helt egen side på andres domæner! Perfekte phising! Men det kan også bruges til at opsnappe mange andre informationer - f.eks. læse folks cookies, passwords osv. Det er faktisk kun fantasien, og mængden af huller i et website, der sætter grænsen.
Og det var så JavaScript injections, som kan være slemme nok i sig selv. Endnu værre bliver det med SQL-injection. Med SQL injection manipuleres webformularer, der poster til en SQL-database, på en sådan måde at hackeren faktisk kan få adgang til selve databasen! Hvis databasen så ikke er ordentligt beskyttet kan hackeren herfra i princippet gøre hvad han vil - tømme databasen, læse det hele, ændre alting og virkelig fucke op i det.
En af de mere underholdende historer om XSS er historien om ham fyren der lagde MySpace ned (en af de første gange): http://fast.info/myspace/ - det er lidt nørded læsning, men virkelig sjovt. Læs også kode-detaljerne her, så vil du forstå meget mere om hvordan en XSS-hacker tænker.
ha.ckers.org har også en god artikel her, der oså inkluderer en masee tools til formatering af scripts: http://ha.ckers.org/xss.html
Nu har jeg selvfølgelig været utilgængelig hele aftenen. Så har ikke haft mulighed for at forklare disse ting. Dette gør jeg dog nu:
De huller du har set har vi opdaget. Det er nogle som de enten ikke har fået lukket, til trods for vores opfordring, eller nogle som er kommet siden vores analyse. I begge tilfælde (SPAMfighter og Amitech) er de blevet gjort opmærksomme på disse huller, men jeg kan skam godt forstå det ser underligt ud når vi fortæller siderne er blevet sikret af os, men i øjeblikket er usikre. Jeg kan fortælle at sidst Amitech fik sikkerhedsanalyseret deres side var Februar 2006 og SPAMfighter var Maj 2006. Desuden har vi lige fornylig informeret Amino om adskillige fejl på forummet som også skal rettes.
En af de ting vi forsøger at få virksomheder til at forstå er, at sikkerhed ikke er statisk. Det er et dynamisk område der skal udvikles på, på lige fod med hvordan websiden bliver udviklet. Det vil altså sige, at det er nødvendigt at få lavet sikkerhedsanalyser rimelig regelmæssigt, især hvis man ofte får nye funktioner ind på ens systemer...
Jeg har tit opfordret kunder til at få testet deres sites, men jeg er holdt op med det da de test sikkerhedsfirmaerne laver alligevel ikke dur. Det er satme sørgeligt, for der er alvorligt brug for disse tests. Jeg føler mig bare ikke kvallificeret til at lave dem selv.
Nu skal du selvfølgelig tænke på, at it-sikkerhedsvirksomhederne, som f.eks. Amitech, kan kun rådgive, hvilket vi også gør. Men det er ikke altid virksomhederne rent faktisk følger det der bliver sagt. Enten fordi de ikke ved hvordan (og så ikke spørger om hjælp), fordi de ikke gider, eller fordi de udskyder det og glemmer det. Mange af vores kunder får simpelthen ikke ordnet det, indtil vi minder dem om det 2-3 gange. Sådan er virkeligheden nu engang - det har intet med it-sikkerhedsvirksomhederne at gøre, for dem kan jeg ærligt sige, og det gælder ikke kun Zepcom, de får testet systemerne ordentligt og får fundet næsten alle huller og i hvert fald noget så simpelt som injections.
Zepcom har jo eksempelvis også en reel tidligere hacker, faktisk en af Danmarks bedste, som konsulent. Så hvor du, som du siger, ikke er særlig god hacker, så er han på alle måder god. Faktisk exceptionel! Problemet er bare igen, som jeg sagde før, at virksomhederne ikke altid følger hvad de rådgivet til + sikkerhed ikke er statisk, så hvis deres sider bliver ændret ofte, så vil siden ikke være sikker særlig længe, medmindre de får en abonnementydelse ind i billedet.
> En af de ting vi forsøger at få virksomheder til at forstå er, at sikkerhed ikke er statisk.
Helt enig! Og det er netop det problem jeg personligt støder ind i oftest. Websites som oprindeligt er blevet lavet sikre, men så tilføjes der en lille ting på en enkelt side, eller en "ubetydelig" detalje ændres, som ingen har tænkt over kan give problemer, og så er der pludselig en dør åben. Jeg ser det f.eks. meget ofte når der indsættes tracking scripts. Meget ofte indlæses sidens URL i koden og derved kan der injectes JavaScript, hvis ikke der er spærret for det effektivt.
Det er ikke nok at låse alle dørene, hvis man lader vinduet stå åbent :)
Jeg synes måske i burde overveje IKKE at reklamere med at I har sikkerhedstjekket bestemte firmaer - af sikkerhedsmæsige grunde. Dels fordi at det er en åben invitation til hackere - når jeg (omend jeg ikke egentligt vil påstå jeg kvallificerer mig til rigtig hacker) ser sådan noget kan jeg bare ikke lade være med liiiige at se om ikke jeg kan smute ind :) Og det kan jeg rigtig tit - næsten altid. Og dels er problemet jo, som du selv nævner, at jeres kunder ikke altid følger jeres anvisninger, eller holder sitet velsikret. Så ved at bruge jeres tidligere kunder som referencer vil jeg nok mene I øger risikoen for disse sites. Og det er jo ikke meningen :)
Hvis I forklarer dette til nye kunder, og i jeres markedsføring, tror jeg godt de fleste kan forstå, hvis I udelader referencer.
> de får testet systemerne ordentligt og får fundet næsten alle huller og i hvert fald noget så simpelt som injections.
Det er altså ikke det jeg har oplevet. Jeg har desværre set flere eksempler på, at store sikkerhedsfirmaer IKKE har fundet de injections-fejl jeg har fundet på mine kunders websites. jeg har ikke erfaring med jeres arbejde, men det er egentlit også sagen uvedkommende. jeg er ikke ude efter at nakke nogle, eller hænge nogle ud :) Min interesse er nok ikke så meget anderledes end din - at websites bliver så sikre som muligt.
Bliv gratis medlem
Opret bruger