ASP.NET MVC - SQL -injektion

Det finns många typer av attacker som vi kan få i våra applikationer, en av de vanligaste och som kan generera en stor skada är SQL -injektionDenna attack består av att hitta sårbarheter i det sätt vi hanterar frågor mot databaser för att extrahera information eller infoga värden som kan påverka dess funktionalitet.
För att skydda oss mot denna typ av attack måste vi först veta vad den består av, på så sätt kan vi lära oss vilken typ av försiktighetsåtgärder vi måste vidta.
Som vi nämnde gör denna attack att vår databas inte fungerar korrekt, för detta introducerar angriparen data som gör att våra frågor misslyckas enligt vissa sårbarheter, med detta kan angriparen försöka få schemat av våra tabeller eller ange data som kan äventyra operationen, t.ex. ange en användare för att komma åt den administrativa delen av vår applikation.
Ett av de vanligaste sätten är att vi anger parametrar direkt när vi tar emot dem från kontrollerna, till exempel har vi en sökning efter kategorier och vi får från kontrollern identifieraren för en kategori som ska sökas, om den passerar direkt utan att rengöra den kan generera en attack som visar angriparen alla befintliga kategorier.
Låt oss titta på följande osäkra kod:

FÖRSTORA

Vi kan se hur i rad 6 vi bygger sökvillkoret och sedan i rad 10 Vi skickar det direkt till metoden som bygger frågan, ett oerfaret öga kanske inte ser några problem, men om en angripare anger följande parameter: "1 eller 1 = 1" du kan få listan över hela vårt bord.
Hur skyddar vi oss själva?Sättet att skydda oss i det här fallet går igenom två grundläggande steg, först är att vi inte kan tillåta data att köras direkt när vi tar emot den, för detta måste vi innan frågan rengöra parametern med en metod som söker efter olagliga tecken och om de hittar dem, skicka användaren till en 404 -sida eller sidan hittas inte.
Låt oss se i följande kod hur vi kan filtrera det vi får:

Här granskar vi med en vanlig fras Låt bara siffror vara vad vår controller får, annars skickar vi ett meddelande, alla kan göra sin version, men det viktiga är att kontrollera vad vår applikation kommer att få.
De andra steg för att undvika attacker är fungerar inte med jokertecken "*" och begränsa alltid frågorna när vi väntar på en post, på så sätt undviker vi att avslöja all data om någon lyckas överskrida våra prognoser.
Fånga undantagSlutligen, om en olaglig parameter kommer in i vår applikation, måste vi till varje pris undvika att ett spår av felet kommer ut, eftersom det har känslig data från vår installation och kan användas mot oss, därför måste vi alltid se till att fånga undantag och skicka ett personligt meddelande som inte innehåller många detaljer, eftersom dessa detaljer kan ses i utvecklingsmiljön.
Som vi kunde se ger oss ett annat perspektiv på hur vi kan skydda vår applikation och hur vi gör för att ge våra användare mer säkerhet.Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng