Wann et ëm Enterprise Stack Sécherheet kënnt, sinn Software Uwendungen de schwaachste Link. An De Staat vun der Uwendungssécherheet, 2020, Forrester seet, datt d'Majoritéit vun externen Attacken entweder duerch Ausbeutung vun enger Software Schwachstelle (42%) oder duerch eng Webapplikatioun (35%).
D'Entwéckler sinn ënner Drock fir Features sou séier wéi méiglech ze verëffentlechen, well d'Applikatioune méi komplex ginn an d'Entwécklungszäitlinne schrumpfen. Fir differenzéiert an zwéngend Applikatiounsfunktionalitéit z'erreechen, vertrauen d'Entwéckler ëmmer méi op Drëtt-Parteibibliothéiken.
Dës Verréckelung Richtung Open Source Komponente mécht Sécherheet Praxis méi komplex fir Firmen. Nei Kaderen wéi Container an APIen komplizéiere weider Applikatiounssécherheet.
Mat Entwéckler ënner Drock fir dauernd nei Features ze verëffentlechen, stellen Organisatiounen e ganz reelle Risiko fir d'Sécherheet net ze halen. Sécherheet kann erreecht ginn andeems d'Applikatiounssécherheet bescht Praktiken an de Softwareentwécklungsliewenszyklus integréiert an se ëmsetzen.
Firwat Ass Web Sécherheetstest wichteg?
Testen vun Webapplikatiounen an hir Konfiguratiounen fir Sécherheetsschwieregkeeten ass d'Zil vum Web Sécherheetstest. Applikatiounschichtattacken (dh HTTP-baséiert Uwendungen zielen) sinn déi primär Ziler.
Et ass heefeg fir verschidden Aarte vun Input un eng Webapplikatioun ofzeginn fir Feeler ze provozéieren an se onerwaart ze behuelen. An dëse sougenannten "negativen Tester" gëtt de System iwwerpréift fir Verhalen dat net virgesinn ass.
Et ass och wichteg ze bemierken datt Web Sécherheet Testen ass net nëmmen drëm d'Sécherheetsfeatures ze testen déi an der Applikatioun implementéiert sinn (zB Authentifikatioun an Autorisatioun).
Et ass och néideg ze testen datt aner Funktiounen (zB Geschäftslogik an Input- an Outputvalidatioun) op eng sécher Manéier ëmgesat ginn. Sécheren Zougang zu de Webapplikatiounsfunktiounen ass d'Zil.
Wat sinn déi verschidden Aarte vu Sécherheetstester?
- Dynamic Application Security Test (DAST). Fir Konformitéit mat reglementaresche Sécherheetsbewäertunge, ass dësen automatiséierte Applikatiounssécherheetstest ideal fir intern konfrontéiert, niddereg-Risiko Uwendungen. Eng Kombinatioun vu manuelle Web Sécherheetstesten an DAST ass déi bescht Approche fir mëttel-Risiko Uwendungen a kritesch Uwendungen déi kleng Ännerungen ënnerhalen.
- Statesch Applikatioun Sécherheetstest (SAST). Dës Approche fir Applikatiounssécherheetstester souwuel manuell wéi automatesch. Eng Applikatioun kann op dës Manéier getest ginn ouni se an engem Produktiounsëmfeld ze lafen. Ausserdeem erlaabt et Entwéckler systematesch Software Sécherheetsschwieregkeeten z'entdecken an ze eliminéieren andeems se Quellcode scannen.
- Pénétratioun Test. Besonnesch fir Uwendungen déi grouss Ännerunge maachen, ass dësen manuelle Applikatiounssécherheetstest ideal. Bewäertungen enthalen Geschäftslogik a Géigner-baséiert Tester fir fortgeschratt Attackszenarien ze identifizéieren.
- Runtime Application Self Protection (RASP). Eng Zuel vun technologeschen Technike ginn an dëser evoluéierender Approche zur Applikatiounssécherheet benotzt fir eng Applikatioun esou ze instrumentéieren datt Attacke kënne iwwerwaacht ginn wéi se ausféieren an am Idealfall an Echtzäit blockéiert ginn.
Wéi reduzéiert d'Applikatiounssécherheetstester Är Organisatioun Risiko?
Majoritéit vun Web Applikatioun Attacken
- D'SQL Injektiounstechnik
- Cross-Site Skripting (XSS)
- Ausféierung vu Kommandoen op afstand
- Wee Traversal
Attack Resultater
- Inhalt dee limitéiert ass
- Konten déi kompromittéiert goufen
- Béiswëlleg Software Installatioun
- Akommes verluer
- Clienten verléieren Vertrauen
- Reputation Schued
- Wéi och nach vill méi
D'Webëmfeld vun haut ass ufälleg fir eng breet Palette vu Probleemer. Zousätzlech fir ze wësse wéi eng Applikatioun exploitéiert ka ginn, d'Wësse vun de potenziellen Resultater vum Attack hëlleft Är Firma d'Schwächheeten virauszegesinn a präzis fir se ze testen.
Mitigéierend Kontrollen kënnen an de fréie Stadien vun der SDLC applizéiert ginn nodeems d'Wurzelursaach vun de Schwachstelle identifizéiert gouf. Zousätzlech kann e Webapplikatiounssécherheetstest d'Wësse profitéieren wéi dës Attacke funktionnéieren fir bekannte Punkte vun Interesse ze zielen.
Fir de Risiko vun Ärer Firma ze managen, musst Dir den Impakt vun engem Attack verstoen, well et ka benotzt ginn fir d'total Schwieregkeet vun der Schwachstelle ze moossen.
Als Resultat vun engem Sécherheetstest kann d'Bestëmmung vun der Gravitéit vun detektéierten Themen Iech hëllefen, Sanéierungsefforten effizient an effektiv ze prioritéieren. Miniméiert de Risiko vun Ärer Firma andeems Dir mat Themen vu kritescher Gravitéit ufänkt a weider op Themen mat nidderegen Impakt geet.
Eng potenziell Impaktbewäertung vun all Applikatioun an der Applikatiounsbibliothéik vun Ärer Firma ier Dir en Thema identifizéiert, kann hëllefe mat der Prioritéit vun der Applikatioun Sécherheetstest.
Wann Web Sécherheetstestung eng etabléiert Lëscht vun héichprofiléierten Uwendungen huet, kënne mir den Test plangen fir Är Firma hir kritesch Uwendungen als éischt ze zielen, sou datt de Risiko géint Äert Geschäft reduzéiert ka ginn.
Wéi eng Feature solle wärend engem Webapplikatiounssécherheetstest iwwerpréift ginn?
Verschidde Feature solle wärend der Sécherheetstest vu Webapplikatiounen iwwerpréift ginn, awer d'Lëscht ass net ustrengend. Är Organisatioun kéint e seriöse Risiko ausgesat ginn duerch eng onpassend Ëmsetzung vun all.
- Applikatioun a Server Konfiguratioun- Mängel kënne mat der Verschlësselungskonfiguratioun, Webserverkonfiguratiounen, etc.
- Input Validatioun a Fehlerhandhabung- Déi heefegst Injektiounsschwieregkeeten, dorënner SQL Injektioun a Cross-Site Scripting (XSS), sinn d'Resultat vu schlechten Input an Output Handhabung.
- Authentifikatioun a Sessiounsmanagement- Schwachstelle kënnen zu der Impersonatioun vu Benotzer féieren. Eng staark Umeldungspolitik ass och essentiell.
- Autorisatioun- Verifizéiert d'Fäegkeet vun der Applikatioun fir vertikal an horizontal Privileg Eskalatioun ze vermeiden.
- Business Logik- Dës Zort vu Logik ass wesentlech fir déi meescht Geschäftsapplikatiounen.
- Client-Säit Logik- Dës Zort Feature gëtt ëmmer méi heefeg op modernen, JavaScript-schwéier Websäiten, souwéi Websäiten déi aner Client-Säit Technologien benotzen (zB Silverlight, Flash, Java Applets).
Top 10 Best Practices Fir Web Applikatioun Sécherheet
Folgend sinn déi Top Ten Uwendungssécherheet Best Practices Är Organisatioun sollt scho implementéieren.
# 1 Verfollegt Är Verméigen
Wann Dir net wësst wat Dir hutt, kënnt Dir et net schützen.
Fir wéi eng Funktiounen oder Apps benotzt Dir spezifesch Serveren? A wéi engem Web Apps benotzt Dir Open Source Komponenten?
Denkt Dir datt et net wichteg ass Är Verméigen ze verfolgen? Et ass ganz wichteg ze erënneren wéi eng Software an all Applikatioun leeft - frot just Equifax, deen $ 700 Millioune bestrooft gouf fir d'Date vun iwwer 145 Millioune Clienten net ze schützen.
Ee vun de Cliente Webportale vun der Kredittbewäertungsagentur gouf kompromittéiert nodeems en Open-Source Komponent, Apache Struts, net gepatcht gouf. D'Firma seet datt et net bewosst war datt de Client Portal déi vulnerabel Open Source Komponent benotzt huet.
Wat Dir méi séier ufänkt Är Verméigen ze verfollegen, wat manner Kappwéi a Katastrophen Dir méi spéit hutt. Wéi Organisatiounen hir Entwécklung Skala, kann dëse Prozess wéi eng Sisyphean Aufgab fillen.
Dir sollt och Är Verméigen klassifizéieren, notéiert déi, déi kritesch sinn fir d'Funktioune vun Ärem Geschäft an déi, déi manner wichteg sinn. Da kënnt Dir Bedrohungen beurteelen an se spéider sanéieren.
#2 Maacht eng Bedrohungsbewäertung
Wann Dir eng Lëscht maacht mat deem wat Dir braucht ze schützen, kënnt Dir dann d'Gefore identifizéieren déi Dir konfrontéiert a wéi se ofgeschaaft kënne ginn.
Wéi kéinten Hacker an Är Applikatioun briechen? Wéi eng bestehend Sécherheetsmoossnamen hutt Dir op der Plaz? Wéi eng zousätzlech Tools sinn néideg?
Dir musst dës an aner Froen als Deel vun Ärer Bedrohungsbewäertung beäntweren.
Wéi och ëmmer, Dir musst och realistesch sinn iwwer de Sécherheetsniveau deen Dir kënnt genéissen. Egal wéi sécher Dir Äre System mécht, Dir kënnt et nach ëmmer hacken. Ausserdeem musst Dir éierlech sinn iwwer d'Moossnamen déi Äert Team iwwer Zäit erhalen kann.
Dir kënnt riskéieren datt Är Sécherheetsnormen a Praktiken ignoréiert ginn andeems Dir zevill dréckt. Huelt Sécherheet eescht a presséiert et net.
Benotzt déi folgend Formel fir Äre Risiko ze evaluéieren:
Risiko = Wahrscheinlechkeet vun Attack x Impakt vun Attack.
Risiko kann och geduecht ginn als d'Wahrscheinlechkeet datt eppes geschitt versus d'Gravitéit vun de Konsequenzen.
Och wann et katastrophal wier wann e Wal aus dem Himmel géif falen an dech zerbriechen, ass et onwahrscheinlech datt et geschitt.
Eng Moustiquebiss op enger Wanderung, op der anerer Säit, ass ganz wahrscheinlech, awer net wahrscheinlech bedeitend Schued iwwer e puer juckende Bumpen ze verursaachen.
#3 Bleift um Top vun Ärem Patching
Installéiert déi lescht Patches op Äre Betribssystemer? Benotzt Dir Drëtt Partei Software? D'Chancen sinn datt Dir hannendru sidd, dat heescht datt Dir ausgesat sidd.
Ee vun de wichtegste Schrëtt déi Dir maache sollt fir d'Sécherheet vun Ärer Software ze garantéieren ass d'Software ze aktualiséieren, entweder vun engem kommerziellen Verkeefer oder vun enger Open-Source Gemeinschaft.
Wann eng Schwachstelle entdeckt a verantwortlech un de Produkt- oder Projetbesëtzer gemellt gëtt, gëtt se op Sécherheetsberodungssiten an Datenbanken wéi d'WhiteSource Vulnerability Database publizéiert.
Wa méiglech, sollt e Fix erstallt ginn a virun der Verëffentlechung verëffentlecht ginn, wat d'Benotzer d'Méiglechkeet gëtt hir Software ze sécheren.
Wann Dir awer kee Patch applizéiert wann een verfügbar ass, profitéiert Dir net vun enger verbesserter Sécherheet.
Wann Dir besuergt sidd datt d'Aktualiséierung op déi lescht Versioun Äre Produkt briechen kann, automatiséiert Tools ka vill hëllefen. All Dag vun der Woch sollt Dir d'Aktualiséierung an d'Patchen als Deel vun Ärer Applikatiounssécherheet Best Practices prioritéieren.
# 4 Verwalte Är Container
An de leschte Joeren sinn d'Container an der Popularitéit gewuess wéi méi Organisatiounen d'Technologie adoptéieren wéinst senger Flexibilitéit, déi de Prozess vun der Entwécklung, Testen an Ofbau vun Komponenten iwwer verschidden Ëmfeld am ganze Softwareentwécklungsliewenszyklus (SDLC) vereinfacht.
Et gëtt allgemeng ugeholl datt Container Sécherheetsvirdeeler ubidden, déi hinnen e Virdeel ginn. Zousätzlech, wéinst hirem selbstännegen OS Ëmfeld, gi se vum Design segmentéiert, an doduerch den Niveau vum Risiko erofgesat.
Wéi och ëmmer, Container si weider vulnérabel fir Exploiten wéi e Breakout Attack, an deem d'Isolatioun gebrach ass. Container kënnen och eng Schwachstelle am Code enthalen, deen an hinnen gelagert ass.
Fir CI/CD Pipeline Sécherheet, sollt Dir vun Ufank bis Enn no Schwachstelle scannen, och an Äre Registry.
Zousätzlech zu dëse Scans, bescht Praktiken fir Applikatiounssécherheet beim Schaffen mat Container enthalen och wichteg Aufgaben, wéi z. Microsoft sëlwer.
# 5 Prioritéit Är Sanéierungsops
Et gouf an de leschte Joeren eng ëmmer méi Unzuel u Schwachstelle gewiescht, an dësen Trend weist keng Zeeche fir séier ze verlangsamen.
Dofir sinn d'Entwéckler beschäftegt mat Sanéierung. Fir Teams déi hoffen hir Uwendungen sécher ze halen wärend se verstänneg bleiwen, ass Prioritéit essentiell.
Bedrohungsbewäertunge ginn op Basis vun der Gravitéit vun enger Schwachstelle (CVSS Bewäertung), der Kritizitéit vun der betroffener Applikatioun an enger Rei vun anere Faktoren duerchgefouert.
Dir musst wëssen ob d'Open-Source Schwachstelle tatsächlech Äre propriétaire Code beaflosst wann et ëm Open Source Schwachstelle kënnt.
Ineffektiv an net en héije Risiko och wann d'CVSS Bewäertung vun der vulnérabel Komponent kritesch ass wann et keng Uruff vun Ärem Produkt kritt.
Smart Strategien sinn déi, déi déi dréngendst Gefore fir d'éischt prioritéieren, baséiert op de Faktoren, déi präsent sinn, an déi niddereg-Risiko fir spéider loossen.
#6 Verschlësselen, verschlësselen, verschlësselen
Den OWASP Top 10 huet Verschlësselung vun Daten am Rescht an am Transit fir Joeren abegraff, wat et eng Fuerderung mécht fir all Applikatioun Sécherheet Best Practices Lëscht.
Man-in-the-Mëtt Attacken an aner Forme vun Andréngen kënnen sensibel Donnéeën exponéieren wann Dir net Äre Traffic richteg gespaart hutt.
Wanns du späichere Passwierder a Benotzer-IDen am Kloertext, zum Beispill, setzt Dir Är Clienten a Gefor.
Vergewëssert Iech datt Dir SSL mat engem aktualiséierten Zertifika als Deel vun Ärer Basischecklëscht fir Verschlësselung benotzt. Loosst Iech elo net hannerloossen datt HTTPS de Standard ass. Hashing ass och recommandéiert.
Zousätzlech sollt Dir ni "Är eege Krypto rullen" wéi se soen. Betruecht Sécherheetsprodukter déi vun engem engagéierten Team ënnerstëtzt ginn mat der Erfahrung fir d'Aarbecht richteg ze maachen.
# 7 Managen Privilegien
Dir musst net jiddereen an Ärer Organisatioun Zougang zu alles ginn. Uwendungen an Daten sinn nëmmen zougänglech vun deenen, déi se brauchen, andeems Dir Reseau Sécherheet Best Practices an Applikatioun Sécherheet Best Practices verfollegt.
Et ginn zwee Grënn dofir. Dat éischt wat Dir maache musst ass ze verhënneren datt en Hacker Marketing Umeldungsinformatioune benotzt fir Zougang zu engem System ze kréien deen aner méi sensibel Donnéeën enthält, wéi Finanzen oder legal.
Insider Bedrohungen sinn och eng Suerg, sief et ongewollt - sou wéi e Laptop verléieren oder de falschen Uschloss un eng E-Mail schécken - oder béiswëlleg.
De Prinzip vum mannsten Privileg fir d'Mataarbechter nëmmen d'Donnéeën ze liwweren, déi se brauchen wann et drëm geet fir Zougang zu Daten ze kréien, kéint Är Belaaschtung reduzéieren am Verglach mat keng Kontrollen op der Plaz.
#8 Embrace Automation for Your Vulnerability Management
D'Sécherheet vun hiren Uwendungen ass an de leschte Joren ëmmer méi wichteg fir Entwéckler ginn, besonnesch wann et ëm Aufgaben wéi Schwachstellemanagement geet.
Fir d'Sécherheet lénks Verréckelung unzegoen, testen Entwécklerteams fréi an dacks, drécken esou vill vun hire Sécherheetskontrollen fréi am Entwécklungsprozess wann et méi einfach a méi bëlleg ass Schwachstelle ze fixéieren.
Fir den ongewollten Testprozess ze managen wéinst der grousser Quantitéit vu Schwachstelle, erfuerderen d'Entwéckler automatiséiert Tools.
Fir potenziell Sécherheetsschwieregkeeten an Ärem propriétaire Code ze fannen, kënne statesch Applikatiounssécherheetstest (SAST) an dynamesch Applikatiounssécherheetstest (DAST) während der Entwécklung agestallt ginn.
Sécherheetslächer si mat SASTs an DASTs zougemaach, awer propriétaire Code mécht e relativ klengen Deel vun Ärem Gesamtcode aus.
A méi wéi 92% vun all modernen Uwendungen maachen Open-Source Komponenten 60-80% vun Ärer Codebase aus. Är Applikatioun Sécherheetschecklëscht sollt Prioritéit fir Open Source Komponenten ze sécheren.
Mat Software Zesummesetzung Analyse Tools kënnen Teams automatiséiert Sécherheetschecken a Berichter am ganze SDLC lafen, all Open Source Komponent an hirer Ëmwelt identifizéieren an unzeginn wéi eng vun hinnen eng bekannte Schwachstelle huet déi e Sécherheetsrisiko fir Är Uwendungen ausmécht.
Dir kënnt Är Schwachstelle besser verwalten andeems Dir Är automatiséiert Tester fir Open Source Sécherheetsprobleemer no lénks verréckelt.
# 9 Pénétratiounstest
Eng Top Applikatioun Sécherheet Best Practices Lëscht wier onkomplett ouni Pen Testen ze ernimmen, och wann automatiséiert Tools hëllefen déi grouss Majoritéit vu Sécherheetsprobleemer ze fangen.
Testen mat Pen a Pabeier erlaabt Iech Är App ze pochen an ze prodéieren fir Schwächen ze fannen. Wann e bestëmmten Hacker probéiert an Är Applikatioun ze briechen, wësse gutt Pen Tester genee wéi eng Schrëtt se maache mussen.
Hackingfirmen kënnen agestallt ginn oder Freelancer kënnen u Bug Bounty Programmer wéi BugCrowd an HackerOne deelhuelen. Är Firma soll e Bug Bounty sponseren wann Dir dat net scho maacht.
Wann Dir Pen-Tester astellen, ass et vill besser fir se ze bezuelen wéi mat de Konsequenze vun enger realer Verstouss ze këmmeren.
#10 Sidd virsiichteg mat Tokens
Trotz der Tatsaach datt dëst einfach ass ze sécheren, si vill Entwéckler hir Tokens net richteg fir Drëtt Parteien ofsécheren.
Andeems Dir populär Entwéckler Websäiten sicht, kënnt Dir einfach onsécher Tokens online fannen. Amplaz Token Detailer soss anzwousch ze späicheren, enthalen d'Entwéckler se einfach an hiren Open-Source Repositories.
Eng Basis Applikatioun Sécherheet Best Praxis ass Är Drëtt Partei Tokens richteg ze sécheren. Dir sollt keng Tokens, déi Dir kaaft hutt, an Ärem Code leien fir jiddereen ze huelen.
Applikatioun Sécherheet Best Practices als Basis Praktiken
Jiddwer vun de beschten Praktiken, déi hei beschriwwe sinn, sollen an de kontinuéierleche Entwécklungsprozess vun Ärer Organisatioun integréiert ginn. D'Applikatiounen an d'Date vun Ärer Firma sinn a Gefor wann Dir de Risiko net miniméiert. Follegt dës Schrëtt fir de Risiko ze minimiséieren.
D'Feeler ze vermeiden déi anerer méiglecherweis maachen ass ee Wee fir virun Hacker ze bleiwen, sou datt Dir méi schwéier sidd fir Attacken ze zielen. Et wäert ni e Perimeter oder Applikatiounssécherheetsmoossnam sinn, déi voll hackbeständeg ass.
Wéi och ëmmer, dës grondleeënd bescht Praktiken ze verfollegen kënnen e laange Wee goen fir Är Applikatioun net wäert ze halen fir d'Hacker.
