mboost-dp1
unknown
Titlen er fejlagtig - hullet er ikke lukket!
MS har foreslået en løsning så man kan gardere sig mod fejlen.
Hjemmekodere vil bruge 5 minutter på at fixe det(det er 5 linie i global.asax).
Men for os i den virkelige verden er det et stort problem - her retter man ikke bare i produktionskode.
I teorien ville det bestå i at jeg rettede fejlen på min lokale maskine - lavede code review med en kollega. Så smed vi det på en test server hvor vi testede at det rent faktisk virkede.
Derefter på en stagingserver der ligner produktions miljøet, og så endelig på produktion.
Og for alle dem der ikke bruger stateserver vil sidstnævnte ikke kunne foregå i business hours da alle vil blive logget ud.
#1)
Kald mig bare anti-ms - ovenstående er fakta - og jeg lever forresten af at lave asp.net. At du tilsyneladende dømmer folk på deres holdninger istedet for faKta må være din sag!
MS har foreslået en løsning så man kan gardere sig mod fejlen.
Hjemmekodere vil bruge 5 minutter på at fixe det(det er 5 linie i global.asax).
Men for os i den virkelige verden er det et stort problem - her retter man ikke bare i produktionskode.
I teorien ville det bestå i at jeg rettede fejlen på min lokale maskine - lavede code review med en kollega. Så smed vi det på en test server hvor vi testede at det rent faktisk virkede.
Derefter på en stagingserver der ligner produktions miljøet, og så endelig på produktion.
Og for alle dem der ikke bruger stateserver vil sidstnævnte ikke kunne foregå i business hours da alle vil blive logget ud.
#1)
Kald mig bare anti-ms - ovenstående er fakta - og jeg lever forresten af at lave asp.net. At du tilsyneladende dømmer folk på deres holdninger istedet for faKta må være din sag!
#3
Det er i alle tilfælde et definationsspørgsmål, og det er en åndsvag diskussion, eftersom MS folk, eller hvad fanden man nu skal kalde dem, har en overfølsom holdning til hvad der er flame.
Microsoft har ikke leveret et fix, hvilket er et problem, hvis den her tråd ender i en flamewar er det #1's skyld, det er en latterlig måde at ligge op til flame på.
Det er i alle tilfælde et definationsspørgsmål, og det er en åndsvag diskussion, eftersom MS folk, eller hvad fanden man nu skal kalde dem, har en overfølsom holdning til hvad der er flame.
Microsoft har ikke leveret et fix, hvilket er et problem, hvis den her tråd ender i en flamewar er det #1's skyld, det er en latterlig måde at ligge op til flame på.
#6: "Microsoft har ikke leveret et fix, hvilket er et problem"
Jo, de har leveret et fix. Men de har ikke lukket hullet hvis det var det du ville frem til.
Fixet ser dog ud til at løse problemet, så spørgsmålet er hvor stor en betydning det har at de ikke decideret har rettet fejlen i ASP.NET.
Jo, de har leveret et fix. Men de har ikke lukket hullet hvis det var det du ville frem til.
Fixet ser dog ud til at løse problemet, så spørgsmålet er hvor stor en betydning det har at de ikke decideret har rettet fejlen i ASP.NET.
#7
Microsoft har ikke lavet et fix... De har lavet en workaround!
Den workaround består af et seperat modul!
Se http://www.microsoft.com/security/incident/aspnet....
Workarounds er effektive, men det er kun midlertidige løsninger...
Microsoft har ikke lavet et fix... De har lavet en workaround!
Den workaround består af et seperat modul!
Se http://www.microsoft.com/security/incident/aspnet....
Workarounds er effektive, men det er kun midlertidige løsninger...
#7
Man kan vælge at kalde det et fix, men i sidste ende er det ikke en løsning at folk skal ændre i deres kode, fordi en asp.net funktion ikke virker ordentligt. Hvis der står i microsofts asp.net information at den form for opsætning er sikker, så er det ikke et ordentligt fix, men et hack uden om en fejl.
Det er selvfølgelig godt at de udsender det hack, så folk kan sikre deres sider, men de skal også helst ud med et ægte fix, ellers er problemet ikke løst.
Man kan vælge at kalde det et fix, men i sidste ende er det ikke en løsning at folk skal ændre i deres kode, fordi en asp.net funktion ikke virker ordentligt. Hvis der står i microsofts asp.net information at den form for opsætning er sikker, så er det ikke et ordentligt fix, men et hack uden om en fejl.
Det er selvfølgelig godt at de udsender det hack, så folk kan sikre deres sider, men de skal også helst ud med et ægte fix, ellers er problemet ikke løst.
Workaroundet er jo sådan set en rar ting, indtil de får releaset en SP/hotfix til frameworket..
..fessor..
..fessor..
#5
Du kan sagtens opdatere de 2 linier der kræves, for derefter at opdatere produktions serveren når det er passende.
Det er jo ikke fordi koden ikke kan gennemskues, det er helt ligefrem hvad koden gør, At lave et "code review" + teste på staging server vil tage ca 5 min.
Jeg arbejder også med asp.net. Det tog mig ca. 1 min at lave et httpmodul med fiksen, 2 min at teste det sammen med kollega, 2 min at opdatere servere.
Du kan sagtens opdatere de 2 linier der kræves, for derefter at opdatere produktions serveren når det er passende.
Det er jo ikke fordi koden ikke kan gennemskues, det er helt ligefrem hvad koden gør, At lave et "code review" + teste på staging server vil tage ca 5 min.
Jeg arbejder også med asp.net. Det tog mig ca. 1 min at lave et httpmodul med fiksen, 2 min at teste det sammen med kollega, 2 min at opdatere servere.
sguft:
Problemet er bare at den slags workarounds er LANGT mere resourcekrævende end mange umiddelbart tror!
Hvis man har en nogenlunde seriøs tilgang til QA, er det ikke et 5 minutters fix!
Problemet er bare at den slags workarounds er LANGT mere resourcekrævende end mange umiddelbart tror!
Hvis man har en nogenlunde seriøs tilgang til QA, er det ikke et 5 minutters fix!
#13: Tjah jeg skal ikke kunne sige hvor ressourcekrævende ovenstående workaround er, men eftersom der blot er tale om et filter tror jeg det er begrænset. Kan du ikke leve med det, må du jo så håndtere situationen manuelt.
Det var iøvrigt ikke mig der påstod at der var tale om et 5 mins fix :)
Det var iøvrigt ikke mig der påstod at der var tale om et 5 mins fix :)
1. De har oplyst hullet
2. Man retter fejlen og lever med den test
3. Vi er alle sammen glade for .NET igen
2. Man retter fejlen og lever med den test
3. Vi er alle sammen glade for .NET igen
ok, det kan godt være det bare er fordi jeg er lidt stiv og lige kommet hjem, men lyder det ikke bare som om at ms kun fikser lige præcis den type validerede url's og ikke selve sikkerhedshullet? :>
#5: Har ikke sagt noget om dig personligt, og selvfølgelig er det et problem med en sikkerhedsfejl af denne karakter, men har oplevet alt for mange gange her på newz.dk, at alt, der har noget med MS at gøre bliver til en ligegyldig nedgørelse af at, der har lavet. Men #1 håbede jeg lidt at komme den i forekøbet, så vi kunne holde os til emnet.. Er hverken anti-MS eller specielt for MS selv.
#17: Det sidste års tid har det /netop/ været flamebait indlæg som dit nr. 1 der har startet flamewars, /hver/ gang.
Det undrer mig iøvrigt at man ikke har sikret sig mod malformed url's fra starten af. Er ikke ligefrem noget nyt for MS (har da været en del af den slags fejl på IIS før), og man må formode de har overvejet at .NET skulle bruges på nettet :)
Så jeg må erkende at jeg faktisk er ret overrasket over at de har lavet sådan en fejl komme ud.
#13: Det er klart at tingene skal checkes og at krævende vil være højere jo vigtigere den production server det evt. skal deployes på er, men som jeg forstår fixet bør det vel kunne komme på relativt hurtigere end så mange andre ting. Det er vel iøvrigt ikke specielt anderledes ift. at installere security fixes - mao. ville det vel være næsten det samme hvis i skulle installere en patch - i kan skippe code-reviewet men test og evt. debugging af en applikation der opfører sig anderledes efter bugfixen kan i jo ikke undgå.
Det undrer mig iøvrigt at man ikke har sikret sig mod malformed url's fra starten af. Er ikke ligefrem noget nyt for MS (har da været en del af den slags fejl på IIS før), og man må formode de har overvejet at .NET skulle bruges på nettet :)
Så jeg må erkende at jeg faktisk er ret overrasket over at de har lavet sådan en fejl komme ud.
#13: Det er klart at tingene skal checkes og at krævende vil være højere jo vigtigere den production server det evt. skal deployes på er, men som jeg forstår fixet bør det vel kunne komme på relativt hurtigere end så mange andre ting. Det er vel iøvrigt ikke specielt anderledes ift. at installere security fixes - mao. ville det vel være næsten det samme hvis i skulle installere en patch - i kan skippe code-reviewet men test og evt. debugging af en applikation der opfører sig anderledes efter bugfixen kan i jo ikke undgå.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund