Самые распространенные ошибки в системах безопасности Web-приложений
На сайте OWASP (Open Web Application Security Project - открытый проект безопасности Web-приложений; www.owasp.org) опубликован список десяти наиболее часто встречающихся брешей в системе безопасности Web-приложений. В нем четко и довольно полно представлены реальные проблемы вместе с возможными средствами их устранения. Ниже мы приводим этот список, дополнив его рекомендациями eWeek Labs.
1. Отсутствие проверки входных параметров
Абсолютно все, что клиентский компьютер пересылает в Web-приложение, должно проходить входной контроль. Поступающий трафик следует сканировать дважды. Во-первых, нужно провести низкоуровневую чистку входящих строк на основе стандартных выражений либо списка стандартных значений. Второй этап проверки входных данных проводится на уровне приложений.
2. Небрежный контроль доступа
Как только пользователь вошел в систему, его привилегии должны учитываться при обращении к каждой странице сайта. При этом нельзя полагаться только на характеристики потока данных - для контроля доступа следует применять и проверку на прикладном уровне. А избежать несанкционированного повторного использования блоков данных поможет их шифрование. К тому же перед выполнением критически важных задач целесообразно производить повторную аутентификацию - это станет еще одним рубежом защиты от перехвата сеанса злоумышленниками.
3. Вторжение в учетные записи и в управление сеансом
Если хакер сумеет перехватить информацию о сеансе связи пользователя, ему нетрудно будет обойти и всю подсистему аутентификации. Поэтому разработчики должны иметь очень веские основания для того, чтобы вставлять в программы собственные коды генерации ключей. В отсутствие оных лучше воспользоваться средствами генерации сеансовых ключей, предусмотренных в сервере приложений.
4. Погрешности сценариев между сайтами
Преобразуйте поступающие от пользователя данные таким образом, чтобы превратить угловые скобки (например, “<”) в кодовую последовательность, используемую для передачи контрольных символов по НТТР, - тогда код сценария будет невозможно сохранить на сервере. Но не забывайте: чтобы обойти такую проверку, злоумышленник может перекодировать символы ASCII в Unicode.
5. Переполнение буфера
Такая опасность возникает лишь в тех случаях, когда хотя бы некоторые компоненты пользовательских данных написаны на языках, не обеспечивающих защиты от переполнения (чаще всего эти проблемы возникают при использовании языков Си и С++). Старайтесь не применять их в кодах Web-приложений, а на компоненты сторонних разработчиков накладывайте “заплаты”.
6. Добавочные команды
Эта брешь возникает, когда при пересылке пользовательских данных из Web-приложения в операционную систему или базу данных SQL не производится их фильтрация, не предусмотрено прерывание управляющих команд либо не используются символы разделения команд. В таких случаях хакер может встроить в пересылаемые данные собственную команду, которая затем будет исполнена на Web-сервере или на сервере баз данных. С учетом этой опасности права пользователя в базах данных стоит ограничить.
7. Неправильная обработка ошибок
Никогда не направляйте стандартные сообщения об ошибках Web-пользователям. Чтобы не допустить утечки информации, подобные послания перехватывайте и заменяйте на собственные сообщения. А установленный на узле механизм отслеживания ошибок подскажет вам, что кто-то ищет слабые места сайта.
8. Некорректное применение криптографии
В любом современном языке программирования предусматривается поддержка криптографии. Пользуйтесь только проверенными алгоритмами шифрования и не храните ключи в исходных текстах, так как на серверах приложений довольно часто встречаются ошибки, приводящие к вскрытию кодов.
9. Проблемы дистанционного администрирования
Применяйте только надежные технологии аутентификации и не открывайте инструментарий управления удаленным пользователям. Если же без этого не обойтись, обратитесь к виртуальной частной сети с ограниченным доступом.
10. Ошибки в конфигурации Web-серверов и серверов приложений
Следите за новыми “заплатами” для таких серверов и своевременно устанавливайте их. Удаляйте ненужные расширения, стандартные учетные записи и используемые по умолчанию пароли. Конфигурируйте приложения так, чтобы избежать утечки информации. Изучайте передовой опыт обеспечения безопасности серверов и применяйте его на практике.
С техническим редактором eWeek Labs на Западном побережье (США) Тимоти Диком можно связаться по адресу: timothy_dyck@ziffdavis.com.
