Как скрыть переменную $ _GET, чтобы быть более защищенной в PHP?

Question

Пока все мои сайты используют в основном $ _GET для получения данных для страницы.

Ex:

editad.php?posting_id=131 

editaccount.php?user_id=2 

-> есть ли способ, чтобы скрыть или быть более обеспеченных о том, что пользователь может видеть? Я не хочу, чтобы они просто могли сказать «URL-адрес editad.php? Posting_id = 40» в URL-адресе. Я знаю, что могу использовать POSTS, но есть ли способ для GET или нет?

-> Я передаю данные через GET, а затем проверяя эти данные, проверяя, равен ли идентификатор пользователя идентификатору пользователя страницы. Если они равны, это позволит пользователю отредактировать эту страницу, если нет, она отобразит только эту страницу. Я также удостоверяюсь, что число - это число, строка строка и т. Д. Есть ли другой способ сделать его более безопасным?

Answer 1

Нет, вы не можете сделать это с помощью $_GET. Чтобы получить защиту через безвестность *, вы можете использовать переменную $_POST, но $_POST также небезопасен (и может быть изменен пользователем). Вы всегда должны проверять входящие данные, независимо от того, используете ли вы $_GET или $_POST и убедитесь, что пользователю разрешен доступ к данным.

* Это будет неясным для мирян. Это будет немедленно прозрачно для любого заинтересованного программиста/хакера.

Answer 2

нет ничего плохого в том, что параметры запроса можно задать в _GET. _POST не более безопасен.

Если пользователь может редактировать объявление 30, но не рекламу 31, ваш код должен обеспечивать соблюдение этих правил.

Answer 3

Вы ответили на свой вопрос *, вы используете POST.

• Однако я не уверен, что вы подразумеваете под «более обеспеченным». Это веб-страница, вы можете посмотреть источник и посмотреть, какие пары ключ/значение отправляются в форму.

Answer 4

То, что я обычно делаю urldecode его (просто получить необработанное значение), а затем запустить эту функцию

function safedata($original) { 
return stripslashes(strip_tags(htmlspecialchars(trim($original)))); 
} 

работает как шарм. Кроме того, вы можете добавить функцию mysql_real_escape_string() в функцию, если вы уже подключены к базе данных.

Answer 5

Единственный способ защитить данные от подслушивающих устройств - использовать POST более https://.

Однако, нет никакого способа, чтобы защитить от пользователя в , так как пользователь может изменить для GET и POST данных легко.

Answer 6

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

Обратите внимание, что в зависимости от вашего приложения даже шифрования недостаточно. Например, если вы передаете токен безопасности, достаточно легко украсть, даже если вы не можете посмотреть содержимое, и вам нужно будет использовать https, а также несколько других вещей. Но это совсем другая возможность червей.

Answer 7

Говоря о безопасности, вы можете рассмотреть возможность использования любого из следующих действий:

1. Использование сеанса передать переменные
2. Добавить соль + хэш-ключ в URL будет принят.

Отправитель:

$hashedKey = sha1($salt + 'posting_id=131'); 
editad.php?posting_id=131&$key=$hashedKey; 

приемник:

$params = getUrlParams(); 
$hashedKey = sha1($salt + params); 

if ($_POST['$key'] == $hashedKey) 
    continue; 
else 
    displayError(); 

Answer 8

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

Пользователи не могут видеть это, поскольку информация о сеансе хранится только на сервере.

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

Вот некоторые сайты, я только что нашел в гугле о состоянии сеанса:

• http://www.w3schools.com/php/php_sessions.asp
• http://userweb.cs.utexas.edu/~mitra/csFall2005/cs329/lectures/php.html

Answer 9

В этом возрасте Firefox и Firebug это не так просто, чтобы скрыть то, что значения переходя от страницы к странице, особенно если это связано с URL-адресом ...

Любые «заинтересованные стороны» могут использовать разработку операторы, которые поставляются в комплекте с браузерами, чтобы посмотреть и посмотреть, как работает страница на самом деле ....

Единственное решение, как было предложено выше, - это зашифровать часть, которая показывает идентификацию пользователя с некоторой изобретательностью, разработчики знают, как это работает ....

Пример: Зачем передавать его как 'user_id' ....? Попробуйте передать его как «cxv = 32» ... Кроме того, вы можете зашифровать фактический идентификатор с помощью некоторого алгоритма, а затем расшифровать его на следующей странице. Это может остановить любую попытку изменения URL-адреса ... по крайней мере, это может сделайте это трудно ... !!

Просто используйте свое воображение ...! ;)

Answer 10

Одна вещь, о которой люди еще не упоминали, - это использование расширения PHP Suhosin. Вы можете исправить ряд известных явлений безопасности в суперглобальных гиперссылках PHP, установив Suhosin и дополнительно контролируя максимальную длину массива/глубину/размер для каждого из $_GET, $_POST и т. Д. Он также обеспечивает прозрачное шифрование данных сеанса. Выдержка из стандартного suhosin.ini файла конфигурации:

Ключ шифрования, используемый состоит из [а] определяется пользователем строки (который может быть изменен с помощью сценария с помощью ini_set()) и необязательно User-Agent, Document-Root и 0-4 Octects [sic] из REMOTE_ADDR.

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

Answer 11

Одним из способов быть немного более безопасным является использование случайного идентификатора сеанса, а не четкого текстового идентификатора пользователя. Как только пользователь войдет в систему, создайте что-то вроде 41b96964c35747e19019d2d0f2efb0d1 и используйте это для сеанса для идентификации пользователя. Таким образом, другой пользователь не может просто угадать следующий идентификатор.

Answer 12

использование nextpage.php?uid=base64_encode($id); и nextpage.php использования

$user_id=base64_decode($_GET[uid]);