AI 72 மணிநேரத்தில் 300 WordPress Plugin பிழைகளைக் கண்டறிந்தது
AI பிழைகளை வேகமாகத் தேடுகிறது. அது குறியீட்டையும் (code) வேகமாக எழுதுகிறது. இது பிளகின் உருவாக்குநர்களுக்கு (plugin developers) ஒரு ஆபத்தான இடைவெளியை உருவாக்குகிறது.
பாதுகாப்பு ஆராய்ச்சியாளர்கள் WordPress சூழலில் 300-க்கும் மேற்பட்ட முக்கியமான zero-day பாதிப்புகளைக் கண்டறிய AI-ஐப் பயன்படுத்தினர். இதை அவர்கள் வெறும் 72 மணிநேரத்தில் செய்து முடித்தனர்.
பிரச்சனை 'vibe coding' ஆகும். டெவலப்பர்கள் தாங்கள் ஆய்வு செய்ய முடியாத வகையில் LLM-களால் உருவாக்கப்பட்ட குறியீடுகளை வெளியிடும்போது இது நிகழ்கிறது. இதன் காரணமாக ஒரு பிளகினில் 100 தனித்தனி பாதுகாப்பு சிக்கல்கள் இருந்தன.
AI உங்கள் இரண்டு பழைய பாதுகாப்புகளை நீக்குகிறது: காலம் மற்றும் மறைமுகத்தன்மை (obscurity).
தாக்குபவர்கள் இப்போது ஓட்டைகளைக் கண்டறிய AI-ஐப் பயன்படுத்துகின்றனர். டெவலப்பர்கள் குறியீடு எழுத AI-ஐப் பயன்படுத்துகின்றனர். இந்த குறியீடுகள் பெரும்பாலும் பின்வரும் பாதுகாப்புப் படிகளைத் தவிர்க்கின்றன:
- Escaping data
- Capability checks
- Nonce validation
ஒரு பொதுவான பிழை அறிக்கை (bug report) வெளியாவதற்கும், அது பெருமளவில் பயன்படுத்தப்படுவதற்கும் இடையிலான கால அவகாசம் இப்போது ஐந்து மணிநேரம் மட்டுமே. இது எதிர்வினையாற்ற போதுமான நேரம் அல்ல. இது நீங்கள் தோற்றுப்போகும் ஒரு பந்தயம்.
நான் இதை கடினமான முறையில் கற்றுக்கொண்டேன். நான் ஒரு AI chatbot பிளகினை உருவாக்கினேன். ஒரு பாதுகாப்பு ஆய்வில் எனது குறியீட்டில் 35 பிழைகள் கண்டறியப்பட்டன. அதில் ஒன்று HTML injection ஆகும்.
நான் ஒரு தவறு செய்துவிட்டேன். நான் AI வெளியீட்டை நம்பினேன். ஒரு மாடல் அந்த உரையை உருவாக்கியதால் அது பாதுகாப்பானது என்று நினைத்தேன். ஆனால் அது இல்லை. மாடல் வெளியீடு பயனர்கள் மற்றும் வெளிப்புறத் தளங்களிலிருந்து வரும் தரவைக் கொண்டுள்ளது. அதை நீங்கள் நம்பகமற்றதாகவே கருத வேண்டும்.
நான் எனது பணிப்பாய்வை (workflow) மாற்றிக்கொண்டேன். ஒரு குறியீடு இயங்குவதால் மட்டுமே அது பாதுகாப்பானது என்று நான் இனி நினைக்கமாட்டேன். AI எழுதிய ஒவ்வொரு பகுதியையும் நான் மூன்று பகுதிகளில் கைமுறையாக ஆய்வு செய்கிறேன்:
- Input: தரவு எவ்வாறு அமைப்பிற்குள் நுழைகிறது.
- Output: தரவு எவ்வாறு அமைப்பிலிருந்து வெளியேறுகிறது.
- Permissions: யார் அந்தச் செயலைச் செய்ய முடியும்.
வெளியீடு தரப்பில், நான் இப்போது esc_html மற்றும் wp_kses போன்ற செயல்பாடுகளைப் பயன்படுத்துகிறேன். ஒவ்வொரு தரவுத்தளப் பதிவிற்கும் (database write) நான் $wpdb->prepare-ஐப் பயன்படுத்துகிறேன். ஒவ்வொரு நுழைவுப் புள்ளியிலும் (entry point) current_user_can மூலம் அனுமதிகளைச் சரிபார்க்கிறேன்.
உண்மையான நெருக்கடி வெறும் பிழைகள் மட்டுமல்ல. அது பதிலளிக்கும் நேரமும் (response time) கூட.
- 52% டெவலப்பர்கள் ஒரு பிழை பொதுவெளியாவதற்கு முன்பே அதற்கான திருத்தத்தை (patch) வெளியிடுவதில்லை.
- வெளிப்படுத்தப்பட்ட பிழைகளில் 46% க்கான தீர்வுகள் எதுவுமே இல்லை.
பெரும்பாலான டெவலப்பர்கள் தனிநபர் உருவாக்குநர்கள் (solo authors). பிழைகளை விரைவாகச் சரிசெய்வதற்காக அவர்களுக்கு ஊதியம் வழங்கப்படுவதில்லை. AI இந்த இடைவெளியை வெளிச்சம் போட்டுக் காட்டுகிறது.
நீங்கள் பிளகின்களை வெளியிடுபவர் என்றால், கவனமாக எழுதுவோம் என்று மட்டும் நம்பிவிடாதீர்கள். தாக்குபவர்கள் சில நொடிகளில் உங்கள் ஓட்டைகளைக் கண்டறிந்துவிடுவார்கள் என்று கருதுங்கள்.
இந்தத் தடுப்பு முறைகளை உருவாக்குங்கள்:
- அனைத்து உள்ளீடு, வெளியீடு மற்றும் அனுமதிகளையும் கைமுறையாக ஆய்வு செய்யுங்கள்.
- அனைத்து மாடல் பதில்களையும் சுத்திகரியுங்கள் (Sanitize).
- மக்கள் உங்களுக்குத் தனிப்பட்ட முறையில் பிழைகளைப் புகாரளிக்க ஒரு வழியை உருவாக்குங்கள்.
உங்கள் readme கோப்பில் ஒரு எளிய பாதுகாப்புத் தொடர்பு விவரத்தைக் கொடுப்பதே ஒரு தொடக்கமாகும். ஒரு பிழை பொதுவான அச்சுறுத்தலாக மாறுவதற்கு முன்பே, புகார்களைப் பெற உங்களுக்கு ஒரு வழிமுறை தேவை.