6 Web Backend-beveiligingsrisico’s waarmee rekening moet worden gehouden bij de ontwikkeling

Neem maatregelen in ontwikkeling om uw webbackend te beveiligen en te beveiligen.


Kleine bedrijven, banken en veel industrieën zijn afhankelijk van webapplicaties. Vanaf het moment dat u een webapplicatie bouwt, is het cruciaal om zeker te zijn dat u protocollen heeft om kwetsbaarheden te controleren terwijl de ontwikkeling evolueert om beveiligingsinbreuken, datalekken en financiële problemen te voorkomen.

De gevaarlijkste webaanvallen zijn aanvallen op de server waar gegevens worden opgeslagen en geanalyseerd.

Wat is Backend?

Een webapplicatie bestaat uit twee delen: frontend en backend.

  • De frontend is client-side, het is het deel waarmee de gebruiker communiceert. Meestal is het gebouwd met HTML, CSS en Javascript.
  • De backend is server-side. Het is eigenlijk hoe de applicatie werkt, de bedrijfslogica, wijzigingen en updates toepast. Enkele van de populaire technische stacks op de server omvatten PHP, NodeJS, Java, Ruby, C, Python, database, beveiliging (authenticatie, toegangscontrole, enz.), Structuur en inhoudsbeheer.

Een kleine herinnering voordat we beginnen – authenticatie, toegangscontrole & sessiebeheer

Het is normaal dat we de voorwaarden door elkaar halen. Laten we het dus snel verduidelijken:

  • Authenticatie betreft het bewijzen van de identiteit van de gebruiker (bijv. Wachtwoord, gebruikersnaam, vragenbeveiliging, vingerafdrukken)
  • Toegangscontrole betreft wat de gebruiker toegang heeft tot de applicatie. Het dwingt het beleid af dat gebruikers niet kunnen handelen buiten hun beoogde rechten.
  • Sessiebeheer heeft betrekking op reacties en verzoektransacties die aan dezelfde gebruiker zijn gekoppeld. Het is een uitwisselingsmechanisme dat wordt gebruikt tussen de gebruiker en de applicatie nadat deze met succes is geverifieerd.

Laten we het volgende onderzoeken voor een betere back-end webbeveiliging.

Injectiefouten

Sinds 2010 heeft OSWAP injectie geclassificeerd als het meest gevaarlijke risico voor webapplicaties.

Door injectiefouten kan een gebruiker gegevens verstrekken die trefwoorden bevatten die het gedrag van op de database gebouwde zoekopdrachten zullen veranderen. Stel dat we een SQL-script hebben dat controleert of er een overeenkomend item in de database bestaat.

uname = request.POST [‘gebruikersnaam’]
passwd = request.POST [‘wachtwoord’]
sql = "SELECT ID VAN gebruikers WAAR gebruikersnaam = ‘" + je naam + "’AND wachtwoord =’" + passwd + "’"
database.execute (sql)

Een aanvaller kan nu het wachtwoordveld manipuleren met behulp van SQL-injectie, bijvoorbeeld door het wachtwoord ‘OR 1 =’ 1 in te voeren, wat leidt tot de volgende SQL-query:

sql = "SELECT ID van gebruikers WAAR gebruikersnaam = ” EN wachtwoord = ‘wachtwoord’ OF 1 = ‘1’

Hierdoor heeft de aanvaller toegang tot alle gebruikerstabellen van de database, waarbij het wachtwoord altijd geldig is (1 = ‘1’). Als ze inloggen als beheerder, kunnen ze de gewenste wijzigingen aanbrengen.

Hoe je dit kunt voorkomen?

Het is heel GEMAKKELIJK om injectiefouten te voorkomen.

De beste en eenvoudigste manier om te controleren of er geen injectiefouten zijn, is een grondige handmatige broncodebeoordeling om te controleren of zoekopdrachten in de database worden gedaan via voorbereide verklaringen. U kunt ook tools gebruiken om te controleren op kwetsbaarheden.

En je moet ook het volgende doen.

  • ORM’s gebruiken (Object Relational Mapping Tools).
  • Ontsnap aan alle invoer. Een datumveld mag nooit iets anders bevatten dan datums.
  • Isoleer uw gegevens zodat alleen de dingen die vanaf een bepaalde locatie toegankelijk moeten zijn, op die locatie worden bewaard.
  • Schrijf goede foutcodes voor afhandeling. Maak uw database of uw backend niet te uitgebreid.

Troy Hunt kreeg een briljante cursus over SQL-injectie. Als je geïnteresseerd bent, kun je dat onderzoeken.

Gebroken authenticatie

Zoals eerder vermeld, behandelt authenticatie de verstrekte referenties. Het is de frontlinie van verdediging tegen onbeperkte toegang. Een slechte implementatie en het niet respecteren van het beveiligingsbeleid kan echter leiden tot verbroken authenticatie.

Gebroken authenticatie gebeurt meestal door drie patronen:

  • Referenties vulling: waarbij de aanvaller een lijst met geldige gebruikersnamen en wachtwoorden heeft en de aanval kan automatiseren om te achterhalen of de inloggegevens geldig zijn.
  • Bruteforce-aanval: waarbij de applicatie zwakke wachtwoorden toestaat voor gebruikers of beheerders.
  • Sessie kapen: waar applicatie sessie-ID, URL onthult of niet draait na inloggen.

In alle gevallen kan de aanvaller toegang krijgen tot een belangrijk account en afhankelijk zijn van het bedrijf dat witwassen van geld, identiteitsdiefstal of wettelijk beschermde, zeer gevoelige informatie kan vrijgeven.

Hoe je dit kunt voorkomen?

Voordat u het authenticatiesysteem implementeert, moet u zich afvragen: wat kan een aanvaller bereiken als het authenticatiesysteem is gecompromitteerd?

En volgens het antwoord kunt u het volgende doen.

  • Implementeer multi-factor authenticatie om geautomatiseerde aanvallen te voorkomen.
  • Stimuleer (of dwing) de gebruiker om een ​​goed wachtwoordbeleid te hanteren.
  • Beperk mislukte aanmeldingen.
  • Gebruik efficiënte algoritme-hash. Houd bij het kiezen van een algoritme rekening met de maximale wachtwoordlengte.
  • Test het sessietime-outsysteem en zorg ervoor dat het sessietoken ongeldig wordt gemaakt na het uitloggen.

Kapotte toegangscontrole

Toegangscontrole bestaat om ervoor te zorgen wat geauthenticeerde gebruiker mag doen. Verificatie en sessiebeheer zijn de basis of toegangscontroleregels. Maar als die regels niet goed zijn ingesteld, kan dit tot grote problemen leiden.

Veelvoorkomende gebreken in toegangscontrole zijn:

  • CORS-verkeerde configuratie waardoor ongeautoriseerde API-toegang mogelijk is.
  • Manipulatie van metagegevens om de toegang tot methoden te sturen.
  • Gedwongen browsen: de aanvaller probeert een URL, wijzigt paden (bijv. Http: //website.domain/user/ naar http: //website.domain/admin) en kan zelfs belangrijke bestanden ontdekken.

Hoe je dit kunt voorkomen?

Meestal ontstaan ​​gebroken toegangsgebreken door onwetendheid over de essentiële vereisten van effectief toegangsbeheer.

  • Standaard weigeren, behalve openbare middelen.
  • Schakel de directorylijst van de server uit en zorg ervoor dat er geen back-upbestanden zijn.
  • Snelheidslimiet API-toegang om de impact van geautomatiseerde aanvallen te verminderen.
  • JWT-tokens ongeldig maken na uitloggen op de backend-zijde.

Gegevensblootstelling

Ook wel gegevenslekken genoemd, is gegevensblootstelling een cyberdreiging die bedrijven en hun klanten bedreigt.

Het treedt op wanneer de applicatie informatie zoals referenties of gevoelige gegevens zoals creditcards of medische dossiers niet afdoende beschermt. Er zijn meer dan 4000 records breekt elke minuut.

De impact op het bedrijfsleven is groot vanuit financieel oogpunt: een gemiddelde inbreuk kan volgens de gegevens 3,92 miljoen dollar kosten IBM.

Hoe je dit kunt voorkomen?

Als backend-ontwikkelaar moet u zich afvragen wat de informatie is die moet worden beschermd.

En om dergelijke gebreken te voorkomen:

  • Gevoelige gegevens versleutelen: versleutel alles voor gegevens op REST. Gebruik voor beveiligde gegevens beveiligde gateways (SSL)
  • Identificeer de gegevens die extra bescherming vereisen en beperk de toegankelijkheid tot slechts een aantal legitieme gebruikers alleen door op sleutels gebaseerde codering af te dwingen.
  • Vermijd een zwak coderingsalgoritme: gebruik up-to-date en sterke algoritmen.
  • Zorg voor een veilig back-upschema.

Onveilige deserialisatie

Serialisatie en deserialisatie zijn concepten die worden gebruikt wanneer gegevens worden geconverteerd in objectindeling om te worden opgeslagen of naar een andere toepassing te worden verzonden. Serialisatie bestaat uit het converteren van gegevens in objectformaat zoals XML of JSON om ze bruikbaar te maken. Deserialisatie is precies het omgekeerde proces.

Aanvallen op deserializers kunnen leiden tot denial-of-service, toegangscontrole en uitvoering van externe code-uitvoering (RCE) als er klassen zijn die kunnen worden gewijzigd om het gedrag te veranderen.

Het tweede voorbeeld van het OWASP top 10-document geeft een goede illustratie van PHP-object serializer:

a: 4: {i: 0; i: 132; i: 1; s: 7:"Mallory"; i: 2; s: 4:"gebruiker";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Dit is een supercookie die informatie bevat zoals gebruikers-ID, het niveau van de gebruiker en het gehashte wachtwoord.

Een aanvaller kan het geserialiseerde object wijzigen om toegang te krijgen tot beheerdersrechten:

a: 4: {i: 0; i: 1; i: 1; s: 5:"Alice"; i: 2; s: 5:"beheerder";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Hoe je dit kunt voorkomen?

Het is van cruciaal belang om seriedragende objecten van niet-vertrouwde bronnen niet te accepteren.

Je zou ook moeten:

  • Vertrouw nooit gebruikersinvoer.
  • Gegevens valideren: als uw toepassing, behalve een tekenreeks, een tekenreeks is voordat u deze gebruikt
  • Gebruik een vinkje om er zeker van te zijn dat de gegevens niet zijn gewijzigd. Het is handig dat u gegevens verzendt tussen twee vertrouwde bronnen (bijv. Gegevensclient-zijde opslaan).

Server XSS

Server XSS (Cross-site scripting) is een type injectie wanneer een aanvaller een webtoepassing gebruikt om schadelijke code naar verschillende gebruikers te sturen. Het treedt op wanneer de aanvaller een aantal vervaardigde gegevens plaatst die schadelijke code bevatten die door de toepassing wordt opgeslagen. Dit beveiligingslek is serverzijdig; de browser geeft het antwoord gewoon weer.

In een forum worden gebruikersposts bijvoorbeeld vaak zonder verificatie in een database opgeslagen. Aanvallers maken van deze gelegenheid gebruik om berichten met schadelijke scripts toe te voegen. Vervolgens ontvangen andere gebruikers deze link per e-mail of zien ze het betreffende bericht en klikken erop.

Hoe je dit kunt voorkomen?

Na primaire identificatie van alle operaties die mogelijk het risico lopen op XSS en die moeten worden beschermd, moet u het volgende overwegen.

  • Invoer valideren: controleer op invoerlengte, gebruik regex-matching en laat alleen een bepaalde set tekens toe.
  • Uitvoer valideren: als de toepassing kopieert naar zijn antwoorden op gegevensitems die afkomstig zijn van een gebruiker of een derde partij, moeten deze gegevens HTML-gecodeerd zijn om mogelijk schadelijke tekens te verwijderen.
  • Limiet HTML toestaan: als u bijvoorbeeld een blogsysteem voor opmerkingen heeft, staat u alleen het gebruik van bepaalde tags toe. Als je kunt, gebruik dan een geschikt raamwerk voor door de gebruiker aangeleverde HTML-opmaak om te proberen ervoor te zorgen dat het geen middelen bevat om JavaScript uit te voeren.

Conclusie

De ontwikkelingsfase is cruciaal voor de beveiliging van webapplicaties. En u zou moeten overwegen om een ​​scanner voor beveiligingsproblemen in de ontwikkelingslevenscyclus op te nemen, zodat de geïdentificeerde problemen voorafgaand aan de productie worden opgelost.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map