FixVibe
Covered by FixVibehigh

CORS غلط ترتيب: حد کان وڌيڪ اجازت واري پاليسين جا خطرا

ڪراس-آريجن ريسورس شيئرنگ (CORS) هڪ برائوزر ميکانيزم آهي جنهن کي آرام ڪرڻ لاءِ ٺهيل آهي Same-Origin Policy (SOP). جڏهن ته جديد ويب ايپس لاءِ ضروري آهي، غلط عمل ڪرڻ- جيئن ته درخواست ڪندڙ جي اصل هيڊر کي گونجائڻ يا 'نال' اصليت کي وائيٽ لسٽ ڪرڻ- نقصانڪار سائيٽن کي اجازت ڏئي سگھي ٿو ته هو پرائيويٽ يوزر ڊيٽا کي خارج ڪري سگھن.

CWE-942

اثر

هڪ حملو ڪندڙ هڪ حساس ايپليڪيشن [S2] جي استعمال ڪندڙن کان حساس، تصديق ٿيل ڊيٽا چوري ڪري سگهي ٿو. جيڪڏهن ڪو صارف نقصانڪار ايپ ۾ لاگ ان ٿيڻ دوران خراب ويب سائيٽ جو دورو ڪري ٿو، ته خراب سائيٽ ائپ جي API کي ڪراس-آريجن درخواستون ڏئي سگهي ٿي ۽ جواب پڙهي سگهي ٿي [S1][S2]. اهو ذاتي معلومات جي چوري جي ڪري سگھي ٿو، بشمول صارف پروفائلز، CSRF ٽوڪن، يا نجي پيغام [S2].

بنيادي سبب

CORS هڪ HTTP-هيڊر تي ٻڌل ميڪانيزم آهي جيڪو سرورز کي بيان ڪرڻ جي اجازت ڏئي ٿو ته ڪهڙن اصل (ڊومين، اسڪيم، يا بندرگاهن) کي وسيلن کي لوڊ ڪرڻ جي اجازت آهي [S1]. ڪمزوريون عام طور تي تڏهن پيدا ٿينديون آهن جڏهن سرور جي CORS پاليسي تمام لچڪدار هجي يا خراب طريقي سان لاڳو ٿيل هجي [S2]:

  • عکاس ٿيل اصل هيڊر: ڪجهه سرورز ڪلائنٽ جي درخواست کان Origin هيڊر پڙهندا آهن ۽ ان کي واپس Access-Control-Allow-Origin (ACAO) جوابي هيڊر [S2] ۾ گونجندا آهن. هي مؤثر طريقي سان ڪنهن به ويب سائيٽ کي وسيلن تائين رسائي جي اجازت ڏئي ٿو [S2].
  • غلط ترتيب ڏنل وائلڊ ڪارڊ: جڏهن ته * وائلڊ ڪارڊ ڪنهن به اصليت کي وسيلن تائين رسائي جي اجازت ڏئي ٿو، اهو انهن درخواستن لاءِ استعمال نٿو ڪري سگهجي جن لاءِ سندون گهربل هجن (جهڙوڪ ڪوڪيز يا اختيار ڏيڻ وارو هيڊر) [S3]. ڊولپر اڪثر ڪري ڪوشش ڪندا آهن ته هن کي متحرڪ طور تي ACAO هيڊر ٺاهي درخواست جي بنياد تي [S2].
  • وائيٽ لسٽنگ 'نال': ڪجهه ايپليڪيشنون null اصل کي وائيٽ لسٽ ڪن ٿيون، جيڪي ريڊائريڪٽ ٿيل درخواستن يا مقامي فائلن جي ذريعي شروع ٿي سگهن ٿيون، بدسلوڪي سائيٽن کي اجازت ڏئي ٿي ته هو null اصل کي رسائي حاصل ڪري. [S2][S3].
  • پارسنگ نقص: ريجڪس يا اسٽرنگ جي ملاپ ۾ غلطيون جڏهن Origin هيڊر جي تصديق ڪري ٿي حملي ڪندڙن کي اجازت ڏئي سگهي ٿي ڊومينز استعمال ڪرڻ جهڙوڪ trusted-domain.com.attacker.com [S2].

اهو نوٽ ڪرڻ ضروري آهي ته CORS ڪراس سائٽ درخواست جعلسازي (CSRF) [S2] جي خلاف تحفظ ناهي.

ڪنڪريٽ فيڪس

  • اسٽيڪ وائيٽ لسٽ استعمال ڪريو: گذارش جي Origin هيڊر [S2] کان متحرڪ طور تي Access-Control-Allow-Origin هيڊر ٺاهڻ کان پاسو ڪريو. ان جي بدران، درخواست جي اصليت کي قابل اعتماد ڊومينز [S3] جي هارڊ ڪوڊ ٿيل لسٽ سان ڀيٽيو.
  • 'نال' اصليت کان پاسو ڪريو: null کي اجازت نه ڏني وئي پنهنجي وائيٽ لسٽ ۾ [S2].
  • سند کي محدود ڪريو: صرف Access-Control-Allow-Credentials: true مقرر ڪريو جيڪڏھن بلڪل ضروري ھجي ته مخصوص ڪراس-آريجن رابطي لاءِ [S3].
  • مناسب تصديق جو استعمال ڪريو: جيڪڏھن توھان کي گھڻن اصليت جي حمايت ڪرڻ گھرجي، پڪ ڪريو ته Origin ھيڊر لاءِ تصديق جي منطق مضبوط آھي ۽ ذيلي ڊومينز يا ساڳي ڏسندڙ ڊومينز [S2] کان پاسو نٿو ڪري سگھجي.

ڪيئن FixVibe ان لاءِ ٽيسٽ ڪري ٿو

FixVibe ھاڻي ھن ۾ شامل آھي گيٽ ٿيل فعال چيڪ طور. ڊومين جي تصديق کان پوء، active.cors ساڳئي-اصلي API درخواستن کي مصنوعي حملي ڪندڙ اصل سان موڪلي ٿو ۽ CORS جوابي هيڊرز جو جائزو وٺندو آهي. اها رپورٽ ڪري ٿي صوابديدي اصليت، وائلڊ ڪارڊ جي تصديق ٿيل CORS، ۽ وسيع کليل CORS غير عوامي API جي آخري پوائنٽن تي جڏهن عوامي اثاثن جي شور کان پاسو ڪيو وڃي.