Browsing Category

security

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

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:

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 🙂

 

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

Bezpieczna aplikacja ASP.NET Core (cz. I) – atak CSRF

Gdy zaczynałem przygodę z aplikacjami webowymi, nie sądziłem, że istnieje aż tyle zagrożeń, na które trzeba zwrócić uwagę. Współczesne frameworki dają same w sobie wiele zabezpieczeń i o niektóre rzeczy nie musimy się już troszczyć. Jestem jednak pewny, że bardzo ważna jest świadomość niebezpieczeństwa na jakie są wystawione nasze aplikacje, a co dalej idzie nasi klienci.

Tutaj narodził się pomysł serii „Bezpieczna aplikacja ASP.NET Core”. W każdej z części chciałbym opisać zagrożenie oraz sposób w jaki się przed nim bronić. Bez owijania w bawełnę czas na pierwsze z nich – atak CSRF.

Czym jest CSRF?

Cross-site request forgery (CSRF lub XSRF) – jest to metoda ataku na serwis internetowy. Ofiarami tego ataku stają się często użytkownicy, którzy nieświadomie przesyłają do serwera żądania spreparowane przez inne osoby. Zazwyczaj celem ataku jest wykorzystanie uprawnień ofiary do wykonania operacji w systemie.

Cechy, które charakteryzują ten atak to:

  • Zazwyczaj dotyczą serwisów, które wymagają zalogowania się
  • Niewidoczne zmuszenie użytkownika (jego przeglądarki) do wykonania żądania HTTP
  • Żądanie polega na wykonaniu w jego imieniu jakiejś operacji zmieniającej stan systemu

Przykład ataku:

ASP.NET Antiforgery, czyli obrona

ASP.NET Core zawiera pakiet pod nazwą Antiforgery, który zapewnia ochronę przed atakami CSRF. Pakiet ten implementuje rozwiązanie oparte na tokenach, zalecane przez organizację OWASP. Specyfikacja tego zalecenia znajduje się tutaj.

W skrócie polega ono na mechanizmie wykorzystującym token set (2 tokeny). Powinny się one znaleźć w każdym zapytaniu trafiającym do walidatora Antiforgery. Set składa się z:

  • Tokenu przechowywanego w formie ciasteczka; jest on pseudolosowy i zaszyfrowany przy użyciu Data Protection API
  • Drugiego tokenu, który powinien znaleźć się w polu formularza, nagłówku żądania lub w innym ciasteczku

Tokeny generowane są po stronie serwera i zwracane do przeglądarki podczas odpowiedzi HTTP.

Walidator Antiforgery odrzuci request jeśli:

  • wygenerowane wartości tokenów się nie zgadzają
  • którykolwiek z tokenów nie został przesłany w odpowiedzi

Jak korzystać z pakietu Antiforgery?

Pakiet Microsoft.AspNetCore.Antiforgery jest dostępny jako zależność pakietu Microsoft.AspNetCore.Mvc. Otrzymujemy go w standardzie tworząc aplikację ASP.NET MVC. Serwisy Antiforgery są automatycznie rejestrowane wraz z serwisami MVC, czyli podczas wywołania  services.addMvc() w metodzie  Startup.ConfigureServices() .

Zacznijmy od początku, czyli generowania tokenów. Dobra wiadomość, ponieważ tokeny generują się automatycznie, o ile korzystamy z tag helperów do utworzenia formularza. Dla przykładu, formularz:

oraz

Spowoduje wygenerowanie:

Jeśli natomiast nie korzystamy z wyżej wymienionych helperów do tworzenia formularzy, możemy skorzystać z tag helpera  @Html.AntiForgeryToken() , który wygeneruje ukryte pole tokenu.

Zapytania AJAX’owe

W przypadku aplikacji SPA często wykonujemy zapytania AJAX’owe. Wtedy nie wysyłamy formularza, ale np. pojedynczą wartość. Istnieje również możliwość zabezpieczenia tych zapytań przed atakami CSRF. Wystarczy, aby token umieścić w nagłówku zapytania. Przykład:

A co z ciasteczkami?

Pakiet Antiforgery traktuje oba tokeny jako set, więc „ciasteczkowy” token generowany jest automatycznie wraz z polami w formularzu. Następnie jest on wysyłany do przeglądarki. Warto wspomnieć o kilku ważnych rzeczach:

  • Ciasteczko antiforgery jest oznaczone jako http only, więc nie jest dostępne z poziomu JavaScriptu
  • W przypadku kilku formularzy na stronie, ciasteczko generowane jest tylko raz i jest zgodne dla wszystkich tokenów w formularzach
  • Nazwa ciasteczka to „.AspNetCore.AntiForgery.#„, gdzie # to hash nazwy aplikacji. Nazwa ta może zostać zmieniona w konfiguracji
  • Jeśli chcemy zapewnić wymóg SSL, wystarczy ustawić RequireSsl na true. Ustawi to flagę secure ciasteczka

Walidacja tokenów

Do walidacji poprawności tokenów dostarczone zostały dwa filtry: ValidateAntiForgeryToken, AutoValidateAntiforgeryToken. Filtry te sprawdzają tokeny, a następnie przepuszczają zapytanie do serwera lub je odrzucają.

ValidateAntiForgeryToken

Jest to filtr, który możemy wykorzystać w akcji kontrolera, całym kontrolerze lub globalnie w aplikacji. Jego użycie np. w kontrolerze spowoduje walidację wszystkich akcji (również GET).

Jeśli chcemy zignorować walidację dla pojedynczej akcji, możemy ją oznaczyć filtrem IgnoreAntiforgeryToken.

AutoValidateAntiforgeryToken

Działa podobnie jak ValidateAntiForgeryToken, ale nie powoduje walidacji requestów następujących typów:

  • GET
  • HEAD
  • OPTIONS
  • TRACE

Użycie dla kontrolera:

Możemy również dodać ten filtr globalnie dla aplikacji

Zalecane jest używanie globalnie AutoValidateAntiforgeryToken, lub ValidateAntiForgeryToken dla konkretnych akcji kontrolora.

Konfiguracja Antyforgery

Konfiguracji możemy dokonać podczas rejestrowania serwisu. Do ustawienia jest wiele opcji bardzo dobrze opisanych w dokumentacji. Przykład konfiguracji:

Podsumowanie

Mam nadzieje, że w przystępny sposób przedstawiłem czym jest atak CSRF, oraz jak się przed nim bronić. Wiele rzeczy mamy dostępnych od razu podczas projektowania aplikacji. Wystarczy więc kilka linijek kodu, aby nasza aplikacja była bezpieczniejsza.

A na koniec serdecznie zapraszam do odwiedzania bloga. Będą pojawiać się kolejne części serii „Bezpieczna aplikacja ASP.NET Core” oraz inne wskazówki jak uczynić nasze aplikacje .NET’owe bardziej bezpiecznymi. 🙂

Daj Się Poznać 2017 security steganography

Steganografia? A co to jest? A komu to potrzebne?

Myślę, że część osób lub nawet większość może się zastanawiać czym jest w ogóle ta steganografia. Zacząłem projekt bez porządnego przedstawienia tematu. Nadrabiam więc zaległości.

Co to jest steganografia?

Steganografia jest nauką lub praktyką, z która prawdopodobnie spotykamy się na co dzień, zupełnie o tym nie wiedząc. Polega ona na ukrywaniu wiadomości, zdjęcia lub pliku w nośniku. Nośnikiem może być zdjęcie lub inna wiadomość. Istotny jest fakt, iż samo prowadzanie komunikacji(ukrywanie wiadomości) jest tajne. Głównym celem steganografii jest więc ukrycie w nośniku wiadomości, tak aby trzecia strona, czyli atakujący, nie była w stanie wykryć jej obecności. Samo słowo steganografia pochodzi z języka greckiego i oznacza „ukryte pisanie”.

W porównaniu do kryptografii, steganografia posiada pewną przewagę. Ukryta w dowolnym nośniku wiadomość nie zwraca na siebie uwagi. Natomiast w kryptografii, wiadomości są szyfrowane i mogą zostać wysłane publicznym kanałem. Tak więc, dużą zaletą stosowania steganografii jest to, iż sama wiadomość jest ukrywana w nośniku, oraz dodatkowo ukrywany jest sam fakt wysłania wiadomości. W poniższej tabeli prezentuje podstawowe właściwości steganografii i kryptografii.

Właściwość Steganografia Kryptografia
Ukrycie wiadomości Tak Nie
Użycie klucza Tak Tak
Ukrycie faktu komunikacji Tak Nie
Dodatkowy nośnik Tak Nie
Ilość przesyłanych informacji Większa od ilości wiadomości Porównywalna do wiadomości

W głównej mierze staganografia zajmuję się ukrywaniem informacji w plikach komputerowych. Wtedy możemy mówić o cyfrowej steganografii. Jak wspomniałem na początku, wiadomość może zostać ukryta w warstwie transportowej, czyli między innymi w plikach, zdjęciach, a także protokołach sieciowych. Najczęściej stosowane są pliki multimedialne. Głównym powodem ich wyboru jest duży rozmiar oraz fakt, iż zawierają dużo informacji nadmiarowych, których zmiana może nie być zauważona przez atakującego.

System steganograficzny

System steganograficzny można zdefiniować jako system składający z dwóch części: kodera i dekodera. Zadaniem kodera jest, przy użyciu klucza, umieszczenie w danym nośniku wiadomości. Klucz powinien być znany tylko nadawcy i odbiorcy. Znajomość klucza oznacza możliwość odczytania wiadomości. Schemat kodera systemu steganograficznego znajduje się na poniższym rysunku.

system steganograficzny

Koder systemu steganograficznego

 

Druga część systemu steganograficznego, czyli dekoder, służy do odczytania wiadomości. W zależności od wybranego algorytmu steganograficznego dekoder może składać się z różnych elementów. Jednak ogólny schemat powinien wyglądać jak na poniższym rysunku. Dekoder na podstawie klucza, odczytuje z nośnika wcześniej umieszczoną, sekretną wiadomość.

dekoder

Dekoder systemu steganograficznego

Chwila, chwila. A ukrywanie informacji to nie jest znakowanie wodne?

Możemy mieć wrażenie, że to o czym pisze to znakowanie wodne. Jest jednak spora różnica pomiędzy znakami wodnymi a steganografią.

Znak wodny to charakterystyczny obraz widzialny w świetle przechodzącym, powstający podczas formowania papieru. Jego najczęstszym zastosowaniem są zabezpieczenia banknotów oraz innych wartościowych dokumentów.

Cyfrowy znak wodny, jest to wiadomość zapisana w różnego rodzaju plikach np. obrazach, nagraniach dźwiękowych lub filmach wideo. Może być ona widoczna, tak jak w przypadku tradycyjnych znaków wodnych lub też niewidoczna. Wtedy do odczytania wcześniej zapisanej informacji, należy użyć programu wraz z zaimplementowanymi algorytmami.

Cyfrowy znak wodny, jest integralną częścią pliku, który został poddany oznakowaniu oraz nie potrzebuje żadnej dodatkowej pamięci. Oznacza to, że powstaje on kosztem pogorszenia jakości danych danego pliku. Znaki wodne, podobnie jak steganografia, są formą ukrywania pewnych informacji w nośnikach. Posiadają jednak wiele cech, które w znaczny sposób odróżniają je od wspomnianej steganografii. Cyfrowe znakowanie wodne można określić jako praktykę niedostrzegalnego umieszczania w nośniku pewnej informacji, traktującej o tym właśnie nośniku. Długość informacji jest zazwyczaj relatywnie mała. Natomiast fakt, iż dany nośnik zawiera znak wodny nie musi być ukrywany.

Porównując tą definicję do steganografii, możemy zauważyć podstawowe różnice. W steganografii ważniejsza jest niewykrywalność. W teorii, zmiana pewnych obszarów w nośniku, może być akceptowalna, ponieważ sam nośnik nie ma znaczącej wartości dla komunikujących się stron – ważna jest ukryta wiadomość. Oczywiście, zmiany nie mogą być zauważalne, ponieważ może to zwrócić uwagę atakującego. Druga znacząca różnica to pożądana długość wiadomości do ukrycia. W steganografii będzie ona dużo większa niż w aplikacjach do znakowania wodnego. W znakowaniu wodnym ukrywana jest informacja mająca związek z nośnikiem. Zazwyczaj jest to krótki podpis – od 8 do 128 bitów. Natomiast w steganografii, może to być tekst lub nawet rysunek.

Czyli podsumowując:

Właściwość Steganografia Znaki wodne
Ukrywana wiadomość Nie związana z nośnikiem Związana z nośnikiem
Długość wiadomości Duża Mała
Niewykrywalność Pożądana Nie ma znaczenia

A na co to komu?

Tak jak ze wszystkimi metodami związanymi z bezpieczną komunikacją, tak i steganografia może być wykorzystana w dobrych i złych celach. Jej główną ideą, tak jak to zostało wspomniane, jest umieszczenie wiadomości w wybranym nośniku. W połączeniu z pewnymi metodami kryptograficznymi, steganografia może posłużyć jako narzędzie do ochrony dokumentów, ograniczenia przeglądania danych czy ochrony przed kradzieżą. W tym ostatnim przypadku, w pliku zostaje umieszczony tzw. znak wodny, który może świadczyć o posiadanych do niego praw autorskich. W przypadku kradzieży, autor może przed sądem udowodnić swoje prawa do oznakowanego pliku.

Niestety, steganografia może zostać wykorzystana przez organizacje terrorystyczne lub szpiegów, do ukrywania faktu prowadzenia komunikacji. Po ataku 11 września 2001 roku na World Trade Center, mówiło się, że terroryści wymieniali rozkazy właśnie dzięki steganografii. Innym przykładem jest jej użycie do ukrywania pornografii, najczęściej dziecięcej, w niezwracających uwagi zdjęciach. Następnie takie zdjęcie, może zostać wysłane publicznym kanałem, np. w wiadomości e-mail lub jako post na forum. Steganografia może być również wykorzystywana przez hakerów do ukrycia kodu wykonawczego. Wtedy istnieje możliwość przeniesienia go nie zważając na zabezpieczenia, czy oprogramowanie antywirusowe np. na serwer ofiary. Następnie kod może zostać skopiowany do pamięci operacyjnej i wykonać niepożądane działania.

Daj Się Poznać 2017 security steganography

StegoCore – algorytm ukrywania danychs LSB

Czas na implementację pierwszego algorytmu steganograficznego. Zgodnie z zapowiedzią będzie nim algorytm LSB. Na początku kilka teoretycznych informacji na jego temat.

Algorytm LSB (pol. najmniej znaczący bit) jest jednym z najstarszych algorytmów wstawiania znaków wodnych. Polega na umieszczaniu kolejnych bitów wiadomości, w miejsce najmniej znaczących bitów nośnika. Ze względu na swoją prostotę, łatwo go zastosować w podpisywaniu obrazów i utworów audiowizualnych. Dla obrazów kolorowych, wiadomość można umieścić w najmniej znaczących bitach składowych RGB.

Metoda pozwala na umieszczenie dużej ilości informacji w obrazie, jednak jest bardzo mało odporna na operacje np. kompresję JPEG, przycinanie obrazu. Z jednej strony jest to wadą, ponieważ w wielu przypadkach można stracić zapisaną wiadomość. Jednak z drugiej strony, gdy zależy nam na tajnej komunikacji jest to zaletą. Prawie każda modyfikacja obrazu powoduje usunięcie sekretu.

Pseudokod algorytmu

Proces umieszczania wiadomości składa się z wybrania zbioru elementów, na których zostanie przeprowadzona operacja. Algorytm wstawiania i odczytywania wiadomości wygląda następująco:

Algorytm LSB – wstawianie znaku

Algorytm LSB – odczytywanie znaku

gdzie:
lsb(c) = najmniej znaczący bit elementu c

Głównym problemem, jest wybór elementów z obrazu, które zostaną poddane zamianie. W najprostszym rozwiązaniu mogą to być kolejne składowe RGB każdego piksela w obrazie rozpoczynając od pierwszego. Zazwyczaj będzie tak, że proces wstawiania wiadomości zakończy się dużo wcześniej, nie wykorzystując wszystkich dostępnych elementów. Może to spowodować wiele problemów związanych z bezpieczeństwem. Część obrazu z zakodowaną wiadomością, będzie posiadała inne właściwości statystyczne, w porównaniu z częścią, która nie uległa zmianie.

Aby temu zapobiec należy wybrać inny sposób wybierania elementów do zakodowania. Dobrym podejściem, jest użycie generatora pseudolosowego. Jeśli dwie osoby współdzielą klucz, mogą go użyć jako ziarno do generatora. W wyniku jego działania otrzymają sekwencję liczb , którą można użyć do wyboru elementów. Wtedy odległość pomiędzy dwoma zakodowanymi bitami będzie pseudolosowa. Odbiorca znając ziarno generatora może odtworzyć sekwencję oraz kolejne współrzędne określające wybór elementów z obrazu.

Co udało się zaimplementować?

Na tę chwilę w StegoCore zaimplementowałem algorytm bez zastosowania generatora pseudolosowego. Myślę, że w przeciągu tygodnia dodam również jego obsługę.

Zdecydowałem się również na umieszczenie bitów danych w dwóch (R i B) z trzech składowych piksela. Dzięki temu nie muszę się martwić o dopełnianie bitami gdyby długość sekretu była niepodzielna przez 3.

W edytowanym obrazie na samym początku będę umieszczał także długość ukrywanych danych. Jest to potrzebne podczas dekodowania, aby wiedzieć ile bitów odczytać. Czyli ostatecznie ukrywane dane (m) będą miały postać:

W związku z tym algorytm dekodowania zostanie lekko zmodyfikowany. Na początku odczytane zostaną 4 bajty, czyli 32 bity (długość danych zapisana jest w int32, który zajmuje właśnie 4 bajty). A następnie odczytane zostaną kolejne n bitów.

Zaimplementowany algorytm dostępny jest na github.

Co dalej?

Do realizacji pozostało kilka rzeczy, które przydadzą się również podczas implementacji innych algorytmów.

  • Sprawdzanie możliwości umieszczenia danych w obrazie – dane mogą być za duże
  • Generator pseudolosowy do wyznaczania miejsc osadzenia danych w pliku graficznym
  • Dodanie obsługi algorytmu w aplikacji webowej
Daj Się Poznać 2017 os x security u2f

Klucz U2F jako metoda logowania do OS X

Jakiś czas temu zakupiłem klucz FIDO U2F firmy Yubico. Służy on do weryfikacji naszej tożsamości podczas dwuskładnikowego logowania na wielu portalach: github, google, facebook itp. Metoda ta jest o wiele szybsza od wysyłania smsa lub maila. Musimy tylko umieścić klucz w porcie USB, a następnie dotknąć podświetloną ikonę klucza. O tym dlaczego zaleca się używanie tego klucza można poczytać między innymi na niebezpieczniku.

Osobiście również zachęcam do tej metody logowania dwuskładnikowego. Klucz jest na tyle mały, że możemy go mieć cały czas przy sobie. Zabezpiecza nas przed wyciekiem haseł czy phishingiem, więc na pewno warto rozważyć zakup. Sam zaopatrzyłem się w niego na amazon.de.

Okazuje się, że w dosyć łatwy sposób możemy wykorzystać klucz jako metodę logowania do Maca. Poniżej kroki jakie należy wykonać. Dodaje, że wykonujesz je na własne ryzyko.

Co potrzebujemy?

  1. Oczywiście Klucz Fido U2F
  2. Homebrew – do instalacji modułu U2F
  3. Wykonanie backupu, np. przy pomocy Time Machine. Niestety podczas konfiguracji możemy wykonać błąd i stracić dostęp do systemu. Innym sposobem jest utworzenie nowego konta użytkownika z prawami administratora.

Konfiguracja

Na początku należy zainstalować moduł U2F za pomocą homebrew:

Moduł powinien zostać zainstalowany w:

Dlatego warto wykonać link, aby za każdym razem nie trzeba było wskazywać całej ścieżki:

Następnym krokiem jest zapisanie danych uwierzytelniających klucza w katalogu  ~/.config/Yubico/u2f_keys . Jest to domyślne miejsce w którym moduł U2F będzie szukać naszych danych podczas logowania. Możemy to zrobić wykonując po koleji:

Po pomyślnym zapisaniu danych, możemy przystąpić do konfiguracji metody logowania. Należy w tym celu edytować plik  /etc/pam.d/authorization i dodać na początku  auth sufficient pam_u2f.so . Plik powinien wyglądać następująco.

Dzięki temu będziemy mogli zalogować się do systemu za pomocą hasła lub klucza. Warto przetestować to przed następnym krokiem. Podczas logowania należy wcisnąć Enter i dotknąć klucz. Powinniśmy zostać zalogowani do systemu. Jeśli coś będzie nie tak, trzeba sprawdzić czy nie popełniliśmy żadnego błędu (np. czy dane z klucza zostały poprawnie zapisane).

Ostatnim krokiem jest użycie klucza jako typowego U2F zmieniając  auth sufficient pam_u2f.so na  auth required pam_u2f.so . Aby się zalogować należy wtedy podać hasło oraz klucz.

Klucz U2F to doskonała metoda do dodatkowego zabezpieczenia dostępu do naszego laptopa. Nie powinniśmy już się obawiać utracenia danych po jego kradzieży. Oczywiście pod warunkiem, że naszego dane są zaszyfrowane np. za pomocą FileVault.

 

Daj Się Poznać 2017 dotnetcore security

StegoCore – podsumowanie po 2 tygodniach

W ostatnich dwóch postach opisałem konfigurację środowiska pracy oraz generowanie projektu przy pomocy Yeomana. Po tym wszystkim nareszcie można usiąść do pisania kodu. W związku z tym, że nie czuje się mocny we frontendzie, a i mój projekt będzie się bardziej opierał na operacjach na plikach, postanowiłem zacząć właśnie od frontendu 🙂 żeby mieć to już z głowy i zdecydować się na jakiś układ, kolorystykę itp.

Zanim zacznę od opisania tego, co udało się zrobić, wyjaśnię na początku jaki mam pomysł na aplikację i co dokładnie ma ona robić:

  • użytkownik będzie mógł przesłać plik graficzny na serwer, a następnie przeprowadzić na nim operacje steganograficzne
  • będzie możliwość ukrycie dowolnego pliku binarnego (o ile zmieści się w pliku graficznym)
  • do dyspozycji będą algorytmy
    • LSB – ukrywanie danych w najmniej znaczących bitach pliku graficznego
    • DCT – ukrywanie danych w blokach danych 8×8 z użyciem dyskretnej transformaty kosinusowej, która jest częścią algorytmu kompresji JPEG (czyli przesłany plik musi być w tym formacie)
    • Wet Paper Codes Algorithm – połączenie DCT z Wet Paper Codes właśnie (więcej o tym algorytmie w kolejnych postach)
  • plik z ukrytą informacją będzie można pobrać lub przekazać linkiem znajomemu

Dropzone.js

Za obsługę przesyłania pliku graficznego na serwer po stronie przeglądarki będzie odpowiadać dropzone.js. Jest to prosta w obsłudze biblioteka umożliwiająca opuszczanie pliku w wyznaczonym miejscu strony, a następnie wykonanie uploadu na serwer. Biblioteka została dodana do projektu jako kolejna zależność w pliku bower.json. Poniżej umieszczam moją konfigurację dropzone wraz z wyjaśnieniem. Być może komuś się przyda.

Powyższa konfiguracja podpinana jest pod formularz z odpowiadającym atrybutem id (w moim przypadku uploaddropzone).

Dropzone podczas uploadu pliku zmienia szerokość (w zakresie 0-100%) elementu z atrybutem data-dz-uploadprogress. Dzięki temu możemy wykorzystać w tym miejscu zwykły bootsrapowy progressbar.

Upload pliku w ASP.NET Core

Dropzone po wyborze lub opuszczeniu pliku wykonuje upload pod wskazany adres. Za sam odbiór i to co zrobimy z plikiem musimy zadbać sami. Do plików wysyłanych na serwer mamy dostęp poprzez Model Binding używając interfejsu IFormFile.

W powyższym przykładzie plik zapisywany do folderu uploads.

Na uwagę zasługuje, znany już programistom .NET z wcześniejszych wersji frameworka, atrybut [ValidateAntiForgeryToken]. Zapewnia on ochronę przez atakami typu CSRF. Działanie tego mechanizmu ochrony można opisać w trzech krokach:

  1. W formularzu, poprzez atrybut asp-antiforgery-„true”, umieszczany jest ukryty element __RequestVerificationToken, wraz z losowo wygenerowanym tokenem

    Request Verification Token

  2. Token ten zapisywany jest również w ciasteczkach
  3. Podczas requestu do akcji w kontrolerze, o ile umieścimy atrybut [ValidateAntiForgeryToken], porównywana jest wartość z formularza i ciasteczka. Jeśli są równe to request zostaje przepuszczony

 

Udało się więc zrealizować pierwszy podpunkt z planu na projekt. Hura! 😀

Co dalej?

Na razie plik graficzny zapisywany jest w folderze uploads, być może to zmienię, gdy znajdę jakiś bezpieczniejszy sposób na ich przetrzymywanie. Może ktoś z Was ma jakiś lepszy pomysł? Nie widzę jednak w aktualnym rozwiązaniu sposobu na dostanie się do plików innego użytkownika. Muszę jedynie pomyśleć o usuwaniu pliku np. po dobie od jego utworzenia.  W każdym razie, nie jest to teraz priorytetem, gdyż w końcu będę mógł zająć się biblioteką StegoCoreLib, czyli samą esencją projektu 🙂 Następy post z podsumowaniem prac nad projektem, będzie zawierał opis implementacji pierwszego algorytmu. Mam przynajmniej taką nadzieję 🙂

Wszystko co do  tej pory zrobiłem, znajduje się oczywiście na githubie. A sama strona prezentuje się tak:

StegoCoreWeb

Tak wiem, dupy nie urywa, mocne 2/10 😀  ale działa i spełnia swoje wymagania.