1
votes

Quel est le problème avec la mise en œuvre des règles de sécurité Firebase dans l'application elle-même?

Je suis nouveau dans la base de données Firebase et j'ai du mal à comprendre les règles de sécurité.

Exemple de règle 1:

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

La règle ci-dessus permet à tout le monde de lire et d'écrire la base de données.

Exemple de règle 2:

XXX

La règle ci-dessus permet uniquement à l'utilisateur authentifié de lire et d'écrire uniquement ses propres données.

Ma question est, si j'ai défini la règle de sécurité de ma base de données sur Exemple de règle 1 et développer mon application de manière à ce que seuls les utilisateurs authentifiés puissent lire et écrire les données, quel est le problème?

Quel est le problème avec la mise en œuvre des règles de sécurité dans l'application elle-même? fort>


0 commentaires

3 Réponses :


3
votes

Si je définis la règle de sécurité de ma base de données sur Exemple de règle 1 et que je développe mon application de telle manière que seuls les utilisateurs authentifiés puissent lire et écrire les données, qu'est-ce qui ne va pas?

Les règles de sécurité de votre première solution, valident les opérations de lecture et d'écriture sur l'ensemble de votre base de données. Donc, si vous attachez un écouteur sur le nœud racine de votre base de données Firebase, il vérifiera si vous avez l'autorisation de lecture sur le nœud racine. Puisque vous avez défini l'autorisation de lecture / écriture sur true:

{
   "rules": {
     ".read": true,
     ".write": true
   }
}

Toutes les opérations de lecture et d'écriture seront approuvées, quel que soit l'aspect de votre code comme dans votre application. Veuillez noter que n'importe quel autre utilisateur peut accéder à votre base de données, même s'il n'utilise pas votre application.

Quel est le problème avec la mise en œuvre des règles de sécurité dans l'application elle-même?

Vous ne pouvez pas ajouter de règles de sécurité dans votre application. Vous pouvez ajouter des contraintes, mais vous ne pouvez pas effectuer l'opération de rejet du serveur selon certaines règles.


3 commentaires

Je ne voulais pas dire ajouter des règles de sécurité dans l'application. Je veux dire que je peux créer l'application en suivant les règles de l'exemple de règle 2 même si ma règle de sécurité est l'exemple de règle 1, n'est-ce pas?


Non, vous ne pouvez pas faire cela! Même si vous sécurisez votre application à 100% par programme, d'autres applications ou utilisateurs peuvent accéder à votre base de données si vous utilisez les règles de sécurité dans l'exemple 1. Je vous recommande donc fortement de sécuriser votre base de données à l'aide de la deuxième solution, afin que seuls les utilisateurs authentifiés puissent y accéder.


@eegooDeveloper La règle numéro un des solutions client-serveur est de ne jamais faire confiance au client . Vous pouvez placer des contrôles dans le client pour limiter les options présentées à un utilisateur, ou l'avertir qu'il ne peut pas faire quelque chose sans toucher le serveur, mais le serveur doit toujours contrôler toute requête qu'il reçoit. Sinon, quelqu'un pourrait écrire son propre client (sans ces chèques), ou pirater le vôtre (pour les contourner).



1
votes

Vous devez suivre cette https://firebase.google.com/ docs / base de données / sécurité / sécurisation des données . Ces règles permettent de définir la sécurité de vos données. Quel type de données peut lire et par qui. Les règles suivent généralement la structure de données que vous avez utilisée dans votre base de données.

{
"rules": {
"users": {
  "$user": {
    // only users whose marks greater than 70  can be read
    ".read": "data.child('marks').val() > (70)",

  }
  }
 }
 }

Afin de lire les données des utilisateurs dont les notes sont supérieures à 70, alors nous pouvons écrire notre règle comme

{
 "users": {
"users0": {
  "name": "ABC",
   "marks":"75",
  "email": "m@gmail.com"
},
"users1": {
  "name": "XYZ",
  "marks":"30",
  "email": "abc@gmail.com"
},

}
}

Dans ce cas , seules les données utilisateur dont les marques sont supérieures à 70 seront lues par l'utilisateur.


2 commentaires

Je sais. Mais nous pouvons faire la même chose dans notre application en utilisant le code, non? Je pense que nous devons le faire. Alors, quel est l'intérêt d'écrire cela comme règle de sécurité?


Ouais, on peut faire ça. Mais il semblait être dans les meilleures pratiques de ne pas écrire trop de code dans votre classe. soit les avoir dans un fichier séparé ou vous pouvez simplement les écrire dans firebase.



1
votes

Lorsque vous accédez à Firebase Database à partir de votre application, votre application contient les informations de configuration nécessaires pour accéder à votre base de données. Pour la base de données en temps réel qui est une URL du modèle https://yourprojectname.firebaseio.com , qui se trouve dans votre google-services.json . L'application doit contenir ces informations pour permettre à votre application de fonctionner. Sans cela, l'application ne saurait à quelle base de données accéder.

Mais cela signifie également qu'un utilisateur malveillant peut extraire ces informations de votre application et les utiliser pour accéder à la base de données sans utiliser votre application. Une fois qu'ils connaissent l'URL de votre base de données non protégée, ils peuvent l'utiliser dans leur propre code. Et si leur code ne suit pas les mêmes règles que votre code, vos données seront corrompues (ou compromises), car il n'y a pas de règles de sécurité côté serveur pour appliquer ces règles.

Un exemple très simple est qu'ils peuvent utiliser l'API Firebase REST pour supprimez toutes vos données .

curl -X DELETE 'https://yourprojectname.firebaseio.com/.json'

Si vous implémentez la logique dans les règles de sécurité côté serveur de Firebase, il n'y a aucun moyen pour un utilisateur malveillant pour le contourner. Même s'ils utilisent l'URL de votre base de données, leurs appels de code / REST seront également vérifiés par rapport aux règles de sécurité et rejetés s'ils ne correspondent pas.


0 commentaires