Egorov N.V. -> Artem Chuprina @ Mon, 16 Nov 2015 22:10:56 +0300: >> EN> А у вас есть гарантия что вам отвечает ваша-же программа, или что >> EN> программа той-же версии что ваша? Если нет, то валидация всех >> EN> полей, особенно на переполнение, преобразование во внутренне >> EN> представление и так далее. >> >> EN> Та же самба торпеду в протокол много раз получала, причем с >> EN> исполнение произвольного кода - ну что-то не провалидировали. >> >> EN> С текстом устроить такую подлость гораздо сложнее... >> >> Ой, да ладно... SQL injection, Javascript injection, XSS... >> >> Проблема валидации недоверенных данных для текста стоит в тот же >> полный рост.
EN> Разговор начался с оверхеда в текстовых протоколах, и быстроты разбора. EN> Несомненно, все типы взаимодействия с недостоверными источниками EN> требуют валидации. Просто не надо утверждать что валидация двоичных EN> данных менее затратна, чем валидация текста. Обратного тоже утверждать не стоит. Они имеют примерно равные затраты на валидацию. EN> Хочу отметить что все приведенные вами примеры атак и происходят в EN> случае интерпретации текстового протокола как простого потока двоичных EN> данных, и решается все семантическим, или хотя-бы грамматическим EN> разбором поступивших данных. Ну, тут палка как минимум о двух концах. Сами эти атаки возможны только потому, что некий движок как раз занимается их грамматическим разбором и последующим семантическим выполнением. И проблема, как ни смешно, встает как раз оттого, что протокол-то текстовый. Что в результате код и данные идут в одном потоке (текст - очень слабо структурированная штука, в нем иначе не получается), и их легко перепутать. Другое дело, что в случае реализации чего бы то ни было на C/C++ любой бинарный протокол обладает ровно тем же недостатком. Ключевые слова - buffer overflow. А вот если памятью управляет рантайм языка, то бинарный протокол внезапно может оказаться надежнее - идея засунуть полученные оттуда данные в eval (или любой его аналог, начиная с SQL-выражения) без предварительного даже не анализа, а преобразования, немедленно оказывается дурацкой. Тупое втыкание СРАЗУ не работает. А раз уж требуются какие-то прыжки и ужимки, то уж берется API, где код и данные разделены (даже если там внутри они снова будут сложены в один текст, как в случае с многострадальнм SQL). Правда, как раз в случае с SQL быстро выясняется, что к нему не существует API, дающих одновременно и разделение, и полную функциональность... В большинстве даже банальный LIKE уже требует injection и экранирования вручную, что уж говорить об ORDER BY RANDOM()...
