Журнал "Information Security/ Информационная безопасность" #4, 2024

Небезопасная десериали- зация, атаки и внедрения в XML достаточно уверено вошли в OWASP Top 10. Рекомендуется использо- вание открытых стандартов, таких как REST, JSON и OAuth для обеспечения совместимости API с другими системами. Желательно на всех ста- диях смотреть, как изме- няется API, чем спродюсиро- ваны эти изменения, насколько они корректны. дает больше возможностей. Но это относится и к возможностям злоумышленников по осуществ- лению атак на наши приложе- ния. Небезопасная десериали- зация, атаки и внедрения в XML достаточно уверено вошли в OWASP Top 10 и присутствуют как подкатегории актуального рейтинга. 4. Возможность загружать файлы на сервер. По сути, c точки зрения безопасности это еще один, достаточно вариативный способ получения данных, нуж- дающийся в контроле. Передача измененных либо же созданных специально для целей осуществ- ления атак файлов – по-прежнему актуальные и часто эффективные методики применяемые злоумыш- ленниками. И опять таки, это усложнение самой API. Корректность – понятие растяжимое Часть из упомянутых выше контролей относятся и к без- опасности, и к структурирова- нию API, которое хорошо про- водить на этапе проектирова- ния, наблюдать в процессе тестирования API и отслеживать после публикации. При этом никуда не уходит (но видоизме- няется) практика моделирова- ния угроз – то есть формирова- ния отношения и формулиро- вания риск-аппетита по отно- шению к таким контролям. Понятно, что для приватных и публичных API внимание к таким контролям может быть совершенно разное, а значит и выдачу информации по таким API можно разделить и отдель- но настроить. Таким образом корректность формирования API можно наблюдать как минимум в двух разрезах: l насколько то, что запроекти- ровано, действительно соответ- ствует функционирующему API; l насколько корректно и без- опасно то API, которое мы внед- рили, с учетом существующих практик. Принципы построения идеального API С точки зрения построения идеального API опять-таки есть базовые принципы, часть из них мы упомянули выше, в составе контролей безопасно- сти и при описании процесса. Давайте их суммируем. 1. Рекомендуется использова- ние открытых стандартов, таких как REST, JSON и OAuth для обеспечения совместимости API с другими системами. Этот пункт больше относится к повторному использованию и масштабиро- ванию созданного API. 2. Не придумывайте слишком много кодов состояний и всегда применяйте одни и те же коды для одинаковых результатов в API. Таким образом тестирова- ние и использование API будет более прогнозируемым. 3. Используйте разбиение на страницы, фильтрацию и сор- тировку при выборе коллекций записей. Представьте, что ваше API вырастет и будет отдавать больше записей, чем вы пред- полагали изначально. С этим, кстати, столкнулся известный сервис NVD, предоставляющий доступ к информации об уязви- мостях, и разработчикам при- шлось в итоге реализовать подобное ограничение. 4. Распределяйте параметры по эндпоинтам с учетом кон- текста данных и количества записей. Эта рекомендация затрагивает и вопросы безопас- ности (сокращение площади атаки), и вопросы управляемо- сти (возможность предоставле- ния большей части функций без большой переделки API). 5. Реализация базовых конт- ролей безопасности: шифрова- ние ответов, аутентификация, включение в ответы только необходимой информации. Как проконтролировать про- цесс создания и функциониро- вания API? Здесь мы конечно не сможем обойтись без инструментария, но так или иначе весь он будет нацелен на обеспечение дове- рия тем этапам, которые мы ведем. 1. Документирование API, управление версиями API. Как база и основа, не только как элемент разработки, но также и хороший инструмент, с помо- щью которого можно встроить автоматическую проверку по контролям. Если есть OAS, можно увидеть, что хотели сде- лать, и что получилось в итоге в трафике к этому API. 2. Тестирование API. Если на вход подается OAS, то компо- нент ПРО API Тест может про- вести все необходимые провер- ки. Таким образом мы понима- ем, что API безопасен. 3. Фиксация OAS. Если API задокументирован и согласо- ван, то его публикацию хорошо осуществлять через API Gate- way, на котором ограничивают- ся вызовы всех функций, не указанных в документации. В линейке продуктов ПРО API этим заведует компонент "ПРО API Защита". 4. Мониторинг API. Желатель- но на всех стадиях смотреть, как изменяется API, чем спро- дюсированы эти изменения, насколько они корректны. В заключение Все, что мы разобрали выше, позволяет минимизировать уровень неизвестности отно- сительно того, что происходит в ваших API. А чем меньше неизвестного, чем больше наблюдаемости, тем выше вероятность, что при атаке, неправильной работе или ошибках интеграции у вас будет больше информации для быстрого и корректного выхода из сложившейся ситуации. l 46 • СПЕЦПРОЕКТ АДРЕСА И ТЕЛЕФОНЫ ВЕБМОНИТОРЭКС см. стр. 62 NM Реклама Рис. 5. Влияние факторов на оценку рисков Фото: Вебмониторэкс