Sprawozdanie

Z przedmiotu 

Podstawy Bezpieczeństwa Informacji

Laboratorium 3 – 4

Sprawozdanie wykonali:

Robert Nawrot
Maciej Gudanowicz

Grupa I9M1S1

1. Projekt sieci przedsiębiorstwa

Pierwszym ćwiczeniem było stworzenie projektu sieci przedsiębiorstwa. Projekt miał 

uwzględniać usługi takie jak: web, bezpieczny zdalny dostęp, baza danych, serwery DNS, poczta 
elektroniczna, serwery plików, sieć użytkowników.

Poniżej nasz projekt sieci:

Do projektu dołączamy przykładowe ustawienia firewalli:

Source

Destination

Action

LAN

Internet

Permit

LAN

Serwer DB

Block

LAN

Poczta

Permit

LAN

Serwery DNS

Permit

LAN

Serwer plików

Block

LAN

Serwer Web

Permit

Internet

LAN

Block

Internet

Serwer DB

Block

Internet

Poczta

Permit

Internet

Serwery DNS

Permit

Internet

Serwer plików

Block

Internet

Serwer Web

Permit

Serwer Web

Serwer DB

Permit

Serwer Web

Serwer plików

Permit

Serwer Web

LAN

Block

ANY

ANY

Block

Wnioski:

Dla zapewnienia najlepszej możliwej ochrony przed atakami należy podzielić projektowaną 

sieć na strefy ochronne. Strefę współdzielą ze sobą elementy sieci, które wymagają takiego samego 
poziomu ochrony. Najsłabiej chroniona jest tak zwana strefa zdemilitaryzowana. Znajdują się w niej 
zasoby, które muszą być dostępne z internetu, takie jak serwer poczty, serwer DNS, serwer web 
oraz bezpieczny zdalny dostęp. Za kolejnym firewallem znajdują się strefy o najwyższym stopniu 
bezpieczeństwa: strefa DB oraz strefa LAN. Taki układ sieci zapewnia dobrą odporność na ataki a 
przy tym umożliwia na zdalny dostęp do zasobów przedsiębiorstwa poprzez zdalny dostęp.

2. Wykonanie ataków na aplikację SuperVEDA

Drugim zadaniem było przeprowadzenie kilku ataków na aplikację SuperVEDA, ataki SQL 

Injection oraz XSS. Następnie próba powtórzenia tych ataków przy włączonym firewallu aplikacji.

Po podłączeniu się do aplikacji rozpoczęliśmy od ataku SQL Injection na stronie showproducts.asp.
Luką w zabezpieczeniach jaką tutaj wykorzystaliśmy była podatność na wprowadzenie kodu SQL 
do adresu URL przeglądarki. Do adresu strony dodaliśmy następujący kod SQL:

UNION SELECT * FROM users WHERE 1=1

Został wygenerowany błąd mówiący o nieprawidłowej ilości argumentów. Następnie 
powtarzaliśmy zapytanie dla coraz większej liczby argumentów. Dla sześciu argumentów 
wygenerowany został błąd o nieprawidłowym typie argumentów. Po kilku próbach znaleźliśmy 
poprawną kombinację argumentów w zapytaniu:

UNION SELECT 1, '1', 1, 1, '1', '1' FROM users WHERE 1=1

Następnie podmieniliśmy pierwszy argument typu tekstowego na nazwę kolumny tabeli users 
przechowującej nazwy użytkowników:

UNION SELECT 1, username, 1, 1, '1', '1' FROM users WHERE 1=1

Zapytanie to wygenerowało następującą tabelę:

Zdobyliśmy również hasła użytkowników, które przechowywane były w niezaszyfrowanej postaci:

Następnie również metodą SQL Injection zaatakowaliśmy stronę dosearch.asp. Do pola 
wyszukiwania wpisaliśmy następujący kod SQL:

' UNION SELECT 1, 1, password, '1', 1, 1, '1' FROM users WHERE '%'='

To również poskutkowało wyświetleniem listy haseł użytkowników:

Ostatni atak SQL injection wykonaliśmy na stronie login.asp. Ze względu na to, że aplikacja 
wysyłając zapytanie do bazy sprawdza jedynie czy zostały zwrócone jakiekolwiek rekordy a nie ich 
ilość, należało w pole username i password wpisać takie wartości aby poskutkowało to zwróceniem 
całej tabeli użytkowników. Do pól wpisaliśmy:

' OR ”='

Co poskutkowało zalogowaniem się na konto pierwszego użytkownika z tabeli. W naszym 
przypadku było to konto użytkownika Mickey.

Następnie przeszliśmy do ataku Cross Site Scripting. Techniki tej użyliśmy w formularzu kontaktu 
z administratorem strony contactus.asp. Wypełniając formularz kontaktowy wpisaliśmy do pola text 
kod mający na celu symulację działania złośliwego kodu wprowadzonego przez intruza:

<script>alert(„Przekierowanie administratora na strone intruza”)</script>

Po wysłaniu wiadomości zalogowaliśmy się na panel administratora i weszliśmy na stronę 
Messages Review. Po kliknięciu na wysłaną wiadomość pojawiło się okno:

Następnie włączony został firewall aplikacji a naszym zadaniem była próba powtórzenia 
wcześniejszych ataków. Niestety nie udało nam się to, firewall wyłapał każdy nasz atak. Zarówno 
na stronę showproducts.asp:

Jak i na stronę dosearch.asp:

Poniżej prezentujemy również screen z panelu firewalla ilustrujący powiadomienie o próbie ataku 
SQL injection:

Wnioski:

Zadanie laboratoryjne pokazało jak poważne niebezpieczeństwo stanowią ataki typu SQL 

injection oraz XSS. Pozwalają one na pozyskanie poufnych danych z bazy aplikacji bądź na 
wykonanie kodu na komputerach innych użytkowników aplikacji. Po uruchomieniu firewalla 
aplikacji nie udało nam się skutecznie przeprowadzić ataku, co nie znaczy, że jest on niemożliwy. 

Nie należy w kwestiach bezpieczeństwa polegać jedynie na jednym rozwiązaniu. Gdyby 

firewall z jakiegoś powodu przestał poprawnie działać aplikacja tego typu była by podatna na 
wszelkiego rodzaju ataki.

Zamiast tego należy starać się napisać jak najbezpieczniejszą aplikację i dodatkowo 

wzmocnić ją firewallem. Można np. używać sparametryzowanych zapytań do bazy lub przed 
wykonaniem zapytania sprawdzić czy pole tekstowe zawiera wyłącznie znaki alfanumeryczne.