ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਅਟੈਕਸ ਦੀ ਵਿਆਖਿਆ

ਪੈਸੇ ਚੋਰੀ ਕਰਨ ਲਈ ਹਮਲਾਵਰ ਹਮੇਸ਼ਾ ਤੁਹਾਡਾ ਕੋਡ ਨਹੀਂ ਤੋੜਦੇ।

ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ API ਅਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ (encryption) ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਵਿੱਚ ਮਹੀਨੇ ਬਿਤਾਉਂਦੇ ਹਨ। ਉਹ SQL injection ਜਾਂ XSS ਨੂੰ ਰੋਕਣ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਨ। ਫਿਰ ਇੱਕ ਹਮਲਾਵਰ ਇੱਕ ਵੀ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ (security control) ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਫੰਡ ਚੋਰੀ ਕਰ ਲੈਂਦਾ ਹੈ।

ਇਹ ਇੱਕ ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਅਟੈਕ (business logic attack) ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਿਵੇਂ ਉਸਨੂੰ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਹਮਲਾਵਰ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਆਪਣੇ ਨਿਯਮਾਂ ਨੂੰ ਤੁਹਾਡੇ ਵਿਰੁੱਧ ਵਰਤਦਾ ਹੈ।

ਇੱਕ ਬੈਂਕ ਵੌਲਟ (bank vault) ਬਾਰੇ ਸੋਚੋ। ਜ਼ਿਆਦਾਤਰ ਸੁਰੱਖਿਆ ਟੈਸਟ ਇਹ ਚੈੱਕ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਦਰਵਾਜ਼ਾ ਮਜ਼ਬੂਤ ਹੈ। ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਟੈਸਟਿੰਗ ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ। ਕੀ ਹੋਵੇਗਾ ਜੇ ਕੋਈ ਗਾਰਡ ਨੂੰ ਆਪਣੇ ਲਈ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹਣ ਲਈ ਮਨਾ ਲਵੇ?

ਵੌਲਟ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਪ੍ਰਕਿਰਿਆ (process) ਫੇਲ ਹੋ ਗਈ ਹੈ।

ਇੱਥੇ ਤਿੰਨ ਤਰੀਕੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਹਮਲਾਵਰ ਬੈਂਕਿੰਗ ਲੌਜਿਕ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਦੇ ਹਨ:

  1. ਇੰਤਜ਼ਾਰ ਦੀ ਮਿਆਦ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨਾ (Bypassing Waiting Periods) ਬੈਂਕ ਅਕਸਰ ਨਵੇਂ ਪ੍ਰਾਪਤਕਰਤਾ (recipient) ਨੂੰ ਜੋੜਨ ਤੋਂ ਬਾਅਦ 24 ਘੰਟੇ ਦੇ ਇੰਤਜ਼ਾਰ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਹੋਣ ਵਾਲੀ ਚੋਰੀ ਨੂੰ ਰੋਕਦਾ ਹੈ। ਇੱਕ ਹਮਲਾਵਰ ਅਜਿਹਾ API endpoint ਲੱਭ ਸਕਦਾ ਹੈ ਜੋ ਇਸ ਚੈੱਕ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਉਹ UI ਦੀ ਪਾਬੰਦੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹਨ ਅਤੇ ਤੁਰੰਤ ਪੈਸੇ ਟ੍ਰਾਂਸਫਰ ਕਰ ਦਿੰਦੇ ਹਨ।

  2. ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸੀਮਾਵਾਂ ਨੂੰ ਤੋੜਨਾ (Breaking Transaction Limits) ਇੱਕ ਬੈਂਕ ਰੋਜ਼ਾਨਾ 50,000 ਦੀ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਕੋਡ ਸਿਰਫ਼ ਹਰੇਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਹਮਲਾਵਰ 49,000 ਦੇ ਪੰਜ ਟ੍ਰਾਂਸਫਰ ਭੇਜ ਸਕਦਾ ਹੈ। ਹਰੇਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਜਾਇਜ਼ ਲੱਗਦੀ ਹੈ। ਕੁੱਲ ਰਕਮ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਪਰ ਸਿਸਟਮ ਇਸ ਨੂੰ ਫੜ ਨਹੀਂ ਪਾਉਂਦਾ।

  3. ਇਨਾਮਾਂ ਦੀ ਦੁਰਵਰਤੋਂ (Reward Abuse) ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਸ ਬਿੱਲ ਭਰਨ 'ਤੇ ਕੈਸ਼ਬੈਕ (cashback) ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਹਮਲਾਵਰ ਇੱਕ ਬਿੱਲ ਭਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਤੁਰੰਤ ਉਸਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਸਿਸਟਮ ਇਨਾਮ ਵਾਪਸ ਨਹੀਂ ਲੈਂਦਾ, ਤਾਂ ਹਮਲਾਵਰ ਅੰਤਹੀਣ ਕੈਸ਼ਬੈਕ ਇਕੱਠਾ ਕਰਨ ਲਈ ਇੱਕ ਲੂਪ ਬਣਾ ਲੈਂਦਾ ਹੈ।

ਆਟੋਮੇਟਿਡ ਸਕੈਨਰ (automated scanners) ਇਸ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਫੜ ਪਾਉਂਦੇ?

ਸਕੈਨਰ ਮਾਲਵੇਅਰ ਜਾਂ ਇੰਜੈਕਸ਼ਨ ਵਰਗੀਆਂ ਤਕਨੀਕੀ ਖਾਮੀਆਂ ਲੱਭਦੇ ਹਨ। ਇੱਕ ਸਕੈਨਰ ਇੱਕ ਸਫਲ ਟ੍ਰਾਂਸਫਰ ਦੇਖਦਾ ਹੈ ਅਤੇ 200 OK ਸਟੇਟਸ ਰਿਟਰਨ ਕਰਦਾ ਹੈ। ਉਹ ਸੋਚਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਠੀਕ ਹੈ।

ਇੱਕ ਮਨੁੱਖੀ ਟੈਸਟਰ ਪੁੱਛਦਾ ਹੈ: ਕੀ ਇਹ ਟ੍ਰਾਂਸਫਰ ਹੋਣਾ ਹੀ ਚਾਹੀਦਾ ਸੀ?

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

ਇਹਨਾਂ ਖੇਤਰਾਂ ਦੀ ਜਾਂਚ ਕਰੋ:

  • ਕੀ ਉਪਭੋਗਤਾ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਟੈਪਸ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹਨ?
  • ਕੀ ਉਪਭੋਗਤਾ ਕਿਸੇ ID ਦੀ ਮਾਲਕੀ ਬਦਲ ਸਕਦੇ ਹਨ?
  • ਕੀ API ਰਾਹੀਂ ਇੰਤਜ਼ਾਰ ਦੀ ਮਿਆਦ ਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?
  • ਕੀ ਸੀਮਾਵਾਂ ਕੁੱਲ ਰਕਮ 'ਤੇ ਲਾਗੂ ਹਨ ਜਾਂ ਸਿਰਫ਼ ਪ੍ਰਤੀ ਕਲਿੱਕ?
  • ਕੀ ਇਨਾਮਾਂ ਨੂੰ ਕਈ ਵਾਰ ਟ੍ਰਿਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?

ਐਲੀਟ ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਸਿਰਫ਼ 'use cases' ਨਹੀਂ ਬਣਾਉਂਦੀਆਂ। ਉਹ 'abuse cases' ਬਣਾਉਂਦੀਆਂ ਹਨ।

"ਉਪਭੋਗਤਾ ਪੈਸੇ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ" ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਬਜਾਏ, "ਹਮਲਾਵਰ ਸੀਮਾਵਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਲਈ 500 ਛੋਟੇ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ" ਦੀ ਜਾਂਚ ਕਰੋ।

ਦੂਜਾ ਸਵਾਲ ਅਸਲ ਜੋਖਮ ਨੂੰ ਲੱਭਦਾ ਹੈ।

ਸਰੋਤ: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj