Форум MySQL

А меня интерует такой вопрос:
Злоумышленник получил доступ к дериктории с документами(скриптами), но пароль от базы он не знает (он храниться в подключаемом файле который вынесен в другую директория).
Но он может изменять код моих скриптов с энными целями
ВОПРОС
как мне сделать так что даже получив возможность изменять скрипты он не смог изменить данные БД (личные данные) т.е. как сделать так чтоб обращение к полям таблицы осуществлялось авторизованно?

>Злоумышленник получил доступ к дериктории с документами(скриптами), но пароль от базы он не знает

Если скрипты в этой директории используют базу данных, то и злоумышленнику и не нужно ничего искать. Он просто модифицирует Ваши скрипты и выполнит нужные ему деструктивные действия.
Например у Вас в скрипте был запрос SELECT, а он изменит на DELETE. И все - грязная работа сделана.

>т.е. как сделать так чтоб обращение к полям таблицы осуществлялось авторизованно?
Дело в том, что оно и осуществляется авторизованно - Вы же используете логин и пароль к серверу БД. А тут речь идет о том, что злоумышленник завладел рабочими скриптами, использующими авторизованый доступ к БД.

Т.е., если это Ваши "рабочие" скрипты, то получив к ним доступ злоумышленник может сделать все что угодно.

ну "рабочий" скрипт обращается к базе через другой скрипт (вынесенный из каталого документов) и в этот скрипт отправляется сам запрос и пароль (ну и по ай-пи еще проверку можно сделать).
Я вот типа такого думаю ...
как бы такое осуществить?
Ведь очень много дырок есть ... для получения доступа к каталогу документов :(
хочется узнать как усложнить задачу взлома злоумышленнику !
ну и какие методы есть для взлома тоже интересно знать чтобы знать что делать нельзя !

>ну "рабочий" скрипт обращается к базе через другой скрипт (вынесенный из каталого документов) и в этот скрипт отправляется сам запрос и пароль (ну и по ай-пи еще проверку можно сделать).
Я вот типа такого думаю ...

Защита может быть только в таком плане - любой запуск скрипта сопровожается вводам пользователем логина и пароля вручную. А иначе как узнать кто запускает этот скрипт: хозяин или злоумышленник. И тогда представьте, что любое обновление страницы вызывает окно для ввода логина и пароля. Нонсенс.

Вообще мы обсуждаем некорректную тему...
Несанкционированный доступ в директорию со скриптами - это уже "крах всего". Именно на недопущение такого доступа должны быть направлены действия.
А когда мы обсуждаем, что делать после того как злоумышленник уже проник в систему - это похоже на обсуждение нужно ли было мыть окна перед пожаром.

>Ведь очень много дырок есть ... для получения доступа к каталогу документов :(
Хм... вообще говоря - это задачи сетевой безопасности. И эти дырки - это дырки сервера и установленного на нем ПО.
И если это не Ваш собственный сервер, то вы практически бессильны что либо предпринять.

ну а какже куки?
Ну и можно после авторизации разрешить работать энное время (минут 10) если нет обращение дольше "10 минут" или происходит обращение с другого ip чем тот что был последнее обращение то просить заново авторизацию
плюс можно привязать к провайдеру(т.е. создать маску IP) ну это человек сам должен выбрать дабы собирать данные всех провайдеров страны дело "муторное".

Если у профессионала будет цель взломать сайт куки и IP его задержат, но не остановят - всё это можно подделать при должной сноровке.

Суть в том что PHP не решает средств сетевой безопасности – это язык "генерации страничек". Да, можно писать php-скрипты так, чтобы в них было по меньше дыр. Но защита сервера и защита доступа к директориям… – эти задачи решаются на других уровнях – на уровне web-сервера, самого сервера, установленного на нем ПО, конфигурации сети.
А вы ведь очень просто и понятно поставили вопрос: что делать после того, как кто то уже получил доступ к скриптам на изменение, т.е. взлом уже совершен. И PHP здесь уже ни при чем. В этом случае PHP будет выполняться злоумышленником точно также как и владельцем.

> ну а какже куки?
Ну и можно после авторизации разрешить работать энное время (минут 10) если нет обращение дольше "10 минут" или происходит обращение с другого ip чем тот что был последнее обращение то просить заново авторизацию
А вот сейчас Вы спрашиваете: "Как предотвратить взлом"? Этот вопрос, по своей сути, кардинально отличается от первого вопроса.
Ведь, если злоумышленник может изменять скрипты, то он просто выкинет из их кода все проверки на безопасность и все… И даже это ему не нужно делать. Он может написать так.

<?   include "../config.php";   $query=" DROP DATABASE forum";   mysql_query($query); ?>

Ведь cookie, ip-адреса – все это нужно когда злоумышленник еще по "ту сторону" барьера, а когда он уже вошел в систему – это здесь ни при чем.

Вот что я имел ввиду :

Защита include-модулей от несанкционированного доступа 19.09.2004 13:16

Дмитрий Попов
http://xpoint.ru/
Когда Вы пишите простенькую гостевую книгу, или счетчик, прибавляющий 1, к предыдущему значению, Вы, как правило, используете один-два файла не связанные друг с другом. Но однажды возникает необходимость разделять программу на несколько частей, причем одна часть вызывается другой.
Пример: делается форум-сервер, вроде www.xpoint.ru. Если Вы заметили, там скрипту forum.cgi присваивается очень много действий: от просмотра сообщений, до отправки личных сообщений. В таких ситуациях используются различные скрипты, каждый из которых отвечает за свое действие. А главный скрипт, в зависимости от действия вызывает тот или иной модуль при помощи конструкции include (или recure).
Но такие файлы не должны вызываться самостоятельно, а только из главного скрипта. Вот здесь мы и покажем три основных способа защиты их от запуска.

Каталог выше корня сайта
Самый простой способ - просто положить скрипты выше каталога www. Т.е. допустим, у Вас выделено место в каталоге /home/youhost.host/htdocs/. Каталог htdocs здесь является корнем сайта (не путать с корнем сервера). Тогда положите ваши скрипты в каталог /home/yourhost.host/ . И все! Из браузера Ваши скрипты будет не возможно увидеть.

Использование константы
Опять же несложный способ - использование функции define(). Просто напишите в главном файле (который вызывает модули) такую строчку (например):

define("INDEX", "yes");
А в первой строке (по крайней мере до того как начнется чего-то важное) напишите следующую строку:

if(!defined("INDEX")) die("Вы не имеете права на работу с этим файлом");
Все! Теперь при любой попытке запустить такой файл напрямую будет выводиться надпись "Вы не имеете права на работу с этим файлом", а сам скрипт выполняться не будет.

Как это работает? Функция define создает константу INDEX. Далее выражение if при помощи другой функции Defined проверяет наличие предопределенной константы, и в случае если константа неопределенна, выводит сообщение об ошибке и прерывает выполнение скрипта.

Использование .htaccess
Здесь есть очень много различных способов защиты всех внешних запусков. Суть у них одна. Создайте в папке с такими файлами-модулями файл .htaccess и пропишите:

<Files ~ "*.*">
Order allow,deny
Deny from all
</Files>
Все. Ни кто с наружи эти файлы запустить не сможет.

Можете написать примерно такую строчку:

<Files ~ "\^_">
Order allow,deny
Deny from all
</Files>
И называть все файлы-модули начиная с _ (_emter.php; _admin.php и т.п.).

Вообще с .htaccess можно сделать очень многое, и здесь я рекомендую обратиться к литературе по Apache.

Источник: http://xpoint.ru/articles/

Хорошая статья.
Тогда vы не поняли друг друга.
Ведь в этой статье подразумевается защита от несанкционированного запуска скриптов. Доступа к коду скриптов, а тем более к их изменению злоумышленник не имеет. Он еще не взломал сайт. Это упреждающие меры.

А возможен же частичный взлом?
Т.е. получить доступ только к "каталогу /home/youhost.host/htdocs/"
Или уж взломают так уж все? Т.е. получат доступ ко всем папкам?

>А возможен же частичный взлом?
Возможно, в принципе, все.
Но если уж хакеры смогут сами писать php-скрипты на сайте! То тут уж ничего не спасет :(

Если попадут в /home/youhost.host/htdocs/, то поднятся на один уровень выше труда уже не составит - если человек получает доступ к выполненению скриптов он найдёт файлы с паролями и к базе данных и к админу сайта, а так как зачастую они могут совпадать с паролями на FTP и SSH - последствия очень плачевны... Слабым утешением может служить, что целью профессионала часто я вляется не сам сайт, а ресурсы сервера - сайт и учётная запись пользователя лишь промежуточное звено, чтобы получить полный контроль над сервером и используя всю его мощь атаковать что-то ещё или заставить его подбирать пароли или хранить свои файлы и т.п.