Forældre fandt banale sikkerhedshuller i udbredt it-system til børnehaver

Illustration: Virrage Images/Bigstock
Opdateret: En forælder er blevet politianmeldt af it-leverandør til det offentlige for at have afsløret sårbarheder i børnehavers it-system på kontroversiel manér med simpelt Javascript-hack.

Et par it-kyndige forældre til børnehavebørn opdagede i sidste halvdel af 2014 en række banale sikkerhedshuller i det udbredte it-system til børnehaver Infoba.

Sikkerhedshullerne bestod blandt andet i, at man kunne få adgang til personlige oplysninger på nogle børnene, der var registreret i systemet over hele landet, når man blot var logget ind i systemet som en forælder. Der var dog ikke tale om følsomme personoplysninger ifølge Infoba.

Den ene af forældrene er siden blevet politianmeldt af Infoba for at have hacket systemet. Selv oplyser han, at han kontaktede it-leverandøren om nogle sikkerhedshuller, men aldrig fik svar, før han testede forskellige sårbarheder. It-leverandøren påpeger, at den er 'nødt til at tage hacking alvorligt'.

»Jeg sendte dem en mail med overskriften 'Stort sikkerhedshul' og regnede med, at nogen ville ringe efter 10 minutter, men de ringede aldrig. Så fandt jeg 3-4 sikkerhedshuller mere på en time,« siger den politianmeldte forælder Henrik Høyer, der til daglig er chef for softwareudvikling hos sPeople.

Hos Infoba tog man dog ikke let på, at Henrik Høyer havde taget sagen i egen hånd og testet en række sårbarheder samt lavet en Javascript-finte, der overraskede pædagogerne i en af børnehaverne.

»Jeg bliver nødt til som it-ansvarlig at tage det seriøst, når vores system bliver hacket. Jeg rådførte mig med politiet og Nationalt Efterforskningscenter (NEC), og de anbefalede at anmelde ham,« siger produktchef hos Infoba Torben Væring, som forsikrer, at de pågældende sikkerhedshuller blev lukket kort efter, at forældrene havde kontaktet Infoba.

Banale fejl i udbredt system

Infoba bliver brugt i samtlige offentlige daginstitutioner i 11 danske kommuner og bruges blandt andet som en digital version af den opslagstavle, som pædagoger og forældre skriver på i børnehaven. Systemet gemmer således blandt andet på informationer om børnenes fravær, kommunikation mellem forældre og pædagoger samt personfølsomme sundhedsoplysninger om barnet såsom allergier og sygdomme.

Sikkerhedshullerne gav dog ikke adgang til de personfølsomme oplysninger ifølge Infobas produktchef, som dog bliver modsagt af de to forældre, der opdagede sikkerhedshullerne i første omgang.

Hele fadæsen startede i august 2014, da forælder og tidligere webudvikler og -tester Christian Liljedahls datter startede i en børnehave på Frederiksberg. Her lagde faren hurtigt mærke til, at børnehavens it-system Infoba havde et gammeldags udseende user interface.

»Det ligner noget, der er holdt sammen med gaffertape. Det minder om det, vi lavede for 15 år siden. Nu har jeg arbejdet med test af webbaserede systemer, og så kan man bare mærke, når hængslet på døren ser ud til at sidde løst,« siger han.

Han lagde mærke til, at der i adresse-url’en i browseren blandt andet stod et ‘id’ med tilhørende nummer for hvert barn. Ved at ændre på nummeret kunne han således få adgang til alle de andre børns oplysninger, uden at han havde rettigheder til at se dem i systemet.

Læs også: Kodefejl lækker 10.000 CPR-numre på elever fra førstehjælpskurser

Det tjek, som der normalt er på hjemmesider med bruger-login, og som sørger for, at kun dem med de tilsvarende rettigheder har adgang til de relevante oplysninger, var således ikkeeksisterende. Selvom man skulle ændre på id’et hver gang for at få adgang til et nyt barns oplysninger, ville en scraper automatisk kunne hive oplysninger på samtlige af børnene ud af systemet.

»Det vidner om et dårligt systemdesign. Det, som er problemet, er, at hver gang de laver en ny side, så skal man sørge for at implementere et sikkerhedstjek i toppen af siden, som gør, at den bruger, der kigger på siden, også har retten til det. Hvis man havde det grundlæggende design tænkt igennem, ville man have det med,« siger Christian Liljedahl og giver systemet dumpekarakter:

»Hvis du lavede sådan et system selv i folkeskolens it-klasse, så ville du få en rød streg. Det her er en fejl, som jeg fandt på systemer for 10-12 år siden, hvor man lige havde lært at kode php-løsninger. Men nu er der gået 10 år, så burde vi have lært det. Det er ganske velbeskrevet, hvordan man gør det her,« siger han.

Produktchefen hos Infoba kan ikke komme med et svar på, hvorfor sikkerhedshullet er sluppet igennem så længe.

»Jeg ved det ikke. Vi gik efterfølgende ind og testede siderne, rettede fejlene og prøver at sikre, at tilsvarende ikke sker andre steder. Vi har lavet test af det, og det er så sluppet igennem alligevel,« siger Torben Væring.

Efter at have opdaget sikkerhedshullet kontaktede Christian Liljedahl it-leverandøren, som rettede det.

»Det, at Christian henvender sig til os, gør, at vi tager det seriøst, fordi vi vurderer, at han har været i god tro,« siger Torben Væring

Infoba er udvalgt som leverandør af intranet og hjemmesider til institutioner på den offentlige SKI-aftale, hvilket betyder, at kommunerne kan vælge systemet uden at lave et udbud først.

Netop inden for it-systemer til børnehaver har iværksætterne bag det agilt udviklede Famly tidligere været ude og kritisere det offentlige for i udbudsprocessen slet ikke at være gearet til at håndtere systemer udviklet efter moderne agile principper.

Læs også: Startup-land: It-iværksættere dropper offentlige kunder efter absurd udbudsforløb

Javascript-finte førte til politianmeldelse

Nogle måneder efter, at den første forælder opdagede sikkerhedshullet i Infobas system, blev virksomheden kontaktet af faderen til endnu et barn.

Ifølge ham selv for at gøre opmærksom på en række sikkerhedshuller i it-systemet. Ifølge Infoba gjorde faderen blot virksomheden opmærksom på, at den ikke benyttede sig af den nyeste type af krypterede SSL-forbindelse, TLS.

Herefter er der uenigheder mellem de to parter om sagens forløb.

Forælderen, Henrik Høyer havde blandt andet opdaget, at den infoskærm, som hver enkelt børnehave havde i systemet, var befængt med et sikkerhedshul, der tillod cross-site scripting. Ganske enkelt blev de beskeder, som man skrev til den fælles infoskærm, ikke renset for tegn, der gør det muligt at indsende Javascript-kode.

Det udnyttede Henrik Høyer til at skrive en simpel Javascript alertbox, der poppede frem med beskeden 'Ring til Infoba og sig at jeres nye intranet løsning er blevet hacket', hvorefter brugeren skulle trykke ‘OK’.

Det var der flere af pædagogerne, som så, og som undrede sig over, ifølge Infobas produktchef.

»Jeg skrev til Infoba og hørte aldrig fra dem. Så lavede jeg den her løsning, som måske var lige på grænsen for, hvad man må,« siger Henrik Høyer og fortsætter:

»Jeg lavede et harmløst javascript, men kunne have gjort det meget værre.«

Han påstår også at have fundet sikkerhedshuller, der tillod SQL-injection, samt en svaghed i funktionen bag glemt kodeord. Dette afviser produktchefen for Infoba.

Efter fem måneder havde Henrik Høyer stadig ikke hørt fra Infoba, men fik den 8. juni 2015 i stedet besøg af en politimand, der fortalte, at han var blevet anmeldt for hacking af Infoba.

Torben Væring forklarer, at han havde set loggen igennem, da han opdagede, at Henrik Høyer havde forsøgt at kompromittere systemet.

»Der kunne jeg se, at han havde været meget kreativ med at se, hvordan han kunne komme igennem systemet. Der må man se på, om det er i god eller ond tro,« siger Torben Væring, der efterfølgende viste loggen til NEC, som anbefalede produktchefen at politianmelde softwareudvikleren.

Torben Væring vil af hensyn til den igangværende sag ikke komme ind på, hvilke konkrete metoder Henrik Høyer benyttede sig af til at komme igennem systemet.

»Han fik kun sat en Javascript-besked op, selvom han har forsøgt på rigtig meget mere,« siger Torben Væring.

Kan du forstå, at man som forælder er bekymret for sikkerheden i det system, som ens barn benytter sig af, og forsøger at teste det?

»Det er sundt, at forældre er skeptiske og mistroiske. Men når der er en, der går til biddet, så politianmelder vi det. Hvis jeg undlader at gøre det, hvordan skulle jeg så vide, om det er en ondsindet hacker?« siger Torben Væring.

Men han skrev jo selv en mail til jer?

»Politiet mente, at det kunne blive en sag, og de anbefalede os ikke at kontakte ham. Det er grunden til, at vi ikke har gjort det. Vi når ikke at reagere på den første mail, før han hacker os, og lige så snart han gør det, så går det over i noget kriminelt,« siger han og fortsætter:

»Det, der adskiller Henriks og Christians måde at gøre det på, er, at Henrik ikke informerer os om id-hacking og script-injection først. Han kører bare på ekspansivt. Endvidere var der ingen sammenhæng i det, han kritiserede i mailen, og den teknik, han brugte til at forsøge at hacke.«

Opdateret den 11. juni kl. 12.22 med præcisering af et af sikkerhedshullerne. Der stod før, at det var muligt at få adgang til børnenes personlige oplysninger uden at være logget ind. Det er ikke korrekt ifølge Infoba, som påpeger, at man skulle være logget ind som forælder for, at sikkerhedshullet kunne udnyttes. Derudover har Version2 fået dokumentation for, hvad der præcist stod i den Javascript-alert box som Henrik Høyer lavede, hvilket er blevet rettet i artiklen. Indholdet i boksen adskiller sig fra det, som forælderen oplyste i første omgang.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (97)
Brian Hansen

Undskyld sproget, men hvor er det direkte latterligt at de anmelder nogen for at gøre opmærksom på en seriøs fejl i deres kode.
Hvis sikkerheden ikke er højere, burde samtlige forældre lave et sagsanlæg mod udviklerne af softwaren som modsvar.

De burde i virkeligheden være taknemmelige for at forælderen ikke anonymt smed instrukserne op på 4chan, reddit og diverse darknet fora. Jeg væmmes!

Simon Mikkelsen

I forskellige tilfælde har forældre fundet meget grove fejl i systemet, givet Infoba besked uden at få svar. Derefter har de lavet en uskadelig proof of concept og en blev politianmeldt.

Det er jo ikke en enkelt fejl og en uansvarlig forældre, men en leverandør der gentagende gange har ignoreret meldinger om alvorlige fejl. Én ting er at have så mange fejl i et moderne system. Noget andet er at ignorere dem og derefter forsøge at skyde budbringeren.

Hvad kan man gøre som forældre?
1. Lade som ingen ting og lade andre snage i sine børns private oplysninger?
2. Skrive til leverandøren som nok ikke gør noget. Man risikerer en politianmeldelse der kan koste jobbet.

Godt jeg ikke bor i en af de kommuner der bruger systemet!

Nicolai Rasmussen

Det virker igen som om den der laver en bil hvor hjulene falder af når man drejer på rattet, anmelder den bruger af bilen der sparker til dækket for at se om det sidder ordentligt fast. Hvornår får man straffet idioterne der laver ansvarspådragende dårlig kode? Hvis man tager sikkerhed seriøst, så laver man ikke sådan noget kluns i første omgang.

Om der er tale om hacking skal jeg ikke gør mig klog på, men den rigtige skurk i det her må være de ansvarlige for koden hvis den er så dårlig som beskrevet.

Da jeg havde jura på ingeniør studiet, lærte jeg at der var skærpede krav når man var professionel. Hvis en professionel svejser satte ild i noget i forbindelse med sit arbejde blev han bedømt relativt hårdt af dommeren. De samme faktiske forhold ville kunne frikende en der svejser som hobby, og dømme en professionel skyldig i grov forsømmelse. Når vi har med it at gøre, så virker det som om juristerne ikke har meldt sig ind i den virkelige verden. Hvor længe skal vi blive ved med at finde os i det her? Det er en skandale af rang.

Jan Gronemann

Version2s blogger, Poul-Henning Kamp, har flere gange foreslået en IT-havarikommission. Det ville være nærliggende nu at have en myndighed der ser på hvordan så ringe kode kan få lov at komme i nærheden af privat data og hvorfor de ikke har taget anmeldelser om fejl og mangler alvorligt.

Hvor er Datatilsynet også i det her? Er det ikke dem der skal sikre at der er styr på adgnag til fortrolig data?

Frithiof Jensen

Man skal nok som hovedregel ikke spilde sin tid på at skrive til de her leverandører, der er tydeligvis ikke Google vi taler om her!

Det jeg mener at man bør gøre er at stikke dem til Datatilsynet direkte. Der findes en e-tjeneste til det, http://www.datatilsynet.dk/Blanketter/

Ellers så har Radio 24/7 og andre en anonymiseret tjeneste, hvor man kan uploade informationerne. Der kunne måske komme et program ud af det med tiden.

... Ellers så er der 4Chan.

Nicolaj Hansen

Jeg forstår simpelthen ikke denne måde at arbejde på...

Hvis man ser noget, som ser ud til ikke at virke korrekt, skal man da skride til handling. Især når det drejer sig om sikkerhedsproblemer. Hvem ville tage en henvendelse seriøs om sikkerhed, hvis brugeren IKKE havde lavet et Proof-of-concept eksempel.

Kim Johannesen

Som forælder, der er tvunget til at bruge systemet, må jeg bare sige at det ikke kun er sikkerheden, der halter hos INFOBA. Hele brugeroplevelsen er gennemgående elendig, og her snakker jeg ikke blot om det aldeles forældede design, men også om informationsarkitekturen og den overordnede oplevelse.

Det er også mit indtryk at administrationen af INFOBA, altså den del hvor pædagoger og institutionsledere logger ind og benytter systemet, er helt forfærdeligt — intet andet kan undskylde det antal af tomme mails, mails uden specialtegn, mails med links der ikke fungerer osv.

Hvordan INFOBA nogensinde er blevet valgt af diverse kommuner forstår jeg simpelthen ikke.

Christian Nobel

Infoba er udvalgt som leverandør af intranet og hjemmesider til institutioner på den offentlige SKI-aftale, hvilket betyder, at kommunerne kan vælge systemet uden at lave et udbud først.

Endnu et eksempel på hvordan den korrupte forbryderhule SKI er direkte landsskadelig.

Er man først inde i klubben, så er det jo nærmest et tag selv bord.

Peter Jensen

Som jeg ser det, så burde historien være at det er de data-krænkede forældre der skal på banen og anmelde firmaet for brud på persondatasikkerheden. Firmaet skal ikke bare kunne få held til at skubbe ansvaret for sit amatørarbejde videre til den der tilfældigvis opdager at det er amatørarbejde. Jeg mener at firmaet og medarbejderne skal stå til ansvar for det arbejde de laver og bliver betalt for.

Men det er så typisk i Danmark - er du et firma eller det offentlige, så straffes skødesløs omgang med personfølsomme data stort set aldrig.

Thomas Andersen

"Hvordan INFOBA nogensinde er blevet valgt af diverse kommuner forstår jeg simpelthen ikke."

Helt enig. Det må da være en historie der er værd at grave mere i. Hvordan kan en så inkompetent udbyder blive valgt til sådan en opgave? Den fejl der blev fundet viser jo at det er rent makværk der er leveret. Der er gået noget helt galt i udvælgelsen af leverandør og efterfølgende kontrol af det leverede produkt.

Jimmy B. Carlsen

Før man hylder manden, kunne det være interessant at vide, hvad han egentlig har forsøgt - og hvor hurtigt efter mailens afsendelse.

At forvente svar inden for 10 minutter på en mail, der i overskriften kunne ligne spam er måske lige i overkanten. Og har han forsøgt at ringe?

Kunne man forestille sig, at han var blevet lidt for ivrig efter at have fundet det første hul? Og teksten i popup'en mildner det heller ikke ligefrem.

For så er det i mine øjne i orden at anmelde det til politiet. Om der så bliver en sag ud af det, er jo så op til dem.

Men samtidig tyder det også på, at Infoba fortjener at blive indklaget til Datatilsynet.

Rune Jensen

Hvordan vises posten? Laves det med javascript? Eller reloades siden og vises det hele med HTML genereret med PHP?

For i og for sig,så er det ikke så svært at lave sikkert. Man skal angive tegnsæt, sørge for, man er sikker på det er en post request, validere fieldnavne, så man ved det er den rigtige formular som er udfyldt (dette også fordi field-name/value-poisoning af f.eks. submit-button HAR jeg oplevet forsøg på - uden jeg kan se hvad de ville).

Så gemme posten i DBen og derefter HTML/XML-encode posten og sende det til klienten.

Men hvis det vises via AJAX, så er jeg ikke så sikker på, der er en nem løsning.

Med DOM-XSS, der er der uendelige muligheder. Og jeg tvivler også på, der findes nogen web-APP som fungerer på AJAX og brugerinput, som ikke er sårbar. Man er nødt til at bruge et tested anti-XSS framework så for bare at være nogenlunde sikker.

Man kan starte med at komme af med innerHTML og innerText (og det er sikkert ikke de eneste)
https://blog.mozilla.org/security/2013/09/24/introducing-html2dom-an-alt...

Ellers så er oWASP tilgængelig og har været det længe:
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Javascrript er en trade-off IMØ. Hvis man viser siden genereret 100% med HTML på serversiden så sparer man en masse problemer men så skal hele siden også reloades.

PS. Og så er HTTPOnly wel standard i alle browsere efterhånden...? Sådan man ikke behøver bruge querystring.

Ivo Santos

De har vel fået opgaven via en vennetjeneste.

Meget dårligt kan man sige om Microsoft, Google, og de andre store it-selvskaber, men det havde vel næsten været mere fornuftigt, hvis det have været et at de store selskaber der havde fået opgaven, de er trods alt vandt til den slags.

Michael Christensen

Det er mig ufatteligt, at systemer som INFOBA og andre systemer, der håndterer personlige data ikke bliver periodisk testet. Sådanne fejl som den, der er beskrevet her, er ganske simple. Hvis kravene til systemerne var, at de skal testes for f.eks. OWASP Top 10 fejl med jævne intervaller, så kunne vi måske komme et skridt videre.

Folmer Fredslund

Der er stadig huller i koden hos INFOBA.
I hvert fald i besked indbakken, hvor man ved at ændre "childId" i adressefeltet kan få adgang til andre id'ers beskeder.

Det er så ikke oplagt hvilket nummer man skal indtaste, da de højst sandsynligt er relativt tilfældige (måske, hvem ved?) og er 5 cifrede.
Men det kan stadig lade sig gøre.
Det ser dog ud til at man skal være logget ind som bruger først.

Christian Hedemann Olsen

"»Politiet mente, at det kunne blive en sag, og de anbefalede os ikke at kontakte ham"

Det kan da godt være der principielt kan være en sag, men man bestemmer da selv som virksomhed hvordan man håndterer det. Det er virkeligt tyndt at ligge ansvaret for den beslutning over på politiet. Man kunne jo vælge at sige tak for hjælpen og få rettet sine fejl. Valget må mest af alt være baseret på om man mener tingene er gjort i god eller ond mening. Der kan vist ikke være tvivl om hvad sagen er her.

At retsforfølge folk kommer i hvertfald ikke til at stoppe hverken de rigtige hackere eller hullerne i koden.

Jacob Hassing

I den "rigtige" verden belønner politiet for at gribe ind, for at undgå skadelig adfærd. Sidst her http://www.dr.dk/Nyheder/Indland/2015/06/10/190940.htm
Ikke at beskytte personfølsomme oplysninger har retsvæsnet hjemmel for reagere kraftigt over for - også selvom det er i et miljø retsvæsnet ikke er vant til (kan) navigere i. Hvor anklager politiet firmaet ??

Henrik Høyer Blogger

Selvom både jeg politiet ikke regner med at sagen nogensinde kommer for retten, ville det dog være meget fornøjeligt.

I en evt. retsag skulle Infoba jo fremlægge deres såkaldte beviser mod mig. Det ville tydeligt udstille manglerne i deres løsning og dermed give dem problemer i forhold til deres kunder (som btw er I deres gode ret til at lade handelen gå tilbage - Infoba har ikke leveret det lovede)

Torben Jensen

I Odense har man valgt at forke en kæmpe bunke penge efter "NemBarn" (bare titlen giver mig myrekryb). Det ligner også noget fra for længe siden, og kræver guhjælpemig at man skal have NemID nøglekort frem hver gang man skal se lille Annas dagbog fra sandkassen.

Men er der nogen som ved hvordan de har det mht sikkerheden ?

Og vores alle sammens elskede skoleintra ?

Begge firmaer er også nærmest monopolister.

Og ja, jeg er også irriteret over at man skylder budbringeren i stedet for at løse problemet. De burde belønnne ham i stedet. Havde han over en anonym forbindelse silently slettet deres database et sted var der måske lidt mere røde øren. Men det kan være det er DET som skal til fremover ? Og så bare holde bøtte med det. Men synd for det stakkels personle som IKKE har fået mere tid efter der blev drysset ITstøv ud over dem og deres dagligdag.

Christoffer Hoel

Jeg brugte 5 minutter med app'en fra min kommune (Rudersdal) og Charles Proxy. Her er hvad jeg fandt uden at kigge i dybden:

  • Opslag (f.eks. nyheder, madplaner) fra min søns institution er offentligt tilgængelige, hvis man har den rette url. Man vil kunne finde alle opslag ved at ændre på id parameteren. Siderne bliver i det mindste hentet https. Se screen short.

  • Billeder er også offentligt tilgængelige, hvis man har den rette url. Denne url indeholder modsat opslag "både" id og UserId. Med et simpelt script, ville man kunne downloade alle billeder fra hele systemet ved at ændre på begge parametre og evt. fjerne width for at få billeder i den original opløsning. Billederne bliver IKKE hentet via https. Se screen short.

  • API-kald indeholder både brugernavn og password som clear-text i headeren! Kaldene sker godt nok via SSL, men alle ved at dette er en dårlig ide. Se screen short.

Gad vide hvad man ellers kunne finde, hvis man gravede dybere?

Nu venter jeg bare på at blive politianmeldt...

Christian Liljedahl

Det er jo kernespørgsmålet her, som det ville være dejligt at få afklaret.
Hvis jeg har en mistanke til at et system er usikkert eller hullet, hvor meget må jeg så gøre for at efterprøve min formodning?

Vi har jo, så vidt jeg er orienteret, ikke en national Security audit unit, som man kan skrive til, som så vil teste en løsning igennem for at se om den er åben, eller gør Datatilsynet sådan noget også?

Jeg gik ikke videre med sagen i august, da det virkede til at Infoba tog min henvendelse seriøst. Men jeg er stærkt forundret over, at de ikke har strammet an her snart et år efter.

.. Og vi er slet ikke begyndt at snakke om deres usability-forbrydelser...

Povl H. Pedersen

Jeg mener, at man bør have en standardpasus om sikkerhed i alle kontrakterne, og så smide leverandører som disse ud af SKI, specielt da det ser ud som om at sikkerhed slet ikke har været en integreret del af løsningen, og de øjensynligt aldrig har pen-testet hverken internt, eller med ekstern hjælp.

Gæt en URL parameter er IKKE sikkerhed, men er at sidestille med at de har udstillet alle børnenes persondata offentligt hvis man spørger mig. Jeg vil sige at leverandøren her har leveret en løsning der er så groft uansvarligt strikket sammen og testet, at leverandøren bør bære et skærpet ansvar for løsningen.

Jeg forventer selvfølgelig at få et brev fra det offentlige, såfremt det i logfiler (som fårhåbentlig gemmes år tilbage) kan konstateres at der er sket noget der ligner scraping, hvor mine børns data også er høstet.

Bjarne Nielsen

Artiklen siger:
"Infoba bliver brugt i samtlige offentlige daginstitutioner i 11 danske kommuner"

Jeg kan kun finde anmeldelser fra to kommuner til Datatilsynet, hvor Infoba er nævnt som databehandler (Thisted og Gladsaxe). Er det mon fordi, at de andre 9 kommuner bruger en anden databehandler?

Jesper Lisby

Jeg kan kommentere på SkoleIntra som tidligere bruger af personaledelen.

Udover at interface & usability kunne trænge til en gevaldig overhaling, så er der f.eks. ingen SSL/TLS kryptering ved login.

Du kan specifikt benytte UNI-login (som bruger TLS), men ikke alle skoler tvinger deres medarbejdere til at gøre det ved login, og når medarbejderne har valget, tager mange nok den nemme løsning med gammeldags skoleintra-login. Selvom du bruger UNI-login, er problemet dog stadig gældende på resten af skoleintra - der er ingen kryptering af den data du sender/modtager.

Så alt man sender og modtager derfra kan i princippet opsnappes af mellemled. Det er ikke betryggende, når det nu er børn og forældres helt private data der opbevares her, ligesom der er fortrolige oplysninger og korrespondencer mellem personalet.

En opstrammer kunne klart anbefales.

Rune Jensen

Gad vide hvad man ellers kunne finde, hvis man gravede dybere?

Well, hvordan ser JSen til sammensætningen af en post ud? Er det AJAX?

Og så blev der nævnt SQL-injection, der burde være masser af muligheder, hvis ikke det er lavet korrekt.

Det eneste, som rent faktisk virker er separering af brugerinput fra sidens egen kode med parameterized queries.

Hvis ikke de bruger det, så er der en mulig sårbarhed.

De kunne give den en tur igennem w3af f.eks. Så man får de lavthængende frugter.

Anders Kvist

Det øjeblik du tager i en dør du ikke er berettiget til at gå ind ad, så har du forsøgt at begå indbrud... i hvert fald som jeg er bekendt med loven :) Ret mig endeligt hvis jeg tager fejl...

PS. Fuck hvor åndsvagt V2 - når et emne er lavet til næsten max og I tilføjer "Re: " foran når man svarer, så bliver det for langt til man kan submitte ;)

Torben Jensen

Ud over naturligvis JS injection, er der så ikke en tradition for at dybe, direkte links er "hemmelige" - og dermed er det "hacking" hvis man bruger det direkte link i stedet for hovedsiden.

I eksemplet ovenfor altså
https://brugerintra.aeblerodkommune.dk/AppV2/Web/Institution/Institution...

Indenfor offentlig udvikling (OG f.eks. Nykredits netbank) er det desværre stadig på mode med IFrames, så det hele bliver "lettere" og direkte url er skjult.

Rune Jensen

Ud over naturligvis JS injection, er der så ikke en tradition for at dybe, direkte links er "hemmelige" - og dermed er det "hacking" hvis man bruger det direkte link i stedet for hovedsiden.

Held og lykke med at sagsøge google fordi googlebot gik den vej.

Man kan nemt fodre googlebot med en URL, som ikke er "offentlig".

Derfor er det fuldstændigt hul i hovedet, hvis man laver dybe links ulovlige på den baggrund, at det ikke er "offentligt".

Hvad man SKAL gøre er at binde ens session med siden og et token i formen. Evt. også med IPen, men mit argument vil så være, amn skal slås med Opera Turbo så.

Hvis du låser dit besøg til siden med et token i foremn, og det token, det giver du også i en session cookie, så er du ret langt. Du kan IKKE komme ind fra et "ikke-offentligt link" uden begge dele.

Hvis du yderligere med det token så laver et fingerprint af headeren, så vil jeg mene det er umuligt at gå den vej, med mindre man kan få adgang til brugerens side, som den er med HTML (fysisk eller via malware). Særligt med HTTPOnly vil man få problemer.

Her:

Method: GET

HTML:

<input type="text" name="[header fingerprint][fixed random alphanumeric field][stardate of GET request]_something">

Session-Cookie: something="[header fingerprint][fixed random alphanumeric field][stardate of GET request]"

På serversiden skal FINGERPRINT kalkuleres on-the-fly ved både GET og POST. De skal være ens uanset. Fingerprint er en hash af HEADERvariable. Evt+IP

Der skal testes for, det er en POST request, før man går vidrere.

Der skal testes for, at cookien ikke er udløbet (stardate POST- stardate GET)

Og der skal testes for at hele token er den samme i textfield name som i cookien.

Hele sekevensen rekalkuleres for hver request, hvilket vil give en unik ID hver gang.

Jeg har implementeret den løsning en gang.

Jeg vil gerne se en, som kan komme ind på nogensomhelst måde udefra med den løsning. Alene hvis man bare bruger et fixed field for random alphanumeric på 3 karakterer, der har man 62 muligheder for én char. Så man får en fordeling på 62x62x62 muligheder, som man skal gætte. Og det ændres ved næste reqwuest. Og det er bare for dét field.

Selvfølgelig vil FINGERPRINT være den samme med den samme browser, men det bliver beregnet udelukkende på serveren. Man kan kun fifle ved at ændre i sin header. Som man skal kende hos brugeren.

Christian Nobel

Det øjeblik du tager i en dør du ikke er berettiget til at gå ind ad, så har du forsøgt at begå indbrud... i hvert fald som jeg er bekendt med loven :)

Det kommer temmelig meget an på forsættet.

Det kan være farligt at sammenligne med den fysiske verden, for der er mange flere nuancer omkring døren, og om hvorvidt det er en dør fra et firmas tomme reception, hvorfor man åbner døren og råber "hallooo, er der nogen", eller om det er en dør til et tydeligt afmærket våbenlager.

Men det er måske mere relevant at forholde sig til at forsikringsselskaber (nogen gange) nægter at betale erstatning hvis nøglen er efterladt i tændingen, og døren ikke er låst.

Uagtet hvordan man end vender og drejer den, så er Infobas omgang med sikkerhed dilettantisk, og deres reaktion på henvendelserne vidner om et foretagende hvor man må tro at inkompetence er et krav ved jobsamtalen.

Christian Nobel

Da der er personfølsomme opslyninger tilgængelige, så er det jo bare at trække leverandøren i retten som kollektivt søgsmål fra de institutioner der benytter det møg kode.

Nu har institutionerne jo sådan set rigeligt med bekymringer i forvejen, og det er jo som så heller ikke dem der er ofrene, men børnene og deres forældre.

Og så er det pludselig at det bliver overmåde svært at få samling på et kollektivt søgsmål.

Christoffer Hoel

Login foregår ukrypteret over http som almindelig form-data. Hvis et login fejler får man 500 Internal Server Error som svar med et stacktrace fra .NET:

<LoginError>   
    <Message>Fejl ved Login.</Message>   
    <ErrorDetails>System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).  
        at System.Guid.GuidResult.SetFailure(ParseFailureKind failure, String failureMessageID, Object failureMessageFormatArgument, String failureArgumentName, Exception innerException) at System.Guid.TryParseGuidWithNoStyle(String guidString, GuidResult&amp; result)  
        at System.Guid.TryParseGuid(String g, GuidStyles flags, GuidResult&amp; result)  
        at System.Guid..ctor(String g) at Login.LoginUser(String login, String pass, String deviceid, String devicename, String url, String guid, String cvr, String appname, XmlDocument xmlresponse) in d:\iis\webSites\AppV2\Web\LogonGallery.ashx:line 294  
        at Login.ProcessRequest(HttpContext context) in d:\iis\webSites\AppV2\Web\LogonGallery.ashx:line 164</ErrorDetails>   
</LoginError>

Hvordan kan man ignorere fejlsider som disse i et produktionsmiljø, This error page might contain sensitive information because ASP.NET is configured to show verbose error messages using <customErrors mode="Off"/> ?

Christian Lysel

Det ligner det er kommunen selv der drifter webserveren, både for nemboern.herning.dk og brugerintra.rudersdal.dk

Hvis det er tilfældet er det endnu mere op af bakken for Infoba.

På den anden side er *.rudersdal.dk og *.herning.dk certifikaterne så hellere ikke i hænderne på Infoba.

Christian Lysel

Grunden til det ligner kommunerne selv drifter server, er at deres IP adresser tilhører kommunerne:

nemboern.herning.dk->91.207.2.23->HERNING-RAADHUS-NET
brugerintra.rudersdal.dk->87.48.148.47->SOELLEROED-KOMMUNE-NET

Instutionslisterne kan skyldes infoba driver nogle centrale database servere.

Bent Jensen

"»Jeg bliver nødt til som it-ansvarlig at tage det seriøst, når vores system bliver hacket. Jeg rådførte mig med politiet og Nationalt Efterforskningscenter (NEC), og de anbefalede at anmelde ham,« siger produktchef hos Infoba Torben Væring, som forsikrer, at de pågældende sikkerhedshuller blev lukket kort efter, at forældrene havde kontaktet Infoba."

Vi på betagte myndigheder som en modspiller og fjende, som kafka, der indsamler alle oplysninger om alle, så de til en hver tid kan anholde en hver, som de finder formålstjenlig, og anklage vedkommen for et eller andet.
Om ikke andet så udøve tortur ved at sætte velkommen i isolation 1 til 2 år, så de kan lære det. Altså alle dem der stiller spørgsmål ved systemet. Hvor sider alle CSC lederene som har givet vores data til USA, og sminket deres regnskab for at få bonus.

Hvis ikke vi får et lille terror angreb en gang i mellem, så betaler vi selv for det, så vi kan få flere penge til yderligere overvågning, så vi kan få banket alle på plads.

Se at få krypteret alt, alle steder til alle tider.

http://www.version2.dk/blog/csc-sagen-anakata-ankesag-247894

Se at få læst den og videregive budskabet.

Ellers fortalte TV2, at vi kunne få fat i begge kandidater, på en gang i aften, midt i byen. Hvis i ville tale nogen borgerlige ord med dem.
Formodelig et mareridt for PET, når de fleste er på Bonholm, glasset er formeligt skudsikkert. Men kan ikke forstå at de meldte så tidligt ud, hvor noget skal afholdes. Men det er jo heldigvis fordi vi lever i Danmark, hvor vi ikke har historik for at skille os voldeligt af med ledere. Da vi kan stemme om det, noget som heldigvis ikke er blevet forbudt, selv om hvis vi kunne ændre systemet, ved at stemme, så ville det nok blive ulovligt.

Gad vide om det også er ulovligt, at påpege et sikkerheds problem, når vi taler om personsikkerhed.

Markus Hornum-Stenz

tager jeg da "onkel morfar"-hatten på her:

Mine børn (6. og 8. kl. nu) gik fint i børnehave uden at der var noget NemBørn-internet site, som pædagoger og forældre skulle lære at bruge (og bekymre sig om sikkerheden på).

Kan det passe, at jeg er den eneste som synes at det er mere foruroligende at SkoleKom/ForældreIntra-trenden har bredt sig ned i børnehaven, end at løsningen er dårligt udført og sagen endnu ringere håndteret (hvad jeg ikke betvivler)?

Jeg tænker at helt uden en webportal til at administrere børns børnehaveaktiviteter, kan både forældre og pædagoger bedre fokusere på kerneydelsen, børneomsorgen.

Der skal jo nok være et årligt ressourceforbrug svarende til i hvert fald en pædagogmedhjælperstilling pr. år for den enkelte institution i sådan et system her, med kurser, drift, support, softwareabonnement og tidsforbrug til Content Management.

Det går såmænd nok med en adresseliste med telefonnumre og mails, det er vi vist alle et levende bevis på.

(Og skulle det endelig være, kunne man nok forestille sig at en professionel driftsleverandør lavede en landsdækkende sikker portalløsning som institutionerne så kan vælge at købe eller lade være, ud fra en forældrebestyrelsesbeslutning.
Det må jo være relativt basal funktionalitet vi er ude i her.....)

Carsten Svendsen

Hele forløbet må da skyldes

  1. Manglende kompetence/kontrakt/forhandlingsevner hos kunden (Det offentlige). Lad mig nævne DSB, rejsekort...gab :|

  2. Manglende evner/proffesionel stolthed hos producenten.

Derfor ved jeg ikke rigtig om man kan slagte infoba så hårdt som der sker på tråden her. Vi ligger blot som der er nogen der har redt!

Jeg kan kun bifalde PHK's forslag om IT-havarikommission. Vi får mere og mere IT og det nytter ikke vi/det offentlige ikke har kompetencen. Det er DYRT... og DUMT!

Nicolai Rasmussen

Det er jo kernespørgsmålet her, som det ville være dejligt at få afklaret.
Hvis jeg har en mistanke til at et system er usikkert eller hullet, hvor meget må jeg så gøre for at efterprøve min formodning?

Vi har jo, så vidt jeg er orienteret, ikke en national Security audit unit, som man kan skrive til, som så vil teste en løsning igennem for at se om den er åben, eller gør Datatilsynet sådan noget også?

Den efterlyste service findes. Man sender urlen ud på 4chan med en beskrivelse af hvad mistanken går på og så bliver den efterfølgende undersøgt for huller HELT UDEN DIN MEDVIRKEN. Det virker som om det er den service jeg vil benytte i fremtiden - det med selv at se hvad der er galt virker meget besværligt, da man skal tale med politi osv. Det er der ingen grund til at risikere.

Henrik Kramshøj Blogger

Jeg kan se mange muntrer sig med requests osv.

1) Sørg for at slå fuld disk kryptering til med det samme!

2) Hent Burp http://portswigger.net/burp/ - eller en anden proxy der logger.

Så kan I surfe rundt på siderne via browser osv., og bagefter dykke ned i requests/response osv.

NB: Lad være med at foretage en aktiv test med Burp - det vil efter min mening klart overtræde god tro. Til gengæld vil jeg til enhver tid forsvare at man logger sin session og kigger den efter for umiddelbare sikkerhedshuller. Når de vil opbevare vores personfølsomme data, så skal vi have en vis tiltro til dem. Ligesom når man vises rundt i bankens boks, før man gemmer smukkerne.

Jacob Sparre Andersen

Vi har jo, så vidt jeg er orienteret, ikke en national Security audit unit, som man kan skrive til, som så vil teste en løsning igennem for at se om den er åben, eller gør Datatilsynet sådan noget også?

Jeg mener at man kan bede DK-CERT om at tjekke systemer for sikkerhedshuller, men jeg er usikker på om de vil tjekke et system uden først at have fået tilladelse fra systemets ejer.

Henrik Kramshøj Blogger

Jeg mener at man kan bede DK-CERT om at tjekke systemer for sikkerhedshuller, men jeg er usikker på om de vil tjekke et system uden først at have fået tilladelse fra systemets ejer.

Du mener forkert

DKCERT (Danish Computer Security Incident Response Team) er en tjeneste fra DeIC (Danish e-Infrastructure Cooperation). DKCERT er Danmarks akademiske CSIRT, der overvåger netsikkerheden for institutioner på forskningsnettet. DKCERT varsler om akutte trusler mod it-sikkerheden.

De har en specifik opgave, men poster til gengæld åbent så andre kan lære af dem.

Robert Voje

Et af problemene er at de vælger at anmelde sagen, og ikke andet.
De retter ikke op i deres egne rutiner, med mindre reglerne tvinger dem til det, eftersom det i deres verden er nogle som har prøvet at komme ind i systemet, og trusselen er ekstern.

Vi trænger virkelig til en IT-havari kommission, og det kan kun gå for langsomt.

Ib Erik Söderblom

Er intelligensen da totalt røget ud af vinduet hos Infoba og NEC ?

Et modent og ansvarligt firma havde taget kontakt på henvendelsen og sagt tak til manden for, at have udført arbejdet for dem, som de ikke var kompetente nok til selv.

Simpelthen for sølle og ynkeligt.

Bjarne Nielsen

Mon nogen har anmeldt Infobia til Datatilsynet?

Mmm, så nemt er det, så vidt jeg ved, ikke. Infoba er ikke dataejer, det er kommunerne, så det er din kommune, som skal have tilladelse fra datatilsynet og derfor er interessant i forhold til evt. anmeldelse.

Og Infoba er i øvrigt kun nævnt som databehandler (som er jo en hel del mindre end dataejer) i ansøgninger for to af de elleve kommuner (to jfr. min søgning hos datatilsynet, elleve jfr. artiklen).

Og det er så vidt jeg kan se et selvstændigt problem: hvis ikke vi får en god og nem på at give udtryk for vores bekymring på, og hvis det ikke er tydeligt, at den bliver taget alvorligt (det er ikke det samme som at få ret), så opstår der selvtægt. Som vi kan se i tråden ovenfor. Det er aldrig godt.

Min bil skal til syn før den må komme på vejen, og den skal jævnligt til syn. At det er i orden kan kan se af, at den har en nummerplade.

Min lokale pizzeria skal have smiley, og det er også udtryk for jævnlig kontrol.

Hvorfor skal applikationen, der behandler personoplysninger, ikke synes på samme måde, og hvorfor skal de ikke have en synlig nummerplade eller smiley, så vi ved hvor vi kan gå hen med vore bekymringer?

Torben Jensen

@Markus - helt enig! Jeg har også flere gange - som nærmest den eneste lidt IT-kyndige iblandt børnehavestuens forældre - korset mig over hvor ringe NemBarn er. Hvor mange gange iPad'en var frossen, programmet bare lukket, ikke-responsivt, eller bare langsomt.

Personalet var meget frustreret over at bruge meget lang tid på det. Og til hvilket formål ? I gamle dage skrev de dagens begivenheder i en bog på stuen, det var fint, og langtidsholdbart. Nu kunne de for det meste skrive online. Men det forsvandt for mig samme dag poden var ude af børnehaven.

I øvrigt var der ikke nogen som skrev til pædagogerne på NemMail, fordi det var for besværligt at finde NemID-nøglekort frem til det.

Til gengæld har det været utroligt dyrt at implementere. Og jeg er rimeligt chokeret over at firmaer kan få en kæmpe årlig licens på noget så ringe. Det er en ren malkeko. Reelt kunne studerende på en uge skrive en licensfri open-source elektronisk opslagstavle, og checkin / ud via stregkodekort - som herefter er gratis.

Desværre fortsætter det senere. Nu har vores kommunes SFO også købt et "checkin-system" / portal, som naturligvis ser elendigt ud på skærmen, fungerer i InternetExplorer - og er separat fra SkoleIntra. Jojo, endnu en cashcow, til endnu et firma.

Når der findes masser af dygtige programmører, og opensource-løsninger, hvorfor så bruge den slags ? Svaret hedder nok "fælles indkøb". Men.. SUK.

Kenneth Rasmussen

Efter at have skrevet med infoba pr mail, har jeg nu fået dette svar:

Kære Kenneth

Jeg forstår godt, at du reagere sådan her, men dele af historien er ikke rigtig. Hele pointen med at Henrik Høyer påstår, at han har kontaktet for at orientere os om java fejlen er ikke sand. Han har ikke kontaktet os om java fejlen, hverken før eller efter han fandt den. I stedet skræmte han pædagogerne i en institutionen. Hvis han havde kontaktet os og sagt han havde fundet et hul, ville situationen være helt anderledes. Da vi blev opmærksomme på java boksen, reagere vi med det samme og hullet blev lukket inden for en halv time.

Da Christian Liljadahl fandt en fejl, var vi i kontakt med han, rettede fejlen og takkede ham. Vi er altid glade for at vores brugere kontakter os, også for at påvise at vi har en fejl. Henrik Høyer er et særtilfælde, og vi bliver nød til at reagere når nogen angriber systemet så voldsomt, både for vores, kunderne og især forældrenes skyld.

Hvis du har lyst, vil min chef Torben Væring meget gerne snakke med dig, så send gerne dit telefonnummer til mig.

Med venlig hilsen

Nicoline Mygind

Kommunikationsmedarbejder

Nu er mit spørgsmål så om Version2.dk vil gå videre i sagen?

Thomas Jensen

JavaScript != Java ... Ak ja.

Til kommunikationsmedarbejderens forsvar må det siges, at der altså findes teknisk kompetente mennesker, der i daglig tale siger java når de omtaler javascript. Altså, som en slags forkortelse. Det behøver ikke være fordi hun er et teknisk analfabet... Men ja, ak, det er dælme et uheldigt signal at sende ud, specielt i en situation hvor de helst skal lave damage control.

Allan Birnbaum

Der er ikke anmeldelsespligt for Infoba; Men det er der for Dataejere. Gladsaxe kommune er, som eksempel anmeldt til Datatilsynet, i anmeldelsen er det så oplyst, at man anvender Infoba. Det er så Gladsaxes ansvar at sikre, at Infoba overholder Persondataloven og tilhørende bekendtgørelse. Jeg har forsøg at verificere, at de gør dette - uden held.

Allan Birnbaum

Ham Torben Væring lyder da ikke videre smart. Han skal da være klar over, at der er forælder, der læser disse artikler og som bor de kommuner, der anvender systemet.

Det er da helt utilstedelig, at der ikke udføres udvidede hardning-tests på et system til håndtering af persondata.

Janus Knudsen

I 2002 havde jeg en lignende sag, dog ikke med cpr-numre, men derimod med sql-injections.
Igennem et dengang populært ASP-forum blev interesserede aspirantudviklere opfordret til at teste websitet for fejl.
Jeg forsøgte mig naturligvis med sql-injection igennem login-prompten, dengang var det ASP 3.0 :) Og naturligvis havde indehaveren ikke sikret sig for den slags, hvilket endte med et bruger-tabellen blev droppet.
Det var nu ikke så alvorligt i første omgang, manden havde en backup og sitet var på ingen måde taget i brug. Men pludselig 1 mdrs tid senere fik jeg et brev fra Rigspolitiets IT-afdeling med en sigtelse for hacking.

Overrasket kontaktede jeg Rigspolitiet og tog straks afsted til afhøring, det var kun lige med nød og næppe at jeg undgik en dom. Og kun fordi at indehaveren af websitet havde spurgt efter en test.

Hvis ikke der var opfordret til test af websitet var jeg blevet dømt for hacking. Så altså... den dag i dag er det stadig ulovligt at ændre querystrings og forsøge at tvinge systemet til at opføre sig anderledes end tiltænkt.

Infoba eller ej, du har hacket deres side, endda i en ganske voldsom grad med scripting og tilhørende sql-injection og det skal du dømmes for.
At Infoba sløser med deres data er en anden snak og det tager Datatilsynet sig af.

Henrik Høyer Blogger

Overrasket kontaktede jeg Rigspolitiet og tog straks afsted til afhøring, det var kun lige med nød og næppe at jeg undgik en dom. Og kun fordi at indehaveren af websitet havde spurgt efter en test.

Du undgik at blive mistænkt. En evt anklage kommer først senere (hvis de mener at der er hold i mistanken). En evt dom kræver altså også lige en dommer....

Henrik Høyer Blogger

Infoba eller ej, du har hacket deres side, endda i en ganske voldsom grad med scripting og tilhørende sql-injection og det skal du dømmes for

Du har vist ikke fulgt med i sagen (eller læst anklageskriftet som jeg linker til ovenfor).

Jeg har ikke haft adgang til systemer eller på anden måde haft adgang til data. Jeg er anklaget for at have skrevet "script alert"* i et beskedsystem mellem forældre og institution.

*) V2 forummet forhindrer mig i at skrive det præcise, men prøv at google efter "script alert"

Janus Knudsen

Du undgik at blive mistænkt. En evt anklage kommer først senere (hvis de mener at der er hold i mistanken). En evt dom kræver altså også lige en dommer....

Sikke noget vrøvl Henrik, jeg blev sigtet fordi jeg var mistænkt i forholdet. Politiet afhører derfor en og fremlægger informationen for anklagemyndigheden, og det er her der rejses tiltale oftest omtalt anklage. At jeg ikke blev dømt var netop fordi at anklagemyndigheden kunne se omstændighederne.

Det kan de ikke i dit tilfælde, du har forbrudt dig imod virksomhedens IT-system, derfor bliver du sigtet og anklaget og stillet for en dommer. Der er ingen formildende omstændigheder der kan forklare din adfærd, du har 100% bevidst forsøgt at blotlægge svagheder i systemet og endda afluret, iflg. Infoba ikke personfølsomme oplysninger, men det er stadig ligegyldigt. Du har hacket deres system uden ret til det.

Og jo jeg har læst anklageskriftet, hvorfor skriver du dog overhovedet det? Deraf fremgår at du har ødelagt eller beskadiget data ved at køre et script som gav dig adgang til Infobas servere.
Det er en meget alvorlig sigtelse den der som jeg på ingen måde ville tage så let på som du giver udtryk for.

Rune Jensen

Hvis ikke der var opfordret til test af websitet var jeg blevet dømt for hacking. Så altså... den dag i dag er det stadig ulovligt at ændre querystrings og forsøge at tvinge systemet til at opføre sig anderledes end tiltænkt.

Der er mullioner af forskellige webbots, som kan gøre det arbejde for dig, hvis du endelig vil gå "fri" som blackhat hacker.

Lav en webside, check at user agent indeholder "bot" eller "http://" og servér et link med SQL injection i kun for dem. Bare en 3-4 dages tid.

Hvilke forskellige botter er der?

Well, selvfølgelig googlebot, Bing bot, Yahoo slurp, men også ahref (som er en bot a ukendt formål), forskellige kinesiske, russiske og japanske botter, open source botter (majestic fx.) for enten søgemaskiner og andre. En del af dem selv med højest mistænkelige formål, men de følger et link, hvis de finder det, det er udgangspunktet.

Sågar er der også botter, som er bestemt til at søge efter ophavsretligt eller "forbudt for børn" link - som de også følger, og maskerer sig som "søgebotter".

Lad botterne gøre arbejdet med at "trykke" på link med SQL-injection, og så slet den webside hvor det startede fra. Voilá.

Vil man være ekstra avanceret - find botter, som udelukkende er med "ondartet" formål (harvesters) og udnyt dem. Søg efter fx. useragent Firefox 2.0, MS IE6.0 eller JAVA, tom accept-language og tom accept-encoding. ...eller test dem op imod stopforumspam's IP-database, som har et API til det.

Virker det?

Tjah... Jeg har lavet forsøget i mindre format med min egen side (så jeg også kunne følge dem i loggen). De fulgte gladeligt linksne, jeg gav dem, uanset en del må have virket mistænkelige, var de blevet fulgt af et menneske. En del af disse kom fra kinesiske IPer... god held og lykke med at spore SQL-injection forsøg den vej fra.

Formålet med det var så ikke i sig selv SQL-injection, men det var en måde at teste, hvordan hjemmesiden ville reagere, hvis den blev udsat for et sådant angreb "udefra" (og der ER andre måder at lave ondartede ting end ved SQL i query string). Søgebotter besøger ens hjemmeside hver dag, det gør ondartede botter ikke nødvendigvist (og med de angreb man er ude efter at teste).

Det gav mig nogle idéer til, hvornår man kan sige en URL er så "twisted", at den må anses som med vilje lavet sådan. Og så sende disse fuldt ud detecterede "angreb" til honeypotten. Andre ville så få en fejlside eller blive redirect til hovedsectionen, alt efter hvor twisted URLen var.

Det hele endte med en ren white list på query string iøvrigt, hvor kontrollen med hvad der sker er ret fintmasket i både query string variabel og værdi. ...og jeg får stadig de her "injection-forsøg" jeg fødede dem med fra diverse botter (særligt Bing-bot), omend ikke så tit mere.

Som en opfølgning... HVAD ville der være sket, hvis den SQL-injection, som lukkede Valus-serverne ned tilbage i midt-2000, var blevet fulgt af google-bot? Det var jo netop et link, man kunne trykke på... og det har altid undret mig, at Google ikke fik lagt dem ned først. Men måske var der nofollow på...

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017