Защита от подстановки переменных в URL

[Leony]

Есть уязвимость: путём подстановки значений в переменную сайт отдаёт бланк заказа
с данными клиента.
Естественно, парсером можно стибрить всю клиентскую базу ФИО, E-Mail, номеров телефонов.

Заказ можно сделать не только авторизованным клиентам.

Пришла идея: неавторизованных клиентов привязать к кукам: если заказал – номер заказа пишем в куку. Если клиент пытается выбрать данные, но номер заказа в куке не совпадает – редирект на страницу ошибки.
Но в данном случае хацкер может вычислить это дело: кука, ведь, находится у него в браузере...

С авторизованными всё ясно: привязка сессии к номеру/ам заказа.

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

 

[dandandan]

Храните всю инфу в Сессии. Урл может быть вообще без параметров или с одним id параметром (например, номер заказа). Если id параметра не привязан к данному пользователю, то выдаем ошибку или редирект куда-нибудь.

 

[ВладимирТрой]

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

 

[Leony]

Решил через .htaccess

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

 

[ВладимирТрой]

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

 

[Leony]

так можно ведь эмулировать запрос передав все необходимые заголовки

Да, действительно: через Proxomitron прикинулся линуксом, и нетскейпом – и .htaccess до фени...
Перехватывал заголовки, и пробовал бурпом их отправить.
Отправлял и Cookie, и User-Agent, и Referer – не прошло.
Я нуб пока в пыхе: подскажите, в какую сторону копать, может, есть у кого наработки.

Храните всю инфу в Сессии

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

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

php_flag session.use_only_cookies on

чтобы браузер не отдавал PHPSESSID в URL`е – у такой настройки подводных камней нет?

 

[Шумадан]

Есть уязвимость: путём подстановки значений в переменную сайт отдаёт бланк заказа
с данными клиента.
Естественно, парсером можно стибрить всю клиентскую базу ФИО, E-Mail, номеров телефонов.

Заказ можно сделать не только авторизованным клиентам.

Пришла идея: неавторизованных клиентов привязать к кукам: если заказал – номер заказа пишем в куку. Если клиент пытается выбрать данные, но номер заказа в куке не совпадает – редирект на страницу ошибки.
Но в данном случае хацкер может вычислить это дело: кука, ведь, находится у него в браузере...

С авторизованными всё ясно: привязка сессии к номеру/ам заказа.

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

зачем писать в куку, что заказал клиент?

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

 

[Leony]

зачем писать в куку, что заказал клиент? у вас в базе должно это храниться

так и сделал:

там, где формируется заказ 
$_SESSION['orders'] .= $заказ."-";  // записываем в БД, в данные сессии заказы, разделяя их дефисом
 
а в бланке заказа:
// защита персональных данных: данный файл показываем только владельцу заказов в данной сессии
if (stristr($_SESSION['orders'], $_GET['orders_id'])===FALSE){  // т.е. если в сесии, в БД нет запрашиваемых для просмотра заказов
header("HTTP/1.1 301 Moved Permanently");
header('Location: /404.php');
exit();
}

 

[Шумадан]

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

что будет, если у вас будет номер заказа 3 а в сессии будет 11-1-22-31-21?

 

[Leony]

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

session_set_save_handler("функция для открытия сесии", "функция для закрытия", "для чтения", "для записи", "для уничтожения", "для определения времени жизни сессии");
Ну а дальше работаем с сессиями, как обычно.

что будет, если у вас будет номер заказа 3 а в сессии будет 11-1-22-31-21?

упс...