mboost-dp1
Google Inc.
arne_v skrev:Udvikler Michal Zalewski fra Google, der har været med til at lave værktøjet, advarer dog mod, at man ser programmet som den endegyldige løsning på sikkerhed, idet der er flere ting den ikke tjekker.
Jeg skulle da også lige til at sige det... Hvad skal man med systemet, når det selvfølgelig alligevel er nødvendigt at tjekke alting igennem manuelt for at være sikker? Det skulle da være underligt, hvis alle programmørens væsentligste fejl lige præcis var dem, Skopfish fandt; hvis programmet finder en fejl, vedkommende ikke selv har været opmærksom på, er det vel bare en indikation af, at hele webapplikationen bør tjekkes godt og grundigt efter, og så er systemet vel ikke andet end en note på siden af skærmen?
#1
Jeg er delvist enig. Et værktøj, der kunne finde alle fejl, ville være rart, men det sker nok ikke. Ethvert værktøj, der hurtigt og nemt kan bidrage med en analyse af ens udvikling, er dog velkomment i min verden.
Det handler om, hvordan man bruger dem. Et vigtigt koncept i softwaretesting er at man husker, at blot fordi alle test afvikles uden fejl, er det ikke ensbetydende med at programmet er fejlfrit. En test kan påvise at der er fejl i software, men ikke erklære det for fejlfrit.
Hvis jeg har et værktøj (f.eks. Skipfish), der kan køres nogle gange i forbindelse med udviklingen (inden mit software sendes over til testerne), så kan jeg levere højere kvalitet i mine leverancer til testerne, og testerne har dermed mere tid til at finde andre fejl.
Jeg er delvist enig. Et værktøj, der kunne finde alle fejl, ville være rart, men det sker nok ikke. Ethvert værktøj, der hurtigt og nemt kan bidrage med en analyse af ens udvikling, er dog velkomment i min verden.
Det handler om, hvordan man bruger dem. Et vigtigt koncept i softwaretesting er at man husker, at blot fordi alle test afvikles uden fejl, er det ikke ensbetydende med at programmet er fejlfrit. En test kan påvise at der er fejl i software, men ikke erklære det for fejlfrit.
Hvis jeg har et værktøj (f.eks. Skipfish), der kan køres nogle gange i forbindelse med udviklingen (inden mit software sendes over til testerne), så kan jeg levere højere kvalitet i mine leverancer til testerne, og testerne har dermed mere tid til at finde andre fejl.
Nu har jeg ikke voldsomt stor erfaring med udvikling af større webapplikationer, men jeg vil da antage, at det mildest talt er en fordel at skrive sin kode ordentligt i første omgang, så den ikke bliver hjemsted for alverdens bugs, når fejl senere rettes.
Hvis et værktøj finder fejl i koden, er disse formentligt hyppigt opstående, hvorfor de ikke burde være lavet oprindeligt. Ja, det kan selvfølgelig ske, at man misser noget, men hvis det sker, antyder det for mig at se, at koden er mangelfuld og formentligt kan være kilde til diverse mere komplekse fejl - hvorfor skidtet alligevel skal gennemrodes.
Man kan selvfølgelig vælge den modsatte tilgang, at skrive en halvfærdig slamkode først og så få Skipfish til at finde de mest groteske fejl i den, men det giver næppe anledning til færre fejl, når måske relativt omfattende bugs rettes hen ad vejen.
Oveni det kommer så problemet med, at automatisering altid medfører dovenskab, og selvom det selvfølgelig udelukkende er programmørens problem, er det alligevel lidt trist, hvis en generel tendens til blindt at stole på Skipfish og lignende opstår... Det gør i hvert fald ikke produktet mere sikkert.
Hvis et værktøj finder fejl i koden, er disse formentligt hyppigt opstående, hvorfor de ikke burde være lavet oprindeligt. Ja, det kan selvfølgelig ske, at man misser noget, men hvis det sker, antyder det for mig at se, at koden er mangelfuld og formentligt kan være kilde til diverse mere komplekse fejl - hvorfor skidtet alligevel skal gennemrodes.
Man kan selvfølgelig vælge den modsatte tilgang, at skrive en halvfærdig slamkode først og så få Skipfish til at finde de mest groteske fejl i den, men det giver næppe anledning til færre fejl, når måske relativt omfattende bugs rettes hen ad vejen.
Oveni det kommer så problemet med, at automatisering altid medfører dovenskab, og selvom det selvfølgelig udelukkende er programmørens problem, er det alligevel lidt trist, hvis en generel tendens til blindt at stole på Skipfish og lignende opstår... Det gør i hvert fald ikke produktet mere sikkert.
#5 -
25. mar. 2010 09:22
Men er det ikke hovedsageligt sårbarheder som den tester for ? og ikke direkte bugs…
En god udvikler kan sagtens lave en god hjemmeside, som dog senere hen viser sig at indeholder sårbarheder, han ikke ville kende til da han udviklede den.
En god udvikler kan sagtens lave en god hjemmeside, som dog senere hen viser sig at indeholder sårbarheder, han ikke ville kende til da han udviklede den.
#4 Men du kan jo ikke skrive en komplet fejlfri kode. Det kræver jo at du ikke alene kender til sproget, men også dets fejl, alle styrker svagheder ved ethvert library og metode, og kan lave logisk tautologisk kodeveje. (Det sidste er jo pokkers svært, og kræver at du kører det igennem diverse redskaber, for at checke om det altid holder - Murphys lov dikterer jo at hvis det kan gå galt, går det galt, og kun en ren tautologi sikrer korrekt kørsel)
Der vil altid være fejl, som kommer af fejlantagelser, manglende viden, dovenskab, stavefejl, regnefejl mv. Uanset hvor pænt det er skrevet.
Eller det er ihvertfald sådan jeg oplever det. Sidst sad jeg og bannede over et array overflow, som var matematisk umuligt. Var selvfølgelig kommet til at skrive j istedet for i, i et af de mange loops :) (Okay, dårligt eksempel da det er en hyppig fejl - 1, i & j er nogle være banditter)
Der vil altid være fejl, som kommer af fejlantagelser, manglende viden, dovenskab, stavefejl, regnefejl mv. Uanset hvor pænt det er skrevet.
Eller det er ihvertfald sådan jeg oplever det. Sidst sad jeg og bannede over et array overflow, som var matematisk umuligt. Var selvfølgelig kommet til at skrive j istedet for i, i et af de mange loops :) (Okay, dårligt eksempel da det er en hyppig fejl - 1, i & j er nogle være banditter)
#7 -
25. mar. 2010 09:46
ipwn (6) skrev:Var selvfølgelig kommet til at skrive j istedet for i, i et af de mange loops :) (Okay, dårligt eksempel da det er en hyppig fejl - 1, i & j er nogle være banditter)
Kan tydeligt huske den første fejl ( jeg opdagede :-P ) lige da jeg begyndte med at programmere…
Var noget i retning af:
if( ( amount + 10 ) / count > res);
{
Return true;
}
Kunne bare ikke forstå hvorfor den altid returnerede true :-P
Med 2.000 forespørgsler/sek kan det vel også bruges til simpelt stresstest.
Måske man skulle sende denne nyhed til COWI, så de kan bruge det til at teste deres eksamenssystem.
Men det er da nice at man kan få et værktøj til at teste sine systemer. Til de små systemer er det perfekt, og til de store kan det sikkert bruges til en overfladisk test (kræver stadig special udviklet test).
Måske man skulle sende denne nyhed til COWI, så de kan bruge det til at teste deres eksamenssystem.
Men det er da nice at man kan få et værktøj til at teste sine systemer. Til de små systemer er det perfekt, og til de store kan det sikkert bruges til en overfladisk test (kræver stadig special udviklet test).
krainert (1) skrev:Jeg skulle da også lige til at sige det... Hvad skal man med systemet, når det selvfølgelig alligevel er nødvendigt at tjekke alting igennem manuelt for at være sikker?
Hvis man ikke vil bruge metoder som fanger mindre end 100% af sikkerheds problemer, så vil man ikke kunne bruge nogen eksisterende metoder overhovedet.
Alt som finder noget er relevant. Og er det cost efficient, så er det godt. Og automatiserede tools er cost efficient.
krainert (1) skrev:Det skulle da være underligt, hvis alle programmørens væsentligste fejl lige præcis var dem, Skopfish fandt;
Det er en kendsgerning at der gang på gang findes mulighed for SQL injection i web apps.
Så uanset om det er "underligt", så vil værktøjet have en effekt.
krainert (1) skrev:hvis programmet finder en fejl, vedkommende ikke selv har været opmærksom på, er det vel bare en indikation af, at hele webapplikationen bør tjekkes godt og grundigt efter, og så er systemet vel ikke andet end en note på siden af skærmen?
Korrekt. Hvis et sådant program finder mange fejl, så er det en indikation af at sikkerheden i web app også bør undersøges på anden vis.
Men det er jo i sig selv også værdifuldt.
krainert (4) skrev:
Nu har jeg ikke voldsomt stor erfaring med udvikling af større webapplikationer, men jeg vil da antage, at det mildest talt er en fordel at skrive sin kode ordentligt i første omgang, så den ikke bliver hjemsted for alverdens bugs, når fejl senere rettes.
Hvis et værktøj finder fejl i koden, er disse formentligt hyppigt opstående, hvorfor de ikke burde være lavet oprindeligt.
Den dag programmers skrives af andre programmer, så vil vi muligvis få fejlfrie programmer.
Men lige så længe det er mennesker der skriver programmer, så vil der være fejl i dem.
Der er ingen som skrive store mængder fejlfri kode.
krainert (4) skrev:
Ja, det kan selvfølgelig ske, at man misser noget, men hvis det sker, antyder det for mig at se, at koden er mangelfuld og formentligt kan være kilde til diverse mere komplekse fejl - hvorfor skidtet alligevel skal gennemrodes.
Hvis den automatiserede test finder mange fejl i noget bestemt kode, så er det en god anledning til at undersøge den nærmere.
Men det er også særdeles værdifult at have en indikation af hvor det bedste kan betale sig at lede videre.
krainert (4) skrev:
Man kan selvfølgelig vælge den modsatte tilgang, at skrive en halvfærdig slamkode først og så få Skipfish til at finde de mest groteske fejl i den, men det giver næppe anledning til færre fejl, når måske relativt omfattende bugs rettes hen ad vejen.
Oveni det kommer så problemet med, at automatisering altid medfører dovenskab, og selvom det selvfølgelig udelukkende er programmørens problem, er det alligevel lidt trist, hvis en generel tendens til blindt at stole på Skipfish og lignende opstår... Det gør i hvert fald ikke produktet mere sikkert.
Det er heller ikke godt at slå sig selv oven i hovedet med en hammer.
Der ligger ikke konceptet at udviklerne skal blive ligeglade.
Automatiserede test tools er ikke en ny ide. Og de første 50 af slagsen har ike haft den effekt, så der er ikke grund til at troi at nummer 51 skulle have den effekt.
Og det hænger jo nok sammen med udviklere jo også vurderes af deres chefer. Ligeglad attituden kan hurtigt føre til at ens stilling spares væk.
#13 -
25. mar. 2010 16:41
arne_v (12) skrev:Medmindre krav spec tillader sårbarheder er enhver sårbarhed vel en bug (men enhver bug er ikke nædvendigvis en sårbarhed).
Når jeg skriver bug, mener jeg det som en fejl der ikke behøver direkte "angreb" for at blive udløst....
Sårbarheder behøver vel ikke indikere at siden indeholder slamkode ? men blot at udvikleren ikke var klar over sårbarheden, eller at sårbarheden ikke er blevet offentlig kendt endnu…
Scorp-D (13) skrev:
Når jeg skriver bug, mener jeg det som en fejl der ikke behøver direkte "angreb" for at blive udløst....
Jeg betragter altså også egenskaber i applikationen som tillader "angreb" for at være fejl.
Scorp-D (13) skrev:
Sårbarheder behøver vel ikke indikere at siden indeholder slamkode ? men blot at udvikleren ikke var klar over sårbarheden, eller at sårbarheden ikke er blevet offentlig kendt endnu…
Fejl må være fejl uanset om programmøren godt viste at det var et problem eller aldrig har hørt om problematikken.
En sårbarhed må være en fejl. I applikationen *eller* i platformen. Hvis fejlen ligger i script sproget eller web serveren er det naturligvis ikke applikations programmørens fejl. Men det er nogens fejl.
#15 -
29. mar. 2010 05:54
Syndes du for en gangs skyld skrive udenom kontekst, og faktisk kun laver ordkløveri....
Mine kommentarer er henholdt til:
Ingen kan tage hånd om alle kommende sårbarheder i udviklingen og test af hjemmesider....
Ergo behøver det nødvendigvis ikke at være fordi, man ikke skrev ordentlig kode i først omgang, at den nu indeholder sårbarheder...
Hvis man kunne dette, ville alle sårbarheder jo være fundet på nuværende tidspunkt....
Mine kommentarer er henholdt til:
Hvad skal man med systemet, når det selvfølgelig alligevel er nødvendigt at tjekke alting igennem manuelt for at være sikker?
skrive sin kode ordentligt i første omgang
Ingen kan tage hånd om alle kommende sårbarheder i udviklingen og test af hjemmesider....
Ergo behøver det nødvendigvis ikke at være fordi, man ikke skrev ordentlig kode i først omgang, at den nu indeholder sårbarheder...
Hvis man kunne dette, ville alle sårbarheder jo være fundet på nuværende tidspunkt....
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