Шифрование и проверка переменной сеанса перед запросом MySQL

Question

У меня есть такой URL (который вы должны войти в систему, чтобы увидеть): https://www.example.com/form.php?id=268

form.php предназначен для пользователей, чтобы обновить информацию о конкретной записи БД (в данном случае идентификатор 268)

Приложение в основном получает идентификатор no, проверяет и очищает его, выполняет запрос mysql и затем заполняет форму результатами запроса.

В запросе я использую idиз URL-адреса плюс переменная сеанса $ _SESSION ['company_id'], которая устанавливается при входе в систему.Это означает, что если пользователь вручную изменяет URL-адрес (например)? Id = 269, он / она сможет видеть детали идентификатора 269 только в том случае, если company_id совпадает с идентификатором company_id, установленным в переменной сеанса.

Я уверен, что идентификатор URL будет в порядке / безопасен, но переменная сеанса меня беспокоит.Я не выполняю никаких проверок IP или пользовательских агентов для переменной сеанса, прежде чем выполнить запрос mysql, что заставляет меня чувствовать себя немного уязвимым.Итак ...

1. Как вы думаете, я должен зашифровать $ _SESSION ['company_id'] для дополнительной безопасности?
2. Как вы думаете, стоит ли выполнять проверку пользовательского агента перед запускомзапрос?Добавляет ли это какое-либо значение безопасности?

-

Обновление

Перепишите вопрос и название, чтобы попытаться быть более конкретным

Answer 1

Нет способа прочитать или изменить переменные $ _SESSION, если PHP не сделает это за вас, поэтому я не вижу причин, по которым вы должны их зашифровать. Поскольку этот вопрос в основном касается личного мнения или методов обеспечения безопасности, я бы сделал следующее:

1. Я не знаю почему, но всякий раз, когда я вижу переменные GET в URL, я всегда начинаю кричать небезопасно в моей голове. Это просто кажется мне рискованным. Я думаю, что подобные URL просто заставляют больше людей хотеть что-то пробовать. Это также может повлиять на рейтинг SEO. Я бы поработал над mod_rewriting, чтобы http://www.example.com/form/123/ автоматически загружал http://www.example.com/form.php?id=123. Если ничего другого, по крайней мере, URL будут выглядеть хорошо.

2. Не думайте, что ID всегда будет содержать цифры. Вместо того, чтобы полагаться на то, что ваши пользователи пропускают номера, и MySQL избегает их в целях безопасности, почему бы не проверить идентификатор самостоятельно и убедиться, что он содержит только цифры?

3. Я не знаю точной реализации подготовленных операторов в PHP, поэтому я не стану приводить вам пример, но я бы порекомендовал использовать их. Они значительно снижают риск внедрения SQL.

Вот файл .htaccess для демонстрации перезаписи URL:

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^form/([0-9]+)/?$ form.php?id=$1 [L,QSA]
</IfModule>

Проверка:

<?php
if(preg_match("/^[0-9]+$/", $_GET['id']))
{
    // show record
}
?>

Answer 2

я собираюсь попытаться обойти ваши и без того плохие практики программирования,
.1 никогда не посылать сырые идентификаторы глазам пользователей
.2 всегда очищать данные перед запросом, или вы сами найдете себя на телефоне с помощью телефона.Ваша хостинговая компания весь день перезагружает серверы ...
.3 вы можете передавать на сервер все что угодно и манипулировать данными.

- вот способ избежать этого, чтобы пользователь не смогизменяя эту HTML-разметку:

// на странице входа установите скрытое поле идентификатора, например, так:

<? 
$array = array('1,2,3,4,5,6,7,8,9,10');
shuffle($array);
$val = pop($array);
$val =  md5($val) 
?>

<form action="page.php?$val">
<input name="whatever" value "<? echo $val ?>"
..... rest of your form
</form>

, затем вы захотите создать page.php со следующим кодом

<?
switch($_POST['whatever']){
   case md5(1):
... run your login code
   break;
   case md5(2):
... run your login code
break;
   case md5(3):
... run your login code
break;
   case md5(4):
... run your login code
break;
   case md5(5):
... run your login code
break;
   case md5(6):
... run your login code
break;
   case md5(7):
... run your login code
break;
   case md5(8):
... run your login code
break;
   case md5(9):
... run your login code
break;
   case md5(10):
... run your login code 
break;
}
?>

теперь не имеет значения, что это за число, потому что оно случайное .... но если они так сильно меняют один символ в URL, это не будет соответствовать строке md5, определенной сервером, ведьма не будетпойманный switch statement ..... теперь необходимы дополнительные сообщения об ошибках, но это ваша работа, малыш!Надеюсь, это поможет.