Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
Правда эта настройка чуть ли не первое, что включают на реальном продакшне при сколь-нибудь существенной нагрузке
Спорное утверждение
Обычно до Jetty/Tomcat и т.п. стоит, например, nginx, на его уровне и включается сжатие
достали постоянные критические уязвимости в Jetty и переключил сервисы на grizzly
Как то в нем меньше уязвимостей находят.
Jetty в половине случаев используется как встроенный движок для проектов на Spring Boot и тут уже так просто "переключить сервисы" не выйдет.
То, что их не находят не значит, что их нет - возможно просто никто особо не ищет.
А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей".
Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание.
"не должен показывать" и все тут.
Так и довод мой довод, что "gzip" в принципе не может прилететь из этого доверенного источника, не был принят во внимание (если уж источник/канал компрометирован, то от туда прилетит финансовое распоряжение, а не gzip бомба)
"не должно быть.."
Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.
А Spring Boot это вообще.. переписывать на 4.x cо старых 2.x потому что "не должно быть сообщений об уязвимости".. Сервисы которым уже по 10 лет (и работают).
А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.
А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей". Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание. "не должен показывать" и все тут.
Так тут проблема не в Спринге, а в вашей СИБ - и вы ее "решили" отказавшись от Спринга, но это ж не решение, правильно? Завтра возможности отказаться от чего-то что бы накормить СИБ не будет, и вы обратно окажетесь в такой же ситуации, только вместо Спринга будет что-то еще.
Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.
Заметьте, заменили вы не потому, что Спринг плох или Гризли хорош, а потому что нашелся кто-то, кто заставил вас психануть.
А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.
Это говорит только о том, что уязвимости ищут и находят - и вам о них говорят. А, ка я и сказал, то, что в Гризли ничего не найдено вовсе не говорит, что в нем нет дыр размером с верблюда - может их просто не ищут и не сообщают о них, поди знай...
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.
Думаю очевидно, что проблема тут ни разу не в Спринге, а в том, что кто-то не хочет включать мозг, и спускает указивки на "устранение уязвимостей" не приходя в сознание.
Думаю несложно догадаться, что при таких вводных даже реализация «сторожевого пса» (Watchdog) для сервиса на Java представляет проблему.
эээ. чешу репу. а как же -XX:+ExitOnOutOfMemoryError, -XX:+CrashOnOutOfMemoryError ?
Оно не всегда срабатывает, а генерация crash-репорта на проде - так себе занятие.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Март, Jetty и утекшая память