Retningslinjer for sikker kodning og bedste praksis for udviklere

secure coding guidelines

Denne vejledning forklarer sikker kodning, hvordan man undgår sikkerhedsrelaterede sårbarheder, og giver kodningsretningslinjer og tjekliste til sikker kodningspraksis:

For at have sikkerhed indbygget i softwaren og implementere Secure Coding Guidelines and Best Practices, skal hele organisationen sammen med det team, der er identificeret til at arbejde på den tilsigtede Application Development, overveje visse aspekter.

Her vil vi diskutere de aspekter, der hjælper med at udvikle en sikret software.

Det er så simpelt, at hvis en udvikler ikke ved, hvad der menes med 'Sikkerhed til softwaren' og hvordan en hacker kan hacke deres software, tage kontrol over den og prøve at udnytte, så er det simpelthen umuligt at kode en sikker software. Så udvikleren skal først forstå betydningen af ​​Secure Coding.

Hvad du lærer:

• Hvad er sikker kodning?
  • Risikoreduktion
  • Årsager til utilstrækkelig sikkerhedsimplementering
• Retningslinjer for sikker kodning
  • Sprogvalg til sikker kodning
  • Sikker kodningsregler og anbefalinger
  • Almindelige programmeringsfejl, der skal undgås
• Tjekliste til sikker kodepraksis
  • Tabeloversigt over sikker kodningsliste
• Konklusion
  • Anbefalet læsning

Hvad er sikker kodning?

Sikker kodning er at designe og udvikle software af undgå svaghederne der fører til sikkerhedsrelaterede sårbarheder ved at overholde de specificerede sikkerhedsstandarder og branchens bedste praksis.

Det allerførste spørgsmål, der opstår i alles sind er 'Hvor meget sikkerhed kræves for vores software' eller Hvornår kan vi sige, at vores software er sikret? og Hvad er disse sikkerhedsstandarder ?

Bedrageri og sikkerhedstrusler øges dag for dag, og vi ser nye sorter og måder at hacke på, selv i den såkaldte mest sikrede software.

For nylig hørte vi UIDAIs Aaadhar-program blive manipuleret for personlige data. Derfor er det virkelig svært at vide, hvor meget sikkerhed der kræves til softwaren, og hvad der er sikkerhedsstandarder, medmindre vi forstår de trusler, der er involveret i softwaren, og prioriterer dem ud fra risiciene for virksomheden.

Det kan muligvis være vanskeligt at give 100% sikkerhedsbeskyttelse til softwaren, men hvis programteamet analyserer Risici og værdipapirer der er involveret i deres software, dvs. potentielle trusler, og hvis teamet kan tage sig af at afbøde disse risici, ville det være godt fra applikationens sikkerhedspunkt.

Således er holdets allerførste opgave at identificere og analysere de risici og værdipapirer, der er involveret i deres anvendelse og forstå de mulige afbødningsmuligheder og vedtage den bedste løsning i overensstemmelse hermed.

Så når de først er identificeret, klassificerer de ti største sårbarheder næsten alle de angreb, som et program sandsynligvis vil stå over for. Dette vil være med til at forstå truslerne og prioritere sikkerheds- og udviklingsindsatsen mere mod forebyggelse end afbødning.

For eksempel. Mens vi planlægger at udvikle en sundhedsrelateret app, der håndterer og gemmer den enkeltes sundhedsdata og deres personlige oplysninger, er den største sikkerhedsrisiko for applikationen at stjæle personens sundhedsdata.

Risikoreduktion

For at mindske risikoen

• Implementering af sikkerhed for adgang til data fra en uautoriseret bruger skal håndteres med korrekt godkendelse og autorisation (stærk implementering af adgangskodepolitik, 2-faktor-godkendelse).
• Der skal udvises forsigtighed for at sikre, at der ikke er nogen datalækage under transmission af data fra en kilde til en anden kilde ved at implementere sikre kanaler (HTTPS) til datatransmission og implementere datakryptering under transit.
• Manipulering eller stjæling af data i hvile er også en anden mulighed. Derfor er opbevaring af personlige sundhedsdata (Brug af kryptering) meget vigtigt.

Inden vi går til 'Secure Coding Standard', er det altid bedre for hele programholdet at have en 'Sikkerhedsbevidsthedssession' og diskutere og brainstorme om,

• Kravet om sikkerhed for deres specifikke produkt.
• Mulige fordele, som en hacker ville have ved at hacke deres system.
• Mulige måder og midler til sikkerhedskompromisser ved deres anvendelse.
• Almindelig sikkerhedspraksis blev fulgt i en lignende branche og et domæne.
• Forståelse af typiske sikkerhedsproblemer i deres respektive programmer.

Det hjælper også holdet til at håndtere bedre, hvis de kan forstå Sårbarhedskilder at deres software kan møde, og årsagerne til, at softwaren er bygget med Dårlig / utilstrækkelig Sikkerhed .

Årsager til utilstrækkelig sikkerhedsimplementering

Generelt er følgende et par årsager til utilstrækkelig implementering af sikkerhed i applikationen.

• Prioritet gives til funktionel frigivelse end sikkerhedsaspekter.
• Uvidenhed eller ingen bevidsthed om softwaresikkerhed og hackere.
• Ikke nok klarhed om programmet eller selve softwaredesignet.
• Programmets kompleksitet.
• Ikke nok data, information om det live system, hvor det vil blive implementeret.
• Intet hensyn til sikkerhed i SDLC-faser.
• Utilstrækkelig viden og forståelse af det specifikke sprog, der bruges i softwaren.
• Ikke nok viden til teamet og udviklerne om retningslinjer for sikkerhedskodning.

Vi ved, at det ikke er, at alle udviklere og testere er opmærksomme på sikkerheden i en applikation og muligvis ikke har en dybdegående forståelse af sikkerhedssårbarheder og udnyttelser, især for den applikation, som de ville arbejde på. Generelt vil de være fortrolige med, 'Sådan kodes funktionelt' men ikke alle ved 'Hvordan man kode sikkert'.

Derfor er det meget vigtige aspekt for organisationen at anvende Secure Coding Practices i deres software først 'Træn mennesker' . Så det er meget vigtigt at træne deres team om sikre kodningsaspekter, bedste sikkerhedskodning og korrekt brug af værktøjet.

Det vigtigste designprincip for softwaresikkerhed er at 'Implementér sikkerhed ved design og standard' .

Retningslinjer for sikker kodning

For at opnå sikkerhed er det meget vigtigt at have en 'Sikker kodningsstandard' identificeret til et program i begyndelsen af ​​applikationsudviklingen, og dette hjælper holdet med at tage sig af de sikre standardindstillinger for softwaren og hjælpe med at beskytte det mod angrebene.

Det er vigtigt at sikre, at hele holdet er Tvinges til at overholde denne standard , uanset kodningssproget og de værktøjer, de bruger i programmet.

Nedenfor er et par eksempler, der skal implementeres som standard i det sikre kodedesign:

• Adgang bør kun være begrænset til godkendte brugere, og godkendelse skal implementeres på hvert lag.
• Kommunikationskanalerne skal krypteres for at beskytte godkendelsestokens.
• Alle nøgler, adgangskoder og certifikater skal opbevares og beskyttes korrekt.
• Filkryptering, databasekryptering og dataelementkryptering skal implementeres.

Sprogvalg til sikker kodning

Sprogvalget til kodning afhænger muligvis ikke af sikker kodning. Der er ikke noget specifikt som et sikret eller usikret sprog til kodning for at opbygge en sikret software.

Det er bare, hvordan vi bruger et programmeringssprog til at opbygge softwaren, og hvor meget dybdegående viden udvikleren har om kodningssproget i implementeringen af ​​sikkerhedsaspekter.

Det er imidlertid præciseret, at Sikker kodningsstandarder er uafhængige af valget af sprog, den bedste praksis for sikker kode er sprogafhængig, platformafhængig og implementeringsafhængig .

For at have en sikker kode er det således vigtigt for udvikleren at have indgående kendskab til det sprog, der bruges i programmet, så de bedste praksis for sikkerhed let kan implementeres.

Eksempel:

• Sandsynligheden for bufferoverløbssårbarhed adskiller sig fra sprog til sprog, men C, C ++ og Assembly betragtes som mest modtagelige på grund af deres forældede hukommelsesstyringsfunktioner. Flere standard C lib-funktioner, såsom strcpy () og memcpy (), er sårbare over for bufferoverløbsangreb. Forkert brug af disse funktioner ved at kopiere en kildebuffer, der er for stor til at passe ind i destinationsbufferen, resulterer i bufferoverløb.
• Det almindelige problem i Java-baserede webapplikationer er de mulige ressourcelækager, der kan opstå på grund af åbne systemressourcer, såsom en fil-, socket- og databaseforbindelse.

Det næste aspekt af sikkerhed handler om værktøjer, der skal bruges i applikationsprogrammet for at optimere sikkerheden ved hjælp af værktøjer som f.eks Integrerede udviklingsmiljøer vil være mest gavnligt, da de giver en masse Advarsler til brugerne og vær opmærksom på disse advarsler for at forsøge at forbedre softwarens kvalitet.

• Integration af kommercielle eller Open source-biblioteker / plugins som Eclipse, Spring Tool Suite, RAD med IDE hjælper udviklerne med at skrive sikker kode ved at opdage og identificere potentielt sårbar kode og giver advarsler om fund relateret til ondsindet filudførelse, informationslækage og forkert fejlhåndtering.

Det er også vigtigt at bruge Statiske og dynamiske analysatorer for at forbedre sikkerhedsaspekterne ved softwaren. Generelt er statiske analysatorer optimeret til specifikke fejltyper, så de ender med at finde et stort antal falske positive, mens de identificerer specifikke fejl. Nogle gange er der muligheder for, at de også går glip af de faktiske fejl.

Derfor anbefales det at bruge flere statiske analysatorer for at få bedre dækning af forskellige typer fejl og for at undgå mange falske positive. Til tider anbefales det også at udføre manuel test til eliminere falske positive .

Sikker kodningsregler og anbefalinger

Det vil være godt for programmet at definere et sæt 'Sikker kodningsregler og anbefalinger' som kildekoden kan evalueres for at være i overensstemmelse med, så testerne kan udføre 'Test af overensstemmelsesoverensstemmelse' for hver af disse sikre kodningsstandarder.

Derfor kan sikkerhedskoden certificeres som Conforming eller Non-Conforming ved hjælp af disse regler i forhold til det indstillede benchmark.

Få af nedenstående regler kan bruges til at kontrollere sikkerhedsovertrædelser:

• Filer skal lukkes, når de ikke længere er nødvendige.
• Når du passerer en struktur over en grænse, skal informationslækage undgås.
• Objekter skal deklareres med passende opbevaringstid.

Så testtilfælde for at verificere disse regler skal designes og udføres for at kontrollere overensstemmelse med overensstemmelse. Det identificeres også, at de fleste af sårbarhederne skyldes typiske almindelige programmeringsfejl.

Derfor skal udvikleren forstå 'Usikker metode til kodning' , mens de også lærer de bedste fremgangsmåder ved Secure Coding. Det er ideelt at samle de mest almindelige programmeringsfejl, der bidrager til deres applikations sikkerhedssårbarheder, så de kan håndteres under kodning.

Sådanne typiske programmeringsfejl er hovedsageligt bidraget fra bufferoverløb, scripting på tværs af websteder og mangler ved injektion.

Nogle af de typiske programmeringssårbarheder inkluderer,

• SQL-injektion (forkert neutralisering af specielle elementer, der bruges i en SQL-kommando).
• Heltalsoverløb.
• Bufferoverløb (Buffer Copy uden kontrol af inputstørrelse).
• Ukontrolleret formatstreng.
• Manglende godkendelse og godkendelse (forkert godkendelse).
• Sensitiv dataeksponering.
• Forkert håndtering af fejl.

Nogle af disse fejl kan føre til systemnedbrud, uventet adgang til systemet og kontrol over softwaren, der går tabt for hackerne.

bedste junk cleaner til Windows 10

Almindelige programmeringsfejl, der skal undgås

Få almindelige programmeringsfejl, der skal undgås, er angivet nedenfor:

• Forkert neutralisering af specielle elementer, der bruges i en SQL-kommando ('SQL Injection').
• Bufferkopi uden at kontrollere størrelsen på input ('Klassisk bufferoverløb').
• Manglende godkendelse til kritisk funktion.
• Manglende eller forkert godkendelse.
• Brug af hårdkodede legitimationsoplysninger.
• Manglende kryptering af følsomme data.
• Ubegrænset upload af fil med farlig type.
• Afhængighed af ikke-tillid til input i en sikkerhedsbeslutning.
• Udførelse med unødvendige privilegier.
• Forfalskning på tværs af websteder (CSRF).
• Download af kode uden integritetskontrol.
• Forkert beregning af bufferstørrelse.
• Forkert begrænsning af overdreven godkendelsesforsøg.
• URL-omdirigering til ikke-betroet websted ('Åben omdirigering').
• Ukontroleret formatstreng.
• Brug af en envejs hash uden salt.

Tjekliste til sikker kodepraksis

Sidst, men ikke mindst, efter at have overvejet alle ovenstående punkter i Secure Software Development-aspekter, skal udviklerne følge Tjekliste oprettet til Secure Code Practices for at sikre, at ting ikke går glip af. Nedenfor er et par, men ikke en udtømmende liste.

Inputvalidering:

• Stol ikke på input, overvej centraliseret inputvalidering.
• Stol ikke på validering på klientsiden.
• Vær forsigtig med problemer med kanonisering.
• Begræns, afvis og rens input. Valider for type, længde, format og rækkevidde.

Godkendelse:

• Opdelingssted efter anonymt, identificeret og godkendt område.
• Brug stærke adgangskoder.
• Support udløbsperioder for adgangskode og deaktivering af konto.
• Opbevar ikke legitimationsoplysninger (brug envejs hashes med salt).
• Krypter kommunikationskanaler for at beskytte godkendelsestokens.
• Videregiv kun formular-godkendelsescookies via HTTPS-forbindelser.

Bemyndigelse:

• Brug mindst privilegerede konti.
• Overvej autorisationsgranularitet.
• Håndhæve adskillelse af privilegier.
• Begræns brugeradgang til ressourcer på systemniveau.
• Brug OAuth 2.0-protokollen til godkendelse og godkendelse.
• Carryout API Validering.
• Hvidliste tilladte metoder.
• Beskyt privilegerede handlinger og følsomme ressourceindsamlinger.
• Beskyt mod forfalskning på tværs af ressourcer (CSRF).

Sessionsstyring:

• Opret en sessionsidentifikator på serveren.
• Afslut sessionen med Logoff.
• Generer en ny session om re-godkendelse.
• Indstil den 'sikre' attribut for cookies, der transmitteres via TLS.

Kryptografi:

• Brug kryptografi, mens 'Data under forsendelse, Data i lager, Data i bevægelse, Beskedintegritet'.
• Udvikl ikke din egen. Brug afprøvede platformsfunktioner.
• Hold ukrypterede data tæt på algoritmen.
• Brug den rigtige algoritme og nøglestørrelse.
• Undgå nøglehåndtering (brug DPAPI).
• Cykle dine nøgler med jævne mellemrum.
• Gem nøgler et begrænset sted.

Logning og revision:

• Identificer ondsindet adfærd.
• Ved, hvordan god trafik ser ud.
• Audit og log aktivitet gennem alle applikationsniveauer.
• Sikker adgang til logfiler.
• Sikkerhedskopier og regelmæssigt analysere logfilerne.

Udgangskodning:

• Carryout ‘Input Validation (XML, JSON….).
• Brug parametreret forespørgsel.
• Udfør 'Skemavalidering'.
• Udfør kodning (XML, JSON ..).
• Send sikkerhedsoverskrifter.

Reference: '' OWASP-tjekliste for sikker kodning (Kort sagt SCP-tjekliste) ''

Tabeloversigt over sikker kodningsliste

Nedenstående tabel opsummerer 'Ting at huske for sikker kode' af en ansøgning.

Konklusion

Vi håber, at denne vejledning vil være din bedste guide til at sikre softwaresikkerhed.

Kodningsretningslinjerne for sikker softwareudvikling blev anført her i enkle vendinger med eksempler til din nemme forståelse af konceptet.

God læselyst!!

Anbefalet læsning

• Sikkerhedstest (En komplet guide)
• Top 30 BEDSTE virksomheder inden for cybersikkerhed i 2021 (små virksomheder til virksomhedsniveau)
• Grundlæggende om computerprogrammering til begyndere Kodning Tutorial
• Top 15 bedste gratis kodeditorer til perfekt kodningsoplevelse
• SQL Injection Testing Tutorial (Eksempel og forebyggelse af SQL Injection Attack)
• Udviklere er ikke gode testere. Hvad sagde du?
• ISTQB Foundation Exam Format & Retningslinjer til løsning af papirer
• Retningslinjer for test af mobilapps sikkerhed