регистрация в wordpress вообще нужна только очень ограниченному числу сайтов.
Дело не в регистрации. За .. чем-то всё (ок, многое) пропускается через load-scripts.php. Сколько тормозов и др проблем это порой добавляет в админке. А в этой «уязвимости» его используют с фронта.
Модератор
Юрій
(@yube)
За .. чем-то всё (ок, многое) пропускается через load-scripts.php
Ну как же? Рекомендации лучших собаководов специалистов по оптимизации сайтов: уменьшить количество http-запросов путем объединения всех используемых js в один документ. CSS, кстати, тоже. И скажите спасибо, что все картинки в один спрайт на лету не загоняют 🙂
Рекомендации лучших <del»>собаководов специалистов по оптимизации сайтов
Оч. хочется верить, что улучшатели хоть с этим одумаются.
Дайте теперь годное решение этой проблемы пожалуйста)
Дайте теперь годное решение этой проблемы пожалуйста)
Во первых Вы ещё достоверно не знаете причин падения. А именно это нужно узнать в первую очередь.
Во вторых решение ЭТОЙ проблемы было дано ещё вчера. Сразу же.
Ну тут уже все понятно почему, с тем человеком переговорил, он признал что это был load-script, тот баг что мы все и обсуждаем здесь.
Попробую защититься тогда, проверю снова и отпишусь
Модератор
Юрій
(@yube)
тот баг что мы все и обсуждаем здесь.
Это не баг, это фича )
Дайте теперь годное решение этой проблемы пожалуйста)
в /wp-admin/.htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in
RewriteRule load-scripts.php - [G,L]
</IfModule>
Пробуйте. Гарантии никакой, хотя бы потому, что все хостинги разные (некоторые настолько, что и на хостинги не похожи;))
И еще: я не понял, при чем тут «взлом»? Завалить сайт этим можно (как и простым обращением к главной или даже к readme.html — хватило бы ресурса на DDoS), но взломать — нет. Ну разве что при очень кривой настройке сервера под нагрузкой wp-config.php начнет отдавать как plain text, и тогда можно подсмотреть логин/пароль от базы.
p.s. Если супостат читает эту ветку и его квалификация позволяет не только скопировать готовый скрипт, то предложенный «сверхлёгкий» метод не сработает.
-
Ответ изменён 6 лет, 7 месяцев назад пользователем
Юрій. Причина: p.s
Тут есть еще такой момент.
Если на сайте тема или плагины на фронте используют load-scripts.php и тп (а таковые имеются), то при его закрытии нужно будет искать им замену.
Дело не в регистрации
ну как не в регистрации то?
wp-admin для посторонних нужен только при открытой регистрации.
если регистрация закрыта — доступ к wp-admin можно закрыть по ip или еще каким образом.
и дернуть load-scripts.php уже не получится.
Модератор
Юрій
(@yube)
Тут есть еще такой момент.
Полностью согласен. Существуют ли вообще абсолютно универсальные решения? Думаю, нет. Разве что классическое «если у вас нет собаки, ее не отравит сосед«.
ну как не в регистрации то?
Я к тому, что сама регистрация в данном случае не причём. Можно закрыть доступы к этим файлам и где она нужна.
А так-то да, запрет доступа к wp-admin (кроме /wp-admin/admin-ajax.php) решит и эту проблему. Для сайтов, где рега не нужна.
Модератор
Юрій
(@yube)
кроме /wp-admin/admin-ajax.php
Я на этот аякс-не-админ давно зубы точу 🙂 Тоже тот еще тормоз с грузилом 🙁
Тоже тот еще тормоз с грузилом
Но вот без доступа к нему не работает ещё больше плагинов. 🙁 В WC напр. без него нельзя завершить заказ. (было во всяком случае в 2й версии)
Всё надеюсь, что и до него дело когда-то дойдет.
Модератор
Yui
(@fierevere)
永子
Ну как же? Рекомендации лучших собаководов специалистов по оптимизации сайтов: уменьшить количество http-запросов путем объединения всех используемых js в один документ. CSS, кстати, тоже. И скажите спасибо, что все картинки в один спрайт на лету не загоняют
что самое смешное, что при наличии HTTPS и HTTP/2 все эти рекомендации становятся с точностью до наоборот. А сейчас у нас «мода» на внедрение HTTPS везде, где надо и не надо )
А сейчас у нас «мода» на внедрение HTTPS везде, где надо и не надо )
При данной «моде» в реальности пока ещё сложно найти хостинг с HTTP/2 🙂
