ASP.NET MVC - SQL-injectie

Er zijn veel soorten aanvallen die we in onze applicaties kunnen ontvangen, een van de meest voorkomende en die een grote hoeveelheid schade kunnen veroorzaken, is de SQL injectieDeze aanval bestaat uit het vinden van kwetsbaarheden in de manier waarop we query's op databases behandelen om informatie te extraheren of waarden in te voegen die de functionaliteit ervan kunnen beïnvloeden.
Om ons te beschermen tegen dit soort aanvallen, moeten we eerst weten waar het uit bestaat, op deze manier kunnen we leren welke voorzorgsmaatregelen we moeten nemen.
Zoals we al zeiden, zorgt deze aanval ervoor dat onze database niet goed werkt, hiervoor introduceert de aanvaller gegevens die onze zoekopdrachten doen mislukken volgens bepaalde kwetsbaarheden, hiermee kan de aanvaller proberen krijg de schema's van onze tabellen of voer gegevens in die de werking in gevaar kunnen brengen, zoals: voer een gebruiker in om toegang te krijgen tot het administratieve gedeelte van onze applicatie.
Een van de meest gebruikelijke manieren is dat we parameters rechtstreeks invoeren zoals we ze van de controllers ontvangen, we zoeken bijvoorbeeld op categorieën en we ontvangen van de controller de identificatie van een categorie die moet worden doorzocht, als deze direct voorbijgaat zonder deze op te schonen kan een aanval genereren die de aanvaller alle bestaande categorieën laat zien.
Laten we eens kijken naar de volgende onveilige code:

VERGROTEN

We kunnen zien hoe in de lijn 6 we bouwen de zoekvoorwaarde en dan in de lijn 10 We geven het rechtstreeks door aan de methode die de query maakt, een onervaren oog ziet misschien geen probleem, maar als een aanvaller de volgende parameter invoert: "1 of 1 = 1" je zou de lijst van onze hele tafel kunnen krijgen.
Hoe onszelf te beschermen?De manier om onszelf in dit geval te beschermen, gaat door twee basisstappen, de eerst is dat we niet kunnen toestaan ​​dat gegevens direct worden uitgevoerd zoals we ze ontvangen, hiervoor moeten we, vóór de query, de parameter opschonen met een methode die zoekt naar illegale tekens en in het geval dat ze worden gevonden, de gebruiker naar een 404-pagina sturen of pagina niet gevonden.
Laten we in de volgende code kijken hoe we kunnen filteren wat we ontvangen:

Hier beoordelen we met een gewone zin Laat alleen cijfers zijn wat onze controller ontvangt, anders sturen we een bericht, iedereen kan zijn versie maken, maar het belangrijkste is om te bepalen wat onze applicatie zal ontvangen.
De tweede stap om aanvallen te voorkomen is werk niet met het jokerteken "*" en beperk altijd de vragen wanneer we wachten op een record, op deze manier voorkomen we dat alle gegevens worden vrijgegeven voor het geval iemand erin slaagt onze voorspellingen te overtreffen.
Vang uitzonderingenTen slotte, als een illegale parameter onze applicatie binnenkomt, moeten we koste wat kost voorkomen dat een spoor van de fout naar buiten komt, aangezien deze gevoelige gegevens van onze installatie bevat en tegen ons kan worden gebruikt. Daarom moeten we er altijd voor zorgen dat de uitzonderingen en stuur een gepersonaliseerd bericht dat niet veel details bevat, aangezien deze details te zien zijn in de ontwikkelomgeving.
Zoals we konden zien, geeft het kennen van de aanvallen ons een ander perspectief op hoe we onze applicatie kunnen beschermen en hoe we onze gebruikers meer veiligheid kunnen bieden.Vond je deze Tutorial leuk en heb je eraan geholpen?Je kunt de auteur belonen door op deze knop te drukken om hem een ​​positief punt te geven