Blog posts

Bezpieczna aplikacja ASP.NET Core (cz. II) – atak XSS

Bezpieczna aplikacja ASP.NET Core (cz. II) – atak XSS

ASP.NET Core Security, Daj Się Poznać 2017, dotnetcore, security

Pora na już drugą cześć cyklu o projektowaniu bezpiecznych aplikacji ASP.NET Core. Dzisiaj opowiem o ataku XSS, czym jest i co zrobić żeby nasza witryna była na niego odporna.

Atak XSS

Czym jest XSS? Najkrócej mówiąc jest atakiem na webaplikacje, polegającym na wstrzyknięciu do przeglądarki złośliwego kodu, najczęściej javascript. Celem atakującego jest inna osoba korzystająca z aplikacji.

Na przykład weźmy prostą aplikację np. bloga. Atakujący umieszcza w komentarzu do artykułu kod javascript:

Następnie taki kod może zostać uruchomiony w przeglądarkach innych osób odwiedzających naszego bloga.

Atak XSS możemy podzielić na dwie grupy:

  • Persistent – złośliwy kod umieszczony zostaje po stronie serwerowej aplikacji (najczęściej w bazie danych); podany wyżej przykład ataku na bloga jest właśnie atakiem persistent xss
  • Reflected – kod javascriptowy umieszczony zostaje w linku, a link następnie jest przesyłany do ofiary; efektem końcowym jest wykonaniu wstrzykniętego kodu w przeglądarce osoby atakowanej

Jakie mogą być skutki ataku?

Atakujący może próbować na przykład

  • uruchomić keylogger w przeglądarce
  • dynamicznie podmienić treść na stronie (tylko front-end)
  • wykraść ciasteczka sesyjne

Jak bronić naszą aplikację?

Jeśli chodzi o kradzież ciasteczek sesyjnych, sprawa jest bardzo prosta i nie wymaga dużo pracy. Wystarczy zastosować parametr HttpOnly w cookiesach. Spowoduje to, że nie będzie możliwy ich odczyt dla skryptów JS.

Jeśli chodzi zaś o samo blokowanie umieszczania złośliwego kodu przez atakującego, to cała rzecz polega na odpowiednim filtrowaniu tego co wysyła użytkownik. Atakujący będzie chciał umieścić kod w znacznikach w jakimś tagu html np. <script> . Musimy więc dane pochodzące od użytkownika odpowiednio enkodować przed umieszczeniem na stronie.

Encodowanie danych w ASP.NET Core

Razor, który jest chyba najczęściej wykorzystywanym enginem w MVC przychodzi z automatycznym enkodowaniem danych. Czyli w standardzie mamy to co w .NET oferowała biblioteka AntiXSS.  O ile używamy znacznika @, to nie musimy się martwić o dane które przesłał nam użytkownik.

Dla przykładu:

Spowoduje wygenerowanie:

Enkodery mogą być również dostępne z poziomu kontrolera poprzez wstrzyknięcie ich przez DI:

Każdy z enkoderów posiada metodę Encode. Jeśli np. chcemy zbudować URL z parametrem pochodzącym od użytkownika powinniśmy użyć UrlEncoder’a.

Widać więc, że w bardzo łatwy i szybki sposób możemy się ochronić przed atakami typu XSS. ASP.NET Core dostarcza nam w standardzie enkoder, więc dopóki używamy @ jesteśmy bezpieczni 🙂

 

About the author

Consultant, developer. Pasjonat programowania rozwijający się przy projektach komercyjnych oraz jako kontrybutor open source. W wolnym czasie lubi pobiegać za piłką, a także obejrzeć dobry film lub serial.

1 Comment

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *