ஒரு GET collection endpoint-இல் விடுபட்ட பாதுகாப்புச் சரிபார்ப்பினால், ஒரு அடிப்படை CoopCycle கணக்கு வைத்திருக்கும் எவரும், ஒரு பகிரப்பட்ட instance-இல் உள்ள அனைத்து கடைகளின் முழு முகவரிப் புத்தகத்தையும் எடுக்க முடிந்தது. இது எண்ணற்ற வாடிக்கையாளர்களின் பெயர்கள், தெரு முகவரிகள் மற்றும் அஞ்சல் குறியீடுகளை வெளிப்படுத்தியது. இந்தத் தவறு இரண்டு நாட்களுக்குள் சரி செய்யப்பட்டது, மேலும் பயனர்கள் சமீபத்திய பதிப்பிற்கு மேம்படுத்த (upgrade) அறிவுறுத்தப்படுகிறார்கள்.
கசிவு எவ்வாறு நடந்தது
CoopCycle – உணவு விநியோகக் கூட்டுறவு அமைப்புகளால் பயன்படுத்தப்படும் ஒரு திறந்த மூல (open-source) தளவாடத் தளம் – தனது API-ஐ PHP framework API Platform மூலம் வரையறுக்கிறது. அந்த framework-இல் ஒவ்வொரு செயல்பாடும் (POST, GET, போன்றவை) ஒரு பாதுகாப்பு வெளிப்பாட்டுடன் (security expression) இணைக்கப்பட்டிருக்க வேண்டும்; அந்த வெளிப்பாடு விடுபட்டிருந்தால், framework எந்த அங்கீகாரச் சரிபார்ப்பும் (authorization check) இன்றி குறியீட்டை இயக்கும்.
டெவலப்பர்கள் ஒரு கடையின் முகவரிப் பட்டியலை உருவாக்குவதற்கோ அல்லது புதுப்பிப்பதற்கோ பயன்படும் POST கோரிக்கையை (request), is_granted('edit', object) என்ற நிலையான expression மூலம் பாதுகாத்துள்ளனர். இது வேலை செய்கிறது, ஏனெனில் அந்த கோரிக்கை ஒரு ஒற்றை கடைத் தரவை (single store entity) இலக்காகக் கொண்டுள்ளது, இது framework மதிப்பீடு செய்வதற்கு ஒரு குறிப்பிட்ட "object"-ஐ வழங்குகிறது.
அதே வளத்தை (resource) வாசிக்கும் GET கோரிக்கை ஒரு தொகுப்பை (collection) இலக்காகக் கொண்டுள்ளது: /api/stores/{id}/addresses. ஒரு தொகுப்பில் ஒற்றை object கிடையாது, எனவே அதே is_granted('edit', object) expression-ஐப் பயன்படுத்த முடியாது. டெவலப்பர்கள் பாதுகாப்பு வரியைத் தவிர்த்ததால், framework எந்தவொரு tenancy (உரிமையாளர் பிரிவு) தொடர்பும் இன்றி, அங்கீகரிக்கப்பட்ட எந்தவொரு பயனருக்கும் முகவரித் தரவை வழங்கியது.
ஒரு பகிரப்பட்ட CoopCycle instance-இல், ஒரு தீய நோக்கம் கொண்ட பயனர் கடை ID-களை வரிசையாகச் சரிபார்த்து, அந்த endpoint-க்கு GET கோரிக்கைகளை அனுப்பி, அமைப்பில் சேமிக்கப்பட்டுள்ள ஒவ்வொரு வாடிக்கையாளரின் வீட்டு முகவரிகளையும் திரட்ட (scrape) முடிந்தது. ஒரு சாதாரண கணக்கைத் தவிர வேறு எந்த கூடுதல் அதிகாரங்களும் இதற்குத் தேவையில்லை.
பிழை ஏன் நீடித்தது
இந்தப் பிரச்சனை ஒரு சாதாரண கவனக்குறைவு அல்ல. API Platform-இன் அறிவிப்புப் பாதுகாப்பு மாதிரி (declarative security model), "பயனர் தொகுப்பில் உள்ள ஒவ்வொரு object-இன் அதே tenant-இல் இருக்க வேண்டும்" என்பதை வெளிப்படையாகக் கூறுவதற்கு நேரடியான வழியைக் கொண்டிருக்கவில்லை. framework அங்கீகாரத்தை (authorization) கடினமானதாக மாற்றிய அதே இடத்தில் தான் இந்த விடுபட்ட குறியீடு இருந்தது.
பிரச்சனையை மேலும் சிக்கலாக்கியது என்னவென்றால், திட்டத்தின் சோதனைத் தொகுப்பு (test suite), அனைத்து முகவரிகளையும் கொண்ட GET பதில் எதிர்பார்த்த செயல்பாடே என்று உண்மையில் உறுதிப்படுத்தியது. வேறு வார்த்தைகளில் கூறுவதானால், சோதனையில் பயன்படுத்தப்பட்ட fixtures, குறுக்கு-வாடிக்கையாளர் அணுகலை (cross-tenant access) அனுமதித்ததால் தானியங்கி சோதனைகள் வெற்றி பெற்றன, இது பாதிப்பை மறைத்துவிட்டது. இந்தச் சூழலில், ஒரு வெற்றிகரமான சோதனைத் தொகுப்பு தவறான பாதுகாப்பு உணர்வையே அளித்தது.
யார் வெற்றி பெறுகிறார்கள் மற்றும் யார் இழக்கிறார்கள்
- வாடிக்கையாளர்கள்: அவர்களின் தனிப்பட்ட அடையாளம் காணக்கூடிய தகவல்கள் (PII) – முழு பெயர்கள் மற்றும் வீட்டு முகவரிகள் – தளத்தில் உள்ள எவருக்கும் வெளிப்பட்டன. தரவு பகிரங்கமாகப் பதிவேற்றப்படவில்லை என்றாலும், இந்த மீறல் பல கூட்டுறவு அமைப்புகளின் தனியுரிமையைச் சிதைத்தது.
- CoopCycle பயன்படுத்தும் கூட்டுறவு அமைப்புகள்: வாடிக்கையாளர் தரவைப் பாதுகாக்கும் தளத்தின் திறனில் இருந்த நம்பிக்கை shaken ஆனது. இன்னும் மேம்படுத்தாத எந்தவொரு கூட்டுறவு அமைப்பும் தொடர்ச்சியான தரவு வெளிப்பாட்டு அபாயத்தை எதிர்கொண்டது.
- CoopCycle பராமரிப்பாளர்கள்: அவர்களின் விரைவான நடவடிக்கை – இரண்டு நாட்களுக்குள் ஒரு திருத்தம் (patch) மற்றும் கூடுதல் பின்னடைவுச் சோதனைகளை (regression tests) சேர்த்தது – பாதிப்பு காலத்தைக் குறைத்தது மற்றும் பொறுப்பான திறந்த மூலப் பராமரிப்பை (open-source stewardship) demonstrated செய்தது. இருப்பினும், இந்தச் சம்பவம், குறிப்பாக framework சார்ந்த இயல்புநிலைகளைச் (defaults) சுற்றி, கடுமையான பாதுகாப்பு ஆய்வு செயல்முறைகளின் அவசியத்தை எடுத்துக்காட்டுகிறது.
டெவலப்பர்கள் மற்றும் தணிக்கையாளர்கள் எவற்றைக் கவனிக்க வேண்டும்
- செயல்பாட்டு சமச்சீரற்ற தன்மை (Operation asymmetry): ஒரு பாதையில் (path) POST (அல்லது ஏதேனும் மாற்றும் செயல்பாடு) பாதுகாக்கப்பட்டும், அதற்கு இணையான GET திறந்த நிலையில் இருந்தால், அந்த முரண்பாடு ஒரு எச்சரிக்கை அறிகுறியாகும் (red flag). POST கோரிக்கை வளத்தைப் பாதுகாப்பதற்கான டெவலப்பர்களின் நோக்கத்தை வெளிப்படுத்துகிறது.
- தொகுப்பு முனையங்கள் (Collection endpoints): ஒரு தனிப் பொருளுக்குப் பதிலாகப் பட்டியலைத் திருப்பித் தரும் எதையும் வழக்கமான பாதுகாப்பு முறைகள் தவிப்பதாக இருக்கலாம். மொத்தமாகப் படிக்கும்போது (bulk reads) அங்கீகாரச் சரிபார்ப்புகள் வெளிப்படையாகச் சேர்க்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும்.
- சோதனைத் தொகுப்பின் யதார்த்தம் (Test suite realism): fixtures ஆகியவை உண்மையான tenancy எல்லைகளைப் பிரதிபலிக்கின்றனவா என்பதை உறுதிப்படுத்தவும். குறுக்கு-வாடிக்கையாளர் தரவு கசிவைச் சரிபார்க்கும் ஒரு வெற்றிகரமான சோதனை, எச்சரிக்கை அறிகுறியே தவிர, அது ஒரு பச்சைக்கொடி அல்ல.
தீர்வு மற்றும் அடுத்த கட்ட நடவடிக்கைகள்
பாதிப்பு அறிவிக்கப்பட்ட பிறகு, CoopCycle முக்கியக் குழு GET collection செயல்பாட்டிற்கு விடுபட்ட பாதுகாப்பு வெளிப்பாட்டைச் சேர்த்தது மற்றும் ஒற்றை-பொருள் மற்றும் தொகுப்பு முனையங்கள் இரண்டிற்கும் வாடிக்கையாளர் தனிமைப்படுத்தலை (tenant isolation) enforcing செய்யும் பின்னடைவுச் சோதனைகளை அறிமுகப்படுத்தியது. இந்தத் திருத்தம் மென்பொருளின் அடுத்த பதிப்பில் வெளியிடப்பட்டது.
CoopCycle பயனர்கள் செய்ய வேண்டியவை:
- தாங்கள் மென்பொருளின் சமீபத்திய பதிப்பைப் பயன்படுத்துவதை உறுதிப்படுத்திக் கொள்ளவும்.
- இதே போன்ற தொகுப்பு-நிலை இடைவெளிகளை ஏற்படுத்தக்கூடிய எந்தவொரு தனிப்பயன் விரிவாக்கங்கள் (custom extensions) அல்லது பிளகின்களைப் (plugins) பரிசீலிக்கவும்.
- அனைத்து API பாதைகளிலும் படிக்க/எழுத (read/write) சமச்சீரற்ற தன்மையைக் கவனித்து மீண்டும் பாதுகாப்பு ஸ்கேன்களை (security scans) இயக்கவும்.
முக்கியக் கருத்து
பாதுகாப்பை அறிவிப்புத் தன்மையுடையதாக (declarative) மாற்றும் கட்டமைப்புகள், டெவலப்பர்கள் ஒற்றைப் பொருட்களுக்கு (single objects) மட்டுமே பொருந்தும் முறைகளைச் சார்ந்திருக்கும் போது, ஆபத்தான இடைவெளிகளை மறைக்கக்கூடும். ஒரு எளிய சரிபார்ப்பு—ஒரு endpoint-ன் 'read side', அதன் 'write side'-ல் உள்ள அதே பாதுகாப்பைக் (guard) கொண்டுள்ளதா?—என்ற கேள்வி, இல்லையெனில் 'green test suites'-களுக்குப் பின்னால் மறைந்திருக்கும் ஒரு வகை 'cross-tenant leaks'-களை வெளிப்படுத்த முடியும்.