Virus lurer på DMI's hjemmeside

http://www.dmi.dk/dmi/virussen_er_en_and

ved en søgning på ngg.js kommer der en del danske websider frem hvor ngg.js figurer i deres headerline. Er disse så inficeret, i såflad burde de påmindes om dette.

Er der virkeligt grund til at fortælle præcis den samme historie begge steder?

http://ing.dk/artikel/89837 http://www.version2.dk/artikel...8000

Peter

Nu var jeg ellers i en kort periode så begejstret over, at der var kommet et nogenlunde nøgternt IT-nyheds-site, der levede op til sin mission.

http://www.version2.dk/artikel/72

Med fare for at blive blacklistet langt ind i næste årtusinde, så fristes jeg til at sige "Version 2 ... af Ekstrabladet.dk", når jeg ser ovenstående artikels overskrift og dens eklatante mangel på relation til indholdet.

Der lurer netop ingen virus på dmi.dk! den lurer andre steder, i links til dmi.dk Efter flere gennemlæsninger af artiklen, kan jeg stadigvæk ikke finde "ekspertens" udtalelse om, hvor stort et problem det er at script-stumpen fides på siden ... hvilket i og for sig er godt det samme, for der står jo netop i artiklen, at den bemeldte script-fil IKKE findes på siden.

Det var ikke hvad jeg havde ventet af et medie, fra vis mission-statement, jeg citerer:

"vil levere uafhængig information af høj faglig kvalitet. Synsvinklen er de professionelle brugeres."

/C

Med nogle få søgninger på google kom jeg frem til at det er nedestående site som er inficeret. Det er dem som linker til dmi.dk (med virus i url'en) og får Version2 til at tro at DMI har virus. :) Husk at ha' dit antivirus opdatere før et besøg!

http://ww w.google.com/search?hl=da&rls=com.microsoft%3Ada%3AIE-SearchBox&rlz=1I7GGLJ&q=polen+ngg.js+vejret+Szczecin&lr=

http://ww w.polen-stettin.dk/

Jeg har redigeret i dine links Stig, da vi helst ikke vil have, at folk skulle klikke og uforvarende blive inficeret med en virus :)

Hvis man er interesseret i at besøge de ovenfor postede links, skal man blot copy/paste det til sin browser og fjerne mellemrummet mellem "ww w".

Men rådet gælder stadig: husk stadig at have antivirusprogrammet opdateret, hvis I skal besøge siderne!

Med venlig hilsen Julian Henlov, community builder, Version2

hvor stort et problem det er at script-stumpen fides på siden ... hvilket i og for sig er godt det samme

Uanset hvoedan man fortolker artiklen, så synes jeg det er lidt farligt at indtage den holdning.

Man kan godt sætte sig ned og sige - ok selve scriptet er lagt på en anden placeholder, så hvad rager det mig ?

Endvidere var tagget tilsyneladende lagt in på et link (i select boxen) og ikke i html'et, og blev derfor ikke afviklet.

MEN det fortæller ikke desto mindre, at dmi tilsyneladende har/havde et sikkerhedsproblem.

Var der et hul? Blev det fundet? Er der flere?

Scriptet findes ikke på siden. Det er en anden side som linker til dmi, med scriptet i linket.

Denne artikel er krydspostet til ing.dk, hvor den også er genstand for en interessant diskussion, og hvor undertegnede har svaret på en række spørgsmål fra læserne.

http://ing.dk/artikel/89837

Venlig hilsen Rolf Ask Clausen redaktionschef, Version2 og ing.dk

Scriptet findes ikke på siden. Det er en anden side som linker til dmi, med scriptet i linket.

Det var også min konklusion, selvfølgelig efter at have skrevet.

Søgemaskinernne følger jo også links så hvis der har været et link med eksempelvis: http://www.dmi.dk/dmi/index/verden/verdensvejr.htm?city=140048003&countr...; Sem er det der findes på Live.com, så følger msn bot'en dette link.

Problemet, eller DMI's fejl, er at de godkender denne URI (200 OK), hvorefter søgebot'en tror der er tale om en ny side, og ikke http://www.dmi.dk/dmi/index/verden/verdensvejr.htm?city=140048003&countr...

DMI burde returnere en 404 Not Found ved den slags.

Google er lidt smartere, for den sammenligner indholdet på tværs af de forskellige URI'er, så man ikke får alt for mange identiske sider.

Men hvis alle servere/systemer, ligesom DMI, er lige dårlige til at håndterer 'forkerte' URI'er, så kan vi se frem til en god gang forurening af søgemaskiner.

Det samme gælder for UVM, i dette link: http://us.uvm.dk/erhverv/lov/bek_vejl/index.htm?menuid=200560<script%20s...; er menuid ikke et tal, og burde også give en 404 Not Found.

Det er måske meget smart kund at benytte den delmængde af URI'en man har brug for, og discarde resten.

Men det åbner for en massiv forurening af søgemaskiner.

Nå, der er tilsyneladende problemer med at angive Links her på debatten.

De nævnte links er én lang URI, og ikke separate links, som muligvis beror på en program 'feature'.

Er der (andre) måder at angive fulde URI'er i dette system ?

DMI burde returnere en 404 Not Found ved den slags.

Øh, nej. Definitionen af 404 er "The server has not found anything matching the Request-URI", og det du sender med er en parameter, ikke en del af URI'en. Hvis du mener de absolut skal sende en HTTP-kode (<>200) selv om problemet ikke ligger i transportlaget, så skulle det vel være 500.

Øh, nå - nu skrev jeg URI og ikke URL. Men så lad os kalde den en parameter til URL'en.

Men 'parameteren' country=Polenosv.

Vil jeg stadig mene bør give en 404 Not Found, da landet hedder "Polen" og ikke "Polenosv."

Stig, synes du også det er en god idé at give en 404 som svar hvis man indtaster det forkerte password eller et forkert formatteret telefonnummer på en side? Det er jo ækvivalent.

Håndter problemer i transportlaget med HTTP-koder, og håndter semantiske problemer i applikationslaget. Tak.

Vi behøver ikke være enige, men en 500 Internal Server error betragter jeg som en programmeringsfejl, og ikke en inputfejl.

Problemet med dmi er, at man får de rigtige data op med forkert input.

Søgemaskinerne får derved en 200 OK, og tror det er et rigtigt link.

Men så giv den en 400 Bad Request i stedet.