Исправление записи курсора SSRF по-прежнему уязвимо (CWE-918)

ТЛ;ДР Попросите редактора AI исправить SSRF, и он напишет поиск DNS, проверку диапазона IP-адресов, а затем fetch(url). Этот чек не имеет силы. Node разрешает имя хоста во второй раз, когда открывает сокет, поэтому сервер имен злоумышленника может вернуть общедоступный IP-адрес для вашей проверки и 169.254.169.254 для фактического соединения. Проверяйте внутри соединения, а не перед ним. Затем включите IMDSv2 и правила исходящего доступа, чтобы код приложения не был единственным, что стоит между параметром URL-адреса и вашими учетными данными. На прошлой неделе я попросил Cursor исправить SSRF. Он немедленно обнаружил ошибку, правильно объяснил CWE-918 и переписал конечную точку с анализатором URL-адресов, разрешением DNS, проверкой частного диапазона и отключенными перенаправлениями. Это выглядело как что-то из руководства по безопасности. Я почти одобрил это. Это все еще можно эксплуатировать. Не потому, что проверка неверна, а потому, что проверка выполняется для другого ответа DNS, чем запрос. Это та часть, которую я нахожу действительно интересной. Первая версия этого бага — пробел в знаниях. Второй версии нет. Модель знает, что такое SSRF, знает меры по смягчению последствий и создает код, который в любом случае дает сбой, потому что сбой происходит в промежутке между двумя строками, а не в