بزنس لاجک حملوں کی وضاحت
حملہ آور ہمیشہ رقم چرانے کے لیے آپ کا کوڈ نہیں توڑتے۔
بہت سے ڈویلپرز APIs اور انکرپشن (encryption) کو محفوظ بنانے میں مہینوں صرف کرتے ہیں۔ وہ SQL injection یا XSS کو روکنے پر توجہ دیتے ہیں۔ پھر ایک حملہ آور کسی بھی سیکیورٹی کنٹرول کو توڑے بغیر رقم چرا لیتا ہے۔
یہ ایک بزنس لاجک حملہ ہے۔
ایپلی کیشن بالکل اسی طرح کام کرتی ہے جیسے اسے ڈیزائن کیا گیا تھا۔ حملہ آور محض آپ کے اپنے قوانین کو آپ کے خلاف استعمال کرتا ہے۔
ایک بینک کے والٹ (vault) کے بارے میں سوچیں۔ زیادہ تر سیکیورٹی ٹیسٹ یہ چیک کرتے ہیں کہ کیا دروازہ مضبوط ہے۔ بزنس لاجک ٹیسٹنگ ایک مختلف سوال پوچھتی ہے۔ کیا ہوگا اگر کوئی گارڈ کو اپنے لیے دروازہ کھولنے پر آمادہ کر لے؟
والٹ کام کر رہا ہے۔ عمل (process) ناکام ہو گیا ہے۔
یہاں تین طریقے ہیں جن کے ذریعے حملہ آور بینکنگ لاجک کا غلط استعمال کرتے ہیں:
انتظار کے دورانیے کو نظر انداز کرنا (Bypassing Waiting Periods) بینک اکثر نئے وصول کنندہ کو شامل کرنے کے بعد 24 گھنٹے کے انتظار کی شرط رکھتے ہیں۔ یہ فوری چوری کو روکتا ہے۔ ایک حملہ آور ایسا API endpoint تلاش کر سکتا ہے جو اس چیک کو چھوڑ دیتا ہو۔ وہ UI کی پابندی کو نظر انداز کر کے فوری طور پر رقم منتقل کر سکتا ہے۔
ٹرانزیکشن کی حد کو توڑنا (Breaking Transaction Limits) ایک بینک روزانہ کی حد 50,000 مقرر کر سکتا ہے۔ اگر کوڈ صرف ہر ٹرانزیکشن کو انفرادی طور پر چیک کرتا ہے، تو ایک حملہ آور 49,000 کے پانچ ٹرانسفر بھیج سکتا ہے۔ ہر ٹرانزیکشن درست نظر آتی ہے۔ کل رقم حد سے تجاوز کر جاتی ہے، لیکن سسٹم اسے پکڑ نہیں پاتا۔
انعامات کا غلط استعمال (Reward Abuse) بہت سی ایپس بلوں کی ادائیگی پر کیش بیک (cashback) دیتی ہیں۔ ایک حملہ آور بل ادا کر سکتا ہے اور پھر فوراً اسے منسوخ کر سکتا ہے۔ اگر سسٹم انعام واپس نہیں لیتا، تو حملہ آور لامتناہی کیش بیک جمع کرنے کے لیے ایک لوپ (loop) بنا لیتا ہے۔
خودکار اسکینرز (automated scanners) اسے کیوں نہیں پکڑ پاتے؟
اسکینرز مالویئر یا انجیکشن جیسی تکنیکی خامیوں کو تلاش کرتے ہیں۔ ایک اسکینر کامیاب ٹرانسفر دیکھتا ہے اور 200 OK کا اسٹیٹس واپس کرتا ہے۔ وہ سمجھتا ہے کہ سب کچھ ٹھیک ہے۔
ایک انسانی ٹیسٹر پوچھتا ہے: کیا یہ ٹرانسفر ہونا ہی چاہیے تھا؟
ان خامیوں کو تلاش کرنے کے لیے، یہ پوچھنا بند کریں کہ کیا کسی فیچر کو ہیک کیا جا سکتا ہے۔ یہ پوچھنا شروع کریں کہ کیا کسی فیچر کا غلط استعمال کیا جا سکتا ہے۔
ان شعبوں کو چیک کریں:
- کیا صارفین تصدیقی مراحل (verification steps) کو چھوڑ سکتے ہیں؟
- کیا صارفین کسی آئی ڈی (ID) کی ملکیت تبدیل کر سکتے ہیں؟
- کیا API کے ذریعے انتظار کے دورانیے کو نظر انداز کیا جا سکتا ہے؟
- کیا حد کل رقم پر لاگو ہوتی ہے یا صرف فی کلک؟
- کیا انعامات کو بار بار حاصل کیا جا سکتا ہے؟
بہترین سیکیورٹی ٹیمیں صرف use cases نہیں بناتیں۔ وہ abuse cases بناتی ہیں۔
"صارف رقم منتقل کرتا ہے" کے بجائے، "حملہ آور حدوں کو نظر انداز کرنے کے لیے 500 چھوٹی ٹرانزیکشنز کی کوشش کرتا ہے" کا ٹیسٹ کریں۔
دوسرا سوال اصل خطرے کو ظاہر کرتا ہے۔
ماخذ: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj