В данном документе перечислены основные уязвимости веб приложений и способы их профилактики, каждая уязвимость относиться к одной из основных категорий:
Организационная— основой уязвимости является человеческий фактор. Данная уязвимость решается при помощи определенных правил работы с сайтом или за счет специального програмного обеспечения.
Проектирование— уязвимость непосредственно приложения. Данные уязвимости устраняются путем учета возможности атаки при разработке, большинство из них могут быть решены на уровне базового функционала, что позволяет минимизировать человеческий фактор.
Эксплуатация— атака может быть произведена на уровне сервера или инфраструктуры, данные проблемы решаются администраторами веб сайтов.
Аутентификация и доступ к сайту.
Нестойкие пароли.
Категория: организационная уязвимость
Использование простых паролей (qwerty, password, дата рождения, номер телефона) позволяет получить доступ к управлению сайтом путем перебора паролей или социальной инженерии.
В общем случае желательно использовать автоматически сгенерированные пароли, но только в том случае если есть уверенность, что человек сможет его запомнить, а не запишет его на листке и повесит на монитор.
В противном случае следует использовать сложные мнемонические пароли: первые буквы стихов или песен в другой раскладке клавиатуры, с изменением некоторых букв на цифрыили спецсимволы.
Есть еще любимая тема оставлять пароли по умолчанию, типа root/ничего или admin/admin (в Йотовском яйце), и думать что об этом никто не узнает.
Лучше всего принудительно заставлять менять «временные» пароли при первом входе.
Перехват пароля.
Категория:организационная, эксплуатационная.
Перехват пароля может быть осуществлен при передаче его от пользователя к серверу, это решается обязательным использованием защищенного соединения (https, ftps) при работе с сервером.
Я помню Сергей Рыжиков, выступая на Хайлоаде или РИТе (не помню уже), спросил кто из присутствующих ходит на админки через защищенное соединение, и в ответ было поднято не так уж много рук. Из чего можно сделать вывод, что прогулка по какой-нибудь конференции с wi-fi сниффером может немного преобразить рунет.
Кроме того, возможна кража с использованием так называемого «фишингового» сайта, т.е. сайт в браузере пользователя подменяется на идентичный, после ввода данных в форму входа, пароль попадает к злоумышленнику, в данном случае важно иметь «подписанный сертификат сайта». При использовании такого сертификата специальная компания (например
http://verisign.com), подтверждает, что это действительно тот сайт, который предполагается, кроме того подписанный сертификат, удостоверяет тоже самое и пользователю сайта (что важно, например при оплате). Данная услуга стоит порядка $800 в год (на стоимость влияет уровень защиты и авторитетность компании, поставщика услуги)
Меня все время удивляют организации, которые ленятся сделать нормальный сертификат, особенно в этом плане умиляет webmoney. Слава богу, сейчас они уже сподобились сделать нормальный сертификат, но еще месяц назад меня честно говоря передергивало от того, что браузер ругается на сайт, на котором я, между прочим, деньги держу.Ко всему прочему самоподписанные сертификаты могут вызывать разные мелкие баги: например с ними отказывается работать связка IE+Flash. Я убил довольно много времени, выясняя, почему перестал работать на продакшене мультизагрузчик, который в тот же самый момент спокойно работал себе на тестовом сервере.
Кража пароля
Категория:организационная
Кража пароля осуществляется при помощи социальной инженерии или вредоносного ПО.
Правила профилактики довольно банальны:
Не хранить и не передавать пароль в открытом виде, т.е. не высылать пароль на почту или через ICQ, Skype и т.д. Важно помнить, что если вы передали пароль, то он с большой вероятностью сохраниться в архиве почты или хистори месенджера.
Не запоминать пароли в браузере или FTP клиенте.
Распространены вирусы которые вставляют вредоносный код на сайт используя сохраненные FTP пароли.
Использовать антивирусное ПО
Регулярно менять пароли
Отдельной строкой следует заметить, что каждый человек, имеющий доступ к сайту, должен иметь свой отдельный логин и пароль, что в дальнейшем поможет выявить причину взлома и обезопасить себя в случае увольнения сотрудника.
Большая головная боль вебстудий — пароли от сайтов клиентов, которые упорно оседают в хистори, архивах почты и расшаренных файликах на сервере.Отдельной приятностью является какой-нибудь мастер-пароль, который подходит к половине сайтов и известен менеджерам, разработчикам, их родственникам, а также блистательной плеяде уволившихся и уволенных сотрудников. Периодически предпринимаются попытки пройтись по всему портфолио и поменять, наконец, мастер пароль на что-то получше, которые обычно завязают где-то в самом начале.
Наиболее простым и элегантным способом является перенос авторизации на сервер студии, т.е. в админку сайта можно войти с OpenID (не любого, а
Читать далее...