Статья Тестирование одного интересного REST API на безопасность.

Приветствую всех читателей форума.
Сегодня я буду тестировать инстанс одного интересного приложения под названием "Vampi", любезно предоставленным @szybnev.
Приложение включает в себя уязвимости из OWASP API Security Top 10.
В статье будут подсвечены такие действия как:

- Чрезмерная уязвимость данных
- Несанкционированная смена пароля
- Mass Assigment
- SQL инъекция
- Неработающая авторизация на уровне объекта

Начинаем с разведки, сканируем приложение с помощью сканера Nuclei и находим там интересный файл:

Этот файл openapi.json содержит описание структуры и функциональности API, включая конечные доступные точки, параметры запросов и другую информацию.
Открыв его мы понимаем какие у нас есть эндпоинты и куда мы можем обращаться.
Основные ручки за которые мы будем дергать это :
/users/v1/_debug
/users/v1/login
/users/v1/register
/users/v1/{username}
/users/v1/{username}/password
/books/v1
/books/v1/{book_title}


Основная часть.
Этот API endpoint "/users/v1/_debug" позволяет получить подробности о пользователях.

Попробуем обратиться к нему через Burp Suite :

Основной момент:
Чрезмерный доступ: Если конечные точки отладки оставлены и не ограждены механизмами аутентификации и авторизации,
это может привести к несанкционированному доступу, что повышает уязвимость приложения.
В спецификации OpenAPI этого параметра нет, по этому всегда стоит проверять это самому.

Если обратимся openapi.json , то понимаем как работает авторизации в приложении:
Здесь используется токен в формате JWT при доступе к ресурсам API.

Несанкционированная смена пароля
У нас есть конечная точка, которая дает возможность смены пароля:

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

Попробуем изменить пароль юзера name2 с токеном пользователя name1.
Устанавливаем в хедер токен Authorization и успешно меняем пароль.

Проверяем это:

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

user = User.query.filter_by(username=username).first()
user.password = request_data.get('password')
db.session.commit()

Mass Assigment

Так же в начале при обращении к debug заметил интересную деталь, где передается значение admin=true или admin=false.
Попробуем зарегистрировать юзера с правами администратора.

Мы успешно сделали это. И теперь мы можем использовать токен на действия с правами администратора.

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

- SQL инъекция
Если покопаться еще в приложении в url параметре одного из юзеров, поставив кавычку , то мы получим ошибку, которая
дает возможность проверить такую атаку как SQL Injection.

Воспользуемся инструментом sqlmap:

user_query = f"SELECT * FROM users WHERE username = '{username}'"
query = db.session.execute(user_query)
ret = query.fetchone()

Основные проблемы кода:

1. Неэкранированные данныx.
2. Использование методов execute с неочищенными данными.

# Параметризованный запрос для безопасности
user_query = "SELECT * FROM users WHERE username = :username"
query = db.session.execute(user_query, {"username": username})

ret = query.fetchone()

Неработающая авторизация на уровне объекта
У приложения есть функционал для получения предмета (книги) по пути /books/v1.
А так же извлечение книги и просмотр содержимого /books/v1/{book_title}.

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

В первом варианте уязвимый код, во втором код делает то же самое, но с дополнительным условием. Он ищет книгу, которая
принадлежит определённому пользователю (user).

Vulnerable Case
book = Book.query.filter_by(book_title=str(book)).first()

Proper Case
book = Book.query.filter_by(user=user, book_title=str(book)).first()

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

Вывод :
Все это в совокупности является серьезными уязвимостями, которые могут возникнуть в приложениях REST API и представляют угрозу для
безопасности пользователей и данных.

Для обеспечения безопасности приложения REST API необходимо активно наблюдать за этими угрозами, реализуя соответствующие меры защиты, такие как аутентификация и авторизация пользователей, фильтрация входных данных, использование параметризованных запросов для предотвращения SQL инъекций и продуманное управление доступом к данным. Только таким образом можно обеспечить надежную защиту от потенциальных атак и утечек данных.

Всем спасибо за внимание! Надеюсь, информация была полезной и интересной. Если у вас есть вопросы или идеи, делитесь ими в комментариях.

 

[szybnev]

Красавчик, топовая статья!