6 угроз безопасности веб-бэкенда, которые следует учитывать при разработке

Примите меры в процессе разработки, чтобы укрепить и обеспечить безопасность веб-сервера..


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

Наиболее опасными являются веб-атаки, которые происходят на стороне сервера, где хранятся и анализируются данные..

Что такое бэкэнд?

Веб-приложение разделено на две части – интерфейс и бэкэнд.

  • Клиентский интерфейс – это та часть, с которой взаимодействует пользователь. Как правило, он построен с использованием HTML, CSS и Javascript..
  • Бэкэнд на стороне сервера. Это в основном то, как приложение работает, применяет бизнес-логику, изменения и обновления. Некоторые из популярных стеков технологий на стороне сервера включают PHP, NodeJS, Java, Ruby, C, Python, базы данных, безопасность (аутентификация, контроль доступа и т. Д.), Структуру и управление контентом..

Небольшое напоминание, прежде чем мы начнем – аутентификация, контроль доступа & управление сеансом

Мы часто путаем термины. Итак, давайте выясним это быстро:

  • Аутентификация касается подтверждения личности пользователя (например, пароля, имени пользователя, вопросов безопасности, отпечатков пальцев)
  • Контроль доступа касается того, что пользователь может получить доступ к приложению. Он применяет политику, согласно которой пользователи не могут действовать за пределами своих предполагаемых разрешений..
  • Управление сеансами касается ответов и запросов транзакций, связанных с одним и тем же пользователем. Это механизм обмена, который используется между пользователем и приложением после успешной аутентификации..

Давайте рассмотрим следующее для лучшей внутренней безопасности веб.

Недостатки впрыска

С 2010 года OSWAP классифицирует инъекцию как самый опасный риск для веб-приложений..

Недостатки внедрения позволяют пользователю предоставлять данные, содержащие ключевые слова, которые будут изменять поведение запросов, построенных на базе данных. Например, предположим, у нас есть сценарий SQL, который проверяет, существует ли соответствующая запись в базе данных..

uname = request.POST [‘username’]
passwd = request.POST [‘пароль’]
sql = "ВЫБЕРИТЕ ID ОТ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ username = ‘" + uname + "’И пароль =’" + ПАРОЛЬ + "’"
database.execute (SQL)

Теперь злоумышленник может манипулировать полем пароля с помощью SQL-инъекции, например, введя пароль «OR 1 =» 1, что приводит к следующему SQL-запросу:

sql = "ВЫБЕРИТЕ ID ОТ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ имя пользователя = ” И пароль = ‘пароль’ ИЛИ ​​1 = ‘1’

Таким образом, злоумышленник может получить доступ ко всем пользовательским таблицам базы данных, причем пароль всегда действителен (1 = ‘1’). Если они входят в систему как администратор, они могут вносить любые изменения, которые он хочет.

Как это предотвратить?

Это очень ЛЕГКО чтобы избежать дефектов впрыска.

Лучший и простой способ проверить, нет ли недостатков внедрения, – это тщательный ручной анализ исходного кода, чтобы проверить, выполняются ли запросы в базе данных с помощью подготовленных операторов. Вы также можете использовать инструменты для проверки уязвимостей.

И вы должны также сделать следующее.

  • Используйте ORM (инструменты реляционного сопоставления объектов).
  • Побег все входы. В поле даты никогда не должно быть ничего, кроме дат.
  • Изолируйте ваши данные таким образом, чтобы в этом месте удерживались только те вещи, к которым необходимо получить доступ из определенного местоположения..
  • Пишите хорошие коды ошибок обработки. Не делайте свою базу данных или серверную часть слишком многословной.

Трой Хант получил блестящий курс по внедрению SQL. Если интересно, вы можете изучить это.

Сломанная аутентификация

Как упоминалось ранее, аутентификация имеет дело с предоставлением учетных данных. Это линия защиты от неограниченного доступа. Однако плохая реализация и несоблюдение политики безопасности может привести к нарушению аутентификации.

Сломанная аутентификация происходит в основном по трем шаблонам:

  • Полномочия начинки: где злоумышленник имеет список допустимых имен пользователей и паролей и может автоматизировать атаку, чтобы убедиться, что учетные данные действительны.
  • Атака грубой силы: где приложение разрешает слабые пароли для пользователей или администраторов.
  • Захват сессии: где приложение предоставляет идентификатор сеанса, URL или не вращается после входа в систему.

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

Как это предотвратить?

Перед внедрением системы аутентификации спросите себя – чего может достичь злоумышленник, если система аутентификации взломана?

И согласно ответу, вы можете сделать следующее.

  • Реализовать многофакторную аутентификацию для предотвращения автоматических атак.
  • Поощряйте (или вынуждайте) пользователя принять правильную политику паролей.
  • Предел неудачных входов.
  • Используйте эффективный алгоритм хэширования. При выборе алгоритма учитывайте максимальную длину пароля.
  • Протестируйте систему тайм-аута сеанса и убедитесь, что маркер сеанса недействителен после выхода из системы.

Сломанный контроль доступа

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

Общие недостатки контроля доступа включают в себя:

  • Неверная конфигурация CORS, которая допускает несанкционированный доступ к API.
  • Управление метаданными для прямого доступа к методам.
  • Принудительный просмотр: злоумышленник попробует URL-адрес, изменит пути (например, http: //website.domain/user/ на http: //website.domain/admin) и даже может обнаружить важные файлы.

Как это предотвратить?

Главным образом, сломанные недостатки доступа происходят из-за незнания основных требований эффективного управления доступом.

  • Запретить по умолчанию, кроме общедоступных ресурсов.
  • Отключите список каталогов сервера и убедитесь, что файлы резервных копий отсутствуют.
  • Ограничение скорости доступа к API для снижения влияния автоматических атак.
  • Недействительные токены JWT после выхода из системы на стороне сервера.

Выдержка данных

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

Это происходит, когда приложение не обеспечивает надлежащей защиты такой информации, как учетные данные или конфиденциальные данные, такие как кредитные карты или медицинские карты. Более 4000 записей нарушается каждую минуту.

Влияние на бизнес большое с финансовой стороны: в среднем нарушение может стоить 3,92 млн. Долл. США, согласно IBM.

Как это предотвратить?

Как бэкэнд-разработчик, вы должны спросить, какая информация нуждается в защите.

А потом для предотвращения таких недостатков

  • Зашифруйте конфиденциальные данные: для данных в REST зашифруйте все. Для передачи данных обязательно используйте безопасные шлюзы (SSL)
  • Определите данные, которые требуют дополнительной защиты, и ограничьте доступ только для группы законных пользователей только путем применения шифрования на основе ключей..
  • Избегайте слабого алгоритма шифрования: используйте современные и сильные алгоритмы.
  • Иметь безопасный план резервного копирования.

Небезопасная десериализация

Сериализация и десериализация – это понятия, используемые при преобразовании данных в объектный формат для хранения или отправки в другое приложение. Сериализация состоит из преобразования данных в объектный формат, такой как XML или JSON, чтобы сделать их пригодными для использования. Десериализация – это только обратный процесс.

Атаки против десериализаторов могут привести к атакам типа «отказ в обслуживании», «контроль доступа» и «удаленное выполнение кода» (RCE), если существуют классы, которые можно изменить для изменения поведения..

Второй пример документа OWASP top 10 предоставляет хорошую иллюстрацию сериализатора объектов PHP:

а: 4: {я: 0; я: 132; я: 1, S: 7:"Маллори"; Я: 2; s: 4:"пользователь";
я: 3, S: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Это супер-печенье, содержащее такую ​​информацию, как идентификатор пользователя, уровень пользователя и хешированный пароль..

Злоумышленник может изменить сериализованный объект, чтобы получить доступ к привилегиям администратора:

а: 4: {я: 0; я: 1; я: 1, S: 5:"Алиса"; Я: 2; s: 5:"админ";
я: 3, S: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Как это предотвратить?

Крайне важно не принимать сериализованные объекты из ненадежных источников.

Вы также должны:

  • Никогда не доверяйте вводу пользователя.
  • Проверьте данные: если ваше приложение кроме строки, убедитесь, что это строка перед использованием
  • Используйте проверку, чтобы убедиться, что данные не были изменены. Полезно, что вы отправляете данные между двумя доверенными источниками (например, храните данные на стороне клиента).

Сервер XSS

Сервер XSS (Межсайтовый скриптинг) – это тип внедрения, когда злоумышленник использует веб-приложение для отправки вредоносного кода различным пользователям. Это происходит, когда злоумышленник публикует некоторые специально созданные данные, содержащие вредоносный код, который хранит приложение. Эта уязвимость на стороне сервера; браузер просто отображает ответ.

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

Как это предотвратить?

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

  • Проверьте ввод: проверьте длину ввода, используйте соответствие регулярному выражению и разрешите только определенный набор символов.
  • Проверка выходных данных: если приложение копирует в свои ответы какой-либо элемент данных, созданный каким-либо пользователем или третьей стороной, эти данные должны быть закодированы в формате HTML для очистки потенциально вредоносных символов.
  • Разрешить ограничение HTML: например, если у вас есть система блогов для комментариев, разрешите использование только определенных тегов. Если вы можете, используйте подходящую среду для предоставленной пользователем разметки HTML, чтобы убедиться, что она не содержит никаких средств для выполнения JavaScript.

Вывод

Этап разработки имеет решающее значение для безопасности веб-приложений. И вам следует рассмотреть возможность включения сканера уязвимостей в жизненный цикл разработки, чтобы выявленные проблемы были устранены до начала производства.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map