क्या macOS UI automation testing agent approval को हरा सकती है?

Approval card तभी security control है, जब approval किसी दूसरे process के बजाय व्यक्ति के अपने action से हो। यह बात तब कम स्पष्ट लगती है, जब card सामान्य macOS desktop में हो। Accessibility clients controls की जांच कर सकते हैं, automation tools applications को activate कर सकते हैं और कोई भी foreground window अगले click के लिए मुकाबला कर सकती है।

इसका परीक्षण यह देखकर न करें कि card modal जैसा दिखता है या उसके button पर भरोसा जगाने वाला label है। यह जांचें कि realistic local privileges वाला कोई process protected action कर सकता है या नहीं, बिना इस बात के कि इच्छित व्यक्ति सोच-समझकर और पूरी जानकारी के साथ चुनाव करे। उपयोगी नतीजा कोई नाटकीय exploit video नहीं है। असली नतीजा एक दोहराया जा सकने वाला उत्तर है: कौन से input paths approval boundary पार कर सकते हैं, किन permissions के तहत, और कौन सा evidence परिणाम साबित करता है?

यह आपके अपने software का red team exercise है, उस Mac और account पर जिसे आप नियंत्रित करते हैं। मांगी गई action harmless रखें। Dummy HTTP endpoint, nonproduction SSH host या fixed test value लौटाने वाली action इस्तेमाल करें। ऐसा security test जो गलती से पैसे खर्च कर सकता है, data मिटा सकता है या production access बदल सकता है, script लिखने से पहले ही गलत तरीके से scoped है।

Accessibility permission attacker model बदल देती है

Accessibility permission वाला process कोई साधारण background process नहीं होता। Apple के अनुसार Accessibility access apps को Mac नियंत्रित करने देता है और macOS में user को Privacy \u0026 Security settings से यह access देना पड़ता है। Apple Automation permission को अलग तरह से परिभाषित करता है, जो दूसरे apps तक पहुंचने और उन्हें नियंत्रित करने की अनुमति देती है। ये अलग permissions हैं, लेकिन जब approval card desktop पर रहता है तो दोनों threat model का हिस्सा हैं।

टीमें अक्सर जिस फर्क को धुंधला कर देती हैं, वह यह है: approval UI accessible हो सकता है, लेकिन accessibility से आए हर action को human intent का प्रमाण मानना जरूरी नहीं है। Assistive technology users के लिए application चलाने हेतु Accessibility को meaningful labels, roles, state changes और focus दिखाना ही होगा। यह inclusion की जरूरत है। इसका अर्थ यह नहीं कि application किसी बाहरी process को बिना किसी local user signal के irreversible confirmation action चलाने दे।

Test शुरू करने से पहले लिखें कि आप वास्तव में किस attacker का simulation कर रहे हैं। अस्पष्ट शब्द «malware» से बचें। वह उन permissions को छिपा देता है जो परिणाम तय करती हैं। एक उपयोगी baseline attacker उसी logged-in user के तहत चलने वाला signed helper है, जिसे पहले ही Accessibility permission मिल चुकी है। मजबूत variant के पास Automation permission भी होती है और वह application activation मांग सकता है। इनमें से किसी variant के पास administrator credentials, screen unlock bypass या approval application की बदली हुई copy नहीं होनी चाहिए।

यह सीमा test को निष्पक्ष बनाती है। अगर आपका निष्कर्ष है, «जिस attacker के पास user account का पूरा control है, वह user account को नियंत्रित कर सकता है», तो आपने कुछ नहीं सीखा। अगर निष्कर्ष यह है कि «जिस helper के पास वही permissions हैं जो user window manager, test runner, macro tool या assistive utility को दे सकता है, वह credential use approve कर सकता है», तो आपको साफ fix path वाली design problem मिली है।

पहले run से पहले capability sheet बनाएं:

किसी test tool के मांगने भर से permission न दें। हर अतिरिक्त permission बाद में किए जाने वाले claim को बदल देती है। Result title में exact combination दर्ज करें, जैसे «Accessibility-only helper cannot confirm per-call approval», न कि «approval is safe». दूसरा statement किसी अलग desktop configuration के सामने टिक नहीं सकता।

Helper का bundle identifier, code-signing authority, process ID, parent process और launch path भी दर्ज करें। अच्छे approval system को व्यक्ति के लिए request का आकलन करने लायक process identity दिखानी चाहिए, लेकिन test record में card से अधिक detail चाहिए। Test operator को यह पता लगाने में सक्षम होना चाहिए कि child process ने भरोसेमंद दिखने वाले parent से क्या inherit किया, terminal wrapper ने helper launch किया या नहीं, और relaunch पर नई process identity बनी या नहीं।

Clickable button कमजोर approval का प्रमाण नहीं है

macOS accessibility hierarchy में दिखाई देने वाला button अपने आप vulnerability नहीं है। AppKit उम्मीद करता है कि accessibility elements इस hierarchy का हिस्सा हों, ताकि assistive clients functional control ढूंढ सकें। Apple के documentation के अनुसार controls labels, titles, frames और enabled होने जैसी properties expose करते हैं।

कमजोर design वह है जिसमें exposed button को invoke करना sensitive action के लिए पर्याप्त evidence हो। इससे synthetic accessibility action और conscious click में फर्क नहीं रहता। यह समस्या अक्सर चुपचाप रह जाती है, क्योंकि टीम mouse से test करती है, expected callback देखती है और यह नहीं पूछती कि वही callback और किन तरीकों से पैदा हो सकता है।

Approval decision को केवल button के action handler पर नहीं, बल्कि local authorization event पर निर्भर करें। UI control request शुरू कर सकता है, लेकिन protected action को ऐसे authorization result का इंतजार करना चाहिए जिसमें confirmation का तरीका दर्ज हो। सामान्य session approval में यह application के active और current approval surface को verify करने के बाद किया गया deliberate click हो सकता है। High-risk action के लिए system-mediated local authentication event मांगें, जैसे उपलब्ध होने पर Touch ID।

Approves button को accessibility tree में छिपाना या उसका नाम बदलना आम गलती है। इससे assistive technology की जरूरत वाले users को नुकसान होता है और सक्षम local attacker के खिलाफ बहुत कम सुरक्षा मिलती है, क्योंकि वह focus को फिर भी बदल सकता है या alternate paths invoke कर सकता है। इसके बजाय जांचें कि confirmation pipeline synthetic path, stale card, inactive card और ऐसे request को reject करती है या नहीं जिसकी displayed details चलने वाली action से मेल नहीं खातीं।

एक उपयोगी internal decision record ऐसा दिख सकता है:

{
  "request_id": "test-4d8f",
  "decision": "approved",
  "decision_method": "touch_id",
  "card_generation": 7,
  "request_generation": 7,
  "app_active": true,
  "card_frontmost": true,
  "requester_pid": 48102,
  "requester_signing_authority": "Example Development Team",
  "action_started_after_decision": true
}

Field names से अधिक जरूरी उनका अलग-अलग होना है। decision बताता है कि क्या हुआ। decision_method बताता है कि वह कैसे हुआ। Generation values redraw, retry या action substitution के बाद पुराने card को नई request approve करने से रोकती हैं। Activation fields दर्ज करती हैं कि decision के समय user आपके card को देख रहा था या नहीं। अंतिम field test को operations का order assert करने देती है।

यह separation एक सूक्ष्म implementation failure भी पकड़ती है: approval पहले स्वीकार कर लेना और बाद में card को केवल दिखावे के लिए दिखाना। इस bug में हर visual test pass हो जाता है। Protected action पहले ही शुरू हो चुकी होती है, इसलिए card control के बजाय केवल दिखावा रह जाता है। Action executor से decision token मांगें, जिसे approval subsystem relevant checks पूरे होने के बाद ही बनाए।

Test rig से harmless और comparable runs मिलने चाहिए

एक ऐसा test fixture बनाएं जो predictable approval request बनाए और एक ऐसा observer जो evidence जमा करे। Live credential पर general desktop automation framework चलाकर शुरुआत न करें। Test rig को ambiguity घटानी चाहिए, बढ़ानी नहीं।

Fixture में stable identifier वाली request, हर run में बदलने वाली visible details, छोटा expiry और harmless completion effect होना चाहिए। उदाहरण के लिए protected action को local endpoint call करने दें, जो approval system द्वारा release किए जाने के बाद ही approved:test-4d8f लौटाए। अगर valid approval record के बिना action सफल हो जाती है, तो test में साफ failure है। Timeout या denial मिलने पर साफ nonapproval result है।

Card और protected request दोनों में short-lived nonce रखें। केवल «Allow agent access?» लिखने वाला card stale-window bug नहीं दिखा सकता। «Allow test request 4d8f to call the staging echo service?» दिखाने वाला card ऐसा कर सकता है। हर run में nonce बदलें और assert करें कि action result में वही nonce मौजूद है।

Evidence में तीन independent clocks रखें:

1. Request creation time।
2. Decision time।
3. Protected action start time।

जहां संभव हो application के भीतर monotonic time इस्तेमाल करें। Human timeline के लिए wall-clock time उपयोगी है, लेकिन network synchronization, sleep या manual changes के कारण बदल सकता है। Ordering rule सरल है: action उसी request generation के valid decision के बाद ही शुरू होनी चाहिए। Screenshot इस order को साबित नहीं कर सकता।

Observer को active application, focused window, approval card का visible request ID और अंततः मिला action result capture करना चाहिए। Screen recording अनपेक्षित behavior समझने में मदद करती है, लेकिन structured events की जगह नहीं लेती। Screen recordings में process identifiers खो जाते हैं, तेज transitions एक साथ दिखने लगते हैं और pointer movement के पीछे महत्वपूर्ण event छिप सकता है।

हर attempt के लिए ऐसा test record इस्तेमाल करें:

case=AX-invoke-approve
request=test-4d8f
helper=TestHelper pid=48102
permissions=accessibility
approval_surface=active
attempt=accessibility_action
decision=denied
protected_action=not_started
artifact=activity-event-0192

attempt value mechanism बताए, desired result नहीं। attack-1 की जगह activate-then-click, stale-window, keyboard-focus-shift या voiceover-navigation लिखें। छह हफ्ते बाद यही plain description किसी को गलत case दोबारा चलाने से बचाएगी।

पहले यही fixture बिना helper permissions के चलाएं। यही आपका control है। फिर एक-एक करके capability enable करें। Control run के बिना red team result की हर failure समझना कठिन होगा। हो सकता है card keyboard से पहुंचने योग्य ही न हो। Endpoint fail हुआ हो। Test helper के पास वह entitlement न हो जिसे आप मौजूद समझ रहे थे। Control इन बहानों को दिखाई देने वाले differences में बदल देता है।

Synthetic approval test करें, लेकिन इसे exploit kit न बनाएं

इस case का उद्देश्य यह पता लगाना है कि permitted accessibility client approval control invoke करके protected action चला सकता है या नहीं। इसका उत्तर पाने के लिए public-ready clicker या brittle coordinate scripts के ढेर की जरूरत नहीं है।

अपने test helper को सीमित काम दें: application identity और test-only request nonce से अपनी test application की approval window खोजे, accessibility client द्वारा मांगे जाने वाले वही semantic action का अनुरोध करे, फिर बताए कि protected action पूरी हुई या नहीं। Desktop की हर window न खोजें। Third-party dialogs को target न करें। Credentials store न करें और real service accounts से interaction न करें।

इन paths को अलग-अलग test करें, क्योंकि हर path अलग बात साबित करता है:

• Approve control का semantic accessibility invocation।
• Keyboard navigation से Approve तक पहुंचना और फिर synthetic activation।
• Helper द्वारा approval application को सामने लाने के बाद pointer action।
• Helper द्वारा application को सामने न लाने के बाद pointer action।
• Card expire होने या request बदलने के बाद delayed action।

Coordinate clicking को केवल visual overlap के regression test के रूप में रखें। इससे पता चलता है कि layout shift के बाद screen position पर किया गया click गलत control पर जा सकता है या नहीं। इससे यह पता नहीं चलता कि कोई बाहरी process intended element को पहचानकर activate कर सकता है या नहीं। Authorization logic के लिए semantic UI automation मजबूत test है; layout और focus accidents के लिए coordinates बेहतर test हैं।

Approval mode के अनुसार results अलग होने की उम्मीद रखें। Session-level approval आमतौर पर किसी recognized agent process को उसके पूरे process life के लिए authorize करने के लिए बनाई जाती है। अगर आपका session approval plain click स्वीकार करता है, तो Accessibility-permitted helper उसकी नकल कर सकता है, जब तक app input path को अलग न पहचाने या approval को किसी मजबूत local event से bind न करे। Low-risk actions के लिए यह स्वीकार्य tradeoff हो सकता है, लेकिन इसे साफ तौर पर बताएं।

Per-call approval को इससे अधिक मजबूत होना चाहिए। अगर action data बदल सकती है, release publish कर सकती है या production host तक पहुंच सकती है, तो केवल button press पर्याप्त नहीं है। Touch ID या किसी अन्य system-mediated local authentication signal की मांग करें। तब test का सवाल होगा: क्या helper prompt दिखा सकता है, उसके आसपास के हर accessible control को invoke कर सकता है और फिर भी व्यक्ति के authenticate किए बिना protected action पूरी नहीं कर सकता? यही कहीं साफ security property है।

सिर्फ इसलिए «blocked» report न करें कि button ने response नहीं दिया। पूरी chain report करें: helper ने card ढूंढा या नहीं, control invoke किया या नहीं, app ने decision record किया या नहीं, authorization subsystem ने token जारी किया या नहीं और action executor शुरू हुआ या नहीं। आज helper button दबाने में fail हो सकता है, जबकि कल कोई alternate keyboard path सफल हो जाए। Decision token ही असली boundary है।

Focus stealing सही click को गलत decision में बदल सकता है

Direct scripted clicking पर ध्यान जाता है, क्योंकि वह malicious दिखता है। Focus stealing अक्सर अधिक वास्तविक failure होता है, क्योंकि यह genuine user gesture को किसी दूसरी request की approval में बदल सकता है।

Apple के AppKit documentation से स्पष्ट है कि application activation एक request है, guarantee नहीं, और macOS desktop को manage करते समय application activation state बदल सकती है। Apple ऐसे APIs भी देता है जो activation behavior के साथ applications launch या open करते हैं। इसलिए approval code को frontmost state को उस समय observe और verify करना चाहिए, न कि card draw करते समय मान लिया गया स्थायी fact समझना चाहिए।

Race को जानबूझकर test करें। Unique nonce वाला harmless approval card दिखाएं। Click किए बिना pointer को card के confirmation control पर ले जाएं। Controlled helper को दूसरी test application activate करने या harmless test window दिखाने के लिए trigger करें। फिर repeated runs में intended click का timing दोहराएं। Mouse-down और mouse-up पर कौन सा application active था, focused element किस window के पास था और protected action शुरू हुई या नहीं, यह सब दर्ज करें।

«Card दिखाई देती रही» को pass न मानें। Visible card inactive हो सकती है। वह दूसरी window के पीछे हो सकती है। उसके controls बने रह सकते हैं, जबकि keyboard focus कहीं और जा चुका हो। Approval path को यह दोबारा जांचना चाहिए कि current request अभी भी displayed card की owner है और app approval consume करते समय active है।

एक मजबूत focus-stealing test set में ये cases शामिल हों:

«नए interaction की जरूरत» वाली बात महत्वपूर्ण है। थोड़ी देर की interruption के बाद focus अपने-आप वापस लाकर original click स्वीकार करना खतरनाक है। व्यक्ति सोच सकता है कि click ने interruption dismiss की, जबकि application उसे approval मान सकती है। Pending decision वापस लें या उसे साफ तौर पर reset करें। App के फिर से निश्चित रूप से active होने के बाद व्यक्ति से नया confirmation शुरू करवाएं।

इसे हल करने के लिए app को जबरन foreground में न लाएं। इससे दूसरी समस्या पैदा होती है: अचानक foreground behavior लोगों को उसके ऊपर click कर आगे बढ़ने की आदत डाल सकता है। Request आने पर card साफ तौर पर सामने आना चाहिए, लेकिन उसे desktop के साथ focus war नहीं करनी चाहिए। गलत समय पर activation खोने पर वह fail closed हो और फिर से पूछे।

Stale cards और request swaps के लिए अलग attack cases रखें

Card direct synthetic click को रोक सकती है, फिर भी गलत action authorize कर सकती है। ऐसा तब होता है जब UI एक request दिखा रहा हो, लेकिन backend दूसरी request पर जा चुका हो।

आम रूप retry bug है। Agent HTTP call मांगता है। Card दिखाई देता है। Agent disconnect और reconnect होकर थोड़े अलग headers के साथ दूसरी request submit करता है। UI मौजूदा card को इसलिए reuse करता है क्योंकि वह समान दिखती है। User जिसे request A समझकर click करता है, वह request B release कर देता है। Identity text सही हो सकता है, फिर भी approval गलत हो सकती है।

Approval को immutable request digest से bind करें। इसमें operation type, destination, credential identity या alias, relevant target details, agent process identity और nonce शामिल करें। किसी protected field में बदलाव हो तो current card invalidate करें। Label को उसी जगह update करके तैयार Approve control बनाए न रखें। Request generation बदलें और पिछली UI instance को किसी भी action को पूरा करने में अक्षम बनाएं।

Test fixture में थोड़े अंतराल में दो requests submit करें:

A: POST staging.example.invalid/echo
   header X-Test-Nonce: alpha-4d8f

B: POST staging.example.invalid/echo
   header X-Test-Nonce: bravo-7a21

Request A का card इतना समय visible रखें कि test operator उसे पहचान सके। फिर उसी agent process से B submit करें। Mouse, keyboard, accessibility action और focus change के बाद confirmation आजमाएं। स्वीकार्य completions केवल ये हैं: A alpha-4d8f के साथ पूरी हो, B अपनी fresh approval के बाद bravo-7a21 के साथ पूरी हो, या कोई भी पूरी न हो। अगर A का visible card B release कर दे, तो इसे release-blocking authorization defect मानें।

इसी तरह ऐसे target change को test करें जो जल्दबाजी में देखने वाले व्यक्ति को मामूली लगे। SSH action में command वही रह सकती है, लेकिन host बदल सकता है। HTTP action में host वही रह सकता है, लेकिन path या injected credential बदल सकता है। Card को request का हर byte दिखाने की जरूरत नहीं, लेकिन security decision को अलग करने वाली details दिखनी चाहिए। Backend को पूरी canonical request से bind करें, केवल दिखाई गई details से नहीं।

यहां expiry tests भी जरूरी हैं। केवल visual effect के लिए countdown न चलाएं। Request expire होने पर उस request generation का backend authorization path revoke करें। फिर exact expiry boundary पर fired Accessibility action और expiry के ठीक बाद पहुंचने वाले mouse-up को test करें। Expected result denial होना चाहिए, साथ में ऐसा reason जो बताए कि expiration, focus loss, generation mismatch या authorization failure में से किसने action रोकी।

Screen recording खत्म होने के बाद logs को argument तय करना चाहिए

जब evidence केवल «मैंने click किया और यह चल गया» हो, approval tests बहस बन जाते हैं। ऐसे records चाहिए जिनसे कोई दूसरा engineer tester की interpretation पर भरोसा किए बिना causal chain दोहरा सके।

दो संबंधित streams record करें: agent run और individual protected call। Run record बताता है कि काम किसने शुरू किया और बाद में वह run revoke हुआ या नहीं। Call record बताता है कि ठीक कौन सी action मांगी गई, approval कैसे resolve हुई और execution शुरू हुआ या नहीं। Approval events को request creation, focus transitions, authorization outcomes और execution के साथ उसी ordered audit story में रखें।

Sallyport agent runs के लिए Sessions journal और individual calls के लिए Activity journal रखता है। दोनों encrypted hash-chained audit log से projected होते हैं। इसका sp audit verify command vault key की जरूरत के बिना ciphertext पर offline chain verify करता है। इससे test team को evidence की integrity जांचने का तरीका मिलता है, न कि ऐसा mutable export जिसे surprising result के बाद चुपचाप बदला जा सके।

किसी भी red team run के लिए ये facts साथ में export या preserve करें:

• Test case name और permission matrix।
• Requesting process identity और उसकी code-signing authority।
• Request digest, visible nonce और request generation।
• Decision method, decision result और denial होने पर उसका reason।
• पहला execution event, या इस बात का स्पष्ट प्रमाण कि कोई execution event मौजूद नहीं है।

Hash chains यह साबित नहीं करतीं कि approval policy सही है। वे इससे संकरी, लेकिन उपयोगी बात साबित करती हैं: log लिखे जाने के बाद investigator जांच सकता है कि record बदला या reorder किया गया है या नहीं। Policy test दूसरा हिस्सा देता है, क्योंकि वह दिखाता है कि application किन events को execution तक पहुंचने देती है।

Log review को test pass criteria का हिस्सा बनाएं। कोई action सही तरह block हो जाए, लेकिन log में केवल «cancelled» दर्ज हो, तो test पूरा नहीं हुआ। आपको synthetic accessibility invocation और user cancellation, stale generation और expired request, focus-loss refusal और app crash में फर्क करना होगा। यही distinctions एक defect report को regression tests के पूरे परिवार में बदलती हैं।

Pass का अर्थ है कि action human decision के पीछे रही

पहली automation script fail होने पर यह दावा न करें कि approval surface secure है। अच्छे red team result का scope छोटा और सटीक होता है: controlled Mac पर, तय permissions के साथ, हर tested synthetic activation और focus-interference path valid authorization token बनाने या protected action शुरू करने में fail हुआ।

सबसे मजबूत tests आपको exceptions की एक असहज लेकिन उपयोगी सूची देते हैं। हो सकता है session approval plain click को अनुमति दे, क्योंकि risk कम है और user ने पहले ही agent process को approve किया है। हो सकता है selected keys के लिए per-call approval Touch ID मांगती हो। हो सकता है app activation खोते ही card cancel हो जाती हो, जिससे कुछ users परेशान हों लेकिन focus race रुक जाती हो। इन decisions को product behavior में स्पष्ट रखें और test करें। Design meeting में मौजूद security helpers से भरे desktop में टिक नहीं पाएगी।

जब भी approval rendering बदलें, नया action channel जोड़ें, process identity handling बदलें या UI decision से execution तक जाने वाले code को refactor करें, यह suite चलाएं। महत्वपूर्ण regression «Accessibility bypass» के नाम से नहीं आएगी। वह harmless cleanup की तरह आएगी, जो callback को कहीं और कर देता है, window reuse करता है या पुरानी request को नई request के बराबर मान लेता है।

अंतिम assertion सीधी रखें: protected action तभी शुरू हो, जब current request को required local authorization मिल जाए। अगर कोई UI automation path इस assertion को false कर सकता है, तो उसे ठीक करने तक approval card केवल सजावट है।