LIMB
[easy lvl] Обход ограничения “413 Request Entity Too Large”
Содержание:
Введение
Кейс
Проблема
Решение
Напутствие
Введение
Хеллоу комьюнити! Хочу поделиться своей недавней историей хакинга в мире крипты с выносом несколько к$.
Кейс:
Криптокомпания организовала игровой ивент, призовой пулл несколько к$. Один из победителей определяется пользователь, который смог набрать максимальное количество очков за попытку игры.
Спустя время я смог найти и подделать API POST запроса отправки очков при “game over” на сервера игры.
Радовался лазейки и потихоньку накручивал себе очки чтобы сильно не палиться и держать топ 1. Однако вскоре нашелся еще один “хакер”, который не стал церемониться и поставил новый рекорд с большим отрывом, 100 тыс очков.
После такого мува от конкурента, нужно было ставить самому новый рекорд, хотя бы 101 тыс очков, но тут и произошла проблема данной темы. При отправке мной 101 тыс очков, возвращалась ошибка 413 Request Entity Too Large, разрабы явно не ожидали что появятся “PRO игроки” с таким безумными результатами. И тут стало понятно, почему конкурент поставил именно такой рекорд.
Проблема:
API запрос возвращает 413 Request Entity Too Large
Решение:
По своему опыту и тексту сообщения понимаю что стоит ограничение на размер тела запроса и также по опыту знаю, что разрабы в ингрес прописывают обычно только ограничение body size message.
Поштурмив гугл и базы уязвимостей ответа не нашлось, однако ИИ подсказала решение. Большинство фреймворков разных языков поддерживают функционал чанков по дефолту (chank - способ когда данные летают не цельными запросами/ответами, а кусками, например видео в ютубе грузится не целиком, а по 15 секунд). Таким образом, убрав из заголовков запроса заголовок Content-Length и добавив заголовок Transfer-Encoding: chunked
запрос улетает и обрабатывается серверами backend, пролетая сквозь ограничения, так как в один момент времени какая либо прокся видит только один чанк, а не все тело запроса. Теперь можно хоть гигабайтами слать данные. А чтобы чанками нельзя было обойти ограничение, нужно указывать новое ограничение на чанки в конфиге.
Напутствие:
Наглядный пример как небольшими усилиями можно обойти систему и нанести дорогостоящую для владельцев компании атаку. Атаки производятся в совокупности более мелких атак, данное решение можно использовать для обхода ограничения размера тела сообщения с целью положить сервер от недостатка памяти и тригернуть перезагрузку.
Мое личное убеждение, что большинство систем подвержены взлому из-за использования дефолтных конфигов различных систем.
Бай Бай
Не удалось прогрузить медиа
Содержание:
Введение
Кейс
Проблема
Решение
Напутствие
Введение
Хеллоу комьюнити! Хочу поделиться своей недавней историей хакинга в мире крипты с выносом несколько к$.
Кейс:
Криптокомпания организовала игровой ивент, призовой пулл несколько к$. Один из победителей определяется пользователь, который смог набрать максимальное количество очков за попытку игры.
Спустя время я смог найти и подделать API POST запроса отправки очков при “game over” на сервера игры.
Не удалось прогрузить медиа
Радовался лазейки и потихоньку накручивал себе очки чтобы сильно не палиться и держать топ 1. Однако вскоре нашелся еще один “хакер”, который не стал церемониться и поставил новый рекорд с большим отрывом, 100 тыс очков.
Не удалось прогрузить медиа
После такого мува от конкурента, нужно было ставить самому новый рекорд, хотя бы 101 тыс очков, но тут и произошла проблема данной темы. При отправке мной 101 тыс очков, возвращалась ошибка 413 Request Entity Too Large, разрабы явно не ожидали что появятся “PRO игроки” с таким безумными результатами. И тут стало понятно, почему конкурент поставил именно такой рекорд.
Проблема:
API запрос возвращает 413 Request Entity Too Large
Решение:
По своему опыту и тексту сообщения понимаю что стоит ограничение на размер тела запроса и также по опыту знаю, что разрабы в ингрес прописывают обычно только ограничение body size message.
Поштурмив гугл и базы уязвимостей ответа не нашлось, однако ИИ подсказала решение. Большинство фреймворков разных языков поддерживают функционал чанков по дефолту (chank - способ когда данные летают не цельными запросами/ответами, а кусками, например видео в ютубе грузится не целиком, а по 15 секунд). Таким образом, убрав из заголовков запроса заголовок Content-Length и добавив заголовок Transfer-Encoding: chunked
Не удалось прогрузить медиа
запрос улетает и обрабатывается серверами backend, пролетая сквозь ограничения, так как в один момент времени какая либо прокся видит только один чанк, а не все тело запроса. Теперь можно хоть гигабайтами слать данные. А чтобы чанками нельзя было обойти ограничение, нужно указывать новое ограничение на чанки в конфиге.
Напутствие:
Наглядный пример как небольшими усилиями можно обойти систему и нанести дорогостоящую для владельцев компании атаку. Атаки производятся в совокупности более мелких атак, данное решение можно использовать для обхода ограничения размера тела сообщения с целью положить сервер от недостатка памяти и тригернуть перезагрузку.
Мое личное убеждение, что большинство систем подвержены взлому из-за использования дефолтных конфигов различных систем.
Бай Бай
👍52
😮11
👏9
💯9