Vladson

Ошибки РНР программистов.
(Часть 1)

Fri, 07 Mar 2008 22:24:17 GMT

Фильтрация данных приходящих от пользователя.

Самая главная ошибка большинства не только начинающих но и опытных программистов, это вера в то что данные надо фильтровать.

Почему это не правда ?

От части это правда, в РНР существует такая фишка как "волшебные кавычки" (magic_quotes) изначально разработанные для повышения безопасности. На деле они не защищают никого ни от чего, так-как хакеры давно нашли способы обходить это "защиту". Разные хостинг-провайдеры по разному настраивают свои сервера, по этому в скрипте желательно это учитывать и при необходимости фильтровать строки пришедшие из вне (POST, GET, COOKIE, и.т.д.). Например так:

<?php
$text = get_magic_quotes_gpc()
	? stripslashes($_POST['text'])
	: $_POST['text'];
?>

Я специально выделил слово "строки" !!! Так как мы фильтруем не данные пользователя, мы наоборот фильтруем лишнее чтоб получить именно исходные данные.

Что делать с данными дальше ?

Вот тут-то и есть главное заблуждение. Многие новички считают что данные надо обработать с помощью htmlspecialchars, mysql_real_escape и многими другими функциями, чтоб они стали "безопасными". Это чистой воды миф !

Данные надо обрабатывать не в зависимости откуда они пришли, а в зависимости куда они уйдут ! © dark-demon.

Данные сами по себе не могут быть опасными !!!
Вот я например пишу:

format c:

странно, но сервер на котором работает эта страничка почему-то работает, однако на страничке эта строчка находятся в неизменённом виде. Есть над чем подумать.

SQL-injection.

Фильтровать данные не надо, надо просто использовать их по назначению.

Когда мы пишем запрос к базе данных:

SELECT * FROM `table`
WHERE `word`='какое-то слово';

Cамо "какое-то слово" не опасно. Опасно будет если мы оправим это "слово" в запрос ! Надо отправлять не "это слово" а то что SQL сервер примет за это слово. Можно даже так:

SELECT * FROM `table`
WHERE `word`=0x4841434b454420425920564c4144534f4e;

Данный пример упрощённый, в реальности mysql_real_escape_string справляется с этим вполне.

Отдельная история с числами в SQL запросах.

Большинство даже опытных программистов (получив число из внешних источников) рекомендуют привести его в числовой тип чтоб отфильтровать всё лишнее. Например так:

<?php
$id = (int)$_POST['id'];
?>

Почему это неправильно ?

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

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

<?php
if ( is_numeric($_POST['id']) ) {
	$id = $_POST['id'];
} else {
	// показать сообщение
	// об ошибке (например 404)
}
?>

Таким образом в запрос отправится именно то число которое в строке запроса, а не то что РНР там себе возомнил.

XSS-attack

Аналогично с XSS мы должны пихать в HTML-страничку не текст, а его представление в HTML формате, куда его предварительно надо конвертировать. Даже так (опять сугубо для прикола, на самом деле htmlspecialchars выглядит "логичнее")

&#x48;&#x41;&#x43;&#x4b;&#x45;
&#x44;&#x20;&#x42;&#x59;&#x20;
&#x56;&#x4c;&#x41;&#x44;&#x53;
&#x4f;&#x4e;

Сам текст должен остаться без изменений.

Т.е мы отправляем не изменённые данные (в запрос, на страничку, на мыло, и.т.д.) приводя в нужный формат, а не фильтруя их !!!

Спасибо за внимание

Любые комментарии и замечания можно смело сообщать мне в "личку", на форумах php.ru или XTGamers.com, я с радостью их прочитаю.


© 2007 Vladson.

Навигация.









, Qip.ru - . - Photo.Qip.ru.
: - 5ballov.Qip.ru




- Hosting.Qip.ru.