API Security

[n-aggarwal]

Set up rules in firebase on who is allowed to access to access what info (business logic).

We want are that the message rooms are only accessible by the sender and the recipient themselves, and that the users cannot retrieve info about other users, their rooms and their messages.

I think it would be better to use allowlisting rules than denylisting rules to increase security.

As of right now, there is no security-- helps in testing...

If anyone wants to help:

Step 1 is to watch this video https://youtu.be/eW5MdE3ZcAw

Step 2 would be to abstractly come up with a set of rules

Step 3 Implement them.

[n-aggarwal]

I will let you know of the how I have set up the collections and the different Schemas by tomorrow night.

[n-aggarwal]

So here is the user Schema:

Before I begin note that each document in each collection has a uid.

First we have the Authentication Collection: That contains the { email, password , name } The password is hashed.

Next we have the "Users" Collection: That contains the {email, name, publicKey, listOfRooms} For a given user, their uid for auth and users will be the same. The email and name will also be the same. The public Key contains the public key of the user. The listOfRooms, well, contains a list of all the rooms the user is in (read further for more info on what rooms are).

Finally we have the ChatRooms:
The ChatRooms is a "Room" with two people -- the ones who are talking to each other. This is the one I most want to protect in our API security rules. The Schema for ChatRooms is as follows: {person_1, person_2, messages} person_1 is the uid of person_1 in the room, and person_2 is the uid of person_2 in the room. ONLY THESE TWO PEOPLE SHOULD BE ABLE TO ACCESS THIS ROOM. NO ONE ELSE SHOULD BE ALLOWED. messages is an array contains a list of message objects where each object is described as follows: {displayName, email, timestamp, message} The displayName is the name of the person who sent the message; email is the email of the person who sent the message. timestamp is the time at which the message was sent, and finally message is the actual text (later on will be encrypted) that the user sent.

[n-aggarwal]

@a-jacewicz I don't think I will have time to work on this because I have to work on the encryption (unless someone else wants to do that). So I will leave this to you. If you have trouble navigating the Schemas let me know!

I would encourage you to take a good look at the database and how the stuff is set up. Ignore the extra collections. Those are made for testing purposes.

[a-jacewicz]

Having a harder time than I expected with implementing API security, specifically because I had to scrap my previous implementation after figuring out that read applies to all fields within a collection, there’s no way to filter out which fields a user can read (meaning the get and list options) and which ones they cannot.

I don’t think this will cause too many problems, as for ChatRooms everything in any given ChatRoom should only be visible to the two people in it. Might be a problem with Users, as listOfRooms would ideally only be visible to the user whose list it is and other fields (email, name & publicKey) would be visible to all users. However, I don’t think that having listOfRooms being public is too big of a deal, as even with the uid of the chatroom, there will not be any way to see what it is in.

In terms of commands beside get, I’m blocking list so that it is never an option for ChatRooms and for Users. I don’t believe we ever want anyone calling more than one query or a collection read request at a time, although this may have to be edited later on if this is not true.

For Users I am not allowing delete, update and create, in addition.

I am not entirely convinced that not allowing create is the right thing to do, but will see. Since accounts being made in the sign in screen are being made through an sdk, that should override my security rules, which will mean that user account can only be created through the sign in page and the requirements associated with it, which is what should ideally happen.

We never want User information to be deleted and also don’t want any of the fields (publicKey, name, email, ListOfRooms) to be edited. Am also unsure on if this will mess up ListOfRooms, which should have new items added to its array when the user enters new ChatRooms, but I believe my security rule will again be overridden. Not as confident on this, though, and I’m predicting I might have to think of alternative ways of doing this.

For ChatRooms, I am not allowing delete. I am allowing create when user is logged in and might include some additional restrictions. I am allowing get if the user is one of the two users in the ChatRoom. Although the contents of ChatRooms change when they are being used (the messages portion), I am again going to try blocking update entirely and seeing if this security rule is overridden by users sending messages as implemented in the code. Based on some documentation I was reading, this might work.

Ideally it will, and then the ONLY way for users to change any aspect of ChatRooms is through sending messages, which will mean that the other fields, which really should not be edited (AESkey, person_1 and person_2) will remain as they should.

If this doesn’t work, will have to think of a different approach. I’m currently about halfway through on implementing this on firebase, but figured it would be good to share my thoughts while I do so in case anyone has anything they want to add/disagree with how I’m going about it.

[a-jacewicz]

Just finished writing first try of code on Firebase, about to attempt set up of testing environment, but going to check pull request first to merge it so that I am testing on fully functioning app with encryption implemented.

I'm predicting that I'm going to need to change how I'm doing update for ChatScreen, think it might end up being that I'm testing to make sure user is one of two people in chat room, that they are editing their own message, and that it is a message that has not yet been written (not quite sure how to implement last part?)

Code right now: rules_version = '2';

// reminder: If document is granted access by any rule, it WILL be allowed

service cloud.firestore { match /databases/{database}/documents { match /Users/{uid} { allow get :if request.auth != null; allow list :if false; // I think create is okay here as account is being made with // sdk allow create: if false ; allow update: if false; allow delete: if false;

match /ChatRooms/{ChatRoomsID} {
    allow get: if request.auth.uid == resource.data.person_1 || request.auth.uid == resource.data.person_2
  allow list :if false; 
        allow create :if  request.auth != null && request.auth.uid == resource.data.person_1 || request.auth.uid == resource.data.person_2; 
        allow update: if false; 
  allow delete: if false;
        }
    }
}

}

[a-jacewicz]

Finished writing and implementing API security for the time being. Implemented so that it protects the ChatRooms and the fields they contain. Have some protection written for Users as well, not ideally done but would need to change code to be able to do so.