هڪ واحد ڪم، هڪ وسيع حملي واري سطح
تصور ڪريو: توهان هڪ مائڪرو سروس ٺاهي رهيا آهيو جيڪا صارف جي سائن اپ کي پروسيس ڪري ٿي. ڪم جي وهڪري ۾ ڪٿي، توهان هڪ اي ميل پتي کي ٽرم ڪريو ٿا SQL ۾ سب اسٽرنگ_انڊيڪس ڊومين حاصل ڪرڻ لاءِ. اهو صاف، ننڍو آهي، ۽ اسٽيجنگ ۾ سٺو ڪم ڪري ٿو. پوءِ، پيداوار ۾، لاگ مڪمل نالن ۽ اي ميل ڊومينز سان سادي متن ۾ ڀرڻ شروع ڪن ٿا، جيڪو هڪ بي ضرر نظر ايندڙ SQL ڪال مان هڪ حادثاتي ليڪ آهي.
اهو مسئلو آهي: ايس ڪيو ايل سب اسٽرنگ_انڊيڪس SQL ۾ انهن اسٽرنگ فنڪشن مان هڪ آهي جيڪو محفوظ نظر اچي ٿو جيستائين اهو غلط جاءِ تي استعمال نه ٿئي. گھڻن ٽيننٽ SaaS ايپس يا سسٽم ۾ جيڪي حساس ڊيٽا کي سنڀاليندا آهن، غلط استعمال نجي رڪارڊ کي ظاهر ڪري سگهي ٿو يا واضح الرٽس کي متحرڪ ڪرڻ کان سواءِ استحقاق وڌائڻ جي اجازت به ڏئي سگهي ٿو. نازڪ ماحول ۾، خاص طور تي گھڻن ٽيننٽ پليٽ فارمن ۾ جتي هڪ واحد سوال ڪيترن ئي گراهڪن جي خدمت ڪري سگهي ٿو، هڪ ننڍڙي ڊيليميٽر منطق غلطي SQL ۾ سب اسٽرنگ_انڊيڪس ڪراس ٽيننٽ ڊيٽا جي نمائش جو سبب بڻجي سگھي ٿو، الڳ ٿيل ڊيٽا سيٽن جي وچ ۾ معلومات ليڪ ٿي سگھي ٿي.
ريئل ڪوڊ ۾ SUBSTRING_INDEX کي سمجهڻ
MySQL ۽ MariaDB ۾، SQL substring_index ٽي دليل وٺندو آهي: پروسيس ڪرڻ لاءِ اسٽرنگ، هڪ ڊيليميٽر، ۽ هڪ ڳڻپ. اهو ان ڊيليميٽر کان اڳ يا بعد ۾ اسٽرنگ جو حصو واپس ڪري ٿو.
اهو عام طور تي ايپليڪيشن سوالن ۾ استعمال ڪيو ويندو آهي ته جيئن هڪ فيلڊ ۾ محفوظ ٿيل منظم قدرن کي جلدي ورهايو وڃي، مثال طور، هڪ اي ميل کي صارف نالو ۽ ڊومين ۾ ٽوڙڻ، هڪ URL مان هڪ ذيلي ڊومين ڪڍڻ، يا هڪ جامع ڪي مان هڪ پريفڪس کي الڳ ڪرڻ. ڊولپر اڪثر ڪري ايپليڪيشن-سائيڊ پارسنگ تي SQL ۾ substring_index چونڊيندا آهن ڇاڪاڻ ته اهو نقصانڪار آهي.cise، ڊيٽابيس کان ٻاهر اضافي پروسيسنگ کان بچي ٿو، ۽ سڌو سنئون فلٽر، شامل ٿيڻ، ۽ گروپنگ آپريشن ۾ استعمال ڪري سگهجي ٿو.
مثال طور: اي ميل مان يوزر نالو ۽ ڊومين ڪڍڻ
sql SELECT SUBSTRING_INDEX(email, '@', 1) AS username, SUBSTRING_INDEX(email, '@', -1) AS domainاستعمال ڪندڙن کان؛
SQL ۾ substring_index لاءِ عام استعمال جا ڪيس شامل آهن:
- ڀليڪار پيغامن لاءِ صارف نالا ڪڍڻ
- اجازت / رد ڪرڻ جي فهرستن جي خلاف اي ميل ڊومينز جي تصديق ڪرڻ
- تجزياتي سوالن ۾ ڊومين جي لحاظ کان صارفين کي گروپ ڪرڻ
ڇاڪاڻ ته SQL جو سب اسٽرنگ_انڊيڪس ڇا ٺيڪ آهيcise ۽ تيزيءَ سان، ڊولپر اڪثر ڪري ان کي سڌو سنئون SQL ۾ اسٽرنگ فنڪشن ۾ فلٽرنگ، تصديق، يا رپورٽنگ لاءِ استعمال ڪندا آهن. مسئلو تڏهن شروع ٿئي ٿو جڏهن ڊيليميٽر يا ڳڻپ متحرڪ هوندا آهن ۽ صارف جي ان پٽ مان ايندا آهن.
جتي سيڪيورٽي ٽٽي ٿي - SQL ۾ Substring_index
ٽي مکيه خطري جا نمونا موڙ SQL ۾ سب اسٽرنگ_انڊيڪس ذميواري ۾، خاص طور تي گھڻ-ڪرايه دار يا اعليٰ داؤ واري نظام ۾:
ڊيٽا جي گهڻي نمائش
هڪ شيئر ٿيل ڊيٽابيس ۾، هڪ کان پوءِ هڪ غلطي يا غلط ڊيليميٽر ڳڻپ ٻين ڪرائيدارن يا غير لاڳاپيل استعمال ڪندڙن کان حساس تفصيل لڪي سگهي ٿي.
sql -- Intended: first name only SELECT SUBSTRING_INDEX(full_name, ' ', 1); -- Bug: leaks full name and extra fields SELECT SUBSTRING_INDEX(full_name, ' ', 3); هڪ گھڻن ڪرائيدارن واري CRM ۾، هي ڪرائيدار جي برآمد ڪيل CSV ۾ ٻين ڪمپنين جا مڪمل گراهڪ نالا ظاهر ڪري سگهي ٿو.
خالي يا خراب فارميٽ وارو ان پٽ
جيڪڏهن ڊيليميٽر غائب آهي يا ان پٽ خالي آهي، SQL جو سب اسٽرنگ_انڊيڪس پوري فيلڊ کي واپس ڪري سگھي ٿو. نازڪ سسٽم ۾، هي اندروني IDs، ڪنيڪٽينيٽڊ ميٽا ڊيٽا، يا ڊيبگ ويلز کي ظاهر ڪري سگھي ٿو جيڪي ٻاهرين نمائش لاءِ نه آهن.
شامل ٿيڻ يا ذيلي سوالن ۾ غير مجاز رسائي
ملٽي ٽيننٽ سيٽ اپ ۾، ٽيننٽ اسڪوپنگ لاءِ SQL ۾ اسٽرنگ فنڪشن جو بي پرواهه استعمال آئسوليشن کي ٽوڙي سگهي ٿو:
SELECT o.id, o.amount, t.name FROM orders o JOIN tenants t ON SUBSTRING_INDEX(o.customer_ref, '-', 1) = t.tenant_code; If ڪسٽمر_ريف جيڪڏهن اهو غير مطابقت سان فارميٽ ٿيل آهي يا صارف جي ڪنٽرول ۾ آهي، ته ٽيننٽ اي ٽيننٽ بي جا آرڊر حاصل ڪري سگهي ٿو. ادائيگي جي نظامن يا صحت جي سار سنڀال جي پليٽ فارمن ۾، اهو ڊيٽا جي الڳ ڪرڻ جي پاليسين جي سڌي خلاف ورزي بڻجي ٿو.
گھڻن ڪرائيدارن جي خطري جو مثال: هڪ SaaS انوائسنگ پليٽ فارم جو تصور ڪريو جتي ڪسٽمر_ريف ڊيش کان اڳ ڪرائيدار جي سڃاڻپ کي انڪوڊ ڪري ٿو (ڪرائيدار جو حڪم). جيڪڏهن ڪو بدسلوڪي ڪندڙ صارف ٻئي ڪرائيدار جي ID سان آرڊر ريفرنس جمع ڪرائي ٿو پر هڪ صحيح آرڊر نمبر، ۽ شامل ٿيڻ استعمال ڪري ٿو SQL ۾ سب اسٽرنگ_انڊيڪس بغير تصديق جي، اهي هڪ مڪمل طور تي مختلف تنظيم سان تعلق رکندڙ انوائس ڊيٽا تائين رسائي حاصل ڪري سگهن ٿا.
حقيقي حملي جا ویکٹر CI/CD ۽ اوپن سورس ڪوڊ
جو غلط استعمال ايس ڪيو ايل سب اسٽرنگ_انڊيڪس صرف هڪ جونيئر-ڊيولپمينٽ غلطي ناهي؛ اهو ظاهر ٿئي ٿو:
- متحرڪ ڊيليمٽر سان ORM سوال
- اوپن سورس پلگ ان ۾ محفوظ ٿيل طريقا
- ان لائن SQL جيڪو درخواست جي پيرا ميٽرز کي سڌو سنئون ڳنڍي ٿو
ڪيئن غير محفوظ ڪوڊ پيداوار تائين پهچي ٿو:
Developer writes query using substring_index in sql ↓ Code is committed and pushed to the repository ↓ Automated build runs (no SQL security checks) ↓ Code review focuses on business logic, not string functions in SQL ↓ Changes are merged into the main branch ↓ Application is deployed to production SQL ۾ غير محفوظ اسٽرنگ افعال لاءِ خودڪار چڪاس کان سواءِ، اهي خطرا جائزو کي نظرانداز ڪري سگهن ٿا ۽ ان کي پيداوار تائين پهچائي سگهن ٿا، ممڪن طور تي پهرين ڏينهن کان حساس ڊيٽا ليڪ ٿي سگهي ٿو.
۾ ڳولا SAST/سي آءِ-سي ڊي
خطري کي سنڀالڻ جو محفوظ ترين طريقو SQL ۾ سب اسٽرنگ_انڊيڪس patterns جو مقصد انهن کي ضم ڪرڻ کان اڳ بلاڪ ڪرڻ آهي.
ڳولا جا ضابطا پڪڙڻ گهرجن:
- استعمال ڪريو ايس ڪيو ايل سب اسٽرنگ_انڊيڪس درخواست جي پيرا ميٽرز مان ڊيليمٽر يا ڳڻپ سان
- ڊيليميٽر جي تصديق غائب آهي.
مثال گهٽ ۾ گهٽ قاعدو:
yaml rules: - id: mysql-substring-index-dynamic-delimiter languages: [sql] message: Avoid SUBSTRING_INDEX with dynamic delimiter or count. severity: error Pipeline قدم:
yaml - name: SAST – SQL rules run: semgrep --config semgrep-sql.yml --error پي آر چيڪ دوران SQL ۾ غير محفوظ اسٽرنگ افعال لاءِ اسڪيننگ ڪندي، توهان ڪوڊ جي جائزي مان اندازو لڳائي ڇڏيو ٿا.
ڊولپرز لاءِ گهٽتائي جون حڪمت عمليون
خطرناڪ استعمال کي پڪڙڻ ايس ڪيو ايل سب اسٽرنگ_انڊيڪس جائزي يا اسڪين ۾ سٺو آهي، پر اصل ڪاميابي ان کي پهرين جاءِ تي متعارف ڪرائڻ ۾ نه آهي. ڪيترائي سيڪيورٽي واقعا ٿين ٿا ڇاڪاڻ ته ڊولپر ايج ڪيسن تي غور ڪرڻ کان سواءِ واقف شارٽ ڪٽ تي ڀروسو ڪندا آهن.
هتي ڪم ڪرڻ وقت مصيبت کي ڪيئن روڪيو وڃي SQL ۾ سب اسٽرنگ_انڊيڪس يا SQL ۾ ساڳيا اسٽرنگ افعال:
عملدرآمد کان اڳ ڊيليميٽر پوزيشن جي تصديق ڪريو
صرف اهو نه سمجهو ته ڊيليميٽر موجود آهي ۽ صحيح جاءِ تي آهي. گھڻن ڪرائيدار سسٽم ۾، هڪ سڃاڻپ ڪندڙ ۾ هڪ غير متوقع ڊيليميٽر ٻئي ڪرائيدار جي ڊيٽا تائين رسائي کولي سگهي ٿو.
sql SELECT CASE WHEN LOCATE('@', email) > 0 THEN SUBSTRING_INDEX(email, '@', 1) ELSE NULL END AS username FROM users; - متوقع آئوٽ پُٽ ڊيگهه چيڪ ڪريو
محفوظ حدون مقرر ڪريو. جيڪڏهن سب اسٽرنگ جو نتيجو تمام ننڍو يا تمام ڊگهو آهي، ته ان کي غلط سمجهيو. - استعمال کان اڳ ڊيٽا کي صاف ڪريو ۽ انڪوڊ ڪريو
صارف جي فراهم ڪيل ان پٽ مان بدمعاش ڊيليميٽرز کي هٽايو ان کان اڳ جو اهو SQL تائين پهچي. - پليو SQL ۾ سب اسٽرنگ_انڊيڪس سيڪيورٽي-نازڪ منطق ۾
ڪڏهن به ان کي اجازت جي چڪاس، ڪرائيدار کي الڳ ڪرڻ، يا ڪنهن به اهڙي شيءِ لاءِ استعمال نه ڪريو جيڪا حساس ڊيٽا تائين رسائي کي ڪنٽرول ڪري. پارسنگ سيڪيورٽي جي حد ناهي. - پارسنگ کي ايپليڪيشن ليئر ڏانهن منتقل ڪريو. ايپليڪيشن-سائڊ لاجڪ توهان کي تصديق، غلطي سنڀالڻ، ۽ يونٽ ٽيسٽ تي بهتر ڪنٽرول ڏئي ٿو.
python def safe_split_email(email): if '@' not in email: raise ValueError("Invalid email") username, domain = email.split('@', 1) if '.' not in domain: raise ValueError("Invalid domain") return username, domain SQL ۾ اسٽرنگ فنڪشن کي غير قابل اعتماد ڪوڊ پاٿ طور علاج ڪندي، توهان ڪنهن به منطقي غلطي جي ڌماڪي جي ريڊيس کي گهٽايو ٿا.
سيڪيورٽي ٽولنگ سان انضمام
ماهر ٽيمون به صرف دستي جائزي تي ڀروسو نٿيون ڪري سگهن؛ خطرناڪ نمونا جهڙوڪ غير محفوظ ايس ڪيو ايل سب اسٽرنگ_انڊيڪس استعمال ۾ گهٽتائي اچي سگهي ٿي، خاص طور تي وڏن ڪوڊ بيسز ۾ يا ٽئين پارٽي ڪوڊ سان ڊيل ڪرڻ وقت.
زائيگيني جهڙن اوزارن کي ڇو ضم ڪيو وڃي:
- اوپن سورس ۽ پراپرٽيري ڪوڊ ٻنهي کي ڍڪي ٿو.: يقيني بڻائڻ ته ڪمزوريون وينڊر پيڪيجز يا ليگيسي ماڊلز ۾ لڪيل نه آهن.
- SQL اسڪرپٽ ۽ ايپليڪيشن ڪوڊ ۾ غير محفوظ نمونن کي ڳولي ٿو: ڳولڻ SQL ۾ سب اسٽرنگ_انڊيڪس غلط استعمال تڏهن به جڏهن اهو پٿون، جاوا، يا Node.js اندر اسٽرنگز ۾ شامل هجي.
- سڌو سنئون ان ۾ ضم ٿئي ٿو CI/CD pipelines: جيڪڏهن غير محفوظ هجي ته تعميرات خودڪار طريقي سان ناڪام ٿي وينديون آهن SQL ۾ اسٽرنگ فنڪشن معلوم ٿين ٿا.
- قابلِ عمل اصلاحي صلاح فراهم ڪري ٿو: ڊولپرز کي ڏيکاري ٿو ته سوال جو ڪهڙو حصو خطرناڪ آهي، ڇو، ۽ ان کي ڪيئن درست ڪجي.
Xygeni سان ڪم جي فلو جي مثال CI/CD سيڪيورٽي:
Source → Commit → Build → SQL Scan (Xygeni) → Fail build if violations found → Remediation & re-scan → Merge & Deploy مسلسل اسڪيننگ تعیناتي کان اڳ اهم آهي، اهو يقيني بڻائي ٿو ته خطرناڪ استعمال ايس ڪيو ايل سب اسٽرنگ_انڊيڪس نه رڳو شروعاتي ترقي دوران پر بعد ۾ تازه ڪارين، ريفيڪٽرز، ۽ انحصار جي تبديلين ۾ پڻ پڪڙيا ويندا آهن. هن فعال طريقي جو مطلب آهي ته ڪمزوريون ختم ٿي وينديون آهن ان کان اڳ جو اهي ڪڏهن به پيداوار تائين پهچي سگهن.
ڊولپرز لاءِ آخري طريقا - SQL ۾ substring_index بابت
ھتي ھي lineئين لائن آھي:
- ايس ڪيو ايل سب اسٽرنگ_انڊيڪس قدرتي طور تي خراب ناهي، پر خراب استعمال ان کي خاموش ڊيٽا ليڪ ۾ تبديل ڪري ٿو.
- هر SQL ۾ سب اسٽرنگ_انڊيڪس سيڪيورٽي حساس رستي ۾ ڪال کي شڪي سمجهيو وڃي جيستائين محفوظ ثابت نه ٿئي.
- SQL ۾ سڀئي اسٽرنگ فنڪشن انهن تناظر ۾ خطرناڪ ٿي سگهن ٿا جتي ڊيٽا جون حدون يا اجازتون اهم آهن؛ هميشه انهن کي حساس ماحول ۾ ممڪن طور تي خطرناڪ سمجهيو، جيتوڻيڪ اهي سادا يا بي ضرر نظر اچن ٿا.
ترقي ٽيمن لاءِ ايندڙ قدم قابل عمل آهن:
- پنھنجي ڪوڊ بيس جي آڊٽ ڪريو ڪنهن به استعمال لاءِ ايس ڪيو ايل سب اسٽرنگ_انڊيڪس شامل ٿيڻ، ذيلي سوالن، يا رسائي ڪنٽرول منطق ۾.
- شامل ڪريو SAST ضابطا متحرڪ ڊيليميٽر ۽ غير تصديق ٿيل ان پٽ کي ڳولڻ لاءِ SQL ۾ اسٽرنگ فنڪشن.
- پارسنگ کي ايپليڪيشن پرت ڏانهن منتقل ڪريو ڪٿي به ممڪن آهي.
- مسلسل اسڪين هلايو ايڪسائيني جهڙن اوزارن سان جيڪي استعمال کان اڳ غير محفوظ استعمال کي پڪڙي سگهن ٿا.
سيڪيورٽي صرف حقيقت کان پوءِ سوراخ ڪرڻ بابت ناهي؛ اهو ڪم جي وهڪري ۾ روڪٿام کي شامل ڪرڻ بابت آهي. جيڪڏهن توهان علاج ڪريو ٿا ايس ڪيو ايل سب اسٽرنگ_انڊيڪس ۽ SQL ۾ ٻين اسٽرنگ فنڪشن کي خام صارف ان پٽ وانگر ساڳئي احتياط سان، توهان پنهنجي سوال ۾ هڪ آسان مددگار کي سڀ کان خطرناڪ لائن ۾ تبديل ڪرڻ کان پاسو ڪندا.
