denne artikkelen handler om ulike kode gjennomgang teknikker og deres anvendelse i den virkelige verden
Hva du vil lære:
hva er sikker kode gjennomgang og hvordan man skal håndtere dem i virkelige scenarier
Hva du bør vite:
Grunnleggende sikkerhetskonsepter
Gjennomgang Av Sikker Kode:
Gjennomgang Av Sikker Kode er en prosess som identifiserer den usikre koden som kan forårsake et potensielt sikkerhetsproblem i et senere stadium av programvareutviklingsprosessen, som til slutt fører til en usikker applikasjon. Når et sikkerhetsproblem oppdages i tidligere STADIER AV SDLC, har det mindre innvirkning enn DE senere stadiene AV SDLC – når den usikre koden flyttes til produksjonsmiljøet. I SDLC-Prosessen (Software Development Life Cycle) kommer prosessen med sikker kodegjennomgang under Utviklingsfasen, noe som betyr at når applikasjonen blir kodet av utviklerne, kan de gjøre selvkodegjennomgang eller en sikkerhetsanalytiker kan utføre kodegjennomgangen, eller begge deler. Utviklerne kan bruke automatiserte verktøy som kan integreres med DERES IDE (Eclipse, MS VS, etc…) og kan gjøre koding og kodevurdering samtidig. Etter det kan de ta hjelp av en sikkerhetsekspert for å identifisere flere feil i koden, da sikkerhetsekspertene har en mer inneboende visning av sikkerhetsproblemer som kan bli savnet av utviklerne.
Ulike studier og undersøkelser viser at omtrent 75% av angrepene skjer på grunn av en usikker applikasjon, som inkluderer usikker kode. På denne måten blir DET en svært viktig del AV SDLC som bør utføres nøye. Utviklere har en tendens til å fokusere på funksjonaliteten til programmet og ignorere sikker koding tilnærming. Men i dag har de blitt mer bevisste på kodevurdering på grunn av de økende hendelsene med hacking og serverangrep.
Figur– 1
Teknikker for å sikre kode gjennomgang:
Generelt kan vi dele prosessen med sikker kodegjennomgang i to forskjellige teknikker:
-
Automatisert verktøybasert / Svart Boks: i denne tilnærmingen gjøres sikker kodegjennomgang ved hjelp av forskjellige åpen kildekode / kommersielle verktøy. For det meste bruker utviklere dem mens de koder, men en sikkerhetsanalytiker kan også ta hjelp av dem. Verktøy er veldig nyttige når vi implementerer den sikre SDLC-prosessen i organisasjonen og gir verktøyet til utviklere selv for å gjøre en “selvkode”-gjennomgang mens de koder. Verktøyene er også nyttige for å analysere stor kodebase (millioner av linjer). De kan raskt identifisere potensielle usikre kodestykker i kodebasen, som kan analyseres av utvikleren eller en sikkerhetsanalytiker.
-
Manuell / Hvit Boks: i denne teknikken utføres en grundig kodegjennomgang over hele koden, noe som kan bli en veldig kjedelig og kjedelig prosess. Men i denne prosessen kan logiske feil identifiseres som kanskje ikke er mulige ved hjelp av automatiserte verktøy, for eksempel forretningslogikkproblemer. Automatiserte verktøy er for det meste i stand til å finne tekniske feil som injeksjonsangrep, men kan savne feil som autorisasjonsproblemer. I denne prosessen, i stedet for å gå linje for linje gjennom hele kodebasen, kan vi konsentrere oss om potensielle problemer i koden. De potensielle sårbarhetene kan prioriteres høyt. For Eksempel, I C / C++, hvis vi prøver å finne noen kopieringsfunksjon i koden og sjekke om den bruker funksjoner som strcpy() for å utføre kopieringsfunksjon. Som vi vet, er strcpy () kjent for å være sårbar for bufferoverløpangrep. Vi kan også være lurt å sjekke om noen tilpasset kryptering blir brukt i programmet, som automatiserte verktøy kan gå glipp av som de kan identifisere standard algoritmer bare.
så den beste tilnærmingen vil være en blanding av begge, avhengig av volum og kritikk av data. I dagens verden hvor mange komplekse applikasjoner utvikles, kan vi ikke ignorere noen av de ovennevnte teknikkene.
Fordeler Med Sikker kode gjennomgang:
det er noen faktorer som bør tas i betraktning mens du utvikler en robust tilgangskontrollmekanisme i webapplikasjonen:
-
Innsatsfordel: innsatsen for å fikse sårbarhetene i DET tidligere stadiet AV SDLC-prosessen er mye mindre enn det senere stadiet av prosessen. Når koden er fullført og feilen ikke er identifisert, er det en veldig kjedelig og tidkrevende prosess å finne problemer når søknaden er klar til å gå inn i produksjonen. Dessuten kan siste minutt fikse påvirke hele funksjonaliteten til programmet og hemme tidsfrister satt for produktutgivelse. Hvem vet, det kan skape en annen sikkerhetsfeil, som lett kan være mulig med en stor og kompleks kode.
-
kostnadsfordel: Kostnaden er direkte proporsjonal med innsatsen som kreves. Ikke bare utviklingskostnader, men også en sårbarhet identifisert i produksjonsmiljøet kan innebære flere kostnader. Igjen er det vel verdt det, da kostnadene forbundet med et angrep kan være mye brattere.
-
Compliance: noen compliance, FOR EKSEMPEL PCI, gjør det nødvendig å gjøre en sikker kodegjennomgang før du starter produktet. Så en organisasjon som følger komplett SDLC har bedre sjanse til å bli sertifisert.
-
Omdømme: Sikker kodegjennomgang fjerner de fleste sikkerhetsfeilene i den tidligere fasen, noe som gjør det sikrere enn bare å gjøre black box-vurderinger. Så det er mindre sjanse for at produktet blir kompromiss, dermed mindre sjanse for omdømmeskader.
Tilnærming:
Disse er basert på blanding av standard prosess og min egen tilnærming. Det kan variere fra person til person.
Standard prosess :
Figur-2
Definer omfang: Først må du forstå og komme opp med et grovt estimat om omfanget av kodevurderingen og innsatsen som er involvert i den. Også budsjettbegrensninger kan defineres. Hva slags kode gjennomgang kan utføres? Svart boks eller hvit boks? Prøv å forstå forretningslogikken til søknaden. Husk hvilke sårbarheter du må se etter, FOR EKSEMPEL OWASP Top 10, SANS, etc … Man kan prøve å gjennomgå dem så mye som mulig, om ikke alle av dem. Deretter kan du utlede hvor mange av dem som kan oppdages ved hjelp av verktøy og som passer best for manuell gjennomgang.
Kategoriser sårbarhetene: hva er din prioritet, noe som betyr hvilken type sårbarheter du vil ta som en prioritet? For eksempel, i forretningsapplikasjoner, kan du konsentrere deg mest om forretningslogikken til applikasjonen og dykke dypt inn i den, da de tekniske lett oppdages av verktøy. Prioritere dem.
følgende er noen kategorier du kan se på:
-
Autorisasjon
-
Autentisering
-
Injeksjonsfeil
-
Feil feilhåndtering / Unntaksfeil
-
Kryptering (Kryptografi)
-
Revisjon og Logging
-
Øktrelaterte feil (Øktstyring)
-
Usikker konfigurasjon
Anbefaling: som sikkerhetsanalytiker er det vår plikt å filtrere falske positiver generert av verktøy og validere dem for å bekrefte at de er faktiske feil. Etter å ha gjort en skikkelig kodegjennomgang, bør du dokumentere sårbarhetene som finnes i en omfattende rapport som dekker kategorien av sikkerhetsproblemet og deres begrensning. Du kan gå et skritt foran og foreslå en prøve sikker kode. Jeg inkluderer også kodebitene i rapporten, helst i en excel-fil, og legg den deretter ved.
dette er hvordan jeg personlig går om det. Punktene nedenfor er basert på min erfaring til dato i å gjøre code review. Jeg har fortsatt mye å lære og punktene nedenfor kan eller ikke kan holde sant i hver tilstand:
utfør alltid manuelle vurderinger: Automatisert kodegjennomgang er en prosess der du kjører skanneverktøyene Som Rational, Ounce Labs og Parasofton kodebasen etterfulgt av en manuell revisjon av resultatene. Skanneren flagger hele koden med sårbarheter basert på oppfatningen. Nå er det auditørens jobb å skille mellom virkelige problemer og falske positiver. Det er her den virkelige smerten begynner. Du har ikke kommandoen over hvert språk. Så det er nødvendig å ta hjelp av språkspesifikke ressurser. Nå har jeg blitt kjent med nesten alle store språk (.NET, Java, PHP) spesifikke sårbarheter. Gjør en svart boks vurdering du aldri kommer til å vite hvor det virkelige problemet ligger.
Snakk med utviklere først: jo mer du involverer utviklere i kodevurderingsprosessen, desto mer effektiv blir analysen. Du får tillit til at uansett hva du gjør er basert på riktig forståelse av koden. På den annen side blir utviklere også glade for at du tar theminto tillit i stedet for å erklære noe sårbart straks.
Har en bærbar pc og penn hendig å forstå flyten av programmet. Å forstå kilden til taint og hvor reflekterer den i koden er nødvendig for å fange de virkelige sårbarhetene. Bare å se at taint går inn i programmet og reflekterer i en annen del av programmet, betyr ikke alltid at det er sårbart For Cross Site Scripting, for eksempel. Igjen her hjelper det å snakke med utviklere, da de kan implementere noen sentralisert inngangsfiltrering / valideringsmekanisme. Så ikke bare hoppe til noen konklusjoner.
Bruk en avansert tekstredigerer: tekstredigereren skal kunne søke etter et begrep i hele kodebasen. En slik tekstredigerer er Notepad++. Den søker begrepet og fremhever dem slik at du kan se hvor alle steder bestemt begrepet blir brukt. Det hjelper deg i å bli med bitene og se hele bildet.
Ha nok tid til å gjøre kodevurdering, da du må bruke tankene dine mer enn en gang for å hente virkelige sårbarheter. Så spør alltid kundene dine for tilstrekkelig tid til å fullføre prosjektet fullt ut.
å være koblet Til Internett hjelper alltid på tidspunktet for kodegjennomgang. Visse vilkår, funksjoner eller metoder alltid irritere deg som du kanskje ikke har sett dem før. Google hjelper mye med å forstå dem.
Finn sårbarheter i sammenheng med programmet: Ikke bare bør du plukke opp reelle og aktuelle sårbarheter i sammenheng med programmet – som det reduserer antall problemer – men også, bør du foreslå mottiltak i rapporten. Det gjør utviklerne glade og selvsikre. Skanneren kan flagge alle problemer Som Høy, Middels eller Lav. Det er ditt ansvar å gi dem riktig rangering basert på applikasjonskontekst.
alle elsker sitt eget program: Programmer er som en utviklere baby. Ikke alltid finne svakheter i programmet, også setter pris på dem hvis du finner noen robust mekanisme som brukes i programmet. På den måten kan du gjøre dem vennlige, og de vil alltid komme til å bruke for å få koden sin gjennomgått. Så begge er da glade.
Tren dem: Sist men Ikke minst, trene utviklere om sårbarhetene i den virkelige verden. Gi dem opplæring, involvere dem og oppmuntre dem til å gjennomgå sine koder før produksjon. Fortell dem hvordan det sparer innsats og penger. Hvis du har et skanneverktøy som støtter plugin-moduler FOR IDE, installer det på sine maskiner slik at de kan gjøre riktig utvikling og en hånd for hånd gjennomgang.
En Eksempelillustrasjon:
Tenk på dette eksemplet (Owasp WebGoat Project):
streng brukernavn = “”;
String passord = “”;
brukernavn = s.getParser ().getRawParameter (BRUKERNAVN);
passord = s.getParser().getRawParameter (PASSORD);
……………..
………..……
String query = ” VELG * fra user_system_data HVOR user_name = ‘”
+ brukernavn + “‘og passord = ‘” + passord + “‘”;
ec.addElement (nytt StringElement(spørring));
inngangene fra brukeren blir bedt om gjennom getRawParameter, og tilordnet variablene’ brukernavn ‘og’ passord’. Igjen blir de brukt direkte i SQL-spørringen uten noen inndatavalidering og blir også innebygd i den dynamiske spørringen. Enhver ondsinnet bruker kan tukle med denne spørringen for å kjøre sine egne vilkårlige SQL-koder. Så hvis vi prøver å finne alle inngangspunkter i kodebasen (getRawParameter i dette tilfellet), kan vi oppdage injeksjonsfeil. Selv om VI søker ETTER SQL-spørringer som brukes i koden, hvis vi finner ut at de blir brukt som dynamiske spørringer, kan de være et tilfelle av en mulig SQL-injeksjon.
På Nettet: 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