Richtlijnen voor veilige codering en best practices voor ontwikkelaars

secure coding guidelines

In deze tutorial wordt Secure Coding uitgelegd, hoe beveiligingsgerelateerde kwetsbaarheden kunnen worden voorkomen, en biedt coderingsrichtlijnen en checklist voor veilige coderingspraktijken:

Om beveiliging in de software te hebben ingebouwd en om Secure Coding Guidelines and Best Practices te implementeren, moet de hele organisatie, samen met het team dat aan de beoogde applicatieontwikkeling werkt, rekening houden met bepaalde aspecten.

Hier zullen we die aspecten bespreken die helpen om een ​​beveiligde software te ontwikkelen.

Zo simpel is het als een ontwikkelaar niet weet wat er wordt bedoeld ‘Beveiliging voor de software’ en hoe een hacker zijn software kan hacken, er controle over kan nemen en proberen te misbruiken, dan is het simpelweg onmogelijk om een ​​veilige software te coderen. De ontwikkelaar moet dus eerst de betekenis van Secure Coding begrijpen.

Wat je leert:

• Wat is veilige codering?
  • Risicobeperking
  • Redenen voor inadequate beveiligingsimplementatie
• Richtlijnen voor veilige codering
  • Taalkeuze voor veilige codering
  • Veilige coderingsregels en aanbevelingen
  • Veelvoorkomende programmeerfouten die moeten worden vermeden
• Checklist voor veilige codepraktijken
  • Tabeloverzicht van de checklist voor veilige codering
• Gevolgtrekking
  • Aanbevolen literatuur

Wat is veilige codering?

Veilige codering is om software te ontwerpen en ontwikkelen door het vermijden van de zwakke punten die leiden tot beveiligingsgerelateerde kwetsbaarheden door te voldoen aan de gespecificeerde beveiligingsnormen en best practices uit de branche.

De allereerste vraag die bij iedereen opkomt is ‘Hoeveel beveiliging is vereist voor onze software’ of Wanneer kunnen we zeggen dat onze software is beveiligd? en Wat zijn die beveiligingsnormen? ​

Fraude en veiligheidsbedreigingen nemen met de dag toe en we zien nieuwe varianten en manieren van hacken, zelfs in de zogenaamde meest beveiligde software.

Onlangs hoorden we dat met het Aaadhar-programma van UIDAI werd geknoeid voor persoonlijke gegevens. Daarom is het erg moeilijk om te weten hoeveel beveiliging vereist is voor de software en wat de beveiligingsnormen zijn, tenzij we de bedreigingen van de software begrijpen en deze prioriteiten stellen op basis van de risico's voor het bedrijf.

Het kan mogelijk moeilijk zijn om de software 100% beveiliging te bieden, maar als het Programmateam het Risico's en zekerheden die betrokken zijn bij hun software, d.w.z. potentiële bedreigingen, en als het team kan zorgen voor het verminderen van die risico's, dan zou het goed zijn vanuit het beveiligingspunt van de applicatie.

j2ee interviewvragen en antwoorden voor ervaren

De allereerste taak van het team is dus het identificeren en analyseren van de risico's en effecten die bij de toepassing ervan betrokken zijn, en de mogelijke risicobeperkende opties begrijpen en dienovereenkomstig de beste optie kiezen.

Dus, zodra de top tien kwetsbaarheden zijn geïdentificeerd, worden bijna alle aanvallen waarmee een programma waarschijnlijk te maken krijgt, geclassificeerd. Dit zal helpen om de bedreigingen te begrijpen en prioriteit te geven aan de inspanningen op het gebied van veiligheid en ontwikkeling, meer gericht op preventie dan op mitigatie.

Bijv. Hoewel we van plan zijn een gezondheidszorggerelateerde app te ontwikkelen die de gezondheidsgegevens van het individu en zijn persoonlijke gegevens verwerkt en opslaat, is het stelen van de persoonlijke gezondheidsgegevens het grootste beveiligingsrisico voor de toepassing.

Risicobeperking

Om het risico te verkleinen,

• Implementatie van beveiliging voor toegang tot gegevens door een ongeautoriseerde gebruiker moet worden afgehandeld met de juiste authenticatie en autorisatie (implementaties van sterk wachtwoordbeleid, 2-factorenauthenticatie).
• Er moet voor worden gezorgd dat er geen datalek is tijdens de overdracht van gegevens van de ene bron naar een andere bron door beveiligde kanalen (HTTPS) voor gegevensoverdracht te implementeren en gegevenscodering tijdens de overdracht te implementeren.
• Het knoeien of stelen van gegevens in rust is ook een andere mogelijkheid. Daarom is de opslag van persoonlijke gezondheidsgegevens (met behulp van codering) zeer essentieel.

Voordat u naar de ‘Secure Coding Standard’ gaat, is het altijd beter dat het hele programmateam een ‘Sessie voor beveiligingsbewustzijn’ en discussiëren en brainstormen over,

• De vereiste van beveiliging voor hun specifieke product.
• Mogelijke voordelen die een hacker zou hebben door zijn systeem te hacken.
• Mogelijke manieren en middelen om de beveiliging van hun toepassing in gevaar te brengen.
• Gemeenschappelijke beveiligingspraktijken gevolgd in een vergelijkbare branche en domein.
• Inzicht in typische beveiligingsproblemen van hun respectievelijke programma's.

Het helpt het team ook om beter om te gaan, als ze de Bronnen van de kwetsbaarheden waarmee hun software te maken kan krijgen en de redenen waarom de software is gebouwd Slecht / onvoldoende Veiligheid ​

Redenen voor inadequate beveiligingsimplementatie

In het algemeen zijn de volgende redenen voor een inadequate beveiligingsimplementatie in de applicatie.

• Er wordt prioriteit gegeven aan Functionele Release dan aan Beveiligingsaspecten.
• Onwetendheid of geen bewustzijn over softwarebeveiliging en hackers.
• Onvoldoende duidelijkheid over het programma of over het softwareontwerp zelf.
• De complexiteit van het programma.
• Niet genoeg gegevens, informatie over het live systeem waar het zal worden ingezet.
• Geen rekening gehouden met beveiliging in de SDLC-fasen.
• Onvoldoende kennis en begrip van de specifieke kenmerken van de taal die in de software wordt gebruikt.
• Niet genoeg kennis bij het team en de ontwikkelaars over richtlijnen voor beveiligingscodering.

We weten dat het niet zo is dat alle ontwikkelaars en testers op de hoogte zijn van de beveiliging van een applicatie en mogelijk geen diepgaand begrip hebben van beveiligingsproblemen en exploits, met name van de applicatie waaraan ze zouden werken. Over het algemeen zullen ze bekend zijn met, ‘Functioneel coderen’ maar ze weten niet allemaal ‘Veilig coderen’.

Daarom is het zeer belangrijke aspect voor de organisatie om Secure Coding Practices in hun software toe te passen eerst ‘Train mensen’ ​Het is dus erg belangrijk om hun team te trainen in veilige coderingsaspecten, de beste praktijken voor beveiligingscodering en het juiste gebruik van tools.

Het belangrijkste ontwerpprincipe van softwarebeveiliging is om ‘Beveiliging door ontwerp en standaard implementeren’ ​

Richtlijnen voor veilige codering

Om veiligheid te bereiken, is het erg essentieel om een ‘Secure Coding standard’ geïdentificeerd voor een programma aan het begin van de applicatieontwikkeling, en dit helpt het team bij het verzorgen van de Secure Defaults voor de software en bij het beschermen tegen aanvallen.

Het is essentieel om ervoor te zorgen dat het hele team dat is Gedwongen om te voldoen aan deze norm , ongeacht de codeertaal en de tools die ze in het programma gebruiken.

Hieronder vindt u enkele voorbeelden die standaard moeten worden geïmplementeerd in het ontwerp van beveiligde code:

• Toegang moet worden beperkt tot alleen geauthenticeerde gebruikers en authenticatie moet op elke laag worden geïmplementeerd.
• De communicatiekanalen moeten worden versleuteld om authenticatietokens te beschermen.
• Alle sleutels, wachtwoorden en certificaten moeten correct worden opgeslagen en beschermd.
• Bestandsversleuteling, database-versleuteling en versleuteling van gegevenselementen moeten worden geïmplementeerd.

Taalkeuze voor veilige codering

De taalkeuze voor codering is mogelijk niet afhankelijk van veilige codering. Er is niets specifieks als een beveiligde of onbeveiligde taal voor codering om beveiligde software te bouwen.

Het is precies hoe we een programmeertaal gebruiken om de software te bouwen en hoeveel diepgaande kennis de ontwikkelaar heeft over de coderingstaal bij het implementeren van beveiligingsaspecten.

Het wordt echter verduidelijkt Secure Coding Standards zijn onafhankelijk van de selectie van de taal, de Secure Code Best Practices zijn taalafhankelijk, platformafhankelijk en implementatie-afhankelijk ​

Om een ​​beveiligde code te hebben, is het dus essentieel dat de ontwikkelaar een grondige kennis heeft van de taal die in het programma wordt gebruikt, zodat de best practices op het gebied van beveiliging eenvoudig kunnen worden geïmplementeerd.

Voorbeeld:

• De kans op een kwetsbaarheid voor bufferoverloop verschilt van taal tot taal, maar C, C ++ en Assembly worden als het meest vatbaar beschouwd vanwege hun verouderde geheugenbeheermogelijkheden. Verschillende standaard C lib-functies, zoals strcpy () en memcpy (), zijn kwetsbaar voor buffer-overflow-aanvallen. Onjuist gebruik van deze functies, door het kopiëren van een bronbuffer die te groot is om in de bestemmingsbuffer te passen, resulteert in een bufferoverloop.
• Het veelvoorkomende probleem bij op Java gebaseerde webtoepassingen zijn de mogelijke lekken van bronnen die kunnen optreden als gevolg van open systeembronnen, zoals een bestand, socket en databaseverbindingen.

Het volgende aspect van beveiliging gaat over de hulpmiddelen die moeten worden gebruikt in het applicatieprogramma om de beveiliging te optimaliseren, met behulp van tools zoals Geïntegreerde ontwikkelomgevingen zal het meest voordelig zijn omdat ze veel bieden Waarschuwingen aan gebruikers en vestig de aandacht op die waarschuwingen om te proberen de kwaliteit van de software te verbeteren.

• Integratie van commerciële of open-source bibliotheken / plug-ins zoals Eclipse, Spring Tool Suite, RAD met IDE helpt de ontwikkelaars om veilige code te schrijven door potentieel kwetsbare code te detecteren en te identificeren en geeft waarschuwingen over bevindingen met betrekking tot het uitvoeren van schadelijke bestanden, informatielekken en onjuiste afhandeling van fouten.

Het is ook essentieel om de Statische en dynamische analysers om de beveiligingsaspecten van de software te verbeteren. Over het algemeen zijn statische analysers geoptimaliseerd voor specifieke soorten fouten, zodat ze uiteindelijk een groot aantal fout-positieven vinden terwijl ze specifieke fouten identificeren. Soms zijn er mogelijkheden dat ze ook de daadwerkelijke fouten missen.

Daarom wordt aanbevolen om te gebruiken meerdere statische analysers om een ​​betere dekking van verschillende soorten fouten te krijgen en om veel valse positieven te vermijden. Soms wordt het ook aanbevolen om uit te voeren handmatig testen naar elimineer valse positieven ​

Veilige coderingsregels en aanbevelingen

Het is goed voor het programma om een ​​set van ‘Regels en aanbevelingen voor veilig coderen’ waarop de broncode kan worden geëvalueerd op naleving, zodat de testers het ‘Conformance Compliance Testing’ voor elk van deze veilige coderingsstandaarden.

Daarom kan de beveiligingscode worden gecertificeerd als conform of niet-conform met behulp van die regels ten opzichte van de vastgestelde benchmark.

voorbeeldtestcases bij het testen van software

Enkele van de onderstaande regels kunnen worden gebruikt om te controleren op beveiligingsovertredingen:

• Bestanden moeten worden gesloten als ze niet langer nodig zijn.
• Bij het passeren van een constructie over een grens, moet informatielekkage worden voorkomen.
• Objecten moeten worden gedeclareerd met de juiste opslagduur.

Testcases om deze regels te verifiëren, moeten dus worden ontworpen en uitgevoerd om de conformiteit te controleren. Er wordt ook vastgesteld dat de meeste kwetsbaarheden worden veroorzaakt door typische veelvoorkomende programmeerfouten.

Daarom moet de ontwikkelaar het begrijpen ‘Onveilige coderingsmethode’ , terwijl ze ook de best practices van Secure Coding leren. Het is ideaal om de meest voorkomende programmeerfouten die bijdragen aan de beveiligingskwetsbaarheden van hun applicatie te verzamelen, zodat ze tijdens het coderen kunnen worden opgevangen.

Dergelijke typische programmeerfouten worden voornamelijk veroorzaakt door bufferoverflows, cross-site scripting en injectiefouten.

Enkele van de typische programmeerkwetsbaarheden zijn:

• SQL-injectie (onjuiste neutralisatie van speciale elementen die in een SQL-opdracht worden gebruikt).
• Geheel getal overloop.
• Bufferoverloop (Bufferkopie zonder de invoergrootte te controleren).
• Tekenreeks met ongecontroleerde indeling.
• Authenticatie en autorisatie ontbreken (onjuiste autorisatie).
• Gevoelige gegevensblootstelling.
• Onjuiste afhandeling van fouten.

Sommige van deze fouten kunnen leiden tot een systeemcrash, onverwachte toegang tot het systeem en het verlies van controle over de software voor de hackers.

Veelvoorkomende programmeerfouten die moeten worden vermeden

Enkele veelvoorkomende programmeerfouten die moeten worden vermeden, worden hieronder vermeld:

• Onjuiste neutralisatie van speciale elementen die worden gebruikt in een SQL-opdracht (‘SQL-injectie’).
• Bufferkopie zonder de invoergrootte te controleren (‘Klassieke bufferoverloop’).
• Ontbrekende verificatie voor kritieke functie.
• Ontbrekende of onjuiste autorisatie.
• Gebruik van hardgecodeerde inloggegevens.
• Ontbrekende versleuteling van gevoelige gegevens.
• Onbeperkte upload van bestand met gevaarlijk type.
• Vertrouwen op niet-vertrouwde input in een beveiligingsbesluit.
• Uitvoering met onnodige rechten.
• Cross-Site Request Forgery (CSRF).
• Downloaden van code zonder integriteitscontrole.
• Onjuiste berekening van buffergrootte.
• Onjuiste beperking van overmatige verificatiepogingen.
• URL-omleiding naar niet-vertrouwde site (‘Open omleiding’).
• Ongecontroleerde opmaakreeks.
• Gebruik van een eenmalige hasj zonder zout.

Checklist voor veilige codepraktijken

Als laatste, maar niet de minste, moeten de ontwikkelaars, na alle bovenstaande punten van Secure Software Development-aspecten in overweging te hebben genomen, het Checklist opgesteld voor de Secure Code Practices om ervoor te zorgen dat er niets over het hoofd wordt gezien. Hieronder zijn er een paar, maar geen volledige lijst.

Invoervalidatie:

• Vertrouw de invoer niet, maar overweeg gecentraliseerde invoervalidatie.
• Vertrouw niet op validatie aan de clientzijde.
• Wees voorzichtig met canonicalisatieproblemen.
• Invoer beperken, afwijzen en opschonen. Valideer op type, lengte, formaat en bereik.

Authenticatie:

• Verdeel de site op anoniem, geïdentificeerd en geverifieerd gebied.
• Gebruik sterke wachtwoorden.
• Ondersteuning voor vervaltijden van wachtwoorden en uitschakeling van accounts.
• Sla geen inloggegevens op (gebruik eenrichtingshash met salt).
• Versleutel communicatiekanalen om authenticatietokens te beschermen.
• Geef formulierauthenticatiecookies alleen door via HTTPS-verbindingen.

Autorisatie:

• Gebruik minst geprivilegieerde accounts.
• Overweeg de granulariteit van autorisaties.
• Scheiding van bevoegdheden afdwingen.
• Beperk gebruikerstoegang tot bronnen op systeemniveau.
• Gebruik het OAuth 2.0-protocol voor verificatie en autorisatie.
• Voer API-validatie uit.
• Toegestane methoden op de witte lijst zetten.
• Bescherm bevoorrechte acties en gevoelige bronverzamelingen.
• Beschermen tegen Cross-site Resource Forgery (CSRF).

Sessiebeheer:

• Maak een sessie-ID op de server.
• Beëindig de sessie met de afmelding.
• Genereer een nieuwe sessie over herauthenticatie.
• Stel het kenmerk ‘secure’ in voor cookies die via TLS worden verzonden.

Cryptografie:

• Gebruik cryptografie tijdens ‘Gegevens onderweg, gegevens in opslag, gegevens in beweging, berichtintegriteit’.
• Ontwikkel niet uw eigen. Gebruik beproefde platformfuncties.
• Houd niet-versleutelde gegevens dicht bij het algoritme.
• Gebruik het juiste algoritme en de juiste sleutelgrootte.
• Vermijd sleutelbeheer (gebruik DPAPI).
• Maak regelmatig gebruik van uw sleutels.
• Bewaar sleutels op een beperkte locatie.

Logboekregistratie en controle:

• Identificeer kwaadaardig gedrag.
• Weet hoe goed verkeer eruitziet.
• Controleer en log activiteiten in alle toepassingslagen.
• Beveiligde toegang tot logbestanden.
• Maak een back-up van de logbestanden en analyseer ze regelmatig.

Uitgangscodering:

• Voer ‘Input Validation (XML, JSON….) Uit.
• Gebruik een geparametriseerde query.
• Voer ‘Schemavalidatie’ uit.
• Voer codering uit (XML, JSON ..).
• Stuur beveiligingskoppen.

Referentie: ​ OWASP-checklist voor veilige coderingspraktijken (Kortom, SCP-checklist) ​

Tabeloverzicht van de checklist voor veilige codering

De onderstaande tabel geeft een overzicht van de ‘Dingen om te onthouden voor veilige code’ van een applicatie.

Gevolgtrekking

We hopen dat deze tutorial uw beste gids is om softwarebeveiliging te garanderen.

De coderingsrichtlijnen voor veilige softwareontwikkeling zijn hier in eenvoudige bewoordingen weergegeven met voorbeelden zodat u het concept gemakkelijk kunt begrijpen.

Veel leesplezier !!

Aanbevolen literatuur

• Beveiligingstests (een complete gids)
• Top 30 BESTE cyberbeveiligingsbedrijven in 2021 (kleine tot grote ondernemingen)
• Basisprincipes van computerprogrammering voor beginners | Zelfstudie over codering
• Top 15 beste gratis code-editors voor een perfecte codeerervaring
• Tutorial SQL-injectie testen (voorbeeld en preventie van SQL-injectieaanvallen)
• Ontwikkelaars zijn geen goede testers. Wat je zegt?
• ISTQB Foundation Examenformaat en richtlijnen om papers op te lossen
• Richtlijnen voor het testen van de beveiliging van mobiele apps