Аудит аутентификации на Web-сайтах. Часть вторая

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

Анонимность пользователя

Транслирует ли система данные пользователя по безопасному каналу?

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

Многие Web сайты (Hotmail, Yahoo) позволяют использовать защищенный вход в систему, но эта опция не стоит по умолчанию, и для входа пользователи должны использовать дополнительную ссылку.

Используется ли для паролей устойчивый алгоритм хеширования?

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

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

Аутентификация сессии

Есть ли возможность обойти аутентификацию, обращаясь непосредственно к модулю?

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

Возможно ли, успешно пройдя аутентификацию, получить доступ к операционной системе Web сервера или сети?

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

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

Могут ли пользователи выйти из системы?

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

Закрывает ли система сессию при выходе или таймауте?

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

Предупреждает ли система смену учетных записей?

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

http://www.example.com/users/accountinfo.asp?userid=1254 

Первая мысль, которая возникает – что будет если сменить userid, например, присвоить этому параметру значение 1253, или даже 1. Если система проверяет лишь флаг аутентификации, то такое действие позволит внедриться в чужую учетную запись.

Безопасность пользователей

Может ли третье лицо путем обмана заставить пользователей войти в систему на поддельных страницах?

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

http://www.citibank.com/domain/redirect/signon/myciti.htm?

BVE=http://Web.da-us.citibank.com&BVP=/cgi-

bin/citifi/scripts/&BV_UseBVCookie=no&US&_u=visitor 

https://www.aa.com/apps/utility/logInOut/LoginMember.jhtml;jsessionid=

0CC3OQ2ND1JEAJJNDSNAEQBFFUGLTT?

anchorEvent=false&_requestid=316005&_requestid=316005 

http://www.amazon.com/exec/obidos/flex-sign-in/ref=ya_hp_pi_1/103-

5972766-0490219?opt=a&page=help/ya-sign-in-secure.html&
response=account-name-change&method=GET&return-url=account-name-change 

Предпочтительнее было бы:

http://login.citibank.com/ 

http://login.aa.com/ 

http://login.amazon.com/ 

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

Объясняете ли вы пользователям о защите их учетных записей?

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

Могут ли пользователи просматривать историю своих учетных записей?

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

Могу ли пользователи легко рапортовать об ошибках безопасности?

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

Могут ли пользователи изменять свои настройки безопасности?

Если вам сложно определить границу между безопасностью и открытостью пользователя, позвольте пользователям самим решать этот вопрос. Например, пользователи могут сами устанавливать таймаут для сессий, ограничения в доступе с определенных IP адресов, количество неудачных попыток входа и т.д. На Yahoo пользователи могут сами устанавливать количество запросов на подтверждение пароля, а Hotmail.com позволяет пользователям устанавливать таймаут сессии. Эти действия позволят пользователям быть более защищенными, если им это нужно.

Могут ли пользователи активировать или удалить учетную запись?

Если вы позволяете пользователям создавать учетные записи, то также, должны позволять удалять их.

Куки

Можно ли пользователю войти в систему, используя похищенные куки?

Запись куки с важными данными может быть как очень удобным, так и небезопасным средством аутентификации. Если атакующий способен похитить куки пользователя, то его учетная запись будет скомпрометирована. Альтернативой является предоставление лимитированного доступа без повторной аутентификации или привязка куки к другой идентифицирующей пользователя информации, как, например, IP адрес, строка User Agent и т.д. Тем не менее, все куки должны иметь четкий срок существования, после окончания которого, пользователь должен пройти повторно аутентификацию. Но лучше всего требовать аутентификацию при каждом открытии сессии.

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

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

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

Сохраняется ли в куки важная информация?

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

Помечены ли куки как безопасные?

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

Указывается ли в куки домен и путь?

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

Общие правила

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

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