Innehåll

Secure Coding

Secure Coding, intro, kap 1-2
Secure Coding, kap 3-6
Secure coding, slutsats


06/09-03 | IcePic | icepic@64bits.se

Utskriftsvänligare versionUtskriftsvänligare version


Secure Coding, Intro, kap. 1-2

Bland alla programmeringsböcker om "Game Physics in Quake2", "Lär dig shellscript.NET på 21 timmar" och "Linux Kernel coding for Dummies(TM)" finns det ibland böcker som pratar om ett koncept istället för att gå in på specifika detaljer eller problem inom programmering. En av dem som jag gillat väldigt mycket sedan tidigare är "Programming Pearls" som tar upp en massa gamla problem och visar i olika språk hur man bör tänka för att få rätt design på lösningen.

När jag såg "Secure Coding" hoppades jag att även denna skulle vara likadan, en bok med idéer, tankar, lösningar och principer man bör ha i bakhuvudet för att kunna skriva säker och fungerande kod. Boken är skriven av Mark G. Graff och Kenneth R. van Wyk, två inte helt okända personer inom säkerhetsbranschen och utgiven av O'Reilly som inte är bara är kända för att ge ut böcker av god klass utan även för att de flesta böcker har ett specifikt djur på framsidan. Dock har denna bok inte fått nåt djur utan istället byggandet av en gammaldags stenbro. Som en sidonot kan ju nämnas att det påstås att romerska brobyggaringejörer fick stå under sina nybyggda broar medans man testade att fara över den med vagnar och soldater. Lite mer sånt inom programmeringsområdet skulle inte alltid vara helt fel. De har även en website som ackompanjerar boken med uppdateringar och nyheter inom området för den som vill hålla sig up-to-date eller bara ta en titt på exempelkapitlet.

Boken är på 200 sidor och indelad i 6 st större kapitel med olika inriktning:

  • 1. "No Straight Thing"
  • 2. "Architecture"
  • 3. "Design"
  • 4. "Implementation"
  • 5. "Operations"
  • 6. "Automation and Testing"

Kapitel 1 - "No Straight Thing" går igenom och funderar över varför inget någonsin funkar. Varför dyker alla dessa problem upp? Vilka typer av problem finns det och varför sker olika typer av attacker? Varför skriver bra programmerare dålig kod? De tar upp ett par exempel på olika typer av problem för att senare kunna återkomma till dem i respektive kapitel beroende på om problemet låg i designen eller i implementationen osv.
(T.ex SYN-floodarna från 95-96 som återkommer om och om igen i boken. En kortare förklaring och kommentar från mig finns i slutet av denna recension för de som inte var med då det begav sig)
De går också igenom i inledningen vad boken inte täcker, och det är bland annat ymniga kodexempel och "hur skriver jag bättre nätverksdemoner" och liknande. Det är en mer övergripande bok om kod i allmänhet och i viss mån om nätverk eftersom så mycket problem, attacker och virus kommer den vägen.

Kapitel 2 - "Architecture" tar upp hur man ska se över säkerhetens arkitektur, dvs före man sätter igång med designen och definitivt före man implementerar sin lösning. Här dyker en av bokens svagheter upp. De lyckas inte riktigt hålla ner saker till en hanterbar mängd. Alla skribenter måste ju se upp med sitt skrivande så att läsaren får en textmiljö som fäster i sinnet. De har skapat en komihåg-lista för den som ska vara säkerhetsarkitekt, och gudarna ska veta att det hade behövts under de senaste åren med allt strul som varit på nätet. Men de tar med allt som man kan tänkas behöva vilket leder till att listan är på hela 30 punkter!

Därefter tar de punkt för punkt och förklarar dem på ett bra sätt, men man kan omöjligen minnas 30 punkter, så det borde förmodligen krympts ner till ett mycket mindre antal genom att gruppera ihop saker under en gemensam punkt eller nåt. Dock är inga av punkterna dåliga eller överflödiga, det är fullt av sanningar alltihopa, men 30 punkter är lite väl magstarkt.

Kapitlet slutar med att de tar en titt på lite olika problem och ett par olika program för att få en bättre bild av vad man tänkt och vilka problem de löser. Även här tar de upp SYN-floodarna igen som en del av hur TCP/IP utvecklades för att fungera i en helt annan miljö än den vi har nu.


  Nästa sida »


06/09-03 | IcePic | icepic@64bits.se

Utskriftsvänligare versionUtskriftsvänligare version

Diskutera denna recensionen i vårt forum!