От кодекс-а
Прегледах кода на Atlant Security 1.1.25. Изводът ми: не изглежда като зловреден плъгин и има доста добре обмислени защити, но не бих го сложил директно на production сайт без staging тест. Има няколко реални архитектурни риска.
Най-важните проблеми
1. Риск от загуба на данни при миграция — висок
При миграцията от старите fwwp_* таблици към aswp_*:
- данните се копират само ако новата таблица е напълно празна;
- след това старата таблица се изтрива независимо дали съдържа допълнителни записи.
Ако старата и новата таблица имат данни, старите записи могат да бъдат загубени. Същият подход при конфликтни настройки предпочита вече съществуващата нова стойност, която може да е default, пред реалната стара конфигурация.
Това трябва да се преработи с INSERT IGNORE, миграция по първични/уникални ключове и изтриване само след проверка на резултата.
2. Събира прекалено чувствителни данни — висок
Visitor logger записва:
- пълния URL, включително query string;
- IP адрес;
- referrer;
- user agent;
- потребителско име;
- история до 30 дни по подразбиране.
Така в базата могат да попаднат:
- reset tokens;
- tracking и authentication параметри;
- имейли, ЕГН или други данни от URL;
- чувствителни REST параметри.
Outbound monitor също пази пълни външни URL адреси. Ако API ключ се предава в query string, той ще бъде записан в лога.
Трябва да има централизирано премахване на чувствителни параметри като token, key, secret, code, nonce, password, signature и възможност query string изобщо да не се пази.
3. Значително натоварване на базата — среден към висок
При почти всяко посещение плъгинът:
- проверява настройки;
- проверява whitelist/blocklist;
- анализира user agent;
- евентуално прави GeoIP lookup;
- записва ред в aswp_visitor_log;
- после прави допълнителен UPDATE за title/post/status.
На сайт с реален трафик това практически означава поне 1–2 допълнителни SQL операции на request. При твоя случай с oversold shared hosting, Redis timeout-и и ограничени DB connections бих бил особено предпазлив.
4. Rate limiting не е атомарен — среден
REST limiter използва APCu масив или WordPress transient чрез:
- прочитане;
- добавяне;
- записване.
При няколко едновременни заявки част от обновяванията могат да се загубят. Това позволява реалният лимит да бъде надвишен. За security limiter е по-добре атомарно Redis increment, object-cache lock или SQL операция с уникален bucket.
5. Неточно логване на HTTP статусите — среден
Request logger се стартира още на init. В този момент повечето заявки изглеждат като HTTP 200. Има специална корекция за 404, но не виждам общо финално обновяване за:
- 301/302;
- 401/403;
- 429;
- 500 и други грешки.
Следователно статистиката може да показва 200 за заявки, които реално са приключили с друг статус.
6. Security плъгинът има огромна зона на влияние
Той контролира едновременно:
- login URL;
- WAF;
- IP blocking;
- REST API;
- XML-RPC;
- 2FA;
- сесии;
- security headers;
- cron;
- файлове и quarantine;
- външни HTTP заявки.
Това не е директна уязвимост, но един regression може да счупи WooCommerce, Gutenberg, cron, webhooks, update проверки или външни API интеграции. Има safe mode чрез:
define('ASWP_SAFE_MODE', true);
Това е добро решение, но изисква достъп до wp-config.php.
Какво е направено добре
Кодът е осезаемо по-добър от типичен случаен WordPress security плъгин:
- AJAX методите обикновено проверяват nonce и capability.
- Няма видими backdoors, eval, shell изпълнение или прикрито изпращане към съмнителен сървър.
- 2FA flow има отделен HMAC challenge, ограничение на опитите, cooldown и bcrypt за email/recovery кодовете.
- Проверява се path traversal преди download/quarantine.
- Quarantine файловете губят изпълнимото си разширение.
- Има защита срещу SSRF, IPv6 и DNS rebinding при външни заявки.
- Cloudflare IP headers не се приемат сляпо.
- WAF първоначално работи в log mode.
- Има аварийна процедура срещу заключване на администратора.
- SQL заявките с входни стойности в повечето случаи използват $wpdb->prepare().
Допълнителни забележки
- TOTP secret се пази в чист вид в usermeta. Това е обичайно, защото е необходим за проверката, но при изтичане на базата 2FA защитата пада. Може да се криптира със server-side ключ.
- Scanner-ът е основно regex-based. Ще има false positives и не трябва автоматично да се приема за еквивалент на професионален malware scanner.
- REST rate limiting чрез transients може сериозно да пълни wp_options, ако няма persistent object cache.
- Плъгинът записва голямо количество информация, което изисква поне актуализирана privacy policy и разумна retention настройка.
- Не успях да пусна автоматичен php -l, защото PHP CLI липсва в средата; анализът е статичен преглед на кода.
Оценка
| Област | Оценка |
|---|
| Видима злонамереност | Не открих |
| Организация на кода | 7/10 |
| Защитно програмиране | 8/10 |
| Производителност | 5/10 |
| Privacy/GDPR | 4/10 |
| Безопасност при обновяване | 4/10 |
| Подходящ за директен production install | Не |
Моята практична присъда: изглежда сериозно разработен, но е прекалено агресивен и комплексен. Бих го тествал на копие на сайта, бих изключил visitor logging или поне query strings, и задължително бих поправил миграцията преди доверено production използване.
www.facebook.com
