ASP.NET MVC - SQL -injeksjon

Det er mange typer angrep som vi kan motta i applikasjonene våre. En av de vanligste og som kan forårsake store skader er SQL -injeksjonDette angrepet består i å finne sårbarheter i måten vi håndterer søk mot databaser for å trekke ut informasjon eller sette inn verdier som kan påvirke funksjonaliteten.
For å beskytte oss mot denne typen angrep må vi først vite hva det består av, på denne måten kan vi lære hva slags forholdsregler vi må ta.
Som vi nevnte, gjør dette angrepet at databasen vår ikke fungerer som den skal. For dette introduserer angriperen data som får våre søk til å mislykkes i henhold til visse sårbarheter, med dette kan angriperen prøve få skjemaene av tabellene våre eller angi data som kan kompromittere operasjonen, for eksempel skriv inn en bruker for å få tilgang til den administrative delen av applikasjonen vår.
En av de vanligste måtene er at vi angir parametere direkte når vi mottar dem fra kontrollerne, for eksempel har vi et søk etter kategorier og vi mottar fra kontrolleren identifikatoren for en kategori som skal søkes, hvis den passerer direkte uten å rense den kan generere et angrep som viser angriperen alle eksisterende kategorier.
La oss se på følgende usikre kode:

FORSTØRRE

Vi kan se hvordan i linje 6 vi bygger søkebetingelsen og deretter i linje 10 Vi sender den direkte til metoden som bygger spørringen, et uerfarent øye ser kanskje ikke noe problem, men hvis en angriper angir følgende parameter: "1 eller 1 = 1" du kan få oversikten over hele bordet vårt.
Hvordan beskytte oss selv?Måten å beskytte oss selv på i dette tilfellet går gjennom to grunnleggende trinn, først er at vi ikke kan tillate data å bli utført direkte etter hvert som vi mottar dem, for dette, før spørringen, må vi rense parameteren med en metode som søker etter ulovlige tegn, og i tilfelle vi finner dem, sender brukeren til en 404 side eller side ikke funnet.
La oss se i følgende kode hvordan vi kan filtrere det vi mottar:

Her gjennomgår vi med en vanlig setning La bare tall være det kontrolleren vår mottar, ellers sender vi en melding, alle kan lage sin versjon, men det viktige er å kontrollere hva applikasjonen vår vil motta.
De sekund trinn for å unngå angrep er ikke arbeide med jokertegnet "*" og begrenser alltid spørsmålene når vi venter på en post, på denne måten unngår vi å avsløre alle dataene i tilfelle noen klarer å overskride prognosene våre.
Fang unntakTil slutt, hvis en ulovlig parameter kommer inn i applikasjonen vår, må vi for enhver pris unngå at et spor av feilen kommer ut, siden den har sensitive data fra vår installasjon og kan brukes mot oss, derfor må vi alltid sørge for å fange opp unntak og send en personlig melding som ikke inneholder mange detaljer, siden disse detaljene kan sees i utviklingsmiljøet.
Som vi kunne se, gir det å kjenne angrepene oss et annet perspektiv på hvordan vi kan beskytte applikasjonen vår og hvordan vi kan gjøre for å gi brukerne mer sikkerhet.Likte og hjalp du denne opplæringen?Du kan belønne forfatteren ved å trykke på denne knappen for å gi ham et positivt poeng