ਇੱਕ GET collection endpoint 'ਤੇ ਗੁੰਮ ਹੋਈ ਸੁਰੱਖਿਆ ਜਾਂਚ (security check) ਕਾਰਨ, CoopCycle ਦੇ ਕਿਸੇ ਵੀ ਬੇਸਿਕ ਖਾਤੇ ਵਾਲਾ ਵਿਅਕਤੀ ਇੱਕ ਸਾਂਝੇ ਇੰਸਟੈਂਸ (shared instance) ਵਿੱਚ ਹਰ ਸਟੋਰ ਦੀ ਪੂਰੀ ਐਡਰੈੱਸ ਬੁੱਕ ਕੱਢ ਸਕਦਾ ਸੀ, ਜਿਸ ਨਾਲ ਅਣਗਿਣਤ ਗਾਹਕਾਂ ਦੇ ਨਾਮ, ਗਲੀ ਦੇ ਪਤੇ ਅਤੇ ਪੋਸਟਕੋਡ ਪ੍ਰਗਟ ਹੋ ਗਏ। ਇਸ ਖਾਮੀ ਨੂੰ ਦੋ ਦਿਨਾਂ ਦੇ ਅੰਦਰ ਸੁਧਾਰ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨਵੀਨਤਮ ਰਿਲੀਜ਼ ਕੀਤੇ ਗਏ ਵਰਜ਼ਨ ਵਿੱਚ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਦੀ ਅਪੀਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਲੀਕ ਕਿਵੇਂ ਹੋਈ
CoopCycle – ਇੱਕ ਓਪਨ-ਸੋਰਸ ਲੌਜਿਸਟਿਕਸ ਪਲੇਟਫਾਰਮ ਜੋ ਫੂਡ-ਡਿਲੀਵਰੀ ਸਹਿਕਾਰੀ ਸਭਾਵਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ – ਆਪਣੇ API ਨੂੰ PHP ਫਰੇਮਵਰਕ API Platform ਨਾਲ ਡੈਫਾਈਨ ਕਰਦਾ ਹੈ। ਉਸ ਫਰੇਮਵਰਕ ਵਿੱਚ, ਹਰੇਕ ਆਪਰੇਸ਼ਨ (POST, GET, ਆਦਿ) ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਆ ਐਕਸਪ੍ਰੈਸ਼ਨ (security expression) ਨਾਲ ਜੋੜਨਾ ਲਾਜ਼ਮੀ ਹੈ; ਜੇਕਰ ਐਕਸਪ੍ਰੈਸ਼ਨ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਫਰੇਮਵਰਕ ਕਿਸੇ ਵੀ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਚੈੱਕ (authorization check) ਤੋਂ ਬਿਨਾਂ ਕੋਡ ਚਲਾਉਂਦਾ ਹੈ।
ਡਿਵੈਲਪਰਾਂ ਨੇ POST ਰਿਕੁਐਸਟ, ਜੋ ਸਟੋਰ ਦੀ ਐਡਰੈੱਸ ਲਿਸਟ ਬਣਾਉਂਦੀ ਹੈ ਜਾਂ ਅੱਪਡੇਟ ਕਰਦੀ ਹੈ, ਨੂੰ ਸਟੈਂਡਰਡ ਐਕਸਪ੍ਰੈਸ਼ਨ is_granted('edit', object) ਨਾਲ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਸੀ। ਇਹ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਰਿਕੁਐਸਟ ਇੱਕ ਸਿੰਗਲ ਸਟੋਰ ਐਂਟਿਟੀ ਨੂੰ ਟਾਰਗੇਟ ਕਰਦੀ ਹੈ, ਜੋ ਫਰੇਮਵਰਕ ਨੂੰ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਇੱਕ ਨਿਸ਼ਚਿਤ "object" ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।
GET ਰਿਕੁਐਸਟ ਜੋ ਉਸੇ ਸਰੋਤ (resource) ਨੂੰ ਪੜ੍ਹਦੀ ਹੈ, ਉਹ ਇੱਕ ਕਲੈਕਸ਼ਨ ਨੂੰ ਟਾਰਗੇਟ ਕਰਦੀ ਹੈ: /api/stores/{id}/addresses। ਇੱਕ ਕਲੈਕਸ਼ਨ ਵਿੱਚ ਕੋਈ ਸਿੰਗਲ ਆਬਜੈਕਟ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਉਹੀ is_granted('edit', object) ਐਕਸਪ੍ਰੈਸ਼ਨ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਕਿਉਂਕਿ ਡਿਵੈਲਪਰਾਂ ਨੇ ਸੁਰੱਖਿਆ ਲਾਈਨ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਸੀ, ਫਰੇਮਵਰਕ ਨੇ ਟੈਨੈਂਸੀ (tenancy) ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਿਸੇ ਵੀ ਪ੍ਰਮਾਣਿਤ (authenticated) ਉਪਭੋਗਤਾ ਨੂੰ ਐਡਰੈੱਸ ਡੇਟਾ ਪ੍ਰਦਾਨ ਕਰ ਦਿੱਤਾ।
ਇੱਕ ਸਾਂਝੇ CoopCycle ਇੰਸਟੈਂਸ 'ਤੇ, ਇੱਕ ਮਾਲੀਸ਼ੀਅਸ ਯੂਜ਼ਰ (malicious user) ਸਿਰਫ਼ ਸਟੋਰ IDs ਰਾਹੀਂ ਇਟਰੇਟ ਕਰ ਸਕਦਾ ਸੀ, ਐਂਡਪੁਆਇੰਟ ਨੂੰ GET ਰਿਕੁਐਸਟਾਂ ਭੇਜ ਸਕਦਾ ਸੀ, ਅਤੇ ਸਿਸਟਮ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਹਰ ਗਾਹਕ ਦੇ ਘਰ ਦੇ ਪਤੇ ਸਕ੍ਰੈਪ (scrape) ਕਰ ਸਕਦਾ ਸੀ। ਇੱਕ ਆਮ ਖਾਤੇ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਵਾਧੂ ਅਧਿਕਾਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ।
ਬੱਗ ਕਿਉਂ ਬਚਿਆ ਰਿਹਾ
ਇਹ ਸਮੱਸਿਆ ਕੋਈ ਸਧਾਰਨ ਲਾਪਰਵਾਹੀ ਨਹੀਂ ਸੀ। API Platform ਦੇ ਡਿਕਲੇਰੇਟਿਵ ਸੁਰੱਖਿਆ ਮਾਡਲ ਵਿੱਚ ਇਹ ਦੱਸਣ ਦਾ ਕੋਈ ਸਿੱਧਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ ਕਿ "ਉਪਭੋਗਤਾ ਨੂੰ ਕਲੈਕਸ਼ਨ ਵਿੱਚ ਹਰੇਕ ਆਬਜੈਕਟ ਦੇ ਸਮਾਨ ਟੈਨੈਂਟ (tenant) ਨਾਲ ਸਬੰਧਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।" ਕੋਡ ਦੀ ਉਹ ਗੁੰਮ ਹੋਈ ਲਾਈਨ ਉੱਥੇ ਹੀ ਸੀ ਜਿੱਥੇ ਫਰੇਮਵਰਕ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ।
ਮਸਲੇ ਨੂੰ ਹੋਰ ਵਧਾਉਂਦੇ ਹੋਏ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਟੈਸਟ ਸੂਟ (test suite) ਨੇ ਅਸਲ ਵਿੱਚ ਇਹ ਮੰਨ ਲਿਆ ਸੀ ਕਿ ਸਾਰੇ ਪਤੇ ਵਾਲਾ GET ਰਿਸਪਾਂਸ ਇੱਕ ਉਮੀਦ ਕੀਤੀ ਗਈ ਵਿਵਹਾਰ ਸੀ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਆਟੋਮੇਟਡ ਟੈਸਟ ਇਸ ਲਈ ਪਾਸ ਹੋ ਗਏ ਕਿਉਂਕਿ ਟੈਸਟਿੰਗ ਵਿੱਚ ਵਰਤੇ ਗਏ ਫਿਕਸਚਰਜ਼ (fixtures) ਨੇ ਕਰਾਸ-ਟੈਨੈਂਟ ਐਕਸੈਸ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਸੀ, ਜਿਸ ਨਾਲ ਅਸਲ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਛਿਪ ਗਈ ਸੀ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ, ਇੱਕ ਗ੍ਰੀਨ ਟੈਸਟ ਸੂਟ ਨੇ ਸੁਰੱਖਿਆ ਦਾ ਇੱਕ ਝੂਠਾ ਅਹਿਸਾਸ ਦਿੱਤਾ।
ਕਿਸਦਾ ਫਾਇਦਾ ਹੋਇਆ ਅਤੇ ਕਿਸਦਾ ਨੁਕਸਾਨ
- ਗਾਹਕ: ਉਹਨਾਂ ਦੀ ਨਿੱਜੀ ਪਛਾਣਨਯੋਗ ਜਾਣਕਾਰੀ (PII) – ਪੂਰੇ ਨਾਮ ਅਤੇ ਘਰ ਦੇ ਪਤੇ – ਪਲੇਟਫਾਰਮ 'ਤੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ ਪ੍ਰਗਟ ਹੋ ਗਏ। ਭਾਵੇਂ ਡੇਟਾ ਜਨਤਕ ਤੌਰ 'ਤੇ ਪੋਸਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਇਸ ਉਲੰਘਣਾ ਨੇ ਕਈ ਸਹਿਕਾਰੀ ਸਭਾਵਾਂ ਦੀ ਪ੍ਰਾਈਵੇਸੀ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ।
- CoopCycle ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਸਹਿਕਾਰੀ ਸਭਾਵਾਂ: ਟੈਨੈਂਟ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਕਰਨ ਦੀ ਪਲੇਟਫਾਰਮ ਦੀ ਯੋਗਤਾ 'ਤੇ ਭਰੋਸਾ ਡੋਲ ਗਿਆ। ਕੋਈ ਵੀ ਸਹਿਕਾਰੀ ਸਭਾ ਜਿਸ ਨੇ ਅਜੇ ਤੱਕ ਅੱਪਗ੍ਰੇਡ ਨਹੀਂ ਕੀਤਾ ਸੀ, ਉਸ ਨੂੰ ਲਗਾਤਾਰ ਡੇਟਾ ਪ੍ਰਗਟ ਹੋਣ ਦਾ ਖਤਰਾ ਸੀ।
- CoopCycle ਦੇ ਮੇਨਟੇਨਰਜ਼: ਉਹਨਾਂ ਦੇ ਤੇਜ਼ ਜਵਾਬ – ਦੋ ਦਿਨਾਂ ਦੇ ਅੰਦਰ ਇੱਕ ਪੈਚ ਅਤੇ ਜੋੜੇ ਗਏ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ (regression tests) – ਨੇ ਇਸਦਾ ਫਾਇਦਾ ਉਠਾਉਣ ਦੇ ਸਮੇਂ ਨੂੰ ਸੀਮਤ ਕਰ ਦਿੱਤਾ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਓਪਨ-ਸੋਰਸ ਸਟੈਵਰਡਸ਼ਿਪ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ। ਹਾਲਾਂਕਿ, ਇਹ ਘਟਨਾ ਸੁਰੱਖਿਆ ਦੀ ਸਖ਼ਤ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਲੋੜ ਨੂੰ ਉਜਾਗਰ ਕਰਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਫਰੇਮਵਰਕ-ਡ੍ਰਿਵਨ ਡਿਫਾਲਟਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ।
ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਆਡਿਟਰਾਂ ਨੂੰ ਕਿਸ ਚੀਜ਼ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ
- ਆਪਰੇਸ਼ਨ ਅਸਮਿਤਤਾ (Operation asymmetry): ਜੇਕਰ ਕਿਸੇ ਪਾਥ 'ਤੇ POST (ਜਾਂ ਕੋਈ ਵੀ ਮਿਊਟੇਟਿੰਗ ਆਪਰੇਸ਼ਨ) ਸੁਰੱਖਿਅਤ ਹੈ ਪਰ ਉਸ ਦੇ ਨਾਲ ਸੰਬੰਧਿਤ GET ਖੁੱਲ੍ਹਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਖਤਰੇ ਦਾ ਸੰਕੇਤ ਹੈ। POST ਡਿਵੈਲਪਰਾਂ ਦੇ ਸਰੋਤ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਦੇ ਇਰਾਦੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।
- ਕਲੈਕਸ਼ਨ ਐਂਡਪੁਆਇੰਟਸ (Collection endpoints): ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਸਿੰਗਲ ਆਈਟਮ ਦੀ ਬਜਾਏ ਲਿਸਟ ਵਾਪਸ ਕਰਦੀ ਹੈ, ਉਹ ਅਕਸਰ ਆਮ ਸੁਰੱਖਿਆ ਪੈਟਰਨਾਂ ਤੋਂ ਬਾਹਰ ਹੁੰਦੀ ਹੈ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਬਲਕ ਰੀਡਜ਼ (bulk reads) ਲਈ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਚੈੱਕ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਜੋੜੇ ਗਏ ਹਨ।
- ਟੈਸਟ ਸੂਟ ਦੀ ਅਸਲੀਅਤ: ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਫਿਕਸਚਰਜ਼ ਅਸਲ ਟੈਨੈਂਸੀ ਸੀਮਾਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਇੱਕ ਪਾਸ ਹੋਣ ਵਾਲਾ ਟੈਸਟ ਜੋ ਕਰਾਸ-ਟੈਨੈਂਟ ਡੇਟਾ ਲੀਕੇਜ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਉਹ ਇੱਕ ਚੇਤਾਵਨੀ ਦਾ ਸੰਕੇਤ ਹੈ, ਨਾ ਕਿ ਹਰੀ ਝੰਡੀ।
ਸੁਧਾਰ ਅਤੇ ਅਗਲੇ ਕਦਮ
ਜਦੋਂ ਕਮਜ਼ੋਰੀ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ ਗਈ, ਤਾਂ CoopCycle ਦੀ ਕੋਰ ਟੀਮ ਨੇ GET ਕਲੈਕਸ਼ਨ ਆਪਰੇਸ਼ਨ ਵਿੱਚ ਗੁੰਮ ਹੋਇਆ ਸੁਰੱਖਿਆ ਐਕਸਪ੍ਰੈਸ਼ਨ ਜੋੜ ਦਿੱਤਾ ਅਤੇ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਸ਼ੁਰੂ ਕੀਤੇ ਜੋ ਸਿੰਗਲ-ਆਈਟਮ ਅਤੇ ਕਲੈਕਸ਼ਨ ਦੋਵਾਂ ਐਂਡਪੁਆਇੰਟਸ ਲਈ ਟੈਨੈਂਟ ਆਇਸੋਲੇਸ਼ਨ (tenant isolation) ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਪੈਚ ਸੌਫਟਵੇਅਰ ਦੇ ਅਗਲੇ ਵਰਜ਼ਨ ਵਿੱਚ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ।
CoopCycle ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ ਕਿ:
- ਪੁਸ਼ਟੀ ਕਰਨ ਕਿ ਉਹ ਸੌਫਟਵੇਅਰ ਦਾ ਹਾਲੀਆ ਵਰਜ਼ਨ ਚਲਾ ਰਹੇ ਹਨ।
- ਕਿਸੇ ਵੀ ਕਸਟਮ ਐਕਸਟੈਂਸ਼ਨ ਜਾਂ ਪਲੱਗਇਨ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਜੋ ਸਮਾਨ ਕਲੈਕਸ਼ਨ-ਲੇਵਲ ਦੀਆਂ ਕਮੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
- ਸਾਰੇ API ਰੂਟਾਂ ਵਿੱਚ ਰੀਡ/ਰਾਈਟ ਅਸਮਿਤਤਾ (read/write asymmetries) 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹੋਏ ਸੁਰੱਖਿਆ ਸਕੈਨ ਦੁਬਾਰਾ ਚਲਾਓ।
ਸਿੱਖਿਆ (Takeaway)
ਉਹ ਫਰੇਮਵਰਕ ਜੋ ਸੁਰੱਖਿਆ ਨੂੰ ਡਿਕਲੇਰੇਟਿਵ (declarative) ਬਣਾਉਂਦੇ ਹਨ, ਖ਼ਤਰਨਾਕ ਕਮੀਆਂ ਨੂੰ ਛੁਪਾ ਸਕਦੇ ਹਨ ਜਦੋਂ ਡਿਵੈਲਪਰ ਅਜਿਹੇ ਪੈਟਰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜੋ ਸਿਰਫ਼ ਸਿੰਗਲ ਆਬਜੈਕਟਾਂ ਲਈ ਹੀ ਕੰਮ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਜਾਂਚ—ਕੀ ਕਿਸੇ ਐਂਡਪੁਆਇੰਟ ਦਾ ਰੀਡ ਸਾਈਡ (read side) ਉਹੀ ਗਾਰਡ ਰੱਖਦਾ ਹੈ ਜੋ ਰਾਈਟ ਸਾਈਡ (write side) ਦਾ ਹੈ?—ਕ੍ਰਾਸ-ਟੈਨੈਂਟ ਲੀਕਸ (cross-tenant leaks) ਦੀ ਇੱਕ ਸ਼੍ਰੇਣੀ ਨੂੰ ਪ੍ਰਗਟ ਕਰ ਸਕਦੀ ਹੈ, ਜੋ ਨਹੀਂ ਤਾਂ ਗ੍ਰੀਨ ਟੈਸਟ ਸੂਟਾਂ (green test suites) ਦੇ ਪਿੱਛੇ ਛੁਪੀ ਰਹਿੰਦੀ।