| ▲ | Tiberium 8 hours ago |
| A bit unrelated, but if you ever find a malicious use of Anthropic APIs like that, you can just upload the key to a GitHub Gist or a public repo - Anthropic is a GitHub scanning partner, so the key will be revoked almost instantly (you can delete the gist afterwards). It works for a lot of other providers too, including OpenAI (which also has file APIs, by the way). https://support.claude.com/en/articles/9767949-api-key-best-... https://docs.github.com/en/code-security/reference/secret-se... |
|
| ▲ | Davidzheng 20 minutes ago | parent | next [-] |
| I'm being kind of stupid but why does the prompt injection need to POST to anthropic servers at all, does claude cowork have some protections against POST to arbitrary domain but allow POST to anthropic with arbitrary user or something? |
|
| ▲ | securesaml 7 hours ago | parent | prev | next [-] |
| I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint.
Alternatively do this in a private repo and enable token revocation (if it exists) |
| |
| ▲ | jychang 6 hours ago | parent | next [-] | | You're revoking the attacker's key (that they're using to upload the docs to their own account), this is probably the best option available. Obviously you have better methods to revoke your own keys. | | |
| ▲ | securesaml 5 hours ago | parent [-] | | it is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?). agreed it shouldn't be used to revoke non-malicious/your own keys | | |
| ▲ | nebezb 3 hours ago | parent [-] | | The poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys… | | |
| ▲ | securesaml 3 hours ago | parent [-] | | there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data? | | |
|
|
| |
| ▲ | eru an hour ago | parent | prev [-] | | > What if GitHub’s token scanning service went down. If it's a secret gist, you only exposed the attacker's key to github, but not to the wider public? |
|
|
| ▲ | mucle6 7 hours ago | parent | prev | next [-] |
| Haha this feels like you're playing chess with the hackers |
| |
|
| ▲ | nh2 7 hours ago | parent | prev | next [-] |
| So that after the attackers exfiltrate your file to their Anthropic account, now the rest of the world also has access to that Anthropic account and thus your files? Nice plan. |
| |
| ▲ | DominoTree 5 hours ago | parent [-] | | For a window of a few minutes until the key gets automatically revoked Assuming that they took any of your files to begin with and you didn't discover the hidden prompt |
|
|
| ▲ | sebmellen 8 hours ago | parent | prev | next [-] |
| Pretty brilliant solution, never thought of that before. |
| |
| ▲ | j45 6 hours ago | parent [-] | | Except is there a guarantee of the lag time from posting the GIST to the keys being revoked? | | |
| ▲ | sk5t 6 hours ago | parent [-] | | Is this a serious question? Whom do you imagine would offer such a guarantee? Moreover, finding a more effective way to revoke a non-controlled key seems a tall order. | | |
| ▲ | j45 an hour ago | parent [-] | | If there’s a delay between jets being posted and disabled they would still be usable no? |
|
|
|
|
| ▲ | trees101 7 hours ago | parent | prev | next [-] |
| why would you do that rather than just revoking the key directly in the anthropic console? |
| |
| ▲ | mingus88 7 hours ago | parent [-] | | It’s the key used by the attackers in the payload I think. So you publish it and a scanner will revoke it | | |
| ▲ | trees101 7 hours ago | parent | next [-] | | oh I see, you're force-revoking someone else's key | |
| ▲ | freakynit 3 hours ago | parent | prev [-] | | Does this mean a program can be written to generate all possible api keys and upload to github thereby revoke everyone's access? | | |
| ▲ | kylecazar 3 hours ago | parent [-] | | They are designed to be long enough that it's entirely impractical to do this. All possible is a massive number. | | |
| ▲ | freakynit 2 hours ago | parent [-] | | That's true tho... possible, but impractical. | | |
| ▲ | 2 hours ago | parent | next [-] | | [deleted] | |
| ▲ | cortesoft 2 hours ago | parent | prev [-] | | Only possible if you are unconstrained by time and storage. | | |
| ▲ | eru an hour ago | parent [-] | | Not only you, but GitHub too, since you need to upload. Storage is actually not much of a problem (on your end): you can just generate them on the fly. |
|
|
|
|
|
|
|
| ▲ | 8 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | lanfeust6 7 hours ago | parent | prev [-] |
| Could this not lead to a penalty on the github account used to post it? |
| |
| ▲ | bigfatkitten 7 hours ago | parent [-] | | No, because people push their own keys to source repos every day. | | |
| ▲ | lanfeust6 7 hours ago | parent [-] | | Including keys associated with nefarious acts? | | |
| ▲ | edoceo 4 hours ago | parent [-] | | Maybe, the point is that people, in general, commit/post all kinds of secrets they shouldn't into GitHub. Secrets they own, shared secrets, secrets they found, secrets they don't known, etc. GitHub and their partners just see a secret and trigger the oops-a-wild-secret-has-appeared action. |
|
|
|
