Kod revision

En mjukvarukodgranskning är en omfattande analys av källkoden i ett programmeringsprojekt med avsikten att upptäcka buggar, säkerhetsintrång eller kränkningar av programmeringskonventioner. Det är en integrerad del av det defensiva programmeringsparadigmet , som försöker minska fel innan programvaran släpps. C- och C++-källkoden är den vanligaste koden som ska granskas eftersom många språk på högre nivå, som Python, har färre potentiellt sårbara funktioner (t.ex. funktioner som inte kontrollerar gränser) [ ^{citat behövs ]} .

Riktlinjer

Vid granskning av programvara bör varje kritisk komponent granskas separat och tillsammans med hela programmet. Det är en bra idé att först söka efter sårbarheter med hög risk och arbeta ner till sårbarheter med låg risk. Sårbarheter mellan högrisk och lågrisk finns i allmänhet beroende på situationen och hur källkoden i fråga används. Applikationspenetrationstestning försöker identifiera sårbarheter i programvara genom att lansera så många kända attacktekniker som möjligt på troliga åtkomstpunkter i ett försök att få ner applikationen. Detta är en vanlig granskningsmetod och kan användas för att ta reda på om några specifika sårbarheter finns, men inte var de finns i källkoden. Vissa hävdar att revisionsmetoder i slutet av cykeln tenderar att överväldiga utvecklare, vilket i slutändan lämnar teamet med en lång lista med kända problem, men få faktiska förbättringar; i dessa fall rekommenderas en in-line-revisionsmetod som ett alternativ.

Högrisksårbarheter

Vissa vanliga högrisksårbarheter kan finnas på grund av användningen av:

Icke-gränskontrollfunktioner (t.ex. strcpy , sprintf , vsprintf och sscanf ) som kan leda till en sårbarhet för buffertspill
Pekarmanipulation av buffertar som kan störa senare gränskontroll, t.ex.: if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;
Anrop som execve (), execution pipes, system() och liknande saker, speciellt när de anropas med icke-statiska argument
Indatavalidering, t.ex. (i SQL): sats := "SELECT * FROM users WHERE name = '" + användarnamn + "';" är ett exempel på en SQL- injektionssårbarhet
Filinkluderingsfunktioner, t.ex. (i PHP): include($page . '.php'); är ett exempel på en sårbarhet för Remote File Inclusion
För bibliotek som kan vara länkade med skadlig kod, returnerar referensen till den interna föränderliga datastrukturen (post, array). Skadlig kod kan försöka modifiera strukturen eller behålla referensen för att observera framtida ändringar.

Låg risk sårbarheter

Följande är en lista över lågrisksårbarheter som bör hittas vid granskning av kod, men som inte ger en högrisksituation.

Kodsårbarheter på klientsidan som inte påverkar serversidan (t.ex. cross-site scripting )
Användarnamnsuppräkning
Katalogpassering
Känsliga API-nycklar

Verktyg

Källkodsgranskningsverktyg letar i allmänhet efter vanliga sårbarheter och fungerar endast för specifika programmeringsspråk . Sådana automatiserade verktyg skulle kunna användas för att spara tid, men bör inte förlitas på för en djupgående granskning. Att använda sådana verktyg som en del av ett policybaserat tillvägagångssätt rekommenderas.

Beroende av krav

Om den är inställd på den låga tröskeln upptäcker de flesta mjukvarugranskningsverktygen många sårbarheter, särskilt om koden inte har granskats tidigare. Men den faktiska betydelsen av dessa varningar beror också på hur applikationen används. Biblioteket som kan vara kopplat till den skadliga koden (och måste vara immunt mot den) har mycket stränga krav som att klona alla returnerade datastrukturer, eftersom de avsiktliga försöken att bryta systemet förväntas. Programmet som bara kan utsättas för den skadliga ingången (som webbserverns backend) måste först bry sig om denna ingång (buffertöverskridanden, SQL-injektion, etc.). Sådana attacker får aldrig förekomma för programmet som endast används internt av auktoriserade användare i en skyddad infrastruktur.

Se även