Key security vulnerability about airbrake-js

[eur00t]

The problem can be solved by adding another specific key, which is generated at every page request. This key should grant permissions to the client:

1. 'use this key only at this page';
2. 'use this key only within security time range'.

The first one is easy to break, as intruder can emulate page environment in notification request by setting required HTTP headers or other request parameters.

One possible solution for 2. is a time-synchronized one-time password technique (http://en.wikipedia.org/wiki/One-time_password#Time-synchronized ). It involves a Symmetric-key algorithm (http://en.wikipedia.org/wiki/Symmetric-key_algorithm ):

• a secret cryptographic key is shared between web server (which serves the page with Airbrake notifier.js) and Airbrake.io API server;
• at each page request current time (T) is encrypted with secret key T -> Ts;
• notification message includes encrypted time Ts and API key;
• server decrypts Ts with secret key attached to received API key. If decrypted time is in security time range, notification is confirmed, else it's rejected.

The point is that time Ts key only could be used within security time range. If user doesn't reload the page for a time longer than that, Ts becomes invalid and can't be used to send notifications.

Every page visitor has access to time key Ts, but it is valid only for limited period of time. This solution makes malicious API key usage harder, but still possible: the intruder can receive fresh time keys by parsing the page retrieved from original web server.

[duncanbeevers]

Has this been an issue for anyone? @benarent Have you seen abuse of this type happening?

I'm not sure how the back-end side works, but we could issue multiple api keys per project which could be revoked. My feelings is that a complicated system like the one described would lead to more problems than it solves.

[benarent]

@duncanbeevers I think it's less of an issue as it's just a write only key, and if someone steals it and sends bad data the key can be easily revoked.

Marking as closed.

[jek-bao-choo]

Hi @benarent
Referring to your comment on 26 Nov 2013,

"I think it's less of an issue as it's just a write only key, and if someone steals it and sends bad data the key can be easily revoked."

In your mentioned solution, what if there is a group of persistent hackers targeting the site, so how many times does one have to repeat the process of revocation and re-deploy the site with the new API key?

Isn't there a way like how Firebase firebase.google.com does it?
They allow users to expose their API key in client-side javascript because they have a good security rules that check for privileges before one could read or write to database, storage, and etc.

@kyrylo #209

[zefer]

@choopage the worst case scenario here is that a malicious party could send errors or deploys to your project. It's a write-only key. This would easily be resolved by rotating your api-key, and we've not yet had any reported case of this happening.

what if there is a group of persistent hackers targeting the site, so how many times does one have to repeat the process of revocation and re-deploy the site with the new API key?

This would be inconvenient, but it is the worst that a group of persistent hackers can achieve with your key.

[derosm2]

Any chance this could be added to the readme or a FAQ section? I think it would be good to acknowledge this upfront so people are aware of any risks, however minimal.

[vmihailenco]

Reopening this, but I think we should provide some way to improve security rather than adding a warning without possible workarounds.