6 ответов

Протокол HTTP не имеет аналогов по дизайну, каждый запрос выполняется отдельно и выполняется в отдельном контексте.

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

Cookies

В типичном случае браузера-сервера; браузер управляет списком пар ключ/значение, известный как файлы cookie, для каждого домена:

  • Файлы cookie могут управляться сервером (созданным/измененным/удаленным) с помощью заголовка ответа Set-Cookie HTTP.
  • Доступ к файлам cookie можно получить на сервере (чтение) путем разбора заголовка запроса HTTP Cookie .

Веб-ориентированные языки программирования/фреймворки предоставляют функции для обработки файлов cookie на более высоком уровне, например, PHP предоставляет setcookie / $_COOKIE , чтобы писать/читать файлы cookie.

Сессия

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

API веб-приложений?

Теперь вернемся к вашему вопросу; так как вы будете ответственны за проектирование API и документируете его, реализация будет вашим решением. Вы в основном должны

  • предоставить клиенту идентификатор, будь то с помощью заголовка ответа HTTP Set-Cookie , внутри тела ответа (ответ XML/JSON).
  • есть механизм для поддержания связи идентификатора/клиента. например таблицу базы данных, которая связывает идентификатор с клиентом/пользователем # 1337 .
  • попросите клиента повторно отправить идентификатор, отправленный ему в (1.) во всех последующих запросах, будь то в заголовке запроса HTTP Cookie , a ?sid=param (*).
  • найдите полученный идентификатор, используя механизм в (2.), проверьте правильность аутентификации и авторизуйтесь для выполнения запрошенной операции, а затем выполните операцию от имени пользователя auth"d.

Конечно, вы можете опираться на существующую инфраструктуру, вы можете использовать управление сеансами PHP (которое позаботится о 1..2 и части аутентификации 4.) в вашем приложении и потребовать, чтобы на стороне клиента выполнялись файлы cookie (что будет заботиться о 3.), а затем вы оставите всю свою логику приложения.

(*) У каждого подхода есть минусы и профи, например, использование параметра запроса GET проще реализовать, но может иметь последствия для безопасности, поскольку запросы GET регистрируются. Вы должны использовать https для критических (все?) Приложений.

Управление сеансом является ответственностью сервера. Когда сеанс создается, маркер сеанса генерируется и отправляется клиенту (и сохраняется в файле cookie). После этого в следующих запросах между клиентом и сервером клиент отправляет токен (обычно) в качестве файла cookie HTTP. Все данные сеанса хранятся на сервере, клиент сохраняет только токен. Например, чтобы начать сеанс в PHP, вам просто нужно:

Session_start(); // Will create a cookie named PHPSESSID with the session token

// If username and password match, you can just save the user id on the session $_SESSION["userID"] = 123;

Теперь вы можете проверить, аутентифицирован ли пользователь или нет:

If ($_SESSION["userID"]) echo "user is authenticated"; else echo "user isn"t authenticated";

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

If (verifyAccountInformation($user,$pass)){ // Check user credentials // Will create a cookie named PHPSESSID with the session token session_start(); $_SESSION["userID"] = 123; }

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

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

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

В конкретном случае использования при разработке веб-службы, использующей протокол SOAP в качестве протокола, существует также WS-Security расширение для протокола SOAP.

Со всеми этими словами я бы сказал, что ответы на следующий вопрос вводят процедуру принятия решения о выборе механизма авторизации/аутентификации для WebApi:

1) Какая целевая аудитория, общедоступная ли она или только для зарегистрированных (платных) участников?
2) Выполняется ли это или * NIX или платформа MS
3) Какое количество пользователей ожидается
4) Насколько чувствителен API данных с данными (более сильные и слабые механизмы аутентификации)
5) Существует ли какая-либо служба единого входа, которую вы могли бы использовать

И многое другое.

Надеюсь, что это очистит бит, так как в уравнении есть много переменных.

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

Базовая аутентификация

В данной статье будет рассмотрен самый простой и доступный способ защиты - базовая аутентификация.

Аутентификация - процесс, с помощью которого проверяется, что некто является именно тем, за кого он себя выдает. Как правило, проверка включает в себя ввод имени и пароля.

Рассмотрим, как работает базовая аутентификация.
При обращении посетителя в защищаемую директорию, сервер Apache в ответ на запрос посылает заголовок с кодом 401 (401 authentication required header). Браузер посетителя принимает заголовок с кодом 401 и выводит окно с полями для ввода имени пользователя и пароля. После ввода имени и пароля эти данные отсылаются назад серверу, который проверяет имя пользователя на предмет нахождения в специальном списке, а пароль на правильность. Если все верно, то посетитель получает доступ к ресурсу. Вместе с заголовком браузеру посылается специальной имя, называемое областью действия. Браузер кэширует не только имя и пароль, чтобы передавать их при каждом запросе, но и область действия. Благодаря этому, ввод имени и пароля в защищаемой директории осуществляется только раз. В противном случае их необходимо было бы вводить при каждом запросе к защищаемой директории. Кэширование параметров аутентификации (имя, пароль, область действия), обычно осуществляет только в пределах одного сеанса.

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

WEB-сервер Apache поддерживает еще один вид защиты - digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленному по алгоритму MD5. Поэтому пароль не может быть перехвачен при сканировании трафика. Но, к сожалению, для использования digest-аутентификации необходимо установить на сервер специальный модуль — mod_auth_digest. А это находится только в компетенции администрации сервера. Также, до недавнего времени, digest-аутентификация поддерживалась не всеми видами браузеров.

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

WEB-сайт и FTP-доступ к нему.

Права на создание файлов.htpaccess и организацию защиты с помощью них.

Утилита генерации паролей htpasswd.exe

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

В конфигурационном файле Apache (он именуется httpd.conf, а просматривать и редактировать его могут только администраторы web-сервера) есть параметр AccessFileName. Там указано имя файла, найдя который той или иной папке, Apache выполнит по отношению к ней указания, содержащиеся в этом файле. По традиции это имя - .htaccess, и именно таким оно установлено на всех серверах хостинга. В файл.htaccess можно поместить команды ограничения доступа к той папке, в которой это файл находится.

Выглядят эти команды так. Вначале указывается название защищенной зоны - AuthName. Именно это название будет впоследствии выводиться в запросе посетителю (рис. 1).

AuthName «Введите пароль»

Рис. 1. Запрос на вход в папку.

В следующем параметре AuthUserFile - указывается путь к файлу с логинами и паролями посетителей. Этот файл должен быть создан в особом формате, так как пароли в нем хранятся в зашифрованном виде. Для создания файлов с паролями применяются специальная программа htpasswd.exe. Если у вас установлен сервер Apache, то такую программу вы найдете в папке C:/Program Files/Apache Group/Apache2/bin/.

Для работы с программой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают файловые менеджеры типа Far, Total Commander и т.п. Можно использовать стандартную утилиту cmd (командная строка), которая входит в поставку Windows 2000/XP.

После запуска программы htpasswd.exe, вам предложат ввести пароль. Необходимо будет ввести пароль два раза, если вы ввели пароль правильно, программа завершает работу и в папке, где находился файл htpasswd.exe будет создан файл.htpasswd.

htpasswd.exe -c .htpasswd admin

Здесь.htpasswd - имя файла паролей, admin - имя пользователя (логин).

Чтобы добавить новые логины и пароли в уже имеющийся файл, эту программу следует запускать без параметра -c. По традиции файл с паролями посетителей принято называть.htpasswd. Обычно Apache настраивается так, что файлы с именами.htaccess и.htpasswd невозможно просмотреть через Web - при такой попытке будет выдаваться лишь сообщение о запрещении доступа. Однако выполнение такой настройки (для этого надо указать несколько параметров в httpd.conf) - целиком на совести администраторов web-сервера.

Не будем полагаться на совесть администраторов и разместим файл.htpasswd выше корня сайта. То есть, если файлы вашего сайта расположены, например, в /home/xxx/htdocs/, .htpasswd нужно поместить в /home/xxx/.

AuthUserFile /pub/home/xxx/.htpasswd

require valid-user

Замечание:

Если это невозможно, то файлы с паролями следует обязательно защитить. Это можно сделать с помощью файлов.htaccess. Чтобы защитить файлы с паролями создайте файл со строками:


deny from all

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

Обратите внимание, что путь к файлу паролей следует указывать абсолютный - то есть от корневого каталога сервера с указанием всего дерева каталогов. На серверах хостинга он обычно имеет вид /pub/home/имя_аккаунта/htdocs/admin/.htpasswd, а на вашем локальном компьютере зависит от местоположения web-сервера и его настроек, например, может выглядеть так: D:/work/localhost/www/admin/.htpasswd.

Замечание:

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

Итак, пожелав «запаролить» доступ к ресурсам какой-либо папки, создайте файл с именем.htaccess с вышеуказанными параметрами.

Замечание:

Удобно создавать файлы.htaccess с помощью встроенного редактора в файловых менеджерах Far, TotalCommander и т.п., а также в редакторе Блокнот.

После этого загрузите оба файла на свой сайт: .htaccess в закрываемую папку, а файл с паролями - в соответствии с прописанным в.htaccess путем к нему.

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

Рис. 2. Сообщение сервера о запрете доступа.

Доступ открывается «для определенного окна браузера и всех его дочерних окон». Иными словами, если посетитель однажды ввел правильные логин и пароль, то он, работая в одном и том же окне браузера, может не только свободно путешествовать по всем ресурсам в запароленной папке, но и, выйдя из нее, свободно вновь в нее войти. То же самое верно и для всех окон браузера, открытых из исходного с помощью команды «открыть в новом окне». А вот если он откроет новое окно браузера и зайдет уже в нем в эту папку, то запрос на ввод логина и пароля появится вновь (разумеется, если страница не была взята из кэша браузера - в последнем случае достаточно ее обновить).

15.09.14 6.3K

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

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

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

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

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

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

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

Что такое авторизация?

Как мы уже говорили, предоставление пользователям уникальных учётных записей позволяет идентифицировать их. Механизм «узнавания » сайтом зарегистрированных посетителей называется аутентификацией.

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

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

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

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

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

Управление доступом на основе групп и ролей

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

Для решения этой проблемы пользователи, имеющие одинаковые права или потребности, собираются в группы. Отдельные права также могут явно или неявно группироваться в так называемые роли. Роли, в свою очередь, могут назначаться отдельным пользователям или группам. В некоторых системах «роль » и «группа » являются синонимами.

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

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

Однако в случае принадлежности пользователя к нескольким группам или ролям в системе должен быть предусмотрен механизм решения конфликтов прав. Например, пользователь блога может быть включён в две группы, одной из которых разрешено создавать посты, а другой – только просматривать. Какое право присваивать пользователю в итоге?

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

Хорошей практикой является разделение пользователей на группы по виду деятельности на сайте. Например, наш блог может иметь следующие группы пользователей: «Авторы », «Редакторы », «Модераторы » и т.д.

Альтернативный подход будет состоять в том, чтобы выделить группы «Создание статей », «Правка статей », «Удаление комментариев » и т. д. Такой подход будет обладать значительной гибкостью, но при этом придётся поддерживать на сайте большее количество различных групп.

Защита страниц средствами ASP.NET

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

При защите сайта на ASP.NET используются три направления разделения доступа:

  • Система роутинга адресов;
  • Веб-формы (файлы и папки );
  • Структуры MVC .

Защита сайта на веб-формах

Как веб-формы, так и роутинг в ASP.NET использует для защиты доступа web.config . Основа конфигурации для защиты доступа к ресурсам сайта выглядит примерно так:

XML -элемент location определяет путь к защищаемому ресурсу: папке, странице или элементу роутинга. В данном примере он задаёт страницу adminhome.aspx . Можно защитить содержимое папки целиком, указав путь к ней. Если атрибут path отсутствует, настройки безопасности применяются к той папке, в которой находится файл web.config , со всеми её подпапками.

Элемент authorization определяет, кто имеет или не имеет доступа к защищаемому ресурсу. Права проверяются последовательно, начиная с первого и до тех пор, пока совпадение не будет найдено. Вложенный элемент allow задаёт разрешение, а deny – запрещение доступа к ресурсу для заданного пользователя или роли.

В нашем примере правило будет проверено первым. Если пользователь обладает ролью администратора, доступ ему будет предоставлен, и проверка условий на этом прекратится.

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

Существует несколько специальных символов, обозначающих часто используемые группы. Мы уже видели символ «* », обозначающий всех пользователей.

Символ «? » обозначает анонимного (не успевшего зарегистрироваться ) пользователя. Несколько групп или отдельных пользователей могут быть перечислены через запятую. Пользователи и роли могут смешиваться в одном правиле, например:

Защита MVC-сайта

Разработка сайта согласно методологии MVC сосредотачивается не на файлах и папках, а на контроллерах и их действиях. Соответствующим образом меняется и защита. По умолчанию все действия всех контроллеров доступны всем пользователям, как и в случае с веб-формами. Вам доступны те же пользователи и роли, но файлов web.config больше нет.

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

Public class AdminController: Controller { ...

Для обозначения анонимов и всех пользователей доступны те же символы «? » и «* ». Вы можете применять установки ко всему контроллеру или к отдельным действиям. При этом настройки действий будут иметь более высокий приоритет, чем настройки всего контроллера:

Public ActionResult AdminView() { ...

Если вы не укажете пользователей или ролей в атрибуте , то доступ будет разрешён всем зарегистрированным пользователям.

В ASP.NET 4 был добавлен атрибут , который позволил разрешить анонимному пользователю доступ к отдельным действиям защищённого контроллера.

Управление контентом в зависимости от роли

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

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

Например, не имеет смысла показывать ссылку на панель администрирования рядовым пользователям. Клиент, не имеющий отправленных заказов, не должен видеть кнопку трекинга. Даже если элемент не активен или ведёт на страницу авторизации, он может смутить простого пользователя и дать злоумышленнику пищу для размышления.

Код, исполняемый сервером на странице, доступной нескольким ролям, должен всегда проверять права пользователя и основывать свои действия на результате этой проверки.

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

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

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

UpdateOrder.aspx?order=33&action=delete

Теперь, представьте хакера, удаляющего все заказы перебором параметра order . Проверяется ли принадлежность заказа пользователю в соответствующем обработчике?

В другом случае отсутствие проверки в чём-то вроде:

UpdateOrder.aspx?order=33&action=refund

позволит злоумышленнику получить возмещение за чужой или не оплаченный заказ. Никогда не полагайтесь на скрытие ссылок как единственный механизм защиты от не авторизованного доступа.

Аспекты безопасности пользовательских сессий

Защита самих данных авторизации является отдельной задачей безопасности, хоть и близко соотносящейся с безопасностью доступа к ресурсам и коду. Во-первых, на безопасность механизма аутентификации влияет продолжительность сессии. В ASP.NET этот параметр задаётся в web.config следующим образом:

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

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

Если кука никак не защищена, её может использовать злоумышленник, перехватив трафик легитимного пользователя и представившись системе этим пользователем.

Существуют средства вроде FireSheep – расширения для браузера Firefox – позволяющие демонстрировать редактирование или подмену авторизационной куки.

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

Фреймворк ASP.NET позволяет усилить защиту сайта, установив атрибут формы входа на сайт requireSSL=»true» . Для ещё большей безопасности рекомендуется также применить тэг в конфигурации сайта.

Заключение

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

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

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

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

Комбинация этих мер позволит вам создать безопасный и защищённый веб-сайт.

Данная публикация представляет собой перевод статьи «Authorization and Protecting Web Resources in ASP.NET » , подготовленной дружной командой проекта

Хорошо Плохо

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

Авторизация - это процесс определения того, имеет ли аутентифицированный пользователь достаточные привилегии на выполнение того или иного действия. Таким действием может быть запрос веб-страницы, доступ к ресурсу, управляемому операционной системой (такому как файл или база данных), либо выполнение специфичных для приложения задач (наподобие размещения заказа в системе управления заказами или назначения проекта в приложении управления проектами вроде Microsoft Project Server).

Некоторые из этих проверок Windows осуществляет автоматически, а другие можно кодировать декларативно, используя файл web.config. Но некоторые проверки придется выполнять непосредственно в коде с использованием объекта IPrincipal.

Авторизация URL

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

Определяемые вами правила действуют через специальный модуль HTTP по имени UrlAuthorizationModule . Модуль просматривает эти правила и проверяет каждый запрос, гарантируя, что пользователю не будут доступны ресурсы, доступ к которым ограничен специальным образом.

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

Правила авторизации

Другими словами, существуют два типа правил: разрешить (allow) и запретить (deny). Тех и других можно добавлять столько угодно. Каждое правило идентифицирует одного или более пользователей либо ролей (групп пользователей). Вдобавок можно использовать атрибут verbs, чтобы создавать правила, применимые только к специфичным типам HTTP-запросов (GET, POST, HEAD ИЛИ DEBUG).

В предыдущих статьях уже приводился простейший пример. Чтобы запретить доступ всем анонимным пользователям, можно определить правило вроде следующего:

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

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

Такое правило требуется редко, потому что оно уже присутствует в файле machine.config. После того как среда ASP.NET применит все правила из файла web.config, она применяет правила из machine.config. В результате любому пользователю, кому явно закрыт доступ, автоматически его получает.

Теперь посмотрим, что произойдет, если в раздел добавить более одного правила:

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

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

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

Конфигурирование доступа для определенных пользователей

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

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

Можно также определить список имен, разделенный запятыми, и запретить доступ сразу нескольким пользователям. Ниже показана версия, эквивалентная предыдущему примеру, в которой используются только два правила аутентификации:

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

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

Следует обратить внимание на одну деталь. Формат имен пользователей в этих примерах предполагает аутентификацию с помощью форм. При такой аутентификации имя пользователя назначается при вызове метода RedirectFromLoginPage(). В этой точке UrlAuthorizationModule также использует это имя и проверит его по списку правил авторизации.

Контроль доступа к определенным каталогам

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

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

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

При использовании правил авторизации в подкаталоге среда ASP.NET все равно читает правила авторизации из родительского каталога. Отличие в том, что правила из подкаталога применяются первыми. Это важно, потому что ASP.NET останавливается, как только находит соответствие правила авторизации. Рассмотрим пример, в котором корневой виртуальный каталог содержит одно правило:

а подкаталог - другое правило:

В этом случае пользователь dan сможет получить доступ к любому ресурсу корневого каталога, но не получит никакого доступа к ресурсам из подкаталога. Если же вы поменяете местами эти два правила, то dan получит доступ только к ресурсам подкаталога, но не получит доступа к ресурсам корневого каталога.

Более интересно то, что ASP.NET допускает неограниченную иерархию подкаталогов и правил авторизации. Например, вполне возможно иметь виртуальный каталог с правилами авторизации, подкаталог, определяющий дополнительные права, и еще один подкаталог внутри этого подкаталога, в котором определен свой набор правил. Проще всего понять процесс авторизации в этом случае - представить все правила в виде единого списка, начинающегося с каталога, в котором находится запрошенная страница. Если все эти правила обработаны и соответствие не найдено, ASP.NET начинает читать правила авторизации из родительского каталога, затем из каталога, родительского по отношению к этому, и т.д. - до тех пор, пока соответствие не будет найдено. Если никаких подходящих правил не найдено, ASP.NET в конечном итоге применяет правило из файла machine.config.

Контроль доступа к определенным файлам

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

Дескрипторы location размещаются вне главного дескриптора и вложены непосредственно в базовый дескриптор , как показано ниже:

В этом примере открывается доступ ко всем файлам приложения за исключением SecuredPage.aspx и AnotherSecuredPage.aspx, которые имеют правило авторизации, запрещающее анонимный доступ к ним.

Конфигурирование доступа для определенных ролей

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

Сама по себе аутентификация с помощью форм роли не поддерживает, но наряду с Membership API в ASP.NET доступен интерфейс API Roles , который представляет собой готовую к использованию реализацию поддержки и управления ролями для приложений. Кроме того, если вы не хотите использовать эту инфраструктуру, достаточно легко создать собственную, которая разделит пользователей на соответствующие группы на основе их удостоверений.

После определения для ролей можно создавать правила авторизации. Фактически эти правила выглядят точно так же, как показанные ранее правила, специфичные для пользователей. Например, следующие правила авторизации запрещают доступ анонимным пользователям, разрешая его двум конкретным пользователям (dan и alex) и двум группам (Manager и Supervisor). Доступ всем прочим пользователям запрещен:

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

Рассмотрим пример:

Ниже описано, как ASP.NET разбирает эти правила:

    В этом примере доступ пользователю alex будет разрешен независимо от групп, к которым он принадлежит.

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

    Далее всем пользователям из группы Manager доступ открыт. Единственным исключением будут те, что входят и в группу Manager и в Guest. Правило Guest определено раньше в списке, поэтому данным пользователям вход уже закрыт.

    Затем доступ закрывается пользователю dan. Но если dan входит в группу Manager, доступ для него остается открытым.

    Любым пользователям, относящимся к группе Supervisor, кроме тех, доступ для которых был открыт или закрыт предыдущими правилами, доступ открывается.

    И, наконец, для всех прочих пользователей доступ закрыт.

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

Файловая авторизация

Авторизация на основе URL - один из краеугольных камней авторизации ASP.NET. Однако в ASP.NET также используется другой тип авторизации, который часто пропускается или игнорируется многими разработчиками. Это авторизация на основе файлов, реализуемая модулем FileAuthorizationModule . Авторизация на основе файлов работает, только в случае применения Windows-аутентификации. Если же используется специальная аутентификация или аутентификация с помощью форм, файловая авторизация не применяется.

Чтобы понять суть файловой авторизации, необходимо разобраться, как операционная система Windows обеспечивает безопасность файловой системы. В случае файловой системы NTFS можно установить списки ACL (access control list - список контроля доступа) , указывающие идентичность пользователей и ролей, которым открыт или запрещен доступ к индивидуальным файлам. Модуль FileAuthorizationModule просто проверяет права доступа к запрошенному файлу, определенные Windows.

Например, если запрашивается веб-страница, FileAuthorizationModule проверяет, имеет ли текущий аутентифицированный IIS пользователь права доступа к соответствующему файлу.aspx. Если не имеет, то код страницы не выполняется и пользователь получает сообщение о запрете доступа.

Новые пользователи ASP.NET часто удивляются, почему файловая авторизация должна быть реализована отдельным модулем, и почему бы ни положиться в этом на операционную систему?

Чтобы понять необходимость в модуле FileAuthorizationModule, необходимо вспомнить, как ASP.NET выполняет код. Если не включено заимствование прав, ASP.NET выполняется от имени фиксированного пользовательской учетной записи, такой как ASPNET. Операционная система Windows будет проверять, имеет ли учетная запись ASPNET права, необходимые для доступа к файлу.aspx, но она не выполнит ту же проверку для пользователя, аутентифицированного IIS. Модуль FileAuthorizationModule заполняет этот пробел. Он осуществляет проверку авторизации с учетом контекста безопасности текущего пользователя. В результате системный администратор может устанавливать права доступа к файлам или папкам и контролировать доступ к частям приложения ASPNET. Обычно проще и удобнее использовать правила авторизации в файле web.config. Однако если необходимо воспользоваться преимуществами существующих привилегий Windows в локальной или корпоративной сети, то это можно сделать.

Механизм Web-сервисов позволяет использовать 1С:Предприятие 8 как набор сервисов в сложных распределенных и гетерогенных системах, а также позволяет интегрировать 1С:Предприятие 8 с другими промышленными системами использованием сервисно-ориентированной архитектуры.

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

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

Послу публикации в указанном каталоге создастся файл default.vrd. Его содержимое будет примерно таким:


xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/DemoSSL"
ib="File="C:\1с\БиблиотекаСтандартныхПодсистем\DemoSSL";">

alias="exchange.1cws"
enable="true"/>
alias="exchange_2_0_1_6.1cws"
enable="true"/>
alias="InterfaceVersion.1cws"
enable="true"/>
alias="messageexchange.1cws"
enable="true"/>
alias="messageexchange_2_0_1_6.1cws"
enable="true"/>
alias="RemoteAdministrationOfExchange.1cws"
enable="true"/>
alias="RemoteAdministrationOfExchange_2_0_1_6.1cws"
enable="true"/>

Тег ws содержит описание публикации веб-сервисов. Если мы обратимся к веб-сервису с помощью браузера, введя его адрес, например, http://192.168.0.85/DemoSSL/ws/exchange.1cws , то увидим окно авторизации, которое попросит ввести логи и пароль пользователя 1С:

2. Окно авторизации веб-сервиса
Обратите внимание, адрес к веб-сервису строится по следующему шаблону:
[СетевойАдресКомпьютера]/[ИмяПубликации]/ws/[АдресВебСервиса]

Создадим пользователя 1С с логином User и паролем 123456 , от имени которого в дальнейшем будет происходить автоматическая авторизация.
Замечено, окно авторизации корректно работает с логином, написанным на латинице, иначе может появится ошибка:


A <a href="/flood-error-vkontakte-oshibka-oshibki-server-error-vkontakte-i-javascript-error-chto-delat.html">server error</a> occurred.

а?б?б?аЕаНб?аИб?аИаКаАб?аИб? аПаОаЛб?аЗаОаВаАб?аЕаЛб? аНаЕ аВб?аПаОаЛаНаЕаНаА.



An error occurred processing this request.

Допустим, необходимо, что бы веб-сервис exchange.1cws не требовал авторизацию. Для этого из файла default.vrd удаляем информацию о данном веб-сервисе, то есть удаляем строчки:
enable="true"/>

Создаем рядом с файлом default.vrd файл с именем exchange и расширением 1cws (exchange.1cws). Откроем файл текстовым редактором, укажем кодировку UTF-8 без BOM и запишем следующие строчки:

namespace="http://www.1c.ru/SSL/Exchange"
name="Exchange"
connectString="File="C:\1с\БиблиотекаСтандартныхПодсистем\DemoSSL";usr="User";pwd="123456""/>

Значения атрибутов тэга service берем из следующих мест:
3. Пространство имен веб-сервиса
Теперь веб-сервис Exchange доступен без запроса авторизации по адресу http://192.168.0.85/DemoSSL/exchange.1cws . Обратите внимание, что изменился путь к веб-сервису, теперь он не содержит уровень ws .

UPD 15.03.2016:
Если стоит апач(а может и не только) — то по дефолту 1С пытается авторизовать пользователя системы вида: \\\HOSTNAME$, если в базе создать такого пользователя с авторизацией системы — то плясать с бубном не нужно, а дальше рулите ролями.

UPD 12.04.2017:
Создать в операционной системе пользователя, под ним настроить запуск Apache. В 1С завести пользователя, установить галку Аутентификация операционной системы и выбрать пользователя Apache. Правда при такой настройке не получится выборочной аутентификации - будут доступны все сервисы, связанные с WEB.