[hackpl] problemy z, e-book
[ Pobierz całość w formacie PDF ]
Problemy z
uwierzytelnianiem HTTP
Praktyka
Emilio Casbas
stopień trudności
Protokół HTTP, oferuje nam mechanizm uwierzytelniania żądanie-
odpowiedź, który może zostać użyty przez serwer sieciowy
lub serwer proxy, do umożliwiania lub odmawiania dostępu do
zasobów sieciowych.
transakcji oraz udostępniane są dane
prywatne oraz poufne. Sieć to wszyst-
ko umożliwia, ale konieczne jest także zacho-
wania bezpieczeństwa, musimy wiedzieć kto
ma dostęp do naszych wrażliwych danych i kto
może realizować działania uprzywilejowane.
Musimy wiedzieć, że nieupoważnieni użyt-
kownicy, nie mogą obejrzeć dokumentów, do
których nie mają dostępu. Serwery muszą w ja-
kiś sposób dowiedzieć się, kim jest każdy użyt-
kownik i na tej podstawie zdecydować jaki ro-
dzaj działań mogą podjąć.
Uwierzytelnianie to technika identyikacji
oparta na znajomości, to znaczy na czymś, co
zna użytkownik, jak na przykład haśle lub nu-
merze PIN. HTTP dostarcza naturalną funkcjo-
nalność do uwierzytelniania HTTP. W rzeczy-
wistości HTTP deiniuje dwa oicjalne protokoły
uwierzytelniania: uwierzytelnianie podstawowe
oraz uwierzytelnianie digest. Tutaj skoncentru-
ję się szczególnie na metodzie uwierzytelniania
podstawowego, która jest szerzej wykorzysty-
wana przez klientów i serwery sieciowe, a tak-
że mniej bezpieczna.
Obszary stosowania tej metody uwierzy-
telniania:
• Serwery sieciowe w internecie - tu znaleźli-
byśmy się w najbardziej powszechnej sytu-
acji. Użytkownik z domu, za pośrednictwem
zwykłego połączenia lub z kafejki interneto-
wej wchodzi na serwer sieciowy na którym
skonigurowano uwierzytelnianie HTTP,
aby uzyskać dostęp do pewnych jego ob-
szarów. Przeglądając choćby kilka korpo-
racyjnych stron internetowych, możemy za-
obserwować wielką ilość stron, które wy-
korzystują ten rodzaj uwierzytelniania, aby
przejść do zastrzeżonych części strony.
Z artykułu dowiesz się...
• Różne zakresy uwierzytelniania HTTP
• Różnice w zatwierdzaniu HTTP w różnych ob-
szarach
• Przykłady praktyczne konwersacji HTTP
• Słabości uwierzytelniania
• Rozwiązania lub alternatywy
Powinieneś wiedzieć...
• Model OSI
• Znajomość protokołu HTTP
2
hakin9 Nr 4/2006
www.hakin9.org
O
becnie w sieci dokonują się miliony
Uwierzytelnianie HTTP
Krótkie wprowadzenie do uwierzytelniania
Uwierzytelnianie digest:
growany z innymi mechanizma-
mi istniejącymi w tej sieci intrane-
towej. Pogarszając problem Sin-
gle Sign On, którym zajmiemy się
później.
• Celem uwierzytelniania digest, jest nie wysyłanie nigdy hasła przez sieć”, w tym ce-
lu wysyła na serwer “podsumowanie” lub “ślad” hasła w sposób nieodwracalny.
• Uwierzytelnianie digest zostało rozwinięte w sposób zgodny i jako bezpieczniej-
sza alternatywa w stosunku do uwierzytelniania podstawowego, ale nie jest to je-
den z protokołów zwanych bezpiecznymi, porównywanymi do tych, które stosują
mechanizmy klucza publicznego (SSL) lub mechanizmy wymiany biletów (kerbe-
ros). Uwierzytelnianie digest nie posiada silnego uwierzytelniania, ani nie oferu-
je ochrony poufności poza ochroną hasła, pozostała część żądania i odpowiedzi
przechodzą jako zwykły tekst.
Przykład praktyczny
Od tego momentu wiemy już, czym
jest uwierzytelnianie HTTP i jakie
są kolejne kroki jego działania, w
tej chwili przyjrzymy się tym etapom
bardziej wnikliwie i w sposób prak-
tyczny, przy użyciu naszej przeglą-
darki internetowej mozilla. Będzie
nam do tego potrzebne rozszerze-
nie aby przechwycić nagłówki HTTP,
które realizujemy.
Potrzebne nam rozszerzenie na-
zywa się
livehttpheaders
i można je
ściągnąć z
ozdev.org/
. Instalujemy je wykonując
kroki opisane na stronie, a następnie
w mozilli pojawi się opcja Live HTTP
Headers, widoczna na Rysunku 6.
Klikamy na tę nową opcję a wte-
dy pojawi się następująca ramka wi-
doczna na Rysunku 2.
Od tego momentu będziemy
otrzymywać wszystkie informacje
o nagłówkach HTTP ze wszystkich
stron po których surfujemy, w ten
sposób zdołaliśmy przechwycić na-
główki, które wyjaśnione są poniżej.
Uwierzytelnianie podstawowe:
• Uwierzytelnianie podstawowe jest jednym z częściej używanych protokołów uwie-
rzytelniania HTTP. Wdraża je większość klientów i serwerów sieciowych. Najlepiej
jest najpierw zobaczyć opis rysunkowy, żeby zorientować się, czym ono jest.
• Poniżej szczegółowo wytłumaczymy wcześniejsze kroki uwierzytelniania HTTP.
• Użytkownik ubiega się o jakiś zasób sieciowy (na przykład obrazek)
• Serwer sprawdza, że jest to zasób chroniony i wysyła klientowi żądanie o hasło z
nagłówkiem HTTP “Authorization Required” i kodem 401.
• Przeglądarka użytkownika otrzymuje kod i nagłówek uwierzytelnienia i pokazuje
dialog użytkownik/hasło. Kiedy użytkownik wprowadza dane, przeglądarka prze-
prowadza kodowanie na base64 z wprowadzonymi danymi i przesyła je na serwer
w nagłówku użytkownika „Authorization”.
• Serwer dekoduje nazwę użytkownika i hasło oraz sprawdza, że ma on dostęp do
chronionego zasobu.
Jak można stwierdzić, uwierzytelnienie podstawowe przesyła parę użytkownik:hasło w
postaci nie szyfrowanej z przeglądarki na serwer i jako takie, nie powinno być używane
dla wrażliwych loginów, o ile nie pracuje się w środowisku szyfrowanym, takim jak SSL.
• Serwery sieciowe w intranecie- w
tym przypadku obszar zastoso-
wania jest mniejszy, jako że jest
on ograniczony jedynie do intra-
netu irmowego, ale problemy
związane z tym rodzajem uwie-
rzytelniania są takie same jak
omawiane wcześniej, jakikolwiek
zasób dostępny wewnątrz sieci
będzie tak samo narażony.
• Serwery proxy w internecie - mo-
że także zajść przypadek, gdy
na przykład, żeby surfować po
niektórych zasobach określonej
sieci, można to robić tylko przez
serwer proxy tej instytucji lub aby
kontrolować jakikolwiek rodzaj
dostępu. Dlatego uwierzytelnia-
nie HTTP może także być wdro-
żone w proxy, aby wszystkie da-
ne szły także przez internet.
• Serwery proxy w intranecie - bar-
dzo popularna jest również sy-
tuacja, gdy wewnątrz sieci kor-
poracyjnych jedyną możliwością
dostępu do internetu jest dostęp
przez serwer proxy, co ma na ce-
lu całkowite kontrolowanie użyt-
kowania internetu. Dlatego też
ustawienie serwera proxy, aby
żądał potwierdzania w celu kon-
troli dostępu użytkowników do
sieci, jest całkowicie naturalne w
tym przypadku. Z reguły ten ro-
dzaj potwierdzenia będzie zinte-
Nagłówki i wyjaśnienie
Klient wysyła standardowe żądanie
HTTP prosząc o dany zasób.
GET /doc/ecasbas/ HTTP/1.1\rn
Host: www.prueba.es\rn
User-Agent: Mozilla/5.0
(Windows; U;
Rysunek 1.
Serwery sieciowe w Internecie
www.hakin9.org
hakin9 Nr 4/2006
3
Praktyka
Keep-Alive: 300\rn
Connection: keep-alive\rn
Authorization:
Basic ZWNhc2JhczpwcnVlYmE=\rn
Następnie serwer porównuje in-
formację od klienta ze swoją listą
użytkowników/haseł. Jeżeli autory-
zacja szwankuje, serwer znowu wy-
śle nagłówek wymaganego uwie-
rzytelnienia HTTP 401. Jeżeli wpro-
wadzone dane są prawidłowe, ser-
wer pokarze żądany zasób. Po tym
serwer przechodzi do żądanego za-
sobu.
Rysunek 2.
Serwery sieciowe w Intranecie
HTTP/1.0 200 OK\rn
Date: Mon, 16 Jan 2006 11:17:58 GMT\rn
Server: Apache/2.0.55 (Unix)
mod_ssl/2.0.55
OpenSSL/0.9.7g PHP/5.1.1\rn
Last-Modiied:
Fri, 13 Jan 2006 10:31:02 GMT\rn
ETag: "125b019-5-f636a580"\rn
Accept-Ranges: bytes\rn
Content-Length: 5\rn
Content-Type: text/html\rn
X-Cache:
MISS from www.prueba.es\rn
Connection: keep-alive\rn
Windows NT 5.1; en-US; rv:1.7.12)
Accept: text/xml,text/html;q=0.9,
text/plain;q=0.8,
image/png,*/*;q=0.1\rn
Accept-Language: en-us,en;
q=0.7,es;q=0.3\rn
Accept-Encoding: gzip,delate\rn
Accept-Charset: ISO-8859-1,
utf-8;q=0.7,*;q=0.7\rn
Keep-Alive: 300\rn
Connection: keep-alive\rn
sword pokazując nazwę hosta i re-
alm. Ilustruje to rysunek 3.
Klient odeśle żądanie z wpro-
wadzonymi danymi o użytkowniku/
haśle
GET /doc/ecasbas/ HTTP/1.1\rn
Host: www.unav.es\rn
User-Agent: Mozilla/5.0
(Windows; U; Windows NT 5.1;
en-US; rv:1.7.12)
Accept: text/tml+xml,text/html,
image/jpeg,image/gif;
q=0.2,*/*;q=0.1\rn
Accept-Language:
en-us,en;q=0.7,es;q=0.3\rn
Accept-Encoding: gzip,delate\rn
Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7\rn
Serwer czyta swoje archiwum
ustawień i określa, że żądany za-
sób jest chroniony hasłem. Serwer
może udostępnić go tylko znanym
użytkownikom.Wtedy serwer odpo-
wiada klientowi żądaniem autory-
zacji oznaczając to kodem HTTP
401.
We wcześniejszych polach widzieli-
śmy pola specjalne, które zostały do-
dane do różnych nagłówków HTTP.
W etapie 3, kiedy serwer wysyła od-
powiedź z nagłówkiem 401, zawarte
HTTP/1.0 401 Unauthorized\rn
Date:
Mon, 16 Jan 2006 11:17:51 GMT\rn
Server: Apache/2.0.55 (Unix)
mod_ssl/2.0.55 OpenSSL/0.9.7g
PHP/5.1.1\rn
WWW-Authenticate:
Basic realm="ByPassword"\rn
Accept-Ranges: bytes\rn
Content-Length: 3174\rn
Content-Type: text/html\rn
X-Cache:
MISS from www.prueba.es\rn
Connection: keep-alive\rn
Przeglądarka klienta interpretuje ten
kod HTTP 401 jako żądanie do uwie-
rzytelnienia, i wtedy przeglądarka
pokazuje prompt użytkownik:pas-
Rysunek 3.
Serwery proxy w Internecie
4
hakin9 Nr 4/2006
www.hakin9.org
Uwierzytelnianie HTTP
Listing 1.
Kod perl do
dekodowania łańcucha w
base64 jak wcześniej
#!/usr/bin/perl
use MIME::Base64;
while (<>) {
print MIME::Base64::deco-
de_base64($_);
}
Rysunek 4.
Serwery proxy w Intranecie
Obydwa rodzaje uwierzytelnień
“digest” i “basic” używane są przez
klientów i serwery sieciowe, jednak
nie należy ich używać jako stopnia
ochrony informacji wrażliwych lub
bezpiecznego dostępu. Bardzo po-
wszechne jest stosowanie tej samej
nazwy użytkownika i hasła do róż-
nych serwisów, w tym przypadku na-
leży pamiętać o tym, żeby zasoby,
które chcemy chronić w ten sposób,
nie były bardzo delikatne i żeby uwie-
rzytelnienia nie funkcjonowały w in-
nym użyciu jak np.: w poczcie lub do-
stępie do informacji prywatnych.
jest specjalne pole.
cje oktetów w sposób niekoniecznie
czytelny dla człowieka. Algorytmy
kodowania i dekodowania są proste,
ale zakodowane dane z reguły są o
33% większe, niż dane nie kodowa-
ne. Aby uzyskać więcej informacji o
takim kodowaniu warto skorzystać z
ramki
W sieci
.
Mając wcześniejszy kod oraz login
w zwykłym tekście, można w trywial-
ny sposób odkodować zapis do poniż-
szego formatu użytkownik:hasło.
WWW-Authenticate:
Basic realm="ByPassword"\rn
Wartość “Basic” pokazuje, że prosi-
my browser o użycie uwierzytelnie-
nia podstawowego. Informacja łań-
cucha “realm” jest łańcuchem ar-
bitralnym wysłanym, aby pokazać
użytkownikowi powiadomienie o ro-
dzaju uwierzytelnienia. Rysunek 3
pokazuje, jak okno dialogowe mozil-
li prosi o uwierzytelnienie pokazując
realm i hosta.
Użytkownik wypełnia formularz
i wysyła go. Przeglądarka automa-
tycznie odsyła prośbę. Jak poka-
zano wcześniej niektóre pola doda-
ne zostały do standardowego żąda-
nia HTTP.
Uwierzytelnianie proxy
Wcześniejsze sekwencje odno-
szą się do klienta proszącego ser-
wer sieciowy o dostęp do chronio-
nego zasobu. Ale można by to za-
stosować w przypadku, kiedy pro-
xy wymaga potwierdzenia, aby uzy-
skać dostęp do zasobu. Przyjrzymy
się również tej sytuacji oraz temu, ja-
kie kody pokazują się, kiedy w grę
wchodzi proxy.
Mając skonigurowany w naszej
ZWNhc2JhczpwcnVlYmE=
--> base64Decode() --> “ecasbas:próba”
Wdrożenie uwierzytelniania “digest”
to dokładnie taki sam proces, jak
przy wcześniejszym uwierzytelnia-
niu podstawowym, jedyna różni-
ca to liczba argumentów dostarczo-
nych przez przeglądarkę oraz for-
mat zwróconego loginu.
Authorization:
Basic ZWNhc2JhczpwcnVlYmE=\rn
Tu właśnie przeglądarka interneto-
wa wysyła informację o aktualnej au-
toryzacji na serwer. Widać, że pole
“Authorization” złożone jest z dwóch
wartości. Słowo “Basic” pokazuje,
jak login zostaje wysłany w zgodzie
z metodą uwierzytelnienia podsta-
wowego. Blok danych, który po nim
następuje to aktualny login wysła-
ny przez przeglądarkę. Nasze da-
ne dotyczące loginu nie pojawiają
się bezpośrednio, ale nie jest to szy-
frowanie, tylko kodowane w base 64.
Podsumowując, kodowanie w ba-
se64 przedstawia arbitralne sekwen-
Rysunek 5.
Uwierzytelnianie podstawowe
www.hakin9.org
hakin9 Nr 4/2006
5
Praktyka
Rysunek 6.
Opcja Live HTTP Headers
User-Agent: Mozilla/5.0
(Windows;
U; Windows NT 5.1;
en-US; rv:1.7.12)
Accept:
application/x-shockwave-lash,
text/xml,
image/gif;q=0.2,*/*;q=0.1\rn
Accept-Language:
en-us,en;q=0.7,es;q=0.3\rn
Accept-Encoding:
gzip,delate\rn
Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7\rn
Keep-Alive: 300\rn
Proxy-Connection:
keep-alive\rn
Proxy-Authorization:
Basic
ZWNhc2Jhc0B1bmF2Lm
VzOnBydWViYTAx\r\n
przeglądarce serwer proxy, składa-
my prośbę, aby móc surfować.
ERR_CACHE_ACCESS_DENIED 0\rn
Proxy-Authenticate: Basic realm=
""Proxy Authentication (user/passwd)""\
rn
X-Cache: MISS from proxy.es\rn
Proxy-Connection: keep-alive\rn
GET
Host: www.google.com\rn
User-Agent: Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7.12)
Accept: application/x-shockwave-lash,
text/xml,application/xml,*/*;q=0.1\rn
Accept-Language:
en-us,en;q=0.7,es;q=0.3\rn
Accept-Encoding: gzip,delate\rn
Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7\rn
Keep-Alive: 300\rn
Proxy-Connection: keep-alive\r\n
Wtedy nasza przeglądarka inter-
pretuje to jako żądanie/odpowiedź
dla uwierzytelnienia podstawowe-
go i pokazuje nam login, aby wpro-
wadzić wymagane dane. Ilustruje to
Rysunek 9.
Niektóre przeglądarki nie inter-
pretują prawidłowo “realm” dlatego
też w niektórych rzeczywiście bę-
dzie widać we wcześniej pokazanej
ramce wiadomość “Proxy Authen-
tication (user/passwd)”, ten akurat
przypadek jest inny, ale będzie nam
służył jako przykład.
Wprowadzamy nazwę użytkow-
nika i hasło, a nasz klient wysyła na-
stępujące dane zwrotne do proxy.
Serwer proxy wewnętrznie spraw-
dza, że rzeczywiście nazwa użyt-
kownika i hasło są ważne i przyznaje
nam dostęp do zasobu.
HTTP/1.0 200 OK\rn
Cache-Control: private\rn
Content-Type: text/html\rn
Content-Encoding: gzip\rn
Server: GWS/2.1\rn
Content-Length: 1408\rn
Date: Mon, 16 Jan 2006 13:05:40 GMT\rn
X-Cache: MISS from ilter\rn
Proxy-Connection: keep-alive\r\n
Proxy odpowiada nam wskazując,
że musimy to potwierdzić, aby móc
przeglądać internet.
HTTP/1.0 407
Proxy Authentication Required\rn
Server: squid/2.5.STABLE12\rn
Mime-Version: 1.0\rn
Date: Mon, 16 Jan 2006 13:01:19 GMT\rn
Content-Type: text/html\rn
Content-Length: 3283\rn
Expires:
Mon, 16 Jan 2006 13:01:19 GMT\rn
X-Squid-Error:
GET
Host: www.google.com\rn
Zamiast odpowiadać kodem 401
HTTP, w przypadku serwera proxy,
pokazuje się kod 407 (wymagane
uwierzytelnienie przez proxy) a do-
Rysunek 7.
Ramka Live HTTP
Headers
Rysunek 8.
Ramka Live HTTP Headers
6
hakin9 Nr 4/2006
www.hakin9.org
[ Pobierz całość w formacie PDF ]