calabdean
commented
4 years ago tyk-policy-bug-debug.log debug log didn't originally upload
Open calabdean opened 4 years ago
calabdean
commented
4 years ago tyk-policy-bug-debug.log debug log didn't originally upload
mcandre
commented
4 years ago Does this happen with too-short keys as well, e.g. 3 that have exactly one matching real key in use?
v2.9.1 and v2.9.4
Describe the bug The bug occurs when using security policies to restrict APIs. I was avoiding the hash collision by using RSA256 and noticed that the keys were still colliding when using this hash. upon further investigation, I found that once a successful call was made to Tyk using the key, a second key (murmur32 by the looks of it) is created in redis and opens my API up to similar but not exactly correct keys, this issue is documented in https://github.com/TykTechnologies/tyk/issues/2516.
Reproduction steps Steps to reproduce the behavior:
start up env docker-compose up (compose file in tyk-bug.txt)
check redis keys (using db 1 with current config, not 0) docker exec -it 294-testing_redis_1 sh /data # redis-cli -n 1 127.0.0.1:6379[1]> keys * 1) "host-checker:PollerActiveInstanceID"
create API do curl command provided intially (in tyk-bug.txt) { "key": "294test", "status": "ok", "action": "added" }
create key using policy do curl command provided intially (in tyk-bug.txt) { "key": "eyJvcmciOiIxIiwiaWQiOiIyOTR0ZXN0a2V5IiwiaCI6InNoYTI1NiJ9", "status": "ok", "action": "added", "key_hash": "3722c0ac57a3a405fac6ca5aee12f7f51cf1c0debbf0f7c0a33d97cf244b4303" }
check redis keys (expect new key with sha256 to be created) 127.0.0.1:6379[1]> keys * 1) "apikey-3722c0ac57a3a405fac6ca5aee12f7f51cf1c0debbf0f7c0a33d97cf244b4303" 2) "host-checker:PollerActiveInstanceID"
try API with incorrect auth header (expect to be told you're not allowed) curl -k https://localhost:8081/294test -H "Authorization: 294testkeys" { "error": "Access to this API has been disallowed" }
check redis keys (expect nothing to happen except some analytics data be loaded) 127.0.0.1:6379[1]> keys * 1) "analytics-tyk-system-analytics" 2) "apikey-3722c0ac57a3a405fac6ca5aee12f7f51cf1c0debbf0f7c0a33d97cf244b4303" 3) "host-checker:PollerActiveInstanceID"
try API with correct auth header (expect to get reply from server, just using a little HTTP echo server) curl -k https://localhost:8081/294test -H "Authorization: 294testkey" {"headers":{"host":"XXXX","user-agent":"curl/7.64.0","accept":"/","authorization":"294testkey","x-forwarded-for":"172.30.0.1","accept-encoding":"gzip"},"body":{}}
check redis keys (expect to see murmur32 key present somehow) 127.0.0.1:6379[1]> keys * 1) "host-checker:PollerActiveInstanceID" 2) "quota-c870ca83" 3) "apikey-c870ca83" 4) "analytics-tyk-system-analytics" 5) "apikey-3722c0ac57a3a405fac6ca5aee12f7f51cf1c0debbf0f7c0a33d97cf244b4303"
compare key contents 127.0.0.1:6379[1]> get apikey-3722c0ac57a3a405fac6ca5aee12f7f51cf1c0debbf0f7c0a33d97cf244b4303 "{\"last_check\":0,\"allowance\":1000,\"rate\":100,\"per\":1,\"throttle_interval\":0,\"throttle_retry_limit\":0,\"date_created\":\"2020-04-23T02:40:37.08824718Z\",\"expires\":-1,\"quota_max\":10000,\"quota_renews\":0,\"quota_remaining\":-1,\"quota_renewal_rate\":3600,\"access_rights\":{\"294test\":{\"api_name\":\"294 Testing\",\"api_id\":\"294test\",\"versions\":[\"Default\"],\"allowed_urls\":[{\"url\":\"\",\"methods\":[\"GET\"]}],\"limit\":{\"rate\":100,\"per\":1,\"throttle_interval\":0,\"throttle_retry_limit\":0,\"quota_max\":10000,\"quota_renews\":0,\"quota_remaining\":0,\"quota_renewal_rate\":3600},\"allowance_scope\":\"\"}},\"org_id\":\"1\",\"oauth_client_id\":\"\",\"oauth_keys\":null,\"certificate\":\"\",\"basic_auth_data\":{\"password\":\"\",\"hash_type\":\"\"},\"jwt_data\":{\"secret\":\"\"},\"hmac_enabled\":false,\"enable_http_signature_validation\":false,\"hmac_string\":\"\",\"rsa_certificate_id\":\"\",\"is_inactive\":false,\"apply_policy_id\":\"\",\"apply_policies\":[\"294tester\"],\"data_expires\":0,\"monitor\":{\"trigger_limits\":null},\"enable_detail_recording\":false,\"meta_data\":{},\"tags\":[\"Startup Users\"],\"alias\":\"\",\"last_updated\":\"1587609637\",\"id_extractor_deadline\":0,\"session_lifetime\":0}" 127.0.0.1:6379[1]> get apikey-c870ca83 "{\"last_check\":0,\"allowance\":1000,\"rate\":100,\"per\":1,\"throttle_interval\":0,\"throttle_retry_limit\":0,\"date_created\":\"2020-04-23T02:40:37.08824718Z\",\"expires\":-1,\"quota_max\":10000,\"quota_renews\":1587613410,\"quota_remaining\":9999,\"quota_renewal_rate\":3600,\"access_rights\":{\"294test\":{\"api_name\":\"294 Testing\",\"api_id\":\"294test\",\"versions\":[\"Default\"],\"allowed_urls\":[{\"url\":\"\",\"methods\":[\"GET\"]}],\"limit\":{\"rate\":100,\"per\":1,\"throttle_interval\":0,\"throttle_retry_limit\":0,\"quota_max\":10000,\"quota_renews\":1587613410,\"quota_remaining\":9999,\"quota_renewal_rate\":3600},\"allowance_scope\":\"\"}},\"org_id\":\"1\",\"oauth_client_id\":\"\",\"oauth_keys\":null,\"certificate\":\"\",\"basic_auth_data\":{\"password\":\"\",\"hash_type\":\"\"},\"jwt_data\":{\"secret\":\"\"},\"hmac_enabled\":false,\"enable_http_signature_validation\":false,\"hmac_string\":\"\",\"rsa_certificate_id\":\"\",\"is_inactive\":false,\"apply_policy_id\":\"\",\"apply_policies\":[\"294tester\"],\"data_expires\":0,\"monitor\":{\"trigger_limits\":null},\"enable_detail_recording\":false,\"meta_data\":{},\"tags\":[\"Startup Users\"],\"alias\":\"\",\"last_updated\":\"1587609637\",\"id_extractor_deadline\":0,\"session_lifetime\":0}"
try API with slightly incorrect key (expect that some small variant will let me in, similar to bug 2516) curl -k https://localhost:8081/294test -H "Authorization: 294testkeys" {"headers":{"host":"nfdocker01-dev.in.telstra.com.au:64007","user-agent":"curl/7.64.0","accept":"/","authorization":"294testkeys","x-forwarded-for":"172.30.0.1","accept-encoding":"gzip"},"body":{}}
confirm key is still in redis 127.0.0.1:6379[1]> keys * 1) "host-checker:PollerActiveInstanceID" 2) "quota-c870ca83" 3) "apikey-c870ca83" 4) "analytics-tyk-system-analytics" 5) "apikey-3722c0ac57a3a405fac6ca5aee12f7f51cf1c0debbf0f7c0a33d97cf244b4303"
Actual behavior A new key (suspect murmur32 somehow) is created in redis, and API keys that did not match the key created were being allowed access to the API. The behaviour seems similar to https://github.com/TykTechnologies/tyk/issues/2516 in the resulting behaviour, but I'm unsure how the key is being added into redis.
Expected behavior I expected that there should be no collision using a hash algorithm other than murmur32, as I have seen it documented that this collides easily. I expect that the API should be restricted only to the exact key created
Screenshots/Video NA
Logs (debug mode or log file): see attached file [Uploading tyk-policy-bug-debug.log…]
Configuration (tyk config file): see attached file (top section covers env, lower section describes what i saw) tyk-bug.txt
Additional context This problem doesn't occur when defining the key restrictions using the access_rights field in the key creation, only when using policies