Comments 16
В отношени youtube. Это, вроде как, логично — проверять корректность названия ролика на уровне UI, на клиенте, при помощи Javacript и только потом отправлят запрос на сервер. В случае с API на клиенте-то нечем проверить, надо было добавить проверку и на сервере?
Зло JSON
Иногда API предоставляется не только для какого-то конечного юзера, а порой и для пересылки данных внутри проекта. Часто это встречается на больших, крупных сайтах с различными доменами. И как-то надо взаимодействовать на стороне клиента между доменами, и тут на помощь приходит JSONP. Это такой JSON с нужными на домене 1, который оборачивается в callback. При обращении на домен 1 юзер отправит свои куки, и можно проверить, авторизован ли он и выдать нужные данные. На втором домене вставляется подобный JS
Абсолютно не понял, причём здесь JSON(P). Это просто вид CSRF-атаки, и защищаться от неё нужно CSRF-токеном.
При том, что когда разработчики реализуют jsonp для кроссдоменной работы (как в примере выше, некоторое внутренее API) как раз и допускают и ошибку, что отсутствуют какие-либо токены (о которых обычно нигде не говорится).
Это всего лишь подвид уязвимости, не самый частый и опасный.
Найти подписывание с ключом справа — тоже не так часто можно встретить.
Моя задача была — дать более-менее универсальный обзор ошибок при разработке API. При этом случай с jsonp — один из популярных, особенно в «западных» проектах.
Моя задача была — дать более-менее универсальный обзор ошибок при разработке API. При этом случай с jsonp — один из популярных, особенно в «западных» проектах.
CSRF в целом гораздо опаснее и популярнее, чем его jsonp-подвид. Странно, что вы решили его (CSRF) даже не упоминать.
Где CSRF популярен, в API?
Ага.
Раскройте полностью мысль, приведите примеры, ибо API в веб может быть абсолютно разным. Если говорить про API с подписыванием каждого запроса — о каком CSRF вообще может идти речь?
Иначе комментарии больше похожи на троллинг и провокации, нежели чем на что-то конструктивное.
Иначе комментарии больше похожи на троллинг и провокации, нежели чем на что-то конструктивное.
Перечитал комментарии, не заметил троллинга и провокации.
Те же самые внутренние API, о которых вы говорите в разделе «Зло JSON» часто имеют ручки, выполняющие некоторые действия. Эти ручки часто не защищены токенами, либо их авторы предполагают, что перевода их на POST вместо GET достаточно для обеспечения безопасности. Это гигантская дыра, которую можно найти почти в любом крупном проекте.
CSRF, строго говоря, это возможность выполнить некое действие «от имени пользователя», заманив его сайт злоумышленника, откуда JS-ом или сабмитом форм в iframe будет выполняться специально сгенерированный запрос к API сервиса. Раскрытие информации через jsonp — один из вариантов использования незащищенной CSRF-ручки — разумеется, не единственный. Наиболее типичные и опасные случаи — это выполнение некоторых действий от имени пользователя (постинг сообщений, например).
Те же самые внутренние API, о которых вы говорите в разделе «Зло JSON» часто имеют ручки, выполняющие некоторые действия. Эти ручки часто не защищены токенами, либо их авторы предполагают, что перевода их на POST вместо GET достаточно для обеспечения безопасности. Это гигантская дыра, которую можно найти почти в любом крупном проекте.
CSRF, строго говоря, это возможность выполнить некое действие «от имени пользователя», заманив его сайт злоумышленника, откуда JS-ом или сабмитом форм в iframe будет выполняться специально сгенерированный запрос к API сервиса. Раскрытие информации через jsonp — один из вариантов использования незащищенной CSRF-ручки — разумеется, не единственный. Наиболее типичные и опасные случаи — это выполнение некоторых действий от имени пользователя (постинг сообщений, например).
Спасибо за развернутый комментарий и ценное дополнение, про подобные случаи согласен.
Вообще в ходе подготовки доклада сложно было разделить типичные веб-баги (ведь CSRF всюду, не только в API) и баги именно при реализации API, так что скорее из-за этого опустил этот момент. Про jsonp добавил вообще за день до выступления и долго сомневался, нужно ли.
Ну а теперь тот, кто прочтет статью и комменты, узнает чуть больше (:
Вообще в ходе подготовки доклада сложно было разделить типичные веб-баги (ведь CSRF всюду, не только в API) и баги именно при реализации API, так что скорее из-за этого опустил этот момент. Про jsonp добавил вообще за день до выступления и долго сомневался, нужно ли.
Ну а теперь тот, кто прочтет статью и комменты, узнает чуть больше (:
Не, не, вы _немного_ про разное говорите. Собственно одно есть нарушение целостности, а другое конфиденциальности. Да, технически МЕТОД АТАКИ — CSRF, и Токен будет решением. Но с точки зрения ИБ — это немного разные риски и угрозы. Например JSONP возвращает по запросу список сообщений к клиенту. Зачем мне городить токен, если JSON достаточно? Изменить через этот «CSRF» ничего нельзя, только получить, но так как у меня JSON без P, то и украсть нельзя. Какие в итоге у меня угрозы от этого CSRF, который, несомненно есть и зачем вы мне навязываете токен?
Sign up to leave a comment.
Тестирование безопасности клиент-серверного API