2017-01-24 2 views
0

Les vérifications des lectures/écritures sur les enregistrements dans une base de données par les utilisateurs doivent-elles être effectuées avant de lire/écrire les données réelles? Ou pourrait-on simplement tout appliquer dans la même requête?Est-ce que les assertions ou les contrôles doivent être terminés avant qu'une action ait lieu pour changer la base de données?

ie.

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

Ou La vérification doit-elle être terminée dans le sql de l'action?

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

Being Me Way trop verbeux (alias verbeux)

Maintenant, je vais modifier toutes les requêtes, juste pour veiller à ce que les utilisateurs font les actions sont autorisés à le faire, où les utilisateurs ont accès pour lire/mettre à jour les enregistrements dans le tableau B qu'ils ont créés ou leurs rôles leur permettent d'ignorer les enregistrements appartenant à des utilisateurs mineurs (administrateurs, enseignants, étudiants)

Actuellement, le processus permet à tout utilisateur de modifier les enregistrements (pratique horrible). L'enseignant A peut voir les informations de l'enseignant B et les modifier en ajoutant/supprimant des élèves de la classe. Une simple vérification de la carte d'identité de l'enseignant empêcherait idéalement cette action. Dois-je effectuer une vérification avant d'accéder à cet enregistrement pour vérifier si l'enseignant X est autorisé à enregistrer id = Y dans la table B. Cela semble bien, mais est-ce vraiment le cas? Est-ce que je fais le double du travail pour vérifier d'abord que lire/écrire les données?

je pensais que ce serait un simple changement de déclaration de requête qui les tables joint basées sur l'ID utilisateur ou autorisations de rôle utilisateur à l'enregistrement qui est en cours de modification.

Je suis conseillé de faire une pré-vérification qui sonne bien, mais maintenant je fais un trafic potentiellement supplémentaire à la base de données pour compléter ce que je considère comme une simple transaction de lecture ou d'écriture. Je regarde en quelque sorte cela comme une affirmation ou une vérification via sql pour vérifier que l'utilisateur peut effectuer la tâche plutôt que de l'exécuter.

Est-ce une pratique standard pour les vérifications d'assertions/permissions? Vérifiez d'abord que vous disposez d'une fonction simple pour mettre à jour, insérer ou supprimer? (attention, Delete n'est jamais vraiment utilisé) Si ce n'est pas le cas, quelle serait une meilleure suggestion?

Informations supplémentaires Le système est configuré pour que l'utilisateur puisse actuellement lire ses propres données, mais avec quelques modifications simples, les utilisateurs peuvent réellement lire les données de n'importe qui.

projet est PHP avec MySQL back-end tout orienté objet

Répondre

2

Toujours vérifier d'abord si vous êtes méfiant, surtout si vous n'êtes pas très confiant dans vos chèques de aseptisation.

Donc, vous devez faire un simple

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

etc. Si is_admin est vrai, alors portez avec votre sélection/mise à jour/script d'insertion. Sinon, refusez l'accès.

+0

Ces vérifications devraient-elles être la pratique standard pour accéder à toutes les données? Lire/écrit? – mcv

+2

Cela dépend du niveau de sécurité dont vos lectures et écritures ont besoin.Si vous écrivez une sortie de backend statique générique vers la base de données, vous n'avez pas besoin de le faire. Pour la lecture, cela dépend entièrement si c'est un matériau sensible. Si elles doivent être un utilisateur admin ou avoir des privilèges spéciaux pour sélectionner ces lignes, alors oui, vérifiez au préalable. Dans le cas de données non-anonymes, cependant, vérifier au préalable ne va pas aider - l'injection peut se produire de toute façon. – Eoghan

+0

Actuellement, à partir de mon post ci-dessus, il n'y a aucun niveau de sécurité. J'ai déjà facilement piraté le site sans trop d'effort. Je pense simplement que si l'utilisateur A peut voir les données de l'utilisateur B plutôt que de les manipuler, il y a quelque chose de fondamentalement faux et pourquoi l'identifiant de l'utilisateur n'est pas utilisé dans la requête de base. – mcv