Pull to refresh

Comments 10

Как защититься от атаки на десериализацию

Я конечно мимокрокодил, но выглядит как "оторвите зад от стула и сделайте хоть что-нибудь.."

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

Без десериализации вы нормального API не сделаете, никак.

Надо именно что использовать безопасные десериализаторы, которые десериализуют только данные, но никогда сами не загружают никакого кода.

ну и в стандартный набор классических ляпов еще и SQL-инъекцию. Попросил как-то начальник Васю добавить в интернет-магазин поиск товаров по подстроке... Дальше понятно.

Если серьезно - то валидация и экранирование всего, что пришло не из доверенного кольца - это база и основа.

Валидация вещь полезная, но вот экранировать лучше бы данные не при вводе, а при выводе.

В конце концов не важно откуда пришла строка содержащая спецсимволы, от пользователя или от админа, если есть способ корректно её вывести - надо именно этот способ и использовать.

При выводе конечно. Я наверное неточно выразился. Валидация - процесс проверки входных данных на ОДЗ. Экранирование - обеспечение соответствия выводимых данных правилам и ограничениям среды.

Для разных систем разные алгоритмы экранирования. Мы можем выводить одни и те же данные в грид бинарного приложения, в NRZ-физический канал, и на html-страницу.

В любом случае, крайне желателен принцип неискажения данных - у кого-то в конце концов может быть фамилия O’Brien, а не O'Brien, и именно так она должна лежать в БД. Исключение - законодательные ограничения и совсем узкие случаи (например, хранение бинарного кода вируса в качестве payload где-нибудь в BLOB БД - пусть даже и в лаборатории ИБ для целей анализа) - не факт, что здесь не нужно его деактивировать каким-нибудь XORом даже перед записью в базу ;).

В эпоху, когда все в Интернете делалось вручную, это все в основном соблюдалось адекватными инженерами.

Сейчас же при формировании html-вывода вручную в 90% случаев энкода не будет, а про правильный URI-энкодинг помнят вообще единицы. Все полагаются вместо этого на автоматические анализаторы сабмита форм не пропускают невинные амперсанды и одинарные кавычки, несмотря на то, что это примерно так же эффективно, как поиск врагов по цвету паспорта )

Не существует универсального способа разом решить все проблемы с помощью одного простого действия

Ну вроде бы ответ очевиден - и в том или ином виде рекомендуется "ехспертами":

например, смотрим статью хабра Компьютерная безопасность страдает от устаревших технологий / Хабр (habr.com)

И этот ответ: отказываемся от текущей версии Web-а. ЭТО НЕ ОЗНАЧАЕТ отказ от интернета, интернет-магазинов и т.д. Интернет (и вообще сети) - это не только Web.

Вообще, получается так, что когда хотят упростить жизнь всем вокруг (sql, например, задумывался как возможность всем получать нужные данные) в результате создают массу проблем. Благими намерениями вымощена дорога в Ад.

***интересные*** Видимо косяк с markdown

Нет, тут имеются в виду интересные в тройных кавычках. Классические кавычки слишком скучно, а одинарные и двойные звездочки как раз заняты болдом и италиком 

Sign up to leave a comment.