GET параметры. Как запретить изменение их вручную?

Question

[dev400]

Как запретить изменение каких либо GET параметров пользователю? Тоесть если человек перешел по ссылке с гет параметрами, то все норм. а если сам ввел туда что то, то ошибка?

Comments

[werw]

Если подходить идеологически правильно, то смысла в этом нет никакого.

Answer 1

[Юрий]

ко всем ссылкам добавлять сигнатуру.

пример функции для генерации ссылок

function getLink($url, $data) {
  ksort($data);
  $query = http_build_query($data);
  $signature = sha512($_SESSION['salt'] . $query);
  return $url . '?' . $query . '&sign=' . $signature;
}

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

function checkSign() {
  $data = $_GET;
  $signQuery = $_GET['sign'];
  unset($data['sign']);
  ksort($data);
  $query = http_build_query($data);
  $signature = sha512($_SESSION['salt'] . $query);
  return $signature === $signQuery;
}

если юзер чтото поменяет то сигнатура не сойдется.
чтобы увеличить безопасность лучше в сигнатуру добавить еще и юрл. иначе у
/users/?id=5
/post/?id=5
сигнатуры будут одинаковые

Comments

[Юрий]

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

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

[Сергей Соколов]

Юрий: ссылку с неизменёнными параметрами передали другу, и она не сработала – потому, что соль, сессия – зачем это всё?

[Юрий]

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

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

Answer 2

[Сергей Соколов]

Добавлять параметром подпись, которая считается как хэш от параметров в ссылке и некого «секрета», известного только серверу. Такую подпись злодей не сможет подделать (с приемлемой вероятностью), а при изменении параметров, подпись не совпадёт, при проверке на сервере. Такая схема, в частности, применяется во ВКонтакте для проверки GET-запроса при открытии iFrame приложений.

Например, ваша ссылка должна содержать параметры param_a и param_b. Когда вы её генерируете на сервере, добавляется параметр sign, равный md5-хэшу от строки, полученной конкатенацией названий параметров, их значений и секретного ключа:

$secretKey = "nXYFyArf6F6iQXTzg"; // хранится в тайне, известен только серверу
$a = "значение неподделываемого параметра А";
$b = "значение неподделываемого параметра B";
$params = array(
  'param_a' => $a,
  'param_b' => $b,
  'sign'    => md5( "param_a" . $a . "param_b" . $b . $secretKey),
);
printf( '<a href="http://site.com?%s">Суперссылка</a>', http_build_query($params));

На сервере полученные GET-параметры проверяются: необходимо наличие подписи, и её совпадение с переданными параметрами. Подпись для полученных параметров вычисляется так же, как и при генерации ссылки – и сравнивается с переданной подписью.

Comments

[dev400]

То есть в таком случае нужно генерировать $a и $b при каждом создании сессии?

[Сергей Соколов]

Андрей: при каждом запросе страницы со ссылкой

Answer 3

[Mikhail Osher]

JWT, например.