На вашем месте я, может, тоже так подумала бы, но я вас уверяю, это реальный проект, а не постановочная история. Просто кейс получился настолько показательный, что его захотелось разобрать в статье)
Спасибо за замечание, и вы абсолютно правы - базовые меры безопасности это must-have. Но это был первый полноценный проект моего коллеги-фронтендера, и писал он его с нуля и самостоятельно - и, как часто бывает в таких случаях, фокус был на "сделать так, чтобы работало", а не на "сделать безопасно". Главное, что он не просто оставил как есть, а пришёл к нам, попросил проверить на безопасность, признал недочёты и сам исправил все критичные уязвимости. Это и есть рост.
Да, при наличии двух источников одного и того же значения (токен и тело запроса) - логично их сверить, так что вы правы) Но цель моей рекомендации - полностью исключить использование клиентского userId, потому что если клиент не может передать userId, то подделка невозможна и проверять нечего.
В случае же, если мы по какой-то причине всё же принимаем userId от клиента - да, его надо сравнивать с тем, что в токене, и при несовпадении - выдавать 403/400 или хотя бы писать alert (как вы и предложили).
Если сервер не принимает userId из тела запроса, то и сравнивать не нужно - он сам извлекает userId из токена и работает только с записями этого пользователя. Если же userId передаётся клиентом - проверка обязательна, чтобы не дать ему действовать от чужого имени. В данном случае предпочтительнее вообще не передавать userId в теле запроса, потому что так проще. Если userId не передается клиентом - он не может его подделать. Нет параметра - нет риска.
Так и есть: безопасность — это не про устранение всех уязвимостей подряд и разовые действия, а про процесс, который включает оценку и приоритизацию рисков и мониторинг за угрозами. И да, согласна — ни open source, ни платное ПО не дают «магической» защиты. Нужно всегда проверять и контролировать :)
В норме администратор почтового сервера не должен иметь возможности напрямую исполнять код в контейнере. Его полномочия ограничены административными функциями. Здесь же шаблонизатор позволял обойти изоляцию и работать с файловой системой.
То есть у Mailcow получилось скрытое RCE через SSTI, и это уязвимость. Такая возможность возникла побочно и явно не задумывалась разработчиками.
На вашем месте я, может, тоже так подумала бы, но я вас уверяю, это реальный проект, а не постановочная история. Просто кейс получился настолько показательный, что его захотелось разобрать в статье)
Спасибо за замечание, и вы абсолютно правы - базовые меры безопасности это must-have. Но это был первый полноценный проект моего коллеги-фронтендера, и писал он его с нуля и самостоятельно - и, как часто бывает в таких случаях, фокус был на "сделать так, чтобы работало", а не на "сделать безопасно". Главное, что он не просто оставил как есть, а пришёл к нам, попросил проверить на безопасность, признал недочёты и сам исправил все критичные уязвимости. Это и есть рост.
Да, при наличии двух источников одного и того же значения (токен и тело запроса) - логично их сверить, так что вы правы) Но цель моей рекомендации - полностью исключить использование клиентского
userId, потому что если клиент не может передатьuserId, то подделка невозможна и проверять нечего.В случае же, если мы по какой-то причине всё же принимаем
userIdот клиента - да, его надо сравнивать с тем, что в токене, и при несовпадении - выдавать 403/400 или хотя бы писать alert (как вы и предложили).Если сервер не принимает userId из тела запроса, то и сравнивать не нужно - он сам извлекает userId из токена и работает только с записями этого пользователя. Если же userId передаётся клиентом - проверка обязательна, чтобы не дать ему действовать от чужого имени. В данном случае предпочтительнее вообще не передавать userId в теле запроса, потому что так проще. Если userId не передается клиентом - он не может его подделать. Нет параметра - нет риска.
Так и есть: безопасность — это не про устранение всех уязвимостей подряд и разовые действия, а про процесс, который включает оценку и приоритизацию рисков и мониторинг за угрозами. И да, согласна — ни open source, ни платное ПО не дают «магической» защиты. Нужно всегда проверять и контролировать :)
Вы правы, для "хоббистов" - баг скорее академический, но для компаний, где админка может быть делегирована или скомпрометирована - риск серьёзный.
В норме администратор почтового сервера не должен иметь возможности напрямую исполнять код в контейнере. Его полномочия ограничены административными функциями. Здесь же шаблонизатор позволял обойти изоляцию и работать с файловой системой.
То есть у Mailcow получилось скрытое RCE через SSTI, и это уязвимость. Такая возможность возникла побочно и явно не задумывалась разработчиками.