RamenHire ਜੌਬ ਬੋਰਡ ਵਿੱਚ ਇੱਕ ਸਟੋਰਡ (stored) HTML ਇੰਜੈਕਸ਼ਨ ਬੱਗ ਨੇ ਕਿਸੇ ਨੂੰ ਵੀ ਜਨਤਕ ਫਾਰਮ ਭਰਨ ਅਤੇ ਟੀਮ ਦੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਈਮੇਲਾਂ ਨੂੰ ਫਿਸ਼ਿੰਗ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ।
ਇਹ ਬੱਗ ਕਿਵੇਂ ਹੋਇਆ
RamenHire Next.js ਅਤੇ Supabase 'ਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਸਟਾਰਟਅੱਪਸ ਨੂੰ ਬਿਨਾਂ ਲੌਗਇਨ ਕੀਤੇ ਨੌਕਰੀਆਂ ਪੋਸਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਹਰ ਸਬਮਿਸ਼ਨ (submission) ਅੰਦਰੂਨੀ ਹਾਇਰਿੰਗ ਟੀਮ ਨੂੰ ਇੱਕ ਈਮੇਲ ਭੇਜਦਾ ਹੈ। ਈਮੇਲ ਦੀ ਬਾਡੀ (body) ਨੂੰ ਰੋਅ ਫਾਰਮ ਫੀਲਡਾਂ—ਕੰਪਨੀ ਦਾ ਨਾਮ, ਜੌਬ ਡਿਸਕ੍ਰਿਪਸ਼ਨ, ਸੰਪਰਕ ਦਾ ਨਾਮ—ਨੂੰ ਸਿੱਧਾ ਇੱਕ HTML ਸਟ੍ਰਿੰਗ ਵਿੱਚ ਜੋੜ ਕੇ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਸਟ੍ਰਿੰਗ ਮੇਲ ਸਰਵਿਸ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਕੋਈ ਐਸਕੇਪਿੰਗ (escaping) ਜਾਂ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ (sanitisation) ਨਹੀਂ ਹੁੰਦੀ।
ਕਿਉਂਕਿ ਟੈਂਪਲੇਟ ਯੂਜ਼ਰ ਇਨਪੁਟ ਨੂੰ ਸੁਰੱਖਿਅਤ HTML ਵਜੋਂ ਮੰਨਦਾ ਹੈ, ਇੱਕ ਮਾਲੀਸ਼ੀਅਸ (malicious) ਉਮੀਦਵਾਰ ਇੱਕ ਫਰਜ਼ੀ “click here to verify” ਲਿੰਕ ਇੰਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ। ਪੇਲੋਡ (payload) ਸਰਵਰ 'ਤੇ ਜੌਬ ਲਿਸਟਿੰਗ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਅਗਲੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਈਮੇਲ ਵਿੱਚ ਉਹ ਮਾਲੀਸ਼ੀਅਸ ਕੋਡ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਹਮਲਾਵਰ ਉਸ ਲਿੰਕ ਨੂੰ ਅਸਲੀ “View Dashboard” ਬਟਨ ਦੇ ਕੋਲ ਲੁਕਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਟੀਮ ਦੇ ਮੈਂਬਰ ਨੂੰ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ (credentials) ਪ੍ਰਗਟ ਕਰਨ ਜਾਂ ਫਿਸ਼ਿੰਗ ਸਾਈਟ 'ਤੇ ਜਾਣ ਲਈ ਧੋਖਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ
ਇਹ ਈਮੇਲਾਂ ਮੁੱਖ ਹਾਇਰਿੰਗ ਕਰੂ (hiring crew) ਨੂੰ ਜਾਂਦੀਆਂ ਹਨ, ਉਹ ਲੋਕ ਜੋ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਅੱਗੇ ਵਧਾਉਣ ਲਈ ਲਗਾਤਾਰ ਲਿੰਕਾਂ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹਨ।
ਤਕਨੀਕੀ ਕਮੀ
HTML ਨੂੰ ਐਸਕੇਪ ਕਰਨਾ ਕੋਈ ਇੱਕ ਕਦਮ ਨਹੀਂ ਹੈ। ਦੋ ਸੰਦਰਭਾਂ (contexts) ਨੂੰ ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ ਹੈ:
- Text nodes – ਟੈਗਸ ਦੇ ਵਿਚਕਾਰ ਦੀ ਸਮੱਗਰੀ।
<ਨੂੰ<ਵਿੱਚ ਅਤੇ>ਨੂੰ>ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਟੈਗਸ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਪਰ ਇਹ ਹਮਲਾਵਰ ਨੂੰ ਐਟਰੀਬਿਊਟ ਵੈਲਯੂ (attribute value) ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ। - Attribute values – ਟੈਗਸ ਦੇ ਅੰਦਰ ਸਟ੍ਰਿੰਗਾਂ ਜਿਵੇਂ ਕਿ
href="…"। ਇੱਕ ਕੋਟ ("ਜਾਂ') ਇੰਜੈਕਟ ਕਰਨ ਨਾਲ ਹਮਲਾਵਰ ਐਟਰੀਬਿਊਟ ਨੂੰ ਜਲਦੀ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਮਾਰਕਅੱਪ (markup) ਪਾ ਸਕਦਾ ਹੈ।
ਅਸਲੀ ਕੋਡ ਸਿਰਫ਼ ਪਲੇਨ ਟੈਕਸਟ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਸੀ, ਜਿਸ ਨਾਲ ਐਟਰੀਬਿਊਟ ਇੰਜੈਕਸ਼ਨ ਲਈ ਰਸਤਾ ਖੁੱਲ੍ਹਾ ਰਹਿ ਗਿਆ।
ਸਮੱਸਿਆ ਦਾ ਹੱਲ
ਡਿਵੈਲਪਰ ਨੇ ਇੱਕ ਛੋਟਾ escapeHtml ਹੈਲਪਰ ਜੋੜਿਆ ਅਤੇ ਇੰਟਰਪੋਲੇਸ਼ਨ (interpolation) ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਯੂਜ਼ਰ ਦੁਆਰਾ ਦਿੱਤੀ ਗਈ ਵੈਲਯੂ 'ਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕੀਤਾ, ਚਾਹੇ ਉਹ ਵੈਲਯੂ ਟੈਕਸਟ ਨੋਡ ਵਿੱਚ ਜਾਵੇ ਜਾਂ ਐਟਰੀਬਿਊਟ ਵਿੱਚ।
ਵੈਰੀਫਿਕੇਸ਼ਨ ਕਦਮ
- Local testing – ਇੰਜੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਟੈਂਪਲੇਟ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਪਾਇਆ ਗਿਆ। ਹਰ ਟੈਸਟ ਵਿੱਚ ਸਿਰਫ਼ ਐਸਕੇਪ ਕੀਤੇ ਅੱਖਰ ਦਿਖਾਈ ਦਿੱਤੇ, ਕੋਈ ਐਗਜ਼ੀਕਿਊਟੇਬਲ (executable) ਟੈਗ ਨਹੀਂ।
- Production testing – ਪੈਚ (patch) ਨੂੰ ਡਿਪਲੋਏ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਲਾਈਵ ਸਾਈਟ ਰਾਹੀਂ ਇੱਕ ਪੇਲੋਡ ਸਬਮਿਟ ਕੀਤਾ ਗਿਆ, ਜਿਸ ਨੇ Cloudflare Turnstile ਬੋਟ ਚੈੱਕ ਨੂੰ ਪਾਸ ਕਰ ਲਿਆ। ਨਤੀਜੇ ਵਜੋਂ ਮਿਲੀ ਈਮੇਲ ਡਿਵੈਲਪਰ ਦੇ ਇਨਬਾਕਸ ਵਿੱਚ ਪਹੁੰਚੀ; ਮਾਲੀਸ਼ੀਅਸ ਲਿੰਕ ਅਤੇ ਕੋਈ ਵੀ ਸਕ੍ਰਿਪਟ ਟੈਗ ਗੜਬੜੀ ਵਾਲੇ ਟੈਕਸਟ ਵਜੋਂ ਦਿਖਾਈ ਦਿੱਤੇ, ਨਾ ਕਿ ਕਲਿੱਕੇਬਲ ਐਲੀਮੈਂਟਸ ਵਜੋਂ।
Gmail ਬਾਰੇ ਇੱਕ ਨੋਟ: ਸਰਵਿਸ ਅਜੇ ਵੀ URL ਨੂੰ ਨੀਲਾ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਲਿੱਕੇਬਲ ਬਣਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਕਲਾਇੰਟ-ਸਾਈਡ ਦੀ ਸਹੂਲਤ ਹੈ ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ HTML ਇੰਜੈਕਸ਼ਨ ਸਫਲ ਹੋ ਗਿਆ ਹੈ। ਇਹ ਫਿਕਸ ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਅਸਲੀ ਬਟਨ ਬਣਾਉਣ ਜਾਂ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ
- ਜਨਤਕ ਫਾਰਮਾਂ ਤੋਂ ਮਿਲੇ ਡੇਟਾ 'ਤੇ ਕਦੇ ਵੀ ਭਰੋਸਾ ਨਾ ਕਰੋ – ਮਾਸੂਮ ਦਿਖਣ ਵਾਲੇ ਫਾਰਮ ਵੀ ਅਜਿਹਾ ਸਟੋਰਡ ਆਉਟਪੁੱਟ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਕਿਤੇ ਹੋਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
- ਵਰਤੋਂ ਦੇ ਸਮੇਂ ਐਸਕੇਪ ਕਰੋ – ਰੈਂਡਰਿੰਗ (rendering) ਤੋਂ ਬਿਲਕੁਲ ਪਹਿਲਾਂ ਸੰਦਰਭ-ਜਾਣੂ ਐਸਕੇਪਿੰਗ (text vs. attribute) ਲਾਗੂ ਕਰੋ, ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਪਹਿਲਾਂ ਨਹੀਂ।
- ਕਲਾਇੰਟ-ਸਾਈਡ ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਦੋਵਾਂ ਦੀ ਜਾਂਚ ਕਰੋ – ਯੂਨਿਟ ਟੈਸਟ ਸਪੱਸ਼ਟ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ; ਲਾਈਵ UI ਰਾਹੀਂ ਇੱਕ ਮੈਨੂਅਲ ਐਂਡ-ਟੂ-ਐਂਡ ਟੈਸਟ ਇਹ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਦੇ ਹੇਠਾਂ ਰੱਖਿਆ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।
- ਈਮੇਲ ਕਲਾਇੰਟ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੋਂ ਸੁਚੇਤ ਰਹੋ – ਕੁਝ ਕਲਾਇੰਟ URL ਨੂੰ ਆਟੋ-ਲਿੰਕ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਸੁਰੱਖਿਆ ਦਾ ਝੂਠਾ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਅੰਡਰਲਾਈਂਗ HTML ਵਿੱਚ ਕੋਈ ਐਕਟਿਵ ਐਲੀਮੈਂਟ ਨਹੀਂ ਹੈ।
ਨਿਚੋੜ
ਯੂਜ਼ਰ ਇਨਪੁਟ ਨੂੰ ਸੰਭਾਲਣ ਵਿੱਚ ਇੱਕ ਇਕੱਲੀ ਚੁੱਕ ਨੇ ਰੋਜ਼ਾਨਾ ਦੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਈਮੇਲਾਂ ਨੂੰ ਫਿਸ਼ਿੰਗ ਵੈਕਟਰ (phishing vector) ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਇੱਕ ਵਿਆਪਕ HTML-ਐਸਕੇਪਿੰਗ ਰੁਟੀਨ ਲਾਗੂ ਕਰਨ ਅਤੇ ਸਥਾਨਕ (locally) ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਨਾਲ ਇਨਬਾਕਸ ਦੀ ਅਖੰਡਤਾ (integrity) ਬਹਾਲ ਹੋ ਗਈ। ਇਹ ਘਟਨਾ ਕਿਸੇ ਵੀ ਵੈੱਬ ਐਪ ਲਈ ਇੱਕ ਸਦੀਵੀ ਸਬਕ ਦਿੰਦੀ ਹੈ ਜੋ ਅਣਵਿਸ਼ਵਾਸਯੋਗ ਡੇਟਾ ਤੋਂ HTML ਤਿਆਰ ਕਰਦੀ ਹੈ: ਸਹੀ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਦੇ ਇਨਬਾਕਸ ਤੱਕ ਸਿੱਧੀ ਪਹੁੰਚ ਦੇ ਸਕਦਾ ਹੈ।