Browsing Category

dotnetcore

Daj Się Poznać 2017 dotnetcore steganography

StegoCore – zakończona implementacja algorytmu Zhao&Koch

Jak obiecałem, tak robię. Po zakończeniu konkursu Daj Się Poznać nie ustają prace nad projektem StegoCore. Już na początku czerwca udało mi się dokończyć i poprawić implementację algorytmu Zhao&Koch, ale jestem leniem i zebrałem się dopiero teraz za napisanie posta. 😀

Co zrobiłem?

  • Wczytałem się dokładnie w opis algorytmu wstawiania i odczytywania znaku. Okazało się, że miałem w swojej implementacji błąd, który uniemożliwiał wstawienie, a co za tym idzie, odczytanie wiadomości.
  • Poprawiłem implementację oraz doświadczalnie dostosowałem parametry wykorzystywane podczas umieszczania znaku.
  • Dokonałem kilka poprawek w aplikacji webowej, tak aby możliwe było wykorzystanie algorytmu Zhao&Koch. W wolnej chwili wdrożę nową wersję aplikacji pod adres pawelskaruz.pl:8080

Co dalej?

  • Po pierwsze chciałbym poprawić aplikację webową, tak aby była używalna 😀 przyda się więcej komunikatów odnośnie umieszczania, odczytywania danych.
  • Do algorytmu Zhao&Koch potrzebny jest parametr d, który może pochodzić od użytkownika, więc chciałbym dodać taką możliwość. Będzie to oczywiście wymagać zmian zarówno w StegoCore, jak i w aplikacji webowej
  • Jeśli już zabiorę się za parametry wejściowe, to chciałbym dodać możliwość umieszczania bitów nie w kolejnych, a losowych miejscach zdjęcia. Myślę, że dobrym pomysłem będzie możliwość podania przez użytkownika hasła, które będzie seed’em do jakiegoś generatora pseudolosowego.
  • Następnym większym krokiem będzie implementacja mojego algorytmu opartego na Web Paper Codes.

I to na tyle dzisiaj. A już niedługo kolejna, 3 część z serii o bezpiecznej aplikacji ASP.NET Core 🙂

Daj Się Poznać 2017 dotnetcore imagesharp steganography

StegoCore – 10 tydzień. Koniec konkursu DSP i duże podsumowanie!

Minęło właśnie 10 tygodni prac nad projektem StegoCore w konkursie Daj Się Poznać. Jest to wiec ostatni tydzień i tym samym koniec konkursu. Ale zanim podsumuje cały projekt, czas na to co udało mi się zrobić w ostatnim tygodniu.

Co słychać?

  • Zaimplementowałem metodę odczytu ukrytej informacji w algorytmie Zhao&Koch
  • Napisałem testy sprawdzające możliwość odczytu ukrytej informacji – niestety wyniki nie są zadawalające; jest wiele przekłamań w odczytywanych bitach, co powoduje brak możliwości poprawnego odczytu danych. Wydaje mi się, że nie popełniłem żadnych błędów podczas implementacji, więc ciężko mi wywnioskować gdzie szukać błędu. Będę musiał dokładnie przeanalizować algorytm ukrywania i odczytu.
  • Zaktualizowałem aplikację webową dostępną pod adresem: http://pawelskaruz.pl:8080/

Co dalej?

  • Muszę przede wszystkich przetestować/przedebugować algorytm Zhao&Koch, aby dowiedzieć się dlaczego otrzymuje przekłamane bity podczas odczytywania.
  • Chciałbym poprawić aplikację webową StegoCoreWeb, wyłapać wyjątki z biblioteki StegoCore i przekazać odpowiednie komunikaty użytkownikowi

Podsumowanie konkursu

Przede wszystkim jestem zadowolony, że przez 10 tygodni udało mi się rozwijać projekt. Niestety wszystkie cele nie zostały osiągnięte. Na koniec konkursu chciałem zaimplementować 3 algorytmy i umieścić bibliotekę w menadżerze NuGet. Tak, jak wspominałem wcześniej, koniec konkursu nie oznacza końca prac nad projektem.

Gdy tylko uporam się z algorytmem Zhao&Koch, umieszczę bibliotekę StegoCore w NuGet. Dalej oczywiście będę rozwijał samą bibliotekę, jak i aplikację webową. Myślę tutaj o zaimplementowaniu własnego algorytmu ukrywania danych opartego na Wet Paper Codes.

Nie jestem za bardzo zadowolony z tylko 27 commitów, ale muszę wziąć pod uwagę fakt, iż mam tendencję to wrzucania wielu rzeczy na raz. Jest to jedna z kilku rzeczy, które muszę poprawić w swojej pracy. Commity nie powinny zawierać, aż tylu zmian w projekcie, a dotyczyć tylko jednej konkretnej zaimplementowanej/poprawionej rzeczy. Dzięki konkursowi nauczyłem się (a przynajmniej jestem świadomy, że muszę nad tym pracować 🙂 ) również innej, bardzo ważnej rzeczy – systematyczności. O wiele lepiej jest codziennie pracować nad projektem niż usiąść po kilku dniach przerwy i siedzieć wiele godzin przed komputerem.

Podczas prac nad StegoCore dosyć dobrze zapoznałem się z .NET Core. Jest to mój pierwszy projekt z użyciem tego frameworka, ale myślę że jak na pierwszy raz nie było tak źle. Do przeprowadzania operacji na zdjęciach użyłem biblioteki ImageSharp. Pomimo tego, że jest ona wciąż w fazie alpha, korzystało się z niej wygodnie i bez większych problemów.

W ramach Daj Się Poznać pisałem cotygodniowe podsumowania projektu, ale również inne posty związane z tematyką IT. TOP 5 najczęściej odwiedzanych to:

  1. Bezpieczna aplikacja ASP.NET Core (cz. I) – atak CSRF
  2. Kompresja JPEG oraz jej wykorzystanie w steganografii
  3. Alternatywa dla Visual Studio? Rider od JetBrains
  4. StegoCore – 3 tydzień, edycja zdjęć w .NET Core
  5. Klucz U2F jako metoda logowania do OS X

Reszta znajduje się pod adresem konkursowym. Serdecznie zachęcam do odwiedzania i czytania 🙂

Sukces!

Udało mi się wytrwać do samego końca konkursu Daj Się Poznać 2017! Yeah!! Sprostałem z wymogami i napisałem 20 postów konkursowych 🙂

Projekt będę dalej rozwijał, więc bardzo zachęcam do śledzenia bloga oraz dotnetomaniaka, na którego wrzucam swoje posty.

Na koniec chciałbym podziękować kilku osobom, które wspierały mnie podczas konkursu. Miewałem momenty zwątpienia i zniechęcenia, ale dzięki Wam nie poddałem się! Nie będę wymieniał z imienia i nazwiska, ale myślę, że te osoby będą wiedzieć, że chodzi o nie. Dzięki! 🙂

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 🙂

 

Daj Się Poznać 2017 dotnetcore steganography

StegoCore – podsumowanie po 9 tygodniach

Pora na podsumowanie po 9 tygodniach pracy nad projektem StegoCore.

Co słychać?

  • Zaktualizowałem wersję dotnetcore do 1.0.4 with SDK 1.0.1; wcześniej używana przeze mnie wersja była RC, wiec stwierdziłem, że warto spróbować przejść do nowszej. Nie spowodowało to żadnych dziwnych zachowań aplikacji, więc upgrade się udał.

    Krótka informacja jak wskazać aplikacji, aby korzystała z nowej wersji dotnet core.

    Po pierwsze należy zainstalować pożądaną wersję dotnet core np. podaną powyżej. Następnym i ostatnim krokiem jest zmienić numer wersji na nowo zainstalowany w pliku global.json, . W moim przypadku plik ten wygląda tak:

  • Dokonałem małego refactoringu w kilku miejscach biblioteki, a także aplikacji webowej: między innymi w kontrolerze bazowym
  • Napisałem testy sprawdzające poprawność metod kwantyzacji i obliczania dyskretnej transformaty kosinusowej; ku mojej uciesze przeszły pomyślnie 🙂
  • Skończyłem implementację metody ukrywania danych z algorytmu Zhao & Koch

Co dalej?

  • Z algorytmu Zhao & Koch została implementacja metody odczytu ukrytej informacji
  • Przetestowanie całego algorytmu Zhao & Koch
  • Niestety nie wystarczy mi już czasu, aby zająć się kolejnym algorytmem ukrywania danych. Dlatego do końca maja chciałbym popracować nad aplikacją webową; tak, aby była bardziej user friendly 🙂

Powoli zbliża się koniec konkursu „Daj się poznać”. Nie chcę kończyć jednak prac nad StegoCore i na pewno dalej będę rozwijał ten projekt. Wiem, że kilka osób go śledzi, więc daje mi to sporą motywację do działania! 🙂

 

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 dotnetcore jetbrains os x

Alternatywa dla Visual Studio? Rider od JetBrains

Kiedy programujemy w C#, w większości przypadków jesteśmy skazani na Visual Studio. Czy słyszał ktoś kiedy o alternatywie? Jakiś czas temu, całkiem przypadkiem, natrafiłem na Rider – nowe IDE dla .NET od JetBrains. Jest on wciąż w trakcie powstawania, jednak stwierdziłem, że warto sprawdzić czy jest na co czekać. Testowany przeze mnie build to:  EAP build 20. Narzędzie jest multiplatformowe, więc testowałem na Windowsie i macOS.

Firmę JetBrains programiści .NET mogą kojarzyć z rozszerzenia do Visual Studio – Resharper. Jedni uważają, że jest świetne, bo pomaga programiście pisać szybciej kod i utrzymać w nim porządek. Inni nie przepadają za nim, w sumie nie wiem dlaczego. Być może dlatego, że szczególnie młodzi programiści mogą ślepo ufać Resharperowi i korzystać ze wszystkich jego podpowiedzi. Może to spowodować, że taki kod będzie mniej czytelny. Moim zdaniem Resharper jest świetnym narzędziem, ale trzeba wiedzieć kiedy i jak z niego korzystać.

Programiści Java mogą kojarzyć JetBrains z IntelliJ – IDE do Javy właśnie. Nigdy z niego nie korzystałem, ale słyszę że wśród kolegów z pracy zbiera dobre recenzje.

Dochodzimy tutaj do Rider’a, który jest połączeniem IntelliJ i Resharpera. Jak on się prezentuje? Sprawdźmy! 🙂

Instalacja

Ze strony JetBrains należy pobrać odpowiednią dla naszego systemu paczkę. Paczka ma około 300mb. Czas instalacji to kilka minut. Każdy kto instalował Visual Studio, wie że ten proces może potrwać kilkadziesiąt minut, więc tutaj duży plus dla Rider’a.

Po instalacji kreator przeprowadzi nas przez wstępną konfigurację, wybór kolorystyki, klawiszologii. Możemy również zainstalować opcjonalne rozszerzenia. Po tym możemy przystąpić do pracy. Do wyboru mamy otwarcie gotowego projektu lub stworzenie nowego.

Nowy projekt

Do wyboru mamy kilka szablonów dla .NET, Xamarin i .NET Core:

Do testów zdecydowałem się na MVC ASP.NEt Core Web App. Otrzymujemy gotowy szablon do pracy. Edytor prezentuje się następująco:

Edytor Rider

Zarówno na macOS i Windows buildowanie oraz uruchomienie aplikacji przebiegło bez żadnych problemów. Pozytywnie zaskoczyło mnie buildowanie na Windows dużej solucji z aplikacją w .NET. Wszystko działa jak należy. Jedyny problem jaki napotkałem to brak możliwości debugowania aplikacji w .NET Core. Nie jest to winą Rider’a, a postanowień licencyjnych. Wykorzystanie pakietu umożliwiającego debugowanie aplikacji .NET Core możliwe jest tylko w Visual Studio, Visual Studio Code i Xamarin Studio.

Pomyślałem, że jednak najlepiej będzie jak przetestuję Rider’a w praktyce. Uruchomiłem więc projekt StegoCore i przystąpiłem do pracy. Poniżej moje uwagi podzielone na plusy i minusy.

Plusy

  • Wspiera większość projektów .NET, .NET Core i opartych na Mono
  • Multiplatformowy – działa na Windows, macOS i Linux
  • Działa bardzo płynnie, nie zauważyłem żadnych przycięć itp; zdarzają się czasami jakieś błędy, ale nie powodują wyłączania aplikacji
  • Wbudowany Resharper – refaktoryzacja kodu, analiza kodu
  • W pełni sprawny menadżer pakietów NuGet

    Rider NuGet

  • Unit test runner – pozwala uruchamiać i debugować testy NUnit i xUnit.net

    Rider Unit Test Runner

  • Wbudowane wsparcie dla systemów kontroli wersji: Git, Subversion, Mercurial, Perforce i TFS
  • Możliwość połączenia się do bazy danych (testowałem na MS SQL)
  • Dekompilator

    Rider decompilator

    Przy użyciu Go to Declaration na dowolnym elemencie biblioteki zostaniemy przeniesieni do jej kodu źródłowego. W sytuacji gdy jest on niedostępny dekompilator Rider’a przygotowuje dla nas kod C# biblioteki.

  • Rozszerzalność przez pluginy

Minusy

  • Pojawiające się błędy; przy czym trzeba mieć na uwadze że jest to wciąć wersja early build
  • Podczas otwarcia istniejącego projektu ASP.NET MVC nie zostały wczytane pliki widoków *.cshtml
  • Brak Package Manager Console
  • Brak możliwoście debugowania aplikacji w .NET Core

Podsumowanie

Pierwszy kontakt z Rider wyszedł pozytywnie. Praca w tym IDE jest przyjemna i szybka, a o to przecież chodzi. Projekt rozwija się bardzo dobrze i trzeba się cieszyć, że w końcu rośnie konkurencja dla Visual Studio. Być może zmotywuje to Microsoft do lepszej pracy nad swoim produktem. Mocno na to liczę, bo myślę że wielu z programistów wolałoby mieć jakąś alternatywę przy wyborze IDE.

Zachęcam również Was do spojrzenia na Rider’a. Aktualna wersja umożliwia darmowe przetestowanie i zapoznanie się z IDE.

Daj Się Poznać 2017 dotnetcore steganography

StegoCore – podsumowanie po pierwszym miesiącu

thumbs up

Właśnie minął pierwszy miesiąc pracy nad StegoCore. Czas na małe podsumowanie tego co udało się zrobić w tym czasie oraz jakie są plany na kolejny miesiąc.

Zrealizowane cele

Przede wszystkim udało się zaprezentować pierwszą wersję aplikacji webowej, która umożliwia ukrycie a następnie odczytanie pliku z danymi. Dosłownie przed chwilą poszedł commit z odpowiednimi zmianami. Sama aplikacja dostępna jest pod adresem:

 pawelskaruz.pl:8080

Ale może zacznijmy od początku.

  • Konfiguracja środowiska pracy oraz wybranie odpowiedniej wersji .NET Core
  • Wykorzystanie Yeomana do wygenerowania szablonów projektów biblioteki oraz aplikacji webowej
  • Wybranie ImageSharp jako bibliotekę do obsługi plików graficznych
  • Implementacja pierwszego algorytmu steganograficznego – LSB
  • Wykorzystanie algorytmu w aplikacji webowej

Aplikacja webowa wymaga jeszcze wielu poprawek (np. zabezpieczenie przed umieszczaniem zbyt dużych plików, nieudana próba odczytu sekretu). Niemniej jednak, jestem zadowolony że udało się zaimplementować pierwszy algorytm i wykorzystać go w aplikacji. Pierwszy miesiąc jak najbardziej na plus.

Co dalej?

  • Implementacja zabezpieczenia przed umieszczeniem zbyt dużych plików lub nieudaną próbą odczytu sekretnego pliku
  • Dodanie do aplikacji webowej kilku wyjaśnień, tak aby byłą bardziej „user friendly”
  • Implementacja kolejnych algorytmów ukrywania danych
  • Dodanie obsługi zapisywania wyjściowego pliku graficznego z ukrytymi danymi w różnych formatach (aktualnie tylko .bmp)
Daj Się Poznać 2017 dotnetcore

StegoCore – 3 tydzień, edycja zdjęć w .NET Core

Czas na podsumowanie po kolejnym tygodniu prac nad StegoCore. W ostatnim poście projektowym skończyłem na tym, iż w końcu będę mógł zająć się biblioteką StegoCoreLib, służącą do ukrywania danych w plikach graficznych. Wcześniej jednak, musiałem zdecydować się na bibliotekę, której użyję do edycji zdjęć. Oczywiście, fajnie byłoby gdyby StegoCore była zależna tylko od standardowych bibliotek, ale nie chciałem tracić czasu pisanie własnego edytora zdjęć. Już prawie miesiąc, a backend prawie nie ruszony!

Długo nosiłem się z wyborem biblioteki. Wymagania, które musi spełniać to:

  • szybkość – szybko dostęp do pikseli zdjęcia
  • dostępność na .NET Core dla Windows, Linux i macOS
  • bezpieczeństwo

Ostatecznie zdecydowałem się na ImageSharp. Aktualnie jest ona jeszcze w fazie alpha, ale bardzo szybko się rozwija i do tego posiada już funkcjonalności, które są mi potrzebne. Mógłbym też skorzystać po prostu z System.Drawing, ale opinie o tej bibliotece nie są zbyt dobre. Została ona zaczerpnięta z Mono, jej źródła różnią się w zależności od systemu (Windows, Linux, Mac). ImageSharp jest niezależna od systemu, na którym jej używamy więc to duży plus. Dodatkowo podobno są kłopoty z wyciekami pamięci. Nauczony więc tym, że jeśli z czymś mogą być problemy – to na pewno będą, odrzuciłem ten wybór.

Konfiguracja ImageSharp

Aktualnie ImageSharp nie jest dostępna w menadżerze Nuget. Pojawi się tam wraz z pierwszą, oficjalną wersją biblioteki. Na szczęście nie musimy ściągać jej ręcznie i kompilować. Możemy wykorzystać menadżera MyGet. W tym celu w folderze projektu należy umieścić plik NuGet.config:

Teraz podczas uruchomienia  dotnet restore , pod uwagę zostaną wzięte źródła z tego pliku. Możemy teraz dodać referencje do do biblioteki w naszym pliku konfiguracyjnego projektu:

Biblioteka ImageSharp aktualnie jest podzielona na kilka mniejszych. Jeśli chcemy skorzystać, np. z metody umożliwiającej dostęp do pikseli zdjęcia czy odpowiednich formatów (jpeg, bmp, png) powinniśmy wskazać je osobno. Lista wszystkich dostępnych paczek dostępna jest na stronie MyGet.

Podczas dodawania biblioteki i jej paczek, miałem sporo problemów gdyż gryzły się ze sobą wersje kolejnych kompilacji. Na szczęście po kilku próbach udało mi się je odpowiednio dopasować. Wyżej wymieniona lista jest tą, którą aktualnie używam. Należy pamiętać o tym, aby zależności te znalazły się też w pliku konfiguracyjnym naszego projektu startowego. W moim przypadku obsługę plików graficznych umieściłem w projekcie StegoCoreLib, a projektem startowym jest StegoCoreWeb. Oznacza to, że w konfiguracji StegoCoreWeb również musimy dodać referencje do ImageSharp (sama referencja do StegoCoreLib nie wystarczy!). Jest to oczywista oczywistość, ale jako, że w VisualStudio, NuGet robi to za nas sam, kompletnie wyleciało mi to z głowy. Dwie godziny stracone na takim czymś, ehh!

Dostęp do pikseli

Moim celem jest ukrycie danych w pliku graficznym, nie zmieniając jego wielkości. Aby to zrobić muszę uzyskać dostęp do pikseli, a następnie je odpowiednio zmodyfikować. Można to zrobić przy użyciu ImageSharp.

Dostęp ten jest bardzo szybki, gdyż jak zauważyłem biblioteka korzysta z unsafe code, czyli bezpośredniego dostępu do pamięci (wskaźniki).

Zmodyfikowany obraz możemy teraz zapisać do pliku lub pamięci.

Co dalej?

Pomimo kilku kłopotów na początku, jestem zadowolony z wyboru ImageSharp jako biblioteki do edycji plików graficznych. Posiada to na czym mi najbardziej zależało, czyli szybki dostęp do pikseli zdjęcia.

Teraz czas na implementację pierwszego algorytmu: LSB, czyli ukrywania danych w najmniej znaczących bitach pikseli zdjęć. Aktualnie na githubie projektu znajduje się pierwsza wersja implementacji. Wymaga jeszcze kilku poprawek, ale jak tylko będzie gotowy to opisze go w na blogu.

Kolejnym krokiem będzie dodanie obsługi algorytmu do aplikacji webowej. Po uploadzie zdjęcia będzie możliwość wybrania algorytmu oraz pliku, który będzie można ukryć. Aktualna wersja StegoCoreWeb umożliwia jedynie upload pliku graficznego oraz jego usunięcie. Znajduje się pod adresem: http://pawelskaruz.pl:8080

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.

Daj Się Poznać 2017 dotnetcore Visual Studio Code yeoman

Yeoman oraz inne pomocne narzędzia dla developera .NET Core

dot net core helpers

Tworząc nowy projekt w Visual Studio mamy do wyboru dużo szablonów startowych. Możemy wygenerować prostą aplikację webowa, która posłuży nam za podstawę do dalszej pracy. Zaoszczędza nam to dużo czasu na konfiguracji całego projektu. Pracując na systemie Linux czy macOS niestety nie ma takiej możliwości. Na szczęście jest Yeoman – narzędzie, które zawiera dużo szablonów startowych. Wywodzi się on ze świata JavaScriptu, ale dostępne są również szablony do .NET Core.

Instalacja

Yoeman jest narzędziem nodowym, więc do jego instalacji konieczne jest posiadanie npm. Sama instalacja npm jest bardzo prosta. Instalator ściągamy ze strony nodejs.org, a samą instalację wykonamy w kilku krokach. Jeśli jesteś zainteresowany czym jest node.js i npm, odsyłam do artykułu Jakuba Gutkowskiego. Gdy mamy już npm na pokładzie naszego komputera, mozemy przystąpić do instalacji Yeomana:

Flaga -g oznacza, że narzędzie będzie dostępne globalnie. Yoeman do pracy potrzebuje również bower’a, więc jeśli go nie posiadamy, konieczne jest jego zainstalowanie. Bower jest menadżerem pakietów webowych, czyli można go porównać do npm. Jeśli podczas instalacji dostaniemy informację o błędzie, a co zapewne się zdarzy na macOS, polecenie należy ponowić z uprawnieniami root’a:

Ostatnim krokiem jest zainstalowanie generatora aspnet, o którego nam przecież chodziło od samego początku:

Jeśli ponownie dostaniemy błąd, należy ponowić polecenie z uprawnieniami roota.

Użycie

Generator uruchamiany poleceniem:

yo generator-aspnet

yo generator-aspnet

Do wyboru mamy wiele szablonów:

  • Empty Web Application – aplikacja webowa bez przykładowego kontrolera i widoków
  • Web Application – aplikacja webowe (z uwierzytelnieniem lub bez)
  • Console Application – aplikacja konsolowa
  • Class Library – projekt biblioteki
  • Unit test project – projekt testów, do wyboru: MSTest, xUnit.net

Każda z opcji dostępna jest w dwóch językach: C# lub F#.

Do celów projektu wykorzystałem szablon Class Library oraz Web Application Basic. W przypadku wyboru aplikacji webowej, zostaniemy następnie zapytani o preferowany framework UI oraz nazwę naszego projektu.

Po utworzeniu projektu zostanie nam wyświetlony stosowny komunikat, a także komendy które należy wykonać, aby skompilować lub uruchomić aplikację.

Miesiąc temu z generator-asp zostały usunięte szablony pojedynczych plików takich jak: klasa, kontroler, gulpfile, gruntfile itp. Zostało to podyktowane faktem, iż mijało to się z założeniami generatora, czyli generowaniem szablonów projektów. Więcej informacji na projektowym githubie. Na szczęście nie jest to jedyne narzędzie, które przyśpiesza pracę chociażby w tworzeniu klasy. Z pomocą przychodzą dodatki do Visual Studio Code.

Rozszerzenia w Visual Studio Code

W zakładce Extensions w Visual Studio Code możemy znaleźć wiele pomocnych rozszerzeń ułatwiających pracy. Przedstawię te, z którym sam korzystam.

  • C# for Visual Studio Core (link) – podpowiadanie składki C#, intelisense, przejdź do definicji, debugowanie
  • C# Extensions (link) – tworzenie nowej klasy, interfejsu, dodatkowo rozwijając menu kontekstowe (na macOS kombinacja „⌘.”) możemy dodać konstruktor na podstawie propertisów, lub odwrotnie utworzyć propertisy na podstawie parametrów konstruktora
C# Extenions

C# Extensions

  • HTML CSS Class Completion (link) – podpowiadanie klas css-owych zdefiniowanych w plikach CSS w naszym projekcie
  • vscode-icons (link) – bardziej kosmetyczne rozserzenie, pliki w naszym projekcie otrzymają odpowiednią ikonę w zależności od typu
  • HTML Snippets (link) – tagi HTML5, snippety, kolorowanie kodu

Dostępnych jest wiele więcej rozszerzeń, nie tylko do naszego kochanego C#. Może on również być dobrym wyborem przy projektach JS, PHP czy Python.

Teraz jak już mamy gotowe szablony, przygotowane środowisko, nie pozostaje nam nic innego jak zabierać się do pracy!