We maintain a repository of useful and illustrative examples of the Flame applications in the repo flame-examples
Web applications often store data for multiple users in a single data structure. While convenient, implementation errors could lead to information leaks. Labeling each user’s data with information flow policies and enforcing information flow control with Flame eliminates such errors by construction. We took an existing Servant REST webapp for storing and retrieving memos, added support for multiple users, and enforced information flow control to ensure only the user possessing a secret key may create, read, or delete the associated memos.
Instructions:
> git clone https://bitbucket.org/decenters/flame-examples > cd flame-examples/memodb > stack build :memodb-server > stack exec memodb-server
Then, from the command line, use curl to interact with the REST api:
> curl http://localhost:8080/memos
Missing auth header
> curl -H "servant-auth-cookie:key1" \
-H "Content-type: application/json" \
-d '{"memo":"Flame rocks!" }' http://localhost:8080/memos
> curl -H "servant-auth-cookie:key1" http://localhost:8080/memos
[{"createdAt":"2017-09-14T19:24:17.720088Z","text":"Flame rocks!","id":1}]
You can also use a sample webage that embeds Javascript that uses this API. First, browse to http://localhost:8080. Entering a valid secret key (try key1, key2, or key3) will list the memos for that user allow you to enter new ones.
Finally, you can try a Flame-enabled Servant client:
> stack build :memodb-client
> stack exec memodb-client
GET key1 before POST: []
GET key1 after POST: [Memo {id = 1, text = "Try Flame and Servant!", createdAt = 2017-09-14 21:07:31.325636 UTC}]
A big advantage of this approach is that
memodb-client and memodb-server
link against the same API specification, ensuring that the same
security policies are enforced on the client and the server.
Nonmalleable information flow control (NMIFC) enforces security for programs that downgrade confidentiality and integrity policies. Like robust declassification, nonmalleability prevents attackers from controlling what information is declassified by a program. NMIFC goes further to prevent attackers from leveraging endorsements to influence declassifications or manipulate confidential data. </p>
NMIFC is useful for authentication mechanisms since they inherently require endorsement and declassification: the result of an authentication attempt is public and trustworthy, despite having a secret dependency (the password or other secret authentication data) and an untrustworthy dependency (the password guess).
To demonstrate how Flame can be used to enforce NMIFC for authentication mechanisms, we have implemented a Basic Authentication module for the Servant web application framework. We used this module to provide a new authentication to our multi-user memo app.
Instructions:
git clone https://bitbucket.org/decenters/flame-examples cd flame-examples/memodb stack build :nmauthdemo stack exec nmauthdemo
Then, browse to http://localhost:8080. You can use username “alice” and password “12345” to log in. Hint: your browser may cache your authentication credentials, so try opening the page in a private browsing session if you want to try logging in multiple times.
Macaroons are authentication tokens like cookies, but may contain more sophisticated caveats that constrain the authority of the token to access resources or perform actions.
Instructions:
> git clone https://bitbucket.org/decenters/flame-examples > cd flame-examples/memodb-macaroons > stack build :memodb-macaroons > stack exec memodb-macaroons alice's macaroon:MDAxM2xvY2F0...
Then, from the command line, use curl to interact with the REST api:
> curl http://localhost:8080/memos
Missing auth header
> curl -H "servant-auth-macaroon:MDAxM2xvY2F0..." \
-H "Content-type: application/json" \
-d '{"memo":"Flame rocks!" }' http://localhost:8080/memos
> curl -H "servant-auth-macaroon:MDAxM2xvY2F0..." http://localhost:8080/memos
[{"createdAt":"2017-09-14T19:24:17.720088Z","text":"Flame rocks!","id":1}]