ТЛ;ДР Попросите редактора ИИ исправить IDOR, и он правильно определит один показанный вами маршрут, а затем оставит PATCH, DELETE и конечную точку списка для поиска по первичному ключу. Конечная точка списка с незаданной областью действия — худшая половина. IDOR обычно стоит...
ТЛ;ДР
Попросите редактора ИИ исправить IDOR, и он правильно определит один показанный вами маршрут, а затем оставит PATCH, DELETE и конечную точку списка для поиска по первичному ключу.
Конечная точка списка с незаданной областью действия — худшая половина. IDOR обычно требует от злоумышленника некоторого перечисления идентификаторов, а конечная точка списка, которая возвращает записи каждого, передает эти идентификаторы бесплатно.
Исправление носит структурный характер: один аксессор в области владельца, через который принудительно проходит каждый обработчик, поэтому новый маршрут не может быть записан без проверки.
На прошлой неделе я попросил Cursor исправить IDOR. Так оно и было, и исправление было правильным.
Затем я прокрутил вниз.
Исправленный обработчик был GET /api/invoices/:id. Двадцатью строками ниже DELETE /api/invoices/:id все еще вызывал findByIdAndDelete(req.params.id). Над ними обоими GET /api/invoices возвращал каждый счет в базе данных тому, кто его спрашивал.
Исправление было реальным. У него просто был радиус взрыва в один маршрут.
Исправление, которое оно пишет
Исправление, которое редактор AI пишет для IDOR, является правильным и правильным только для одного обработчика.
Вот что я дал:
// До - CWE-639: обход авторизации через ключ, управляемый пользователем
app.get('/api/invoices/:id', requireAuth, async (req, res) => {
константа инв.