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

Accept: application/x-shockwave-flash, dla uwierzytelnienia podstawowe- Serwer proxy wewnętrznie spraw-
text/xml,application/xml,*/*;q=0.1\rn go i pokazuje nam login, aby wpro- dza, że rzeczywiście nazwa użyt-
Accept-Language: wadzić wymagane dane. Ilustruje to kownika i hasło są ważne i przyznaje
en-us,en;q=0.7,es;q=0.3\rn Rysunek 9. nam dostęp do zasobu.
Accept-Encoding: gzip,deflate\rn Niektóre przeglądarki nie inter-
Accept-Charset: pretują prawidłowo  realm dlatego HTTP/1.0 200 OK\rn
ISO-8859-1,utf-8;q=0.7,*;q=0.7\rn też w niektórych rzeczywiście bę- Cache-Control: private\rn
Keep-Alive: 300\rn dzie widać we wcześniej pokazanej Content-Type: text/html\rn
Proxy-Connection: keep-alive\r\n ramce wiadomość  Proxy Authen- Content-Encoding: gzip\rn
tication (user/passwd) , ten akurat Server: GWS/2.1\rn
Proxy odpowiada nam wskazując, przypadek jest inny, ale będzie nam Content-Length: 1408\rn
że musimy to potwierdzić, aby móc służył jako przykład. Date: Mon, 16 Jan 2006 13:05:40 GMT\rn
przeglądać internet. Wprowadzamy nazwę użytkow- X-Cache: MISS from filter\rn
nika i hasło, a nasz klient wysyła na- Proxy-Connection: keep-alive\r\n
HTTP/1.0 407 stępujące dane zwrotne do proxy.
Proxy Authentication Required\rn Zamiast odpowiadać kodem 401
Server: squid/2.5.STABLE12\rn GET HTTP, w przypadku serwera proxy,
Mime-Version: 1.0\rn http://www.google.com/ HTTP/1.1\rn pokazuje się kod 407 (wymagane
Date: Mon, 16 Jan 2006 13:01:19 GMT\rn Host: www.google.com\rn uwierzytelnienie przez proxy) a do-
Content-Type: text/html\rn
Content-Length: 3283\rn
Expires:
Mon, 16 Jan 2006 13:01:19 GMT\rn
X-Squid-Error:
Rysunek 7. Ramka Live HTTP
Rysunek 8. Ramka Live HTTP Headers
Headers
www.hakin9.org
6 hakin9 Nr 4/2006
Uwierzytelnianie HTTP
Podsumowanie Tabela 1. Uwierzytelnianie serwera sieciowego i
uwierzytelnianie proxy.
Serwer sieciowy Serwer Proxy.
kod stanu bez autoryzacji: 401 kod stanu bez autoryzacji: 407
WWW-authenticate Proxy-Authenticate
Authorization Proxy-authorization
Rysunek 9. Ramka Live HTTP
Authentication-Info Proxy-Authentication-Info.
Headers
może narazić bezpieczeństwa in-
dawany nagłówek w przypadku ser- dostępu przy użyciu SSL, bezpiecz- nych systemów.
wera sieciowego WWW-authentica- ne połączenia szyfrowane w sieci Ludzie dążą do tego, żeby wy-
te, teraz dla proxy brzmi Proxy-Au- (IPSEC), programy z bezpiecznym korzystywać tę samą nazwę użyt-
thenticate. A cały proces jest iden- logowaniem, itp, jeżeli tylko jeden z kownika i hasło do różnych celów,
tyczny jak w przypadku dostępu do zasobów używa tej formy uwierzy- przez co pomimo tego, że używa-
ograniczonego zasobu sieciowe- telniania, mielibyśmy natychmiasto- ne będą w środowiskach zaufanych
go, z wyłączeniem tych minimalnych wy dostęp do wszystkich dostępnych i w przypadku dostępu do informa-
różnic. serwisów. cji nie wrażliwej, zawsze istniało-
Idealnym polem do wdrażania i by ryzyko, że te same uwierzytel-
Ogólne spojrzenie na
używania tego rodzaju uwierzytel- nienia dałyby nam dostęp do waż-
uwierzytelnianie HTTP
niania byłby na przykład dostęp do niejszych serwisów jak poczta elek-
Schemat uwierzytelniania podsta- statystyk użycia danego serwera troniczna, prywatne dokumenty czy
wowego nie jest bezpieczną meto- lub dostęp do jakiegokolwiek zaso- bazy danych.
dą uwierzytelniania użytkowników. bu, jeżeli sądzimy, że bezprawny do- Mając sniffera sieciowego i kilka
Nie ochrania w żaden sposób toż- stęp do niego, nie niesie za sobą po- skryptów odpowiednich do interpre-
samości użytkownika, która przeka- tencjalnego zagrożenia. W połącze- towania przechwyconego ruchu, w
zywana jest poprzez sieć jako zwy- niu z tym, uwierzytelnienia dostępu przeciągu kilku minut możliwe jest
kły tekst. HTTP z drugiej strony nie muszą zostać dostarczone przez ad- otrzymanie setek par  użytkownik/
unika użycia dodatkowych sche- mina strony lub przez program gene- hasło metodą opisaną powyżej.
matów uwierzytelnienia i mechani- rujący. Nigdy nie może wybierać ich Przy uwierzytelnianiu HTTP, hasła
zmów szyfrowania, zastosowanych użytkownik, jako że znalez
libyśmy podróżują po sieci jawnie, a w trak-
do zwiększenia lub polepszenia bez- się znowu z tym samym, wcześniej- cie połączenia nagłówki z hasła-
pieczeństwa uwierzytelnienia pod- szym problemem. Ludzie nie mają mi przeciętnie podróżują więcej niż
stawowego. zwyczaju używać różnych uwierzy- raz. W trakcie trwania połączenia,
Mimo słabości tego rodzaju uwie- telnień do różnych serwisów, ale wy- wysyłane są ponownie w przypad-
rzytelnienia, jak mogliśmy zobaczyć korzystują je wielokrotnie. ku każdej kolejnej przeprowadzo-
wcześniej, metody tej używa się w nej transakcji. Jest to związane z
różnych środowiskach, gdzie naj- Zakończenie właściwością protokołu HTTP, któ-
większym zagrożeniem jest istnie- Uwierzytelnienie podstawowe ry nie zachowuje stanu i koniecz-
nie Single Sign On, to znaczy twoje HTTP jest proste i wygodne, ale nie ne jest przypomnienie danych, któ-
uwierzytelnienia służą ci do potwier- jest to metoda bezpieczna. Należy re dostarcza się, w trakcie każde-
dzenia dostępu do jakiegokolwiek jej używać w przypadkach, gdy do- go połączenia, które realizujowane
zasobu w sieci. W ten sposób jest w stęp do informacji ma mieć charak- jest z serwerem sieciowym lub pro-
zasadzie wszystko jedno, czy użyte ter prywatny, a nie absolutnie ko- xy. Aby ulepszyć ten sposób uwie-
zostaną mechanizmy bezpiecznego nieczny i tam, gdzie jego użycie nie rzytelniania lub zastąpić go inny-
mi, bardziej bezpiecznymi metoda-
mi należałoby:
W Sieci
" http://livehttpheaders.mozdev.org/  Plugin dla mozilli.
" połączyć go z SSL, aby wzmoc-
" ftp://ftp.isi.edu/in-notes/rfc2617.txt  Uwierzytelnianie HTTP: uwierzytelnianie do-
nić bezpieczeństwo kodując
stępu Basic i digest
wszystkie dane transmisji
" http://www.faqs.org/rfcs/rfc2045.html  Kodowanie transferu zawartości w Ba-
se64 " zastąpić uwierzytelnieniem di-
" http://httpd.apache.org/docs/1.3/howto/auth.html  Konfiguracja apache, aby żą- gest
dał uwierzytelniania.
" użyć Kerberos
" http://rfc.sunsite.dk/rfc/rfc2617.html  RFC 2617
" Usunąć je z miejsc, gdzie nie jest
potrzebne l
www.hakin9.org hakin9 Nr 4/2006 7