Защита сайта

[a_n_d_y]

Может будем делиться тем как максимум защитить свой сайт.
Я пока не профи в php, но в создании сайтов пользую define для защиты страниц, но на скока я слышал этого не так и много. Еще mod_rewrite конечно в помощь, но опять же гарантий нет...

Добавлено через 1 минуту
Чтоб не подумали что я ламер, скажу что register_globals=Off

 

[rootkit]

я в своей смс писал класс для ведения логов - для $_REQUEST (что вводили), для всех запросов к БД, для учета попыток зайти под админом (сейчас работаю над баном по IP и на определенное время) - в лог файл пишем IP, дату, время, сам запрос и т.д.

 

[Jeurey]

Ммм... а что есть защита? Защита от чего?

Я, как минимум, делаю следующее:
Устанавливаю разрешение на использование того либо иного массива($_REQUEST, $_POST, $_GET) в самом начале скрипта. Там же прохожу его через array_walk() с функцией mysql_real_escape_string();

Делаю детект на наличие слов, характерных для SQL-инъекций с учетом флага правомерности такой передачи запроса (по сути - локальный флаг для каждого запроса (UNION, SELECT, UPDATE, DELETE и т.д.) В случае обнаружения подобной бяки - отправление в ловушку (с записью лога действий пользователя).

Обязательная проверка на наличие конструкций a-ля "./././" если вы включаете файлы, используя данные из принимаемой строки запроса...

Да много ньюансов

 

[nopase]

Поля формы помимо SQL инъекций, очень полезно проверять на присутствие mail-инъекций (переноса строк и им подобного), если они используются потом при отправки письма (например, письмо с подтверждением регистрации) и желательно ставить капчу на такие формы.

Формы типа поиска по сайту, добавления постов скриню от HTML тегов - обороняюсь от XSS.

А к БД обращаюсь через классы, в которых есть placeholder'ы - так точно SQL инъекцию не пропустишь.

На использование eval - табу.

Еще гениальное решение, подсказанное, коллегой - резать поля по длинне. Очень сильно такой подход затрудняет процесс взлома.

Я вобще себе класс написал, который пропускает только разрешенные поля с только разрешенными данными. Это имхо удобней, чем выдумывать запрещенные. К тому же класс подвешивается на выходной поток, парсит его, находит свою форму и подставляет дефолтные (или сохраненные) значения - очень удобно. Могу поделиться, правда он сыроват.

 

[Jeurey]

Выкладывай - доработаем

 

[rootkit]

А к БД обращаюсь через классы, в которых есть placeholder'ы - так точно SQL инъекцию не пропустишь.

а можно воспользоваться Pear :: DB - сам отфильтрует, что не нужно

Я вобще себе класс написал, который пропускает только разрешенные поля с только разрешенными данными. Это имхо удобней, чем выдумывать запрещенные. К тому же класс подвешивается на выходной поток, парсит его, находит свою форму и подставляет дефолтные (или сохраненные) значения - очень удобно. Могу поделиться, правда он сыроват.

что-то типа этого?

	public static function get($array, $name, $defaultValue = null) {
		if (isset($array[$name])) return $array[$name];
		else return $defaultValue;
	}

 

[nopase]

а можно воспользоваться Pear :: DB - сам отфильтрует, что не нужно

Можно. Я лично предпочитаю PDO.

что-то типа этого?

	public static function get($array, $name, $defaultValue = null) {
		if (isset($array[$name])) return $array[$name];
		else return $defaultValue;
	}

Почти Во вложении.
Сам понимаю, качество кода оставляет желать лучшего. Принимается только конструктивная критика. И вопросы по существу. Критика Jeurey а-ля "вот эта строчка - фуфло, и эта тоже" приветствуется

Вот пример использования:

$form_dsc = array(
						'method' => 'POST',
						'name'   => 'adddoc',
						'fields' => 
								array(
									'name' => array(
										'checkers'	=>
											array(
												array('type'=>form::STRING, 'param'=>form::ALL, 'errorno'=>1),
												array('type'=>form::MINLEN,	'param'=>3, 'errorno'=>2)),
										'persist'	=> true),
									'part' => array(
										'checkers'	=>
											array(),
										'persist'	=> true),
									'description' => array(
										'checkers'	=>
											array(
												array('type'=>form::STRING, 'param'=>form::ALL, 'errorno'=>1),
												array('type'=>form::MINLEN, 'param'=>3, 'errorno'=>2)),
										'persist'	=> true, 'optional'	=> true),
									'publish' => array(
										'checkers'	=> array(),
										'persist'	=> true, 'optional'	=> true)									
								)
					);
				
				$form = new form($form_dsc);
				if(isset($_REQUEST['doAdd'])){
					
					if(!$form->isTidy())
						$res = array('result' => 'errors', 'errors' => $form->getErrors());
					else{
						$mans = new manualsList();
						$man = new manual();

						$man->name			= $form->name;
						$man->description	= $form->description;
						$man->publish		= ($form->publish ? 1 : 0);

						$mans->add($man);
					}
				}

 

[medvoodoo]

ну вы звери
если уж максимум безопасности то:
1) Отдельный обработчик запросов
2) Проверка типов в методах классов
3) mysqli
4) XML-XSLT там намного проще парсинг вывода спецсимволов происходит нежели спец средствами
5) капчи + защита от перебора

 

[Jeurey]

Медвуду, мы еще не определились с понятием "безопасность" а ты лезешь вон куда уже )))

 

[robi]

Медвуду, мы еще не определились с понятием "безопасность" а ты лезешь вон куда уже )))

В моем понимании: безопастность это невозможность выполнить произвольный код на моем сайте

по сути большенство методов "предохранения" описано выше.
Я например в миминуме привожу все числовому типу. строки пытаюсь не использовать вообще - ессесно кроме поиска. и реврайт - затрудняет взлом + оч хорошо для сео.
Хотя на мой взгляд - вопрос безопасности очень индивидуален и зависит от проекта.