akral Jul 10 2007 at 02:07

Основы безопасности PHP

5 min

28K

PHP*

+42

185

Comments 185

Mclaud Jul 10 2007 at 03:26

Спасибо за статью! Побольше таких=)

gribozavr Jul 10 2007 at 03:30

Отличная статья! Мне очень понравился стиль изложения: что написал программист как это можно сломать как защититься.

Но мне всё-таки кажется, что таким важным вещам лучше учить сразу. Если человек уже год пишет рабочие сайты и ещё не разу не слышал об этих мерах безопасности, у него есть хороший повод пересмотреть свой код :)

Подсказка авторам книг и другой учебной литературы: если рассказываете про MySQL, то одним из пунктов обязательно нужно рассказать про SQL injection.

gribozavr Jul 10 2007 at 03:37

> Но мне всё-таки кажется, что таким важным вещам лучше учить сразу.
Это я про то, что программиста с 12-18 месяцев стажа уже нельзя назвать начинающим.

akral Jul 10 2007 at 12:31

С утра посмотрел и тоже немножко усомнился в своей адекватности. %)
Исправил.

vitaminych Jul 10 2007 at 04:45

Явно преувеличен стаж, безопасность это следующий урок любого программиста, который выучил как сделать "Hello World!" тремя и более способам. Приведенные проблемы относятся к начальному уровню, то есть для новичков.

Для валидации данных полезно использовать такие функции как intval, ctype_*. Если набор возможных значений заведомо известен, то in_array тоже сойдет. В куки вообще лучше хранить только хэш сессии, а всё остальное на сервере или в БД. Динамически подключаемые файлы должны проверяться на местонахождение, ограничивать папку для возможных файлов, например. А лучше, конечно, иметь список допустимых файлов.

jiexaspb Jul 10 2007 at 05:05

По поводу стажа согласен. Да и вообще, таких статей в интернете куча. И во всех написано тоже самое. Надоели эти статьи для новичков, даёшь что-нибудь интересно для Pro.
> куки вообще лучше хранить только хэш сессии
не согласен, сессии тоже не самый лучший вариант, так как при нетрудной атаки, можно создать такое количество сессий, что сервак не выдержит... Подробнее в гугле.

А куки я считаю нормальным местом для хранения данных. А то, что у юзера могут вытащить куки трояном, то это его вина, а не программиста.

gribozavr Jul 10 2007 at 05:47

Троян не единственный вариант. Ещё есть XSS. А есть вообще такие данные (например, сумма заказа, или уровень прав доступа) которые нельзя хранить в кукисах по соображениям безопасности.

jiexaspb Jul 10 2007 at 14:57

XSS может быть только по вине программиста, если программист внимательный, то он избежит данной ошибки.

UFO just landed and posted this here

akral Jul 10 2007 at 12:28

Простите, не силён. :)

akral Jul 10 2007 at 12:31

А куки я считаю нормальным местом для хранения данных. А то, что у юзера могут вытащить куки трояном, то это его вина, а не программиста.

Sniffing, XSS, дополнительный траффик, отключенные куки.

И о юзерах надо заботиться, если они — ваши клиенты. Ваше заявление из разряда «плевал я на поддержку IE, нефиг пользоваться левым браузером».

jiexaspb Jul 10 2007 at 14:51

то есть вы хотите сказать, что в сессиях лучше и безопаснее хранить к примеру логин и пароль, чем в куках?

simple Jul 10 2007 at 14:52

Зачем хранить логин и пароль? Храните ID пользователя.
На крайняк - храните в зашифрованном виде.

jiexaspb Jul 10 2007 at 15:20

> Зачем хранить логин и пароль?
затем, чтобы человек после авторизации мог не вводить свой пароль пару дней. К примеру вот прям тут(на етом сайте) в куках хранится hha - это ID юзера, и hhb - пароль в зашифрованом(md5) виде. Если я не ошибаюсь конечно.

> На крайняк - храните в зашифрованном виде.
А если так, то какую вы здесь видеть дырку?
<?
// Для наглядности
$login = "12345"; // Логин
$pass = "mypass"; // Пароль
$ip = $_SERVER['REMOTE_ADDR']; // IP
$hash = md5($pass.$ip); // Получаем зашифрованный пароль и айпи в одну строку. То есть теперь у нас пароль привязан к IP. И если его украдут у пользователя, то на другой машине он будет безполезен.

// Сохраняем инфу в куки
setcookie("login", $login, ...
setcookie("pass", $hash,...
?>

На странице проверки авторизации:

if(isset($_COOKIE['login']) and isset($_COOKIE['pass']))
{
// Запрос, который вытащит пароль юзeра с ID $_COOKIE['login']
mysql_query....

// Представим, что в переменной $user['pass'] лежит пароль вытащенный сейчас из БД
if(md5($user['pass'].$_SERVER['REMOTE_ADDR']) === $_COOKIE['pass'])
{
// юзер авторизован
}
else
{
// не авторизован
}
?>

akral Jul 10 2007 at 15:24

В вашем примере есть дыра.
Во первых, могут (и наиболее вероятно) украсть из локальной подсетки с тем же IP.

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

А зачем вам хранить пароль?
if (isset($_SESSION['userid'])) $db->get('... WHERE `id` = '.$_SESSION['userid']));

Зачем проверка на пароль вообще?

jiexaspb Jul 10 2007 at 15:29

Эмм, как зачем. :D Вы когда где-нибудь авторизируетесь, вы что только логин вводите?

> Во вторых выдавая хеш пользователю, вы раскрываете алгоритм шифровки, что не хорошо.
Я не спорю, можно создавать рандомный хеш при авторизации, сохранять его в БД и ложить в куке и потом просто сверять два хеша.

akral Jul 10 2007 at 15:32

Я не спорю, можно создавать рандомный хеш при авторизации, сохранять его в БД и ложить в куке и потом просто сверять два хеша.

Так это и есть сессии!
session_register это и делает без лишних телодвижений.

Идентификатор сессии и есть авторизация.

WoZ May 22 2008 at 15:32

ну у сессии ограниченное время жизни. как я понимаю, потому куки и нужны

akral May 22 2008 at 15:59

Настройка длины сессии.

Так что, как я понимаю, вы ошибаетесь.

simple Jul 10 2007 at 15:35

У меня отключены куки. Что мне делать? =)

jiexaspb Jul 10 2007 at 15:39

у меня нет интернета, что мне делать?
/* люди до сих пор размышляют, что делать с теми у кого отключены куки, но таких уже не осталось */

nini Jul 10 2007 at 17:39

ну как же не осталось - у нас портал 4.2К пользователей, так я как-то системку для опросов и тестов написал, с использованием куки, так потом выяснилось, что у многих они отключены, пришлось потом исправлять.

minibikini Jul 10 2007 at 18:58

вернутся в 90е ;-)

Apostol Jul 10 2007 at 17:51

Даже не ID пользователя можно хранить в куках и зашифрованный пароль, а ID авторизации (не сессии) и md5 какой-то случайной строки.

simple Jul 10 2007 at 18:14

Накой вообще что-то хранить в куках, если есть сессии?
Максимум что я храню в куках - дату последнего визита или на других проектах - уникальный ID посетителя (чтобы статистику обсчитывать более точно).

Apostol Jul 10 2007 at 18:22

В куках хранить инфу только для автоматического захода через N-ное количество времени. У вас же сессии 2 недели не живут? ;)

simple Jul 10 2007 at 18:37

Этого ещё не хватало, чтоб они жили по 2 недели ))

korchasa Jul 10 2007 at 18:20

Т.н. сеансовый ключ. Чем вам не нравится PHPSESSID, при условии VDS или приватного сервера, конечно?

Apostol Jul 10 2007 at 18:38

Не понял, при чём здесь выделенные и приватные сервера? Сессиями пользуюсь во всю. Куками гораздо реже. Но именно для автоматического захода спустя большой промежуток времени, предпочитаю хранение инфы в куках.

korchasa Jul 10 2007 at 19:04

На шаред-хостинге легко украсть содержимое сессии, украв куку.

Как вы передаете сессионный ключ между страницами?

Apostol Jul 10 2007 at 22:38

В куках. Ограничиваю время жизни сессии. Да и у меня собственный сервер.

simple Jul 10 2007 at 21:49

папка tmp имеет права доступа 0777 и её легко может прочитать любой скрипт, находящийся на том же хостинге. Дальше рассказывать?

Apostol Jul 10 2007 at 22:36

Всё, дальше не надо. :)

simple Jul 10 2007 at 18:38

Много ли народу берёт под свои проекты VDS?

korchasa Jul 10 2007 at 19:08

"20 долларов то не лишние..." :)
Мне проще отдать $20, зная, что это будет мой (почти) сервер, в котором я сам буду ставить Apache(Nginx), PHP, MySQL(SQLite,PostgreSQL) и никакой супер-админ не поставит какую-нибудь хрень.

За всех, конечно, сказать не могу.

simple Jul 10 2007 at 21:48

Во-во. Мне тоже проще, но другим - нет )

akral Jul 10 2007 at 15:13

Да.

Но пароль-то зачем хранить в любом случае?

Если очень нужно (зачем?), то храните хеш. По сути данные в сессии хранятся в файловой системе так же, как БД, так что никакой опастности, если только не будет перехвачен session ID, но для этого можно добавить привязку к IP, User-Agent, ...

jiexaspb Jul 10 2007 at 15:23

А вам не кажется, что чтобы перехватить session ID нужно одинаково столько же времени, сколько и на кражу кук? Ну разве что, вы будете передавать сессион ид в УРЛ... но это сейчас не в моде + юзер может сам случайно передать свой ID сессии злоумышлинику...

akral Jul 10 2007 at 15:25

Да, но украв session ID, злоумышленник будет иметь просто тупой хеш, а украв пароль из куков, или даже его хеш, злоумшленник будеть иметь более важную информацию :)

simple Jul 10 2007 at 15:36

Если плюшки-печенюшки выключены, то session id всегда передаётся по url.
Разберитесь с механизмом работы сессий.

jiexaspb Jul 10 2007 at 15:40

Кто вам сказал, что я не знаю об этом?

simple Jul 10 2007 at 16:36

> Ну разве что, вы будете передавать сессион ид в УРЛ... но это сейчас не в моде

Вот тут написано, что Вы этого не знаете. Модно/немодно - это размышления не программиста, а блондинки в супермаркете.

jiexaspb Jul 10 2007 at 16:53

А я не программист. Я кодер.

simple Jul 10 2007 at 17:14

Тогда всё ясно

nini Jul 10 2007 at 17:41

где можно почитать про это =) ?

simple Jul 10 2007 at 23:27

Про что?

nini Jul 10 2007 at 23:36

про программистов и кодеров

simple Jul 11 2007 at 00:21

Поищите в Гугле. Не помню просто на каком сайте это пробегало.

jiexaspb Jul 10 2007 at 17:01

+ по урл передовать не безопасно
+ разве тока блондинки носят модный шмот? а да точно, я забыл, программисты строго классику:D

simple Jul 10 2007 at 17:16

1. Согласен.
2. Ошибаетесь =) Не поверите, иногда программисты занимаются не только программированием. Я вот например ещё резидент в одном крупном клубе )

Короче, мы уже начали с Вами придираться к образным фразам. Давайте оставим это занятие для других...

jiexaspb Jul 10 2007 at 17:24

=) ок

jiexaspb Jul 10 2007 at 15:26

В итоге мы получаем, что хранение пароля и логина в сессиях и куках одинаково опасно, только сессии ещё могут и положить сервак, если грамотно DDOSнуть и тогда их кол-во перерастет за несколько сотен тысяч..

akral Jul 10 2007 at 15:27

В итоге чего? О_о

Говорю же, нельзя давать даже хеш пароля! Взламывается даже md5!

jiexaspb Jul 10 2007 at 15:33

Здесь я согласен, возможен вариант как я описал выше "10 июля 2007 15:29 "

akral Jul 10 2007 at 15:35

А чем он отличается от мною с самого начала предлагаемых сессий?

jiexaspb Jul 10 2007 at 15:41

тем что сессиями можно уложить сервер, читайте ниже "10 июля 2007 15:37"

bersz Jul 12 2007 at 15:31

Есть ли взлом md5 без банального брутфорса?
Гуглил-гуглил, не нашел ничего интересного :(

akral Jul 10 2007 at 15:28

1 000 000 сессий по 200 байт это 200 Mb. Согласен, никакой сервак не выдержит. :))

jiexaspb Jul 10 2007 at 15:33

Проконсультируйтесь у сис.админов по этому поводу.

jiexaspb Jul 10 2007 at 15:37

Сессии создаются в ТМП. Время жизни 30 минут.

Каждый раз при создании сессии проверяется уникальность сгенерированного кода. 5000 файлов практически уводят сервер в даун
Уникальность проверяется чтением папки ТМП, сосбственно чтение и убивает сервер

DEL Jul 10 2007 at 17:23

Похоже на страшную сказку по запугиванию юнцов-кодеров. Это абсолютная чушь. Да и кстати вы можете сами указывать session_name.

jiexaspb Jul 10 2007 at 18:46

Нет не сказка, об этом мне рассказывал человек Tibor - который когда-то создал самый быстрый и безопасный клон нюки - xNuke. Также он давно занимается создание и поддержкой проектов, с очень большой посещаемостью.
> Это абсолютная чушь
Аргументы?

medwed Jul 10 2007 at 09:57

Мне как раз очень нужно это все, спасибо. Только вот появилась надежда на продолжение. =)

delightmanua Jul 10 2007 at 10:40

есть очень хорошее правило - никогда не доверять тому, что отправил пользователь через браузер. Абсолютно всё нуждается в проверке.

Есть два относительно надёжных места хранения инфромации - это сессии и БД

gro Jul 10 2007 at 10:42

Слишком сумбурно и непоследовательно.
Пишется "не делайте так", "потенциальная опастность", а объяснений "почему" нет.

В пятой версии появилась константа E_STRICT, показывающая строгие замечания по поводу кода. Разумеется, их желательно видеть, но они не входят в E_ALL, потому будем использовать числовое значение error_reporting(8191)

Только что константы были, теперь какое-то непонятное число. Почему не
error_reporting(E_ALL | E_STRICT)?

akral Jul 10 2007 at 12:28

И правда, непонятно. Я редактировал после, потому получилось бессвязно.

PHP 4 не знает E_STRICT и будет ругаться. А используя числовое значение, мы уверены в корректной работе.

Borka Jul 10 2007 at 15:54

а кто мешает проверить на наличие E_STRICT и при его отсутствии создать его с нужным значением?

ergil Jul 10 2007 at 11:00

поправьте ошибку в заголовке.
"Безопасности", а не "Безопастности".

zerkms Jul 10 2007 at 11:27

лучше не нужно, это сразу очень сильно характеризует адекватность статьи...

akral Jul 10 2007 at 12:27

Спасибо ;)

ergil Jul 10 2007 at 12:28

не за что :)

zerkms Jul 10 2007 at 11:27

"Поэтому их необходимо перехватывать и упорядычивать."
ошибки не надо перехватывать, их надо исправлять

"Создаём функцию для фильтрации (mysql_real_escape_string - длинно)"
переименование функций - зло, пользуйся редакторами с автокомплитом

"Не проверяйте на наличие плохих символов. Проверяйте на отсутствие нехороших. Вместо"
разницы абсолютно никакой, всё зависит от ситуации

"Данный материал для начинающих программистов (ИМО, до 12-18 месяцев стажа)."
добрая половина материала вообще не рекомендуется к прочтению, как растлевающая умы молодым и неокрепшим в профессиональном смысле разработчикам

DEL Jul 10 2007 at 12:18

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

akral Jul 10 2007 at 12:26

добрая половина материала вообще не рекомендуется к прочтению, как растлевающая умы молодым и неокрепшим в профессиональном смысле разработчикам

/me морг-морг глазами
В смысле?

zerkms Jul 10 2007 at 12:32

в смысле - статью новичкам лучше не читать, им будет только хуже...
ты это поймёшь, чуть попозже...

akral Jul 10 2007 at 12:36

Простите, о Великий Гуру!

zerkms Jul 10 2007 at 12:46

и не надо язвить, к критике надо относиться с пониманием

akral Jul 10 2007 at 12:51

К критике в стиле «подрастёшь — поймешь» и обращению на «ты», думаю, можно относиться и с иронией. ;)

zerkms Jul 10 2007 at 12:54

эм... тебя так задевает обращение на вы?
хм...
ну если ты действительно не принял (не понял) 3 моих замечания, разве это не повод рассуждать о том - что ты поймёшь их позже (см. дорастёшь) не?

zerkms Jul 10 2007 at 12:54

*на ты

akral Jul 10 2007 at 13:04

Просто, как я видел раньше, на хабре принято обращаться на «вы». Кроме того, в контексте «подрастёшь — поймёшь», переход на ты имеет дополнительный эмоциональный окрас. А в принципе мне до лампочки, так что можете общаться и на ты :)

Конструктивно рассмотрим ваши замечания:

"Поэтому их необходимо перехватывать и упорядычивать."
ошибки не надо перехватывать, их надо исправлять

То-есть ваш код такой идеальный и 100-процентно хороший, что никогда и нету таких ситуаций, когда он вывалится с ошибкой? Например перегруз БД, когда она плюётся «Невозможно выполнить»?

"Создаём функцию для фильтрации (mysql_real_escape_string - длинно)"
переименование функций - зло, пользуйся редакторами с автокомплитом

Согласен, но я имел ввиду немного другое, и сейчас дополнил статью.
Фильтрация данных может измениться, может произойти переход на другую БД, а менять «myqsl_» на «foosql_» во всём коде даже с автозаменой нехорошо.

"Не проверяйте на наличие плохих символов. Проверяйте на отсутствие нехороших. Вместо"
разницы абсолютно никакой, всё зависит от ситуации

Разница есть. Разрешая только a-z0-9_, мы уверены, что эти символы ничего плохого не сделают. Запрещая '"`\, мы можем забыть запретить нулл-байт или другие контрольные символы.

"Данный материал для начинающих программистов (ИМО, до 12-18 месяцев стажа)."
добрая половина материала вообще не рекомендуется к прочтению, как растлевающая умы молодым и неокрепшим в профессиональном смысле разработчикам

Это неконструктивное замечание. =)

zerkms Jul 10 2007 at 13:20

"То-есть ваш код такой идеальный и 100-процентно хороший, что никогда и нету таких ситуаций, когда он вывалится с ошибкой? Например перегруз БД, когда она плюётся «Невозможно выполнить»?"
я не говорил про Ваш код, я не говорил про свой код. Я лишь откомментировал Ваш совет новичкам
"Поэтому их необходимо перехватывать и упорядочивать."
После этой фразы начинающие программисты будут считать, что перехват и умалчивание ошибок - нормальная практика, вместо того, что бы писать хороший код

"Фильтрация данных может измениться, может произойти переход на другую БД, а менять «myqsl_» на «foosql_» во всём коде даже с автозаменой нехорошо."
экранирование переменных - меньшее что Вас будет заботить при переходе на другую СУБД. Даже при использовании DBAL, так или иначе диалект sql будет иным

"Разница есть. Разрешая только a-z0-9_, мы уверены, что эти символы ничего плохого не сделают."
проверяя preg_match('/^[a-z]+$/', $var); или preg_match('/[^a-z]/', $var); мы в варианте 1 проверяем на вхождение в дозволенный интервал, в варианте 2 - на вхождение в недозволенный. Оперируя вашей фразой - вариант 1: проверка на отсутствие плохих символов, 2: проверка на наличие плохих
т.е. как раз тот вариант - когда разницы никакой

"Это неконструктивное замечание. =)"
хм.. как бы то ни было - я бы не посоветовал её читать никому из начинающих. в этом плане гораздо полезнее тот же phpfaq.ru

korchasa Jul 10 2007 at 15:08

>>"Поэтому их необходимо перехватывать и упорядочивать."
>После этой фразы начинающие программисты будут считать, что перехват и умалчивание ошибок - нормальная >практика, вместо того, что бы писать хороший код
До появления исключений, многие эмулировали их через trigger_error, и это нормально. Излишние проверки часто замусоривают систему, особенно работе на разных слоях, приходится дублировать проверки везде. Перехват ошибок нормальная практика и как-то странно с этим спорить. Идеального кода не бывает.

Насчет проверки данных. Различают два понятия: валидация и фильтрация. То, что описано в статье именно валидация, т.е. проверка по белому списку. С другой стороны фильтрацию тоже никто не отменял. У них логически разные предназначения
Пример: пользователь пишет комментарий (e-mail и текст). E-mail нужно проверять по

akral Jul 10 2007 at 15:20

Обрезалося! Добавьте, пожалуйста!

Предпологаю, что вы хотели сказать, что email надо вылидировать, а текст фильтровать, и будете правы.

korchasa Jul 10 2007 at 15:35

Да именно это и хотел. Не дополните ли статью на тему фильтрации? А еще бы хорошо заменить все таки авторизацию, на аутентификацию, тоже разные вещи все таки.

akral Jul 10 2007 at 15:44

Поправил.
И разницу между авторизацией и аутентификацией подметил. :)

UFO just landed and posted this here

absoluteplush Jul 10 2007 at 14:14

"переименование функций - зло, пользуйся редакторами с автокомплитом"
а повышать читаемость кода тоже зло? или делать обвертки с возможностью дополнить их в будущем?

zerkms Jul 10 2007 at 14:18

стороннему программисту, который будет читать код - проще понять нативные функции, чем никому не нужные врапперы. так что читабельность тут только страдает.

akral Jul 10 2007 at 14:51

К примеру, if (is_email($data)) гораздо читабельнее, чем if (preg_match('/QLNqufQPPIDHQWODn,amnDWALjdnqdQLOWHFQLO/',$data)) =)

zerkms Jul 10 2007 at 15:02

не юлите
я говорил о конкретном частном создании алиаса на функцию, а не об инкапсуляции сложной логики

TonyClifton Jul 10 2007 at 11:43

Да, очень полезно. Спасибо.

akirsanov Jul 10 2007 at 11:55

Не проверяйте на наличие плохих символов. Проверяйте на отсутствие
нехороших.

- явно имелось ввиду:
Не проверяйте на наличие плохих символов. Проверяйте на отсутствие
хороших.

DEL Jul 10 2007 at 12:17

Тоже внесу несколько своих замечаний:
1. E_STRICT - вещь замечательная хотябы потому, что выдает замечания по depricated (устаревшим) функциям (начинающему программисту пригодится).
2. Можно ловить ошибки и errorHandler, однако куда красивее display_error в нет, а писать в логи, естественно после запуска. Иначе пользователь у вас будет видеть всегда "Мол, «простите, облажались маленько»...", а вы будуте часами искать ошибки.
3. Про register_globals, ну не знаю кто ее еще применяет...
4. По поводу слешей: отключайте меджик слеши вполучаемых переменых и используйте mysql_real_escape_string, зачем огород городить и придумывать велосипед...
5. И инклудах используйте define, так советует PHP.
6. Прор куки согласен, храните в сессии.

akral Jul 10 2007 at 12:25

1. Согласен. Я так и написал. :)
2. На мой взгляд, позволять пользователю видеть пустую страницу вместо извинения — очень плохо. Он будет неудомевать, пробовать заново. А в логи моя функция так и так пишет. Вы бы в начале прочитали её ещё раз. ;)
4. Начинающие программисты вряд ли имеют доступ к глобальному конфигу и знания, как выключить magic_quotes. Очень часто вы находитесь на shared сервере, а set_ini тут не работает, поскольку к моменту выполнения set_ini magic_quotes уже поработали.
5. Не могли бы вы перефразировать? Никак не пойму. :(

DEL Jul 10 2007 at 12:36

2. Естественно выводить что-то, я разве против. Где у вас там запись в логи?
4. Сложно найти хостинг где не работает .htaccess и в нем нельзя прописать magic_quotes в оф.
5. Попробую объяснить:

<?php
$x = '/usr/local/php/includes';
include($x.'include.php');
?>

Unsafe use of variable in call include()/require() (line 4)

akral Jul 10 2007 at 12:42

2. "// Запись в БД или отсылка по почте вебмастеру."
4. Мммм... Согласен.
5. А что делать, если я динамически выбираю модуль? Грубо говоря из $_GET?

DEL Jul 10 2007 at 12:46

2. log_errors проще, а еще представьте ту ситуацию когда у вас отсылка по почте или запись в БД тоже будет выдавать ошибку, что тогда:)
5. Проверяйте, конечно, хорошенько что там инклудите:)

akral Jul 10 2007 at 12:47

2. Хорошая шутка. :))

akral Jul 10 2007 at 12:48

В стиле «давай сделаем два ящика — на рамблере и на mail.ru, сделаем переадресацию с одного на другой и обратно и отправим одно письмо!» :)

UFO just landed and posted this here

DEL Jul 10 2007 at 12:47

Кстати я из БД вытаскиваю.

akral Jul 10 2007 at 12:49

Я тоже. ._.

flint Jul 11 2007 at 00:31

4. Начинающие программисты вряд ли имеют доступ к глобальному конфигу и знания, как выключить magic_quotes. Очень часто вы находитесь на shared сервере, а set_ini тут не работает, поскольку к моменту выполнения set_ini magic_quotes уже поработали.

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

set_magic_quotes_runtime(0);



function strips(&$el)

    {

      if (is_array($el))

            foreach($el as $k=>$v) strips($el[$k]);

        else

            $el = stripslashes($el);

    }

if (get_magic_quotes_gpc())

    {

      sk_ga_strips($_GET);

      sk_ga_strips($_POST);

      sk_ga_strips($_COOKIE);

      sk_ga_strips($_REQUEST);

      if (isset($_SERVER['PHP_AUTH_USER'])) sk_ga_strips($_SERVER['PHP_AUTH_USER']);

      if (isset($_SERVER['PHP_AUTH_PW']))   sk_ga_strips($_SERVER['PHP_AUTH_PW']);

    }

Вставить перед исполнением каждого php-скрипта. Лучше, в отдельный файл это запихнуть и каждый раз подключать.

Недостатки, конечно, налицо, но если сайт не такой и посещаемый, то вполне приемлимое решение.

akral Jul 11 2007 at 01:41

Ну да... Вот он в статье и приведён. :)

array_map > foreach

UFO just landed and posted this here

akral Jul 10 2007 at 12:45

Я согласен, что такой информации много. Но её должно быть много. Потому начинающие как раз и не знают, что искать. И надо, чтобы они попадали на такую информацию.

И мне достаточно одного единственного "спасибо" в топике, чтобы понять, что не зря я это написал, что бы там профи не рассказывали. :)
Карма, в отличие от этого, мне до лампочки. ;)

UFO just landed and posted this here

nini Jul 10 2007 at 17:52

ого, нехило! и оно растет! уже 946, прям как в гугле

akral Jul 10 2007 at 18:25

Хорошо говорите, респект.

Кстати, за линк спасибо. :)

meniam Jul 10 2007 at 12:39

> Во первых, функция error_reporting позволяет нам решить, какие ошибки мы хотим видеть.
Я хочу видеть все, но что бы пользователь не видел никаких, поэтому использую:
http://ru2.php.net/manual/ru/ref.errorfu…

leemuar Jul 10 2007 at 12:54

Статья неплохая, однако: было б лучше, если Вы обосновывали некоторые положения простыми примерами, так сказать "на слониках". Например, касательно register_globals: то что это плохо Вы сказали, а _реального примера_ того, как это могут использовать для взлома нет.

MTonly Jul 10 2007 at 13:05

упорядычивать → упорядочивать

akral Jul 10 2007 at 13:07

Спасибо.

/me стыдно.

antonrr Jul 10 2007 at 13:18

Отличная статья. Я даже не начинающий, так, любитель-самоучка, мне было интересено. :)

caston Jul 10 2007 at 14:00

Хорошая статья. Рекомендовал бы начинающим.)

Nicholass Jul 10 2007 at 14:10

Классная статья. Сейчас мне нужно приступать к разработке и я хорошо освежил безопасность в голове. Спасибо.

zerkms Jul 10 2007 at 14:19

эту информацию надо знать, а не помнить ;)

Accko Jul 10 2007 at 14:24

автору большое спасибо!

simple Jul 10 2007 at 14:47

Автору - респект. Когда я начинал заниматься PHP, то таких мануалов не было и приходилось всему учиться на своих ошибках.

Кстати, новичкам ещё будет полезен вот этот сайт: http://www.omsk777.ru/all.php?act=web

alkeeper Jul 10 2007 at 15:27

Новичкам больше будет полезен ман и phpclub

akral Jul 10 2007 at 15:30

Я тоже люблю сказать RTFM. Только я так отвечаю на вопросы. В ман можно лезть, когда знаешь, за чем лезешь. Просто так перечитывают ман никак не начинающие.

alkeeper Jul 10 2007 at 16:01

1. Изучая предмет не системно, а по принципу how-to, больших результатов не достигнешь.
2. RTFM это одно, а профессиональное комьюнити - несколько иное.
3. Есть поиск по этому комьюнити, выдающий решения по большинству вопросов, в том числе и по безопасности.
4. По PHP очень удобный ман.
5. Приведеный в пример сайт - потуги таких же "профессионалов", которые, не научившись языку, раздают советы направо и налево.
6. "Просто так" ман никто не перечитывает.

akral Jul 10 2007 at 18:22

Я просто так перечитываю ман. ._.

Novikov Jul 11 2007 at 16:23

Если у меня кто-то из работников отвечает клиенту RTFM, то получает наряд вне очереди :))

alkeeper Jul 12 2007 at 07:31

Мы сейчас о клиентах или о программистах говорим? Я программист и смело посылаю всех, включая директора, к RTFM. Но дело не в этом! Я никого не посылал читать ман, если человек является ах***ным программистом, тогда конечно... зачем ему читать ман, он же и так все знает.
А если серьезно... Меня бесят эти ах***но профессиональные сайты, на которых опубликованы статьи, раскрывающие тему "2*2=4", преподносящие предмет обсуждения как бином Ньютона или решение теоремы Ферма, блин, пиз*ец, сенсация, оказывается magic_quotes_gpc надо вырубать.... А кто-нибудь здесь знает вообще, что такое GPC, и как это расшифровывается?
Нет, разумеется, давайте каждому (здесь есть тег, чтоп слова зачоркивать? Хотел вписать "лизать жопу") объяснять вещи, которые должны срабатывать на автомате... Наряд вне очереди... Хе-хе, Вы пойдите хорошего спеца по PHP найдите, потом будете раз 88 (восемьдесят восемь) думать насчет нарядов. Кстати, это ведь Вы написали статейку про Code Style (мол, надо то комментировать, это комментировать, отступы скобочки и т.д.). Вероятно, чуваки прозябающие в "нарядах", не знают, что такое "стиль кодирования", и мне от этого вас откровенно жаль.

Novikov Jul 12 2007 at 12:45

Да верю, верю, что Вы круты и смелы :-) Много видел таких крутых и смелых.

У нас пишут не на PHP, и я не отвлекаю своих людей от клиентских проектов на лично мои интересы и хобби ;-)

Тег, чтоб слова зачеркивать? ~~RTFM('HTML')~~ :-)

alkeeper Jul 12 2007 at 15:32

тогда уж по CSS

kostin Jul 10 2007 at 14:49

Статья понравилась, спасибо за неё. Тут, по крайней мере, собраны все основные источники небезопасности приложений: читать о каждом подробнее можно уже в других публикациях.

Немного расстроил стиль большинства критиков: вместо исправления ошибок, лишь указывают на них (а ведь люди квалифицированные, могли бы предложить свои конкретные добавочки). Хотя, безусловно, имеются и содержательные комментарии. За них тоже большое спасибо.

Throwable Jul 10 2007 at 14:51

Господа, не буду оригинален, но пора на свалку языки, допускающие подобное.
Пока все нормальные языки двигались в сторону контроля типов и строгих конструкций, скриптовые языки всегда пытались услужить программистам, убирая "ненужную" декларативную писанину. Использовать в веб среде язык, не делающий существенного различия между кодом и данными и допускающий динамический code-injection просто безумие. Поэтому любой php скрипт по дефолту остается дырявым, пока не доказано обратное. Я призываю всех обратить внимание в сторону Java EE: JSP/JSTL и фреймворков типа JSF.

gro Jul 10 2007 at 15:08

Очередной холивар? Давайте.
Откуда это нормальные языки двигались к строгим типам? От нетипизированных ассемблеров?
Вам не кажется, что изначально строгие типы, это ограничение компилирующих языков?
Что значит "не делающий существенного различия между кодом и данными"? Вы знакомы с функциональным программированием и т.п? PHP по "неделанью различий" очень далеко до многих языков. Хотя вы можете считать их всех ненормальными.

Поэтому любой php скрипт по дефолту остается дырявым, пока не доказано обратное

Хватит выдвигать безумные лозунги, их тьма. Мотивируйте.
Кстати, что вы подразумеваете под "скриптовыми" языками?

simple Jul 10 2007 at 15:14

Вероятно интерпритируемые языки =)

gro Jul 10 2007 at 15:27

А PHP не просто интерпретатор, а транслирующий. Java и C#, кстати, в некотором смысле тоже. Однако, различие интерпретатор/компилятор влияет только на скорость исполнения, но никак не на дырявость, типизированность и тому подобное.
Скрипт, же переводится, как сценарий. Скрипты выполняются в других системах, манипулируя уже существующими объектами. Браузерный Javascript - скриптовый язык, а PHP никакой не скриптовый.

simple Jul 10 2007 at 15:40

Я-то это понимаю...
Но PHP всё-таки скриптовый язык... У него даже это по-моему в документации написано.

gro Jul 10 2007 at 15:42

Документация нагло вводит в заблуждение =)

simple Jul 10 2007 at 16:34

Всё может быть, но я склонен верить ей - не зря же её писали +)

akral Jul 10 2007 at 18:30

Про данный случай ничего не говорю, но вообще в РНР документации порой проскальзывают косяки, особенно в переводной.

DEL Jul 10 2007 at 16:38

PHP скриптовый и даже то, что парсенный код может повторно запускаться при установки некоторого софта никак на это не влияет.

gro Jul 10 2007 at 16:55

Ладно, ладно
Универсальный скриптовый язык, согласен :)

akral Jul 10 2007 at 15:16

Эх... vi против emacs, кто-нибудь? :)

Я не знаю JSP, JSF, но я думаю, что человек умеющий может написать дырявый и опасный код и там, не правда ли? :)

UFO just landed and posted this here

leemuar Jul 10 2007 at 16:25

Я призываю Вас идти нафиг с вашими советами.
А лучше сюда - http://www.habrahabr.ru/blog/i_am_clever…

nini Jul 10 2007 at 17:57

а никакой вступительной статьи только для "Java EE: JSP/JSTL и фреймворков типа JSF" нет? что-то я ничего толкового найти не смог.

anton_nazarov Jul 11 2007 at 13:00

Еще бы :)
В J2EE Tutorial-е про JSP/JSTL/JSF первые 500 страниц.
Вот мощь Enterprise-технологий :)

hazy Jul 10 2007 at 15:05

в контексте о magick quotes:
Для борьбы с неправильными разработчиками, разработчики PHP решили все эскейпить. Теперь разработчики защищаются от разработчиков PHP выключением magick quotes )))

korchasa Jul 10 2007 at 15:13

Разработчики 300 раз уже извинились за magick quotes и register_globals, и safe_mode. Ну хватит их уже пинать. Все эти опции включаются обычно недалёкими админами.

Jenek Jul 10 2007 at 15:05

Спасибо, я как раз начинающий в php, статья понравилась.

Насчет error_reporting(8191), так конечно нельзя, а что если код будет читать кто-то не читавший с вашу статью :) и попробуй догадайся, что-это.

Стойт написать, что-то вроде:

if(!defined(E_STRICT)) define(E_STRICT, 2048);

хотя вам видней, я же начинающий

gro Jul 10 2007 at 15:10

if (!defined("E_STRICT")) define("E_STRICT", 2048);
кавычки не забываем :)

Jenek Jul 10 2007 at 15:28

конечно, просто непривычно брать в кавычки имена переменных и констант

gro Jul 10 2007 at 15:29

Это еще не имя константы :)

simple Jul 10 2007 at 15:11

Хм... Начинающие так не пишут =) Новички бы понаставили кучу {} скобок и писали бы без пробелов после запятых =)

Jenek Jul 10 2007 at 15:26

я начинающий в php

simple Jul 10 2007 at 15:34

Да. я это понял уже после своего комментария ) Просто у меня php был первым языком.

leemuar Jul 10 2007 at 15:26

Вы говорите об оформлении кода. Это приходит со временем. На алгоритм же не влияет никак.

simple Jul 10 2007 at 15:41

Осознал уже после нажатия кнопки "добавить" )

akral Jul 10 2007 at 15:18

Не поверите, в первой редакции этой статьи было так и написано.
Но я подумал, что это излишество. Что такое 8191, можно узнать там же, где и что такое E_STRICT.
А так две дополнительных комманды.

cyberklin Jul 10 2007 at 21:51

использование magic numbers в коде - плохой стиль программирования, как ни крути. почитайте книгу Макконнелла - там это рассмотрено очень подробно.

leemuar Jul 10 2007 at 15:32

Хорошая статья, напомнила мне мой период паранои в первые месяцы программирования на PHP.

Пожелания к статье: больше примеров "на слониках".
Например, сказано что register_globals - зло, а примеры взлома с их использованием не приведены.
Фраза "валидируйте все, что вводит пользователь" пугает своей сложностью =) Я бы сказал "Проверяйте" и "Trust no one" =)

leemuar Jul 10 2007 at 15:48

Кстати, о SQL-инъекциях. Я часто использую функцию для выполнения запросов, увиденную мною в книге Котерова. Изначально расчитана на MySQL, но легко меняется и для другой СУБД.

Выглядит так:
mysql_qw('INSERT INTO users (name) VALUES (?)', $u_name);

Работает аналогично sprintf: заменяет символы ? в строке запроса (1й параметр функции) на соответствующие ему значения и выполняет запрос. Перед заменой значения обрабатываются mysql_escape_string() и заключаются в кавычки.

Код функции:

$v) {
if (!$i) continue; // это шаблон
if (is_int($v)) continue; // целые числа не нужно экранировать
$args[$i] = "'".mysql_escape_string($v)."'";
}
// На всякий случай запорняем 20 последних аргументов недопустимыми
// значениями, чтобы в случае, если число "?" превышает количество
// параметров, выдавалась ошибка SQL-запроса (поможет при отладке).
for ($i=$c=count($args)-1; $i<$c+20; $i++)
$args[$i+1] = "UNKNOWN_PLACEHOLDER_$i";

// Формируем SQL-запрос.
return call_user_func_array("sprintf", $args);

leemuar Jul 10 2007 at 15:49

Код функции - http://forum.dklab.ru/viewtopic.php?p=10…

theGalex Jul 10 2007 at 17:01

тогда уж лучше использовать класс DB simple все от того же Дмитрия Котерова http://dklab.ru

leemuar Jul 10 2007 at 17:28

Ну классы - это уже для продвинутых, мы говорим о начинающих

DEL Jul 10 2007 at 17:54

Начинающим нужно начинать с классов.

leemuar Jul 10 2007 at 18:24

Не согласен.

UFO just landed and posted this here

alkeeper Jul 10 2007 at 20:51

Абсолютно согласен, при грамотном использовании ООП самые большие методы (функции) не более 20 строк получаются, при том с предельно ясной логикой. К тому же, на число строк в большей степени может влиять желание вписать код в 80тисимвольный предел по ширине для удобочитаемости и вот примерно такие sql запросы:

SELECT COUNT(*) AS `before`
FROM `some_table`
WHERE
`some_id` = '{$this->somvar}' AND (
`someoneelsevar` > '{$this->someproperty}' OR
(
`voices_number` = '{$this->onemoreproperty}' AND
`id` user_id}'
))

Уже не говоря о перевязке двух и более таблиц с различными JOIN'ами, группировками и т.д.

alkeeper Jul 10 2007 at 21:04

Ой, из-за маленького окошечка с синтаксисом напутал :(

UFO just landed and posted this here

alkeeper Jul 11 2007 at 11:05

Ну из-за одного запроса, имхо, менять привычный БД-Струмент не стоит. К тому же некоторые фичи DbSimple, заявленные как преимущества, мне кажутся сомнительными.

WoZ May 22 2008 at 16:03

и как на мускуле эти джойны работали? они сервак не ложили?

DEL Jul 11 2007 at 10:37

У начинающего должно точно в голову засесть объектно-ориентированное программирование, чтобы он не видел смысла писать что-то без использования классов. Сам же потом благодарить будет.

UFO just landed and posted this here

alkeeper Jul 10 2007 at 17:41

Речь идет о технологии Placeholder'ов, которая поддерживается, например такой штукой, как PEAR::DB и последователями (точно не помню ADODB кажется тоже держит плейсхолдеры), а также некоторыми БД на уровне их API для PHP, кроме того, смотрим про PDO Functions в мане

leemuar Jul 10 2007 at 18:25

Да, забыл упомянуть названия, спасибо.

dmach Jul 10 2007 at 16:02

Может быть стоило просто дать ссылку на http://ru.php.net/manual/ru/security.php?

leemuar Jul 10 2007 at 16:07

Может просто было написать RTF PHPM и не писать ни статьи ни камментов? =)

Easter Jul 10 2007 at 16:57

Хочу сказать спасибо за статью. Хотя для себя в ней ничего не прочел. Но знаю как это сложно собраться с духом и систематизировать свой опыт. Так как лишен хабара-потенции, то немогу добавить плюс. %)

flint Jul 11 2007 at 00:48

Статья неплохая, как памятка, если случилась внезапная амнезия. Или тем, кто вообще только начинает, пожалуй.

Вообще, чем больше я читаю статей по PHP, тем больше убеждаюсь в том, что заинтересованные делятся на две большие группы: те, кто хотят учится программированию и те, кто хотят учится программированию на PHP. Одна аббревиатура и один предлог решают вообще все, как не удивительно. Взять хотя бы ту прелестную радость, с которой php-шники открывают уже привычные вещи. Например, статьи в духе "что такое private в классах и где это использовать". Или "зачем нужны абстрактные классы". Круто.

Автору респект, что грамотно оформляет материалы. Приятно смотреть.

alkeeper Jul 11 2007 at 08:32

Чтож вы нас (PHP-программистов) совсем за варваров чумазых держите? Разве идеология ООП и его принципы как-то принципиально отличаются в PHP, или, если чувак начал писать вызовы со "стрелочками", то он типа ОО программист на PHP?

flint Jul 12 2007 at 22:00

Сюрприз: вы ушли в крайность и утрируете. Я не говорю, какие возможности предоставляет тот или иной язык. Я говорю про образ мышления и подход к разработке среднестатистического программиста.

Кстати, я сам достаточно много пишу на PHP. Потому что альтернатив, которые "стоят вообще везде" у него нет. Разве что Perl.

alkeeper Jul 13 2007 at 07:31

Да, наверное, вы правы, я погорячился. Подход среднего представителя PHP фауны сообщества обусловлен жывучестью PHP приложений, содержащих ошибки, "собачкой", выключаемыми display_errors и настраиваемым error_reporting. Отсюда лень, невнимательность исполнителя и его же пофигизм.

UFO just landed and posted this here

alkeeper Jul 11 2007 at 13:27

Видимо стоит разделять такие понятия как "php-шник" и "PHP-программист", как линуксоидов и Пользователей Linux ;)

UFO just landed and posted this here