Retningslinjer for sikker koding og beste fremgangsmåter for utviklere

secure coding guidelines

Denne opplæringen forklarer Sikker koding, hvordan du kan unngå sikkerhetsrelaterte sikkerhetsproblemer, og gir retningslinjer for koding og sjekkliste for sikker kodingspraksis:

For å ha sikkerhet innebygd i programvaren og implementere Secure Coding Guidelines and Best Practices, må hele organisasjonen sammen med teamet som er identifisert for å jobbe med den tiltenkte Application Development, vurdere visse aspekter.

Her vil vi diskutere de aspektene som hjelper til med å utvikle en sikret programvare.

overføring matrise til metode i java

Det er så enkelt som at hvis en utvikler ikke vet hva som menes med ‘Sikkerhet for programvaren’ og hvordan en hacker kan hacke programvaren sin, ta kontroll over den og prøve å utnytte, så er det rett og slett umulig å kode en sikker programvare. Så utvikleren må først forstå betydningen av Secure Coding.

Hva du vil lære:

• Hva er sikker koding?
  • Risikoreduserende tiltak
  • Årsaker til utilstrekkelig sikkerhetsimplementering
• Retningslinjer for sikker koding
  • Språkvalg for sikker koding
  • Sikker kodingsregler og anbefalinger
  • Vanlige programmeringsfeil som skal unngås
• Sjekkliste for sikker kodepraksis
  • Tabelloversikt over sikker kodingssjekkliste
• Konklusjon
  • Anbefalt lesing

Hva er sikker koding?

Sikker koding er å designe og utvikle programvare av unngå svakhetene som fører til sikkerhetsrelaterte sårbarheter ved å følge de spesifiserte sikkerhetsstandardene og bransjens beste praksis.

Det aller første spørsmålet som dukker opp i alles sinn er ‘Hvor mye sikkerhet kreves for programvaren vår’ eller Når kan vi si at programvaren vår er sikret? og Hva er disse sikkerhetsstandardene ?

Bedrageri og sikkerhetstrusler øker dag for dag, og vi ser nye varianter og måter å hacke på, selv i den såkalte mest sikrede programvaren.

Nylig hørte vi at UIDAIs Aaadhar-program ble manipulert for personopplysninger. Derfor er det veldig vanskelig å vite hvor mye sikkerhet som kreves for programvaren og hva som er sikkerhetsstandardene med mindre vi forstår truslene som er involvert i programvaren og prioriterer dem basert på risikoen for virksomheten.

Det kan være vanskelig å gi 100% sikkerhetsbeskyttelse til programvaren, men hvis programteamet analyserer Risiko og verdipapirer som er involvert i programvaren deres, dvs. potensielle trusler, og hvis teamet kan ta seg av dempet risikoen, vil det være bra fra sikkerhetspunktet til applikasjonen.

Dermed er den aller første oppgaven for teamet å identifisere og analysere risikoen og verdipapirene som er involvert i deres anvendelse og forstå mulige avbøtingsalternativer og vedta det beste alternativet deretter.

Så når de først er identifisert, klassifiserer de ti beste sårbarhetene nesten alle angrepene som et program sannsynligvis vil møte. Dette vil bidra til å forstå truslene og prioritere sikkerhets- og utviklingsarbeidet mer mot forebygging enn avbøting.

F.eks. Mens vi planlegger å utvikle en helserelatert app, som håndterer og lagrer individets helsedata og deres personlige informasjon, er den største sikkerhetsrisikoen for applikasjonen å stjele personopplysningene.

Risikoreduserende tiltak

For å redusere risikoen,

• Implementering av sikkerhet for tilgang til data fra en uautorisert bruker må håndteres med riktig autentisering og autorisasjon (sterk implementering av passordpolicy, 2-faktor autentisering).
• Det må utvises forsiktighet for å sikre at det ikke oppstår datalekkasje under overføring av data fra en kilde til en annen kilde ved å implementere sikre kanaler (HTTPS) for dataoverføring og implementere datakryptering under transitt.
• Manipulering eller stjeling av data i hvile er også en annen mulighet. Derfor er lagring av personlige helsedata (ved hjelp av kryptering) veldig viktig.

Før du går til 'Secure Coding Standard', er det alltid bedre for hele programteamet å ha en ‘Sessions for bevissthet om sikkerhet’ og diskutere og brainstorme om,

• Kravet til sikkerhet for deres spesifikke produkt.
• Mulige fordeler som en hacker ville ha ved å hacke systemet deres.
• Mulige måter og metoder for sikkerhetskompromisser ved applikasjonen.
• Vanlig sikkerhetspraksis fulgt i en lignende bransje og et domene.
• Forståelse av typiske sikkerhetsproblemer i deres respektive programmer.

Det hjelper også teamet til å håndtere bedre, hvis de kan forstå Sårbarhetskilder som programvaren deres kan møte og årsakene til at programvaren er bygget med Dårlig / utilstrekkelig Sikkerhet .

Årsaker til utilstrekkelig sikkerhetsimplementering

Generelt er følgende noen årsaker til utilstrekkelig sikkerhetsimplementering i applikasjonen.

• Prioritet er gitt for funksjonelle utgivelser enn sikkerhetsaspekter.
• Uvitenhet eller ingen bevissthet om programvaresikkerhet og hackere.
• Ikke nok klarhet om programmet eller selve programvaredesignet.
• Kompleksiteten i programmet.
• Ikke nok data, informasjon om live-systemet der den skal distribueres.
• Ingen hensyn til sikkerhet i SDLC-fasene.
• Utilstrekkelig kunnskap og forståelse av detaljene i språket som brukes i programvaren.
• Ikke nok kunnskap til teamet og utviklerne om retningslinjer for sikkerhetskoding.

Vi vet at det ikke er slik at alle utviklere og testere er klar over sikkerheten til en applikasjon og kanskje ikke har en grundig forståelse av sikkerhetsproblemer og utnyttelser, spesielt ikke for applikasjonen de vil jobbe med. Generelt vil de være kjent med, ‘Hvordan kode funksjonelt’ men ikke alle vet «Hvordan kode sikkert».

Derfor er det veldig viktige aspektet for organisasjonen å vedta Secure Coding Practices i programvaren sin å først ‘Train People’ . Så det er veldig viktig å trene teamet deres om sikre kodingsaspekter, beste sikkerhetskodepraksis og riktig bruk av verktøy.

Det viktigste designprinsippet for programvaresikkerhet er å 'Implementer sikkerhet etter design og standard' .

Retningslinjer for sikker koding

For å oppnå sikkerhet er det veldig viktig å ha en ‘Secure Coding standard’ identifisert for et program helt i begynnelsen av applikasjonsutviklingen, og dette hjelper teamet med å ta seg av Secure Standard for programvaren og bidra til å beskytte den mot angrepene.

Det er viktig å sikre at hele teamet er det Tvang for å overholde denne standarden , uavhengig av kodingspråket og verktøyene de bruker i programmet.

Nedenfor er noen eksempler som må implementeres som standard i den sikre kodedesignen:

• Tilgang bør være begrenset til autentiserte brukere, og autentisering må implementeres i hvert lag.
• Kommunikasjonskanalene må krypteres for å beskytte autentiseringstokener.
• Alle nøkler, passord og sertifikater må være riktig lagret og beskyttet.
• Filkryptering, databasekryptering og dataelementkryptering må implementeres.

Språkvalg for sikker koding

Språkvalget for koding er kanskje ikke avhengig av sikker koding. Det er ikke noe spesifikt som et sikret eller usikret språk for koding for å bygge en sikret programvare.

Det er bare hvordan vi bruker et programmeringsspråk for å bygge programvaren og hvor mye inngående kunnskap utvikleren har om kodingsspråket i implementeringen av sikkerhetsaspekter.

Imidlertid er det avklart at, skjønt Sikker kodingsstandarder er uavhengige av valget av språk, den beste fremgangsmåten for sikker kode er språkavhengig, plattformavhengig og implementeringsavhengig .

For å ha en sikker kode, er det derfor viktig for utvikleren å ha inngående kunnskap om språket som brukes i programmet, slik at sikkerhetspraksis kan implementeres enkelt.

Eksempel:

• Sannsynligheten for sårbarhet med bufferoverløp er forskjellig fra språk til språk, men C, C ++ og Assembly anses å være mest utsatt på grunn av deres utdaterte minnestyringsfunksjoner. Flere standard C lib-funksjoner, for eksempel strcpy () og memcpy (), er sårbare for bufferoverløpsangrep. Feil bruk av disse funksjonene ved å kopiere en kildebuffer som er for stor til å passe inn i målbufferen, resulterer i bufferoverløp.
• Det vanligste problemet i Java-baserte webapplikasjoner er mulige ressurlekkasjer som kan oppstå på grunn av åpne systemressurser, for eksempel en fil-, stikkontakt- og databaseforbindelse.

Neste aspekt av sikkerhet handler om verktøy som skal brukes i applikasjonsprogrammet for å optimalisere sikkerheten ved hjelp av verktøy som Integrerte utviklingsmiljøer vil være mest fordelaktig da de gir mye Varsler til brukerne og vær oppmerksom på disse varslene for å prøve å forbedre kvaliteten på programvaren.

• Integrering av kommersielle eller åpen kildekodebiblioteker / plugins som Eclipse, Spring Tool Suite, RAD med IDE hjelper utviklerne til å skrive sikker kode ved å oppdage og identifisere potensielt sårbar kode og gir varsler om funn relatert til skadelig filutførelse, informasjonslekkasje og feil feilhåndtering.

Det er også viktig å bruke Statiske og dynamiske analysatorer for å forbedre sikkerhetsaspektene av programvaren. Vanligvis er statiske analysatorer optimalisert for bestemte typer feil, slik at de ender opp med å finne et stort antall falske positive mens de identifiserer spesifikke feil. Noen ganger er det muligheter for at de også savner de faktiske feilene.

Derfor anbefales det å bruke flere statiske analysatorer for å få bedre dekning av forskjellige typer feil og for å unngå mange falske positive. Noen ganger anbefales det også å utføre manuell testing til eliminere falske positive .

Sikker kodingsregler og anbefalinger

Det vil være bra for programmet å definere et sett med ‘Sikker kodingsregler og anbefalinger’ som kildekoden kan evalueres for å være samsvar, slik at testerne kan utføre 'Testing av samsvarssamsvar' for hver av disse sikre kodingsstandardene.

Derfor kan sikkerhetskoden sertifiseres som samsvarende eller ikke-samsvarende ved å bruke disse reglene mot den angitte referansen.

Få av reglene nevnt nedenfor kan brukes til å se etter sikkerhetsbrudd:

• Filer må lukkes når de ikke lenger er nødvendige.
• Når du passerer en struktur over en grense, må informasjonslekkasje unngås.
• Objekter skal deklareres med passende lagringstid.

Så, testtilfeller for å verifisere disse reglene må utformes og utføres for å kontrollere samsvarets samsvar. Det er også identifisert at de fleste av sårbarhetene er forårsaket av typiske vanlige programmeringsfeil.

Derfor må utvikleren forstå ‘Usikker metode for koding’ , mens de også lærer seg beste praksis for Secure Coding. Det er ideelt å samle de vanligste programmeringsfeilene som bidrar til sikkerhetsproblemene i applikasjonen deres, slik at de kan tas vare på mens de kodes.

Slike typiske programmeringsfeil er hovedsakelig bidratt fra bufferoverløp, skripting på tvers av nettsteder og injeksjonsfeil.

Noen av de typiske programmeringssårbarhetene inkluderer,

• SQL Injection (Feil nøytralisering av spesielle elementer brukt i en SQL Command).
• Heltalloverløp.
• Bufferoverløp (Buffer Copy uten å kontrollere størrelsen på inngangen).
• Ukontrollert formatstreng.
• Mangler godkjenning og autorisasjon (feil autorisasjon).
• Sensitiv dataeksponering.
• Feil feilhåndtering.

Noen av disse feilene kan føre til systemkrasj, uventet tilgang til systemet og kontroll av programvaren som går tapt for hackerne.

Vanlige programmeringsfeil som skal unngås

Få vanlige programmeringsfeil som må unngås er listet opp nedenfor:

• Feil nøytralisering av spesielle elementer brukt i en SQL-kommando (‘SQL Injection’).
• Bufferkopi uten å sjekke størrelsen på inngangen (‘Classic Buffer Overflow’).
• Mangler godkjenning for kritisk funksjon.
• Manglende eller feil autorisasjon.
• Bruk av hardkodede referanser.
• Mangler kryptering av sensitive data.
• Ubegrenset opplasting av fil med farlig type.
• Avhengighet av ikke-klarerte innganger i en sikkerhetsbeslutning.
• Utførelse med unødvendige privilegier.
• Forfalskning på tvers av nettsteder (CSRF).
• Nedlasting av kode uten integritetssjekk.
• Feil beregning av bufferstørrelse.
• Feil begrensning av overdreven autentiseringsforsøk.
• URL-omdirigering til ikke-klarert nettsted (‘Open Redirect’).
• Ukontrollert formatstreng.
• Bruk av enveis hasj uten salt.

Sjekkliste for sikker kodepraksis

Sist, men ikke minst, etter å ha vurdert alle punktene ovenfor i Secure Software Development-aspekter, må utviklerne følge Sjekkliste opprettet for Secure Code Practices for å sikre at ting ikke blir savnet. Nedenfor er noen få, men ikke en uttømmende liste.

Inngangsvalidering:

• Ikke stol på innspill, vurder sentralisert inngangsvalidering.
• Ikke stol på validering på klientsiden.
• Vær forsiktig med problemer med kanonisering.
• Begrens, avvis og rens innspill. Valider for type, lengde, format og rekkevidde.

Godkjenning:

• Partisjonsside etter anonymt, identifisert og autentisert område.
• Bruk sterke passord.
• Støtt utløpsperioder for passord og deaktivering av konto.
• Ikke lagre legitimasjon (bruk enveis hash med salt).
• Krypter kommunikasjonskanaler for å beskytte godkjenningstokener.
• Pass skjemaer autentisering informasjonskapsler bare over HTTPS-tilkoblinger.

Autorisasjon:

• Bruk minst privilegerte kontoer.
• Vurder autorisasjonsgranularitet.
• Håndheve separasjon av privilegier.
• Begrens brukertilgang til systemnivåressurser.
• Bruk OAuth 2.0-protokollen for autentisering og autorisering.
• Validering av Carryout API.
• Hviteliste tillatte metoder.
• Beskytt privilegerte handlinger og sensitive ressurssamlinger.
• Beskytt mot ressursforfalskning på tvers av nettsteder (CSRF).

Øktledelse:

• Opprett en øktidentifikator på serveren.
• Avslutt økten med Logoff.
• Generer en ny økt om re-autentisering.
• Angi 'sikker' attributt for informasjonskapsler som overføres over TLS.

Kryptografi:

• Bruk kryptografi mens 'Data under transport, Data i lagring, Data i bevegelse, Meldingsintegritet'.
• Ikke utvikle din egen. Bruk prøvde og testede plattformfunksjoner.
• Hold ukryptert data nær algoritmen.
• Bruk riktig algoritme og nøkkelstørrelse.
• Unngå nøkkeladministrasjon (bruk DPAPI).
• Sykle nøklene med jevne mellomrom.
• Oppbevar nøkler på et begrenset sted.

Logging og revisjon:

• Identifiser skadelig oppførsel.
• Vet hvordan god trafikk ser ut.
• Revisjon og loggaktivitet gjennom alle applikasjonsnivåene.
• Sikker tilgang til loggfiler.
• Sikkerhetskopier og analyser regelmessig loggfilene.

Utgangskoding:

• Carryout ‘Input Validation (XML, JSON….).
• Bruk Parameterized query.
• Gjennomfør 'Schema validering'.
• Utfør koding (XML, JSON ..).
• Send sikkerhetsoverskrifter.

Referanse: ' OWASP Secure Coding Practices Checklist (Kort sagt, SCP-sjekkliste) '

Tabelloversikt over sikker kodingssjekkliste

Tabellen nedenfor oppsummerer ‘Ting å huske for sikker kode’ av en søknad.

Konklusjon

Vi håper denne opplæringen vil være din beste guide for å sikre programvaresikkerhet.

Retningslinjene for koding for sikker programvareutvikling ble oppført her i enkle termer med eksempler for enkel forståelse av konseptet.

Glad lesning !!

Anbefalt lesing

• Sikkerhetstesting (En komplett guide)
• Topp 30 BESTE cybersikkerhetsselskaper i 2021 (små til bedriftsnivåbedrifter)
• Grunnleggende om dataprogrammering for nybegynnere Koding veiledning
• Topp 15 beste gratis kodeditorer for perfekt kodingsopplevelse
• SQL Injection Testing Tutorial (Eksempel og forebygging av SQL Injection Attack)
• Utviklere er ikke gode testere. Hva sier du?
• ISTQB Foundation Exam Format & Guidelines To Solve Papers
• Retningslinjer for testing av mobilapper