Форум PHP

Привет всем! я не давно начал изучать php,mysql и щас делаю школьный сайт сделано много. И вот я хотел бы узнать безопасна ли у меня регистрация и авторизация пользователей. При создании сайта руководствовался вашей книгой PHP 5 На примерах.
главная страница, регистрация и авторизация пользователей в прикреплении.
И вот вопрос сессии безопасны или нет?
И что можете предложить им взамен?
Я знаю что:
в регистрации надо добавить проверку логина, паролей

Нет не безопасна. Нельзя подставлять данные в SQL-запрос, побывавшие на машине клиента без предварительной обработки. Перед подставновкой в SQL-запрос (файл handleruser.php) элемента суперглобального массива $_POST['login']

<?php   $query="SELECT * FROM users WHERE login='".$_POST['login']."'"; ?>

необходимо экранировать спец-символы (в зависимости от того, включены магические кавычки или нет), чтобы предотвратить SQL-инъекцию

<?php   if (!get_magic_quotes_gpc())   {     $_POST['login'] = mysql_escape_string($_POST['login']);   } ?>

PS Лучше избегать использования POSIX-регулярных выражений (ereg) и использовать вместо них Perl-регулярные выражения, так как первые будут исключены из ядра PHP в версии 6.

>PS Лучше избегать использования POSIX-регулярных выражений (ereg) и использовать вместо них Perl-регулярные выражения, так как первые будут исключены из ядра PHP в версии 6.
Это ты о проверки введеных данных при регистрации???

да.

С Perl еще не знаком:(
Ну придется знакомится=)
А больше нет уязвимостей???

Вроде как нет... только в файле vixod.php перед SQL-запросом

<?php   $query=mysql_query("DELETE * FROM session WHERE id_session=".$_GET['s_id'].""); ?>

добавьте преобразование

<?php   $_GET['s_id'] = intval($_GET['s_id']); ?>

чтобы всю таблицу не потёрли.

спасибо.
А сессия не безопасна в том смысле что если я оставлю на форуме ссылку в которой будет содержаться идентификатор сессии и любой сможет попасть в защищенную часть сайта??

Сессии обычно существуют небольшое время и в перспективе - это не опасно. Однако, если у вас SID передаётся через GET-параметры, а не через cookie без лишней надобности лучше такие ссылки не размещать - действительно, злоумышленик может получить доступ к защищённой части сайта.

привязка сессии к ип, софту...

а как к софту привязать? если не секрет...

имеется в виду, вероятно, к строке USER_AGENT.

...или новый нераспространенный способ основанныя на яве

Основанный на чем?

js, получение настроек браузера и версий его компонентов или модулей
надо будет мне покопаться в этом направлении

>получение настроек браузера и версий его компонентов или модулей

И что там можно выкопать? Все, что немногое можно узнать, это относящееся к браузеру - так это, для конкретного браузера, может быть стандартно для очень многих пользователей. Другое дело, если бы можно было узнать с помощью JS о пользователе.

Здравствуйте.

Вот вы говорите "привязка к IP", а в от такая ситуация - в школе компьютерный класс на каждой машине стоит Windows и браузер IE. Сайт находится на стороне. Все машини класса входят в интернет через шлюз, т.е. машин в классе десяток, а IP сайт ловит один. Что должен фильтровать сайт? Я предлагаю вариант с использованием проверки адреса, откуда пришел пользователь если со своего сайта - проверяем, с чужого - блокируем (т.е. исли он пришел с чужого сайта с моими переменными например uid).
Как хакер может узнать uid пользователя.
1. Похитить сессии специальным трояном. Но эта не наша проблемма. Ей должны заниматься админы.
2. Вписать в базу JS скрипт, который будет показывать куки. Здесь уже наша задача стереть ненужные теги.

>Все машини класса входят в интернет через шлюз, т.е. машин в классе десяток, а IP сайт ловит один

Если мы обсуждаем уже поднятую тему, то в данном конкретном случае никаких особых проблем не возникнет. Поскольку сессионный IP в том числе и при обращении изнутри школы не изменится (он как был, так и останется адресом прокси-сервера шлюза) то открытый сеанс пользователя будет работать.

Если же Вы собираетесь привязывать к IP что-то другое - тогда не стоит.
Впрочем, в этом случае лучше открыть новую тему. Предварительно почитав, например, здесь.

>Сессии обычно существуют небольшое время и в перспективе - это не опасно. Однако, если у вас SID передаётся через GET-параметры, а не через cookie без лишней надобности лучше такие ссылки не размещать - действительно, злоумышленик может получить доступ к защищённой части сайта.

То есть, я правильно вас понял?
Если перекрыть фильтрацией входных данных пути XSS уязвимости, то coocies в безопасности?
А SID , если его прямо не публиковать, так и вообще - всё равно, что в сейфе лежит? : )