Статичният преглед на ini-protector 1.9.5 изглежда добре. Не открих нещо, което да ме накара да кажа „не го слагай на публичен сайт“.
Оценката ми е приблизително: 8/10 за кодова сигурност. Бих го използвал, но с няколко забележки.
Положителното:
- Няма eval(), exec(), shell_exec(), system(), скрит PHP payload или подозрителна obfuscation.
- Няма неизвестни бинарни файлове в ZIP-а.
- Всички PHP файлове минават php -l без syntax errors.
- Admin операциите като промяна на настройки, блокиране на IP, integrity действия и update са защитени с capability checks и nonce проверки.
- REST endpoint-ът /secwp/v1/state не е публично четим. Работи само ако INI WP connector е конфигуриран и използва HMAC проверка + site ID.
- Собственият update механизъм всъщност тегли само от downloads.wordpress.org, а не от някакъв произволен сървър на разработчика. Допълнително проверява slug, версия и името на плъгина преди инсталация.
- SQL заявките, които видях, използват $wpdb->prepare() там, където има променливи параметри. Динамичните имена на таблици са вътрешно генерирани, не идват от request.
- IP блокирането по подразбиране използва REMOTE_ADDR, което е правилният консервативен подход.
- TOTP secret-ът се криптира с sodium_crypto_secretbox, когато libsodium е наличен.
- Recovery кодовете се пазят хеширани.
- ALTCHA е self-hosted.
- Vulnerability scanner-ът говори с wpvulnerability.net; не видях изпращане на потребителски данни натам.
Има обаче няколко неща, които бих имал предвид:
- SECWP_TRUST_PROXY
Има настройка:
define('SECWP_TRUST_PROXY', true);
При включването ѝ плъгинът започва да вярва на:
CF-Connecting-IP
X-Forwarded-For
Това е безопасно само ако origin сървърът реално не може да бъде достъпен директно.
Например ако сайтът е зад Cloudflare, но IP адресът на origin-а е публично достъпен, атакуващ може директно да прати:
X-Forwarded-For: 1.2.3.4
и да подмени адреса, използван от traffic/autoblock системата.
Аз бих оставил SECWP_TRUST_PROXY изключен, освен ако firewall-ът допуска HTTP/HTTPS само от Cloudflare/proxy.
- Webhook-ът на File Integrity допуска произволен HTTP/HTTPS адрес
Проверява се само:
http://
https://
Тоест администратор би могъл да сложи примерно:
http://127.0.0.1:...
Технически това е SSRF surface.
Тук рискът е нисък, защото URL може да задава само администратор с manage_options. Но за security plugin бих предпочел да използва wp_safe_remote_post() вместо wp_remote_post().
Това е най-конкретното нещо, което бих поправил в кода.
- TOTP fallback към plaintext
Ако libsodium липсва:
if ( ! function_exists( 'sodium_crypto_secretbox' ) ) {
return $plain;
}
Тоест TOTP secret-ът се записва некриптиран в базата.
Не е vulnerability сама по себе си — ако някой вече има DB + WordPress salts, ситуацията така или иначе не е добра — но за security plugin поведението не ми харесва.
На нормален PHP 8.x Linux сървър почти сигурно имаш sodium. Просто бих проверил:
php -m | grep sodium
Трябва да върне:
sodium
- Traffic monitor може да стане тежък
Това е по-скоро operational проблем, отколкото security vulnerability.
При включен traffic logging се прави DB insert при почти всяка frontend заявка:
$wpdb->insert(...)
и на приблизително 2% от заявките прави pruning проверки.
Default retention е 90 дни, а default:
MAX_ROWS = 0
тоест няма твърд лимит на броя редове.
На сайт с 1–5 хил. заявки дневно — нищо особено.
На сайт със стотици хиляди HTTP заявки дневно тази таблица може да стане значителна.
Аз бих сложил например:
Retention: 30 days
Max rows: 200000–500000
ако целта е просто security telemetry.
- Auto-block бих оставил първо в suggestion mode
Самият автор правилно го е направил така по подразбиране.
Логиката маркира като подозрителни неща като:
404
wp-login POST
/.env
/.git
xmlrpc.php
empty user agent
Това е разумно, но автоматично IP blocking винаги носи риск от false positives.
Затова първоначално:
Auto Block: ON
Enforce: OFF
и след седмица-две гледаш предложенията.
Има и нещо, което специално ми харесва: кодът изглежда писан с мисъл за security, а не просто като marketing „security plugin“. На доста места има allowlists, validation, hash_equals(), wp_safe_redirect(), nonce-и, capability проверки и коментари защо е избран даден подход.
За публичен WordPress сайт бих го пуснал.
Моята конфигурация би била:
2FA ON
Limit login ON
ALTCHA ON
File integrity ON
Vulnerability scan ON
Security headers ON
Info disclosure ON
Traffic monitor ON, но с retention limit
Auto-block Suggest mode първоначално
SECWP_TRUST_PROXY OFF
И задължително бих проверил sodium.
Най-сериозната промяна, която бих предложил на разработчика, е wp_remote_post() за webhook-а да стане wp_safe_remote_post(). След това не виждам очевиден blocker за production публичен сайт.
Това е статичен code audit, не pentest — т.е. не доказва отсъствие на уязвимости, но не открих очевидна RCE, SQL injection, unauthenticated privileged action, backdoor или подозрително изтичане на данни.
www.facebook.com
тъкмо го одобриха в репо-то