The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в приложениях на базе HTTP-библиотеки Hyper, opennews (??), 06-Янв-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


198. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +1 +/
Сообщение от MaleDog (?), 07-Янв-23, 12:58 
Э-э. Выделить небольшой буфер на проверку заголовков. Передать их обработчику, чтобы тот авторизовал, проверил и сам выделил нужное количество оперативы. Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению буфера или даже раньше передавать их обработчику. Что он с ними будет делать уже его проблема, главное буфер тут нужен чтобы избежать задержек. Но точно не пытаться считать весь запрос в оперативку.
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

208. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от MaleDog (?), 07-Янв-23, 13:33 
Ну а chunked-запрос - это извращение. Насколько я помню изначально chunked был только для ответа сервера. Но потом реализовали и для запроса. При этом у chunked отсутствует заголовок Content-Length. Сколько читать указано перед чанком. Наиболее безопасно выделять буфер непосредственно перед чтением чанка проверив предварительно, что тот не слишком длинный, так как стандартом не оговорены ни максимальная длинна, ни то что чанки должны быть одинаковой длинны.
В любом случае chunked это не про быстродействие, это скорее про "бедность" передающего на оперативку. Так что нет никаких причин быстро его на сервере обрабатывать помещая весь запрос в оперативку.
Ответить | Правка | Наверх | Cообщить модератору

339. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 08-Янв-23, 20:47 
Почему извращение?
Допустим мы хотим залить контент заранее не известного объёма.
Какую-нибудь телеметрию например, которая идёт потоком, но лить хотим по HTTP.
Why not?
Ответить | Правка | Наверх | Cообщить модератору

367. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от MaleDog (?), 10-Янв-23, 22:28 
Потому, что заранее не известно когда закончится запрос. Теоретически я хоть целый день могу развлекать сервер одним запросом(насколько хватит терпения у проектировавшего сервер). Кроме того ему нужно будет решать вопросы с увеличивающимся или уменьшающимся буфером или склеиванием, ведь максимальная длинна чанка не известна заранее и нигде не сказано что они могут быть одной и той же длинны. и эта проблема умножается на два или на три, если со стороны сервера или клиента есть прокси. Лучше уж тогда TCP и бинарный протокол, где все, включая длинну сообщения будет заранее оговорено. Не спорю то же самое можно оговорить и в заголовке HTTP, но зачем? Учитывая что выбрав бинарь вы минимум вдвое сэкономите на длинне сообщения.
Ответить | Правка | Наверх | Cообщить модератору

368. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от MaleDog (?), 10-Янв-23, 22:56 
Тем более, что часто люди просто не думают. Вот к примеру реальный случай. Мне предлагают использвать chunked HTTP(даже не HTTPS). Есть некий девайс на esp32(520 KB RAM), в нем есть буфер EEPROM на 128KB. Разработчик говорит: я не знаю сколько у меня записей будет потому не могу сказать заранее Content-Length. Но в данном случае это чистое лукавство. Судя по коду у него две третьих оперативы всегда свободны. Т. е. запрос содержащий если не половину, то четверть EEPROM можно спокойно затолкать в оперативку даже в формате JSON и посчитать его длинну.В 4-5 запросов можно передать все данные. Но нет, нужно же осложнить жизнь разработчику сервера и передать все в одном chunked, и пусть этот разработчик продумает все возможные способы атаки, где левый долбящийся бот может вызвать отказ.
Если что, реальный случай. Есть некая небольшая компания занимающаяся IOT, у них есть сайт с demo-кабинетом. Меня пригласили оценить и возможно сделать что-то подобное(я универсал, "сам пою, сам снимаю, сам по морде получаю"). Зашел в кабинет - красивенько. Ну там схема квартиры, и один датчик. Вижу кнопку "отчет" и datetimepicker. Пробую отчет за день - нормально. За неделю - сервер слегка задумался. За месяц - сервер упал. Да так что даже статус не возвращает. Вместе с сервером упал и сайт компашки. Вот специально попросил заказчика проверитть, что не меня забанили, а именно сервер упал. Да не может быть думаю. Через полчаса, когда кто-то видимо перезагрузил сервер повторяю операцию - сервер еще на полчаса в отрубе. Вот что бывает когда кто-то не продумал все возможные варианты использования его поделия.
Ответить | Правка | Наверх | Cообщить модератору

371. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 11-Янв-23, 15:07 
Про read timeout что-нибудь слышал?
Ну и да - чанк не обязательно читать целиком, снова растожаберство какое-то в голове :)
Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

372. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  –1 +/
Сообщение от MaleDog (?), 12-Янв-23, 23:15 
Тут вся суть в том. Как отличить добросовестное использование от недобросовестного. Если это обычный http запрос с Content-Length, то довольно просто выделить буфер и установить таймаут. Если это Chunked, то придется устанавливать эти правила для каждого чанка. Что гораздо затратнее.
Ответить | Правка | Наверх | Cообщить модератору

373. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +/
Сообщение от Омномним (?), 13-Янв-23, 00:45 
Чичиго?
Ответить | Правка | Наверх | Cообщить модератору

248. "Уязвимость в приложениях на базе HTTP-библиотеки Hyper"  +2 +/
Сообщение от Аноним (248), 07-Янв-23, 21:27 
> Затем выделить небольшой буфер для чтения тела запроса, читать запрос по частям по заполнению

Э-э, там, в той самой библиотеке, для этого есть aggregate - читает в буфер, размер буфера устанавливается по вкусу. Кто ж виноват, что нельзя никак заставить использовать именно это API?

Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру