Okta's NextJS-0auth troubles 🔥 Горячее
Исследователь безопасности сообщил об уязвимости инъекции параметров OAuth в библиотеке auth0/nextjs-auth0 от Okta, которая позволяла злоумышленникам манипулировать токенами и URI перенаправления. Он предложил простой патч с кодированием параметра, но через три недели его PR закрыли, сославшись на другой, "подписанный" коммит. Оказалось, что оригинальный вклад исследователя был присвоен с использованием ИИ, который создал фиктивного автора "Simen A. W. Olsen" с несуществующим email.
Мейнтейнер признал использование ИИ для создания коммита и даже сгенерировал ИИ-ответ с извинениями, но отказался исправить атрибуцию, заявив, что "не может это изменить". Это привело к обвинениям в нарушении авторских прав. Параллельно первая уязвимость, позволявшая захватывать аккаунты, была исправлена только после трёхнедельного ожидания, а команда безопасности Okta заявила, что не примет отчёт об уязвимости без видеодемонстрации эксплуатации.
Комментарии (135)
- Комментаторы обсуждают, что Okta и Auth0 не редко становятся объектом критики за игнорирование PR и отсутствие прозрачности в open-source-проектах.
- Участники также отмечают, что крупные корпорации, включая Okta, плохо справляются с внешними вкладами и не предоставляют должного признания авторам вкладов.
- Некоторые комментаторы поднимают вопрос о том, что использование SaaS-решений вроде Okta и Auth0 может быть рискованным, особенно если учесть их историю игнорирования уязвимостей и отсутствие прозрачности.
- Также обсуждается, что GitHub и другие платформы могли бы улучшить свой процесс рассмотрения PR и взаимодействия с внешними вкладами, чтобы избежать подобных ситуаций в будущем.
Vendors that treat single sign-on as a luxury feature 💬 Длинная дискуссия
SSO Wall of Shame — список вендоров, считающих SSO роскошью, а не базовой безопасностью.
SSO позволяет компании управлять доступом через собственный поставщик идентификации (Google, Okta, Azure AD), централизованно создавать/удалять аккаунты и мгновенно отключать уволенных сотрудников. Для любой организации >5 человек это критично.
Однако вендоры прячут SSO за «Enterprise»-тарифами, где цена выше в 2–4 раза или привязана к большому пакету ненужных функций. Это тормозит внедрение безопасности.
Примеры завышенных надбавок
| Вендор | Базовая цена | SSO-цена | Рост |
|---|---|---|---|
| Airtable | $10/польз./мес | $60 | +500 % |
| Appsmith | $15 | $2 500 | +16 567 % |
| Coursera | $399/польз./год | $49 875/год | +12 400 % |
| Cloudflare | $20/домен/мес | $1 000 | +4 900 % |
| Breezy HR | $171/мес | $1 500 | +777 % |
| DatoCMS | $100/мес | $667 | +567 % |
| Canva | $10/польз./мес | $40 | +300 % |
| Figma | $12 | $45 | +275 % |
| Bitrise | $90 | $270 | +200 % |
| Box | $5 | $15 | +200 % |
(и ещё ~30 компаний с ростом 15–167 %).
Вывод: если вендор «серьёзно относится к безопасности», SSO должен быть либо в базе, либо за умеренную доплату.
Комментарии (159)
- «SSO-налог» — это не техническая, а ценовая сегментация: крупные клиенты обязаны иметь SSO (SOC2), поэтому за него платят.
- Поддержка SSO действительно дорога: множество тикетов, сложные интеграции, вызовы инженеров, особенно при частных IdP.
- Часть вендоров всё же даёт базовый SSO через Google/GitHub/Microsoft, но «частный IdP» остаётся маркером Enterprise.
- Малым компаниям SSO тоже нужен по контрактам, но высокие цены отталкивают; кто-то предлагает субсидии или прокси-решения.
- Итог: SSO = не «фича», а показатель зрелости клиента и объём его кошелька.