Cookie-файлы и проблемы защиты



Задание

 

Прочитать теорию. Объем немалый, но не стал ничего выбрасывать.

Отчет

 

Не требуется

 

Не забывайте каждый день занятий до 15.00 посылать сообщение на мою почту.

Теория

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

Механизмы сеансов, cookies и другие подобные механизмы (например, с серверной стороны) понадобились, поскольку изначально каждое HTTP-взаимодействие (запрос клиента – ответ сервера) было спроектировано как отдельное автономное TCP/IP-соединение (взаимодействие завершено – соединение разорвано), и такое взаимодействие не могло оставлять «следов» для последующих HTTP-взаимодействий.

Cookies

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

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

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

Использование функции setcookie()

Для работы с cookie-файлами предусмотрена только одна функция — setcookie(). В таблице ниже перечислены по порядку параметры этой функции. Все эти параметры, кроме первого, являются необязательными:

Параметры функции setcookie()

Имя параметра Предпо-лагае мый тип Значение
name string Имя cookie-файла (аналогичное имени переменной)
value string Значение, которое должно быть сохранено в cookie-файле (аналогично значению, которое должно было быть присвоено переменной). Если этот параметр не задан, то cookie-файл, указанный в качестве первого параметра, удаляется
expire int Значение, определяющее, когда должен истечь срок существования данного cookie-файла. Значение 0 (применяемое по умолчанию) указывает, что cookie-файл должен существовать до закрытия программы браузера. Любое другое целое число интерпретируется как абсолютное значение времени в секундах, когда cookie-файл должен стать недействительным
path string В случае, предусматриваемом по умолчанию, рассматриваемый cookie-файл может считываться (и устанавливаться) на любой странице, при формировании которой сценарий обращается к указанному подкаталогу корневого каталога документов веб. Возможность задать путь к подкаталогу (например, "/forum/") позволяет подчеркнуть различия между cookie-файлами, имеющими одинаковое имя, но устанавливаемыми на других сайтах или в других подобластях веб-сервера (в данном примере предполагается, что cookie-файл будет действительным только в области forum). В обозначении пути должна обязательно присутствовать заключительная косая черта
httponly bool Cookie-файлы, заданные с этим флагом, передаются только с помощью запросов протокола HTTP. Значением по умолчанию является FALSE
domain string В случае, предусматриваемом по умолчанию, проверка домена, доступа к которому требует клиент, не производится. Если же данный параметр не пуст, то имя домена должно совпадать с ним. Например, если один и тот же сервер обслуживает домены www.mysite.com и forum.mysite.com, то в коде одного сайта можно обеспечить, чтобы на другом сайте не считывались (и не устанавливались) его cookie-файлы, присвоив параметру domain значение 'forum.mysite.com'.
secure bool Значением по умолчанию является 0 (false). Если этот параметр равен 1, или true, то cookie-файл будет передаваться только через соединение с защищенным сокетом (иначе говоря, по протоколу SSL или HTTPS). Обратите внимание на то, что установка такого cookie-файла возможна только при условии, что защищенное соединение уже открыто

 

Давайте рассмотрим пример:

Код PHP

setcookie('membername', 'Alex');

В этом примере устанавливается cookie-файл с именем membername, который имеет значение Alex. Поскольку в этом вызове нет других параметров, кроме первых двух, данный cookie-файл будет храниться только до тех пор, пока не закрыта используемая в настоящее время программа браузера. Кроме того, значение указанного cookie-файла может быть считано в последующих запросах на получение страниц, поступающих с данного браузера на данный сервер, без учета того, каковым является доменное имя в запросе или где находится запрашиваемая страница в файловой иерархии корневого каталога документов веб. Кроме того, cookie-файл может быть считан независимо от того, является ли соединение веб-защищенным. Например, рассмотрим следующий вызов:

Код PHP

setcookie('membername', 'Alex', time() + 60 * 60 * 24 * 7,

"/", "www.mysite.com", 1);

В этом примере устанавливается cookie-файл со значением 'Alex'. Если бы на предыдущей странице был установлен cookie-файл, как показано в приведенном выше примере, то выполнение последнего оператора привело бы к его перезаписи. Срок хранения установлен равным 604 800 секундам (или 1 неделя) от текущей даты. В качестве параметра с обозначением пути задан самый верхний каталог в иерархии каталогов из всех возможных (/), поэтому данный cookie-файл может считываться в любом случае, независимо от его местонахождения в иерархии каталогов веб. Параметр с обозначением хоста задан равным "www.mysite.com". Это означает, что переход к просмотру следующей страницы должен привести к считыванию данного cookie-файла только в том случае, если пользователь действительно передает свой запрос с этого хоста. Наконец, последний параметр указывает, что рассматриваемый cookie-файл должен считываться или записываться через защищенное соединение между сокетами. (Если же само соединение, используемое на текущей странице, не является защищенным, то, по-видимому, данный cookie-файл вообще не будет установлен.)

Если требуется задать значения только последних параметров функции setcookie() и оставить первые не тронутыми, с тем чтобы им были присвоены значения, предусмотренные по умолчанию, то лучше все задать в качестве параметра с обозначением домена пустую строку (''), вместо параметра с обозначением пути ввести строку, содержащую символ косой черты ('/'), а в качестве срока хранения указать значение 0.

Если в сценарии PHP имеется несколько вызовов функции setcookie(), то такие вызовы обычно выполняются в последовательности, противоположной той, в которой они присутствуют в сценарии; но такая последовательность выполнения в некоторых версиях браузера нарушается. Лучше всего руководствоваться следующим правилом: никогда не передавать два разных значения для одного и того же cookie-файла при выполнении кода любой отдельно взятой страницы. (Так или иначе, передача больше чем одного cookie-файла не имеет смысла, поскольку один из них всегда перезаписывает другой.)

Cookie-файлы и проблемы защиты

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

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

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

Удаление cookie-файлов

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

Чтение cookie-файлов

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

·В версии PHP 4.1 и последующих версиях пара "имя-значение" из считанного cookie-файла добавляется к суперглобальному массиву $_COOKIE так, как если бы была выполнена операция $_COOKIE['name'] = value.

·Если разрешено использование директивы register_globals, то значение cookie-файла присваивается обычной глобальной переменной уровня страницы, имеющей такое же имя, как и в cookie-файле. Но поскольку использование директивы register_globals запрещено по умолчанию начиная с версии PHP 4.2, такая возможность в указанной или более поздней версии обеспечивается, только если администратор сервера внес изменение в конфигурацию.

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

Код PHP

$membername = $_COOKIE['membername'];

echo "Привет, <b>$membername</b>!";

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

 

Сеансы

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

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

 

Информация о сеансах хранится на стороне сервера. Переменные сеанса сохраняются в файле, в сериализованном виде. Когда переменная сериализуется (преобразуется в последовательную форму), в файл записывается имя переменной, тип и значение в виде последовательной строки. В UNIX-подобных операционных системах этот файл обычно сохраняется в файловой системе /tmp (временная файловая система).

Интерпретатор PHP фактически не создает запись о сеансе, пока переменной сеанса не будет присвоено значение. Таким образом, при отсутствии каких-либо значений сеанс в действительности ничего не делает.

Браузер отправляет идентификатор сеанса на сервер всякий раз, когда запрашивает очередную страницу. Идентификатор сеанса может передаваться через cookie (как показано на схеме) или в виде параметра URL. По умолчанию идентификатор передается через cookie, но поскольку есть вероятность, что пользователь запретил использование cookie в настройках своего браузера, мы также рассмотрим возможность передачи идентификатора сеанса в строке URL.


Дата добавления: 2021-04-05; просмотров: 85; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!