Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

Причем, работает нормально HTTPS только в том случае, если для пользователя не произошло незаметной подмены сертификата (как это делает софт на подобии SecureTower). В случае, если сертификат подменяется незаметно или пользователя в открытую заставляют принять невалидный сертификат (т.к. иначе ничего не будет вообще) HTTPS работать перестает.

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

Давать возможность пользователю работать с сайтом по HTTPS можно, но заставлять нужно только тогда, когда шифрование реально необходимо: например, в интернет-банкинге. Дело в том, что у некоторых компаний могут быть закрыты исходящие соединения на 443-й порт, либо запрещен бинарный трафик.

HTTPS-трафик создает дополнительную нагрузку на сервер, прежде всего на процессор, а так же замедляет передачу информации пользователю. Этот еще два камня в его огород. Вывод: если нет острой необходимости, не нужно заставлять и, возможно, даже рекомендовать пользователю пользоваться HTTPS.

Как вариант, можно проводить по защищенному протоколу только авторизацию. Обычно пользователю дают возможность выбрать способ авторизации: защищенный или обычный. Тот, кому важна безопасноть, выберет защищенный способ при условии, что он для него технически доступен.

Но в этом случае большинству пользователей эта защита может оказаться непонятной и ненужной. Если мы хотим им помочь, то следует определить, доступен ли клиенту HTTPS автоматически и, в зависимости от результата, установить обычную авторизацию, либо защищенную. Только пользовалею надо сообщить о том, какой способ выбран (можно графически).

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

Хэшировать ли пароль? Это может иметь значение только в одном случае: если у пользователя один пароль на несколько сервисов. Тогда перехватчик не увидит пароля в открытом виде, чтобы использовать его на других сервисах. Но подобрать брутфорсом пароль все равно возможно. Только это уже не так тривиально, как подсмотреть в открытом виде. Так что если вы на стороне пользователя, постарайтесь пароль хэшировать до передачи.

А как делают другие?

Про Яндекс я уже рассказал. Добавлю, что пароль он передает в открытом виде и не пускает на главную страницу портала по HTTPS.

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

Google работает по HTTPS нормально. Пароль передает в открытом виде. Авторизацию по умолчанию предлагает защищенную. Способов определения, поддерживает  ли клиент HTTPS, я не нашел.

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

Детектить версии нужно только популярных в СНГ немобильных версий браузеров, поэтому в моем коде определяется только Opera, Firefox, Safari, Internet Explorer и Google Chrome. Если вам потребуется определить версии большего числа браузеров, код можно легко дополнить.

Чтобы не раскидывать функции по проекту, весь код я оформляю в классы. Создадим статический класс, в котором будут два метода: определение версии браузера и сравнение версии с данными барьерными версиями по каждому из браузеров. Назовем его BrowserUtils.

Класс состоит из двух методов: определение браузера и его версии и сравнении полученной версии с пороговыми версиями по разным браузерам. Использовать класс очень просто:

Единственный нюанс по коду есть у Safari. Все версии этого браузера всегда посылали в UserAgent тег Safari/build, где buld — версия их движка. Это большая первая цифра, например 528.16. Так версии Safari отображаются в Google Analytics. Но более поздние версии стали писать свою версию в теге Version. Выглядит это примерно так: Version/4.0.2.

Так как мне требовалось выводить версию пользователю, я использовал код считывания версии из тега Version, а для старых версий не детектит номер версии.

Скачать PHP-код определения версии браузера.

Очередная порция статистики (см. также «Статистика браузеров и разрешений») по рунету и байнету на базе 3-х сайтов компании, в которой я работаю. Обработана статистика за последний месяц (11.11.2007 — 11.12.2007) трех сайтов, два из которых белорусские, один — российский. Аудитория двух первых сайтов — специалисты финансовой и кадровой сферы (это сайты соответствующих изданий). Третий сайт посвящен поиску работы, поэтому его аудитория довольно широка. Преимущественно, все сайты посещаются с рабочих мест.

Статистика на этот раз коснется версии браузера и версии флеш-плеера у посетителя.

За 30 дней сайты посетили 166 800 уникальных посетителей. Подробная статистика доступна в отчете PDF, а пятерки лидеров по усредненным данным 3-х сайтов выглядят так:

Топ-5 браузеров:
1. Internet Explorer 69,68%
2. Opera 21,49%
3. Firefox 8,36%
4. Mozilla 0,25%
5. Safari 0,09%

Топ-5 версий флеш:
1. 9.0 60,23%
2. 6.0 12,24%
3. (not set) 10,21%
4. 8.0 5,26%
5. 7.0 6,38%

Прочитать этот документ можно в формате PDF (405,3Кб). Даные, на основе которых написана статья, так же можно посмотреть в полном объеме в формате PDF (872,9Кб).

Итак, о сайтах.

1) Первый сайт – это российский ресурс, форум для секретарей. Посещается в основном с рабочих мест. Аудитория 1.

2) Второй – белорусский портал по поиску работы. Аудитория 2.

3) Третий – российский сайт, который посещают специалисты по кадрам, секретарскому делу и финансам с рабочих мест. Аудитория 3.

4) Четвертый – белорусский сайт, который посещают специалисты по кадрам и финансам с рабочих мест. Аудитория 3.

Аудитория 2 наиболее выделяется из списка. В нее входят все группы пользователей, кроме пенсионеров, причем пользуются ресурсом, как с рабочих мест, так и из дому.

Все сайты обладают хорошей посещаемостью.

Грузить цифрами вас не буду. Сразу перейдем к результатам. Сначала ответим на два вопроса, очень важные для разработчика интерфейса: «под какое минимальное разрешение делать сайт» и «какими средствами (из JS, CSS, XHTML) можно пользоваться». С первым вопросом все предельно ясно. По второму поясню. Многий важный функционал JS появлялся в новых версиях браузеров и не поддерживается старыми. Старые браузеры так же не поддерживают последние версии XHTML и CSS. По этому, ориентируясь на старые браузеры, разработчик сильно ужимает себя в возможности использования современных средств.

«Под какое минимальное разрешение делать сайт?». Анализ собранной статистики, показал, что имеет смысл делать сайты под разрешение 1024х768 и выше. Разрешение 800х600 установлено у 6,27% пользователей, при этом у остальных – большие разрешения. А при просмотре сайта шириной 800 на разрешении 1440, например, явно ощущается дискомфорт. В то же время, слишком широкие сайты так же не очень удобно читать. Например, тянущийся дизайн при разрешении 1440х900 на всю ширину монитора не всегда удобен. На мой взгляд, оптимально делать тянущиеся дизайны с ограничением ширины от 955 (для 1024) до 1200 (для 1280). Тем же 6%, у кого установлено разрешение 800х600, придется пользоваться горизонтальным скроллингом и задуматься о смене монитора.

Результирующие диаграммы разрешений.

«Какими средствами (из JS, CSS, XHTML) можно
пользоваться?» Выше во вступлении описано, что подразумевается под этим вопросом – повторяться не буду. Перейду сразу к делу. 74,68% аудитории сайтов пользуются браузером Microsoft Internet Explorer 6.0. Практически по всем сайтам этот показатель стабилен. Второе место за Mozilla (Firefox) – 9,38%. Microsoft Internet Explorer 7.0 – 8,43%. Остальные версии браузеров – менее 3%.

Плохая новость заключается в том,
что браузером Microsoft Internet Explorer 5.0 пользуются 2,48% пользователей, а
эта версия браузера не поддерживает много стандартом и функционала JS. Однако 84%
посетителей пользуются браузерами, Но, похоже на то, что данная статистика не
определяет браузеры Opera 9.x. Это видно, если изучить статистику по браузерам без учета
версий.

Здесь на втором месте крепко закрепилась Opera. Причем, 15,6% — это нешуточная доля аудитории. Вывод из всех этих данных сделать легко. Основная аудитория сайта пользуется браузерами, которые хорошо (или более-менее хорошо) поддерживающими наиболее важный функционал (IE 6, Opera 9, Firefox 2). Это значит, что мы все же можем начинать использовать Ajax и такие библиотеки, как JQuery. Но при этом не забывайте писать, что для просмотра сайта требуется браузер Internet Explorer с минимальной версией 6.0.

Ну и на последок информация, которая для web-разработчика особой ценности не имеет, но может быть интересна просто любому IT-специалисту. Это статистика по операционным системам.