Secure Code Review: A Practical Approach

dit artikel gaat over verschillende technieken voor code review en hun toepassing in de echte wereld

wat u leert:

Wat is secure code review en hoe hiermee om te gaan in real-life scenario ‘ s

Wat moet u weten:

basis beveiligingsconcepten

Secure Code Review:

Secure Code Review is een proces dat het onveilige stuk code identificeert dat een potentiële kwetsbaarheid kan veroorzaken in een later stadium van het softwareontwikkelingsproces, wat uiteindelijk leidt tot een onveilige toepassing. Wanneer een kwetsbaarheid wordt gedetecteerd in eerdere stadia van SDLC, heeft dit minder impact dan de latere stadia van SDLC – wanneer de onveilige code naar de productieomgeving verplaatst. In de SDLC (Software Development Life Cycle) proces , de secure code review proces valt onder de ontwikkelingsfase, wat betekent dat wanneer de applicatie wordt gecodeerd door de ontwikkelaars, ze kunnen doen self-code review of een security analist kan de code beoordeling uit te voeren, of beide. De ontwikkelaars kunnen geautomatiseerde tools die kunnen worden geà ntegreerd met hun IDE (Eclipse, MS VS, etc…) en kan codering en code beoordeling tegelijkertijd doen. Daarna, ze kunnen de hulp van een security expert te nemen om meer gebreken in de code te identificeren, als de security experts hebben een meer intrinsieke visie op de veiligheidsproblemen die kunnen worden gemist door de ontwikkelaars.

uit verschillende studies en enquêtes blijkt dat ongeveer 75% van de aanvallen te wijten is aan een onveilige toepassing, waarin onveilige code is opgenomen. Op deze manier wordt het een zeer essentieel onderdeel van SDLC dat strikt moet worden uitgevoerd. Ontwikkelaars hebben meestal de neiging om zich te concentreren op de functionaliteit van de applicatie en negeren de veilige codering aanpak. Maar tegenwoordig zijn ze zich meer bewust geworden van code review als gevolg van de toenemende incidenten van hacking en server aanvallen.

figuur– 1

technieken om code review te beveiligen:

over het algemeen kunnen we het secure code review proces verdelen in twee verschillende technieken:

  1. geautomatiseerde tool based / Black Box: in deze aanpak, de secure code review wordt gedaan met behulp van verschillende open source/commerciële tools. Meestal ontwikkelaars gebruiken ze terwijl ze coderen, maar een security analist kan ook hulp van hen. Tools zijn erg handig bij het uitvoeren van code review wanneer we het secure SDLC proces in de organisatie implementeren en de tool aan ontwikkelaars zelf bieden om een “self-code” review te doen terwijl ze coderen. Ook, de tools zijn nuttig bij het analyseren van grote codebase (miljoenen lijnen). Ze kunnen snel potentiële onveilige stukjes code in de codebase identificeren, die door de ontwikkelaar of een beveiligingsanalist kunnen worden geanalyseerd.
  2. handmatig / wit vak: in deze techniek wordt een grondige code beoordeling uitgevoerd over de hele code, die een zeer vervelend en vermoeiend proces kan worden. Maar in dit proces, logische gebreken kunnen worden geïdentificeerd die niet mogelijk zijn met behulp van geautomatiseerde tools, zoals business logic problemen. Geautomatiseerde tools zijn meestal in staat om het vinden van technische gebreken zoals injectie aanvallen, maar kunnen missen gebreken zoals autorisatie problemen. In dit proces, in plaats van regel voor regel door hele code base, kunnen we ons concentreren op potentiële problemen in de code. Deze potentiële kwetsbaarheden kunnen een hoge prioriteit krijgen. Bijvoorbeeld, in C / C++, als we proberen een kopieerfunctie in de code te vinden en controleren of het functies gebruikt zoals strcpy() voor het uitvoeren van kopieerfunctie. Zoals we weten, strcpy () is bekend dat kwetsbaar voor buffer Overflow aanvallen. We kunnen ook willen controleren of een aangepaste encryptie wordt gebruikt in de applicatie, die geautomatiseerde tools kunnen missen als ze alleen standaard algoritmen kunnen identificeren.

    de beste aanpak is dus een combinatie van beide, afhankelijk van het volume en de kriticiteit van de gegevens. In de wereld van vandaag, waar veel complexe toepassingen worden ontwikkeld, kunnen we geen van de bovengenoemde technieken negeren.

voordelen van Secure code review:

er zijn een aantal factoren waarmee rekening moet worden gehouden bij het ontwikkelen van een robuust toegangscontrolemechanisme in de webapplicatie:

  1. inspanning voordeel: de inspanning om de kwetsbaarheden in de vroege fase van het SDLC proces op te lossen is veel minder dan de latere fase van het proces. Zodra de code is voltooid en de fout is niet geïdentificeerd, het is een zeer vervelend en tijdrovend proces om problemen te vinden zodra de applicatie klaar is om in productie te gaan. Ook kan last minute vaststelling van invloed zijn op de volledige functionaliteit van het programma en belemmeren deadlines ingesteld voor de release van het product. Wie weet, het kan een ander veiligheidslek, die gemakkelijk mogelijk is met een grote en complexe code te creëren.
  2. kostenvoordeel: de kosten zijn recht evenredig met de vereiste inspanning. Niet alleen ontwikkelingskosten, maar ook een kwetsbaarheid in de productieomgeving kan meer kosten met zich meebrengen. Nogmaals, het is de moeite waard, omdat de kosten verbonden aan een aanval veel steiler kunnen zijn.
  3. Compliance: sommige compliance, zoals PCI, maakt het noodzakelijk om een veilige code review te doen voordat het product wordt gelanceerd. Een organisatie die volledige SDLC volgt, heeft dus meer kans om gecertificeerd te worden.
  4. reputatie: Secure code review verwijdert de meeste van de beveiligingsfouten in de eerdere fase, waardoor het veiliger is dan alleen het doen van black box assessments. Er is dus minder kans dat het product een compromis wordt, dus minder kans op reputatieschade.

aanpak:

deze zijn gebaseerd op een mix van standaard proces en mijn eigen aanpak. Het kan van persoon tot persoon verschillen.

standaardproces :

Figuur-2

definieer scope: eerst moet je begrijpen en met een ruwe schatting komen over de reikwijdte van de code review en de inspanningen die daarbij betrokken zijn. Ook kunnen budgettaire beperkingen worden vastgesteld. Wat voor soort code review kan worden uitgevoerd? Zwarte doos of witte doos? Probeer de zakelijke logica van de toepassing te begrijpen. Vergeet niet naar welke kwetsbaarheden je moet zoeken, zoals OWASP Top 10, SANS, etc… men kan proberen om ze zo veel mogelijk te bekijken, zo niet allemaal. Dan kunt u afleiden hoeveel van hen kunnen worden gedetecteerd met behulp van tools en die het meest geschikt zijn voor handmatige beoordeling.

categoriseer de kwetsbaarheden: Wat is uw prioriteit, wat betekent welk type kwetsbaarheden u als prioriteit zult nemen? Bijvoorbeeld, in zakelijke toepassingen, kunt u zich voornamelijk concentreren op de zakelijke logica van de toepassing en duik diep in het, als de technische degenen gemakkelijk worden gedetecteerd door tools. Geef ze prioriteit.

dit zijn een paar categorieën die u kunt bekijken:

  • Toestemming
  • Verificatie
  • Injectie gebreken
  • Onjuiste afhandeling van fouten/Uitzondering gebreken
  • Encryptie (Cryptografie)
  • Auditing en Logging
  • Sessie gerelateerde fouten (Session management)
  • Onzeker configuratie

Aanbeveling: Als een security analyst, het is onze plicht filter valse positieven gegenereerd door tools en valideren van hen in om te bevestigen dat hij de werkelijke fouten. Na het doen van een goede code review, je moet documenteren de kwetsbaarheden gevonden in een uitgebreid rapport coating van de categorie van de kwetsbaarheid en hun beperking. U kunt een stap vooruit en stel een voorbeeld veilige code. Persoonlijk neem ik de codefragmenten ook op in het rapport, bij voorkeur in een excel-bestand en voeg het dan toe.

zo doe ik het persoonlijk. De punten hieronder zijn gebaseerd op mijn ervaring tot op heden in het doen van code review. Ik heb nog veel te leren en de punten hieronder kunnen wel of niet waar zijn in elke conditie:

voer altijd handmatige reviews uit: geautomatiseerde code review is een proces waarbij u scanprogramma ‘ s uitvoert zoals Rational, Ounce Labs, en Parasofton de codebasis, gevolgd door een handmatige audit van de resultaten. De scanner markeert de hele code met kwetsbaarheden op basis van de perceptie. Nu is het de taak van de auditor om onderscheid te maken tussen echte problemen en valse positieven. Hier begint de echte pijn. Je hebt geen controle over elke taal. Dus het nemen van hulp van Taal specifieke middelen is vereist. Nu ben ik vertrouwd geraakt met bijna alle belangrijke talen (.NET, Java, PHP) specifieke kwetsbaarheden. Bij een black box assessment kom je nooit te weten waar het echte probleem ligt.

praat eerst met ontwikkelaars: hoe meer u ontwikkelaars betrekt bij uw codeherzieningsproces, hoe effectiever de analyse zal zijn. Je krijgt het vertrouwen dat wat je ook doet is gebaseerd op het juiste begrip van de code. Aan de andere kant, ontwikkelaars ook blij dat je ze te nemen in vertrouwen in plaats van iets kwetsbaar meteen verklaren.

beschikken over een handig notitieboekje en een pen om de stroom van het programma te begrijpen. Inzicht in de bron van de taint en waar doet het weerspiegelt in de code is noodzakelijk om de echte kwetsbaarheden te vangen. Alleen maar zien dat de taint is het invoeren van het programma en reflecteren in een ander deel van het programma betekent niet altijd dat het kwetsbaar is voor Cross Site Scripting, bijvoorbeeld. Ook Hier helpt praten met ontwikkelaars, omdat ze misschien een gecentraliseerd invoerfilter / validatiemechanisme implementeren. Dus trek geen overhaaste conclusies.

gebruik een geavanceerde teksteditor: de teksteditor moet in staat zijn om een term in de hele codebasis te zoeken. Een dergelijke teksteditor is Notepad++. Het zoekt de term en benadrukt ze, zodat u kunt zien waar alle plaatsen de specifieke term wordt gebruikt. Het helpt je bij het aansluiten van de stukken en het zien van het volledige beeld.

heb voldoende tijd om code te controleren, omdat u uw gedachten meer dan eens moet toepassen om echte kwetsbaarheden op te pikken. Vraag uw klanten dus altijd voldoende tijd om het project volledig af te ronden.

verbonden zijn met Internet helpt altijd bij het controleren van de code. Bepaalde termen, functies of methoden irriteren je altijd omdat je ze misschien nog niet eerder hebt gezien. Google helpt veel bij het begrijpen van hen.

vind kwetsbaarheden in de context van de applicatie: niet alleen moet u echte en toepasselijke kwetsbaarheden in de context van de applicatie oppikken – omdat het het aantal problemen vermindert – maar ook moet u de tegenmaatregelen in het rapport voorstellen. Dat maakt ontwikkelaars blij en zelfverzekerd. De scanner kan elk probleem markeren als Hoog, Gemiddeld of laag. Het is uw verantwoordelijkheid om ze de juiste ranking te geven op basis van applicatiecontext.

iedereen houdt van zijn eigen programma: Programma ‘ s zijn als een ontwikkelaarsbaby. Niet altijd lokaliseren van de zwakke punten van het programma, ook waarderen ze als u een robuust mechanisme gebruikt in het programma. Op die manier, u kunt ze vriendelijk en ze zullen altijd komen om te gebruiken om hun code beoordeeld. Dus beiden zijn dan gelukkig.

Train ze: last but not least, train ontwikkelaars over de kwetsbaarheden in de echte wereld. Geef ze training, betrek ze erbij en moedig ze aan om hun codes te herzien voordat ze worden geproduceerd. Vertel hen hoe het bespaart moeite en geld. Als u een scanning tool die plug-ins voor IDE ondersteunt, installeer het op hun machines, zodat ze de juiste ontwikkeling en een hand met de hand beoordeling kunnen doen.

een voorbeeld:

beschouw dit voorbeeld (Owasp WebGoat Project):

String gebruikersnaam = “”;

String wachtwoord = “”;

gebruikersnaam = s. getParser ().getRawParameter (gebruikersnaam);

password = s.getParser ().getRawParameter (wachtwoord);

……………..

………..……

String query = ” SELECT * FROM user_system_data WHERE user_name = ‘”

+ gebruikersnaam + “‘and password = ‘” + Wachtwoord + “‘”;

ec.addElement (nieuwe StringElement (query)));

de ingangen van de gebruiker worden gevraagd via getRawParameter, en toegewezen aan de’ gebruikersnaam ‘en’ wachtwoord ‘ variabelen. Nogmaals, ze worden direct gebruikt in de SQL query zonder enige input validatie en ook worden ingebed in de dynamische query. Elke kwaadaardige gebruiker kan knoeien met deze query om zijn eigen willekeurige SQL-codes uit te voeren. Dus als we proberen om alle toegangspunten in de codebase te vinden (getRawParameter in dit geval), kunnen we injectiefouten detecteren. Zelfs als we zoeken naar SQL-query ‘s die in de code worden gebruikt, als we vinden dat ze worden gebruikt als dynamische query’ s, kunnen ze een geval zijn van een mogelijke SQL-injectie.

op het Net: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.