Как защитить admin.php

Есть трейд скрипт, злоумышленник постит трейдера в виде JS утягивающего куки, далее когда овнер заходит в админку, злоумышленник перехватывая куки, сам заходит в admin.php и заливает шелл. Можно конечно права на темплейты ставить, только чтение, но это крайний выход.
Вопрос, как защитить admin.php - допилить самому нереал, файл под ioncube.
Если бы была папка /admin/ можно было бы закрыть htpasswd или .htaccess по IP.
А как быть с файлом admin.php.

htaccess позволяет закрыть один файл admin.php по IP

Код: [развернуть]

<Files "admin.php">    Order Deny,Allow   Deny from all Allow from ххх.ххх.ххх.ххх </Files>

всем спасибо за решение

Int13h писал:

злоумышленник постит трейдера в виде JS утягивающего куки, далее когда овнер заходит в админку, злоумышленник перехватывая куки, сам заходит в admin.php и заливает шелл.

в смысле постит трейдера перехватывающего куки ?

да видимо просто данные, которые может постить кто-угодно, даже не обрамляются в какой-нибудь htmlspecialchars()
и видимо отправляется например в качестве имени трейдера что-то типа <script></script> в котором берутся куки и отправляются на домен злоумышленника.
дальше владелец с админки заходит в список трейдеров и у него исполняется эта ява.
потом злодей, получив куки владельца, в своем браузере подставляет их и заходит в admin.php как будто он авторизован.

а вот этот пост новых трейдеров также происходит через зашифрованное в ioncube что-то?

как вариант еще соорудить дополнительный скрипт, который будет проходиться по всем данным в базе с трейдерами и удалять к примеру все что не цифра и не буква.

Stek: -
обходит фильтр входящих данных, а именно (мыло трейдера), не проверяет скрипт. Через webmasters.php. в результате, злоумышленник постит JS, который эксплуатирует XSS уязвимость. При заходе овнера в админку, выполняется JS, передающих cookies, снифятся, используя их злоумышленник проникает в админку.
Что то подобное. http://habrahabr.ru/post/129173/

EvGenius - нет, просто если не ioncube, можно было бы webmasters.php допилить проверку входящих данных, да и admin.php можно было через $_SERVER['REMOTE_ADDR'] блокировать.

Но уже посоветовали метод защиты админки

а что за скрипт? может проще разработчику скинуть, чтоб пофиксил

Закрытие входа в админку не решает проблему полностью, т.к. враги могут и дальше постить трейдеров и запускать в браузере админа произвольный js, когда он будет заходить на admin.php.

Как вариант обернуть добавления трейдеров в обертку другого скрипта.
Т.е. что то вроде:

Код:

<?php // чистим $_POST $_GET массивы, удаляя оттуда весь мусор include('old_sad_dtrader.php');

нужно зафильтровать спецсимволы в переменной поля с мылом
htmlspecialchars
но я помню там был какой то подвох и нужно долго копать чтоб правильно без косяков фильтровать формы.
вообще ограничение по ип верный способ!

Может в htacсess попробовать запихнуть следующее

Код: [развернуть]

<IfModule mod_rewrite.c>          RewriteEngine On                 # Rules to block unneeded HTTP methods          RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]          RewriteRule ^(.*)$ - [F]                 # Rules to block suspicious URIs          RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]          RewriteCond %{QUERY_STRING} ^.*\.(bash|git|hg|log|svn|swp|cvs) [NC,OR]          RewriteCond %{QUERY_STRING} etc/passwd [NC,OR]          RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]          RewriteCond %{QUERY_STRING} ftp\:  [NC,OR]          RewriteCond %{QUERY_STRING} http\:  [NC,OR]          RewriteCond %{QUERY_STRING} https\:  [NC,OR]          RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]          RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]          RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]          RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]          RewriteCond %{QUERY_STRING} ^.*(127\.0).* [NC,OR]          RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]          RewriteCond %{QUERY_STRING} ^.*(request|concat|insert|union|declare).* [NC]          RewriteCond %{QUERY_STRING} !^loggedout=true          RewriteCond %{QUERY_STRING} !^action=jetpack-sso          RewriteCond %{QUERY_STRING} !^action=rp          RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$          RewriteCond %{HTTP_REFERER} !^http://maps\.googleapis\.com(.*)$          RewriteRule ^(.*)$ - [F]                 # Rules to block foreign characters in URLs          RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F).* [NC]          RewriteRule ^(.*)$ - [F]                 # Rules to help reduce spam          RewriteCond %{REQUEST_METHOD} POST          RewriteCond %{REQUEST_URI} ^(.*)wp-comments-post\.php*          RewriteCond %{HTTP_REFERER} !^(.*)domain.com.*          RewriteCond %{HTTP_REFERER} !^http://jetpack\.wordpress\.com/jetpack-comment/ [OR]          RewriteCond %{HTTP_USER_AGENT} ^$          RewriteRule ^(.*)$ - [F]       </IfModule>

Stek: - интересный изящный метод данные с формы post action -> $PHP_SELF , начало кода фильтрует POST данные, далее отрабатывает заинклуженный дырявый скрипт, отправляет "чистые" данные в трейд базу, выводит трейд линк. И тут даже при удалённом POST запросе, не получится запихнуть, не зная новое имя обработчика формы с уязвимостью.

Diablo - GB продукты http://www.gbscript.com/ , да древние, уже не поддерживаются, но "боевые" скрипты, тот же GB TOP, уступает только DF Pro,если не брать тот же смарт и тп современные CJ скрипты в роли Топа.

Stek писал:

Как вариант обернуть добавления трейдеров в обертку другого скрипта. Т.е. что то вроде: Код: <?php // чистим $_POST $_GET массивы, удаляя оттуда весь мусор include('old_sad_dtrader.php');

Это и имел в виду. Только старый файл нужно не просто переименовывать, а закрывать полностью.

new.php

Код:

<?php define('__INNER_CALL__', 1); //удаляем мусор из $_GET, $_POST ... require('old.php');

old.php

Код:

<?php if (!defined('__INNER_CALL__')) exit; //дальше старый код без изменений

Вообще конечно это косяк автора скрипта. Надо экранировать данные для вывода, а для сессий делать проверку по IP и ставить HTTP-only куки

Stek писал:

Как вариант обернуть добавления трейдеров в обертку другого скрипта. Т.е. что то вроде: Код: <?php // чистим $_POST $_GET массивы, удаляя оттуда весь мусор include('old_sad_dtrader.php');

webmasters.php проверяет там имя скрипта и если оно old_sad_dtrader.php не работает.

я закрывал webmasters.php в htacces для всех айпи кроме сервера и делал свою форму трейда которая проверяет входящие данные и потом курлом добавляет трейдера в старую форму

Что же это за скрипт такой, где не озабитились проверить входящие данные, но зато параноят на "а вдруг меня спиздят".

Чуть вшые писали что это GB продукты http://www.gbscript.com/

переименуй admin.php в admin_huy_vam_dostup.php