Riktlinjer för säker kodning och bästa metoder för utvecklare

secure coding guidelines

Denna handledning förklarar säker kodning, hur man undviker säkerhetsrelaterade säkerhetsproblem, och ger kodningsriktlinjer och checklista för säker kodningspraxis:

För att få säkerhet inbyggd i programvaran och för att implementera Secure Coding Guidelines and Best Practices, måste hela organisationen tillsammans med teamet som identifierats för att arbeta med den avsedda applikationsutvecklingen överväga vissa aspekter.

Här kommer vi att diskutera de aspekter som hjälper till att utveckla en säker programvara.

Det är så enkelt som om en utvecklare inte vet vad som menas med ”Säkerhet för programvaran” och hur en hackare kan hacka sin programvara, ta kontroll över den och försöka utnyttja är det helt enkelt omöjligt att koda en säker programvara. Så utvecklaren måste först förstå innebörden av Secure Coding.

Vad du kommer att lära dig:

• Vad är säker kodning?
  • Riskreducering
  • Orsaker till otillräcklig säkerhetsimplementering
• Riktlinjer för säker kodning
  • Språkval för säker kodning
  • Säkra kodningsregler och rekommendationer
  • Vanliga programmeringsfel som ska undvikas
• Checklista för säker kod
  • Tabellöversikt över säker kodlista
• Slutsats
  • Rekommenderad läsning

Vad är säker kodning?

Säker kodning är att designa och utveckla programvara av undvika svagheterna som leder till säkerhetsrelaterade sårbarheter genom att följa de angivna säkerhetsstandarderna och branschens bästa praxis.

Den allra första frågan som uppstår i allas sinne är ”Hur mycket säkerhet krävs för vår programvara” eller När kan vi säga att vår programvara är säker? och Vilka är dessa säkerhetsstandarder ?

Bedrägerier och säkerhetshot ökar dag för dag och vi ser nya varianter och sätt att hacka, även i den så kallade mest säkra programvaran.

Nyligen hörde vi att UIDAIs Aaadhar-program blev manipulerat för personuppgifter. Därför är det verkligen svårt att veta hur mycket säkerhet som krävs för programvaran och vilka säkerhetsstandarder som är om vi inte förstår hoten med programvaran och prioriterar dem baserat på riskerna för verksamheten.

överföra array till metod i Java

Det kan vara svårt att ge 100% säkerhetsskydd till programvaran, men om programteamet analyserar Risker och värdepapper som är inblandade i deras programvara, dvs. potentiella hot, och om teamet kan ta hand om att mildra dessa risker, skulle det vara bra från applikationens säkerhetspunkt.

Således är teamets allra första uppgift att identifiera och analysera de risker och säkerheter som är involverade i deras tillämpning och förstå de möjliga begränsningsalternativen och anta det bästa alternativet därefter.

Så när de en gång identifierats klassificerar de tio bästa sårbarheterna nästan alla de attacker som ett program sannolikt kommer att möta. Detta kommer att bidra till att förstå hoten och prioritera säkerhets- och utvecklingsinsatserna mer mot förebyggande än motverkande.

T.ex. Medan vi planerar att utveckla en hälsorelaterad app, som hanterar och lagrar individens hälsodata och deras personliga information, är den högsta säkerhetsrisken för applikationen att stjäla personlig hälsoinformation.

Riskreducering

För att mildra risken,

• Implementering av säkerhet för åtkomst till data av en obehörig användare måste hanteras med korrekt autentisering och auktorisering (starka lösenordspolicyimplementeringar, 2-faktor autentisering).
• Försiktighet måste iakttas för att se till att det inte finns någon dataläckage under överföring av data från en källa till en annan källa genom att implementera säkra kanaler (HTTPS) för dataöverföring och implementera datakryptering under transitering.
• Att manipulera eller stjäla data i vila är också en annan möjlighet. Därför är lagring av personlig hälsodata (med hjälp av kryptering) mycket viktigt.

Innan du går till ”Secure Coding Standard” är det alltid bättre för hela programteamet att ha en ”Säkerhetsmedvetenhetssession” och diskutera och brainstorma om,

• Kravet på säkerhet för deras specifika produkt.
• Möjliga fördelar som en hackare skulle ha genom att hacka sitt system.
• Möjliga sätt och medel för kompromisser med deras applikation.
• Vanliga säkerhetspraxis följde i en liknande bransch och domän.
• Förståelse för typiska säkerhetsfrågor i deras respektive program.

Det hjälper också teamet att hantera bättre, om de kan förstå Sårbarhetens källor som deras programvara kan möta och orsakerna till vilka programvaran är byggd med Dålig / otillräcklig säkerhet .

Orsaker till otillräcklig säkerhetsimplementering

I allmänhet är följande några skäl till otillräcklig säkerhetsimplementering i applikationen.

• Prioritering ges för funktionella utsläpp än säkerhetsaspekter.
• Okunnighet eller ingen medvetenhet om programvarusäkerhet och hackare.
• Inte tillräckligt med tydlighet om programmet eller själva programvarudesignen.
• Programmets komplexitet.
• Inte tillräckligt med data, information om live-systemet där den kommer att distribueras.
• Ingen övervägande av säkerhet i SDLC-faserna.
• Otillräcklig kunskap och förståelse för det specifika språket som används i programvaran.
• Inte tillräckligt med kunskap för teamet och utvecklarna om riktlinjer för säkerhetskodning.

Vi vet att det inte är så att alla utvecklare och testare är medvetna om säkerheten för en applikation och kanske inte har en djupgående förståelse för säkerhetssårbarheter och exploateringar, särskilt inte för den applikation som de skulle arbeta med. Generellt sett kommer de att känna till, ”Hur kodar jag funktionellt” men inte alla vet ”Hur man kodar säkert”.

Därför är den mycket viktiga aspekten för organisationen att använda Secure Coding Practices i sin programvara att först 'Träna människor' . Så det är väldigt viktigt att utbilda sitt team om säker kodningsaspekter, bästa säkerhetskodningspraxis och korrekt verktygsanvändning.

Den viktigaste designprincipen för mjukvarusäkerhet är att ”Implementera säkerhet genom design och standard” .

Riktlinjer för säker kodning

För att uppnå säkerhet är det mycket viktigt att ha en ”Säker kodningsstandard” identifierades för ett program i början av applikationsutvecklingen, och detta hjälper teamet att ta hand om Secure Defaults för programvaran och hjälpa till att skydda den från attackerna.

Det är viktigt att se till att hela laget är Tvingas följa denna standard , oavsett kodningsspråket och de verktyg de använder i programmet.

Nedan följer några exempel som behöver implementeras som standard i den säkra koddesignen:

• Åtkomst bör endast begränsas till autentiserade användare och autentisering måste implementeras i varje lager.
• Kommunikationskanalerna måste krypteras för att skydda autentiseringstoken.
• Alla nycklar, lösenord och certifikat måste lagras och skyddas ordentligt.
• Filkryptering, databaskryptering och kryptering av dataelement måste implementeras.

Språkval för säker kodning

Språkvalet för kodning kanske inte är beroende av säker kodning. Det finns inget specifikt som ett säkert eller oskyddat språk för kodning för att bygga en säker programvara.

Det är bara hur vi använder ett programmeringsspråk för att bygga programvaran och hur mycket fördjupad kunskap utvecklaren har om kodningsspråket för att implementera säkerhetsaspekter.

Det klargörs dock dock Säkra kodningsstandarder är oberoende av valet av språk, bästa praxis för säker kod är språkberoende, plattformberoende och implementeringsberoende .

För att ha en säker kod är det därför viktigt för utvecklaren att ha fördjupade kunskaper om språket som används i programmet, så att bästa praxis för säkerhet enkelt kan implementeras.

Exempel:

• Sannolikheten för buffertöverskridande sårbarhet skiljer sig från språk till språk, men C, C ++ och Assembly anses vara mest mottagliga på grund av deras föråldrade minneshanteringsfunktioner. Flera standard C lib-funktioner, till exempel strcpy () och memcpy (), är sårbara för buffert-överflödsattacker. Felaktig användning av dessa funktioner genom att kopiera en källbuffert som är för stor för att passa in i målbufferten resulterar i buffertöverflöd.
• Det vanliga problemet i Java-baserade webbapplikationer är möjliga resursläckor som kan uppstå på grund av öppna systemresurser, till exempel en fil-, sockel- och databasanslutning.

Nästa aspekt av säkerhet handlar om verktyg som ska användas i applikationsprogrammet för att optimera säkerheten med hjälp av verktyg som Integrerade utvecklingsmiljöer kommer att vara mest fördelaktigt eftersom de ger mycket Varningar användare och uppmärksamma dessa varningar för att försöka förbättra kvaliteten på programvaran.

• Integrering av kommersiella bibliotek / öppen källkodsbibliotek / plugins som Eclipse, Spring Tool Suite, RAD med IDE hjälper utvecklarna att skriva säker kod genom att upptäcka och identifiera potentiellt sårbar kod och ger varningar om resultat relaterade till skadlig filkörning, informationsläckage och felaktig hantering av fel.

Det är också viktigt att använda Statiska och dynamiska analysatorer för att förbättra säkerhetsaspekterna av programvaran. Generellt är statiska analysatorer optimerade för specifika feltyper, så de hamnar i att hitta ett stort antal falska positiva saker medan de identifierar specifika fel. Ibland finns det möjligheter att de saknar de faktiska felen också.

Därför rekommenderas att använda flera statiska analysatorer för att få bättre täckning av olika typer av fel och för att undvika många falska positiva effekter. Ibland rekommenderas det också att utföra manuell testning till eliminera falska positiva .

Säkra kodningsregler och rekommendationer

Det är bra för programmet att definiera en uppsättning ”Säkra kodningsregler och rekommendationer” till vilken källkoden kan utvärderas för överensstämmelse så att testarna kan utföra 'Testning av överensstämmelse med överensstämmelse' för var och en av dessa säkra kodningsstandarder.

Därför kan säkerhetskoden certifieras som överensstämmande eller ej överensstämmande med dessa regler mot det fastställda riktmärket.

Få av reglerna som nämns nedan kan användas för att kontrollera säkerhetsöverträdelser:

• Filer måste stängas när de inte längre behövs.
• När du passerar en struktur över en gräns måste informationsläckage undvikas.
• Objekt ska deklareras med lämplig lagringstid.

Så testfall för att verifiera dessa regler måste utformas och utföras för att kontrollera överensstämmelsen. Det identifieras också att de flesta sårbarheter orsakas av typiska vanliga programmeringsfel.

Därför måste utvecklaren förstå ”Osäker kodningsmetod” , medan de också lär sig de bästa metoderna för Secure Coding. Det är perfekt att samla in de vanligaste programmeringsfelen som bidrar till säkerhetsproblemen i deras applikation så att de kan tas om hand medan de kodas.

Sådana typiska programmeringsfel har huvudsakligen bidragit från buffertöverflöden, skriptöverföring och injektionsfel.

Några av de typiska sårbarheterna i programmeringen inkluderar,

• SQL-injektion (felaktig neutralisering av specialelement som används i ett SQL-kommando).
• Heltals överflöde.
• Buffertöverflöd (buffertkopia utan att kontrollera storleken på ingången).
• Okontrollerad formatsträng.
• Autentisering och auktorisering saknas (felaktig auktorisering).
• Känslig exponering av data.
• Felaktig hantering av fel.

Några av dessa fel kan leda till systemkrasch, oförutsedd åtkomst till systemet och kontrollen av programvaran förloras för hackarna.

Vanliga programmeringsfel som ska undvikas

Några vanliga programmeringsfel som behöver undvikas listas nedan:

• Felaktig neutralisering av specialelement som används i ett SQL-kommando ('SQL Injection').
• Buffertkopia utan att kontrollera storleken på ingången (”Classic Buffer Overflow”).
• Autentisering saknas för kritisk funktion.
• Saknad eller felaktig auktorisering.
• Användning av hårdkodade referenser.
• Kryptering av känsliga data saknas.
• Obegränsad uppladdning av fil med farlig typ.
• Tillit till otillförlitliga ingångar i ett säkerhetsbeslut.
• Utförande med onödiga privilegier.
• Cross-Site Request Forgery (CSRF).
• Nedladdning av kod utan integritetskontroll.
• Felaktig beräkning av buffertstorlek.
• Felaktig begränsning av alltför stora autentiseringsförsök.
• URL-omdirigering till otillförlitlig webbplats (”Öppna omdirigering”).
• Okontrollerad formatsträng.
• Användning av en envägs hash utan salt.

Checklista för säker kod

Sist, men inte minst, efter att ha beaktat alla ovanstående punkter i Secure Software Development aspekter, måste utvecklarna följa Checklista upprättad för Secure Code Practices för att se till att saker inte missas. Nedan följer några men inte en uttömmande lista.

Ingångsvalidering:

• Lita inte på input, överväg centraliserad inputvalidering.
• Lita inte på validering på klientsidan.
• Var försiktig med kanoniseringsfrågor.
• Begränsa, avvisa och desinficera inmatning. Validera för typ, längd, format och intervall.

Autentisering:

• Partitionswebbplats efter anonymt, identifierat och autentiserat område.
• Använd starka lösenord.
• Stöd lösenords utgångsperioder och inaktivera konto.
• Förvara inte referenser (använd envägs hash med salt).
• Kryptera kommunikationskanaler för att skydda autentiseringstoken.
• Passera formulärautentiseringscookies endast via HTTPS-anslutningar.

Tillstånd:

• Använd minst privilegierade konton.
• Överväg auktoritetsgranularitet.
• Tillämpa separering av privilegier.
• Begränsa användarens tillgång till resurser på systemnivå.
• Använd OAuth 2.0-protokollet för autentisering och auktorisering.
• Carryout API Validation.
• Vitlista tillåtna metoder.
• Skydda privilegierade åtgärder och känsliga resurssamlingar.
• Skydda mot förfalskning över flera platser (CSRF).

Sessionshantering:

• Skapa en sessionsidentifierare på servern.
• Avsluta sessionen med Logoff.
• Generera en ny session om re-autentisering.
• Ställ in 'säkert' attribut för kakor som överförs via TLS.

Kryptografi:

• Använd kryptografi under ”Data under transport, Data i lagring, Data i rörelse, Meddelandeintegritet”.
• Utveckla inte din egen. Använd beprövade plattformsfunktioner.
• Håll okrypterad data nära algoritmen.
• Använd rätt algoritm och nyckelstorlek.
• Undvik nyckelhantering (använd DPAPI).
• Cykla dina nycklar regelbundet.
• Förvara nycklar på en begränsad plats.

Loggning och granskning:

• Identifiera skadligt beteende.
• Vet hur bra trafik ser ut.
• Granska och logga aktivitet genom alla applikationsnivåer.
• Säker åtkomst till loggfiler.
• Säkerhetskopiera och analysera regelbundet loggfilerna.

Utgångskodning:

• Carryout ‘Input Validation (XML, JSON….).
• Använd parametrerad fråga.
• Genomför ”Schemavalidering”.
• Utför kodning (XML, JSON ..).
• Skicka säkerhetsrubriker.

Referens: '' OWASP Secure Coding Practices Checklist (Kort sagt SCP-checklista) ''

Tabellöversikt över säker kodlista

Tabellen nedan sammanfattar ”Saker att komma ihåg för säker kod” av en ansökan.

Slutsats

Vi hoppas att den här guiden blir din bästa guide för att säkerställa programvarusäkerhet.

Kodningsriktlinjerna för säker mjukvaruutveckling listades här i enkla termer med exempel för att du enkelt ska förstå konceptet.

Glad läsning!!

Rekommenderad läsning

• Säkerhetstestning (En komplett guide)
• Topp 30 BÄSTA cybersäkerhetsföretag år 2021 (små företag till företagsnivå)
• Grunderna i datorprogrammering för nybörjare Kodningshandledning
• Topp 15 bästa gratis kodredigerare för perfekt kodningsupplevelse
• SQL Injection Testing Tutorial (Exempel och förebyggande av SQL Injection Attack)
• Utvecklare är inte bra testare. Vad du säger?
• ISTQB Foundation Exam Format och riktlinjer för att lösa papper
• Riktlinjer för testning av mobilapps säkerhet