|
Secure Coding |
 |
06/09-03 | IcePic | icepic@64bits.se
Kapitel 3 - "Design" tar upp den inte helt oviktiga fasen av all utveckling och programmering. Här finns det massor av pekpinnar, och precis som i det föregående kapitlet så stämmer givetvis allihopa. De går in på saker som att man inte ska överdimensionera heller. Det är ju ingen idé att ha 1024-bitars krypto för att skydda fantomenklubbens hemliga valspråk i år, eftersom hotet och risken är så låg. Man tar även upp koncept som "sandboxar", wrappers, jails, m.m. Man visar även en liten snutt C-kod från Sendmail's "säkra" shell för att peka på en enskild specifik bugg som introducerats när man lagat andra buggar. Det är i princip den enda kod som överhuvudtaget presenteras, och man måste inte alls begripa hela snutten för att kunna följa resonemanget. De går även igenom alternativ till sendmail som i sin design är byggda på ett helt annat vis just för säkerhetens skull, och de presenterar på ett klockrent sätt en fin och komplett sågning av den första WEP-implementationen.
Secure Coding, kap. 3-6För de som inte följt WLan-historien så står WEP för Wireless Equivalent Privacy, dvs det ska vara lika säkert som om man kört på koppartråd. Tyvärr hade de lite problem i själva designen som gjorde att det inte alls blev lika säkert som tråd. Och inte bara ett problem, de hade fyra. (Bortsett från "problemet" med att krypteringen inte ens är påslaget som default!)
Numera finns det WEP2, WPA och andra efterföljare som rättar till en del av problemen men inte alla. Det är alltså inte ett problem i koden, det är inte felskrivningar eller slarviga programmerare, det är själva designen som gör en säker implementation omöjlig. Ska man göra ett WLan-kort enligt den specen så kan man inte göra den säker just på grund av de fyra missarna. Illa.
Men det är en väldigt bra pekpinne för att visa på att designen betyder så mycket mer än vad man först kan tro. Igen får SYN-floodarna i TCP/IP-stackarna en känga, denna gång för dålig design.
Kapitel 4 - "Implementation" tar upp de specifika detaljerna om hur programmen ska kodas, vad som är viktigt i den delen av utvecklingen och vanliga fel. Den börjar med ett stycke om SYN-floodarna (igen), fast denna gång om felen i själva koden. Den förklarar lite om buffer overflows, tar upp detaljer att ta hänsyn till som att man alltid måste se upp med data som kommer från användaren och listar ett antal misstag som folk gjort.
Exempel på det sistnämnda innefattar bl.a. att referera till en fil flera gånger i samma program via dess filnamn så att den skulle kunnat byts ut under programmets gång, att inte förutsätta att din användare är godhjärtad och att inte förutsätta att allt jämt lyckas. Den har ett antal exempel på program och implementationer som varnande exempel på olika sätt som folk lyckats lura programmen att bugga ur på de mest oväntade sätt.
Kapitel 5 - "Operations" tar upp mycket om driften runt program och datorer, och här kommer mesta delen av nätverksproblemen in. Det finns en hel del "politiska" tips här också, med exempel på hur stora nät slagits av virus som hittat in till labbmaskiner som inte alls var under IT-gruppens kontroll. De patchades inte för de "var ju bara labbmaskiner". Väl på insidan kunde virusen sprida död och elände för fullt. Sådana saker bör inte kunna hända om man har en organisation som ser till att patchning av samtliga datorer och program är en grupps ansvar och inte delat mellan ett flertal olika grupper och personer. Speciellt inte om de inte ens talar med varandra. Det är i viss mån ett kapitel med listor på saker man ska och inte ska göra i olika situationer, fast med fokus på drift och inte på kodning så mycket. Dock ska man inte glömma att ett bra program är ju tänkt att gå i drift och fungera länge och väl, så den sidan ska man inte åsidose heller.
Kapitel 6 - "Automation and Testing" avslutar det hela med att gå igenom vad man kan göra mot/med sitt program för att hjälpa till att finna problem i koden, säkerhetsmässigt sett då. Det är inte så mycket om debuggning i sig, men mer om vilka verktyg och metoder man kan använda för att se om ens program möter de krav man ställt på det. Mycket av boken har varit ganska Unix-orienterad, och detta kapitel är ännu lite mer så. Varje gång det listas program för att testa en typ av fel, mäta ens nätverk eller nåt så är det ett par alternativa program men aldrig mer än en för Windows i varje lista. Jag har inget emot det själv, men det bör påpekas för potentiella köpare att när det väl kommer till kritan så är det 75% Unix och 25% Windows.
| « Föregående | Nästa sida » |
Utskriftsvänligare version
Diskutera denna recensionen i vårt forum!