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…
- 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ą.
- 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.
- 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
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!
Dzięki za poradnik!
Proste rozwiązanie twojego problemu z przerzucaniem fragmentu tekstu do nowej linii – numerowanie wierszy w tabelkach z kodem 😉
@Krzysztof, racja, czemu ja na to wcześniej nie wpadłem 😛 Zobaczę, może są jakieś ciekawe wtyczki do tego.
Jak moge założyć blokadę na adres IP lub kilka adresów IP?
Z adresami IP jest bardzo podobnie.
order allow,deny
allow from all
deny from ADRESIP
Dzięki nie wiedziałam że to takie proste 😀
Ciekawy poradnik ! Oby takich więcej 🙂
Pozdrawiam
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źć :/
@Robert, hmm ciekawy topik, coś więcej możesz zdradzić?
Dzięki zrobiłem i działa wyśmienicie.
Da radę w inny sposób? U mnie nie chce działać. Serwer litespeed.