Я хочу рассказать о собственном опыте защиты веб-приложений, используемых на предприятиях/фирмах с ограниченным числом сотрудников.
Поговорим о системе, когда проверка подлинности пользователей осуществляется только с помощью паролей.
Прежде всего, советую прочитать хабратопик Где тонко, там и рвется (закрытый топик для подписчиков блога UI Design and Usability), именно он подтолкнул меня к написанию своего.
Хочу отметить, что парольная защита – не единственный способ проверки подлинности, но на данный момент самый привычный и используемый.
Первая задача, которая стоит перед разработчиком системы безопасности – это надёжная аутентификация пользователя.
При выборе парольного способа у разработчика остаётся мало возможностей для манёвра.
Для работы у него есть поля:
1. Логин
2. Пароль
Иногда, к этому может добавляться поле ввода домена, фирмы, подразделения.
В большинстве случаев логин и любое дополнительное поле (фирма и прочее) известны широкому кругу лиц, и реально конфиденциальным является только пароль.
При этом пароль не может быть сложным (см. Где тонко, там и рвется).
Единственное, что может требовать разработчик от пользователей – периодически менять пароль на другой, удобный пользователю.
И, фактически, вся система защиты строится на способе обмена идентификационными данными (далее — просто данными) и политике работы пользователей в системе.
1. Прежде всего – это защищённая передача данных пользователя.
Идеально использование SSL, но, к сожалению, не всегда возможно.
Простое хеширование по алгоритму md5 и передача нам не интересно.
Намного более правильно использовать HMAC. Данный метод позволяет хешировать и передать данные, так же он позволяет защититься от подборки исходных пользовательских данных в случае одностороннего перехвата.
Под «односторонним» я имею в виду передачу данных от клиента к серверу.
2. Использование виртуальной клавиатуры.
Уменьшает возможность перехвата данных кей-логгерами.
3. Блокировка пользователя после 7-10 неудачных попыток входа.
Практически исключает взлом пароля путём перебора.
4. Смена идентификатора пользователя в системе (сессии) после аутентификации.
В нашем случае – смена после успешного входа пользователя в систему.
5. Привязка пользователя к текущему клиенту.
Решается посредством привязки к IP и браузеру.
Это сводит к минимуму ущерб от похищения сессии пользователя.
6. В самой сессии со стороны пользователя – никаких данных!
Только её идентификатор.
7. Запрос повторной аутентификации пользователя после N минут неактивности.
8. Система привязки пользователей к конкретным IP/дням/времени работы.
Нечего рядовому менеджеру Кате делать в системе в субботу в 02:23 с IP американской университетской сети :).
9. Принципиальная невозможность работы с системой через прокси-сервера.
Особенно актуально в случае работы без SSL.
К сожалению, в ряде случае отследить невозможно.
10. И Самое Важное – постоянный мониторинг работы системы!
Вход/выход пользователей, блокировки, неверный ввод/перебор пароля, сканирование на уязвимости и так далее, всё в руках паранойи разработчика :)
Поговорим о системе, когда проверка подлинности пользователей осуществляется только с помощью паролей.
Прежде всего, советую прочитать хабратопик Где тонко, там и рвется (закрытый топик для подписчиков блога UI Design and Usability), именно он подтолкнул меня к написанию своего.
Хочу отметить, что парольная защита – не единственный способ проверки подлинности, но на данный момент самый привычный и используемый.
Первая задача, которая стоит перед разработчиком системы безопасности – это надёжная аутентификация пользователя.
При выборе парольного способа у разработчика остаётся мало возможностей для манёвра.
Для работы у него есть поля:
1. Логин
2. Пароль
Иногда, к этому может добавляться поле ввода домена, фирмы, подразделения.
В большинстве случаев логин и любое дополнительное поле (фирма и прочее) известны широкому кругу лиц, и реально конфиденциальным является только пароль.
При этом пароль не может быть сложным (см. Где тонко, там и рвется).
Единственное, что может требовать разработчик от пользователей – периодически менять пароль на другой, удобный пользователю.
И, фактически, вся система защиты строится на способе обмена идентификационными данными (далее — просто данными) и политике работы пользователей в системе.
1. Прежде всего – это защищённая передача данных пользователя.
Идеально использование SSL, но, к сожалению, не всегда возможно.
Простое хеширование по алгоритму md5 и передача нам не интересно.
Намного более правильно использовать HMAC. Данный метод позволяет хешировать и передать данные, так же он позволяет защититься от подборки исходных пользовательских данных в случае одностороннего перехвата.
Под «односторонним» я имею в виду передачу данных от клиента к серверу.
2. Использование виртуальной клавиатуры.
Уменьшает возможность перехвата данных кей-логгерами.
спорно: Комментарий.
3. Блокировка пользователя после 7-10 неудачных попыток входа.
Практически исключает взлом пароля путём перебора.
4. Смена идентификатора пользователя в системе (сессии) после аутентификации.
В нашем случае – смена после успешного входа пользователя в систему.
5. Привязка пользователя к текущему клиенту.
Решается посредством привязки к IP и браузеру.
Это сводит к минимуму ущерб от похищения сессии пользователя.
6. В самой сессии со стороны пользователя – никаких данных!
Только её идентификатор.
7. Запрос повторной аутентификации пользователя после N минут неактивности.
8. Система привязки пользователей к конкретным IP/дням/времени работы.
Нечего рядовому менеджеру Кате делать в системе в субботу в 02:23 с IP американской университетской сети :).
9. Принципиальная невозможность работы с системой через прокси-сервера.
Особенно актуально в случае работы без SSL.
К сожалению, в ряде случае отследить невозможно.
10. И Самое Важное – постоянный мониторинг работы системы!
Вход/выход пользователей, блокировки, неверный ввод/перебор пароля, сканирование на уязвимости и так далее, всё в руках паранойи разработчика :)
update: Пункты 4-10 относятся не столько к парольной защите, сколько к безопасности приложения в целом.
