Введение
В предыдущих статьях мы обсуждали значение GraphQL в современной архитектуре. Поэтому мы не можем отрицать, что злоумышленники чрезмерно нацелены на получение информации. Поэтому в этой статье я рассмотрю несколько потенциальных опасностей GraphQL. Если вы не читали мою предыдущую публикацию в блоге о GraphQL, пожалуйста, нажмите на предоставленную ссылку и прочитайте там информацию.
https://gupta-bless.medium.com/learning-and-testing-for-graphql-vulnerabilities-3efa9b5064f9
Раскрытие данных или постоянные утечки данных
Если наши запросы Graph QL не защищены должным образом или настроены неправильно, любой неавторизованный пользователь или злоумышленник может получить доступ к конфиденциальным или конфиденциальным данным; это известно как раскрытие данных или утечка данных. Существует вероятность того, что пользователь имеет обычные права доступа пользователя, но если у него есть доступ к административным данным, это также является уязвимостью к раскрытию данных. Используя API-интерфейсы GraphQL, клиенты могут указать, какой объем данных они хотят извлечь за один запрос; однако, если эти API не контролируются должным образом, эта функция может привести к раскрытию конфиденциальных данных. Доступ к дополнительной информации может быть преднамеренным или непреднамеренным.
Возьмем пример Medium.com, где пользователи пишут свои блоги, а Medium.com обрабатывает данные в GraphQL. Итак, у него есть 2 типа схем: «Пользователь» и «Почта». У каждого пользователя есть имя пользователя, адрес электронной почты и список публикаций, которые он публикует, тогда как сообщения содержат заголовки, контент и временные метки. Таким образом, в обычных сценариях пользователь получает сообщение с заголовком, запрос GraphQL в этом случае становится:
запрос {
пользователь (unname: «ABC») {
не называть имя
сообщения {
заголовок
}
}
}
Поскольку ни для одного из параметров нет ограничений, злоумышленник может включить поле электронной почты и получить всю связанную с ним конфиденциальную информацию.
