اتوماسیون وابسته به رابط کاربری در برابر پورتال‌های شرکای ثالث

هر سازمانی فهرستی از پورتال‌هایی دارد که کارمندان روزانه به صورت دستی وارد آن‌ها می‌شوند تا کاری انجام دهند که باید خودکار باشد اما نیست. پورتال‌های فروشنده برای بررسی وضعیت سفارش. سایت‌های دولتی برای ارائه گزارش‌های نظارتی. پورتال‌های شرکت‌های بیمه پرداخت برای تأیید واجد شرایط بودن و بررسی وضعیت ادعا. هیئت‌های صدور مجوز ایالتی برای تأیید اعتبارنامه. پورتال‌های مرجع مالیاتی برای ارائه پرونده‌های انطباق.

این پورتال‌ها API ندارند. یا APIهایی دارند که مستند نشده‌اند، محدودیت نرخ دارند، یا محدود به "شرکای ترجیحی" هستند که برای دسترسی پرداخت می‌کنند. داده‌ها پشت یک صفحه ورود زندگی می‌کنند، در HTML رندر می‌شوند، و تنها راه دریافت آن‌ها ورود به سیستم و ناوبری در رابط کاربری است.

اتوماسیون سنتی از اسکریپت‌های مرورگر استفاده می‌کند. اسکریپت‌های Selenium، Playwright، یا Puppeteer که وارد می‌شوند، به صفحه مناسب می‌روند، عناصر را توسط انتخابگر CSS یا XPath پیدا می‌کنند، داده را استخراج می‌کنند، و خارج می‌شوند. این اسکریپت‌ها کار می‌کنند تا زمانی که نکنند. یک بازطراحی پورتال نام‌های کلاس CSS را تغییر می‌دهد. یک CAPTCHA جدید به جریان ورود اضافه می‌شود. منوی ناوبری از نوار کناری به منوی همبرگری منتقل می‌شود. یک بنر رضایت کوکی شروع به پوشاندن دکمه ارسال می‌کند. اسکریپت به‌آرامی خراب می‌شود، و کسی متوجه نمی‌شود تا زمانی که فرآیند پایین‌دستی که به داده بستگی دارد شروع به تولید خطا کند.

هیئت‌های پزشکی ایالتی مثال بسیار بدی هستند. پنجاه تای آن‌ها وجود دارد، هر کدام با وب‌سایت متفاوت، چیدمان‌های متفاوت، روش‌های احراز هویت متفاوت، و تنسیق‌های داده متفاوت. آن‌ها با جدول‌های زمانی خودشان و بدون هیچ اطلاعیه‌ای بازطراحی می‌کنند. یک سرویس تأیید اعتبارنامه که به کشیدن این سایت‌ها متکی است ممکن است در هر لحظه پنج یا ده اسکریپت از پنجاه اسکریپت خود را خراب داشته باشد، که هر کدام نیاز به یک توسعه‌دهنده دارند که چیدمان جدید را بررسی و انتخابگرها را بازنویسی کند.

چگونه Triggerfish این را حل می‌کند

اتوماسیون مرورگر Triggerfish Chromium کنترل‌شده توسط CDP را با ناوبری بصری مبتنی بر LLM ترکیب می‌کند. عامل صفحه را به صورت پیکسل‌های رندرشده و تصاویر دسترسی‌پذیری می‌بیند، نه به عنوان یک درخت DOM. عناصر را بر اساس ظاهر و عملکردشان شناسایی می‌کند، نه نام‌های کلاس CSS. وقتی یک پورتال بازطراحی می‌شود، عامل سازگار می‌شود چون فرم‌های ورود هنوز مثل فرم‌های ورود به نظر می‌رسند، منوهای ناوبری هنوز مثل منوهای ناوبری به نظر می‌رسند، و جداول داده هنوز مثل جداول داده به نظر می‌رسند.

ناوبری بصری به‌جای اسکریپت‌های انتخابگر

ابزارهای اتوماسیون مرورگر از طریق هفت عملیات کار می‌کنند: ناوبری، تصویر، کلیک، تایپ، انتخاب، اسکرول، و انتظار. عامل به یک URL می‌رود، یک تصویر از صفحه رندرشده می‌گیرد، درباره آنچه می‌بیند استدلال می‌کند، و تصمیم می‌گیرد چه اقدامی انجام دهد. هیچ ابزار evaluate که JavaScript دلخواه را در زمینه صفحه اجرا کند وجود ندارد. این یک تصمیم امنیتی آگاهانه است. عامل با صفحه به همان روشی که انسان انجام می‌دهد تعامل می‌کند، از طریق رابط کاربری، و نمی‌تواند کدی اجرا کند که توسط یک صفحه مخرب بهره‌برداری شود.

وقتی عامل با یک فرم ورود روبرو می‌شود، فیلد نام کاربری، فیلد رمز عبور، و دکمه ارسال را بر اساس چیدمان بصری، متن جایگزین، برچسب‌ها، و ساختار صفحه شناسایی می‌کند. نیازی نیست بداند که فیلد نام کاربری id="auth-input-email" یا class="login-form__email-field" دارد. وقتی آن شناسه‌ها در یک بازطراحی تغییر می‌کنند، عامل متوجه نمی‌شود چون هرگز به آن‌ها متکی نبوده.

امنیت دامنه مشترک

ناوبری مرورگر همان پیکربندی امنیتی دامنه را با عملیات واکشی وب به اشتراک می‌گذارد. یک بلوک پیکربندی واحد در triggerfish.yaml لیست‌های رد SSRF، لیست‌های مجاز دامنه، لیست‌های رد دامنه، و نگاشت‌های دامنه به طبقه‌بندی را تعریف می‌کند. وقتی عامل به یک پورتال فروشنده طبقه‌بندی‌شده در CONFIDENTIAL می‌رود، taint جلسه به‌طور خودکار به CONFIDENTIAL تشدید می‌شود، و همه اقدامات بعدی در آن گردش کار مشمول محدودیت‌های سطح CONFIDENTIAL می‌شوند.

لیست رد SSRF کدگذاری‌شده و غیرقابل نادیده گرفتن است. محدوده‌های IP خصوصی، آدرس‌های link-local، و نقاط پایانی ابرداده ابری همیشه مسدود هستند. تفکیک DNS قبل از درخواست بررسی می‌شود تا از حملات DNS rebinding جلوگیری شود. این اهمیت دارد چون اتوماسیون مرورگر بالاترین سطح سطح حمله در هر سیستم عاملی است. یک صفحه مخرب که سعی می‌کند عامل را به یک سرویس داخلی هدایت کند قبل از اینکه درخواست از سیستم خارج شود مسدود می‌شود.

واترمارک‌گذاری نمایه مرورگر

هر عامل نمایه مرورگر خودش را حفظ می‌کند که با کوکی‌ها، ذخیره محلی، و داده‌های جلسه با گذشت زمان انباشته می‌شود. نمایه یک واترمارک طبقه‌بندی دارد که بالاترین سطح طبقه‌بندی استفاده‌شده را ثبت می‌کند. این واترمارک تنها می‌تواند تشدید شود، نه کاهش یابد.

اگر عامل از نمایه مرورگر خود برای ورود به یک پورتال فروشنده CONFIDENTIAL استفاده کند، نمایه با سطح CONFIDENTIAL واترمارک می‌شود. یک جلسه بعدی که در طبقه‌بندی PUBLIC اجرا می‌شود نمی‌تواند از آن نمایه استفاده کند، و از نشت داده از طریق اعتبارنامه‌های کش‌شده، کوکی‌ها، یا توکن‌های جلسه که ممکن است اطلاعات حساسی را در خود داشته باشند جلوگیری می‌کند. جداسازی نمایه به ازای عامل است، و اجرای واترمارک خودکار است.

این یک مشکل ظریف اما مهم در اتوماسیون پورتال را حل می‌کند. نمایه‌های مرورگر حالتی انباشته می‌کنند که داده‌های دسترسی‌یافته را منعکس می‌کند. بدون واترمارک‌گذاری، نمایه‌ای که به یک پورتال حساس وارد شده می‌تواند از طریق پیشنهادهای تکمیل خودکار، داده‌های صفحه کش‌شده، یا کوکی‌های پایدار به یک جلسه با طبقه‌بندی پایین‌تر اطلاعات درز کند.

مدیریت اعتبارنامه

اعتبارنامه‌های پورتال در کیف‌چین کلید سیستم‌عامل (سطح شخصی) یا vault سازمانی (سطح سازمانی) ذخیره می‌شوند، نه در فایل‌های پیکربندی یا متغیرهای محیطی. هوک SECRET_ACCESS هر بازیابی اعتبارنامه را ثبت می‌کند. اعتبارنامه‌ها در زمان اجرا توسط موتور گردش کار تفکیک می‌شوند و از طریق رابط تایپ به جلسات مرورگر تزریق می‌شوند، نه با تنظیم مقادیر فرم به‌صورت برنامه‌ریزی‌شده. این به این معنی است که اعتبارنامه‌ها از همان لایه امنیتی مانند هر عملیات حساس دیگری عبور می‌کنند.

مقاومت در برابر تغییرات رایج پورتال

اینجا چیزی است که وقتی تغییرات رایج پورتال رخ می‌دهند اتفاق می‌افتد:

بازطراحی صفحه ورود. عامل یک تصویر جدید می‌گیرد، چیدمان به‌روز شده را شناسایی می‌کند، و فیلدهای فرم را توسط زمینه بصری پیدا می‌کند. مگر اینکه پورتال به یک روش احراز هویت کاملاً متفاوت (SAML، OAuth، توکن سخت‌افزاری) تغییر کرده باشد، ورود بدون هیچ تغییر پیکربندی کار می‌کند.

بازساختاربندی ناوبری. عامل صفحه را بعد از ورود می‌خواند و بر اساس متن لینک، برچسب‌های منو، و عناوین صفحه نه الگوهای URL به بخش هدف می‌رود. اگر پورتال فروشنده "وضعیت سفارش" را از نوار کناری چپ به یک منوی کشویی ناوبری بالا منتقل کرده باشد، عامل آن را آنجا پیدا می‌کند.

بنر رضایت کوکی جدید. عامل بنر را می‌بیند، دکمه قبول/رد را شناسایی می‌کند، روی آن کلیک می‌کند، و با وظیفه اصلی ادامه می‌دهد. این توسط درک کلی صفحه LLM مدیریت می‌شود، نه توسط یک کنترل‌کننده کوکی با هدف خاص.

CAPTCHA اضافه‌شده. اینجا رویکرد محدودیت‌های صادقانه دارد. CAPTCHA تصویری ساده بسته به قابلیت‌های دید LLM ممکن است قابل حل باشد، اما reCAPTCHA v3 و سیستم‌های تحلیل رفتاری مشابه می‌توانند مرورگرهای خودکار را مسدود کنند. گردش کار اینها را به صف دخالت انسانی هدایت می‌کند نه اینکه به‌آرامی شکست بخورد.

درخواست احراز هویت چندعاملی. اگر پورتال شروع به نیاز به MFA کند که قبلاً لازم نبود، عامل صفحه غیرمنتظره را تشخیص می‌دهد، وضعیت را از طریق سیستم اعلان گزارش می‌دهد، و گردش کار را تا زمانی که یک انسان مرحله MFA را کامل کند متوقف می‌کند. گردش کار می‌تواند برای انتظار برای تکمیل MFA و سپس از سرگیری از جایی که متوقف شده پیکربندی شود.

پردازش دسته‌ای در چندین پورتال

پشتیبانی از حلقه for در موتور گردش کار به این معنی است که یک گردش کار واحد می‌تواند بر روی چندین هدف پورتال تکرار کند. یک سرویس تأیید اعتبارنامه می‌تواند یک گردش کار تعریف کند که وضعیت مجوز را در همه پنجاه هیئت پزشکی ایالتی در یک اجرای دسته‌ای بررسی کند. هر تعامل پورتال به عنوان یک زیر-مرحله جداگانه با جلسه مرورگر خودش، ردیابی طبقه‌بندی خودش، و مدیریت خطای خودش اجرا می‌شود. اگر سه تا از پنجاه پورتال شکست بخورند، گردش کار چهل و هفت تای دیگر را کامل می‌کند و سه شکست را با زمینه خطای دقیق به صف بررسی هدایت می‌کند.

در عمل چگونه به نظر می‌رسد

یک سازمان اعتبارسنجی مجوزهای ارائه‌دهنده مراقبت بهداشتی را در هیئت‌های پزشکی ایالتی به عنوان بخشی از فرآیند ثبت‌نام ارائه‌دهنده تأیید می‌کند. به‌طور سنتی، دستیاران تأیید به صورت دستی وارد وب‌سایت هر هیئت می‌شوند، ارائه‌دهنده را جستجو می‌کنند، وضعیت مجوز را اسکرین‌شات می‌گیرند، و داده را در سیستم اعتبارسنجی وارد می‌کنند. هر تأیید پنج تا پانزده دقیقه طول می‌کشد، و سازمان صدها تا در هفته پردازش می‌کند.

با Triggerfish، یک گردش کار چرخه تأیید کامل را مدیریت می‌کند. گردش کار دسته‌ای از ارائه‌دهندگان با شماره مجوز و ایالت‌های هدفشان دریافت می‌کند. برای هر ارائه‌دهنده، اتوماسیون مرورگر به پورتال هیئت ایالتی مربوطه می‌رود، با اعتبارنامه‌های ذخیره‌شده وارد می‌شود، ارائه‌دهنده را جستجو می‌کند، وضعیت مجوز و تاریخ انقضا را استخراج می‌کند، و نتیجه را ذخیره می‌کند. داده‌های استخراج‌شده در CONFIDENTIAL طبقه‌بندی می‌شوند چون شامل PII ارائه‌دهنده هستند، و قواعد جلوگیری از نوشتن به پایین از ارسال آن به هر کانال زیر آن سطح طبقه‌بندی جلوگیری می‌کنند.

وقتی یک هیئت ایالتی پورتال خود را بازطراحی می‌کند، عامل در تلاش تأیید بعدی سازگار می‌شود. وقتی یک هیئت CAPTCHA اضافه می‌کند که دسترسی خودکار را مسدود می‌کند، گردش کار آن ایالت را برای تأیید دستی علامت‌گذاری می‌کند و پردازش بقیه دسته را ادامه می‌دهد. دستیاران تأیید از انجام دستی همه تأییدها به مدیریت تنها استثناهایی که اتوماسیون نمی‌تواند حل کند تبدیل می‌شوند.