
Secure database-driven applications on Neocities - stefmonge
https://fauna.com/blog/secure-database-driven-applications-on-neocities
======
jitl
What is the security model here? I see the word "secure", but no discussion of
threat models or what this security provides.

If there's a key that can create users and arbitrary records, and the key is
stored in plaintext in your browser code, what's to keep an enterprising user
from using your FaunaDB instance as their own data store if they copy-paste
the key into their own scripts?

Does FaunaDB protect against a resource usage attack where the client key is
used to (maliciously) create millions or billions of new users, costing $$$$?

~~~
jchanimal
You are correct that a script could create new users at machine speed. Rate
limiting is typically done outside of the app server stack, but the FaunaDB
dynamic schedule, QoS, and quota system have the potentially to mitigate this
kind of attack. For instance, as we add support for per-key quotas etc, the
publicly exposed key can be provisioned with the limits you describe.

The use case we're illustrating here is support for the early stages of
experimental apps. In the case of a successful app needing to patch this
vulnerability in realtime, the sensible thing to do may be to put the user
creation function behind a Lambda-like endpoint or a smart proxy that can
apply non-application logic to manage resource attacks.

You can learn about the object-level security model here:
[https://fauna.com/documentation/security](https://fauna.com/documentation/security)

~~~
jitl
Given your response here, I think using the word "secure" in your article
title is disingenuous.

You shouldn't promote a practice or technique as "secure", but then when asked
about security, tell me that the sensible thing to do is to implement security
myself.

You should discuss the limitations of your actor-based security model frankly
in your documentation and promotional tutorials. Even more so because you plan
more security features like "key-based quotas", indicating y'all are well
aware of these limitations, and foresee the need for more mitigations!

As it is, I think FaunaDB is an interesting product, but because of the
approach to security related messaging, I view the whole system with distrust.
What other "lies of omission" would I find if I actually started using this
product?

~~~
le-mark
How is this different than someone attacking a contact form on a wordpress
site? In your mind what would be a sufficient mitigation for a service like
this? A one time use token for example? Captcha on the signup form?

~~~
jitl
Yeah, I think your suggested mitigations sound reasonable. Everything in this
space is going to be only partial mitigations, but it should still be
discussed, especially if "secure" is a selling point and given that the
FaunaDB service is billed based on usage.

What I would do:

\- one-time use token for the creation form, a la CSRF tokens and nonces;
Although that just doubles the number of requests needed to perform a
submission

\- rate-limit all endpoints based on IP, user agent, etc

\- Captcha on creation form

------
jchanimal
Author here: Only a few years ago the idea of the browser connecting directly
to a cloud database was considered unthinkable from a security standpoint. Now
backend APIs are used directly by browser and mobile apps everywhere.

Has anything changed other than developer's comfort with connecting directly
from the browser to the backend? Mobile apps are common, and single page
applications are accepted. In my experience moving to a simpler stack is good
for security.

------
manigandham
{secret:"fnACW7G2d0ACAeiItklGS3QR-FW3sjHK3zwP1kus"}

What is the point in having database access with secrets available to the end-
user and how is that secure?

~~~
jchanimal
This secret is merely the token that allows for new users to sign up. Once you
are authenticated, you get a per-user secret that is kept in local storage.

Many signup forms don't even have the equivalent of the first secret. It's
purpose is more as a client identifier than a genuine secret. If a malicious
client were to grab that published secret, the web service author could rotate
keys and put a new secret in the HTML, and rate limit the attacked secret.

~~~
placeybordeaux
Would you consider my private keys secure if I posted them here and said that
I would rotate them as soon as someone uses them in a way I don't like?

~~~
jchanimal
It's common for client applications to encode a client secret. Many API client
apps use a model like this, for example Firebase calls their equivalent token
an API Key.

The "secret" in this case is really being used to select a context. So the
secret you'd embed in your copy of the app would differ from mine, and it
would point to your database, not mine.

------
foota
I think the biggest take away from this article is that neocities still
exists.

Edit: neat database service as well

------
le-mark
> With a secure database that starts for free and runs at global scale, web
> applications hosted on Neocities can come alive with custom data. — Kyle
> Drake, Founder of Neocities

Holy shit Kyle, that is a HUGE about face for you!

