security testing
Applicatiebeveiliging testen - Testtechnieken voor de beveiliging van web- en desktopapplicaties
De behoefte aan beveiligingstests?
De software-industrie heeft in deze tijd een solide erkenning gekregen. In het afgelopen decennium lijkt de cyberwereld echter nog meer te domineren en de drijvende kracht te zijn die de nieuwe vormen van bijna elk bedrijf vormgeeft. Webgebaseerde ERP-systemen die tegenwoordig worden gebruikt, zijn het beste bewijs dat IT een revolutie teweeg heeft gebracht in ons geliefde wereldwijde dorp.
Tegenwoordig zijn websites niet alleen bedoeld voor publiciteit of marketing, maar deze zijn ontwikkeld tot sterkere tools om tegemoet te komen aan de zakelijke behoeften.
Webgebaseerde salarisadministratiesystemen, winkelcentra, banken, aandelenhandel worden niet alleen door organisaties gebruikt, maar worden tegenwoordig ook als producten verkocht.
Dit betekent dat online applicaties het vertrouwen van klanten en gebruikers hebben gewonnen met betrekking tot hun essentiële functie genaamd SECURITY.
Ongetwijfeld is de beveiligingsfactor ook van primair belang voor desktoptoepassingen.
Als we het echter over internet hebben, neemt het belang van beveiliging exponentieel toe. Als een online systeem de transactiegegevens niet kan beschermen, zal niemand er ooit aan denken om deze te gebruiken. Veiligheid is nog geen woord dat op zoek is naar de definitie ervan, en het is ook geen subtiel concept. Ik wil echter graag enkele complimenten over beveiliging noemen.
beste dvd-ripsoftware voor mac
Voorbeelden van beveiligingsfouten in een applicatie
- Een studentenbeheersysteem is onveilig als de ‘Admission’ branch de gegevens van de ‘Exam’ branch kan bewerken
- Een ERP-systeem is niet veilig als DEO (data entry operator) ‘Rapporten’ kan genereren
- Een online winkelcentrum heeft geen beveiliging als de creditcardgegevens van de klant niet versleuteld zijn
- Aangepaste software beschikt over onvoldoende beveiliging als een SQL-query de werkelijke wachtwoorden van zijn gebruikers ophaalt
Veiligheid
Nu presenteer ik u de eenvoudigste definitie van beveiliging in mijn eigen woorden.
'Beveiliging betekent dat geautoriseerde toegang wordt verleend tot beschermde gegevens en ongeautoriseerde toegang wordt beperkt'
Het heeft dus twee belangrijke aspecten; de eerste is de bescherming van gegevens en de tweede is toegang tot die gegevens. Bovendien, of de applicatie nu desktop- of webgebaseerd is, draait beveiliging om de twee bovengenoemde aspecten.
Laten we een overzicht hebben van de beveiligingsaspecten voor zowel desktop- als webgebaseerde softwareapplicaties.
Wat je leert:
Testen van desktop- en webbeveiliging
Een desktoptoepassing moet niet alleen veilig zijn wat betreft de toegang, maar ook wat betreft de organisatie en opslag van de gegevens.
Evenzo vereist webapplicatie, zelfs meer, beveiliging met betrekking tot de toegang, samen met gegevensbescherming. Een webontwikkelaar moet de applicatie immuun maken voor SQL Injections, Brute Force Attacks en XSS (cross-site scripting). Evenzo, als de webtoepassing externe toegangspunten mogelijk maakt, moeten deze ook veilig zijn.
Houd er bovendien rekening mee dat Brute Force Attack niet alleen gerelateerd is aan webapplicaties, ook desktopsoftware is hier kwetsbaar voor.
Ik hoop dat dit voorwoord genoeg is en laat me nu ter zake komen. Aanvaard alstublieft mijn verontschuldigingen als u tot nu toe dacht dat u over het onderwerp van dit artikel leest. Hoewel ik de softwarebeveiliging en de belangrijkste zorgen ervan kort heb uitgelegd, is mijn onderwerp ‘Beveiligingstests’.
Aanbevolen literatuur => Testen van beveiliging van webapplicaties
Ik zal nu uitleggen hoe de kenmerken van beveiliging worden geïmplementeerd in softwareapplicaties en hoe deze moeten worden getest. Mijn focus zal liggen op wat en hoe van beveiligingstests, niet op beveiliging.
Aanbevolen hulpprogramma's voor beveiligingstests
#1) Netsparker
Netsparker is een oplossing voor het testen van de beveiliging van webtoepassingen met mogelijkheden voor automatisch crawlen en scannen voor alle soorten verouderde en moderne webtoepassingen, zoals HTML5, Web 2.0 en Single Page Applications. Het maakt gebruik van Proof-Based Scanning Technology en schaalbare scanmiddelen.
Het geeft u volledige zichtbaarheid, ook al heeft u een groot aantal activa te beheren. Het heeft veel meer functionaliteiten zoals teambeheer en kwetsbaarheidsbeheer. Het kan worden geïntegreerd in de CI / CD-platforms zoals Jenkins, TeamCity of Bamboo.
Probeer de beste Netsparker-beveiligingstesttool#twee) Kiuwan
Zoek en los kwetsbaarheden in uw code op in elke fase van de SDLC.
Kiuwan voldoet aan de strengste beveiligingsnormen, waaronder OWASP, CWE, SANS 25, HIPPA en meer. Integreer Kiuwan in uw IDE voor directe feedback tijdens de ontwikkeling. Kiuwan ondersteunt alle belangrijke programmeertalen en kan worden geïntegreerd met toonaangevende DevOps-tools.
Scan uw code gratis# 3) Indusface WAS gratis website malwarecontrole
Indusface WAS biedt zowel handmatige penetratietesten gebundeld met zijn eigen geautomatiseerde kwetsbaarheidsscanner voor webtoepassingen die kwetsbaarheden detecteert en rapporteert op basis van OWASP top 10 als een website-reputatiecontrole van links, malware en defacementcontroles van de website bij elke scan
Voer gratis een snelle websitescan uit
Neem contact op om hier een vermelding voor te stellen.
Lijst met 8 beste beveiligingstesttechnieken
# 1) Toegang tot de applicatie
Of het nu een desktop-applicatie is of een website, toegangsbeveiliging wordt geïmplementeerd door ‘Rollen en rechtenbeheer’. Het wordt vaak impliciet gedaan terwijl het functionaliteit omvat,
Bijvoorbeeld, in een ziekenhuisbeheersysteem maakt een receptionist zich het minst zorgen over de laboratoriumtests, aangezien het zijn taak is om alleen de patiënten te registreren en hun afspraken met artsen te plannen.
Dus alle menu's, formulieren en schermen met betrekking tot laboratoriumtests zullen niet beschikbaar zijn voor de rol van ‘receptionist’. Daarom garandeert de juiste implementatie van rollen en rechten de toegangsbeveiliging.
Hoe te testen: Om dit te testen, moeten alle rollen en rechten grondig worden getest.
De tester moet verschillende gebruikersaccounts maken met verschillende en meerdere rollen. Vervolgens moet hij de applicatie gebruiken met behulp van deze accounts en controleren of elke rol alleen toegang heeft tot zijn eigen modules, schermen, formulieren en menu's. Als de tester een conflict constateert, moet hij een beveiligingsprobleem in alle vertrouwen registreren.
Dit kan ook worden begrepen als authenticatie- en autorisatietesten, wat heel mooi wordt weergegeven in de onderstaande afbeelding:
Dus eigenlijk moet u testen over ‘wie u bent’ en ‘wat u kunt doen’ voor verschillende gebruikers.
Enkele van de authenticatietests omvatten een test voor wachtwoordkwaliteitsregels, test voor standaardaanmeldingen, test voor wachtwoordherstel, test captcha, test voor uitlogfunctionaliteit, test voor wachtwoordwijziging, test voor beveiligingsvraag / antwoord, enz.
Evenzo omvatten enkele van de autorisatietests een test voor paddoorgang, test voor ontbrekende autorisatie, test voor horizontale toegangscontroleproblemen, enz.
# 2) Gegevensbescherming
Er zijn drie aspecten van gegevensbeveiliging. De eerste is dat een gebruiker kan alleen de gegevens bekijken of gebruiken die hij geacht wordt te gebruiken Dit wordt ook verzekerd door rollen en rechten
Bijvoorbeeld, TSR (telesalesvertegenwoordiger) van een bedrijf kan de gegevens van de beschikbare voorraad inzien, maar kan niet zien hoeveel grondstof er is ingekocht voor productie.
Dus dit aspect van beveiligingstesten is hierboven al uitgelegd. Het tweede aspect van gegevensbescherming heeft betrekking op hoe die gegevens worden opgeslagen in de database
Verder lezen = >> Wat is databasebeveiligingstests
wat kun je doen met c ++
Alle gevoelige gegevens moeten worden gecodeerd om ze te beveiligen. Versleuteling moet sterk zijn, vooral voor gevoelige gegevens zoals wachtwoorden van gebruikersaccounts, creditcardnummers of andere bedrijfskritische informatie.
Het derde en laatste aspect is een uitbreiding van dit tweede aspect. De juiste beveiligingsmaatregelen moeten worden genomen wanneer de stroom van gevoelige of bedrijfskritische gegevens zich voordoet. Of deze gegevens nu tussen verschillende modules van dezelfde applicatie zweven of naar verschillende applicaties worden verzonden, ze moeten worden versleuteld om ze veilig te houden.
Gegevensbescherming testen: De tester moet in de database zoeken naar ‘wachtwoorden’ van het gebruikersaccount, factureringsinformatie van klanten, andere bedrijfskritische en gevoelige gegevens en moet controleren of al deze gegevens in gecodeerde vorm in de database worden opgeslagen.
Evenzo moet hij verifiëren dat gegevens worden verzonden tussen verschillende formulieren of schermen na alleen de juiste versleuteling. Bovendien moet de tester ervoor zorgen dat de gecodeerde gegevens correct worden gedecodeerd op de bestemming. Er moet speciale aandacht worden besteed aan verschillende ‘indienen’ acties.
De tester moet verifiëren dat wanneer de informatie wordt verzonden tussen de client en de server, deze niet in een begrijpelijk formaat wordt weergegeven in de adresbalk van een webbrowser. Als een van deze verificaties mislukt, heeft de applicatie zeker een beveiligingsfout.
De tester moet ook controleren op het juiste gebruik van salting (door een extra geheime waarde toe te voegen aan de eindinvoer, zoals een wachtwoord, waardoor het sterker en moeilijker te kraken wordt).
Onveilige willekeur moet ook worden getest, aangezien het een soort kwetsbaarheid is. Een andere manier om gegevensbescherming te testen, is door te controleren op zwak algoritmegebruik.
Bijvoorbeeld, aangezien HTTP een clear-text-protocol is, vormt het een bedreiging voor de toepassingsbeveiliging als de gevoelige gegevens zoals gebruikersreferenties via HTTP worden verzonden. In plaats van HTTP moeten gevoelige gegevens worden overgedragen via HTTPS (beveiligd via SSL, TLS-tunnel).
HTTPS vergroot echter het aanvalsoppervlak en daarom moet worden getest of de serverconfiguraties correct zijn en de geldigheid van het certificaat is gegarandeerd.
# 3) Aanval met brute kracht
Brute Force Attack wordt meestal gedaan door sommige softwaretools. Het concept is dat door een geldige gebruikers-ID te gebruiken, de s oftware probeert het bijbehorende wachtwoord te raden door steeds opnieuw in te loggen.
Een eenvoudig voorbeeld van beveiliging tegen een dergelijke aanval is het opschorten van een account voor een korte periode, zoals alle mailtoepassingen zoals ‘Yahoo’, ‘Gmail’ en ‘Hotmail’ doen. Als een bepaald aantal opeenvolgende pogingen (meestal 3) niet lukt om met succes in te loggen, wordt dat account enige tijd geblokkeerd (30 minuten tot 24 uur).
Hoe Brute-Force Attack te testen: De tester moet controleren of een of ander mechanisme voor accountopschorting beschikbaar is en correct werkt. (S) Hij moet proberen om in te loggen met ongeldige gebruikers-ID's en wachtwoorden om er zeker van te zijn dat de softwaretoepassing de accounts blokkeert als continue pogingen worden gedaan om in te loggen met ongeldige inloggegevens.
Als de applicatie dit doet, is deze beveiligd tegen brute-force-aanvallen. Anders moet dit beveiligingslek door de tester worden gemeld.
Testen op brute kracht kan ook worden onderverdeeld in twee delen: black box-testen en grey-box-testen.
Bij Black box-tests wordt de authenticatiemethode die door de applicatie wordt gebruikt, ontdekt en getest. Bovendien zijn de grey box-tests gebaseerd op gedeeltelijke kennis van wachtwoord- en accountgegevens en geheugenaanvallen.
Klik hier om brute krachttests van black box en grey box te verkennen, samen met voorbeelden.
Met de bovenstaande drie beveiligingsaspecten moet rekening worden gehouden voor zowel web- als desktopapplicaties, terwijl de volgende punten alleen betrekking hebben op webgebaseerde applicaties.
# 4) SQL-injectie en XSS (cross-site scripting)
Conceptueel gezien is het thema van beide hackpogingen vergelijkbaar, dus deze worden samen besproken. In deze benadering is het kwaadaardig script wordt door hackers gebruikt om een website te manipuleren
Er zijn verschillende manieren om tegen dergelijke pogingen immuun te zijn. Voor alle invoervelden van de website moeten veldlengtes klein genoeg zijn om de invoer van een script te beperken
matrixsjabloon voor traceerbaarheid van vereisten met voorbeeld
Bijvoorbeeld, De achternaam moet een veldlengte hebben van 30 in plaats van 255. Er kunnen enkele invoervelden zijn waar grote gegevensinvoer nodig is. Voor dergelijke velden moet de juiste validatie van de invoer worden uitgevoerd voordat die gegevens in de toepassing worden opgeslagen.
Bovendien moeten in dergelijke velden alle HTML-tags of het invoeren van scriptlabels worden verboden. Om XSS-aanvallen uit te lokken, moet de applicatie scriptomleidingen van onbekende of niet-vertrouwde applicaties negeren.
Hoe test SQL-injectie en XSS: De tester moet ervoor zorgen dat de maximale lengte van alle invoervelden is gedefinieerd en geïmplementeerd. (S) Hij moet er ook voor zorgen dat de gedefinieerde lengte van invoervelden niet geschikt is voor zowel scriptinvoer als taginvoer. Beide kunnen eenvoudig worden getest
Bijvoorbeeld, Als 20 de maximale lengte is die is opgegeven voor het veld ‘Naam’ en de invoertekenreeks ‘
thequickbrownfoxjumpsoverthelazydog ”kan beide beperkingen verifiëren.
De tester moet ook verifiëren dat de applicatie geen anonieme toegangsmethoden ondersteunt. Als een van deze kwetsbaarheden bestaat, is de toepassing in gevaar.
In principe kunnen SQL-injectietests op de volgende vijf manieren worden uitgevoerd:
- Detectie technieken
- Standaard SQL-injectietechnieken
- Vingerafdruk de database
- Technische exploitatie
- Handtekeninginvasietechnieken voor SQL-injectie
Klik hier om in detail te lezen over de bovenstaande manieren om SQL-injectie te testen.
XSS is ook een soort injectie die een kwaadaardig script in een website injecteert. Klik hier om diepgaand te kijken naar testen voor XSS.
# 5) Servicetoegangspunten (verzegeld en beveiligd open)
Tegenwoordig zijn bedrijven afhankelijk van en werken ze met elkaar samen, hetzelfde geldt voor applicaties, met name websites. In dat geval moeten beide medewerkers enkele toegangspunten voor elkaar definiëren en publiceren.
Tot dusver lijkt het scenario vrij eenvoudig en duidelijk, maar voor sommige webgebaseerde producten, zoals aandelenhandel, zijn de dingen niet zo eenvoudig en gemakkelijk.
Als er een groot aantal doelgroepen is, moeten de toegangspunten voldoende open zijn om alle gebruikers te faciliteren, voldoende ruimte bieden om aan alle verzoeken van gebruikers te voldoen en voldoende veilig zijn om elke beveiligingsproef te doorstaan.
Servicetoegangspunten testen: Laat me het uitleggen met de voorbeeld van de webapplicatie voor aandelenhandel; een belegger (die de aandelen wil kopen) moet toegang hebben tot actuele en historische gegevens over aandelenkoersen. De gebruiker moet de mogelijkheid krijgen om deze historische gegevens te downloaden. Dit vereist dat de applicatie voldoende open moet zijn.
Met accommoderend en veilig bedoel ik dat de applicatie investeerders in staat moet stellen vrijelijk te handelen (volgens de wettelijke voorschriften). Ze kunnen 24/7 kopen of verkopen en de transactiegegevens moeten immuun zijn voor elke hackaanval.
Bovendien zal een groot aantal gebruikers tegelijkertijd met de applicatie communiceren, dus de applicatie moet voldoende toegangspunten bieden om alle gebruikers te vermaken.
In sommige gevallen zijn deze toegangspunten kunnen worden verzegeld voor ongewenste toepassingen of mensen Dit hangt af van het zakelijke domein van de applicatie en zijn gebruikers,
Bijvoorbeeld, Een op maat gemaakt webgebaseerd Office Management Systeem kan zijn gebruikers herkennen op basis van IP-adressen en weigert een verbinding tot stand te brengen met alle andere systemen (applicaties) die niet binnen het bereik van geldige IP's voor die applicatie vallen.
De tester moet ervoor zorgen dat alle inter-netwerk en intra-netwerktoegang naar de applicatie is door vertrouwde applicaties, machines (IP's) en gebruikers.
Om te verifiëren dat een open toegangspunt voldoende veilig is, moet de tester proberen toegang te krijgen vanaf verschillende machines met zowel vertrouwde als niet-vertrouwde IP-adressen. Om een goed vertrouwen te hebben in de prestaties van de app, moeten verschillende soorten realtime transacties in bulk worden geprobeerd. Hierdoor wordt ook de capaciteit van accesspoints van de applicatie duidelijk geobserveerd.
De tester moet ervoor zorgen dat de applicatie alle communicatieverzoeken van vertrouwde IP's en applicaties alleen ontvangt, terwijl alle andere verzoeken worden afgewezen.
Evenzo, als de applicatie een open toegangspunt heeft, moet de tester ervoor zorgen dat het (indien nodig) uploaden van gegevens door gebruikers op een veilige manier mogelijk maakt. Op deze veilige manier bedoel ik over de bestandsgroottelimiet, bestandstypebeperking en het scannen van het geüploade bestand op virussen of andere beveiligingsbedreigingen.
Dit is allemaal hoe een tester de veiligheid van een applicatie kan verifiëren met betrekking tot zijn toegangspunten.
# 6) Sessiebeheer
Een websessie is een opeenvolging van de HTTP-verzoek- en reactietransacties die aan dezelfde gebruiker zijn gekoppeld. De sessiebeheertests controleren hoe sessiebeheer wordt afgehandeld in de webapp.
U kunt testen op het verlopen van de sessie na een bepaalde inactieve tijd, beëindiging van de sessie na maximale levensduur, beëindiging van de sessie na uitloggen, controleren op het bereik en de duur van sessiecookies, testen of een enkele gebruiker meerdere gelijktijdige sessies kan hebben, enz.
# 7) Foutafhandeling
Testen op foutafhandeling omvat:
Controleer op foutcodes Bijvoorbeeld, test 408 time-out verzoek, 400 ongeldige verzoeken, 404 niet gevonden, enz. Om deze te testen, moet u bepaalde verzoeken aan de pagina doen zodat deze foutcodes worden geretourneerd.
De foutcodes worden geretourneerd met een gedetailleerd bericht. Deze berichten mogen geen kritische informatie bevatten die kan worden gebruikt voor hackdoeleinden
Controleer op stapelsporen : Het omvat in feite het geven van een aantal uitzonderlijke input aan de applicatie, zodat het geretourneerde foutbericht stack-traces bevat die interessante informatie bevatten voor hackers.
# 8) Specifieke risicovolle functionaliteiten
De twee risicovolle functionaliteiten zijn voornamelijk betalingen en uploads van bestanden Deze functionaliteiten moeten zeer goed worden getest. Voor het uploaden van bestanden moet u in de eerste plaats testen of het uploaden van ongewenste of schadelijke bestanden beperkt is.
Voor betalingen moet u voornamelijk testen op injectiekwetsbaarheden, onveilige cryptografische opslag, bufferoverflows, wachtwoord raden, enz.
Neem contact op om hier een vermelding voor te stellen.Verder lezen:
- Beveiligingstests van webapplicaties
- Top 30 interviewvragen over beveiligingstests
- Verschil tussen SAST / DAST / IAST / RASP
- SANS Top 20 beveiligingsproblemen
Aanbevolen literatuur
- Handleiding voor het testen van webapplicaties
- Alfatesten en bètatesten (een complete gids)
- ETL-testen Tutorial datawarehouse-testen (een complete gids)
- Netwerkbeveiligingstests en de beste hulpprogramma's voor netwerkbeveiliging
- Beginnershandleiding voor penetratietesten van webapplicaties
- Build Verification Testing (BVT Testing) Complete Guide
- Functioneel testen versus niet-functioneel testen
- Een complete gids voor penetratietesten met voorbeeldtestcases