Платформата за автоматизация на работни процеси n8n, използвана широко в корпоративни среди за интеграция и автоматизация, е открила сериозна уязвимост, която застрашава сигурността на потребителските акаунти. Проблемът се проявява при Enterprise инсталации, които са конфигурирани да приемат удостоверителни токени (JWT) от повече от един външен издател.
Какво се случи?
При нормална работа, когато потребител се идентифицира чрез JWT токен, системата трябва да провери както идентификатора на потребителя (sub claim), така и издателя на токена (iss claim), за да потвърди, че токенът е валиден и принадлежи на правилния потребител. В конкретния случай на n8n обаче, при конфигурация с множество издатели, платформата е проверявала само идентификатора на потребителя, игнорирайки издателя.
Това означава, че ако нападател разполага с валиден токен от издател А, който съдържа идентификатор (sub) на потребител, съществуващ под издател Б, системата ще го впусне в акаунта на този потребител без допълнителна проверка. По този начин се заобикаля необходимостта от парола или други мерки за автентикация.
Защо това е важно?
Тази уязвимост подкопава основни принципи на сигурността при удостоверяване и достъп до системи. В корпоративни среди, където n8n се използва за автоматизиране на критични процеси и интеграция на различни услуги, компрометирането на потребителски акаунти може да доведе до сериозни последици. Злонамерени лица биха могли да извършват операции от името на други потребители, да получат достъп до чувствителни данни или да нарушат работата на автоматизираните процеси.
По-широк контекст
Използването на JWT токени за удостоверяване е широко разпространена практика в съвременните уеб приложения и платформи. Токените съдържат информация, която удостоверява самоличността на потребителя и се подписват от доверен издател. Важно е системите да проверяват както идентификатора на потребителя, така и издателя, за да гарантират, че токенът е валиден и не е подправен.
Проблемът при n8n показва колко е критично правилното имплементиране на тези проверки, особено когато се работи с множество издатели на токени. Подобни грешки могат да доведат до сериозни пробиви в сигурността, които да застрашат както потребителите, така и цялата инфраструктура на компанията.
Какво може да последва?
След откриването на уязвимостта, разработчиците на n8n вероятно ще пуснат актуализация, която коригира начина, по който се обработват JWT токените при множество издатели. Потребителите на Enterprise версии трябва незабавно да приложат тези обновления и да прегледат конфигурациите си, за да ограничат риска от злоупотреби.
Освен това, този случай подчертава необходимостта от редовни одити на сигурността и внимателно тестване на системите за автентикация, особено при сложни конфигурации с множество доставчици на удостоверяване. В дългосрочен план, компаниите трябва да инвестират в обучение и инструменти, които да им помогнат да откриват и предотвратяват подобни уязвимости.
