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

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:

<script>
   alert('hacked');
</script>

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:

   @{
       var untrustedInput = "<script>alert(1)</script>";
   }
   <script>
       document.write("@untrustedInput");
   </script>

Spowoduje wygenerowanie:

<script>
       document.write("&lt;script&gt;alert(1)&lt;/script&gt;");
</script>

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

public class TestController : Controller
   {
       HtmlEncoder _htmlEncoder;
       JavaScriptEncoder _javaScriptEncoder;
       UrlEncoder _urlEncoder;

       public TestController(HtmlEncoder htmlEncoder,
                             JavaScriptEncoder javascriptEncoder,
                             UrlEncoder urlEncoder)
       {
           this._htmlEncoder = htmlEncoder;
           this._javaScriptEncoder = javascriptEncoder;
           this._urlEncoder = urlEncoder;
       }
   }

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 🙂

Paweł Skaruz