Безопасно передать/получить страницу реферера в PHP через GET?

Я прочитал несколько сообщений, касающихся перенаправления на предыдущую страницу после входа пользователя в систему и т. д. и большинство упоминали, что получение URL-адреса предыдущей страницы через HTTP_REFERRER ненадежно/небезопасно.

Мой вопрос: могу ли я добавить немного информации в конец URL-адреса, скажем, login.php?referrer=main или login.php?referrer=prof, и полагаться на то, что такие переменные не будут подделаны, CRSF'ированы, изменены каким-либо образом?

Будет ли POST лучше/хуже? Есть ли надежный/безопасный способ добиться того, что мне нужно?

По сути, я пытаюсь найти лучший способ получить ссылочную страницу в PHP, чтобы ее можно было перенаправить без риска злонамеренных намерений, вызывающих сбои в работе сайта.

ТИА.

РЕДАКТИРОВАТЬ: Сценарий:

Пользователь посещает страницу комментариев, но ему необходимо войти в систему, чтобы опубликовать комментарий, поэтому на странице будет размещена ссылка login to comment. Когда пользователь щелкает ссылку login to comment, его целью будет login.php?comment20303, после посещения страницы входа и предоставления проверенных учетных данных он должен вернуться на страницу comment20303, с которой он был создан до входа в систему.

REEDIT: мой вопрос сводится к тому, безопасно ли добавлять URL-адрес перенаправления на страницу входа, получать к нему доступ через GET и повторно использовать его для возврата на исходную страницу? Из комментариев ниже видно, что ответ отрицательный, не без некоторых проверок достоверности.


person IIIOXIII    schedule 22.11.2014    source источник


Ответы (1)


Часто я помещаю ссылающуюся страницу в скрытое поле в своей форме.

<input type="hidden" name="ref" value="login.php"/>

Затем на моей целевой странице я буду использовать реферал с установленными переменными get, чтобы сообщить странице входа, почему она была перенаправлена ​​обратно.

$ref = trim(strip_tags($_POST['ref']));

//something causes an error (incorrect password maybe)======
$error = "true";
$msg = urlencode("Login Incorrect");
//no harm in putting the referring page in the GET but I don't think you need it for a login process.
header('location: '.$ref.'?error='.$error.'&msg='.$msg);
die();

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

if (isset($_GET['error']) && $_GET['error'] == "true"){
    $error = true;
    $msg = trim(strip_tags($_GET['msg']));

//Echo out the msg if it is set somewhere in your HTML
}

Я предпочитаю использовать POST при отправке формы. GET проще всего использовать для редиректа.

РЕДАКТИРОВАТЬ: НА ОСНОВЕ ВАШЕГО КОММЕНТАРИЯ

  1. пользователь вводит комментарий, и комментарий имеет сгенерированный системой идентификатор.
  2. пользователь не аутентифицирован, поэтому перенаправляется на reg/login с идентификатором в URL
  3. пользователь регистрируется/входит в систему снова, передает идентификатор в URL
  4. система аутентифицируется, и поскольку существует $_GET['commentID'], она вставляет запись БД, связывающую пользователя с комментарием.
  5. вернуть пользователя в область редактирования комментариев с идентификатором в URL и дескриптором.

Всегда обрезайте и зачищайте GET

person silversunhunter    schedule 22.11.2014
comment
Я планирую использовать его, скажем, на странице комментариев, когда пользователь не вошел в систему, он не может опубликовать комментарий, поэтому я подумал добавить ref=comment20304 в конец URL-адреса для входа, т.е. login.php?comment20304, поэтому, как только пользователь подтвердили свой вход в систему через login.php, они могут быть перенаправлены обратно на страницу, которую они просматривали до входа в систему. Я также рассматривал возможность POST, однако я где-то читал, что POST также небезопасен. В основном я хочу что-то безопасное, чтобы мои пользователи не перенаправлялись на old-xxx-ladies.com и т. д., а не на comment20304. - person IIIOXIII; 22.11.2014
comment
Конечно, добавление идентификатора комментария — это нормально, если вы связываете идентификатор с новым пользователем, прежде чем отправить его обратно в область редактирования комментария. Таким образом, они не могут попробовать разные идентификаторы и отредактировать их, поскольку они должны быть связаны с пользователем. - person silversunhunter; 22.11.2014
comment
да и так GET. И насколько я слышал, все, что отправляется через HTTP. Таким образом, вы должны поставить некоторые логические проверки и проверить, что вы получаете. - person silversunhunter; 22.11.2014
comment
@silversunhunter: я думаю, что частичное значение перенаправления и некоторые логические проверки — это то, что мне нужно, поскольку чем больше я об этом думаю, тем более, что я не добавляю/отправляю весь URL-адрес login.php?ref=sitename.com/comment49043, а просто идентификатор комментария странице, на которой они были до входа в систему, не должно быть риска для безопасности, потому что, если идентификатор комментария не найден или недействителен, я мог бы просто добавить процедуру предупреждения/ошибки, которая перенаправит их на страницу по умолчанию, такую ​​как их профиль и т.д. по ошибке. - person IIIOXIII; 22.11.2014
comment
@baao: я читал, что токен CSRF может быть полезен, но я даже не знаю, с чего начать реализацию такой стратегии. - person IIIOXIII; 22.11.2014
comment
Верно, но я бы сделал еще один шаг и связал идентификатор комментария с пользователем. Если я вижу, что нахожусь на странице комментариев, а идентификатор в URL-адресе равен 123, я могу попробовать 124 125 или любое другое число, пока не найду тот, который открыт для редактирования. Система должна проверить и убедиться, что этот комментарий принадлежит мне, прежде чем разрешить мне его редактировать. - person silversunhunter; 22.11.2014
comment
Это небольшое руководство для начала bkcore.com/blog/code/nocsrf- php-класс.html - person baao; 22.11.2014
comment
@silvershunter: я говорю о простом добавлении комментария, чтобы сказать ветку форума. Для этого пользователю нужно будет войти в систему, однако поток, в котором он находится, может быть прокомментирован любым зарегистрированным пользователем, в этом случае, я думаю, все, что мне нужно, это идентификатор потока. Затем я могу поставить проверку на странице потока, чтобы убедиться, что идентификатор потока действительно соответствует действительному потоку, найденному в базе данных, и, если нет, перенаправить на страницу потока, не найденного. Однако, если комментируемый поток имел определенные привилегии, мне нужно было бы проверить их идентификатор пользователя и т. д., чтобы убедиться, что они могут просматривать/добавлять в поток. - person IIIOXIII; 22.11.2014