2020-06-29
167
Суть уязвимости, как следует из названия, заключается в отсутствии проверки наличия надлежащего доступа к запрашиваемому объекту.
Большинство веб-приложений проверяют права доступа, прежде чем отобразить данные в пользовательском интерфейсе. Тем не менее, приложения должны выполнять те же проверки контроля доступа на сервере при запросе любой функции. Ведь есть еще множество вспомогательных служебных запросов, которые, зачастую отправляются в фоновом режиме асинхронно, при помощи технологии AJAX.
Если параметры запроса не достаточно тщательно проверяются, злоумышленники смогут подделать запрос для доступа к данным без надлежащего разрешения.
Частный, и пожалуй, самый распространенный случай данной уязвимости мы уже рассмотрели в 4 пункте нашей статьи – отсутствие проверки пользователя в личных сообщениях.
Межсайтовая подделка запроса (Cross-Site Request Forgery, CSRF/XSRF)
Вектор атаки CSRF, также известный как XSRF, позволяет злоумышленнику выполнять от имени жертвы действия на сервере, где не реализованы дополнительные проверки.
|
|
|
Например, в некоторой платежной системе для перевода средств на другой аккаунт, есть страница вида:
demobank.com/transfer_money.jsp? transfer_amount =1000& transfer_account =123456789
где transfer_amount – сумма для перевода и transfer_account – номер аккаунта, куда должны быть переведены средства.
Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на вышеуказанную страницу платежной системы. Как результат – деньги уйдут на счет злоумышленника, после чего, вероятно, будут оперативно обменяны на Bitcoin или переведены в другую безвозвратную платежную систему, и получить их назад уже не получится.
Предполагается, что жертва должна была предварительно пройти аутентификацию в платежной системе и должна быть открыта активная сессия (скажем, страница платежной системы открыта в другой вкладке браузера).
Решается проблема достаточно просто и об этом мы расскажем в отдельной статье, посвященной CSRF.
Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities)
Зачастую web-приложения написаны с использованием специальных библиотек или «фреймворков» (англ – framework), которые поставляются сторонними компаниями. В большинстве случаев эти компоненты имеют открытый исходный код, а это означает, что они есть не только у вас, но и у миллионов людей во всем мире, которые штудируют их исходный код, в том числе, и на предмет уязвимостей. И нужно отметить, что делают они это отнюдь не безуспешно.
Также уязвимости ищут (и находят) в более низкоуровневых компонентах системы, таких как сервер базы данных, web-сервер, и наконец, компоненты операционной системы вплоть до ее ядра.
|
|
|
Очень важно использовать последние версии компонентов и следить за появляющимися известными уязвимостями на сайтах типа securityfocus.com.
Непроверенные переадресации и пересылки (Unvalidated Redirects and Forwards)
Web-приложения зачастую переадресуют пользователя с одной страницы на другую. В процессе могут использоваться ненадлежащим образом проверяемые параметры с указанием страницы конечного назначения переадресации.
Без соответствующих проверок, атакующий может использовать такие страницы для переадресации жертвы на подложный сайт, который, к примеру, может иметь очень схожий или неотличимый интерфейс, но украдет ваши данные кредитной карты или другие критичные конфиденциальные данные.
Этот вид уязвимостей, также как и многие другие перечисленные выше, является разновидностью ошибок проверки входящих данных (input validation).
