Безопастность в PHP...

← →
Knight © (2003-09-27 22:21) [0]

Спросил, тут сабж на XPoint, так там все прям такие крутые, обназывали кто как смог, а на вопрос так конкретно ничего и не ответили... так-что я лучше тут спрошу, не так обидно... :)

Как защитить ресурс и настройки пользователей от сторонних посягательств. В частности как тут можно использовать SSL? И что такое MD5? Если можно, подкрепите, примерами или ссылками.

← →
Knight © (2003-09-27 23:09) [1]

Для примера...

------------------------------------------
Проверять откуда запрос:
$referer=getenv("HTTP_REFERER");
if (!ereg("^ http://www.myserver.com")) {
echo "hacker? he-he...\n";
exit;
}
------------------------------------------

Отрезать лишнее по требуемой длинне, т.к. форму можно подделать:
$username=substr($username,0,20);
------------------------------------------

Отсеивать пустое:
if (empty($username)) {
echo "invalid username";
exit;
}
------------------------------------------

Запретить пользователю использовать любые символы, кроме букв русского и латинского алфавита, знака "_" (подчерк), пробела и цифр:

if (preg_match("/[^(\w)|(\x7F-\xFF)|(\s)]/",$username)) {
echo "invalid username";
exit;
}
------------------------------------------

Для поля ввода адреса e-mail добавить в список разрешенных символов знаки "@" и ".", но убрать русские буквы и пробел:

if (preg_match("/[^(\w)|(\@)|(\.)]/",$usermail)) {
echo "invalid mail";
exit;
}
------------------------------------------

В поле ввода текста использовать функций nl2br(), htmlspecialchars(), strip_tags(). Если нужны теги то использовать тегозаменители. Никогда не разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов, например IMG.
------------------------------------------

Вести логи. Если в каждую из описанных процедур встроить возможность занесения события в лог-файл с указанием IP-адреса потенциального злоумышленника - то в случае реальной атаки вычислить хакера будет гораздо проще, поскольку хакеры обычно пробуют последовательно усложняющиеся атаки. Для определения IP-адреса желательно использовать не только стандартную переменную REMOTE_ADDR, но и менее известную HTTP_X_FORWARDED_FOR, которая позволяет определить IP пользователя, находящегося за прокси-сервером. Естественно - если прокси это позволяет.
------------------------------------------

Использовать сессии совместно с переменными в куксах и ссылках.
------------------------------------------

← →
Knight © (2003-09-27 23:47) [2]

Вот ещё придумал...
------------------------------------------

Запретить изменение не только ника, но и мыла, чтобы после того, как кто-то пробьётся к настройкам пользователя и что-либо там изменит (например, пароль), owner смог это исправить, т.к. получит все изменения в, автоматически отправленном ему, письме.
------------------------------------------

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

Шифровать письма пользователю... только вот пока не знаю, как это сделать средствами PHP, чтобы пользователь смог после это прочитать... :)
------------------------------------------

← →
Dionys © (2003-09-28 01:43) [3]

http://netsecurity.r2.ru/docs/aspects.html

← →
Knight © (2003-09-28 02:12) [4]

>> Dionys © (28.09.03 01:43) [3]
А на PHP ничего не встречал?

Но за менюшку, всё-равно, спасибо... мне понравилось :)

← →
Dionys © (2003-09-28 03:02) [5]

PHP: авторизация доступа - http://getinfo.ru/get.html?did=393
Сессии в PHP - http://getinfo.ru/get.html?did=250
Приемы безопасного программирования веб-приложений на PHP - http://getinfo.ru/get.html?did=210

← →
Knight © (2003-09-28 08:17) [6]

Это уже читал... И всё что написано выше именно от туда :)

← →
Dionys © (2003-09-28 08:57) [7]

а это?...
http://docs.gets.ru/catalog.html?cat=24&slevel=2
http://docs.gets.ru/catalog.html?cat=56&slevel=2
http://phpclub.net/index.phtml?m=30079&newlang=ru

← →
Knight © (2003-09-28 09:59) [8]

Что-то интересное там есть, но прочитать не успел... отца приспичило на рыбалку ехать, вернусь, дочитаю... :)

← →
MeF88 © (2003-09-28 10:32) [9]

MD5 - алгоритм шифровки строк и цифр в строку длиной 32, состоящую из разных знаков. Причем обратного преобразования не существует. Вот почему при потере пароля отправляют новый, а не старый. Так как старый они получить не могут. (Это только на нормальных сайтах).

Больше ниче сказать не смогу, т.к. есть свои методы обеспечения безопастности, а объяснять их смысл мне влом.

← →
Knight © (2003-09-28 10:37) [10]

>> MeF88 © (28.09.03 10:32) [9]
А как им пользоваться из PHP? Функции есть?

> А как им пользоваться из PHP? Функции есть?

Есть. Называется string md5(string)...

>> MeF88 © (28.09.03 10:32) [9]
Если лом пройдёт, напиши, что-нить... я буду только к вечеру.
Особенно меня интерисует, обеспечение безопастности для пользователей, приходящих из локальных сеток... т.к. у самого, в своё время в общаге, мыло угнали... XRAY"ем, кажется.

-------------------------------------
Ещё одна мысль...

Прописывать генерированный ID не только в ссылки и формы, но и в куксы, причём все разные. В начале каждой страницы сверять старый с тем, что в базе, если сошлось, то заменять его на новый. Это сделает подделку куки довольно проблематичной (при условии, что все пакеты не перехватываются третьими лицами, например, в локальной сети, соответствующими программами)

>> MeF88 © (28.09.03 10:39) [11]
> Есть. Называется string md5(string)...
За функцию спасибо... не встречал, а может внимания не обратил.

>Больше ниче сказать не смогу, т.к. есть свои методы обеспечения > безопастности, а объяснять их смысл мне влом.
Но всё-же напиши если, что... :)

Люди поделитесь своими наработками...

> Особенно меня интерисует, обеспечение безопастности для
> пользователей, приходящих из локальных сеток... т.к. у самого,
> в своё время в общаге, мыло угнали... XRAY"ем, кажется.

И ещё, какие логи лучше вести самому? (для определения атак и последующего вычисления атакующего)

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

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

А пункты такие:

> Всегда спрашивать пароль при входе.

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

> Для входа в режим редактирования использовать:
>>Основной пароль.
>>Дополнительный пароль.

Комментарий: После регистрации в первом таком письме высылать дополнительный (сгенерированный)пароль, а можно и логин, которые запрашивать, например, через диалог Header("WWW-Authenticate: Basic realm=\"My Realm\"") при попытке зайти в режим редактирования настроек, а лучше при попытке сохранить изменения (человек уже наизменял всего... мысли в голове ходят, о том, какой он крутой кулхацкер, а тут такой облом :)

Основному оставлять форум, чат и другую мелочёвку.
-----------------------------------------------

> Запретить изменение E-mail после регистрации.
> Уведомлять о всех изменениях от моего имени.

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

Прописывать генерированный ID не только в ссылки и формы, но и в куксы, причём все разные. В начале каждой страницы сверять старый с тем, что в базе, если сошлось, то заменять его на новый. Это сделает подделку куки довольно проблематичной (опять же, при условии, что все пакеты не перехватываются третьими лицами)
-----------------------------------------------

Может добавите ещё что-нить?

Безопастность в PHP... Найти похожие ветки