Какой самый простой способ проверить, не манипулировали ли данными таблицы в firebug
У меня есть таблица, которая, очевидно, имеет идентификаторы для каждой строки. Когда пользователь нажимает на строку таблицы, он попадает на другую страницу, где отображаются полные данные (другая страница — это та же страница, которая не отображается после события загрузки).
Я собираю событие click с помощью jquery, а затем отправляю идентификатор в jquery load, и он загружается в данные.
Проблема в этом. Если у человека, использующего страницу, установлен firebug, он может манипулировать идентификатором на столе и, возможно, получить доступ к тому, к чему у него не должно быть доступа.
Поэтому мне пришлось написать функцию, которая проверяет, что входящий идентификатор может быть доступен этому пользователю.
function checkID($searchColumn,$userColumn,$tablename,$table_id,$user_id)
{
Global $db;
$query = "SELECT `{$userColumn}` FROM $tablename WHERE `{$searchColumn}`=?";
//echo $query;
$stmt = $db->prepare($query);
$stmt->bind_param('i',$table_id);
$stmt->execute();
$stmt->bind_result($myuser_id);
if($stmt->fetch())
{
if($myuser_id==$user_id):
return true;
else:
return false;
endif;
}
}
По сути, вышеуказанная функция дает мне истину или ложь в зависимости от того, может ли пользователь получить доступ к этому идентификатору.
Есть ли лучший способ проверить, были ли данные обработаны в firebug на стороне сервера?
По сути, я хочу убедиться, что идентификатор, отправляемый на сервер, совпадает с идентификатором в таблице, и им не манипулировал firebug. Хотя моя функция работает, я продолжаю думать, что, возможно, есть более простое решение. Что делают профессионалы?
Решение
Данные поступающие от клиента всегда должен быть проверен и продезинфицирован на стороне сервера.
То есть если $searchColumn, $userColumn, $tablename, $table_id а также $user_id входите как переменные запроса, вам нужно проверить правильность каждой из них. Особенно $userColumn, $tablename а также $searchColumn Нужно тщательно проверять SQL-инъекции, потому что они добавляются перед вызовом prepare(),
Если вам не требуется гибкость, вы должны ввести в таблицу имена таблиц и столбцов.
Вы даже можете сохранить идентификатор пользователя на стороне сервера (в качестве переменной сеанса) и установить его только один раз при входе в систему, чтобы полностью избавиться от проверки. Однако таблицы, ссылающиеся на пользовательские данные, все еще должны иметь столбец с идентификатором пользователя.
Чтобы гарантировать, что пользователь может получить доступ только к тем данным, которые он должен видеть, необходимо включить идентификатор пользователя в запрос.
Пример:
Представьте, что у вас есть заказы и элементы заказа в отношении от 1 до m. Вы показываете пользователю список заказов, которые он сделал. Когда пользователь теперь выбирает заказ для отображения своих элементов, вы можете включить в запрос идентификатор пользователя, чтобы гарантировать, что пользователь не сможет получить доступ к заказам других пользователей.
Тогда оператор SELECT может выглядеть так:
SELECT oi.name,
oi.description
oi.price
FROM order_item oi
INNER JOIN order o ON o.id = oi.order_id
WHERE o.id = ?
AND o.userID = ?
Когда пользователь затем предоставляет идентификатор заказа другого пользователя, элементы не возвращаются.
Это также можно сделать в два этапа, сначала сделав запрос order таблица, чтобы проверить, назначен ли заказ пользователю и, если да, сделать запрос по элементам заказа.
Другие решения
Других решений пока нет …