USD 64.37 ЕВРО 70.93

Безопасность веб-сайта должна начинаться с самого начала его разработки

Общество

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

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

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

Первоначально виновными в существовании бреши объявили Google, чей «Поиск» используется на сайтах, но поисковый гигант заявил, что уязвимость – в коде самой веб-страницы.

Эксперт по безопасности из FireEye Чон Рон Хва на вопрос, почему проверка входящих данных могла быть проигнорирована всеми, кроме хакеров, сказал, что веб-разработчики, как правило, не задумываются о безопасности своего кода, и не владеют методиками, позволяющими такой код создавать. И даже если методиками они владеют, приоритетом для них является функционал, а вопросы безопасности остаются второстепенными. Или игнорируются вовсе.

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

Чтобы избежать подобных недосмотров в будущем, чрезвычайно важно контролировать логику кода, закрывать криптографические «дыры», через которые может произойти утечка критически важных данных, а также оценить степень защищённости сервера среди прочих мер, обеспечивающих защищённость сайта.

Разумеется, достичь 100% защищённости сайта – крайне сложно. Хакеры же будут использовать пути наименьшего сопротивления, поэтому нужно в любом случае сделать всё возможное, чтобы не быть лёгкой мишенью, отметил Чон.

Особый акцент Чон сделал на том, что хакерам даже не пришлось взламывать правительственные сайты, чтобы добиться эффекта дефейса и ввести посетителей правительственных ресурсов в заблуждение. А ведь с помощью межсайтового скриптинга хакеры могли запросто инфицировать компьютеры посетителей незаметно для них. И это могло бы иметь куда более серьёзные последствия — как финансовые, так и в вопросах доверия к правительственным ресурсам.

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

«Безопасность веб-сайта должна начинаться с самого начала его разработки, на протяжении всего жизненного цикла его проектирования, а тестирование должно использоваться для усиления и проверки безопасности, а не просто для того, чтобы убедиться в наличии хоть каких-то средств защиты веб-сайта».