Ключевые слова: веб-приложения, информационная безопасность, аутентификация
В современном мире веб-приложению недостаточно быть функциональным, удовлетворять требованиям пользователей и менеджмента организации. Наряду с этими требованиями, одной из главных задач его разработчиков становится обеспечение информационной безопасности веб-приложения. Сейчас огромное количество организаций работает только в виртуальном пространстве, делая веб-приложение основным способом ведения бизнеса, оказания услуг или взаимодействия с клиентами. Утечки личных данных клиентов или другой чувствительной информации могут привести не только к большим финансовым и репутационным убыткам, но и привести к банкротству всей компании.
Учитывая большой уровень рисков, который связан с информационной безопасностью веб-приложения, ей должно быть уделено должное внимание при разработке. Меры обеспечения безопасности должны быть не только техническими, такими как защитные экраны веб-приложений, создание демилитаризованной зоны, но и организационными. К организационным мерам относится такая важная часть политики безопасности как политика паролей веб-приложения. Разные виды приложений, в том числе веб-приложений, имеют разные типы и уровни рисков, связанные с аутентификацией, поэтому и политики паролей разных типов приложений могут сильно отличаться.
Приложения, доступные из глобальной сети интернет, часто подвержены атакам автоматизированного перебора паролей, что требует выбора длинного и случайного пароля. Наоборот, мобильные банковские приложения, доступ к полю ввода пароля в которых можно получить только при наличии доступа к разблокированному мобильному устройству, требуют пароль небольшой длинны, часто состоящий только из цифр. Правила, хорошо подходящие для одного типа приложений или сфер деятельности, могут быть неприемлемыми для других. На выбор правил в политике также могут влиять государственные, международные или отраслевые стандарты. В данной статье предложена и рассмотрена политика паролей для веб-приложения работающего в сфере электронной торговли (e-commerce).
Даже если в приложении невозможно провести оплату без подтверждения от банка, например, через СМС, доступ в личный кабинет может привести к утечке чувствительный информации. К такой информации относятся история покупок клиента, которая в случае с лекарствами может привести к утечке данных о состоянии здоровья клиента, адрес, телефон и другие персональные данные.
Так как веб-приложения в сфере e-commerce направлены на широкий круг пользователей, к ним возможен свободный доступ из любой части мира через сеть интернет. Это делает приложения уязвимыми к атаке перебора паролей. Минимальная возможная длина паролей, встречающаяся в современных веб-приложениях и часто установленная по умолчанию во многих CMS (cистема управления содержимым), на которых строятся e-commerce приложения, составляет 6 символов. Так как российским пользователям кроме цифр и символов латинского алфавита доступно еще 33 символа русского алфавита, это означает, что для них использование такой длины более безопасно. При наличии дополнительных рисков, минимальная длина пароля может быть выбрана 8 или 10 символов. Более длинные минимальные пароли могут привести к возникновению отрицательного эффекта, например, вынуждая пользователю повторить пароль два раза.
Просто выбор минимальной длины пароля не может обеспечить необходимый уровень безопасности, так как не всегда пользователи используют весь доступный алфавит, а лишь его часть. Длины паролей в 6 и 8 символов делают удобным использование дат в качестве паролей и могут еще более уменьшить количество необходимых для подбора комбинаций. Использование в этом случае дат, которые широко известны или могут быть получены из открытых источников, таких как дата рождения пользователя, упрощают задачу атакующему.
Использование специальных символов, таких как знак процента или вопросительный знак, еще более расширяет доступный алфавит и должно быть сделано обязательным. Существуют часто используемые пользователями шаблоны поведения, такие как использование восклицательного знака на конце пароля для обхода этого правила. Такие шаблоны так же должны быть приняты во внимание и запрещены.
В типичном веб-приложении пароль является текстовой строкой и является тем, что знает пользователь. Использование концепции двухфакторной аутентификация предполагает, что подтверждение личности пользователя происходит на основе комбинации факторов, таких как чем обладает пользователь, где и в какое время он находится, а также его биометрических данных. Для веб-приложений хорошо подходит использование СМС или приложения двухфакторной аутентификации, через которое пользователь получает некий код. В приложении должна быть возможность активировать двухфакторную авторизацию после или во время прохождения регистрации.
Подходящей для веб-приложения, обслуживающего русскоязычных пользователей, может считаться пароль длинной 8 и более символов, содержащий один или более спецсимвол. Пароль не может быть датой или фразой, встречающейся в распространённых словарях паролей. При выборе такого пароля, пользователю должно демонстрироваться краткое пояснение о небезопасности выбранного пароля.
С ростом количества пользователей веб-приложение быстро сталкивается с тем, что пользователи регулярно забывают свои учетные данные. Восстановление их через техническую поддержку может привести к существенному повышению расходов на ее содержание, что приводит к необходимости автоматизации восстановления учетных данных, в том числе и пароля.
Даже при использовании некой дополнительной информации, такой как ответ на секретный вопрос, указанный при регистрации, не следует сбрасывать или показывать пользователю его пароль. Письмо или СМС с подтверждением сброса пароля должно быть отправлено пользователю на почту или на мобильный телефон, что является аналогом двухфакторной аутентификации. Доступ к адресу электронной почты или телефону в данном случае будет доступом к тому, что имеет пользователь в добавок к информации, которую он знает.
Неверно реализованная схема восстановления пароля или ответ на неверно введенные пользователем учетные данные могут привести к перебору зарегистрированных в веб-приложении пользователей. В случае с e-commerce приложением и использованием персональных данных, таких как почта или имя в качестве логина, утечка факта регистрации пользователя может быть нежелательной. Ответ на ввод неверных данных и запрос восстановления пароля должны быть определены в политике паролей и выбраны так, чтобы не позволить получить информацию о присутствии пользователя в базе данных приложения.
В ответ на неверно введенный пароль и на ввод несуществующего логина должно демонстрироваться одинаковое сообщение “Логин или пароль неверны. Проверьте правильность введенных данных.”. В ответ на запрос восстановления пароля должно демонстрироваться сообщение “Письмо с подтверждением отправлено на указанный адрес”.
Для пароля в веб-приложении может быть задано максимальное время действия, после которого пользователь обязан его сменить. Новый пароль не должен совпадать со старым. Такие правила часто установлены в военных или банковских системах. Несмотря на увеличение уровня безопасности, такой подход не всегда оправдан в сфере e-commerce, рассчитанной на массового пользователя, и может привести к обратному эффекту. Пользователи, которые не понимают необходимости придумывать новый пароль слишком часто, начнут обходить это ограничение, добавляя цифры в конец или начало пароля.
В случае, когда разработчиками принято решение использовать максимальное время жизни пароля, необходимо выбрать его не слишком коротким. Для сферы e-commerce это может быть срок от нескольких месяцев до года. Так же в этом случае необходимо выбрать минимальное время жизни пароля, так как пользователи могут обойти ограничение уникальности пароля сбросив его несколько раз подряд.
Так как e-commerce веб-приложения доступны из сети интернет, один из основных их рисков является автоматизированный подбор учетных данных, осуществляющийся одновременно по тысячам аккаунтов. Такой подбор могут осуществлять ботнеты из десятков тысяч компьютеров ничего не подозревающих пользователей, среди которых могут оказаться и клиенты компании. Поэтому для e-commerce веб-приложений блокировка таких попыток по IP адресу не является адекватным решением.
Одним из решений этой проблемы является временная блокировка аккаунта. После достаточно большого количества попыток неверного ввода пароля аккаунт блокируется до связи с техподдержкой и подтверждения личности пользователя. Количество неудачных попыток можно установить в диапазоне нескольких десятков, что исключит блокировку аккаунта самим пользователем. Однако это может привести к риску атаки с отказом в обслуживании, когда целью атакующего станет не получение доступа к аккаунтам, а прекращение обслуживания приложением клиентов.
Другой подход заключается в том, что после каждых 10 неудачных попыток подбора пароля аккаунт может блокироваться на 2–3 минуты. Это сильно замедлит процесс подбора пароля, сделав приложение менее ценной целью для атакующего. Среднее количество времени, затраченное на доступ к аккаунту, будет слишком большим.
Другим решением этой проблемы может стать использование CAPTCHA, которое заставляет пользователя выполнить некое сложное для компьютера действие и подтвердить, что он не является частью ботнета или программой.
Одним из самых уязвимых мест в веб-приложении являются его пользователи. Организация может тратить огромные средства на разработку своих веб-приложений, сертификацию безопасности кода и уровня подготовки сотрудников, внедрять политики безопасности. Все эти усилия полностью бесполезны, если пользователь переходит по ссылке в фишинговом письме и вводит свои учетные данные на фишинговом сайте.
Организация должна вкладывать средства в обучение в том числе своих пользователей. Это может быть краткая памятка, состоящая из нескольких слайдов в конце процесса регистрации, напоминающая пользователю проверять наличие значка https соединения в браузере, имя организации, которой выдан сертификат. Советовать использовать менеджер паролей для хранения учетных данных вместо выбора хорошо запоминаемого одинакового пароля для множества сайтов.
Вывод
Для типового веб-приложения, работающего в сфере e-commerce, оптимальной политикой паролей является выбор длины пароля от 8 символов, с использованием русских, латинских и специальных символов и цифр. Использование спецсимволов должно быть сделано обязательным.
Политика должна запрещать использование паролей, обнаруженный в списках первых по популярности нескольких сотен паролей, так как они часто используются злоумышленниками в автоматизированных инструментах подбора учетных данных. Запрет на использование более крупных или машинно-сгенерированных списков не рационально, так как приложение должно обнаруживать факт перебора и использовать другие методы защиты. В качестве таких мер может выступать CAPTCHA или временная блокировка аккаунта.
Организация должна внедрять меры обеспечения безопасности не только в приложении, но и среди пользователей. Часто при достаточно хороших технических средствах и политиках именно пользователи становятся самым уязвимым звеном.
