Plik htaccess – Blokada dostępu do strony dla konkretnej przeglądarki

W komentarzu do wpisu o zabezpieczaniu CMS WordPress padło pytanie: W jaki sposób zablokować dostęp do witryny z poziomu .htaccess tylko dla konkretnej wersji przeglądarki. W niniejszym artykule przedstawię dwa rozwiązania, pierwsze bazujące na mod_setenvif, drugie na mod_rewrite. W tym miejscu można również zadać pytanie – dlaczego czytelnik chce blokować wejścia z konkretnej wersji przeglądarki? Powodów może być wiele…

1. Dana wersja przeglądarki posiada błędy, które uniemożliwiają prawidłowe wyświetlanie witryny lub dokonanie na niej innej akcji np. wyświetlenia filmu, przesłania formularza etc. Tak kilka lat do tyłu było z jedną z mobilnych wersji przeglądarek bazujących na silniku WebKit, która na jednej ze stron przez zmiany w renderowaniu „gubiła” pola w formularzu, mimo prawidłowego zakodowania strony/formularza. Akurat rozwiązania z blokowaniem odradzam, lepiej użytkownikowi przedstawić komunikat o niekompatybilnej przeglądarce z prośbą o jej „wymianę” na inną, ale na upartego idzie całkowicie zablokować użytkownika z „podpadniętą” przeglądarką.
2. Mamy wersję testową strony i chcemy, aby tylko użytkownicy korzystający na przykład z Opery czy Chrome mogli na nią wejść. Cóż… sytuacja wcale nie jest wyimaginowana i podczas tworzenia strony WWW możemy być zmuszeni do przetestowania witryny w ściśle określonych warunkach, przez ściśle określonych użytkowników legitymujących się konkretnymi UA Strings.
3. Mamy na stronie uciążliwego spamera lub trolla, który zawraca nam niepotrzebnie głowę i chcemy troszkę utrudnić im życie. O ile spamer odpuści temat, to już z trollem tak łatwo nie pójdzie, ale spróbować zawsze warto, htaccess może pomieścić wiele linijek kodu.

To najciekawsze scenariusze, chyba że coś mi umknęło 🙂

.htaccess i blokowanie konkretnej wersji przeglądarki

Większość przeglądarek internetowych identyfikuje danego użytkownika w oparciu o ciąg UA String (User Agent String). Mając do dyspozycji UA, możemy zablokować dostęp do strony, jednak użytkowników legitymujących się danym UA może być więcej, w związku z czym należy pamiętać, że i osobom postronnym możemy zablokować dostęp.

Dla przykładu, mając UA String w postaci:

Opera/9.80 (Windows NT 6.1; WOW64; U; en) Presto/2.10.229 Version/11.62

Reguła blokowania w .htaccess wygląda następująco:


<Limit GET POST HEAD>
SetEnvIfNoCase User-Agent "Opera/9\.80 \(Windows NT 6\.1; WOW64; U; en\) Presto/2\.10\.229 Version/11\.62" ban_bot
Order Allow,Deny
Allow from all
Deny from env=ban_bot
</Limit>


Limit GET POST HEAD – określamy dla jakiego typu żądania zostanie wykonana reguła blokowania, w tym przypadku zdefiniowane są 3 podstawowe: GET, POST i HEAD. Jeżeli nie sprecyzujesz metod w <Limit>, blokowanie będzie dotyczyło wszystkich wykonywanych requestów.

SetEnvIfNoCase – jedna z dyrektyw modułu serwera Apache mod_setenvif, wraz z aktywnym mod_headers pozwala utworzyć regułę blokowania i ją wykonać. SetEnvIfNoCase w odróżnieniu do SetEnvIf wykonuje komparację zdefiniowanych zmiennych nie zwracając uwagi na wielkość liter. W niektórych przypadkach, aby „odstrzelić” konkretnego użytkownika, będziesz musiał użyć SetEnvIf.

Order Allow,Deny – kolejność wykonywania reguł, w tym przypadku „przepuść wszystkie” (Allow from all) poza tymi uwzględnionymi w zmiennych (ban_bot). Czyli stronę będą mogli odwiedzić wszyscy użytkownicy, którzy posiadają UA String różny od tego, który zdefiniowałeś w zmiennej ban_bot.

Aby wykorzystać reguły blokowania z SetEnvIfNoCase / SetEnvIf serwer musi mieć aktywne moduły mod_setenvif i mod_headers. W innym przypadku będziemy musieli poradzić sobie nieco inaczej i wykorzystać reguły przepisywania, o ile administrator serwera włączył mod_rewrite.

Dla powyższego przykładu reguła blokowania wykorzystująca mod_rewrite wygląda następująco:


ErrorDocument 403 "Zostales zablokowany!"
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Opera/9\.80 \(Windows NT 6\.1; WOW64; U; en\) Presto/2\.10\.229 Version/11\.62" [NC] RewriteRule .* - [F,L]

ErrorDocument 403 – komunikat wyświetlany użytkownikowi, gdy nastąpi zablokowanie jego UA. Jeżeli nie wdrożysz obsługi błędów, serwer zwróci dodatkowo błąd HTTP 500.

RewriteEngine On – włączamy mechanizm przepisywania.

RewriteCond – warunek, który musi zostać spełniony, aby reguły umieszczone w RewriteRule zostały przetworzone i wykonane. W przykładzie UA występuje jako cały ciąg, który obejmujemy w cudzysłowy. Kropki oraz nawiasy okrągłe poprzedzone są znakiem ucieczki (escape string – backslash). Jeżeli w ciągu UA znajdziesz inne znaki interpretowane przez RewriteEngine, również i one musisz „opuścić”.

RewriteRule – reguły przepisywania adresów URL. W omawianym przykładzie [F] oznacza kod odpowiedzi serwera 403 Forbidden (alternatywnie możesz zastosować R=403), [L] oznacza, że mamy do czynienia z ostatnią regułą RewriteRule do wykonania.

W zaprezentowanych przykładach mamy do czynienia z blokowaniem całego ciągu, który musi zgadzać się z warunkiem blokowania. W jaki sposób zignorować wszystkie elementy, z wyjątkiem nazwy i wersji przeglądarki?

Wystarczy lekko zmodyfikować warunek w regułce, poniżej przykłady:

Wykorzystanie mod_setenvif…


<Limit GET POST HEAD>
SetEnvIfNoCase User-Agent "Opera/9\.80" ban_bot
Order Allow,Deny
Allow from all
Deny from env=ban_bot
</Limit>


Wykorzystanie mod_rewrite…


RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Opera/9\.80" [NC] RewriteRule .* - [F,L]

Inny przykład, gdzie naszym celem jest zablokowanie wszystkich użytkowników Firefox, którzy używają wersji 21. Przykładowy UA:

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0

Wykorzystanie mod_setenvif…


<Limit GET POST HEAD>
SetEnvIfNoCase User-Agent "Firefox/21\.0" ban_bot
Order Allow,Deny
Allow from all
Deny from env=ban_bot
</Limit>


Wykorzystanie mod_rewrite…


RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Firefox/21\.0" [NC] RewriteRule .* - [F,L]

Na zakończenie kilka dodatkowych pytań i odpowiedzi…

Jak sprawdzić User Agent przeglądarki?

Najprostszym sposobem sprawdzenia jest skorzystanie z dedykowanego narzędzia – Simple User Agent Checker.

W jaki sposób sprawdzić, czy blokada faktycznie działa?

Wystarczy, że zainstalujesz w przeglądarce dodatek typu User Agent Switcher (dostępny dla przeglądarek Firefox, Chrome, Opera) i zmienisz UA String przeglądarki na dokładnie ten, który dodałeś do blokowania. Jeżeli serwer zwróci kod błędu 403 lub zdefiniowany przez Ciebie komunikat – blokada działa!

Dodatek User Agent Switcher możesz pobrać z oficjalnych repozytoriów:

• Firefox – addons.mozilla.org
• Chrome – chrome.google.com
• Opera – addons.opera.com