2017-01-24 19 views
0

Должны ли выполняться проверки чтения/записи записей в базе данных пользователями перед чтением/записью фактических данных? Или можно просто применить все это в одном запросе?должно быть выполнено или должно быть выполнено до того, как произойдет действие, чтобы изменить базу данных?

ie.

assertUserCanViewClassRoom($classroomId, $userId, $userRole); 
assertUserCanRemoveStudent($classroomId, $userId, $userRole); 

Или Если проверка должна быть завершена в sql мероприятия?

viewClassRoom($classroomId, $userId, $userRole); 
removeStudent($classroomId, $userId, $userRole); 

Me Being Слишком Многословный (ака Словесный)

Теперь я собирался изменить все запросы, просто чтобы убедиться, что пользователи делают действия разрешено делать так, где пользователи имеют доступ для чтения/обновления записей в таблице B, которые они могут создать или их роли, позволяют им игнорировать записи, принадлежащие меньшим пользователям (например, администраторы, преподаватели, учащиеся)

В настоящее время этот процесс позволяет любому пользователю изменять записи (ужасная практика). Учитель A может просмотреть информацию о Учителе B и изменить ее, добавив/удалив учащихся из класса. Простая проверка идентификатора учителя идеально предотвратила бы это действие даже из-за происходящего.

Должен ли я поставить чек перед доступом к этой записи, чтобы проверить, имеет ли Teacher X разрешение на запись id = Y в таблицу B. Это звучит здорово, но действительно ли это? Я делаю двойную работу, чтобы проверить сначала, чем читать/записывать данные?

Я думал, что это будет просто изменить оператор запроса, который присоединяется к таблицы, основанной на идентификатор пользователя или роли пользователя разрешения к записи, которая будет изменяться.

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

Является ли эта стандартная практика для утверждений/проверок разрешения? Проверьте сначала, чем простую функцию для обновления, вставки или удаления? (помните, что Delete никогда не используется). Если это не так, то что было бы лучшим предложением?

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

Проект PHP с MySQL бэкэндом все объектно-ориентированном

ответ

2

Всегда проверяйте первым, если вы осторожны, особенно если вы не очень уверены в своих проверках санитарной обработки.

Таким образом, вы могли бы сделать простой

SELECT is_admin FROM users WHERE user = '{$userid}'; 

и т.д. Если is_admin верно, то вести с выбора/обновления/скрипт вставки. Если нет, запретите доступ.

+0

Должны ли эти проверки быть стандартной практикой для доступа ко всем данным? Чтение/запись? – mcv

+2

Это зависит от уровня безопасности, который вы читаете и пишет.Если вы пишете какой-то общий статический backend-выход в db, вам не нужно. Для чтения это полностью зависит от того, является ли он чувствительным материалом. Если они должны быть администратором или иметь специальные привилегии для выбора из этих строк, тогда да, проверьте заранее. Однако в случае неанализированных данных проверка заранее не поможет - инъекция может произойти в любом случае. – Eoghan

+0

В настоящее время из моего поста выше есть нулевые уровни безопасности. Я уже легко взломал сайт без особых усилий. Я просто думаю, что если пользователь A может видеть данные пользователя B, чем манипулировать им, есть что-то принципиально неправильное и почему идентификатор пользователя не использовался в базовом запросе с помощью левого оператора объединения. – mcv