ресурс для начинающих веб-разработчиков
комплексные веб-услуги по созданию сайтов

Семейство протоколов защищенных сокетов (SSL) изначально было разработано компанией Nestcape с целью создания безопасного соединения веб-серверов с веб-браузерами. С тех пор SSL стал неофициальным стандартным методом обмена чувствительной информацией между браузерами и серверами.

Достаточно хорошо поддерживаются SSL как версии 2, так и версии 3. Большинство Web-серверов либо включают функциональность SSL, либо допускают ее подключение в виде модуля. Internet Explorer и Netscape Navigator поддерживают SSL, начиная с версии 3.

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

Когда для пересылки информации используется HTTP, этот протокол вызывает Transmission Control Protocol (TCP, Протокол управления передачей), который, в свою очередь, зависит от Internet Protocol (IP, Межсетевого протокола). Последний протокол требует протокола, управляющего сетевыми аппаратными средствами и преобразующего пакеты данных в электрические сигналы, отправляемые в точку назначения.

HTTP называется протоколом уровнем приложения. Протоколами такого типа являются FTP, SMTP и Telnet (как показано на рисунке ), а также POP, IMAP и ряд других. TCP — это один из двух протоколов транспортного уровня, используемого в сетях TCP/IP. IP — протокол сетевого уровня. Хост сетевого уровня отвечает за соединение хоста (компьютера) с сетью. Протоколы этого уровня в данном стеке TCP/IP не указаны, поскольку для различных типов сетей на этом уровне требуются различные протоколы.

При отправке данные пересылаются по этому стеку от приложения к физической сетевой среде. При получении данные проходят от физической сети через стек к приложению.

Использование SSL добавляет к описанной модели еще один прозрачный уровень. УровеньSSL находится между транспортным уровнем и уровнем приложения. Модифицированная схема показана на рисунке ниже. Уровень SSL изменяет данные, поступившие от приложения HTTP, до их передачи транспортному уровню.

Теоретически SSL может обеспечить среду безопасной пересылки и другим протоколам кроме HTTP, но обычно его используют только для HTTP. Возможность использования других протоколов связана с тем, что уровень SSL является исключительно прозрачным, т.е. он обеспечивает такой же интерфейс протоколам выше него, как и транспортный уровень. Кроме того, он прозрачно обеспечивает установку соединения, шифрование и дешифрование.

Когда Web-браузер соединяется с безопасным Web-сервером через HTTP, обеим сторонам необходимо воспользоваться протоколом установки соединения (квитирования), позволяющим договориться об аутентификации и кодировании. Последовательность установки соединения включает в себя следующие шаги:

1. Браузер соединяется с сервером, поддерживающим SSL, и запрашивает у него аутентификацию.
2. Сервер отправляет свой цифровой сертификат.
3. Сервер может дополнительно (крайне редко) запросить аутентификацию у браузера.
4. Браузер посылает список поддерживаемых им алгоритмов шифрования и хэширования. Сервер выбирает наиболее сложное шифрование из поддерживаемых им.
5. Браузер и сервер генерируют ключи сеанса:
   • Браузер получает открытый ключ сервера из его цифрового сертификата и использует его для шифрования случайного числа.
   • Сервер отвечает отправкой случайных данных в текстовом формате (если только браузер не выслал цифровой сертификат в ответ на запрос сервера — в этом случае сервер использует открытый ключ браузера).
   • Ключи шифрования для этого сеанса генерируются по случайным данным с использованием хэш-функции.

Генерирование качественных случайных данных, дешифрация цифровых сертификатов, генерирование ключей и использование криптографии по открытому ключу требует времени, поэтому процедура установки соединения выполняется не сразу. К счастью, результаты кэшируются, поэтому, если тот же самый браузер соединяется с тем же сервером, процесс установки соединения требует времени только один раз.

Пересылка данных по SSL-соединению проходит следующие стадии:

1. Данные разбиваются на управляемые пакеты.
2. Каждый пакет (необязательно) сжимается.
3. Каждый пакет имеет коды аутентификации сообщения (message authentication code — MAC), вычисленные с использованием хэш-алгоритма.
4. MAC-код и сжатые данные комбинируются и шифруются.
5. Зашифрованные пакеты вместе с заголовочной информацией пересылаются по
   сети.

Весь процесс показан на рисунке ниже.

Из схемы можно заметить, что заголовок TCP добавляется после кодирования данных. Это значит, что маршрутная информация может быть перехвачена. И хотя шпионы не смогут получить информацию, они смогут определить, кто ею обменивается.

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

Алгоритмы сжатия основаны на поиске повторяющихся последовательностей данных. Попытка их применения после того, как данные в результате шифрования были превращены в случайный набор битов, в большинстве случаев оказывается бесполезной. Было бы нежелательным, чтобы SSL, разработанный для повышения безопасности сети, приводил к существенному увеличению трафика.

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

В относительно недалеком будущем SSL 3.0 будет, скорее всего, заменен на TLS 1.0 (Transport Layer Security, защита транспортного уровня). TLS предназначен быть действительно открытым стандартом, а не стандартом, который был разработан одной организацией и открыт для остальных. Он основывается на SSL 3.0, однако содержит ряд улучшений, связанных с преодолением недостатков SSL и повышением гибкости.

Проверка данных, вводимых пользователем

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

В нескольких местах этого раздела обсуждались методы проверки пользовательского ввода. Ниже приводится их краткий список.

• Функцию addslashesQ следует использовать для фильтрации данных до их пересылки в базу данных. Она позволяет избежать символов, которые могут вызывать проблемы при сохранении в базе данных. Чтобы вернуть данные к исходному виду, можно воспользоваться функцией stripslashes().
• Магические кавычки. Включить директивы magic_quotes_gpc и magic_quotes_runtime можно в файле php.ini. Они автоматически добавляют или убирают управляющие символы обратной косой черты, причем magic_quotes_gpc выполняет это для входных переменных методов GET, POST и cookie-наборов, a magic_quote_runtime — для данных, входящих или исходящих из базы данных.
• Функцию escapeshellcmdQ следует использовать до передачи данных таким командам, как system() или ехес(). Функция помещает символы обратной косой черты перед каждым метасимволом, который может быть использован злонамеренным пользователем с целью запуска определенных системных команд.
• Для удаления из строки HTML- и PHP-дескрипторов можно воспользоваться функцией strip_tags(). Это не позволит создавать сценарии внутри данных, которые сервер передает для отображения браузеру.
• Функция htmlspecialchars() предназначена для преобразования некоторых символов в их HTML-эквиваленты. Например, символ < преобразуется в &It;. Таким образом любые дескрипторы сценария можно превратить в безопасные символы.

Обеспечение безопасного хранения данных

Три различных типа сохраняемых данных (HTML- или PHP-файлы, данные сценариев и данные MySQL) часто размещаются в разных областях одного и того же диска. Каждый тип требует различных предосторожностей, поэтому и обсуждаться они будут отдельно.

Наиболее опасным является выполняемое содержимое. На веб-сайте таковым обычно являются сценарии. Необходимо проявлять особую осторожность при установке прав доступа внутри веб-иерархии. Под последней здесь подразумевается дерево каталогов, начинающееся с htdocs на сервере Apache или inetpub на сервере IIS. Посторонние должны иметь возможность только читать сценарии, но ни в коем случае не переписывать или вносить поправки в них.

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

Если сценариям требуется записывать в файлы, для этой цели необходимо создать каталог за пределами веб-дерева. В особенности это касается сценариев по выгрузке файлов. Сценарии и записываемые ими данные не должны перемешиваться.

При записи важные данные можно зашифровать. Однако подобный подход редко дает хорошие результаты.

Предположим, что на веб-сервере имеется файл creditcardnumbers.txt, и взломщик получил доступ к серверу, что еще он может прочесть? Чтобы зашифровать и дешифровать данные, требуются соответствующие программы и один или несколько файлов ключей. Если взломщик может прочесть данные, скорее всего, ничто не помешает ему прочесть файлы ключей, равно как и другие файлы.

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

Содержимое базы данных похоже на данные, хранящиеся в обычных файлах данных. Если MySQL настроен корректно, то только эта система может записывать информацию в свои файлы. А это значит, что беспокоиться следует только о доступе пользователей в рамках MySQL. В разделе уже обсуждались вопросы, связанные с системой управления правами доступа MySQL, которая присваивает определенные права определенным пользователям на указанных хостах.

Особого внимания требует следующий факт: часто в PHP-сценариях необходимо указать пароль для доступа в MySQL. PHP-сценарии зачастую являются общедоступно загружаемыми. Однако это не представляет такой проблемы, как может показаться сначала. Если конфигурация веб-сервера не нарушена, исходный код РНР никогда не будет виден снаружи.

Если веб-сервер сконфигурирован для обработки файлов с расширением .php при помощи интерпретатора РНР, внешние пользователи не имеют возможности увидеть исходный код. Нем не менее, при использовании расширений следует быть осторожным. Если файлы .inc разместить в веб-каталогах, по внешнему запросу можно будет получить исходный код. В этом случае необходимо поместить файлы за пределами веб дерева и либо сконфигурировать сервер так, чтобы он не пересылал файлы с таким расширением, либо использовать для них только расширение .php.

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

Определение необходимости хранения номеров кредитных карточек

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

Что происходит с номером кредитной карточки? Если выполняется одноразовая транзакция и обработка карточки в реальном времени, лучше просто получить номер и направить его сразу в шлюз транзакций, не сохраняя на своем сервере.

Если необходимо производить периодические отчисления, например, взымать ежемесячные взносы с одной и той же кредитной карточки, такой подход не подойдет. В данной ситуации номера карточек следует хранить за пределами веб-сервера.

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