przegladarka-www-okno

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:

Domeny

Mariusz Kołacz

Skomentuj wpis - Komentarzy (11)

  1. Mariusz Kołacz pisze:

    W związku z pytaniem, które pojawiło się chwilę temu na priv odpowiadam w komentarzu.
    Pytanie dotyczyło błędu 500.

    W linijce RewriteCond, Version w pierwszym przykładzie zostało niestety przeniesione do nowej linii. RewriteCond umieszczamy w pliku htaccess w jednej linii, jeżeli tego nie zrobimy, serwer zwróci błąd 500. Oczywiście dotyczy to także SetEnvIfNoCase, jeżeli doszło do podziału wiersza.

    Niestety taki urok stron responsywnych, tabelki z kodem będą w pewnych sytuacjach przerzucały część tekstu do nowej linii.

    Pozdrawiam!

  2. Michał pisze:

    Dzięki za poradnik!

  3. Krzysztof pisze:

    Proste rozwiązanie twojego problemu z przerzucaniem fragmentu tekstu do nowej linii - numerowanie wierszy w tabelkach z kodem ;-)

  4. Mariusz Kołacz pisze:

    @Krzysztof, racja, czemu ja na to wcześniej nie wpadłem :P Zobaczę, może są jakieś ciekawe wtyczki do tego.

  5. Grizz pisze:

    Jak moge założyć blokadę na adres IP lub kilka adresów IP?

  6. Ola pisze:

    Dzięki nie wiedziałam że to takie proste :D

  7. Mariusz Kołacz pisze:

    Z adresami IP jest bardzo podobnie.

    order allow,deny
    allow from all
    deny from ADRESIP

  8. Kasia pisze:

    Ciekawy poradnik ! Oby takich więcej :)
    Pozdrawiam

  9. Robert pisze:

    Jak zrobić żeby co drugie wejście na stronę kończyło się komunikatem Forbidden 403? Dostałem takie zadanie na kolokwium i próbuję to rozgryźć :/

  10. Mariusz Kołacz pisze:

    @Robert, hmm ciekawy topik, coś więcej możesz zdradzić?

  11. Karol pisze:

    Dzięki zrobiłem i działa wyśmienicie.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Poinformuj mnie o nowych komentarzach do tego wpisu.