C ++ Programmeren: 10 Anti-Hacker Tips - dummies

Als C ++ -programmeur moet u weten wat u in uw C ++ -code moet doen om te voorkomen dat u programma's schrijft die kwetsbaar zijn voor hackers. Er zijn ook beschreven functies die u kunt inschakelen als uw besturingssysteem ze ondersteunt, zoals Address Space Layout Randomization (ASLR) en Data Execution Prevention (DEP).

Maak geen aannames over gebruikersinvoer

De tunnelvisie van de programmeur is in orde tijdens de vroege ontwikkelingsfase. Op een gegeven moment moet de programmeur (of, beter nog, een andere programmeur die niets te maken heeft met de ontwikkeling van de code) achterover leunen en het onmiddellijke probleem vergeten. Ze moet zichzelf de vraag stellen: "Hoe zal dit programma reageren op illegale invoer? “

Hier volgen enkele regels voor het controleren van invoer:

• Neem geen aannames over de lengte van de invoer.

• Accepteer niet meer invoer dan waarvoor u ruimte heeft in uw buffers met vaste lengte (of gebruikte buffers met variabele grootten).

• Controleer het bereik van elke numerieke waarde om te controleren of dit zinvol is.

• Controleer en filter uit speciale tekens die door een hacker kunnen worden gebruikt om code in te voeren.

• Geef onbewerkte invoer niet door aan een andere service, zoals een databaseserver.

Voer dezelfde controles uit op de waarden die worden geretourneerd door externe services. De hacker bevindt zich mogelijk niet aan de invoerzijde, hij bevindt zich mogelijk aan de responszijde.

Mislukte bewerkingen

Uw programma moet redelijk reageren op storingen die zich binnen het programma voordoen. Als uw aanroep naar een bibliotheekfunctie bijvoorbeeld een nullptr, retourneert, moet het programma dit detecteren en iets redelijks doen.

Redelijke Hier moet redelijk liberaal worden begrepen. Het programma hoeft niet rond te snuffelen om erachter te komen waarom de functie geen redelijk adres heeft opgeleverd. Het kan zijn dat het verzoek te veel geheugen bevatte vanwege onredelijke invoer. Of het kan zijn dat de constructor een soort van illegale invoer heeft gedetecteerd.

Het maakt niet uit. Het punt is dat het programma de staat ervan zo goed mogelijk moet herstellen en moet instellen op het volgende stukje invoer zonder bestaande gegevensstructuren zoals de heap te beschadigen of te corrumperen.

Een programmalogboek onderhouden

Runtime-logboeken maken en onderhouden waarmee iemand kan reconstrueren wat er is gebeurd in het geval van een beveiligingsfout. (Eigenlijk is dit net zo waar in het geval van een fout.) U wilt bijvoorbeeld waarschijnlijk loggen telkens wanneer iemand in of uit uw systeem meldt.

U zult zeker willen weten wie bij uw systeem was aangemeld toen zich een beveiligingsgebeurtenis voordeed - dit is de groep die het grootste risico loopt op een beveiligingsverlies en die het meest achterdochtig zijn bij het zoeken naar schuldigen.Bovendien wilt u eventuele systeemfouten melden die de meeste uitzonderingen bevatten.

Een real-world productieprogramma bevat een groot aantal oproepen die er ongeveer als volgt uitzien:

log (DEBUG, "Gebruiker% s ingevoerd wettelijk wachtwoord", sUser);

Dit is maar een voorbeeld. Elk programma heeft een soort logfunctie nodig. Of het al dan niet log () wordt genoemd, is niet van belang.

Volg een goed ontwikkelingsproces

Elk programma moet een goed doordacht, formeel ontwikkelingsproces volgen. Dit proces moet ten minste de volgende stappen omvatten:

• Collectievereisten en documentvereisten, inclusief beveiligingsvereisten.

• Ontwerp beoordelen.

• Houd u aan een coderingsnorm.

• Test eenheid ondergaan.

• Voer formele acceptatietests uit die zijn gebaseerd op de oorspronkelijke vereisten.

Daarnaast moeten peer reviews worden uitgevoerd op belangrijke punten om te controleren of de vereisten, het ontwerp, de code en testprocedures van hoge kwaliteit zijn en voldoen aan de bedrijfsstandaarden.

Implementeer goede versiebeheer

Versiebeheer is iets vreemds. Het is logisch om je geen zorgen te maken over versie 1. 1 wanneer je onder het pistool zit om versie 1. 0 uit de deur te krijgen en in de uitgestrekte handen van de wachtende gebruikers. Versiebeheer is echter een belangrijk onderwerp dat vroegtijdig moet worden aangepakt, omdat het moet worden ingebouwd in het oorspronkelijke ontwerp van het programma en niet later moet worden vastgezet.

Een bijna triviaal aspect van versiebeheer is weten welke versie van het programma een gebruiker gebruikt. Wanneer een gebruiker oproept en zegt: "Het doet dit wanneer ik erop klik", moet de helpdesk echt weten welke versie van het programma de gebruiker gebruikt. Hij zou in zijn versie een probleem kunnen beschrijven dat al in de huidige versie is opgelost.

Gebruikers veilig verifiëren

Gebruikersverificatie moet eenvoudig zijn: de gebruiker biedt een accountnaam en een wachtwoord en uw programma kijkt de accountnaam in een tabel op en vergelijkt de wachtwoorden. Als de wachtwoorden overeenkomen, wordt de gebruiker geverifieerd. Maar als het gaat om anti-hacking, is niets zo eenvoudig.

Berg de wachtwoorden nooit eerst zelf op in de database. Dit wordt het opslaan van ze in het heldere genoemd en wordt beschouwd als zeer slechte vorm. Het is veel te gemakkelijk voor een hacker om het wachtwoordbestand te bemachtigen. Sla in plaats daarvan een beveiligde transformatie van het wachtwoord op.

Externe sessies beheren

U kunt bepaalde aannames doen als al uw toepassingen op één computer worden uitgevoerd. Om te beginnen, als de gebruiker zich eenmaal heeft geauthenticeerd, hoeft u zich geen zorgen te maken dat hij wordt getransformeerd in een andere persoon. Toepassingen die communiceren met een externe server kunnen deze veronderstelling niet maken - een hacker die aan de lijn luistert, kan wachten totdat de gebruiker zichzelf verifieert en vervolgens de sessie kaapt.

Wat kan de beveiligingsgerichte programmeur doen om deze situatie te voorkomen? U wilt de gebruiker niet herhaaldelijk om zijn wachtwoord vragen om er zeker van te zijn dat de verbinding niet is gehackt. De alternatieve oplossing is om een ​​ -sessie te maken en te beheren. U doet dit door de server een sessiecookie naar de externe toepassing te sturen zodra de gebruiker zichzelf met succes heeft geverifieerd.

Verdoezelen van uw code

Code verduistering is de handeling om het uitvoerbare bestand zo moeilijk mogelijk te maken voor een hacker om het te begrijpen.

De logica is eenvoudig. Hoe eenvoudiger het voor een hacker is om te begrijpen hoe uw code werkt, hoe eenvoudiger het voor de hacker is om kwetsbaarheden te achterhalen.

De eenvoudigste stap die u kunt nemen, is ervoor zorgen dat u alleen een releaseversie van uw programma distribueert die geen foutopsporingssymboolinformatie bevat. Wanneer u het projectbestand voor het eerst maakt, moet u ervoor zorgen dat zowel een foutopsporings- als een releaseversie moet worden gemaakt.

Distribueer nooit, nooit versies van uw applicatie met de meegeleverde symboolinformatie.

Onderteken uw code met een digitaal certificaat

Code ondertekening werkt door een veilige hash van de uitvoerbare code te genereren en te combineren met een certificaat dat is uitgegeven door een geldige certificeringsinstantie. Het proces werkt als volgt: het bedrijf dat het programma maakt, moet zich eerst registreren bij een van de certificaatautoriteiten.

Nadat de certificeringsinstantie overtuigd is dat My Company een geldige software-entiteit is, geeft deze een certificaat af. Dit is een lang nummer dat iedereen kan gebruiken om te verifiëren dat de houder van dit certificaat de beroemde My Company of San Antonio is.

Gebruik veilige encryptie waar nodig

Zoals elke goede waarschuwing heeft deze waarschuwing verschillende delen. Ten eerste: "Gebruik waar nodig codering. "Dit doet vaak denken aan het communiceren van bankrekeninggegevens via internet, maar je moet meer algemeen denken dan dat.

Gegevens die worden gecommuniceerd, via internet of over een kleiner bereik, zijn algemeen bekend als Data in Motion. Data in Motion moet gecodeerd zijn tenzij het voor een hacker geen zin heeft.

Gegevens die op de schijf zijn opgeslagen, staan ​​bekend als Gegevens in rust. Deze gegevens moeten ook worden gecodeerd als de kans bestaat dat de schijf verloren gaat, wordt gestolen of wordt gekopieerd. Bedrijven versleutelen routinematig de harde schijven op hun bedrijfslaptops in het geval dat een laptop wordt gestolen bij de beveiligingsscanner op de luchthaven of ergens in een taxi wordt achtergelaten.

Kleine draagbare opslagapparaten zoals thumb-drives zijn vooral gevoelig voor verlies - gegevens op deze apparaten moeten worden gecodeerd.