வலைமைப்பாளர்களுக்கான SQL இன்ஜெக்ஷன் குறைபாடுகளை கையேடு மூலம் சோதனை செய்தல் மற்றும் மூடுதல் முறைகள்

SQL இன்ஜெக்ஷன் குறைபாடுகளை கையேடு மூலம் சோதனை செய்தல் என்பது, ஒரு வலைத்தளத்தில் உள்ள படிவம், URL அளவுரு, குக்கீ, தேடல் பெட்டி அல்லது API உள்ளீடுகள் தரவுத்தொகுப்பின் கேள்விகளை பாதிக்கிறதா என்பதை கட்டுப்படுத்தப்பட்ட மற்றும் அங்கீகரிக்கப்பட்ட முறையில் உறுதிப்படுத்தும் செயல்முறை ஆகும். வலைமைப்பாளர்களுக்கான நோக்கம் தாக்குதல் செய்வது அல்ல; தவறான செய்தி, abnormal பதில், எதிர்பாராத வடிகால்வியல் நடத்தை அல்லது கேள்வி மாந்திரிகை முறையீடு போன்ற குறியீடுகளை முற்றிலும் கண்டறிந்து, பின்னர் அளவுருவான கேள்விகள், உள்ளீட்டு சரிபார்ப்பு, உரிமை வரம்பு மற்றும் பாதுகாப்பான சேவையகம் அமைப்பினால் குறைபாட்டை நிரந்தரமாக மூடுவதுதான்.

இந்த வழிகாட்டி, நேரடி வாடிக்கையாளர் தரவுகளை ஆபத்தில் வைக்காமல் செயல்படுத்தable பாதுகாப்பு மையமாக உள்ள கட்டுப்பாட்டு பட்டியல் ஒன்றை வழங்குகிறது. சோதனைகளை நீங்கள் உங்கள் தளத்தில் மட்டுமே, எழுதிய அனுமதி கொண்ட திட்டங்களில் அல்லது staging சூழலில் செய்ய வேண்டும். தரவுகளை பெற்றுக்கொள்வதற்கு, அடையாளத்தை முந்தியதாகக் கடந்து செல்ல, அட்டவணை கண்டுபிடிப்பதற்கு அல்லது அனுமதியற்ற சிஸ்டங்களில் சோதனை செய்யும் நடவடிக்கைகள் இந்த கட்டுரையின் உருப்படிகள் அல்ல. இங்கு உள்ள அணுகுமுறை; குறியீடுகளை அடையாளமிடுதல், ஆதாரங்களை குறைந்த அளவுக்கு சேகரித்தல், திருத்தங்களை செயல்படுத்துதல் மற்றும் மீண்டும் சோதித்தல் ஆகும்.

SQL இன்ஜெக்ஷன் என்றால் என்ன மற்றும் வலைமைப்பாளருக்காக ஏன் முக்கியம்?

SQL இன்ஜெக்ஷன் என்பது பயனர் வழங்கிய தரவு பாதுகாப்பான முறையில் பிரிக்கப்படாமல் SQL கேள்விக்கு சேர்க்கப்படுவதன் மூலம் உருவாகும் ஒரு பாதுகாப்பு குறைபாடு ஆகும். எடுத்துக்காட்டாக, தேடல், வடிகால்வு, தயாரிப்பு விவரங்கள், உள்ளீட்டு படிவம், ஆணை கேள்வி அல்லது நிர்வாக குழு பட்டியலிடும் திரை போன்ற பகுதிகளில் பயனர் உள்ளீடு தரவுத்தொகுப்பின் கேள்வியை மாற்ற உணருமானால், ஆபத்து உள்ளது. முடிவுகள்; தரவுகள்漏出, அனுமதியற்ற செயல்முறை, உள்ளடக்கம் மாற்றம், பயனர் கணக்குகளை கைப்பற்றுதல் அல்லது தளம் முற்றிலும் செயலிழக்கலாம்.

OWASP Top 10 பட்டியலில் இன்ஜெக்ஷன் வகையானது பல ஆண்டுகளாக மேலே உள்ளது. ஒரு சிறிய வலைப்பதிவு முதல் மின்னணு வணிக அடிப்படையை வரை, ஒவ்வொரு அளவிலான திட்டமும் பாதிக்கப்படலாம். குறிப்பாக பழைய PHP பயன்பாடுகள், புதுப்பிக்காத இணைப்புகள், தனிப்பயனாக்கப்பட்ட நிர்வாக குழுக்கள், தவறான ORM பயன்பாடு மற்றும் பதிவு செய்யப்படாத API முடிவுகள் ஆபத்தாக இருக்கலாம். ஒரு பாதுகாப்பான விருந்தினர்கள் அடுக்கு இந்த ஆபத்தை தனியாக நீக்காது; ஆனால் தற்போதைய PHP பதிப்புகள், தனித்து விருந்தினர்கள் கணக்குகள், WAF, ஒழுங்கான காப்பு மற்றும் SSL போன்ற கட்டுப்பாடுகள் சேதத்தை குறைக்கின்றன. இந்த கட்டத்தில் உங்கள் அடிப்படையை பின்வட்டமாக பரிசீலிக்க வலை உருவாக்குதல் மற்றும் SSL சான்றிதழ் பக்கங்களை ஒரு இயற்கை கட்டுப்பாட்டு படியாகக் காணலாம்.

கையேடு சோதனை செய்யும் முன் பாதுகாப்பான தயாரிப்பு

கையேடு சோதனைத் தரம், தயாரிப்புடன் நேர்மறையான தொடர்புடையது. சீரற்ற முயற்சிகள் செய்வதற்குப் பதிலாக, அளவு, சூழல், பதிவு மற்றும் மறுபடியும் திட்டம் அமைக்க வேண்டும். குறிப்பாக உற்பத்தி சூழலில் சோதனை செய்யும் போது, செயல்திறன் பாதிப்பு மற்றும் தவறான நேர்மறைகள் கவனமாக கையாளப்பட வேண்டும். மிகவும் பாதுகாப்பான அணுகுமுறை, ஒரே குறியீடு மற்றும் ஒத்த தரவுத்தொகுப்பு வடிவமைப்புடன் செயல்படும் ஒரு staging நகலில் சோதனை செய்யுதல் ஆகும்.

1. அளவையும் அதிகாரத்தையும் தெளிவாகக் கூறுங்கள்

• சோதனை செய்யப்படும் டொமைன், துணை டொமைன், குழு மற்றும் API முடிவுகளை பட்டியலிடுங்கள்.
• உங்களுக்கான அதிகாரம் இல்லாத மூன்றாம் தர சேவைகளை விலக்குங்கள்.
• சோதனை நேரத்தை குறைந்த போக்குவரத்திற்கான காலத்திற்கு எடுத்துக்கொள்ளுங்கள்.
• தரவை மாற்றும் நடவடிக்கைகளை சோதனை பயனர் மற்றும் சோதனை தரவுகளுடன் மட்டுப்படுத்துங்கள்.
• தவறு நேர்ந்தால், மீண்டும் செல்லக்கூடிய காப்பு மற்றும் அணுகல் தகவல்களை தயார் செய்து வைத்திருங்கள்.

ஒரு புதிய திட்டம் வெளியிடப்படவிருந்தால், டொமைன், DNS மற்றும் விருந்தினர்கள் மாற்றத்தின் போது பாதுகாப்பு கட்டுப்பாட்டை ஒத்திவைக்காதீர்கள். வெளியீட்டுக்கு முன் அமைப்பு விசாரணை மற்றும் லினக்ஸ் ஹோஸ்டிங் போன்ற அடிப்படைக் கட்டுப்பாடுகள் உடன் பாதுகாப்பான குறியீட்டு கட்டுப்பாட்டையும் செய்ய வேண்டும்.

2. பயன்பாட்டின் உள்ளீட்டு வரைபடத்தை உருவாக்குங்கள்

SQL இன்ஜெக்ஷன் பொதுவாக பயனர் தரவை அனுப்பும் இடங்களில் தோன்றுகிறது. எனவே முதலில் மேற்பரப்பை வரைபடமிடுங்கள். கீழே உள்ள பகுதிகளை ஒவ்வொன்றாகக் கவனியுங்கள்: URL அளவுருக்கள், POST படிவங்கள், தேடல் பெட்டிகள், வகை வடிகால்கள், வரிசை அளவுருக்கள், குப்பை மற்றும் ஆணை பகுதிகள், பயனர் சுயவிவரம், கருத்து படிவங்கள், நிர்வாக குழு பட்டியல்கள், JSON API உட்பட, HTTP தலைப்புகள் மற்றும் குக்கீகள். ஒவ்வொரு பகுதியில் எதிர்பார்க்கப்படும் தரவின் வகையை எழுதுங்கள். எடுத்துக்காட்டாக id எண் என்றால், slug உரை என்றால், தேதி பகுதி குறிப்பிட்ட வடிவத்தில் இருக்கிறதா, வரிசை மட்டும் அனுமதிக்கப்பட்ட பின்வட்டங்களில் இருந்து தேர்வு செய்யப்படுகிறதா?

3. பதிவு செய்வதையும் காப்பு செய்வதையும் இயக்குங்கள்

சோதனை நேரத்தில் பயன்பாட்டுப் பதிவுகள், வலை சேவையகம் அணுகல் பதிவுகள் மற்றும் தரவுத்தொகுப்பு தவறு பதிவுகள் மதிப்புள்ள ஆதாரங்களை வழங்குகின்றன. ஆனால் உற்பத்தியில் விவரமான தரவுத்தொகுப்பு தவறுகளை பயனருக்கு காட்டுவது தவறு. சரியான செயல்முறை; தவறை பயனருக்கு ஒரு பொதுவான செய்தியுடன் காட்டுவது, விவரங்களை பாதுகாப்பான பதிவேற்ற முறையில் எழுதுவது. சோதனைக்கு முன் தற்போதைய காப்புகளை எடுத்துக் கொள்ளுங்கள். முக்கியமான தளங்களில் கோப்பு காப்பு, தரவுத்தொகுப்பு காப்பு மற்றும் அமைப்பு காப்பு தனித்தனியாக கையாளப்பட வேண்டும். Hostragons இல் நீங்கள் பயன்படுத்தும் அடிப்படைக்கு ஏற்ப உங்கள் காப்பு திட்டத்தை விற்பனை காப்பீடு உள்ளடக்கத்துடன் மதிப்பீடு செய்யலாம்.

SQL இன்ஜெக்ஷன் குறைபாடுகளை கையேடு மூலம் சோதனை செய்வது: படி படியாகக் கட்டுப்பாட்டு பட்டியல்

கீழே உள்ள படிகள், போராட்டம் மற்றும் உறுதிப்படுத்தல் மாந்திரிகைக்கு அடிப்படையாக அமைந்துள்ளன. நோக்கம் தரவுகளை பெறுவது அல்ல; ஒரு உள்ளீட்டு கேள்வி மாந்திரிகையை பாதிக்கிறதா என்பதை புரிந்து கொள்ள வேண்டும். ஒவ்வொரு சோதனையிலும் முதலில் சாதாரண நடத்தை பதிவு செய்யுங்கள், பின்னர் மட்டுமே சிறிய மற்றும் மீண்டும் பெறக்கூடிய மாற்றங்களுடன் பதில் வேறுபாட்டைக் கவனியுங்கள்.

படி 1: சாதாரண பதிலை சுட்டுங்கள்

ஒரு தயாரிப்பு விவரங்கள் பக்கம், தேடல் படிவம் அல்லது பயனர் வடிகால்வு திரையை தேர்ந்தெடுக்கவும். சாதாரண அளவுருவுடன் பக்கத்தின் HTTP நிலை குறியீட்டை, பதில் நேரத்தை, பதிவுகள் எண்ணிக்கையை, பக்கம் தலைப்பை மற்றும் திரையில் காணப்படும் செய்தியைக் கவனியுங்கள். எடுத்துக்காட்டாக, தயாரிப்பு பக்கம் 200 பதிலளிக்கிறது, 120 ms இல் திறக்கிறது மற்றும் ஒரு தயாரிப்பை மட்டும் காட்டினால், இது உங்கள் சுட்டி ஆகும். சுட்டி இல்லாமல் செய்யப்பட்ட சோதனைகளில் ஒவ்வொரு மெதுவானது அல்லது தவறு தவறுதலாக குறைபாடாகக் கருதப்படும்.

படி 2: வகை மாறுபாடு மற்றும் எளிய பிரிக்கும் தவறுகளை சோதிக்கவும்

எண்ணிக்கை எதிர்பார்க்கப்படும் ஒரு பகுதியில் உரை மதிப்பு, உரை எதிர்பார்க்கப்படும் ஒரு பகுதியில் எதிர்பாராத சிறப்பு எழுத்துக்கள், தேதியை எதிர்பார்க்கும் ஒரு பகுதியில் மாறுபட்ட வடிவம் அனுப்பப்படும்போது, பயன்பாடு எப்படி செயல்படுகிறது? பாதுகாப்பான பயன்பாடு அல்லது உள்ளீட்டை மறுக்கிறது அல்லது கட்டுப்படுத்தப்பட்ட தவறு மீள்திரும்புகிறது. ஆபத்தான பயன்பாடு தரவுத்தொகுப்பு தவறு செய்தியை திரையில் வெளிப்படுத்தலாம், பதிவுகள் எண்ணிக்கையை மாற்றலாம் அல்லது பக்கம் வடிவமைப்பை பாதிக்கலாம். இங்கு கவனிக்கவகையானது தவறான தகவலின் உள்ளடக்கம் ஆகும். SQL உரை, அட்டவணை பெயர், பாகை பெயர், டிரைவர் பெயர் அல்லது கேள்வி பகுதி தோற்றமளிக்கிறதெனில், தகவல்漏出 உள்ளது, மேலும் இன்ஜெக்ஷன் இல்லாவிட்டாலும் இது சரிசெய்யப்பட வேண்டும்.

படி 3: மாந்திரிகை பதில் வேறுபாடுகளை கண்காணிக்கவும்

சில குறைபாடுகள் நேரடியாக தவறு உருவாக்காது; வெறும் பக்கம் காட்டும் முடிவு மாறுகிறது. எடுத்துக்காட்டாக, அதே வடிகால்வில் சாதாரண சூழலில் 3 தயாரிப்புகள் தோன்றும்போது, சிறிய மாந்திரிகை மாற்றத்திற்குப் பிறகு முடிவு எண்ணிக்கை எதிர்பாராதவிதமாக அதிகரிக்கவோ அல்லது பூஜ்யமாக்கவோ இருக்கிறதெனில் கேள்வி பயனர் உள்ளீட்டால் பாதிக்கப்படலாம். இந்த கட்டத்தில் தரவுகளை பெற முயற்சிக்காமல், வெறும் பதில் வேறுபாடு உள்ளதா என்பதை பதிவு செய்யுங்கள். பாதுகாப்பான அமைப்புகளில் பயனர் உள்ளீடு அளவுருப்படி செயல்படுத்தப்படுகிறது என்பதால், சிறப்பு எழுத்துக்கள் கேள்வி மாந்திரிகையை மாற்றாது; வெறும் தேடும் உரையின் ஒரு பகுதியாகக் கருதப்படுகிறது.

படி 4: தவறு செய்திகளை மற்றும் HTTP குறியீடுகளை பரிசீலிக்கவும்

SQL இன்ஜெக்ஷன் குறியீடு எப்போதும் திரையில் தோன்றும் தவறு அல்ல. சில நேரங்களில் 500 தவறு, வெற்று வெள்ளை பக்கம், மாறுபட்ட வழிமொழி, எதிர்பாராத 403 பதில் அல்லது நீண்ட காலமாகும் கேள்வி என்ற வடிவத்தில் தோன்றலாம். இணைய சேவையகம் பதிவுகளில், அதே கேள்விக்கு பயன்பாட்டு நிலை தவறு உருவாகினால், தொடர்புடைய குறியீட்டு தொகுதியைப் பரிசீலிக்க வேண்டும். குறிப்பாக, இந்த சொற்கள் ஆபத்து சிக்னலாக இருக்கலாம்: தரவுத்தொகுப்பு தவறு, SQL சொற்றொடர், தெரியாத பாகை, மூடப்பட்ட மேற்கோள், PDO தவறு, MySQL தவறு, PostgreSQL தவறு அல்லது ORM கேள்வி தவறுகள். உற்பத்தியில், இந்த விவரங்களை பயனருக்கு காட்டவேண்டும்.

படி 5: API மற்றும் AJAX முடிவுகளை மறக்காதீர்கள்

நவீன தளங்களில் பல கேள்விகள் காட்சி பக்கத்தைவிட பின்னணி API முடிவுகளில் செயல்படுகின்றன. உலாவி அபிவிருத்தி கருவிகளில் நெட்வொர்க் பகுதியை திறந்து JSON கேள்விகளை, வடிகால்வியல் முடிவுகளை மற்றும் நிர்வாக குழு AJAX அழைப்புகளை பரிசீலிக்கவும். API பக்கம் இதே பாதுகாப்பு விதிமுறைகள் பொருந்துகின்றன: தரவின் வகை சரிபார்க்கப்பட வேண்டும், அனுமதிக்கப்பட்ட மதிப்புகளின் பட்டியல் நடைமுறையில் இருக்க வேண்டும், அளவுருவான கேள்விகள் பயன்படுத்தப்பட வேண்டும் மற்றும் தவறு வெளியீடு எளிமைப்படுத்தப்பட வேண்டும். API பாதுகாப்பு தொடர்பான மேலும் பரவலான கட்டுப்பாடுகள் API பாதுகாப்பு உள்ளடக்கத்திற்கு இணைப்பை வழங்குவது பயனுள்ளதாக இருக்கும்.

படி 6: உரிமை சரிபார்ப்பை SQL பாதுகாப்புடன் சோதிக்கவும்

SQL இன்ஜெக்ஷன் கேள்வி எழுதுவதுடன் மட்டுமல்ல; உரிமை வடிவமைப்பும் முக்கியம். ஒரு பயனர் தனது ஆணைகளை மட்டுமே பார்க்க வேண்டுமானால், id அளவுரு மாறும்போது மற்றொரு ஆணைக்கு அணுகலாம் என்றால், இது நேரடியாக இன்ஜெக்ஷன் அல்ல, ஆனால் கடுமையான அணுகல் கட்டுப்பாடு குறைபாடு ஆகும். பாதுகாப்பான பயன்பாடு, கேள்வியில் பயனர் id தகவல்களை சேவையகத்தால் வழங்கப்பட வேண்டும், மற்றும் கிளையண்ட் கொண்டு வரும் id மதிப்புக்கு நம்பிக்கை வைக்கக்கூடாது. இந்த கட்டுப்பாடு குறிப்பாக வாடிக்கையாளர் குழு, பில், ஆதரவு கோரிக்கைகள் மற்றும் உறுப்பினர் அமைப்புகளில் முக்கியமானது.

கையேடு சோதனை கண்டுபிடிப்புகளை எவ்வாறு விளக்க வேண்டும்?

ஒரு கண்டுபிடிப்பின் உண்மையான குறைபாடு இருக்கிறதா என்பதைப் புரிந்துகொள்ள, குறைந்தபட்சம் இரண்டு ஆதாரங்களை தேடுங்கள்: பதில் வேறுபாடு மற்றும் பதிவு பதிவுகள் போன்றவை. ஒரே 500 தவறு எப்போதும் SQL இன்ஜெக்ஷன் என்று பொருள் இல்லை; கோப்பு அனுமதி, நினைவகம் எல்லை அல்லது இணைப்பு மோதல்கள் என்பதாக இருக்கலாம். ஆனால் தரவுத்தொகுப்பு தவறு மற்றும் பயனர் உள்ளீட்டு ஒரே இடத்தை குறிக்கிறதெனில், முன்னுரிமை உயர் ஆக வேண்டும்.

SQL இன்ஜெக்ஷன் குறைபாடுகளை மூடுவதற்கான வழிகள்

நிரந்தர தீர்வு, ஒரே பாதுகாப்பு இணைப்பை நிறுவுவது அல்ல. சரியான தீர்வு அடுக்கு அடிப்படையாகும்: பாதுகாப்பான குறியீடு, வரம்பு தரவுத்தொகுப்பு கணக்கு, வலிமையான தவறு மேலாண்மை, புதுப்பிக்கப்பட்ட அடிப்படைகள், கண்காணிப்பு மற்றும் ஒழுங்கான சோதனை ஒன்றாக செயல்படுத்தப்பட வேண்டும்.

1. அளவுருவான கேள்வி மற்றும் தயாரிக்கப்பட்ட உரையைப் பயன்படுத்துங்கள்

எளிய பாதுகாப்பு, பயனர் உள்ளீட்டை SQL உரையில் ஒன்றிணைக்காதது ஆகும். PHP PDO உதாரணத்தில் பாதுகாப்பான அணுகுமுறை இதற்கான மாந்திரிகையாக இருக்கிறது: `prepare` மூலம் கேள்வி மாதிரி உருவாக்கப்படுகிறது, பயனர் தரவுகள் `execute` நிலைமையில் அளவுருவாக வழங்கப்படுகின்றன. எடுத்துக்காட்டாக: `$stmt = $pdo->prepare('SELECT id, title FROM posts WHERE slug = ?'); $stmt->execute([$slug]);`. இந்த முறையில் தரவுத்தொகுப்பு, உள்ளீட்டை கட்டளையாக அல்லாமல் தரவாக செயல்படுத்துகிறது.

ORM ஐப் பயன்படுத்தினால், கவனமாக இருங்கள். Laravel, Symfony, Django அல்லது இதற்கான அமைப்புகளில் தரவுத்தொகுப்பின் கட்டமைப்பான் பெரும்பாலும் பாதுகாப்பானது; ஆனால் raw கேள்வி எழுதும்போது ஆபத்து மீண்டும் வருகிறது. Raw SQL கட்டாயம் என்றால், அளவுரு இணைப்புகளைப் பயன்படுத்த வேண்டும், உரை இணைப்புகள் செய்யக்கூடாது.

2. உள்ளீட்டு சரிபார்ப்பு மற்றும் அனுமதிக்கப்பட்ட பட்டியலை நடைமுறைபடுத்துங்கள்

அளவுருவான கேள்வி முதன்மை பாதுகாப்பாகும்; ஆனால் சரிபார்ப்பு இரண்டாவது வலிமையான அடுக்காகும். id பகுதி மட்டுமே முழுமையான எண் ஆக இருக்க வேண்டும், தேதி ISO வடிவத்தில் இருக்க வேண்டும், மின்னஞ்சல் பகுதி மின்னஞ்சல் வடிவத்திற்கு உட்பட்டிருக்க வேண்டும், வரிசை அளவுரு மட்டும் அனுமதிக்கப்பட்ட பாகைகளில் இருந்து தேர்வு செய்யப்பட வேண்டும். குறிப்பாக `order by` போன்ற பாகை பெயர் அல்லது திசை குறிக்கும் பகுதிகளில் அளவுரு இணைப்பே போதுமானதாக இருக்காது. இந்த சந்தர்ப்பத்தில் அனுமதிக்கப்பட்ட பட்டியலைப் பயன்படுத்துங்கள்: எடுத்துக்காட்டாக வரிசை மட்டும் price, created_at மற்றும் title ஆக இருக்கலாம்; திசை asc அல்லது desc உடன் மட்டுப்படுத்தப்பட வேண்டும்.

3. தரவுத்தொகுப்பு பயனரின் உரிமைகளை வரம்பளிக்கவும்

இணைய பயன்பாட்டின் தரவுத்தொகுப்பு பயனர் எல்லாவற்றையும் செய்யக்கூடிய நிர்வாகி அல்ல வேண்டும். பெரும்பாலான தளங்களில் பயன்பாட்டுக் கணக்கிற்கு தேவையான SELECT, INSERT, UPDATE மற்றும் DELETE உரிமைகளை மட்டுமே வழங்கப்படுகிறது; DROP, ALTER, CREATE போன்ற உரிமைகள் உற்பத்தியில் மூடப்படுகின்றன. அறிக்கைக்கு தனி வாசிக்கக்கூடிய பயனர், பராமரிப்புக்கு தனி நிர்வாகி கணக்கு பயன்படுத்தலாம். எனவே ஒரு குறைபாடு ஏற்பட்டால், பாதிப்பின் பரப்பளவு குறைக்கப்படுகிறது.

4. தவறு மேலாண்மையை பாதுகாப்பானதாக உருவாக்குங்கள்

உற்பத்தி சூழலில் விவரமான தவறு காட்டுதலை மூடுங்கள். பயனருக்கு பொதுவான செய்தியை வழங்குங்கள்: செயல்முறை தற்போது நிறைவேறவில்லை போன்றது. விவரமான தவறுகள், கேள்வி தகவல், கோப்பு பாதை மற்றும் stack trace மட்டுமே அணுகலை கட்டுப்படுத்திய பதிவுகளில் இருக்க வேண்டும். பதிவுகள் ஒழுங்காக மாற்றப்பட வேண்டும், உண்மையான தரவுகளை மறைக்க வேண்டும் மற்றும் அனுமதியற்ற அணுகலுக்கு மூடப்பட வேண்டும்.

5. WAF, தற்போதைய பதிப்புகள் மற்றும் விருந்தினர் அடுக்குகளைப் பயன்படுத்துங்கள்

வலை பயன்பாட்டு தீவிரம், தீவிரமான மாதிரிகளை தடுப்பதில் கூடுதல் அடுக்குக்களை வழங்குகிறது; ஆனால் தவறான குறியீட்டின் இடத்தில் இது வராது. PHP, Node.js, Python தொகுப்புகள், CMS அடிக்கோடு, தீமை மற்றும் இணைப்புகள் புதுப்பிக்கப்பட்டிருக்க வேண்டும். பழைய பதிப்புகள், அறிந்த SQL இன்ஜெக்ஷன் குறைபாடுகள் மற்றும் தவறு மேலாண்மை பலவீனங்களை அடங்கிக்கொள்ளலாம். WordPress ஐப் பயன்படுத்தும் வலைமைப்பாளர்களுக்கான WordPress பாதுகாப்பு வழிகாட்டி, இணைப்புகள் தேர்வு மற்றும் புதுப்பிப்பு ஒழுங்கு ஆகியவற்றின் அடிப்படையில் நல்ல முழுமையாக இருக்கின்றது.

விருந்தினர் பக்கம் தனித்துப் பணி அமைப்பு, தற்போதைய தரவுத்தொகுப்பு பதிப்பு, ஒழுங்கான காப்பு, பாதுகாப்பான கோப்பு அனுமதிகள் மற்றும் SSL பயன்பாடு முக்கியமாகும். SSL SQL இன்ஜெக்ஷன் குறைபாட்டை மூடாது; ஆனால் பயனர் தரவுகளை வலைதளத்தில் பாதுகாக்கிறது. குறிப்பாக, உள்ளீடு, கட்டணம் மற்றும் வாடிக்கையாளர் குழு உள்ள தளங்களில் SSL சான்றிதழ் பயன்பாடு அடிப்படையான தேவையாகும்.

6. பாதுகாப்பான குறியீட்டு மதிப்பீடு மற்றும் மீண்டும் சோதனை செய்யுங்கள்

திருத்தத்திற்குப் பிறகு, ஒரே கையேடு சோதனைகளை மீண்டும் செயல்படுத்துங்கள். எதிர்பார்க்கப்படும் முடிவு இதுதான்: சிறப்பு எழுத்துக்கள் கேள்வி மாந்திரிகையை மாற்றாது, தவறுகள் பயனருக்கு விவரங்களை வழங்காது, பதிவு செய்யப்பட்ட தவறு தவிர்ந்தால், தரவுத்தொகுப்பு தவறு தோன்றாது மற்றும் உரிமை கட்டுப்பாடுகள் சேதமடையாது. குறியீட்டு மதிப்பீட்டில் உரை இணைப்புகள் மூலம் SQL உருவாக்கும் இடங்களைத் தேடுங்கள். பெரிய திட்டங்களில் எளிமையான தேடல் கூட பயனுள்ளதாக இருக்கும்: SELECT, WHERE, ORDER BY, raw, query, exec போன்ற சொற்கள் உள்ள கோப்புகளை ஆய்வு செய்யலாம்.

வலைமைப்பாளர்களுக்கான நடைமுறை பாதுகாப்பு ஒழுங்கு

SQL இன்ஜெக்ஷன் பாதுகாப்பு ஒரே முறை சோதனை அல்ல, ஒழுங்கான பராமரிப்பு செயல்முறை ஆகும். மாதாந்திரமாக CMS மற்றும் இணைப்புகளை புதுப்பிக்கவும். மூன்று மாதங்களுக்கு ஒரு அடிப்படையான படிவங்களை மற்றும் API முடிவுகளை கையேடு மூலம் மீண்டும் பரிசீலிக்கவும். பெரிய குறியீட்டு மாற்றங்களுக்கு பிறகு தரவுத்தொகுப்பு கேள்விகளை மீண்டும் பரிசீலிக்கவும். புதிய உருவாக்கப்படும் ஒவ்வொரு அம்சத்திற்கும் இந்த 5 கேள்விகளை கேளுங்கள்: இந்த பகுதி பயனர் உள்ளீட்டை பெறுகிறதா? தரவின் வகை சரிபார்க்கப்படுகிறதா? கேள்வி அளவுருவானதா? தவறு பயனருக்கு விவரம் காட்டுகிறதா? இந்த செயல்முறைக்கு தரவுத்தொகுப்பு பயனரின் உரிமை உண்மையில் தேவையா?

மேலும், காப்புகளை மீண்டும் மீட்டுக்கொள்ளும் வகையில் சோதிக்கவும். பல தளங்கள் காப்பு எடுக்கிறார்கள் என்றாலும், மீட்டலைச் சோதிக்கவில்லை என்பதால், நெருக்கடியான நேரங்களில் சிக்கல் ஏற்படுகிறது. பாதுகாப்பான விருந்தினர், வலிமையான காப்பு மற்றும் ஒழுங்கான குறியீட்டு வளர்ச்சி SQL இன்ஜெக்ஷன் ஆபத்தை முக்கியமாகக் குறைக்கும்.

பொதுவாக செய்யப்படும் தவறுகள்

• மட்டுமே கிளையண்ட் பக்கம் JavaScript சரிபார்ப்பில் நம்புவது. தாக்குதலாளர் உலாவியைக் கொண்டு வர வேண்டியதில்லை; சேவையக பக்கம் சரிபார்ப்பு அவசியம்.
• ஒரே குறியீட்டு சுருக்கம் போதுமானது என்று நினைக்கிறது. நவீன பாதுகாப்பு, எழுத்துக்கள் நீக்குதல் அல்ல; அளவுருவான கேள்வி ஆகும்.
• நிர்வாக குழுவை பாதுகாப்பாகக் கருதுவது. நிர்வாக குழுக்கள் பயனர் உள்ளீட்டை பெறுகின்றன மற்றும் சோதிக்கப்பட வேண்டும்.
• ORM ஐப் பயன்படுத்தும்போது ஒவ்வொரு கேள்வியும் தானாகவே பாதுகாப்பாக இருக்கிறது என்று நினைக்கிறது. Raw கேள்வி மற்றும் மாறுபட்ட வரிசை பகுதிகள் ஆபத்தை உருவாக்கலாம்.
• தரவுத்தொகுப்பு கணக்குக்கு தேவையல்லாத அதிக உரிமை வழங்குவது. குறைந்தபட்ச உரிமை விதிமுறையைப் பரிசீலிக்க வேண்டும்.
• உற்பத்தி சூழலில் விவரமான தவறு காட்டுதலை திறந்துவைக்கிறது. இது, தாக்குதலாளருக்கு ஒரு வழிமுறை ஆக இருக்கலாம்.

சுருக்கமான அட்டவணை: சோதனை மற்றும் மூடுதல் முன்னுரிமைகள்

அரசு கேள்விகள்

SQL இன்ஜெக்ஷன் குறைபாடுகளை கையேடு மூலம் சோதனை செய்வது சட்டமா?

மட்டுமே உங்கள் அமைப்புகளில் அல்லது எழுதிய அனுமதி பெற்ற திட்டங்களில் சட்டமாகும். மூன்றாம் தர தளங்களில் அனுமதியின்றி சோதனை செய்வது சட்ட புறம்பானது மற்றும் ஒழுக்கதான் அல்ல. சோதனை அளவு, நேரம் மற்றும் முறைகள் முன்பு தெளிவுபடுத்தப்பட வேண்டும்.

தனியாக WAF பயன்பாடு SQL இன்ஜெக்ஷன் ஆபத்தை முடிக்குமா?

இல்லை. WAF கூடுதல் பாதுகாப்பு அடுக்காகும், ஆனால் தவறான கேள்வியை சரிசெய்யவில்லை. நிரந்தர தீர்வு அளவுருவான கேள்வி, உள்ளீட்டு சரிபார்ப்பு, பாதுகாப்பான தவறு மேலாண்மை மற்றும் குறைந்தபட்ச உரிமை விதிமுறையாகும்.

WordPress தளங்களில் SQL இன்ஜெக்ஷன் எங்கு அதிகமாக்கிறது?

பொதுவாக புதுப்பிக்கப்படாத இணைப்புகள், நம்பிக்கையற்ற தீமைகள், தனிப்பயனாக்கப்பட்ட குறியீடுகள், AJAX முடிவுகள் மற்றும் தவறான படிவ செயல்பாடுகளால் உருவாகிறது. அடிக்கோடு, தீமை மற்றும் இணைப்புகள் புதுப்பிக்கப்பட வேண்டும்; பயன்படுத்தப்படாத இணைப்புகளை நீக்க வேண்டும்.

SQL இன்ஜெக்ஷன் மற்றும் அணுகல் கட்டுப்பாட்டின் குறைபாடு ஒரே விஷயமா?

இல்லை. SQL இன்ஜெக்ஷன் என்பது கேள்வி மாந்திரிகை பயனர் உள்ளீட்டால் மாறுகிறது. அணுகல் கட்டுப்பாடு குறைபாடு பயனருக்கு காணக்கூடிய மூலத்தை அணுகலாம். ஆனால் இரண்டும் ஒரே திரையில் ஒன்றாக இருக்கலாம் மற்றும் ஒன்றாக சோதிக்கப்பட வேண்டும்.

ஒரு குறைபாட்டை மூடினேன் என்பதை எப்படி உறுதிப்படுத்துவது?

திருத்தத்திற்குப் பிறகு, ஒரே உள்ளீடுகளை மீண்டும் சோதிக்கவும். முடிவுகள் மாறக்கூடாது, விவரமான தரவுத்தொகுப்பு தவறு தோன்றக்கூடாது, பதிவுகளில் கட்டுப்படுத்தப்படாத SQL தவறு உருவாகக்கூடாது மற்றும் உரிமை கட்டுப்பாடுகள் சரியாக செயல்பட வேண்டும். முக்கிய சிஸ்டங்களில் சுயமாகக் குறியீட்டு மதிப்பீடு அல்லது பாதுகாப்பு சோதனை பரிந்துரைக்கப்படுகிறது.

மூடு

SQL இன்ஜெக்ஷன் குறைபாடுகளை கையேடு மூலம் சோதனை செய்வது, வலைமைப்பாளர்களுக்கான தொழில்நுட்ப ஆட்சி அல்ல, ஒழுங்கான பராமரிப்பு பொறுப்பு ஆகும். பாதுகாப்பான சோதனை அணுகுமுறையுடன் ஆபத்தான உள்ளீடுகளை கண்டுபிடிக்கலாம், அளவுருவான கேள்விகள் மற்றும் சரியான அங்கீகாரங்களுடன் நிரந்தர தீர்வுகளை உருவாக்கலாம். Hostragons அடிப்படையில் உங்கள் தளத்தை பராமரிக்கும் போது, தற்போதைய விருந்தினர், SSL, காப்பு மற்றும் பாதுகாப்பு அடுக்குகளை ஒன்றாக மதிப்பீடு செய்வது நீண்ட கால நிலைத்தன்மையை அதிகரிக்கும். நீங்கள் உங்கள் தற்போதைய தளத்தின் விருந்தினர் மற்றும் பாதுகாப்பு தேவைகளை விற்பனை அழுத்தம் இல்லாமல் பரிசீலிக்க Hostragons தீர்வுகளைப் பார்வையிடலாம்.