ਵੈਬਮਾਸਟਰਾਂ ਲਈ ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਖਾਮੀਆਂ ਦੀ ਮੈਨੁਅਲ ਜਾਂਚ ਅਤੇ ਮੁਕਾਉਣ ਦੇ ਤਰੀਕੇ

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਖਾਮੀਆਂ ਦੀ ਮੈਨੁਅਲ ਜਾਂਚ, ਇੱਕ ਵੈਬ ਸਾਈਟ ਦੇ ਫਾਰਮ, URL ਪੈਰਾਮੀਟਰ, ਕੁਕੀਜ਼, ਖੋਜ ਬਾਕਸ ਜਾਂ API ਇਨਪੁੱਟ ਦੀਆਂ ਡੇਟਾਬੇਸ ਪੁੱਛਤਾਛਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀਆਂ ਗੱਲਾਂ ਦੀ ਸਮਰੱਥਾ ਅਤੇ ਅਧਿਕਾਰਿਤ ਢੰਗ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਵੈਬਮਾਸਟਰਾਂ ਲਈ ਉਦੇਸ਼ ਹਮਲਾ ਕਰਨਾ ਨਹੀਂ ਹੈ; ਗਲਤੀ ਦੇ ਸੁਨੇਹੇ, ਅਸਮਾਨਿਆ ਪ੍ਰਤਿਕ੍ਰਿਆ, ਅਣਉਮੀਦ ਫਿਲਟਰਿੰਗ ਵਿਵਹਾਰ ਜਾਂ ਪੁੱਛਤਾਛ ਦੀ ਮੰਤਵ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਜਲਦੀ ਪਛਾਣਨਾ ਹੈ, ਅਤੇ ਫਿਰ ਪੈਰਾਮੀਟਰ ਵਾਲੀਆਂ ਪੁੱਛਤਾਛਾਂ, ਇਨਪੁੱਟ ਦੀ ਪੁਸ਼ਟੀ, ਅਧਿਕਾਰ ਸੀਮਿਤ ਕਰਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਸਰਵਰ ਸੰਰਚਨਾ ਨਾਲ ਖਾਮੀ ਨੂੰ ਸਦਾ ਲਈ ਮੁਕਾਉਣਾ ਹੈ।

ਇਹ ਰਹਨਮਾਈ, ਜੀਵੰਤ ਗਾਹਕ ਡੇਟਾ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾਉਣ ਦੇ ਬਿਨਾਂ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਸੁਰੱਖਿਆ-ਕੇਂਦਰਿਤ ਜਾਂਚ ਦੀ ਸੁਚੀ ਪੇਸ਼ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਜਾਂਚਾਂ ਸਿਰਫ ਆਪਣੇ ਸਾਈਟ 'ਤੇ, ਲਿਖਤੀ ਇਜਾਜ਼ਤ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਜਾਂ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਣ 'ਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਡੇਟਾ ਖਿੱਚਣ, ਪਛਾਣ ਪਾਰ ਕਰਣ, ਟੇਬਲ ਖੋਜਣ ਜਾਂ ਅਧਿਕਾਰ ਤੋਂ ਬਿਨਾਂ ਸਿਸਟਮਾਂ 'ਤੇ ਜਾਂਚ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ। ਇੱਥੇ ਦਾ ਹੰਸਾ; ਲੱਛਣਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ, ਸਬੂਤ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਪੱਧਰ 'ਤੇ ਇਕੱਠਾ ਕਰਨਾ, ਸੁਧਾਰ ਲਾਗੂ ਕਰਨਾ ਅਤੇ ਦੁਬਾਰਾ ਜਾਂਚ ਕਰਨਾ ਹੈ।

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਕੀ ਹੈ ਅਤੇ ਵੈਬਮਾਸਟਰ ਲਈ ਕਿਉਂ ਮਹੱਤਵਪੂਰਕ ਹੈ?

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ, ਉਪਭੋਗਤਾ ਤੋਂ ਆ ਰਹੇ ਡੇਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਅਲੱਗ ਕੀਤੇ ਬਿਨਾਂ ਐਸਕਿਊਐਲ ਪੁੱਛਤਾਛ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਬਣਿਆ ਇੱਕ ਸੁਰੱਖਿਆ ਖਾਮੀ ਹੈ। ਉਦਾਹਰਣ ਲਈ, ਜੇ ਕੋਈ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ, ਜਿਵੇਂ ਖੋਜ, ਫਿਲਟਰਿੰਗ, ਉਤਪਾਦ ਵਿਸਥਾਰ, ਲਾਗਿਨ ਫਾਰਮ, ਆਰਡਰ ਪੁੱਛਤਾਛ ਜਾਂ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਸੂਚੀਕਰਨ ਸਕਰੀਨ ਦੇ ਇਲਾਕਿਆਂ ਵਿੱਚ ਡੇਟਾਬੇਸ ਪੁੱਛਤਾਛ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਖਤਰਾ ਹੈ। ਨਤੀਜਾ; ਡੇਟਾ ਲੀਕ, ਅਧਿਕਾਰਤ ਕਾਰਵਾਈ, ਸਮੱਗਰੀ ਮੈਨਿਪੂਲੇਸ਼ਨ, ਉਪਭੋਗਤਾ ਖਾਤਿਆਂ ਦਾ ਕਬਜ਼ਾ ਜਾਂ ਸਾਈਟ ਦਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਿੱਗ ਜਾਣਾ ਹੋ ਸਕਦਾ ਹੈ।

OWASP ਦੀਆਂ ਸਿਖਰ 10 ਸੂਚੀਆਂ ਵਿੱਚ ਇੰਜੈਕਸ਼ਨ ਸ਼੍ਰੇਣੀ ਸਾਲਾਂ ਤੋਂ ਉੱਚੇ ਪੱਧਰ 'ਤੇ ਹੈ। ਛੋਟੇ ਬਲੌਗ ਤੋਂ ਲੈ ਕੇ ਈ-ਕਾਮਰਸ ਢਾਂਚੇ ਤੱਕ ਹਰ ਪੱਧਰ ਦੇ ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੇ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ PHP ਐਪਲੀਕੇਸ਼ਨਾਂ, ਅਪਡੇਟ ਨਾ ਕੀਤੇ ਗਏ ਐਡ-ਇਨ, ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਲਿਖੇ ਗਏ ਐਡਮਿਨ ਪੈਨਲ, ਗਲਤ ORM ਦੀ ਵਰਤੋਂ ਅਤੇ ਲਾਗਿਨ ਨਾ ਕੀਤੇ API ਸਿਰੇ ਖਤਰੇ ਵਿੱਚ ਹਨ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਹੋਸਟਿੰਗ ਪੱਧਰ ਇਸ ਖਤਰੇ ਨੂੰ ਸਿਰਫ਼ ਪ੍ਰਧਾਨ ਨਹੀਂ ਕਰਦਾ; ਪਰ ਅਪਡੇਟ ਕੀਤੇ PHP ਵਰਜਨ, ਅਲੱਗ ਹੋਸਟਿੰਗ ਖਾਤੇ, WAF, ਨਿਯਮਿਤ ਬੈਕਅਪ ਅਤੇ SSL ਵਰਗੇ ਨਿਯੰਤਰਣ ਨੁਕਸਾਨ ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ। ਇਸ ਪੈਰਾਏ ਵਿੱਚ, ਆਪਣੀ ਢਾਂਚਾ ਨੂੰ ਮੁੜ ਦੇਖਣ ਲਈ ਵੈਬ ਹੋਸਟਿੰਗ ਅਤੇ SSL ਸਰਟੀਫਿਕੇਟ ਪੇਜਾਂ ਨੂੰ ਕੁੱਝ ਕੁਸ਼ਲਤਾ ਦੇ ਤੌਰ 'ਤੇ ਦੇਖਣਾ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।

ਮੈਨੁਅਲ ਜਾਂਚ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਤਿਆਰੀ

ਮੈਨੁਅਲ ਜਾਂਚ ਦੀ ਗੁਣਵੱਤਾ, ਤਿਆਰੀ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਬੰਧਿਤ ਹੈ। ਬੇਰੁਜ਼ਗਾਰ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰਨ ਦੇ ਬਜਾਏ, ਦਾਇਰਾ, ਵਾਤਾਵਰਣ, ਰਿਕਾਰਡ ਅਤੇ ਵਾਪਸੀ ਦੀ ਯੋਜਨਾ ਨਿਸ਼ਚਿਤ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਜੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਭਾਵ ਅਤੇ ਗਲਤ ਪਾਜ਼ੀਟਿਵਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਇਹ ਹੈ ਕਿ ਇਹ ਸਟੇਜਿੰਗ ਕਾਪੀ ਵਿੱਚ ਜਾਂਚ ਕੀਤੀ ਜਾਵੇ ਜਿਸ ਵਿੱਚ ਸੇਮ ਕੋਡ ਅਤੇ ਸਮਾਨ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਹੋਵੇ।

1. ਦਾਇਰਾ ਅਤੇ ਅਧਿਕਾਰ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ

• ਜਾਂਚ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਡੋਮੇਨ, ਸਬਡੋਮੇਨ, ਪੈਨਲ ਅਤੇ API ਸਿਰੇ ਦੀ ਸੂਚੀ ਬਣਾਓ।
• ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਅਧਿਕਾਰ ਨਹੀਂ ਰੱਖਦੇ ਉਹ ਤੀਜੀ ਪਾਰਟੀ ਸੇਵਾਵਾਂ ਨੂੰ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
• ਜਾਂਚ ਦੇ ਸਮੇਂ ਨੂੰ ਘੱਟ ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਸਮੇਂ ਵਿੱਚ ਰੱਖੋ।
• ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਡੇਟਾ ਬਦਲਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਜਾਂਚ ਯੂਜ਼ਰ ਅਤੇ ਜਾਂਚ ਡੇਟਾ ਨਾਲ ਸੀਮਿਤ ਰੱਖੋ।
• ਗਲਤੀ ਦੇ ਸਮੇਂ ਵਿੱਚ ਵਾਪਸ ਆਉਣ ਲਈ ਤੁਹਾਡੇ ਕੋਲ ਬੈਕਅਪ ਅਤੇ ਪਹੁੰਚ ਜਾਣਕਾਰੀਆਂ ਤਿਆਰ ਰੱਖੋ।

ਜੇ ਕੋਈ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਡੋਮੇਨ, DNS ਅਤੇ ਹੋਸਟਿੰਗ ਬਦਲਣ ਦੇ ਦੌਰਾਨ ਸੁਰੱਖਿਆ ਜਾਂਚ ਨੂੰ ਮੌਕਾ ਨਾ ਦਿਓ। ਜਾਰੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਡੋਮੇਨ ਪੁੱਛਤਾਛ ਅਤੇ Linux ਹੋਸਟਿੰਗ ਵਰਗੇ ਢਾਂਚਾ ਪਦਾਂ ਦੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕੋਡ ਜਾਂਚ ਵੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

2. ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇਨਪੁੱਟ ਨਕਸ਼ਾ ਬਣਾਓ

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਡੇਟਾ ਭੇਜਣ ਵਾਲੇ ਸਥਾਨਾਂ 'ਤੇ ਲੱਗਦੀ ਹੈ। ਇਸ ਲਈ ਪਹਿਲਾਂ ਸਤਹ ਦੀ ਨਕਸ਼ਾ ਬਣਾਓ। ਹੇਠਾਂ ਦਿੱਤੇ ਖੇਤਰਾਂ ਨੂੰ ਇੱਕ ਇੱਕ ਕਰਕੇ ਨੋਟ ਕਰੋ: URL ਪੈਰਾਮੀਟਰ, POST ਫਾਰਮ, ਖੋਜ ਬਾਕਸ, ਸ਼੍ਰੇਣੀ ਫਿਲਟਰ, ਕ੍ਰਮ ਪੈਰਾਮੀਟਰ, ਕਾਰਟ ਅਤੇ ਆਰਡਰ ਖੇਤਰ, ਉਪਭੋਗਤਾ ਪ੍ਰੋਫਾਈਲ, ਟਿੱਪਣੀ ਫਾਰਮ, ਐਡਮਿਨ ਪੈਨਲ ਸੂਚੀਆਂ, JSON API ਬੋਡੀ, HTTP ਹੈਡਰ ਅਤੇ ਕੁਕੀਜ਼। ਹਰ ਖੇਤਰ ਲਈ ਉਮੀਦ ਕੀਤੀ ਡੇਟਾ ਕਿਸਮ ਲਿਖੋ। ਉਦਾਹਰਣ ਲਈ, id ਸੰਖਿਆਵਾਦੀ ਹੈ, slug ਲਿਖਤ ਹੈ, ਮਿਤੀ ਖੇਤਰ ਨੂੰ ਨਿਰਧਾਰਤ ਫਾਰਮੈਟ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕ੍ਰਮ ਸਿਰਫ਼ ਅਨੁਮਤ ਕਾਲਮਾਂ ਵਿੱਚੋਂ ਚੁਣਿਆ ਜਾ ਰਿਹਾ ਹੈ?

3. ਲਾਗਿੰਗ ਅਤੇ ਬੈਕਅਪ ਨੂੰ ਖੋਲ੍ਹੋ

ਜਾਂਚ ਦੌਰਾਨ ਐਪਲੀਕੇਸ਼ਨ ਲਾਗ, ਵੈਬ ਸਰਵਰ ਪਹੁੰਚ ਲਾਗ ਅਤੇ ਡੇਟਾਬੇਸ ਗਲਤੀ ਲਾਗ ਕੀਮਤੀ ਸਬੂਤ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਵਿਸਥਾਰਿਤ ਡੇਟਾਬੇਸ ਗਲਤੀਆਂ ਨੂੰ ਉਪਭੋਗਤਾ ਨੂੰ ਦਿਖਾਉਣਾ ਗਲਤ ਹੈ। ਸਹੀ ਐਪਲੀਕੇਸ਼ਨ; ਗਲਤੀ ਨੂੰ ਉਪਭੋਗਤਾ ਨੂੰ ਆਮ ਸੁਨੇਹੇ ਨਾਲ ਦਿਖਾਉਣਾ, ਵਿਸਥਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਲਾਗ ਚੈਨਲ ਵਿੱਚ ਲਿਖਣਾ ਹੈ। ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਅਪਡੇਟ ਬੈਕਅਪ ਲਓ। ਨਾਜ਼ੁਕ ਸਾਈਟਾਂ 'ਤੇ ਫਾਈਲ ਬੈਕਅਪ, ਡੇਟਾਬੇਸ ਬੈਕਅਪ ਅਤੇ ਸੰਰਚਨਾ ਬੈਕਅਪ ਨੂੰ ਅਲੱਗ ਅਲੱਗ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ। Hostragons ਪਾਸੇ, ਤੁਸੀਂ ਆਪਣੇ ਵਰਤੇ ਗਏ ਢਾਂਚੇ ਦੇ ਅਨੁਸਾਰ ਬੈਕਅਪ ਯੋਜਨਾ ਨੂੰ ਹੋਸਟਿੰਗ ਬੈਕਅੱਪ ਸਮੱਗਰੀ ਨਾਲ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ।

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਖਾਮੀਆਂ ਦੀ ਮੈਨੁਅਲ ਜਾਂਚ: ਕਦਮ ਬਾਈ ਕਦਮ ਜਾਂਚ ਸੂਚੀ

ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮ, ਨਿਰਪੱਖ ਨਜ਼ਰ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਨ ਦੇ ਤਰਕ 'ਤੇ ਅਧਾਰਿਤ ਹਨ। ਉਦੇਸ਼ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਨਹੀਂ ਹੈ; ਇੱਕ ਇਨਪੁੱਟ ਦੀ ਪੁੱਛਤਾਛ ਮੰਤਵ ਨੂੰ ਖ਼ਰਾਬ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਸਮਝਣਾ ਹੈ। ਹਰ ਜਾਂਚ ਵਿੱਚ ਪਹਿਲਾਂ ਆਮ ਵਿਵਹਾਰ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ, ਫਿਰ ਸਿਰਫ਼ ਛੋਟੇ ਅਤੇ ਵਾਪਸ ਲੈਣਯੋਗ ਬਦਲਾਅ ਨਾਲ ਪ੍ਰਤਿਕ੍ਰਿਆ ਦੇ ਅੰਤਰ ਨੂੰ ਦੇਖੋ।

ਕਦਮ 1: ਆਮ ਪ੍ਰਤਿਕ੍ਰਿਆ ਨੂੰ ਸੰਦਰਭ ਬਣਾਓ

ਇੱਕ ਉਤਪਾਦ ਵਿਸਥਾਰ ਪੰਨਾ, ਖੋਜ ਫਾਰਮ ਜਾਂ ਉਪਭੋਗਤਾ ਫਿਲਟਰਿੰਗ ਸਕਰੀਨ ਚੁਣੋ। ਆਮ ਪੈਰਾਮੀਟਰ ਨਾਲ ਪੰਨੇ ਦੇ HTTP ਸਥਿਤੀ ਕੋਡ, ਪ੍ਰਤਿਕ੍ਰਿਆ ਸਮਾਂ, ਰਿਕਾਰਡਸ ਦੀ ਗਿਣਤੀ, ਪੰਨਾ ਦਾ ਸਿਰਲੇਖ ਅਤੇ ਸਕਰੀਨ 'ਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਸੁਨੇਹਾ ਨੋਟ ਕਰੋ। ਉਦਾਹਰਣ ਲਈ, ਜੇ ਉਤਪਾਦ ਪੰਨਾ 200 ਦਾ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ, 120 ਮਿ.ਸੈਕਿੰਡ ਵਿੱਚ ਖੁਲ ਰਿਹਾ ਹੈ ਅਤੇ ਇੱਕ ਉਤਪਾਦ ਦਿਖਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਹ ਤੁਹਾਡਾ ਸੰਦਰਭ ਬਣ ਜਾਵੇਗਾ। ਬਿਨਾਂ ਸੰਦਰਭ ਦੇ ਕੀਤੀ ਗਈ ਜਾਂਚਾਂ ਵਿੱਚ ਹਰ ਮੰਦਤਾ ਜਾਂ ਗਲਤੀ ਗਲਤੀ ਨਾਲ ਖਾਮੀ ਸਮਝੀ ਜਾ ਸਕਦੀ ਹੈ।

ਕਦਮ 2: ਕਿਸਮ ਦੀ ਅਸਮਰਥਤਾ ਅਤੇ ਸਧਾਰਣ ਅਲੱਗ ਕਰਨ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰੋ

ਜਦੋਂ ਸੰਖਿਆਵਾਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾ ਰਹੀ ਖੇਤਰ ਵਿੱਚ ਲਿਖਤੀ ਮੁੱਲ, ਲਿਖਤੀ ਉਮੀਦ ਕੀਤੀ ਜਾ ਰਹੀ ਖੇਤਰ ਵਿੱਚ ਅਣਉਮੀਦਿਤ ਵਿਸ਼ੇਸ਼ ਅੱਖਰ, ਮਿਤੀ ਉਮੀਦ ਕੀਤੀ ਜਾ ਰਹੀ ਖੇਤਰ ਵਿੱਚ ਵੱਖਰੇ ਫਾਰਮੈਟ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ? ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਤਾਂ ਇਨਪੁੱਟ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ ਜਾਂ ਨਿਯੰਤਰਿਤ ਗਲਤੀ ਵਾਪਸ ਕਰਦੀ ਹੈ। ਖਤਰਨਾਕ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾਬੇਸ ਗਲਤੀ ਸੁਨੇਹਾ ਸਕਰੀਨ 'ਤੇ ਪ੍ਰਿੰਟ ਕਰ ਸਕਦੀ ਹੈ, ਰਿਕਾਰਡਸ ਦੀ ਗਿਣਤੀ ਬਦਲ ਸਕਦੀ ਹੈ ਜਾਂ ਪੰਨੇ ਦੀ ਸੰਰਚਨਾ ਨੂੰ ਖ਼ਰਾਬ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਥੇ ਧਿਆਨ ਦੇਣ ਵਾਲੀ ਗੱਲ ਹੈ ਗਲਤੀ ਸੁਨੇਹੇ ਦਾ ਸਮੱਗਰੀ। ਜੇਕਰ SQL ਦੇ ਗ੍ਰਾਮਰ, ਟੇਬਲ ਦਾ ਨਾਮ, ਕਾਲਮ ਦਾ ਨਾਮ, ਡ੍ਰਾਈਵਰ ਦਾ ਨਾਮ ਜਾਂ ਪੁੱਛਤਾਛ ਦਾ ਹਿੱਸਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜਾਣਕਾਰੀ ਦੀ ਲੀਕ ਹੋ ਰਹੀ ਹੈ ਅਤੇ ਇੰਜੈਕਸ਼ਨ ਨਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਇਸਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਦਮ 3: ਪ੍ਰਤਿਕ੍ਰਿਆ ਦੇ ਅੰਤਰ ਨੂੰ ਪਛਾਣੋ

ਕੁਝ ਖਾਮੀਆਂ ਸਿੱਧਾ ਗਲਤੀ ਨਹੀਂ ਪੈਦਾ ਕਰਦੀਆਂ; ਸਿਰਫ਼ ਪੰਨੇ 'ਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਨਤੀਜਾ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਣ ਲਈ, ਜੇਕਰ ਇੱਕ ਹੀ ਫਿਲਟਰ ਖੇਤਰ ਵਿੱਚ ਆਮ ਹਾਲਤ ਵਿੱਚ 3 ਉਤਪਾਦ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਜਦੋਂ ਛੋਟੇ ਮੰਤਵ ਬਦਲਾਅ ਦੇ ਬਾਅਦ ਨਤੀਜਿਆਂ ਦੀ ਗਿਣਤੀ ਅਣਉਮੀਦਿਤ ਤੌਰ 'ਤੇ ਵਧ ਜਾਂਦੀ ਹੈ ਜਾਂ ਖਾਲੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪੁੱਛਤਾਛ ਉਪਭੋਗਤਾ ਦੇ ਇਨਪੁੱਟ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਪਦਵੀ ਵਿੱਚ, ਡੇਟਾ ਖਿੱਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੇ ਬਗ਼ੈਰ, ਸਿਰਫ਼ ਪ੍ਰਤਿਕ੍ਰਿਆ ਦੇ ਅੰਤਰ ਨੂੰ ਨੋਟ ਕਰੋ। ਸੁਰੱਖਿਅਤ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਪੈਰਾਮੀਟਰ ਦੇ ਤੌਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਵਿਸ਼ੇਸ਼ ਅੱਖਰ ਪੁੱਛਤਾਛ ਦੇ ਮੰਤਵ ਨੂੰ ਬਦਲਦੇ ਨਹੀਂ; ਸਿਰਫ਼ ਖੋਜੀ ਗਈ ਲਿਖਤ ਦਾ ਇੱਕ ਹਿੱਸਾ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ।

ਕਦਮ 4: ਗਲਤੀ ਦੇ ਸੁਨੇਹੇ ਅਤੇ HTTP ਕੋਡਾਂ ਦੀ ਜਾਂਚ ਕਰੋ

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਦਾ ਲੱਛਣ ਹਮੇਸ਼ਾ ਸਕਰੀਨ 'ਤੇ ਪੈਦਾਹ ਹੋਣ ਵਾਲੀ ਗਲਤੀ ਨਹੀਂ ਹੁੰਦਾ। ਕਈ ਵਾਰੀ 500 ਦੀ ਗਲਤੀ, ਖਾਲੀ ਸਾਫ਼ ਪੰਨਾ, ਵੱਖਰੀ ਦਿਸ਼ਾ, ਅਣਉਮੀਦਿਤ 403 ਜਵਾਬ ਜਾਂ ਲੰਬੀ ਚਾਲ ਦੀ ਲੋੜ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਜੇਕਰ ਵੈਬ ਸਰਵਰ ਲਾਗਾਂ ਵਿੱਚ ਉਸੇ ਅਰਜ਼ੀ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ ਵਿਸ਼ੇਸ਼ਤਾ ਪੈਦਾ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਸੰਬੰਧਤ ਕੋਡ ਬਲਾਕ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ ਹੇਠਲੀਆਂ ਸ਼ਬਦਾਵਲੀ ਖਤਰੇ ਦੇ ਸੰਕੇਤ ਹੋ ਸਕਦੀ ਹੈ: ਡੇਟਾਬੇਸ ਗਲਤੀ, SQL ਗ੍ਰਾਮਰ, ਅਣਜਾਣ ਕਾਲਮ, ਬੰਦ ਨਾ ਕੀਤੀ ਗਈ ਉਲੰਘਣਾ, PDO ਥਾਪਣਾ, MySQL ਗਲਤੀ, PostgreSQL ਗਲਤੀ ਜਾਂ ORM ਪੁੱਛਤਾਛ ਦੀਆਂ ਗਲਤੀਆਂ। ਉਤਪਾਦਨ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਵੇਰਵਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਦਿਖਾਉਣ ਤੋਂ ਬੰਦ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਕਦਮ 5: API ਅਤੇ AJAX ਸਿਰਿਆਂ ਨੂੰ ਨਾ ਭੁੱਲੋ

ਆਧੁਨਿਕ ਸਾਈਟਾਂ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਪੁੱਛਤਾਛਾਂ ਦਿਖਾਈ ਦੇ ਰਹੀਆਂ ਸਾਈਟ ਦੇ ਬਜਾਏ ਪਿਛੇ ਦੇ API ਸਿਰਿਆਂ ਤੋਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਆਪਣੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿਕਾਸਕ ਸੰਦਾਂ ਵਿੱਚ ਨੈੱਟਵਰਕ ਟੈਬ ਖੋਲ੍ਹ ਕੇ JSON ਬੁੱਕੀਆਂ, ਫਿਲਟਰਿੰਗ ਐਂਡਪਾਇੰਟਾਂ ਅਤੇ ਐਡਮਿਨ ਪੈਨਲ AJAX ਕਾਲਾਂ ਦੀ ਜਾਂਚ ਕਰੋ। API ਪਾਸੇ ਵੀ ਇੱਕੋ ਹੀ ਸੁਰੱਖਿਆ ਅਸੂਲ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਡੇਟਾ ਕਿਸਮ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਨੁਮਤ ਮੁੱਲਾਂ ਦੀ ਸੂਚੀ ਲਾਗੂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਪੈਰਾਮੀਟਰ ਵਾਲੀਆਂ ਪੁੱਛਤਾਛਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਗਲਤੀ ਦੀ ਆਉਟਪੁੱਟ ਨੂੰ ਸਾਦਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। API ਸੁਰੱਖਿਆ ਨਾਲ ਸੰਬੰਧਿਤ ਵੱਡੇ ਨਿਯੰਤਰਣਾਂ ਲਈ API ਸੁਰੱਖਿਆ ਸਮੱਗਰੀ ਨੂੰ ਜੁੜਨ ਲਈ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ।

ਕਦਮ 6: ਅਧਿਕਾਰਾਂ ਦੀ ਜਾਂਚ ਨੂੰ ਐਸਕਿਊਐਲ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ ਮਿਲਾਕੇ ਜਾਂਚੋ

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਸਿਰਫ਼ ਪੁੱਛਤਾਛ ਲਿਖਣ ਨਾਲ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹੈ; ਅਧਿਕਾਰਾਂ ਦੀ ਡਿਜ਼ਾਈਨ ਵੀ ਮਹੱਤਵਪੂਰਕ ਹੈ। ਜੇ ਇੱਕ ਉਪਭੋਗਤਾ ਸਿਰਫ਼ ਆਪਣੇ ਆਰਡਰਾਂ ਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ ਪਰ id ਪੈਰਾਮੀਟਰ ਬਦਲਣ 'ਤੇ ਹੋਰ ਆਰਡਰਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਿੱਧਾ ਇੰਜੈਕਸ਼ਨ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਪਰ ਇਹ ਇੱਕ ਗੰਭੀਰ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਦੀ ਖਾਮੀ ਹੈ। ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨ, ਪੁੱਛਤਾਛ ਵਿੱਚ ਉਪਭੋਗਤਾ id ਜਾਣਕਾਰੀ ਨੂੰ ਸਰਵਰ ਪਾਸੇ ਦੀ ਸੈਸ਼ਨ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਗਾਹਕ ਤੋਂ ਆ ਰਹੀ id ਮੁੱਲ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਹ ਜਾਂਚ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਗਾਹਕ ਪੈਨਲ, ਬਿਲ, ਸਹਾਇਤਾ ਬੇਨਤੀ ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਸਿਸਟਮਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਕ ਹੈ।

ਮੈਨੁਅਲ ਜਾਂਚ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਕਿਵੇਂ ਸਮਝਣਾ ਹੈ?

ਇੱਕ ਲੱਛਣ ਦੇ ਅਸਲ ਖਾਮੀ ਹੋਣ ਦਾ ਸਮਝਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਦੋ ਸਬੂਤਾਂ ਦੀ ਭਾਲ ਕਰੋ: ਪ੍ਰਤਿਕ੍ਰਿਆ ਦਾ ਅੰਤਰ ਅਤੇ ਲਾਗ ਰਿਕਾਰਡ। ਇੱਕ ਮਾਤਰ 500 ਦੀ ਗਲਤੀ ਹਮੇਸ਼ਾ ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਦਾ ਮਤਲਬ ਨਹੀਂ ਹੈ; ਫਾਈਲ ਦੀ ਆਗਿਆ, ਯਾਦਾਸ਼ਤ ਸੀਮਾ ਜਾਂ ਐਡ-ਇਨ ਟਕਰਾਅ ਵੀ ਹੋ ਸਕਦੇ ਹਨ। ਪਰ ਜੇਕਰ ਡੇਟਾਬੇਸ ਗਲਤੀ ਨਾਲ ਉਪਭੋਗਤਾ ਦੇ ਇਨਪੁੱਟ ਇੱਕੋ ਹੀ ਸਥਾਨ 'ਤੇ ਸੂਚਿਤ ਕਰਦੇ ਹਨ, ਤਾਂ ਪ੍ਰਾਥਮਿਕਤਾ ਉੱਚੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਖਾਮੀਆਂ ਨੂੰ ਮੁਕਾਉਣ ਦੇ ਤਰੀਕੇ

ਸਥਾਈ ਹੱਲ, ਇਕਲਾ ਸੁਰੱਖਿਆ ਐਡ-ਇਨ ਇੰਸਟਾਲ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਠੀਕ ਹੱਲ ਪਾਸ ਦੇ ਹਨ: ਸੁਰੱਖਿਅਤ ਕੋਡ, ਸੀਮਿਤ ਡੇਟਾਬੇਸ ਖਾਤਾ, ਮਜ਼ਬੂਤ ਗਲਤੀ ਪ੍ਰਬੰਧਨ, ਅਪਡੇਟ ਕੀਤੀ ਢਾਂਚਾ, ਨਿਗਰਾਨੀ ਅਤੇ ਨਿਯਮਿਤ ਜਾਂਚ ਇਕੱਠੇ ਲਾਗੂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

1. ਪੈਰਾਮੀਟਰ ਵਾਲੀ ਪੁੱਛਤਾਛ ਅਤੇ ਪ੍ਰੀਪੇਅਰਡ ਸਟੇਟਮੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਸਭ ਤੋਂ ਆਧਾਰਭੂਤ ਸੁਰੱਖਿਆ ਇਹ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਨੂੰ ਐਸਕਿਊਐਲ ਪਾਠ ਵਿੱਚ ਸ਼ਾਮਲ ਨਾ ਕੀਤਾ ਜਾਵੇ। PHP PDO ਉਦਾਹਰਣ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਇਹ ਹੈ: `prepare` ਨਾਲ ਪੁੱਛਤਾਛ ਟੈਮਪਲੇਟ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਉਪਭੋਗਤਾ ਡੇਟਾ `execute` ਪੜਾਅ ਦੇ ਦੌਰਾਨ ਪੈਰਾਮੀਟਰ ਦੇ ਤੌਰ 'ਤੇ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਣ: `$stmt = $pdo->prepare('SELECT id, title FROM posts WHERE slug = ?'); $stmt->execute([$slug]);`। ਇਸ ਤਰੀਕੇ 'ਚ ਡੇਟਾਬੇਸ, ਇਨਪੁੱਟ ਨੂੰ ਹੁਕਮ ਨਹੀਂ, ਸਗੋਂ ਡੇਟਾ ਦੇ ਤੌਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ORM ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਵੀ ਧਿਆਨ ਰੱਖੋ। Laravel, Symfony, Django ਜਾਂ ਸਮਾਨ ਢਾਂਚਿਆਂ ਵਿੱਚ ਸਟੈਂਡਰਡ ਕਵੈਰੀ ਬਿਲਡਰ ਬਹੁਤ ਸਾਰੀਆਂ ਹਾਲਤਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ; ਪਰ ਜਦੋਂ ਰਾ ਕਵੈਰੀ ਲਿਖੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਖਤਰਾ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਰਾ SQL ਅਨਿਵਾਰਯ ਹੈ ਤਾਂ ਪੈਰਾਮੀਟਰ ਬਾਂਧਣ ਦੀ ਵਰਤੋਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਤਰ ਨੂੰ ਜੋੜਨਾ ਨਹੀਂ ਚਾਹੀਦਾ।

2. ਇਨਪੁੱਟ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਅਨੁਮਤ ਸੂਚੀ ਲਾਗੂ ਕਰੋ

ਪੈਰਾਮੀਟਰ ਵਾਲੀ ਪੁੱਛਤਾਛ ਮੁੱਖ ਸੁਰੱਖਿਆ ਹੈ; ਪਰ ਪ੍ਰਮਾਣਿਕਤਾ ਦੂਜਾ ਮਜ਼ਬੂਤ ਪੱਧਰ ਹੈ। id ਖੇਤਰ ਸਿਰਫ ਪੌਜ਼ੀਟਿਵ ਪੂਰਨ ਸੰਖਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਮਿਤੀ ISO ਫਾਰਮੈਟ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਈ-ਮੇਲ ਖੇਤਰ ਨੂੰ ਈ-ਮੇਲ ਫਾਰਮੈਟ ਦੇ ਅਨੁਸਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕ੍ਰਮ ਪੈਰਾਮੀਟਰ ਸਿਰਫ਼ ਅਨੁਮਤ ਕਾਲਮਾਂ ਵਿੱਚੋਂ ਚੁਣਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ `order by` ਵਰਗੇ ਕਾਲਮ ਨਾਮ ਜਾਂ ਦਿਸ਼ਾ ਦਰਸਾਉਣ ਵਾਲੇ ਖੇਤਰਾਂ ਵਿੱਚ ਪੈਰਾਮੀਟਰ ਬਾਂਧਣ ਹਮੇਸ਼ਾ ਯਥੇਸ਼ਟ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਨੁਮਤ ਸੂਚੀ ਦੀ ਵਰਤੋਂ ਕਰੋ: ਉਦਾਹਰਣ ਵਜੋਂ, ਕ੍ਰਮ ਸਿਰਫ਼ price, created_at ਅਤੇ title ਹੋ ਸਕਦਾ ਹੈ; ਦਿਸ਼ਾ asc ਜਾਂ desc ਨਾਲ ਸੀਮਿਤ ਹੁੰਦੀ ਹੈ।

3. ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾ ਦੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰੋ

ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾ ਹਰ ਚੀਜ਼ ਕਰਨ ਵਾਲਾ ਪ੍ਰਬੰਧਕ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਖਾਤੇ ਨੂੰ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ SELECT, INSERT, UPDATE ਅਤੇ DELETE ਅਧਿਕਾਰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ; DROP, ALTER, CREATE ਵਰਗੇ ਅਧਿਕਾਰ ਉਤਪਾਦਨ ਵਿੱਚ ਬੰਦ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਰਿਪੋਰਟਿੰਗ ਲਈ ਵੱਖਰੇ ਪੜ੍ਹਨ ਯੋਗ ਉਪਭੋਗਤਾ, ਦੇਖਭਾਲ ਲਈ ਵੱਖਰੇ ਪ੍ਰਬੰਧਕ ਖਾਤੇ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਇੱਕ ਖਾਮੀ ਬਣਦੀ ਹੈ ਤਾਂ ਵੀ ਪ੍ਰਭਾਵ ਖੇਤਰ ਘੱਟ ਰਹਿੰਦਾ ਹੈ।

4. ਗਲਤੀ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਓ

ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਵਿਸਥਾਰਿਤ ਗਲਤੀ ਦਿਖਾਉਣ ਨੂੰ ਬੰਦ ਕਰੋ। ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਆਮ ਸੁਨੇਹਾ ਦਿਓ: ਕਾਰਵਾਈ ਇਸ ਸਮੇਂ ਪੂਰੀ ਨਹੀਂ ਹੋ ਸਕੀ। ਵਿਸਥਾਰਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਪੁੱਛਤਾਛ ਜਾਣਕਾਰੀ, ਫਾਈਲ ਦਾ ਮਾਰਗ ਅਤੇ ਸਟੈਕ ਟ੍ਰੇਸ ਸਿਰਫ਼ ਪਹੁੰਚ ਸੀਮਤ ਲਾਗਾਂ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਲਾਗਾਂ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਮੁੜ ਮੁੜ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਮਾਸਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਧਿਕਾਰਤ ਪਹੁੰਚ ਤੋਂ ਬੰਦ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

5. WAF, ਅਪਡੇਟ ਕੀਤੀਆਂ ਸੰਸਕਰਨ ਅਤੇ ਹੋਸਟਿੰਗ ਪੱਧਰ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਫਾਇਰਵਾਲ, ਖਰਾਬ ਇਰਾਦੇ ਵਾਲੇ ਨਮੂਨਿਆਂ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਇੱਕ ਵਾਧੂ ਪੱਧਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ; ਪਰ ਗਲਤ ਕੋਡ ਦੇ ਬਦਲੇ ਨਹੀਂ ਆਉਂਦਾ। PHP, Node.js, Python ਪੈਕੇਜ, CMS ਨਿਯਮ, ਥੀਮ ਅਤੇ ਐਡ-ਇਨ ਨੂੰ ਅਪਡੇਟ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣੇ ਸੰਸਕਰਨ, ਜਾਣੇ ਪਛਾਣੇ ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਖਾਮੀਆਂ ਅਤੇ ਗਲਤੀ ਪ੍ਰਬੰਧਨ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਸਮੇਤ ਹੋ ਸਕਦੇ ਹਨ। WordPress ਵਰਤਣ ਵਾਲੇ ਵੈਬਮਾਸਟਰਾਂ ਲਈ WordPress ਸੁਰੱਖਿਆ ਰਹਿਨਮਾਈ, ਐਡ-ਇਨ ਚੋਣ ਅਤੇ ਅਪਡੇਟ ਅਨੁਸ਼ਾਸਨ ਦੇ ਤੌਰ 'ਤੇ ਇੱਕ ਚੰਗੀ ਪੂਰਨਤਾ ਹੈ।

ਹੋਸਟਿੰਗ ਪਾਸੇ, ਅਲੱਗ ਖਾਤਾ ਢਾਂਚਾ, ਅਪਡੇਟ ਕੀਤਾ ਡੇਟਾਬੇਸ ਸੰਸਕਰਨ, ਨਿਯਮਿਤ ਬੈਕਅਪ, ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਆਗਿਆ ਅਤੇ SSL ਦੀ ਵਰਤੋਂ ਮਹੱਤਵਪੂਰਕ ਹੈ। SSL ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਖਾਮੀ ਨੂੰ ਨਹੀਂ ਰੋਕਦਾ; ਪਰ ਉਪਭੋਗਤਾ ਦੇ ਡੇਟਾ ਦੀ ਨੈੱਟਵਰਕ 'ਤੇ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਲਾਗਇਨ, ਭੁਗਤਾਨ ਅਤੇ ਗਾਹਕ ਪੈਨਲ ਵਾਲੀਆਂ ਸਾਈਟਾਂ 'ਤੇ SSL ਸਰਟੀਫਿਕੇਟ ਦੀ ਵਰਤੋਂ ਇੱਕ ਮੁੱਖ ਜ਼ਰੂਰਤ ਹੈ।

6. ਸੁਰੱਖਿਅਤ ਕੋਡ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਜਾਂਚ ਕਰੋ

ਸੁਧਾਰਣ ਦੇ ਬਾਅਦ ਉਹੀ ਮੈਨੁਅਲ ਜਾਂਚਾਂ ਦੁਬਾਰਾ ਕਰੋ। ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ ਇਹ ਹੈ: ਵਿਸ਼ੇਸ਼ ਅੱਖਰ ਪੁੱਛਤਾਛ ਦੇ ਮੰਤਵ ਨੂੰ ਬਦਲਦੇ ਨਹੀਂ, ਗਲਤੀਆਂ ਉਪਭੋਗਤਾ ਨੂੰ ਵਿਸਥਾਰ ਨਹੀਂ ਦਿਖਾਉਂਦੀਆਂ, ਲਾਗਾਂ ਵਿੱਚ ਜਾਂਚ ਕੀਤੀਆਂ ਗਈਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਗਲਤੀ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੀ ਅਤੇ ਅਧਿਕਾਰਾਂ ਦੀ ਜਾਂਚ ਟੁੱਟੀ ਨਹੀਂ ਹੁੰਦੀ। ਕੋਡ ਸਮੀਖਿਆ ਵਿੱਚ ਸਤਰਾਂ ਦੇ ਜੋੜਨ ਨਾਲ ਐਸਕਿਊਐਲ ਬਣਾਉਣ ਵਾਲੀਆਂ ਜਗ੍ਹਾ ਦੀ ਭਾਲ ਕਰੋ। ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਭਾਲ ਵੀ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ: SELECT, WHERE, ORDER BY, raw, query, exec ਵਰਗੇ ਸ਼ਬਦਾਂ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਵੈਬਮਾਸਟਰਾਂ ਲਈ ਪ੍ਰੈਕਟਿਕਲ ਸੁਰੱਖਿਆ ਰੁਟੀਨ

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਸੁਰੱਖਿਆ ਇੱਕ ਵਾਰੀ ਦੀ ਜਾਂਚ ਨਹੀਂ ਹੈ, ਬਲਕਿ ਨਿਯਮਿਤ ਦੇਖਭਾਲ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਮਹੀਨਾਵਾਰ CMS ਅਤੇ ਐਡ-ਇਨ ਅਪਡੇਟ ਦੀ ਜਾਂਚ ਕਰੋ। ਤਿੰਨ ਮਹੀਨਿਆਂ ਵਿੱਚ ਨਾਜ਼ੁਕ ਫਾਰਮਾਂ ਅਤੇ API ਸਿਰਿਆਂ ਦੀ ਮੈਨੁਅਲ ਵੇਖ-ਰੇਖ ਕਰੋ। ਵੱਡੇ ਕੋਡ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਡੇਟਾਬੇਸ ਪੁੱਛਤਾਛਾਂ ਨੂੰ ਮੁੜ ਦੇਖੋ। ਨਵੇਂ ਵਿਕਸਤ ਕੀਤੇ ਹਰੇਕ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਇਹ 5 ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਇਹ ਖੇਤਰ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਲੈਂਦਾ ਹੈ? ਡੇਟਾ ਕਿਸਮ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ? ਪੁੱਛਤਾਛ ਪੈਰਾਮੀਟਰ ਵਾਲੀ ਹੈ? ਗਲਤੀ ਉਪਭੋਗਤਾ ਨੂੰ ਵਿਸਥਾਰ ਦਿਖਾਉਂਦੀ ਹੈ? ਇਸ ਕਾਰਵਾਈ ਲਈ ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾ ਦੇ ਅਧਿਕਾਰ ਵਾਸਤਵ ਵਿੱਚ ਜਰੂਰੀ ਹਨ?

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਬੈਕਅਪ ਦੇ ਵਾਪਸੀ ਯੋਗ ਹੋਣ ਦੀ ਜਾਂਚ ਕਰੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਸੋਚਦੀਆਂ ਹਨ ਕਿ ਉਹ ਬੈਕਅਪ ਲੈਂਦੀਆਂ ਹਨ ਪਰ ਵਾਪਸੀ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰਨ ਕਾਰਨ ਸੰਕਟ ਦੇ ਸਮੇਂ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦੀਆਂ ਹਨ। ਸੁਰੱਖਿਅਤ ਹੋਸਟਿੰਗ, ਮਜ਼ਬੂਤ ਬੈਕਅਪ ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਕੋਡ ਵਿਕਾਸ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੇ ਹਨ ਤਾਂ ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਦੇ ਖਤਰੇ ਨੂੰ ਮਹੱਤਵਪੂਰਕ ਤੌਰ 'ਤੇ ਘਟਾਉਂਦੇ ਹਨ।

ਅਕਸਰ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਗਲਤੀਆਂ

• ਸਿਰਫ਼ ਕਲਾਇੰਟ ਪਾਸੇ JavaScript ਪ੍ਰਮਾਣਿਕਤਾ 'ਤੇ ਵਿਸ਼ਵਾਸ ਕਰਨਾ। ਹਮਲਾਵਰ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਸਰਵਰ ਪਾਸੇ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਲਾਜ਼ਮੀ ਹੈ।
• ਇੱਕਲੀਆਂ ਉਲੰਘਣਾਂ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ ਯਥੇਸ਼ਟ ਹੈ, ਇਹ ਸੋਚਣਾ। ਆਧੁਨਿਕ ਰੱਖਿਆ, ਅੱਖਰ ਹਟਾਉਣਾ ਨਹੀਂ, ਬਲਕਿ ਪੈਰਾਮੀਟਰ ਵਾਲੀ ਪੁੱਛਤਾਛ ਹੈ।
• ਐਡਮਿਨ ਪੈਨਲ ਨੂੰ ਸੁਰੱਖਿਅਤ ਸਮਝਣਾ। ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਵੀ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਇਸ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
• ORM ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਹਰ ਪੁੱਛਤਾਛ ਆਪਣੇ ਆਪ ਸੁਰੱਖਿਅਤ ਹੈ, ਇਹ ਸੋਚਣਾ। ਰਾ ਪੁੱਛਤਾਛ ਅਤੇ ਗਤੀਸ਼ੀਲ ਕ੍ਰਮ ਖੇਤਰ ਖਤਰਾ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
• ਡੇਟਾਬੇਸ ਖਾਤੇ ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਅਧਿਕਾਰ ਦੇਣਾ। ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਦੇ ਅਸੂਲ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਜੀਵੰਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਵਿਸਥਾਰਿਤ ਗਲਤੀ ਦਿਖਾਉਣ ਨੂੰ ਖੁੱਲਾ ਛੱਡਣਾ। ਇਹ ਹਮਲਾਵਰ ਲਈ ਇੱਕ ਰੋਡਮੈਪ ਹੋ ਸਕਦਾ ਹੈ।

ਸੰਖੇਪ ਟੇਬਲ: ਜਾਂਚ ਅਤੇ ਮੁਕਾਉਣ ਦੀਆਂ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਖਾਮੀਆਂ ਦੀ ਮੈਨੁਅਲ ਜਾਂਚ ਕਰਨ ਦੀ ਕਾਨੂੰਨੀ ਹੈ?

ਇਹ ਸਿਰਫ ਆਪਣੇ ਸਿਸਟਮਾਂ 'ਤੇ ਜਾਂ ਲਿਖਤੀ ਇਜਾਜ਼ਤ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕਾਨੂੰਨੀ ਹੈ। ਤੀਜੀ ਪਾਰਟੀ ਸਾਈਟਾਂ 'ਤੇ ਬਿਨਾਂ ਇਜਾਜ਼ਤ ਦੇ ਜਾਂਚ ਕਰਨਾ ਕਾਨੂੰਨੀ ਅਤੇ ਨੈਤਿਕ ਨਹੀਂ ਹੈ। ਜਾਂਚ ਦਾ ਦਾਇਰਾ, ਸਮੇਂ ਦੀ ਸੀਮਾ ਅਤੇ ਤਰੀਕੇ ਪਹਿਲਾਂ ਹੀ ਸਪਸ਼ਟ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

ਸਿਰਫ WAF ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਐਸਕਿਊਐਲ ਇੰਜੈਕਸ਼ਨ ਦੇ ਖਤਰੇ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ?

ਨਹੀਂ।