ਨਿਰੰਤਰ ਏਕੀਕਰਨ ਅਤੇ ਨਿਰੰਤਰ ਤੈਨਾਤੀ (CI/CD) pipelineਸੁਚਾਰੂ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਨੂੰ ਸੁਚਾਰੂ ਬਣਾਉਣ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੇ ਹਨ। ਫਿਰ ਵੀ, ਜਿਵੇਂ ਕਿ ਇਹ pipelineਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਜਾ ਰਹੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਬਚਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੋਰ ਵੀ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਡੂੰਘਾਈ ਨਾਲ ਜਾਂਚ OWASP ਟੌਪ-10 ਵਿੱਚ ਪਛਾਣੇ ਗਏ ਇੱਕ ਪ੍ਰਮੁੱਖ ਜੋਖਮ ਨੂੰ ਹੱਲ ਕਰਨ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ। CI/CD ਸੁਰੱਖਿਆ ਜੋਖਮ: ਜ਼ਹਿਰੀਲਾ Pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ (ਪੀਪੀਈ)।
ਜ਼ਹਿਰ ਕੀ ਹੈ? Pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ (ਪੀਪੀਈ)
OWASP ਟੌਪ-10 ਦੇ ਅਨੁਸਾਰ CI/CD ਸੁਰੱਖਿਆ ਜੋਖਮ, "ਜ਼ਹਿਰ Pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ (ਪੀਪੀਈ) ਜੋਖਮ ਇੱਕ ਹਮਲਾਵਰ ਦੀ ਯੋਗਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਕੋਲ ਸਰੋਤ ਨਿਯੰਤਰਣ ਪ੍ਰਣਾਲੀਆਂ ਤੱਕ ਪਹੁੰਚ ਹੈ - ਅਤੇ ਬਿਲਡ ਵਾਤਾਵਰਣ ਤੱਕ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ - ਬਿਲਡ ਵਿੱਚ ਖਤਰਨਾਕ ਕੋਡ/ਕਮਾਂਡਾਂ ਨੂੰ ਇੰਜੈਕਟ ਕਰਕੇ ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਹੇਰਾਫੇਰੀ ਕਰਨ ਲਈ pipeline ਸੰਰਚਨਾ, ਅਸਲ ਵਿੱਚ 'ਜ਼ਹਿਰ' ਦੇਣਾ pipeline ਅਤੇ ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਖਤਰਨਾਕ ਕੋਡ ਚਲਾਉਣਾ"
ਥੋੜ੍ਹੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜ਼ਹਿਰੀਲਾ Pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ (PPE) ਉਦੋਂ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਹਮਲਾਵਰ ਸੋਧ ਸਕਦਾ ਹੈ pipeline ਤਰਕ.
ਦੋ ਹਨ ਰੂਪ:
- ਸਿੱਧਾ PPE (ਡੀ-ਪੀਪੀਈ): ਇੱਕ D-PPE ਦ੍ਰਿਸ਼ ਵਿੱਚ, ਹਮਲਾਵਰ CI ਕੌਂਫਿਗ ਫਾਈਲ ਨੂੰ ਸੋਧਦਾ ਹੈ। ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਉਹਨਾਂ ਕੋਲ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਤਾਂ ਤਬਦੀਲੀ ਨੂੰ ਸਿੱਧੇ ਰੈਪੋ 'ਤੇ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਰਿਮੋਟ ਬ੍ਰਾਂਚ ਵਿੱਚ ਧੱਕ ਕੇ, ਜਾਂ ਇੱਕ ਬ੍ਰਾਂਚ ਜਾਂ ਫੋਰਕ ਤੋਂ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਇੱਕ PR ਜਮ੍ਹਾਂ ਕਰਕੇ। ਕਿਉਂਕਿ ਸੀ.ਆਈ. pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਸੋਧੀ ਹੋਈ CI ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਵਿੱਚ ਕਮਾਂਡਾਂ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਹਮਲਾਵਰ ਦੀਆਂ ਖਤਰਨਾਕ ਕਮਾਂਡਾਂ ਅੰਤ ਵਿੱਚ ਬਿਲਡ ਨੋਡ ਵਿੱਚ ਇੱਕ ਵਾਰ ਚੱਲਦੀਆਂ ਹਨ ਜਦੋਂ ਬਿਲਡ pipeline ਚਾਲੂ ਹੈ.
- ਅਸਿੱਧੇ PPE (ਆਈ-ਪੀਪੀਈ): ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਡੀ-ਪੀਪੀਈ ਦੀ ਸੰਭਾਵਨਾ ਕਿਸੇ ਵਿਰੋਧੀ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੀ ਜਿਸ ਕੋਲ ਇੱਕ ਤੱਕ ਪਹੁੰਚ ਹੋਵੇ SCM ਰਿਪੋਜ਼ਟਰੀ (ਜਿਵੇਂ ਕਿ ਜੇਕਰ pipeline ਨੂੰ ਉਸੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਵੱਖਰੀ, ਸੁਰੱਖਿਅਤ ਸ਼ਾਖਾ ਤੋਂ CI ਸੰਰਚਨਾ ਫਾਈਲ ਖਿੱਚਣ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ)। ਅਜਿਹੇ ਹਾਲਾਤ ਵਿੱਚ, ਜ਼ਹਿਰ ਦੇਣ ਦੀ ਬਜਾਏ pipeline ਆਪਣੇ ਆਪ ਵਿੱਚ, ਇੱਕ ਹਮਲਾਵਰ ਦੁਆਰਾ ਹਵਾਲਾ ਦਿੱਤੀਆਂ ਗਈਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਖਤਰਨਾਕ ਕੋਡ ਇੰਜੈਕਟ ਕਰਦਾ ਹੈ pipeline (ਉਦਾਹਰਣ ਵਜੋਂ: ਦੇ ਅੰਦਰੋਂ ਹਵਾਲਾ ਦਿੱਤੀਆਂ ਗਈਆਂ ਸਕ੍ਰਿਪਟਾਂ pipeline ਸੰਰਚਨਾ ਫਾਈਲ)
ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿਚ, GitHub ਸੋਧੇ ਹੋਏ ਨੂੰ ਲਾਗੂ ਕਰੇਗਾ pipeline ਪਹਿਲਾਂ ਦੀ ਸਮੀਖਿਆ ਜਾਂ ਪ੍ਰਵਾਨਗੀ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ.
ਪੀਪੀਈ ਦਾ ਜਲਦੀ ਪਤਾ ਲਗਾਉਣਾ
ਅਸੀਂ ਇਸ ਕਿਸਮ ਦੀ ਕਮਜ਼ੋਰੀ ਦਾ ਪਤਾ ਕਿਵੇਂ ਲਗਾ ਸਕਦੇ ਹਾਂ?
ਆਓ ਇਸ ਉਦਾਹਰਣ ਨੂੰ ਵੇਖੀਏ। pipeline :
ਅਤੇ ਇੱਕ ਡਮੀ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ (runtests.sh) ਦੀ ਸਮੱਗਰੀ:
The pipeline ਇਹ ਕਾਫ਼ੀ ਸਰਲ ਹੈ: ਇਸਦਾ ਉਦੇਸ਼ ਸਮੀਖਿਅਕ ਨੂੰ ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਸੰਕੇਤ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ Pull Request (PR) ਸਵੀਕ੍ਰਿਤੀ ਪ੍ਰਕਿਰਿਆ:
- ਇਸਨੂੰ ਚਾਲੂ ਕੀਤਾ ਜਾਵੇਗਾ ਪੁੱਲ_ਰਿਕੁਆਇਟ (ਭਾਵ ਜਦੋਂ ਵੀ ਕੋਈ PR ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ)
- ਇਹ ਪੀਆਰ ਕੋਡ (ਭਾਵ ਯੋਗਦਾਨ ਪਾਇਆ ਕੋਡ) ਚੈੱਕਆਉਟ ਕਰਦਾ ਹੈ।
- ਇਹ ਬਿਲਡ ਬਣਾ ਦੇਵੇਗਾ
- ਇਹ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ ਕੋਡ 'ਤੇ ਟੈਸਟ ਚਲਾਏਗਾ (ਜਿਵੇਂ ਕਿ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਨੂੰ ਚਲਾ ਕੇ)
ਕਦਮ #3 (ਬਿਲਡ ਬਣਾਓ) ਅਤੇ #4 (ਟੈਸਟ ਚਲਾਓ) ਅਸਫਲ ਹੋ ਜਾਣਗੇ ਜੇਕਰ ਕੋਡ ਕੰਪਾਇਲ ਨਹੀਂ ਹੁੰਦਾ ਜਾਂ ਇਹ ਟੈਸਟ ਪਾਸ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਲਈ, ਇਹ ਕਦਮ PR ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਇੱਕ ਜ਼ਰੂਰੀ, ਪਰ ਕਾਫ਼ੀ ਨਹੀਂ, ਸ਼ਰਤ ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਰੈਪੋ ਐਡਮਿਨ ਯੋਗਦਾਨ ਪਾਏ ਗਏ ਕੋਡ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧੇਗਾ ਅਤੇ, ਇਸਦੇ ਆਧਾਰ 'ਤੇ, ਉਹ PR ਨੂੰ ਸਵੀਕਾਰ/ਅਸਵੀਕਾਰ/ਟਿੱਪਣੀ ਕਰੇਗਾ।
ਜ਼ਾਇਜੇਨੀ ਸਕੈਨਰ
ਜ਼ਾਇਗੇਨੀ ਇੱਕ CLI ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ("ਜ਼ਾਇਜੇਨੀ ਸਕੈਨਰ”) ਜਿਸਨੂੰ ਇੱਕ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ pipeline ਜਾਂ ਕਮਾਂਡ-ਲਾਈਨ ਵਿੱਚ ਚਲਾਓ। Xygeni ਸਕੈਨਰ ਪ੍ਰਕਿਰਿਆ ਕਰੇਗਾ pipelineਕਮਜ਼ੋਰੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਅਤੇ, ਜੇਕਰ ਇੱਕ GitHub PAT ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ org/repo ਪੱਧਰ 'ਤੇ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਖੋਜਣ ਲਈ GitHub ਨਾਲ ਜੁੜ ਜਾਵੇਗਾ।
ਜ਼ਾਇਗੇਨੀ ਇਨਵੈਂਟਰੀ
ਜਦੋਂ ਅਸੀਂ ਇਸ ਰੈਪੋ 'ਤੇ Xygeni ਸਕੈਨਰ ਚਲਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਸੰਪਤੀਆਂ ਦਾ ਇੱਕ ਉਪਯੋਗੀ ਸਮੂਹ ਖੋਜਦਾ ਹੈ ( ਜ਼ਾਇਗੇਨੀ ਇਨਵੈਂਟਰੀ). ਵਸਤੂ ਸੂਚੀ ਕਈ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਨਾਲ ਭਰੀ ਹੋਵੇਗੀ CI/CD ਜਾਇਦਾਦ, ਜਿਵੇ ਕੀ:
- The SCM ਸਿਸਟਮ ਜਿੱਥੇ ਰੈਪੋ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
- The SCM ਪਲੱਗਇਨ ਸਥਾਪਤ/ਵਰਤਿਆ ਗਿਆ
- The ਕੋਡ ਰਿਪੋਜ਼ਟਰੀ ਆਪਣੇ ਆਪ ਨੂੰ
- The SCM ਸੰਗਠਨ ਰੈਪੋ ਕਿੱਥੇ ਨਾਲ ਸਬੰਧਤ ਹੈ
- The CI/CD Pipelineਐੱਸ ਅਤੇ ਨੌਕਰੀਆਂ
- The CI/CD ਸਿਸਟਮ ਚੱਲ ਰਿਹਾ ਹੈ pipelines
- IaC ਸਰੋਤ ਰਿਪੋ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ
- ਵਿਦੇਸ਼ ਨਿਰਭਰਤਾ
- ਆਦਿ ..
ਸਾਡੀ ਉਦਾਹਰਣ ਵਿੱਚ, ਅਸੀਂ ਵਸਤੂ ਸੂਚੀ ਨੂੰ ਕੁਝ ਖਾਸ ਸੰਪਤੀ ਕਿਸਮ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹਾਂ (SCM- ਅਤੇ CICD-ਸਬੰਧਤ ਸੰਪਤੀਆਂ), ਤਾਂ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ:
- SCM ਸਿਸਟਮ GitHub Cloud ਹੈ
- ਰੈਪੋ GitHub ਕਲਾਉਡ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਖਾਸ GitHub ਸੰਗਠਨ ਨਾਲ ਸਬੰਧਤ ਹੈ।
- ਦੋ ਹਨ pipelineGitHub ਦੁਆਰਾ ਸੰਚਾਲਿਤ (CI/CD ਸਿਸਟਮ)
- ਹਰ pipeline ਇੱਕ ਖਾਸ ਕਦਮ ਸ਼ਾਮਲ ਹੈ
ਉਪਰੋਕਤ ਨੂੰ ਚੁਣ ਕੇ pipeline ਅਸੀਂ ਕੁਝ ਕਮਜ਼ੋਰੀਆਂ ਦੇਖ ਸਕਦੇ ਹਾਂ:
- At pipeline ਪੱਧਰ 'ਤੇ, ਇਹ ਦੋਵਾਂ ਲਈ ਕਮਜ਼ੋਰ ਹੈ ਡਾਇਰੈਕਟ ਅਤੇ ਅਸਿੱਧੇ PPE।
ਅਸੀਂ ਉਨ੍ਹਾਂ ਜ਼ਹਿਰੀਲੇ ਲੋਕਾਂ ਦੇ ਵੇਰਵੇ ਦੇਖ ਸਕਦੇ ਹਾਂ Pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ
ਜ਼ਾਇਗੇਨੀ ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਡੀ-ਪੀਪੀਈ ਲਈ ਕਮਜ਼ੋਰ ਕਿਉਂਕਿ ਇਹ ਇੱਕ 'ਤੇ ਚਾਲੂ ਹੁੰਦਾ ਹੈ Pull Request ਘਟਨਾ ਅਤੇ ਕੋਈ ਵਾਧੂ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਰੈਪੋ ਉਪਭੋਗਤਾ ਸੋਧ ਸਕਦਾ ਹੈ pipeline ਅਤੇ ਉਹ ਸੋਧਾਂ ਬਿਨਾਂ ਕਿਸੇ ਸਮੀਖਿਆ ਜਾਂ ਪ੍ਰਵਾਨਗੀ ਦੇ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ।
ਇਸੇ ਅਰਥ ਵਿੱਚ, ਜ਼ਾਇਗੇਨੀ ਇਹ ਵੀ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਕਿ ਇਹ I-PPE ਲਈ ਕਮਜ਼ੋਰ ਤੋਂ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਨੂੰ ਕਾਲ ਕਰਨ ਕਰਕੇ pipeline: ਕੋਈ ਵੀ ਰੈਪੋ ਉਪਭੋਗਤਾ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸੋਧ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਸੋਧਾਂ ਬਿਨਾਂ ਕਿਸੇ ਸਮੀਖਿਆ ਜਾਂ ਪ੍ਰਵਾਨਗੀ ਦੇ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ।
ਕੀ ਤੁਸੀਂ ਹੋਰ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ?
ਪੀਪੀਈ ਦੀ ਵਰਤੋਂ
ਪੀਪੀਈ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਆਓ ਇੱਕ ਅਜਿਹੇ ਦ੍ਰਿਸ਼ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ ਜਿੱਥੇ ਦੋ ਤਰ੍ਹਾਂ ਦੇ ਰੈਪੋ ਉਪਭੋਗਤਾ:
- An ਅੰਦਰੂਨੀ ਉਪਭੋਗਤਾ (ਉਸ ਰੈਪੋ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਇੱਕ ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਰ), ਰੈਪੋ 'ਤੇ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਨਾਲ
- An ਬਾਹਰੀ ਉਪਭੋਗਤਾ (ਇੱਕ ਆਊਟਸੋਰਸਡ ਡਿਵੈਲਪਰ ਜੋ ਉਸ ਰੈਪੋ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਪਰ ਰੈਪੋ 'ਤੇ ਪੜ੍ਹਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਨਾਲ), ਭਾਵ ਰੈਪੋ ਨੂੰ ਬ੍ਰਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ ਅਤੇ ਫੋਰਕ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਗਿਆ ਹੈ।
ਮੰਨ ਲਓ ਕਿ ਦੋਵੇਂ ਖਤਰਨਾਕ ਹਮਲਾਵਰ ਹਨ (ਜਾਂ ਕਿਸੇ ਖਤਰਨਾਕ ਅਦਾਕਾਰ ਦੁਆਰਾ ਨਕਲ ਕੀਤੇ ਗਏ ਹਨ)। ਰੈਪੋ ਵਿੱਚ ਕੁਝ ਰਾਜ਼ ਹੈ ਅਤੇ ਦੋਵੇਂ ਚਾਹੁੰਦੇ ਹਨ ਰੈਪੋ ਰਾਜ਼ ਚੋਰੀ ਕਰਨ ਲਈ ਅਤੇ ਇਸਨੂੰ ਹੈਕਰ-ਨਿਯੰਤਰਿਤ ਸਰਵਰ ਤੇ ਭੇਜੋ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਉਹ ਜ਼ਹਿਰੀਲੇ ਦਾ ਫਾਇਦਾ ਉਠਾਉਣਗੇ Pipeline ਦੀਆਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ pipeline.
ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ (ਬਾਹਰੀ ਅਤੇ ਅੰਦਰੂਨੀ ਉਪਭੋਗਤਾ), ਉਹ ਇੱਕ ਖੋਲ੍ਹਦੇ ਹਨ Pull Request ਉਹੀ ਸੋਧਾਂ ਦੇ ਨਾਲ:
- The pipeline ਅਤੇ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸੋਧਿਆ ਜਾਂਦਾ ਹੈ ਨੂੰ ਭੇਤ ਪੜ੍ਹੋ ਵਾਤਾਵਰਣ ਤੋਂ ਅਤੇ ਇਸਨੂੰ ਹੈਕਰ-ਨਿਯੰਤਰਿਤ ਸਰਵਰ ਤੇ ਭੇਜੋ
ਸੋਧਾਂ ਇਸ ਪ੍ਰਕਾਰ ਹੋ ਸਕਦੀਆਂ ਹਨ:
ਦੋਵੇਂ ਉਪਭੋਗਤਾ ਇੱਕ ਬਣਾਉਣਗੇ Pull Request ਸੋਧਾਂ ਦੇ ਨਾਲ. ਪੀਆਰ ਦੀ ਸਿਰਜਣਾ 'ਤੇ, GitHub ਦੋਵੇਂ ਸੋਧਾਂ ਨੂੰ ਲਾਗੂ ਕਰੇਗਾ। (ਪਿਛਲੀ ਸਮੀਖਿਆ ਜਾਂ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ), ਜਿਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੇਠ ਲਿਖੇ ਹਨ:
ਲਿਖਣ ਅਤੇ ਪੜ੍ਹਨ ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਵੀ ਇਹੀ ਹੈ, ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ D-PPE ਅਤੇ I-PPE ਨੂੰ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਫ਼ਰਕ ਨਾਲ ਕਿ ਪੜ੍ਹਨ ਵਾਲਾ ਉਪਭੋਗਤਾ ਭੇਦਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ। (!!!!)
ਇਹ ਕਾਰਨ ਹੈ ਕਿਉਂਕਿ, ਫੋਰਕ ਤੋਂ ਆਉਣ ਵਾਲੇ PR ਦੇ ਮਾਮਲੇ ਵਿੱਚ, GitHub ਰੈਪੋ ਸੀਕਰੇਟਸ ਤੱਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਪੜ੍ਹਨ ਵਾਲਾ ਉਪਭੋਗਤਾ ਭੇਦ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦਾ, ਉਹ ਫਿਰ ਵੀ ਕੋਈ ਹੋਰ ਪ੍ਰੋਗਰਾਮ ਚਲਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਆਮ ਹਮਲੇ ਦੀ ਉਦਾਹਰਣ PR ਬਣਾਉਣਾ ਹੈ ਜੋ ਇੱਕ ਕ੍ਰਿਪਟੋ ਮਾਈਨਰ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ GitHub ਦੌੜਾਕ ਜ਼ਹਿਰੀਲੇ ਨੂੰ ਚਲਾਉਣ ਵੇਲੇ ਕ੍ਰਿਪਟੋ ਮਾਈਨਰ ਨੂੰ ਚਲਾਏਗਾ। pipeline.
ਇਹ ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਾਤਾਵਰਣ ਨਹੀਂ ਹੈ, ਬੇਸ਼ੱਕ!! ਇਸ ਤੋਂ ਬਚਣ ਲਈ ਰੈਪੋ ਐਡਮਿਨ ਕੀ ਕਰ ਸਕਦਾ ਹੈ?
ਕੁਝ ਗੂਗਲਿੰਗ ਤੋਂ ਬਾਅਦ, ਰੈਪੋ ਐਡਮਿਨ ਨੇ ਸੋਧਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ pipeline ਇੱਕ 'ਤੇ ਚਾਲੂ ਹੋਣ ਲਈ ਪੁੱਲ_ਰਿਕੁਆਇਟ_ਟਾਰਗੇਟ ਘਟਨਾ। ਕਿਉਂ? ਕਿਉਂਕਿ pipelinepull_request_target 'ਤੇ ਟਰਿੱਗਰ ਕੀਤੇ ਗਏ s ਐਗਜ਼ੀਕਿਊਟਿੰਗ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੇ ਹਨ pipeline ਸੋਧਾਂ, ਭਾਵ ਕਿਸੇ ਵੀ ਉਪਭੋਗਤਾ ਸੋਧ ਦੇ ਬਾਵਜੂਦ "ਮੂਲ" pipeline ਨੂੰ ਫਾਂਸੀ ਦਿੱਤੀ ਜਾਵੇਗੀ।
ਸਾਡੀ ਉਦਾਹਰਣ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ, ਹਮਲਾ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਹੋਵੇਗਾ। ਇਸ ਤੋਂ ਬਾਅਦ ਕੀ ਹੋਵੇਗਾ? pipeline ਸੋਧ?
ਜਿਵੇਂ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੀ, ਡੀ-ਪੀਪੀਈ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਪਰ, ਕਿਉਂਕਿ I-PPE ਅਜੇ ਵੀ ਉੱਥੇ ਹੈ, ਰੀਡ ਯੂਜ਼ਰ ਹੁਣ ਰੈਪੋ ਸੀਕਰੇਟ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ!!!
ਕੀ ਕਾਰਨ ਹੈ ਕਿ ਹੁਣ ਪੜ੍ਹਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਕੋਲ ਗੁਪਤ ਜਾਣਕਾਰੀ ਤੱਕ ਪਹੁੰਚ ਹੈ? ਹਾਲਾਂਕਿ pipeline ਸੋਧਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਫਿਰ ਵੀ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸੋਧਣਾ ਸੰਭਵ ਹੈ। ਜਦੋਂ ਏ pipeline pull_request_target 'ਤੇ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਇਸਨੂੰ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਮੋਡ ਵਿੱਚ ਚਲਾਇਆ ਜਾਵੇਗਾ so ਇਹ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਵੀ ਹੋਵੇਗੀ।, ਜਿਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਨੂੰ ਰੈਪੋ ਸੀਕਰੇਟਸ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ!!
ਰੋਕਥਾਮ ਦੇ ਉਪਾਅ
GitHub ਖਤਰਨਾਕ PRs ਤੋਂ ਬਚਾਅ ਲਈ ਕੁਝ ਉਪਾਅ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
ਸ਼ਾਖਾ ਸੁਰੱਖਿਆ ਨਿਯਮ
GitHub ਨਾਲ ਤੁਸੀਂ ਚੁਣੀਆਂ ਗਈਆਂ ਸ਼ਾਖਾਵਾਂ ਉੱਤੇ ਸ਼ਾਖਾ ਸੁਰੱਖਿਆ ਨਿਯਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ।
ਆਪਣੀਆਂ ਸੁਰੱਖਿਅਤ ਸ਼ਾਖਾਵਾਂ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਨੀਤੀ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਦੀ ਲੋੜ ਹੈ pull request ਮਿਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ (ਨਾਲ ਹੀ ਵਾਧੂ ਸ਼ਰਤਾਂ ਜਿਵੇਂ ਕਿ ਲੋੜੀਂਦੀਆਂ ਪ੍ਰਵਾਨਗੀਆਂ, ਕੋਡ ਮਾਲਕਾਂ ਤੋਂ ਸਮੀਖਿਆਵਾਂ, ਆਦਿ।)
ਕੁਝ ਸ਼ਰਤਾਂ ਜੋ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹਨ:
- "ਨਿਰਧਾਰਤ ਅਦਾਕਾਰਾਂ ਨੂੰ ਲੋੜ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ pull requests".
- "ਉਪਰੋਕਤ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਆਗਿਆ ਨਾ ਦਿਓ।"
ਜਦੋਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਸ਼ਰਤਾਂ ਨੀਤੀ ਵਿੱਚ ਸਖ਼ਤੀ ਜੋੜਦੀਆਂ ਹਨ, ਇਹ ਸ਼ਰਤਾਂ ਨੀਤੀ ਨੂੰ ਢਿੱਲ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਇਸ ਨਾਲ ਖਤਰਨਾਕ ਗਤੀਵਿਧੀਆਂ ਲਈ ਇੱਕ ਖੁੱਲ੍ਹਾ ਦਰਵਾਜ਼ਾ ਖੁੱਲ੍ਹ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਣ ਵਜੋਂ, ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਜਦੋਂ "ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ" ਵਿਅਕਤੀਆਂ ਦੁਆਰਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਚੋਰੀ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
GITHUB_TOKEN ਅਨੁਮਤੀਆਂ ਨੂੰ ਸੀਮਤ ਕਰੋ (ਘੱਟੋ-ਘੱਟ-ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ)
GitHub ਟੋਕਨ ਅਨੁਮਤੀਆਂ ਨੂੰ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਅਨੁਮਤੀਆਂ ਤੱਕ ਹੀ ਸੀਮਤ ਕਰੋ; ਇਸ ਤਰ੍ਹਾਂ, ਭਾਵੇਂ ਹਮਲਾਵਰ ਤੁਹਾਡੇ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨ ਵਿੱਚ ਸਫਲ ਹੋ ਜਾਣ pipeline, ਉਹ ਬਹੁਤਾ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਣਗੇ।
ਵਰਤ ਕੇ ਸਟ੍ਰਿੰਗ ਇੰਟਰਪੋਲੇਸ਼ਨ ਤੋਂ ਬਚੋ pipeline env ਵੇਰੀਏਬਲ
ਜਦੋਂ ਵੀ ਤੁਸੀਂ ਆਪਣੇ ਵਿੱਚ ਕੁਝ ਇਨਪੁੱਟ ਵੇਰੀਏਬਲ ਵਰਤਦੇ ਹੋ pipeline, ਧਿਆਨ ਰੱਖੋ ਕਿ ਉਹਨਾਂ ਨੂੰ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ "ਅਣਭਰੋਸੇਯੋਗ" ਡੇਟਾ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (ਉਨ੍ਹਾਂ ਦੀ ਸਮੱਗਰੀ ਅੰਤਮ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ)। ਵੇਖੋ ਭਰੋਸੇਯੋਗ ਕਾਰਵਾਈਆਂ ਅਤੇ ਵਰਕਫਲੋ ਸੁਰੱਖਿਅਤ ਅਤੇ ਗਿਥਬ ਐਕਸ਼ਨ ਸਿੱਖੋ।
ਤੁਹਾਨੂੰ ਸਟਰਿੰਗ ਇੰਟਰਪੋਲੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਬਜਾਏ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਅੰਦਰ ਇਨਪੁੱਟ ਵੇਰੀਏਬਲ ਪਾਉਣ ਲਈ ਹਮੇਸ਼ਾ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਵਰਕਫਲੋ ਰਨ ਅਤੇ ਪ੍ਰਵਾਨਗੀ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ
ਲਈ ਜਨਤਕ ਰਿਪੋਜ਼, GitHub ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ "ਬਾਹਰੀ" ਪੀਆਰ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ.
GitHub ਸੰਗਠਨ ਸੈਟਿੰਗਾਂ ("ਸੰਗਠਨ >> ਸੈਟਿੰਗਾਂ >> ਕਾਰਵਾਈਆਂ >> ਆਮ") ਬਾਹਰੀ PR ਦਾ ਪ੍ਰਬੰਧਨ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਇਹ ਦੱਸਣ ਦਿਓ:
ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ, GitHub ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲਿਆਂ ਲਈ PR ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਜਿਸ ਨਾਲ ਖਤਰਨਾਕ ਬੇਨਤੀ ਹਮਲੇ ਹੋਰ ਵੀ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਣਗੇ। ਫਿਰ ਵੀ, ਹਮਲਾਵਰ ਕੁਝ ਮਾਸੂਮ ਯੋਗਦਾਨ ਪਾ ਕੇ ਪ੍ਰੋਜੈਕਟ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲਿਆਂ ਦਾ ਵਿਸ਼ਵਾਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। pull request ਅਸਲ ਹਮਲੇ ਤੋਂ ਪਹਿਲਾਂ।
ਇਸ ਅਰਥ ਵਿਚ, ਤੀਜਾ ਵਿਕਲਪ (ਸਾਰੇ ਬਾਹਰੀ ਸਹਿਯੋਗੀਆਂ ਲਈ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ) ਉੱਚ ਪੱਧਰ ਦਾ ਨਿਯੰਤਰਣ ਜੋੜਦਾ ਹੈ।
ਲਈ ਪ੍ਰਾਈਵੇਟ ਰਿਪੋਜ਼, ਗਿੱਟਹੱਬ ਸੰਗਠਨ- ਅਤੇ ਰਿਪੋ-ਪੱਧਰ ਦੋਵਾਂ 'ਤੇ ਮਦਦਗਾਰ ਨਿਯੰਤਰਣ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
"ਇਸ ਤੋਂ ਵਰਕਫਲੋ ਚਲਾਓ Pull Requests” (ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਚੈੱਕ ਨਹੀਂ ਕੀਤਾ ਗਿਆ) ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਫੋਰਕ ਪੀਆਰ ਤੋਂ ਵਰਕਫਲੋ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ (GITHUB_TOKEN ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਅਨੁਮਤੀਆਂ ਦੇ ਨਾਲ ਅਤੇ ਗੁਪਤਤਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ)। ਇਸ ਵਿਕਲਪ ਨੂੰ ਆਖਰੀ ਵਿਕਲਪ ਦੇ ਨਾਲ ਚੁਣ ਕੇ (“ਫੋਰਕ ਪੀਆਰ ਵਰਕਫਲੋ ਲਈ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੈ”), ਤੁਸੀਂ ਪ੍ਰਾਈਵੇਟ ਰਿਪੋਜ਼ ਵਰਗੀ ਨੀਤੀ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹੋ (ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦਿਖਾਇਆ ਗਿਆ ਹੈ)।
ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਇੱਕ ਪੜ੍ਹੇ ਹੋਏ ਉਪਭੋਗਤਾ ਤੋਂ ਪੀਪੀਈ ਸ਼ੋਸ਼ਣ ਵਿੱਚ ਦੇਖਿਆ ਹੈ, ਫੋਰਕ ਤੋਂ ਵਰਕਫਲੋ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦੇ ਰਿਹਾ ਹੈ pull requests ਅਸੁਰੱਖਿਅਤ ਹੈ!!
ਬਾਕੀ ਬਚੇ ਵਿਕਲਪ ("ਫੋਰਕ ਤੋਂ ਵਰਕਫਲੋ ਨੂੰ ਲਿਖਣ ਵਾਲੇ ਟੋਕਨ ਭੇਜੋ pull requests"ਅਤੇ"ਲਈ ਵਰਕਫਲੋ ਨੂੰ ਰਾਜ਼ ਅਤੇ ਵੇਰੀਏਬਲ ਭੇਜੋ pull requests") ਸੁਰੱਖਿਆ ਪੱਧਰ ਘਟਾਓ ਫੋਰਕ ਪੀਆਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ।
ਤੁਸੀਂ ਇਸ ਫੋਰਕ ਨੀਤੀ ਨੂੰ ਸੰਗਠਨ ਪੱਧਰ 'ਤੇ ਜਾਂ ਰੈਪੋ-ਪੱਧਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਨੀਤੀ ਸੰਗਠਨ-ਪੱਧਰ 'ਤੇ ਅਯੋਗ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਰੈਪੋ ਪੱਧਰ 'ਤੇ ਸਮਰੱਥ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਪਰ, ਜੇਕਰ ਨੀਤੀ ਸੰਗਠਨ-ਪੱਧਰ 'ਤੇ ਸਮਰੱਥ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਰੈਪੋ-ਪੱਧਰ 'ਤੇ ਅਯੋਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਖਬਰ
ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ ਕੁਝ ਹੋਣ ਦੇ ਪ੍ਰਭਾਵ ਵੇਖੇ ਹੋਣਗੇ pipeline ਜ਼ਹਿਰ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ Pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ। ਇਹ ਬਹੁਤ ਆਸਾਨ ਹੈ commit ਇੱਕ ਕਮਜ਼ੋਰ pipeline, ਅਤੇ ਸੁਰੱਖਿਅਤ ਲਿਖਣਾ ਮੁਸ਼ਕਲ ਹੈ।
ਇਸ ਲਈ ਅਜਿਹੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਜਾਣੂ ਹੋਣ ਲਈ Xygeni ਸਕੈਨਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਤੁਸੀਂ ਕਿਸੇ ਵਲਨ ਨੂੰ ਉਦੋਂ ਤੱਕ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸਦੀ ਹੋਂਦ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹੋ !!
ਪਰ... ਅਜੇ ਵੀ ਇੱਕ ਸਵਾਲ ਬਾਕੀ ਹੈ... I-PPE ਤੋਂ ਕਿਵੇਂ ਬਚੀਏ?
ਇਹ ਸਾਡੀ ਅਗਲੀ ਪੋਸਟ ਦਾ ਵਿਸ਼ਾ ਹੋਵੇਗਾ 🙂 … ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਜ਼ਹਿਰ ਦਿੱਤਾ ਗਿਆ Pipeline ਐਗਜ਼ੀਕਿਊਸ਼ਨ (I-PPE) !!
