ويب سائيٽ سيڪيورٽي جا موتمار گناهه: اسان سال لاءِ ڪمزوري اسڪينر جي انگن اکرن مان ڇا سکيو

اٽڪل هڪ سال اڳ، اسان DataLine تي شروع ڪيو خدمت IT ايپليڪيشنن ۾ ڪمزورين کي ڳولڻ ۽ تجزيو ڪرڻ لاء. خدمت Qualys ڪلائوڊ حل تي ٻڌل آهي، جنهن جي آپريشن جي وضاحت ڪئي وئي آهي اسان اڳ ۾ ئي ٻڌايو آهي. حل سان ڪم ڪرڻ جي هڪ سال دوران، اسان مختلف سائيٽن لاءِ 291 اسڪين ڪيا ۽ ويب ايپليڪيشنن ۾ عام ڪمزورين تي انگ اکر گڏ ڪيا. 

هيٺ ڏنل آرٽيڪل ۾ آئون توهان کي ڏيکاريندس ته ويب سائيٽ سيڪيورٽي ۾ ڪهڙا سوراخ لڪيل آهن تنقيد جي مختلف سطحن جي پويان. اچو ته ڏسون ته اسڪينر کي ڪهڙيون خاميون مليون آهن خاص طور تي، اهي ڇو ٿي سگهن ٿيون، ۽ ڪيئن پنهنجو پاڻ کي بچائڻ لاءِ. 

Qualys سڀني ويب ايپليڪيشن جي ڪمزورين کي ورهائي ٿو تنقيد جي ٽن سطحن ۾: گھٽ، وچولي ۽ اعلي. جيڪڏهن توهان "شدت" جي تقسيم تي نظر اچن ٿا، اهو لڳي ٿو ته هر شيء ايترو خراب ناهي. اعلي سطحي تنقيد سان گڏ ڪجھ ڪمزوريون آھن، اڪثر ڪري سڀ غير نازڪ آھن: 

پر غير تنقيدي معنيٰ بي ضرر نه آهي. اهي پڻ سخت نقصان پهچائي سگهن ٿا. 

مٿيون ”غير نازڪ“ ڪمزوريون

1. مخلوط مواد جي ڪمزورين.

   ويب سائيٽ سيڪيورٽي لاءِ معيار HTTPS پروٽوڪول ذريعي ڪلائنٽ ۽ سرور جي وچ ۾ ڊيٽا جي منتقلي آهي، جيڪو انڪرپشن کي سپورٽ ڪري ٿو ۽ معلومات کي مداخلت کان بچائي ٿو. 

   ڪجھ سائيٽون استعمال ڪن ٿيون مخلوط مواد: ڪجهه ڊيٽا غير محفوظ HTTP پروٽوڪول ذريعي منتقل ڪئي وئي آهي. هن طريقي سان اهو اڪثر ڪري پهچايو ويندو آهي غير فعال مواد - معلومات جيڪا صرف سائيٽ جي ڊسپلي کي متاثر ڪري ٿي: تصويرون، سي ايس ايس انداز. پر ڪڏهن ڪڏهن اهو ڪيئن منتقل ڪيو ويندو آهي فعال مواد: اسڪرپٽ جيڪي سائيٽ جي رويي کي ڪنٽرول ڪن ٿا. انهي حالت ۾، خاص سافٽ ويئر استعمال ڪندي، توهان سرور مان ايندڙ فعال مواد سان معلومات جو تجزيو ڪري سگهو ٿا، پرواز تي پنهنجا جواب تبديل ڪري سگهو ٿا ۽ مشين کي اهڙي طريقي سان ڪم ڪري سگهو ٿا جيڪو ان جي تخليق ڪندڙن جو ارادو نه هو. 

   برائوزرن جا نوان ورزن صارفين کي خبردار ڪن ٿا ته مخلوط مواد سان سائيٽون غير محفوظ آهن ۽ مواد کي بلاڪ ڪن ٿيون. ويب سائيٽ ڊولپرز پڻ ڪنسول ۾ برائوزر ڊيڄاريندڙ وصول ڪن ٿا. مثال طور، اهو ڪيئن ڏسڻ ۾ اچي ٿو يقين ڪريو: 

   
   
   اهو خطرناڪ ڇو آهي؟: حملو ڪندڙ هڪ غير محفوظ پروٽوڪول استعمال ڪندا آهن صارف جي معلومات کي روڪڻ، اسڪرپٽس کي تبديل ڪرڻ ۽ سندس طرفان سائيٽ تي درخواستون موڪلڻ لاءِ. جيتوڻيڪ هڪ سائيٽ جو دورو ڪندڙ ڊيٽا داخل نه ڪيو، اهو هن کان بچائي نٿو سگهي فشنگ - ٺڳيءَ جا طريقا استعمال ڪندي ڳجهي معلومات حاصل ڪرڻ. مثال طور، هڪ اسڪرپٽ استعمال ڪندي، توهان صارف کي هڪ غير محفوظ سائيٽ ڏانهن ريڊائريڪٽ ڪري سگهو ٿا جيڪو هڪ صارف جي واقفيت جي طور تي ظاهر ڪري ٿو. ڪجهه حالتن ۾، بدسلوڪي سائيٽ اصل کان به بهتر نظر اچي ٿي، ۽ صارف پاڻ فارم ڀري سگهي ٿو ۽ رازداري ڊيٽا جمع ڪري سگهي ٿو. 

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: جيتوڻيڪ سائيٽ جي منتظم هڪ SSL/TLS سرٽيفڪيٽ نصب ۽ ترتيب ڏني آهي، انساني غلطي جي ڪري هڪ خطرو پيدا ٿي سگهي ٿو. مثال طور، جيڪڏهن ڪنهن هڪ صفحي تي توهان هڪ لاڳاپو لنڪ نه، پر http کان هڪ مڪمل لنڪ لڳايو، ۽ ان کان علاوه توهان http کان https ڏانهن ريڊائريڪٽ سيٽ نه ڪيو آهي. 

   توهان برائوزر استعمال ڪندي سائيٽ تي مخلوط مواد ڳولي سگهو ٿا: صفحي جو سورس ڪوڊ ڳولھيو، ڊولپر ڪنسول ۾ نوٽيفڪيشن پڙھو. بهرحال، ڊولپر کي ڪوڊ سان ڊگھي وقت ۽ ٿڪائي سان ٽڪرائڻو پوندو. توھان عمل کي تيز ڪري سگھوٿا خودڪار تجزياتي اوزار سان، مثال طور: ايس ايس ايس چڪ, مفت لائيٽ هائوس سافٽ ويئر يا ادا ڪيل سافٽ ويئر Screaming Frog SEO Spider.

   انهي سان گڏ، ڪمزوري پيدا ٿي سگھي ٿي وراثت-ڪوڊ سان مسئلن جي ڪري - ڪوڊ جيڪو وراثت ۾ مليو هو. مثال طور، جيڪڏهن ڪجهه صفحا هڪ پراڻي ٽيمپليٽ استعمال ڪندي ٺاهيا ويا آهن، جيڪي اڪائونٽ ۾ نه ٿا وٺن سائيٽن جي https ڏانهن منتقلي.    

2. ڪوڪيز بغير "HTTPOnly" ۽ "محفوظ" جھنڊن جي.

   "HTTPOnly" وصف ڪوڪيز کي اسڪرپٽ پاران پروسيس ٿيڻ کان بچائيندو آهي جيڪي حملو ڪندڙ صارف جي ڊيٽا چوري ڪرڻ لاءِ استعمال ڪندا آهن. "محفوظ" پرچم ڪوڪيز کي صاف متن ۾ موڪلڻ جي اجازت نٿو ڏئي. ڪميونيڪيشن کي صرف ان صورت ۾ اجازت ڏني ويندي جڏهن محفوظ HTTPS پروٽوڪول ڪوڪيز موڪلڻ لاءِ استعمال ڪيو وڃي. 

   ٻئي خاصيتون ڪوڪي ملڪيتن ۾ بيان ڪيون ويون آهن:

   Set-Cookie: Secure; HttpOnly

   اهو خطرناڪ ڇو آهي؟: جيڪڏهن سائيٽ ڊولپر انهن خاصيتن جي وضاحت نه ڪئي، هڪ حملو ڪندڙ صارف جي معلومات کي ڪوڪيز مان روڪي سگهي ٿو ۽ ان جو استحصال ڪري سگهي ٿو. جيڪڏهن ڪوڪيز کي تصديق ۽ اختيار ڏيڻ لاءِ استعمال ڪيو وڃي ٿو، ته هو صارف جي سيشن کي هائيجيڪ ڪري سگهندو ۽ پنهنجي طرفان سائيٽ تي ڪارناما سرانجام ڏيندو. 

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: ضابطي جي طور تي، مشهور فريم ورڪ ۾ اهي خاصيتون خودڪار طور تي مقرر ڪيا ويا آهن. پر اڃا به چيڪ ڪريو ويب سرور جي ٺاھ جوڙ ۽ جھنڊو سيٽ ڪريو: Set-Cookie HttpOnly؛ محفوظ.

   انهي صورت ۾، "HTTPOnly" خاصيت ڪوڪيز کي توهان جي پنهنجي جاوا اسڪرپٽ ڏانهن پوشيده بڻائي ٿي.  

3. رستي تي ٻڌل خطرات.

   اسڪينر اهڙي خطري جي رپورٽ ڪري ٿو جيڪڏهن اهو عوامي طور تي رسائي لائق فائل يا ويب سائيٽ ڊاريڪٽري کي ممڪن طور تي ڳجهي معلومات سان ملي ٿو. مثال طور، اهو انفرادي سسٽم جي ترتيب واري فائلن کي ڳولي ٿو يا پوري فائيل سسٽم تائين رسائي. اها صورتحال ممڪن آهي جيڪڏهن رسائي جا حق سائيٽ تي غلط طور تي مقرر ڪيا ويا آهن.

   اهو خطرناڪ ڇو آهي؟: جيڪڏهن فائيل سسٽم ”اسٽيڪس آئوٽ“ ٿي سگهي ٿو، هڪ حملو ڪندڙ آپريٽنگ سسٽم جي انٽرفيس ۾ اچي سگهي ٿو ۽ پاسورڊ سان فولڊر ڳولڻ جي ڪوشش ڪري سگهي ٿو جيڪڏهن اهي صاف متن ۾ محفوظ ٿيل آهن (ائين نه ڪريو!). يا توهان پاسورڊ هيش چوري ڪري سگهو ٿا ۽ پاسورڊ کي زبردستي زور ڏئي سگهو ٿا، ۽ پڻ ڪوشش ڪري سگهو ٿا سسٽم ۾ استحقاق کي وڌائڻ ۽ انفراسٽرڪچر ۾ تمام گهڻي منتقل ڪرڻ جي.  

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: رسائي جي حقن جي باري ۾ نه وساريو ۽ پليٽ فارم، ويب سرور، ويب ايپليڪيشن کي ترتيب ڏيو ته جيئن ويب ڊاريڪٽري کي "فرار" ڪرڻ ناممڪن آهي.

4. خودڪار ڀرڻ سان حساس ڊيٽا داخل ڪرڻ لاءِ فارم.

   جيڪڏهن هڪ صارف اڪثر ڪري ويب سائيٽن تي فارم ڀريندو آهي، انهن جو برائوزر هن معلومات کي محفوظ ڪري ٿو آٽو فل فيچر استعمال ڪندي. 

   ويب سائيٽن تي فارمن ۾ حساس معلومات سان گڏ فيلڊ شامل ٿي سگھي ٿو، جهڙوڪ پاسورڊ يا ڪريڊٽ ڪارڊ نمبر. اهڙين شعبن لاءِ، ان کي غير فعال ڪرڻ جي لائق آهي فارم خودڪار ڀريندڙ فنڪشن پاڻ سائيٽ تي. 

   اهو خطرناڪ ڇو آهي؟: جيڪڏهن صارف جو برائوزر حساس معلومات محفوظ ڪري ٿو، ته حملو ڪندڙ ان کي بعد ۾ روڪي سگهي ٿو، مثال طور فشنگ ذريعي. ذات ۾، هڪ ويب ڊولپر جيڪو هن nuance جي باري ۾ وساري ڇڏيو آهي پنهنجي صارفين کي ترتيب ڏئي رهيو آهي. 

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: هن معاملي ۾، اسان وٽ هڪ شاندار تڪرار آهي: سهولت بمقابله سيڪيورٽي. جيڪڏهن هڪ ويب ڊولپر صارف جي تجربي بابت سوچي رهيو آهي، هو شعوري طور پاڻمرادو مڪمل چونڊ ڪري سگهي ٿو. مثال طور، جيڪڏهن ان جي پيروي ڪرڻ ضروري آهي ويب مواد جي رسائي جي ھدايتن - معذور استعمال ڪندڙن لاء مواد جي رسائي لاء سفارشون. 

   گھڻن برائوزرن لاءِ، توھان غير فعال ڪري سگھوٿا خودڪار مڪمل ٿيڻ کي autocompete="off" خاصيت سان، مثال طور:

    <body>
       <form action="/sd/form/submit" method="get" autocomplete="off">
         <div>
           <input type="text" placeholder="First Name">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Credit card number">
         </div>
         <input type="submit">
       </form>
     </body>

   پر اهو ڪروم لاءِ ڪم نه ڪندو. هي جاوا اسڪرپٽ استعمال ڪندي ڇڪايو ويو آهي، نسخي جو هڪ قسم ڳولي سگهجي ٿو هتي. 

5. X-Frame-Options هيڊر سائيٽ ڪوڊ ۾ مقرر نه ڪيو ويو آهي. 

   هي هيڊر فريم، iframe، ايمبيڊ، يا اعتراض جي ٽيگ کي متاثر ڪري ٿو. ان جي مدد سان، توھان مڪمل طور تي منع ڪري سگھو ٿا پنھنجي سائيٽ کي ھڪڙي فريم اندر شامل ڪرڻ. هن کي ڪرڻ لاء، توهان کي قيمت بيان ڪرڻ جي ضرورت آهي X-Frame-Options: deny. يا توهان وضاحت ڪري سگهو ٿا X-Frame-Options: sameorigin، پوءِ هڪ iframe ۾ شامل ٿيڻ صرف توهان جي ڊومين تي موجود هوندو.

   اهو خطرناڪ ڇو آهي؟: اهڙي هيڊر جي غير موجودگي بدسلوڪي سائيٽن تي استعمال ڪري سگهجي ٿي ڪلڪ جيڪنگ. هن حملي لاءِ، حملو ڪندڙ بٽڻن جي مٿان هڪ شفاف فريم ٺاهي ٿو ۽ استعمال ڪندڙ کي چالان ٿو. مثال طور: اسڪيمرز ويب سائيٽ تي سماجي نيٽ ورڪنگ صفحن کي فريم ڪن ٿا. صارف سوچي ٿو ته هو هن سائيٽ تي هڪ بٽڻ تي ڪلڪ ڪري رهيو آهي. ان جي بدران، ڪلڪ کي روڪيو ويو آهي ۽ صارف جي درخواست سوشل نيٽ ورڪ ڏانهن موڪلي وئي آهي جتي هڪ فعال سيشن آهي. هي ڪيئن حملو ڪندڙ صارف جي طرفان اسپام موڪليندا آهن يا رڪنيت حاصل ڪن ٿا ۽ پسند ڪن ٿا. 

   جيڪڏهن توهان هن خصوصيت کي غير فعال نه ڪيو، هڪ حملو ڪندڙ توهان جي ايپليڪيشن بٽڻ کي بدسلوڪي سائيٽ تي رکي سگهي ٿو. هو شايد توهان جي ريفرل پروگرام يا توهان جي استعمال ڪندڙن ۾ دلچسپي رکي ٿو.  

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: نقصان ٿي سگھي ٿو جيڪڏھن X-Frame-Options متضاد قدر سان ويب سرور يا لوڊ بيلنس تي سيٽ ڪيل آھن. انهي صورت ۾، سرور ۽ بيلنس صرف هيڊر کي ٻيهر لکندو، ڇاڪاڻ ته انهن وٽ پس منظر ڪوڊ جي مقابلي ۾ اعلي ترجيح آهي.  

   X-Frame-Options هيڊر جا انڪار ۽ ساڳيا اصل قدر Yandex ويب ڏسندڙ جي آپريشن ۾ مداخلت ڪندا. ويب ڏسندڙ لاءِ iframes جي استعمال جي اجازت ڏيڻ لاءِ، توهان کي سيٽنگن ۾ هڪ الڳ قاعدو لکڻو پوندو. مثال طور، nginx لاءِ توھان ان کي ترتيب ڏئي سگھوٿا:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. PRSSI (رستو سان لاڳاپيل اسٽائل شيٽ درآمد) خطرات.  

   هي سائيٽ جي اسٽائل ۾ هڪ ڪمزور آهي. اهو ٿئي ٿو جيڪڏهن لاڳاپيل لنڪس جهڙوڪ href="/sd/somefolder/styles.css/" اسلوب فائلن تائين رسائي لاءِ استعمال ڪيا وڃن. هڪ حملو ڪندڙ هن جو فائدو وٺندو جيڪڏهن اهي صارف کي بدسلوڪي صفحي ڏانهن ريڊائريڪٽ ڪرڻ جو رستو ڳوليندا. صفحو ان جي url ۾ هڪ لاڳاپو لنڪ داخل ڪندو ۽ هڪ طرز ڪال ٺاهيندو. توهان کي هڪ درخواست ملندي جيئن badsite.ru/…/somefolder/styles.css/، جيڪو انداز جي آڙ ۾ خراب ڪارناما انجام ڏئي سگهي ٿو. 

   اهو خطرناڪ ڇو آهي؟: هڪ فريب ڪندڙ هن ڪمزوري جو استحصال ڪري سگهي ٿو جيڪڏهن اهي ٻئي حفاظتي سوراخ ڳولين. نتيجي طور، ڪوڪيز يا ٽوڪن مان صارف جي ڊيٽا چوري ڪرڻ ممڪن آهي.

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: سيٽ ڪريو X-Content-Type-Options header to: nosniff. انهي حالت ۾، برائوزر چيڪ ڪندو مواد جي قسم جي اندازن لاء. جيڪڏهن قسم متن/سي ايس ايس کان سواءِ آهي، برائوزر درخواست کي بلاڪ ڪندو.

نازڪ ڪمزوريون

1. پاسورڊ فيلڊ سان هڪ صفحو سرور کان هڪ غير محفوظ چينل تي منتقل ڪيو ويو آهي (HTML فارم جنهن ۾ پاسورڊ فيلڊ شامل آهي HTTP تي خدمت ڪئي وئي آهي).

   سرور کان جواب هڪ غير انڪرپٽ ٿيل چينل تي "انسان وچ ۾" حملن لاء خطرناڪ آهي. هڪ حملو ڪندڙ ٽرئفڪ کي روڪي سگهي ٿو ۽ پاڻ کي ڪلائنٽ ۽ سرور جي وچ ۾ ڇڪي سگھي ٿو جيئن صفحو سرور کان ڪلائنٽ ڏانهن سفر ڪري ٿو. 

   اهو خطرناڪ ڇو آهي؟: فريب ڪندڙ صفحي کي تبديل ڪرڻ جي قابل ٿي ويندو ۽ صارف کي رازداري ڊيٽا لاء فارم موڪليندو، جيڪو حملي ڪندڙ جي سرور ڏانهن ويندو. 

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: ڪجهه سائيٽون صارفين کي پاسورڊ جي بدران اي ميل/فون ذريعي هڪ ڀيرو ڪوڊ موڪلينديون آهن. انهي حالت ۾، نقصان ايترو نازڪ نه آهي، پر ميڪانيزم صارفين جي زندگين کي پيچيده ڪندو.

2. هڪ غير محفوظ چينل تي لاگ ان ۽ پاسورڊ سان هڪ فارم موڪلڻ (لاگ ان فارم HTTPS ذريعي جمع نه ڪيو ويو آهي).

   انهي صورت ۾، هڪ لاگ ان ۽ پاسورڊ سان هڪ فارم موڪليو ويو آهي صارف کان سرور ڏانهن هڪ اڻ ڳڻي چينل ذريعي.

   اهو خطرناڪ ڇو آهي؟: اڳئين ڪيس جي برعڪس، هي اڳ ۾ ئي هڪ نازڪ خطرو آهي. حساس ڊيٽا کي روڪڻ آسان آهي ڇو ته توهان کي ان لاءِ ڪوڊ لکڻ جي به ضرورت ناهي. 

3. جاوا اسڪرپٽ لئبرريون استعمال ڪندي سڃاتل ڪمزورين سان.

   اسڪين دوران، سڀ کان وڌيڪ استعمال ٿيل لائبريري jQuery هئي نسخن جي وسيع تعداد سان. هر نسخي ۾ گهٽ ۾ گهٽ هڪ، يا ان کان به وڌيڪ، سڃاتل خطرات آهن. نقصان جي نوعيت جي لحاظ کان اثر تمام مختلف ٿي سگهي ٿو.

   اهو خطرناڪ ڇو آهي؟سڃاتل ڪمزورين جا ڪارناما آهن، مثال طور:

   
   
   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: باقاعدگي سان چڪر ڏانهن موٽڻ: معلوم ٿيل نقصانن جي ڳولا - درست ڪريو - چيڪ ڪريو. جيڪڏھن توھان عمدي لئبرريون استعمال ڪريو ٿا، مثال طور پراڻن برائوزرن کي سپورٽ ڪرڻ لاءِ يا پئسا بچائڻ لاءِ، ھڪ موقعو ڳوليو ڪنھن سڃاتل خطري کي حل ڪرڻ لاءِ. 

4. ڪراس سائيٽ اسڪرپٽنگ (XSS). 
   ڪراس-سائيٽ اسڪرپٽنگ (XSS)، يا ڪراس-سائيٽ اسڪرپٽنگ، هڪ ويب ايپليڪيشن تي حملو آهي جنهن جي نتيجي ۾ مالويئر ڊيٽابيس ۾ متعارف ڪرايو پيو وڃي. جيڪڏهن Qualys اهڙي قسم جي خطري کي ڳولي ٿو، ان جو مطلب آهي ته هڪ امڪاني حملي آور ڪري سگهي ٿو يا اڳ ۾ ئي پنهنجي JS اسڪرپٽ کي سائيٽ ڪوڊ ۾ متعارف ڪرايو آهي بدسلوڪي عملن کي انجام ڏيڻ لاء.

   ذخيرو ٿيل XSS وڌيڪ خطرناڪ، ڇاڪاڻ ته اسڪرپٽ سرور تي شامل ڪئي وئي آهي ۽ هر دفعي حملو ٿيل صفحي کي برائوزر ۾ کوليو ويندو آهي.

   ظاهر ٿيل XSS عمل ڪرڻ آسان آهي ڇاڪاڻ ته هڪ خراب اسڪرپٽ کي HTTP درخواست ۾ داخل ڪري سگهجي ٿو. ايپليڪيشن هڪ HTTP درخواست وصول ڪندي، ڊيٽا کي درست نه ڪندي، ان کي پيڪيج ڪندو، ۽ ان کي فوري طور تي موڪليو. جيڪڏهن هڪ حملو ڪندڙ ٽرئفڪ کي روڪي ٿو ۽ هڪ اسڪرپٽ داخل ڪري ٿو جهڙوڪ

   <script>/*+что+то+плохое+*/</script> 

   پوءِ ڪلائنٽ جي طرفان بدسلوڪي درخواست موڪلي ويندي.

   XSS جو هڪ شاندار مثال: js sniffers جيڪي سي وي سي، ڪارڊ جي ختم ٿيڻ جي تاريخ، وغيره داخل ڪرڻ لاءِ صفحا ٺاهيندا آهن. 

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: Content-Security-Policy header ۾، اسڪرپٽ-src وصف استعمال ڪريو ڪلائنٽ برائوزر کي مجبور ڪرڻ لاءِ ته صرف هڪ قابل اعتماد ذريعو مان ڪوڊ ڊائون لوڊ ۽ ان تي عمل ڪريو. مثال طور، اسڪرپٽ-src 'self' صرف اسان جي سائيٽ مان سڀني اسڪرپٽ کي وائيٽ لسٽ ڪري ٿو. 
   بهترين عمل آهي ان لائن ڪوڊ: صرف اجازت ڏيو ان لائن جاوا اسڪرپٽ استعمال ڪندي غير محفوظ-ان لائن قدر. هي قدر ان لائن js/css جي استعمال جي اجازت ڏئي ٿو، پر js فائلن کي شامل ڪرڻ کان منع نٿو ڪري. اسڪرپٽ-src 'self' سان ميلاپ ۾ اسان خارجي اسڪرپٽ کي عمل ٿيڻ کان روڪيون ٿا.

   رپورٽ-uri استعمال ڪندي هر شي کي لاگ ان ڪرڻ جي پڪ ڪريو ۽ ان کي سائيٽ ۾ لاڳو ڪرڻ جي ڪوششن کي ڏسو.

5. SQL انجيڪشن.
   خطري کي ظاهر ڪري ٿو SQL ڪوڊ کي ويب سائيٽ ۾ داخل ڪرڻ جو امڪان جيڪو سڌو ويب سائيٽ جي ڊيٽابيس تائين رسائي ڪري ٿو. SQL انجيڪشن ممڪن آهي جيڪڏهن صارف کان ڊيٽا جي اسڪريننگ نه ڪئي وئي آهي: ان کي درست ڪرڻ جي جانچ نه ڪئي وئي آهي ۽ فوري طور تي سوال ۾ استعمال ڪيو ويندو آهي. مثال طور، اهو ٿئي ٿو جيڪڏهن ويب سائيٽ تي هڪ فارم چيڪ نه ڪري ته ڇا ان پٽ ڊيٽا جي قسم سان ملندو آهي. 

   اهو خطرناڪ ڇو آهي؟: جيڪڏهن ڪو حملو ڪندڙ هڪ SQL سوال هن فارم ۾ داخل ڪري ٿو، ته هو ڊيٽابيس کي تباهه ڪري سگهي ٿو يا ڳجهي معلومات ظاهر ڪري سگهي ٿو. 

   ڇا هڪ ويب ڊولپر کي ياد رکڻ گهرجي: ڀروسو نه ڪريو جيڪو برائوزر مان اچي ٿو. توھان کي پنھنجي حفاظت ڪرڻ جي ضرورت آھي ٻئي ڪلائنٽ پاسي ۽ سرور جي پاسي. 

   ڪلائنٽ جي پاسي، لکو فيلڊ جي تصديق جاوا اسڪرپٽ استعمال ڪندي. 

   مشهور فريم ورڪ ۾ تعمير ٿيل افعال پڻ سرور تي مشڪوڪ اکرن کان بچڻ ۾ مدد ڪن ٿا. اهو پڻ استعمال ڪرڻ جي سفارش ڪئي وئي آهي پيراميٽر ٿيل ڊيٽابيس سوالن کي سرور تي.

   اهو طئي ڪيو ته ڪٿي ڊيٽابيس سان لاڳاپو ويب ايپليڪيشن تي ٿئي ٿو. 

   ڳالهه ٻولهه تڏهن ٿيندي آهي جڏهن اسان ڪا به معلومات حاصل ڪندا آهيون: هڪ id سان هڪ درخواست (ID جي تبديلي)، نئين استعمال ڪندڙ جي تخليق، هڪ نئون تبصرو، يا ڊيٽابيس ۾ نيون داخلائون. اھو آھي جتي SQL انجڻ ٿي سگھي ٿو. جيتوڻيڪ اسان ڊيٽابيس مان هڪ رڪارڊ حذف ڪريون ٿا، SQL انجڻ ممڪن آهي.

عام تجويزون

ڦيٿي کي ٻيهر نه بڻايو - ثابت ٿيل فريم ورڪ استعمال ڪريو. ضابطي جي طور تي، مشهور فريم ورڪ وڌيڪ محفوظ آهن. .NET - ASP.NET MVC ۽ ASP.NET ڪور لاءِ، Python - Django يا Flask لاءِ، Ruby - Ruby on Rails لاءِ، PHP لاءِ - Symfony، Laravel، Yii، JavaScript لاءِ - Node.JS-Express.js، جاوا لاءِ - بهار MVC.

وينڊر جي تازه ڪاري جي پيروي ڪريو ۽ باقاعده تازه ڪاري ڪريو. اهي هڪ ڪمزوري ڳوليندا، پوء هڪ استحصال لکندا، ان کي عام طور تي دستياب بڻائيندا، ۽ سڀ ڪجهه ٻيهر ٿيندو. سافٽ ويئر وينڊر کان مستحڪم ورزن جي تازه ڪاري لاءِ رڪنيت حاصل ڪريو.

چيڪ ڪريو رسائي جا حق. سرور جي پاسي، هميشه توهان جي ڪوڊ جو علاج ڪريو ڄڻ ته اهو، پهرين کان آخري خط تائين، توهان جي سڀ کان وڌيڪ نفرت ڪندڙ دشمن طرفان لکيو ويو آهي، جيڪو توهان جي سائيٽ کي ٽوڙڻ چاهي ٿو، توهان جي ڊيٽا جي سالميت جي ڀڃڪڙي ڪري ٿو. ان کان سواء، ڪڏهن ڪڏهن اهو سچ آهي.

ڪلون استعمال ڪريو، ٽيسٽ سائيٽون، ۽ پوء انھن کي پيداوار لاء استعمال ڪريو. هي مدد ڪندو، پهرين، هڪ پيداواري ماحول ۾ غلطين ۽ غلطين کان بچڻ لاء: هڪ پيداوار ماحول پئسا آڻيندو آهي، هڪ سادي پيداوار ماحول نازڪ آهي. جڏهن ڪنهن به مسئلي کي شامل ڪرڻ، حل ڪرڻ يا بند ڪرڻ، اهو هڪ امتحان واري ماحول ۾ ڪم ڪرڻ جي قابل آهي، پوء ڪارڪردگي ۽ ڪمزورين کي جانچڻ، ۽ پوء پيداوار جي ماحول سان ڪم ڪرڻ جي منصوبابندي ڪرڻ. 

پنھنجي ويب ايپليڪيشن کي محفوظ ڪريو ويب ايپليڪيشن فائر وال ۽ ان سان گڏ خطراتي اسڪينر کان رپورٽون ضم ڪريو. مثال طور، DataLine Qualys ۽ FortiWeb استعمال ڪري ٿو خدمتن جي بنڊل طور.

جو ذريعو: www.habr.com