Безопасная аутентификация и авторизация
Довольно часто в Web–системах приходиться сталкиваться с ситуацией, когда одна информация должна быть доступна определенному кругу лиц или конкретному лицу, а другая — другому или же быть общедоступной.
Проблема — открывать или не открывать доступ к некоторой информации в данном конкретном случае — и есть проблема аутентификации и авторизации.
Аутентификация — это проверка пользователя: действительно ли он тот, за кого пытается себя выдавать. Для аутентификации используется информация, предоставить которую может только сам пользователь.
В Web–системах для проведения аутентификации в большинстве случаев участвует пара значений — имя пользователя и пароль, удостоверяющий, что пользователь действительно тот, за кого себя выдает. Считается, что никто, кроме самого пользователя, не знает пароль. Естественно, известны более сложные и более надежные методы аутентификации, в частности биометрические, но в Web–системах они практически не применяются.
Авторизация — это проверка, имеет ли право данный пользователь выполнять некоторое действие, имеет ли право доступа к некоторым данным. Авторизации, как правило, предшествует аутентификация.
Система авторизации может быть построена на нескольких принципах:
-
Авторизация с распределением пользователей по группам
Пользователи разделяются на группы, и для каждой группы определяются права на доступ к тому или иному документу, права выполнять те или иные действия. -
Авторизация с присвоением уровня доступа
Каждому пользователю присваивается уровень доступа, а каждому документу и каждому действию — минимальный уровень доступа, который должен быть у пользователя для того, чтобы выполнить действие или получить доступ к документу. -
Табличный уровень доступа
Каждому пользователю для каждого документа или действия присваивается значение, отвечающее за уровень доступа пользователя к этому документу. Другими словами, для каждого документа или действия определен список пользователей, которые имеют право доступа к этому документу или имеют право выполнять данное действие.
Методы аутентификации
В самом начале при доступе к системе пользователь проходит аутентификацию. В Web-программировании применяются несклько методов аутентификации, каждый из которых имеет свои плюсы и минусы.
Рассмотрим самые популярные из этих методов.
Длинный URL
Наиболее просто реализуемый метод аутентификации (и одновременно авторизации) — сделать путь URL того или иного ресурса длинным и бессмысленным.
Например, для получения доступа к администранивной панели некоторой системы необходимо зайти по данному адресу:
http://site/jash47gdnc023nvs0sdvgh34234khsdg0wjsdnbv.php
При этом более никакой аутентификации не проводится.
Очевидно, что если на самом сайте не будет сылок на этот адрес и это адрес будет держаться в секрете, то подбор такого URL для злоумышленника будет довольно сложной задачей, сопоставимой с подбором самого пароля. Можно считать, что пароль содержиться в самом URL–адресе.
Однако этот метод имеет огромное количество недостатков, которые сводят надежность метода к нулю.
-
URL никакими системами не рассматривается как иформация, которая может содержать секретные сведения.
-
URL могут попадать в log-файлы HTTP–сервера, прокси-сервера. А следовательно, нет никакой гарании, что эти сведения не будут доступны третьим лицам.
-
Также нельзя гарантировать, что адрес не попадет в базы данных поисковых систем, а попасть он туда может если ссылка на указанный адрес была в открытом доступе, и поисковый робот успел ее проиндексировать.
Применять данную политику можно разве что в ситуациях, когда предоставляется доступ к данным, не имеющим конфиденциального характера, однако они могут быть интересны только ограниченному кругу лиц. Причем от утечки этих данных обладатель не должен нести никакого ущерба.
Система аутентификации со стороны клиента
В некоторых случаях сама аутентификация целиком проводится на стороне клиента, а серверу лишь посылается ее результат. Как подтип такой аутентификации может быть, что клиент переадресовывается на некоторый длинный URL в случае удачного прохождения аутентификации.
В любом случае независимо от реализации такую систему аутентификации нельзя назвать достаточно хорошей. Практически, она даже хуже системы с длинным URL.
Вот пример системы с аутентификацией пользователя методами JavaScript.
<html>
<title>аутентификация</title>
<head>
<script type="text/javascript">
function auth()
{
p = prompt('Введите пароль');
if(p == 'pdgf32f')
{
document.location.href='auth.html';
exit;
}
else alert('Пароль неверный');
}
</script>
</head>
<body>
<input type="button" value="Войти в систему" onclick="auth()">
</body>
</html>
Очевидно, что подобная система не представляет никакой преграды перед нападающим. Полный текст HTML–страницы доступен любому, даже неаутентифицированному пользователю, и любой пользователь, просматривая исходный код, сможет выявить всю информацию, необходимую для проведения аутентификации.
Кроме JavaScript на стороне клиента, аутентификация может выполняться в Java–аплетах, Active X–компонентах и другими способами, предполагающими выполнение некоторого кода, с помощью которого будет произведена аутентификация на стороне клиента.
Одиночный пароль
В некоторых случаях для аутентификации пользователя используется одиночный пароль. При этом у каждого пользователя он свой. Имя пользователя или логин в аутентификации не используются.
Эта система тоже ненадежна. При такой политике у пользователей не должно быть одинаковых паролей, иначе их нельзя будет отличить. Теперь представим ситуацию, когда в системе регистрируется новый пользователь и вводит, уже имеющийся, пароль. Очевидно, что система должна отказать в регистрации, тем самым пароль будет раскрыт.
Причем для прохождения аутентификации в качестве пользователя даже не нужно знать имя пользователя, так как аутентификация проходит только с использованием пароля.
Подобную систему можно использовать только тогда, когда заранее известно, что у системы будет минимальное количество пользователей, или если пользователь будет один.
Имя и пароль
Наиболее распространенный способ аутентификации. Нередко в качестве имени может служить кодовый номер или адрес электронного ящика. При правильной реализации подобная система первичной аутентификации будет достаточно надежна для большинства Web–систем.
Наиболее часто встречающейся ошибкой при реализаии тагого метода является то, что пароль передается HTTP–методом GET, параметры которого могут полностью логироваться как на промежуточных прокси–серверах, так и на HTTP–сервер системы.
В случае передачи имени пользователя методом HTTP POST система будет избавлена от подобных недостатков.
Стоит отметить, что пароль на сервер все равно будет передаваться в открытом виде и может быть перехвачен на любом промежуточном узле. Для защиты от подобного преехвата использутся протокол HTTPS. В этом случае перехват трафика ничего не даст.
