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

1. 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

1. Testowanie aplikacji „superVEDA”

1. Wykaz podatności aplikacji SuperVeda

Podatności aplikacji SuperVeda

1. 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

1. 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.

1. 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”