I'm still working on full documentation for this project (sorry y'all, I probably should've done that before posting the video), but for now I'll write here and note that being authorized does not give you full access to the database if the tables have protection policies. Different tables have protection policies in place.

When a user signs in, an auth token is generated and stored in the authTokens table. That auth token is a JSON object that contains the user's id, the auth token itself, and the expiration date of the token (measured as millis since unix epoch).

A table can have any combination of four protection flags:

'c' - Create Access:
When a user creates a row (JSON obj) in the table, a 'userId' field will be automatically appended to that row. Unauthenticated users cannot create rows in this table, and will receive a 401 response if they attempt to do so.

'r' - Read Access:
When a user attempts to read from the table, they will only received data from rows in which userId == authToken.userId. If they request a SELECT * query and do not have access to any of the rows in the table, they will received an empty array. If they request a SELECT {id} query on a row they do not have access to, they will receive a 401 response.
Any table with the 'r' protection flag should also be given the 'c' flag to ensure that rows created by the user will append the user's id to the row.

'u' - Update Access:
When a user requests to update a row (JSON obj) in the table, they will only be allowed to do so if the target row's userId == authToken.userId. If it does not, the user will receive a 401 response.
Any table with the 'u' protection flag should also be given the 'c' flag to ensure that rows created by the user will append the user's id to the row.

'd' - Delete Access:
When a users requests to delete a row (JSON obj) in the table, they will only be allowed to do so if the target row's userId == authToken.userId. If it does not, the user will receive a 401 response.
Any table with the 'd' protection flag should also be given the 'c' flag to ensure that rows created by the user will append the user's id to the row.

'*' - All Access:
This flag applies all four of the protection flags (c, r, u, and d) to the table.

By default, a new table has no protection flags. This means that anybody can read, write, update or delete data from that row. Protection flags are given to a table by running the PROTECT {tableName} {flags} command on the /query endpoint.

For example, the posts table will have three protection flags: Create, Update and Delete, because you want the post to be readable to all users, but you don't want the post to be editable by anybody other than the post's author. Adding these protection flags with the PROTECT command would look like this:

PROTECT posts cru

When a query is made to the database, the server first checks for protection flags on that table. If it has no protection flags, the server will proceed to honor the request. If the table DOES have protection flags, the server will then check the request headers to ensure that an Authorization header with a token has been included. If it has, the server will check the authTokens table to ensure that the token is valid (exists and isn't expired). If the token is included and valid, the server will use that token to follow the rules outlined above.

Note: requests on the users and authTokens table via the /query endpoint are forbidden and will be rejected. Instead, all auth-related functions are handled with the AUTH command, which has four variants:

AUTH REGISTER {username} {password} - Registers a new user with the provided username and password and returns a new auth token

AUTH LOGIN {username} {password} - Checks the provided username and password against the users table to see if the credentials are valid. If valid, a new auth token will be issued and returned. If not, a 401 will be returns.

AUTH VERIFY {authToken} - Checks the provided authToken against the authTokens table to see if the authToken exists and is not expired. Returns a JSON object with a 'tokenValid' boolean that is true if the token is valid or false if the token is not valid.

AUTH LOGOUT {authToken} - Delete the provided authToken from the authTokens table if it exists

As far as SQL injection goes, that shouldn't be too much of an issue. MCDB does not contain an honest-to-god SQL interpreter, and will not execute more than one command per /query request.

For example, the INSERT INTO command is structured as such:
INSERT INTO {tableName} VALUE {JSON object or really anything you want}

If you create a post on MCSocial, the query will look something like this:
INSERT INTO posts VALUE {"content":"I love Minecraft!"}

If you were to try to create a post on MCSocial that had a body like "I love Minecraft`; DELETE * FROM posts;", it wouldn't do anything because the /query endpoint won't even recognize the second command. It'll just chug everything after VALUE and write it to the database. It might make your JSON syntax invalid and therefore make your post unreadable, but it wouldn't affect other data on the server.

I will note that there are definitely security vulnerabilities with this project. For example, there is no encryption between the client and server, so a user's auth token is exposed when a request is made to the server.

There are plenty of security and efficiency upgrades I could make to this project (future video or livestream?), but please be aware that this project is a proof-of-concept. It is not meant for real-world applications. The security features that exist are there simply because I wanted to play with them, not because I recommend using MCDB in production.

[MCSocial Site] SQL injection #4

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions