WOJSKOWA AKADEMIA TECHNICZNA
Laboratorium: Podstawy bezpieczeństwa informacji
Sprawozdanie z ćwiczenia laboratoryjnego nr 2:
Wykonali: Marcin Machul, Adrian Urbanek
Grupa: I0E1S1
Prowadzący: mgr inż. Bartosz Kryński
Treść zadania
Zadanie laboratoryjne składało się z 2-óch części:
Należało uruchomić skaner podatności sieci Web(my wybraliśmy skaner OWASP ZAP), przeanalizować zidentyfikowane podatności aplikacji SuperVeda
Należało wygenerować raport podatności
Pokazać konsekwencje praktycznego wykorzystania podatności
Należało stworzyć projekt sieci przedsiębiorstwa z zaproponowanymi strefami bezpieczeństwa, uwzględnione powinny zostać usługi: web, bezpieczny zdalny dostęp, bazy danych, serwery DNS, poczta elektroniczna, serwery plików, sieć użytkowników
Testowanie aplikacji „superVEDA”
Wykaz podatności aplikacji SuperVeda
Podatności aplikacji SuperVeda
Przedstawienie konsekwencji wykorzystania podatności
Atak SQL Injection
Jako pierwszy został przeprowadzony atak na formularz logowania, formularz został wypełniony w sposób opisany w części poprzedniej.
Efektem tego było zalogowanie na losowe konto użytkownika.
Wykonanie ataku XSS
Podczas testu aplikacji okazało się że błędy posiadał moduł rejestracji użytkowników. Do pola First name został wprowadzony ciąg <script>alert("Uwaga XSS")</script>. Po dokonaniu rejestracji widzimy wywołane okno alertu z naszym napisem Uwaga XSS
Wygenerowany raport z występującymi podatnościami
Cross site scrpiting(Hard)
Cross-site scripting lub HTML injection jest możliwy . Skrypt może być wstrzykiwany w przeglądarce, który wydawał się być prawdziwa zawartość z oryginalnej strony. Skrypty te mogą być wykorzystane do wykonania dowolnego kodu lub kradzieży poufnych informacji klientów, takich jak hasło użytkownika lub ciasteczka.
Bardzo często jest to w formie hiperłącza z wtryskiwanego skrypcie osadzone w kwerendzie ciągów. Jednak XSS jest możliwe poprzez danych POST formularz, ciasteczka, dane użytkownika wysyłane od innego użytkownika lub danych udostępnionych pobierane z bazy danych.
SQL Injection(Hard)
SQL injection jest możliwy . Parametry przedstawione użytkowników będą formułowane w zapytaniu SQL do przetwarzania baz danych. Jeśli zapytanie jest zbudowany przez "konkatenacji" prosty, jest możliwe do zmiany znaczenia zapytania starannie crafting parametry. W zależności od rodzaju i prawa dostępu do bazy danych, stosowane, zmodyfikowane zapytanie może być używany do pobierania informacji poufnych z bazy danych lub wykonanie kodu. MS SQL i PostgreSQL, który wspiera wiele oświadczeń, może zostać wykorzystana, jeśli dostęp do bazy danych prawo jest bardziej wydajny.
Cross site scripting without brackets(Hard)
Cross-site scripting lub HTML injection jest możliwe bez "<" i ">". Skrypt może być wstrzykiwany w przeglądarce, który wydawał się być prawdziwą zawartość z oryginalnej strony. Skrypty te mogą być wykorzystane do wykonania dowolnego kodu lub kradzieży poufnych informacji klientów, takich jak hasło użytkownika lub ciasteczka.
Bardzo często jest to w formie hiperłącza z wtryskiwanego skrypcie osadzone w kwerendzie ciągów. Jednak XSS jest możliwe poprzez danych POST formularz, ciasteczka, dane użytkownika wysyłane od innego użytkownika lub danych udostępnionych pobieranych z bazy danych.
Parametr tampering(Medium)
Pewien parametr spowodowane strona błędu lub StackTrace Java ma być wyświetlany. Wskazuje to na to brak obsługi wyjątków i obszarów potencjalnych dalszych exploita.
Cookie set without HttpOnly flag(Low)
Cookie został ustawiony bez flaga HttpOnly, co oznacza, że ciasteczko może być udostępnione przez JavaScript. Złośliwy skrypt można uruchomić na tej stronie, a następnie plik cookie będzie dostępny i może zostać przekazany do innej witryny. Jeśli jest to plik cookie sesji następnie porwanie sesji może być niemożliwe.
Password Autocomplete in browser(Low)
Autouzupełnianie atrybut nie jest wyłączona w formularzu HTML / INPUT elementu zawierającego wejście typu hasło. Hasła mogą być przechowywane w przeglądarkach i odzyskane.
Projekt firewalla dla sieci przedsiębiorstwa
a)schemat zapory sieciowej
Rysunek przedstawia ogólny schemat firewalla. Nasza zapora działać będzie zaporą filtrującą czyli będzie monitorować przesyłane pakiety i przepuszczać tylko te które są zgodne z regułami ustawionymi na zaporze. W naszym przypadku będą to : web, bezpieczny zdalny dostęp, bazy danych, serwery DNS, poczta elektroniczna, serwery plików, sieć użytkowników.
b)Schemat połączeń
Źródło | Cel | Obsługa | Akcja |
---|---|---|---|
Poczta www | Bezpieczny dostęp | Poczta: 993 Web: 443, 80 |
Permit |
Any | Poczta WWW | Any | Permit |
Bazy danych | Poczta WWW |
Bazy danych: 1433 | Permit |
Bazy danych | Sieć użytkowników | Bazy danych: 1433 | Permit |
Bazy danych | Bezpieczny dostęp | Bazy danych: 1433 | Permit |
Sieć użytkowników | Poczta WWW | Sieć użytkowników: Any | Permit |
Sieć użytkowników | Bazy danych | Sieć użytkowników: Any | Permit |
Sieć użytkowników | Bezpieczny dostęp | Sieć użytkowników: Any | Permit |
Sieć użytkowników | Any | Any | Permit |
Bezpieczny dostęp | Poczta www |
Bezpieczny dostęp: 443 | Permit |
Bezpieczny dostęp | Bazy danych | Bezpieczny dostęp: 443 | Permit |
Bezpieczny dostęp | Sieć użytkowników | Bezpieczny dostęp: 443 | Permit |
Any | Any | Any | Drop |
Tabela dla reguł firewalla
4)Wnioski
Zapora sieciowa zapewnia bezpieczeństwo wewnątrz sieci. Nie zezwala na realizację zewnętrznych żądań nawet jeśli korzystamy z adresu IP dzięki, któremu jesteśmy przez serwer traktowani na równi z użytkownikami sieci. Dzięki takim programom jak OWASP ZAP możemy monitorować ataki, śledzić-mamy dostęp do szczegółowych statystyk. Przeprowadziliśmy serię ataków z których jedne się powiodły inne nie.
Dzięki temu laboratorium mamy świadomość jak ważny jest dobrze zaprojektowany firewall . Jesteśmy świadomi luk w sieci i możemy im skutecznie przeciwdziałać. Nasza wiedza została uzupełniona o informacje bezpieczeństwo sieci wygląda od strony „hakera”