| |
|
|
| | Всем привет!
Хотел обобщить и обсудить все необходимые и главное достаточные методы защиты баз, скриптов от нехороших взломщиков. Зашита средствами php
В отношении XSS
<title><?php echo strip_tags($pagename;) ?></title>
или
<title><?php echo htmlspecialchars($pagename, ENT_QUOTES); ?></title>
|
При использовании strip_tags возможен обман этой функции и лучше использвать htmlspecialchars
если атрибут alt для рисунка, то addslashes(), если url — urlencode().
В отношении sql инъекций
// Включаем код по очистке от слешей в каждый файл
function stripslashes_array($array) {
return is_array($array) ?
array_map('stripslashes_array', $array) : stripslashes($array);
}
if (get_magic_quotes_gpc()) {
$_GET = stripslashes_array($_GET);
$_POST = stripslashes_array($_POST);
$_COOKIE = stripslashes_array($_COOKIE);
}
// Конец кода по очистке
// А затем в каждом запросе экранируем все входящие переменные
$result=("select name from table where pole1= '".intval($_GET'[pole1'])."' AND pole2='".mysql_real_escape_string($decription)."' AND pole3 = '$_GET['pole3' ]";
// $pole1 (тип число) берется из GET.
// $pole2 берется из базы (тип текст). рассчитывать на защиту при добавлении информации в базу не стоит в ряде случаев
// $pole3 (тип текст) текстовое берется из GET
|
| |
| |
|
|
| |
|
|
| |
для: Импекс
(21.06.2010 в 11:38)
| | | необходимым и вполне достаточным условием защиты программы от взломщика является написание этой программы без ошибок.
Это совершенно достаточный, и вместе с тем - абсолютно необходимый фактор.
Всё остальное - суета, чушь, ересь. | |
| |
|
|
| |
|
|
| |
для: Trianon
(21.06.2010 в 11:51)
| | | )) а по подробней. Мы собственно о грамотности речь и ведем))
"написание этой программы без ошибок. " Забыл уточнить, что обсуждение является концептуальным, на уровне функций и логики. | |
| |
|
|
| |
|
|
| |
для: Импекс
(21.06.2010 в 11:52)
| | | О какой грамотности?
вот логика как раз и должна быть реализована без ошибок.
Концепция же "программа без ошибок" ,очевидно, допускает обратную.
Что в общем-то нонсенс. | |
| |
|
|
| |
|
|
| |
для: Trianon
(21.06.2010 в 12:01)
| | | ... | |
| |
|
|
| |
|
|
| |
для: Trianon
(21.06.2010 в 12:01)
| | | тогда получается, что функцию mysql_real_escape_string следует использовать в любом случае, и в том, когда установлены магические кавычки, и не установлены.
Когда кавычки установлены, и местная локаль одно байтовая, то просто будут лишние слеши и при SELECT это не важно, результат выборки просто не определен. А если локаль многобайтовая, то защита магическими кавычками со строны сервера не справяться, зато подстрахует функция mysql_real_escape_string
Рассуждения верны? | |
| |
|
|
| |
|
|
| |
для: Импекс
(21.06.2010 в 16:38)
| | | Нет, если в базе будут экранирующие слэшы - это искажение исходных данных.
mysql_real_escape_string следует использовать только при отключеных магических кавычках.
Чтобы не заморачиваться (и не грузить код лишними проверками), я бы рекомендовал отключать их в файле .htaccess.
Другой вопрос, что не везде такое прокатит, и тогда следует использовать следующую конструкцию:
<?php
function s_slash($value)
{
if (is_array($value))
$value = array_map('s_slash', $value);
elseif ( !empty($value) && is_string($value) )
$value = stripslashes($value);
return trim($value);
}
if (get_magic_quotes_gpc()) {
$_GET = !empty($_GET) ? s_slash($_GET) : NULL;
$_POST = !empty($_POST) ? s_slash($_POST) : NULL;
$_COOKIE = !empty($_COOKIE) ? s_slash($_COOKIE) : NULL;
$_REQUEST = !empty($_REQUEST) ? s_slash($_REQUEST) : NULL;
}
|
| |
| |
|
|
| |
|
|
| |
для: neadekvat
(21.06.2010 в 16:45)
| | | А чем плохи магические кавычки от сервера -. в кодировках. Главное что функцию mysql_real_escape_string кодировкой не обманеш, а кавычки, получается можно. тогда что остается с включенными кавычками,: или удалять слеши прогонять инфу mysql_real_escape_string или устанавливать локаль для данного скрипта. Какую я не знаю пока) | |
| |
|
|
