Safari MCP પર આધારિત એક ઓટોમેશન ટૂલે ડેવલપરના ડેશબોર્ડ ટેબને વાંચતી વખતે જ બંધ કરી દીધું. આ ઘટનાએ તે ગાર્ડ (guard) માં રહેલી એક છુપાયેલી ખામીને ખુલ્લી પાડી દીધી જે AI-સંચાલિત એજન્ટોને તેમના સિવાયના કોઈપણ ટેબને સ્પર્શતા રોકવા માટે બનાવવામાં આવ્યો હતો, અને તે દર્શાવે છે કે શા માટે “safe-by-default” શ્રેણીઓ જોખમી સાબિત થઈ શકે છે.
જે ગાર્ડ કામ કરતો હતો—જ્યાં સુધી તે કામ ન કરતો રહ્યો
ટૂલ તેના દ્વારા બનાવવામાં આવેલા દરેક ટેબને આંતરિક ઓળખકર્તા (internal identifier) સાથે ટેગ કરે છે. એજન્ટ કોઈપણ કમાન્ડ આપતા પહેલા, ગાર્ડ તે માર્કર તપાસે છે; જો માર્કર ન હોય, તો ગાર્ડ કાર્ય કરવાનો ઇનકાર કરે છે. વ્યવહારમાં, ગાર્ડે એજન્ટને એવું પેજ વાંચતા અટકાવ્યું જે તેણે ખોલ્યું નહોતું—બરાબર જે કરવા માટે તેને ડિઝાઇન કરવામાં આવ્યો હતો.
એક ફોર્મ ભરતી વખતે, પેજ બીજા ડોમેન પર રીડાયરેક્ટ થયું. આ રીડાયરેક્ટથી માર્કર નીકળી ગયું, જેના કારણે ટેબ અનલેબલ (unlabelled) થઈ ગયું. ગાર્ડે ખૂટતું માર્કર જોયું અને રિપોર્ટ કર્યો, “હું માલિકીની ચકાસણી કરી શકતો નથી, તેથી હું આ ટેબ વાંચીશ નહીં.” તે સમયે સેફ્ટી ચેક ઈરાદા મુજબ જ કામ કરતું હતું.
લાઇન ઓળંગી જતું ક્લીનઅપ કોડ
ત્યારબાદ મેન્યુઅલ ક્લીનઅપ રૂટિન આવ્યું જે અનાથ (orphaned) ટેબ્સ—જેમાં માર્કર નથી—તેમને બંધ કરવા માટે હતું. આ રૂટિને માલિકીની પુષ્ટિ કર્યા વિના ટૂલને “close a tab” કરવાનું કહ્યું. કારણ કે ગાર્ડ સાબિત કરી શક્યો નહીં કે ટેબ તેનું પોતાનું છે, ટૂલ ડિફોલ્ટ એક્શન પર આવી ગયું: “close the current tab.” વર્તમાન ટેબ એ ડેવલપર જે ડેશબોર્ડ વાંચી રહ્યો હતો તે હતું, કોઈ અનાથ ટેબ નહીં.
પરિણામ એક વિનાશક ઓપરેશન હતું જે સેફ્ટી પાથ દ્વારા ટ્રિગર થયું હતું જે ડેડ એન્ડ (dead end) હોવું જોઈતું હતું.
ત્રણ સ્તરો જેણે “no ownership” ને પરવાનગી તરીકે લીધું
- Command categorisation – કમાન્ડ્સને ગ્રુપ કરતી યાદીએ
close_tabને વ્યાપક “tab management” બકેટ હેઠળ મૂક્યું હતું. ડેવલપરે ધાર્યું હતું કે તે બકેટમાં રહેલી બધી વસ્તુઓ નુકસાનકારક નથી કારણ કે અન્ય કમાન્ડ્સ (જેમ કે “list tabs”) ફક્ત માહિતી વાંચે છે. કોઈ સ્પષ્ટ નોંધેclose_tabને વિનાશક તરીકે ફ્લેગ ન કર્યું, તેથી તેણે તેના પડોશીઓની ધારવામાં આવેલી સુરક્ષા વારસામાં લીધી. - Extension-level policy – Safari એક્સ્ટેન્શન જે બ્રાઉઝરની તમામ ક્રિયાઓનું સંચાલન કરતું હતું, તેણે સેશન પાસે કંઈ જ ન હોય ત્યારે કોઈપણ ઓપરેશનની મંજૂરી આપી દીધી. તે નિયમ ફક્ત રીડ-ઓન્લી (read-only) ક્રિયાઓ માટે કામ કરે છે, પરંતુ તેણે
close_tabને પ્રોવેનન્સ ચેક (provenance check) વગર અમલમાં લાવવા માટે પણ દરવાજો ખોલી દીધો. - Logic mismatch – ક્લીનઅપ રૂટિને એક ટેબ પર માલિકીનો ફ્લેગ તપાસ્યો પરંતુ પછી બ્રાઉઝરે “current” તરીકે રિપોર્ટ કરેલા ટેબ પર ક્લોઝ ફંક્શનને કોલ કર્યું. આ મિસમેચને કારણે ગાર્ડ દ્વારા માર્કર ન શોધવાની નિષ્ફળતાએ ક્લોઝ કમાન્ડને બાયપાસ કરી દીધો અને તેને ખોટા લક્ષ્ય તરફ વાળ્યો.
દરેક સ્તરે એમ ધાર્યું હતું કે “માલિકી નોંધાયેલ નથી” નો અર્થ “કાર્ય કરવા માટે સુરક્ષિત છે” એવો થાય છે, અને સાથે મળીને તેઓએ ટેબ-બંધ કરવાનો કમાન્ડ બનાવ્યો જે કોઈપણ કાયદેસરતાના પુરાવા વિના ચાલ્યો.
ઉકેલ: વિનાશક ક્રિયાઓ માટે માલિકીનો પુરાવો ફરજિયાત છે
સુધારેલ લોજિક રીડ-ઓન્લી પાથને વિનાશક પાથથી અલગ કરે છે. હવે, close_tab કમાન્ડ અમલમાં આવે તે પહેલાં, ટૂલે લક્ષ્ય ટેબ માટે માન્ય માર્કર રજૂ કરવું આવશ્યક છે. જો માર્કર ખૂટતું હોય, તો કમાન્ડ વર્તમાન ટેબ પર ડિફોલ્ટ જવાને બદલે એરર (error) ફેંકે છે. ગાર્ડ હવે સામાન્ય “do something” બ્રાન્ચ પર પાછો આવતો નથી.
આ ફેરફાર તે અસ્પષ્ટ સ્થિતિને દૂર કરે છે જ્યાં ખૂટતું માર્કર કાં તો “કંઈ કરવા માટે નથી” અથવા “આગળ વધો અને કાર્ય કરો” તરીકે વાંચવામાં આવી શકે છે. સ્પષ્ટ નિષ્ફળતાને ફરજિયાત બનાવીને, ટૂલ વપરાશકર્તાના કાર્યને અકસ્માતે નુકસાન થતું બચાવે છે.
ડેવલપર્સે શેના પર ધ્યાન આપવું જોઈએ
- કેટેગરીનું નામ સુરક્ષા નક્કી ન કરવા દો – “tab management” જેવું લેબલ તેની અંદરના દરેક કમાન્ડની અસર વિશે કંઈ જ કહેતું નથી. કમાન્ડની બાજુમાં જ દરેક ઓપરેશનનો ખર્ચ (read vs. destroy) નોંધો.
- ગાર્ડની શરતો ક્રિયાની ગંભીરતા સાથે મેળ ખાતી હોવી જોઈએ – રીડ રિક્વેસ્ટ માટે પૂરતી તપાસ ડેટા ડિલીટ કરી શકે તેવા કમાન્ડ માટે પૂરતી નથી. દરેક પ્રકારની અસર માટે અલગ વેરિફિકેશન પાઇપલાઇન્સ બનાવો.
- Implicit fallbacks ટાળો – જ્યારે ગાર્ડ માલિકીની ચકાસણી ન કરી શકે, ત્યારે સૌથી સુરક્ષિત પ્રતિસાદ એ છે કે પ્રક્રિયા રદ કરવી, નહીં કે ડિફોલ્ટ લક્ષ્ય પસંદ કરવું. ડિફોલ્ટ એક્શન્સ એ પ્રિવિલેજ-એસ્કેલેશન બગ્સ (privilege-escalation bugs) નો સામાન્ય સ્ત્રોત છે.
- એડજસન્સી એસમ્પશનનું ઓડિટ કરો – કોઈપણ યાદી અથવા મેનૂની સમીક્ષા કરો જ્યાં કમાન્ડ્સ એકબીજાની બાજુમાં હોય છે. જો કોડ સ્પષ્ટપણે સુરક્ષાનું પુનઃ મૂલ્યાંકન ન કરે તો એક નિર્દોષ કમાન્ડ તેના પડોશીઓ પર મૂકવામાં આવેલા વિશ્વાસને વારસામાં મેળવી શકે છે.
Takeaway
માલિકીનો ગાર્ડ ન હોવો એ બગ નથી; તે ડિઝાઇન ગેપ (design gap) છે. દરેક વિનાશક કમાન્ડને અલગ સુરક્ષા ડોમેન તરીકે ગણો જે સત્તાના સ્પષ્ટ પુરાવાની માંગ કરે છે, અને ક્યારેય “no marker” ને “go ahead” તરીકે અર્થઘટન ન કરવા દો. તો જ ઓટોમેશન ટૂલ્સ તે ટેબ્સનું રક્ષણ કરી શકશે જેનું મેનેજમેન્ટ કરવા માટે તેમને બનાવવામાં આવ્યા છે.