آخرین بهروزرسانی: 28 سپتامبر، 2026

امنیت فایل اکسل توضیح داده شد: XLSX، XLSM و خطرات ماکرو
برای دههها، مایکروسافت اکسل بهعنوان موتور جهانی عملیات تجاری شناخته شده است. این برنامه بودجههای شرکتی را متعادل میکند، مجموعههای داده پیچیده را بهصورت بصری نمایش میدهد، موجودی را ردیابی میکند و خطوط تجزیه و تحلیل را در تقریباً تمام صنایع قدرت میبخشد.
با این حال، همان انعطافپذیری محاسباتی باعث شده است که صفحات گسترده بهعنوان یک هدف دائمی برای دشمنان سایبری باقی بمانند. مهاجمان از زمان اوایل ویروسهای ماکرو در اواخر دههٔ ۱۹۹۰، صفحات گسترده را سلاحگذاری کردهاند. در حالی که مایکروسافت و مدیران سیستم لایههای متعددی از دفاع را معرفی کردهاند — مانند جداسازی فرمت فایل و مسدودسازی پیشفرض ماکروها — مهندسی اجتماعی و ریسکهای معماری ظریف همچنان باعث میشوند حملات متمرکز بر اکسل مرتبط بمانند.
برای ساختن یک وضعیت امنیتی مقاوم، توسعهدهندگان، مدیران و کاربران پیشرفته باید زیر سطح رابط کاربر کتابکار نگاه کنند. درک چگونگی عملکرد فرمت OpenXML زیرین، تفاوتهای سطح معماری بین .xlsx و .xlsm، و مکانیکهای اجرای ماکرو برای دفاع از نقاط انتهایی مدرن حیاتی است.
1. ساختار فایلهای مدرن اکسل: OpenXML تجزیهشده
قبل از انتشار Microsoft Office 2007، اکسل فایلها را عمدتاً با استفاده از فرمتهای باینری اختصاصی ذخیره میکرد، که برجستهترین آن فرمت .xls بود (تحت کنترل Binary Interchange File Format یا BIFF8). در فایلهای .xls، رکوردهای داده، تعاریف قالببندی، فرمولها و جریانهای ماکرو Visual Basic for Applications (VBA) در یک کانتینر ذخیرهسازی ساختاریافته واحد بستهبندی میشدند. این امر بازرسی برنامهنویسی را دشوار میساخت و به مهاجمان اجازه میداد اسکریپتهای مخرب را در بخشهای باینری مبهم پنهان کنند.
از Excel 2007 به بعد، مایکروسافت استاندارد Office Open XML (OOXML) را معرفی کرد (بهعنوان ECMA-376 و ISO/IEC 29500 استاندارد شد). تحت OOXML، کتابکارهای اکسل دیگر بهصورت بلوکهای باینری یکپارچه نیستند. در عوض، آنها آرشیوهای فشرده هستند که شامل ساختار سلسلهمراتبی اسناد XML، جداول روابط و داراییهای رسانهای جاسازیشده میباشند.
درون محفظه ZIP
اگر هر کتاب کار مدرن استاندارد اکسل را بگیرید و پسوند آن را به .zip تغییر دهید، میتوانید محتویات آن را با هر ابزار استاندارد فشردهسازی استخراج کنید:
my_workbook.xlsx (extracted)
│
├── [Content_Types].xml <-- Registry of MIME types and structural parts
├── _rels/ <-- Package-level relationship mappings
│ └── .rels
├── docProps/ <-- Metadata (author, creation date, revision)
│ ├── app.xml
│ └── core.xml
└── xl/ <-- Core spreadsheet contents
├── workbook.xml <-- Workbook-level parameters and sheet list
├── styles.xml <-- Cell styles, fonts, and borders
├── sharedStrings.xml <-- Unique string index for performance optimization
├── _rels/
│ └── workbook.xml.rels <-- Sheet and component dependencies
└── worksheets/
├── sheet1.xml <-- Raw cell values, formulas, and grid geometry
└── sheet2.xml
این تغییر ساختاری مزایای امنیتی فوری را فراهم کرد:
- DPI (بازرسی عمیق بسته) و قابلیت مشاهده دروازه: دستگاههای امنیتی، پروکسیها و عوامل نقطه انتهایی میتوانند آرشیو را بهصورت زنده باز کنند و درختهای XML متنی را تجزیه کنند تا رشتههای مشکوک، URLهای خارجی یا اشیای جاسازیشده را شناسایی کنند.
- تأیید فایل بهصورت قطعی: اگر فایلی ادعا کند یک سند OpenXML است اما قوانین طرحواره را نقض کند، اکسل از باز کردن آن خودداری میکند یا آن را در حالت بازیابی ایزوله اجرا میکند.
- جداسازی فرمت: مایکروسافت صفحاتگسترده محاسباتی معمولی را از فایلهایی که قادر به اجرای اسکریپتهای رویهای جاسازیشده هستند، جدا کرد.
۲. XLSX vs. XLSM: مرز معماری
تفاوت اصلی بین .xlsx و .xlsm در این است که آیا ساختار فایل اجازهٔ گنجاندن پروژههای ماکرو اجرایی را میدهد یا نه.
| ویژگی / بعد | .xlsx (صفحهگسترده OpenXML اکسل) | .xlsm (صفحهگسترده اکسل با ماکرو) |
|---|---|---|
| نوع محتوای MIME | application/vnd.openxmlformats-officedocument.spreadsheetml.sheet | application/vnd.ms-excel.sheet.macroEnabled.12 |
| محفظه ذخیرهسازی VBA | بهطور سفت و سخت ممنوع. نمیتوان vbaProject.bin را ذخیره کرد | مجاز. شامل xl/vbaProject.bin |
| خطر اجرای بومی | ناچیز برای اجرای ماکرو؛ محدود به تزریق فرمول/DDE | بالا؛ میتواند کد VBA خودکار را هنگام تعامل با کتابکار اجرا کند |
| طرحوارهٔ OpenXML Strict | مطابق با تعاریف XML سختگیرانه و بدون ماکرو | شامل تعاریف برای افزونههای اتوماسیون قدیمی و مدرن |
| نشانگر بصری کاربر | آیکون صفحهگسترده سبز استاندارد | آیکون صفحهگسترده با نشان تعجب |
مکانیزم اجرای قانون: چرا XLSX نمیتواند ماکروها را اجرا کند
یک سؤال رایج میان مدیران و توسعهدهندگان تازهکار این است: اگر یک مهاجم یک فایل مخرب .xlsm بگیرد، کد اجرایی را تزریق کند و پسوند فایل را به .xlsx تغییر دهد، چه اتفاقی میافتد؟
پاسخ کوتاه: فایل ماکرو را اجرا نخواهد کرد.
اکسل بهطور کامل به پسوند فایل برای تعیین قوانین اجرا تکیه نمیکند. هنگام باز کردن فایلی با نام .xlsx:
- اکسل محتوای فشرده (zip) را بررسی میکند و به
[Content_Types].xmlارجاع میدهد. - در یک فایل واقعی
.xlsx، تمام انواع محتوا تعریفشده نمایانگر عناصر داده استاندارد هستند (مانندworksheet،sharedStringsیاstyles). - اگر یک مهاجم بهصورت دستی یک جریان VBA کامپایلشده (
xl/vbaProject.bin) را به بستهٔ.xlsxتزریق کند و روابط (relationships) را بهروز رسانی کند، اکسل با یک تناقض واضح در طرحواره (schema) مواجه میشود:- اکسل یک پسوند
.xlsxرا میبیند که به انواع محتوا مرتبط است که قابلیت ماکرو را نشان میدهند. - اکسل یک خطای جدی یکپارچگی میاندازد: “اکسل نمیتواند فایل ‘filename.xlsx’ را باز کند زیرا قالب یا پسوند فایل معتبر نیست. اطمینان حاصل کنید که فایل خراب نشده است…”
- اکسل یک پسوند
- اگر مهاجم انواع داخلی را دستنخورده بگذارد بدون اینکه باینری را ثبت کند، اکسل
vbaProject.binرا بهعنوان یک پیوست بدون ارجاع و یتیم درون آرشیو zip در نظر میگیرد و آن را بهطور کامل در طول چرخه بارگذاری حذف میکند.
در نتیجه، فایلی که بهطور دقیق بهعنوان یک کانتینر واقعی .xlsx عمل میکند نمیتواند کد بومی VBA را اجرا کند. اما این به این معنی نیست که فایلهای .xlsx از تمام مسیرهای حمله آزاد هستند، همانطور که در ادامه این راهنما بررسی میشود.
۳. ریسکهای ماکرو و چرخه حیات حمله
ماکروها برای خودکارسازی وظایف تکراری حسابداری، مدلسازی مالی و دستکاری دادهها از طریق Visual Basic for Applications (VBA) طراحی شدند. از آنجا که VBA برای اتوماسیون محیط کار ساخته شده بود، دسترسی گستردهای به سیستمعامل ویندوز زیرین از طریق Component Object Model (COM)، Windows Script Host (WSH) و فراخوانیهای مستقیم Win32 API فراهم شد.
هنگامی که یک ماکرو غیرقابل اعتماد اجرا میشود، با دسترسی دقیقاً مشابه کاربر وارد شده اجرا میگردد. این ماکرو در یک محیط ایزولهسازی مرورگر شبیهسازیشده به سبک JavaScript محبوس نمیشود.
+--------------------------------------------------------------------------------+
| ATTACK LIFECYCLE |
+--------------------------------------------------------------------------------+
│
▼
[ Delivery & Evasion ] ──────► Spear-phishing email with .xlsm, .xlam, or .zip.
│
▼
[ Social Engineering ] ──────► Lures victim to bypass Protected View ("Enable Content").
│
▼
[ Auto-Execution ] ──────► Auto_Open() or Workbook_Open() triggers automatically.
│
▼
[ System Invocation ] ──────► VBA creates COM objects (WScript.Shell, WinHttp.WinHttpRequest).
│
▼
[ Payload Retrieval ] ──────► Spawns hidden PowerShell/cURL to fetch staging binary.
│
▼
[ Post-Exploitation ] ──────► In-memory execution, credential theft, lateral movement.
تکنیکهای رایج ورود ماکرو
هوکهای خودکار اجرا: حملهکنندگان نقطه ورود خود را در داخل هندلرهای رویداد ذاتی مانند
Sub Auto_Open()یاPrivate Sub Workbook_Open()قرار میدهند. به محض اینکه کاربر اجازه اجرا را بدهد، این روتینها بدون نیاز به کلیک داخل صفحهگسترده فعال میشوند.پنهانسازی و Stomping:
- پنهانسازی رشته: بارهای مخرب URLها و فراخوانیهای سیستم را با استفاده از آرایههای کاراکتری، رمزگذاری XOR، رمزگشایی Base64، یا ترکیب متغیرهای محیطی (مثلاً
Chr(112) & Chr(111) & Chr(119)...) مخفی میکنند. - VBA Stomping: VBA در داخل
vbaProject.binبه دو شکل وجود دارد: کد منبع تفسیرشده و p-code کامپایلشده (کد شبهپروگرام هدفگذاریشده برای نسخه خاص Office که آن را کامپایل کرده است). حملهکنندگان میتوانند کد منبع واضح را بهطور کامل پاک کنند و فقط p-code کامپایلشده باقی بماند. بسیاری از راهحلهای آنتیویروس پایه و تجزیهگرهای ایستاتیک فقط جریان منبع را بررسی میکنند و p-code تا زمانی که توسط نسخهٔ Office مطابقت داشته باشد، کشف نمیشود.
- پنهانسازی رشته: بارهای مخرب URLها و فراخوانیهای سیستم را با استفاده از آرایههای کاراکتری، رمزگذاری XOR، رمزگشایی Base64، یا ترکیب متغیرهای محیطی (مثلاً
استفاده از ابزارهای بومی (LotL): ماکروهای مخرب مدرن به ندرت یک فایل
.exeرا مستقیماً روی دیسک میاندازند، که بلافاصله عوامل تشخیص و پاسخ به نقطه انتهایی (EDR) را هشدار میدهد. در عوض، آنها با ابزارهای سیستمی داخلی تعامل میکنند:- ایجاد نمونهٔ
WScript.Shellبرای اجرای آرگومانهای خط فرمان. - فراخوانی
PowerShell.exeبا دور زدن سیاست اجرای (-ExecutionPolicy Bypass -WindowStyle Hidden). - فراخوانی APIهای بومی Win32 از طریق
Declare PtrSafe Function CreateProcessیاVirtualAllocبرای تزریق شلکد مستقیم به حافظه سیستم.
- ایجاد نمونهٔ
۴. بردارهای تهدید دیگر در صفحات گسترده (فراتر از VBA استاندارد)
ایمنسازی یک محیط در برابر فایلهای .xlsm تنها نیمی از مبارزه است. دشمنان همچنین از مکانیزمهایی استفاده میکنند که بهصورت مستقل از VBA سنتی عمل میکنند.
تبادل داده پویا (DDE) و تزریق CSV
اکسل دارای یک پروتکل قدیمی به نام Dynamic Data Exchange (DDE) است که برای امکانپذیر کردن اشتراکگذاری دادهها بین برنامههای در حال اجرا طراحی شده است (به عنوان مثال، پخش زنده دادههای تیکر سهام از یک برنامه جداگانه به یک سلول اکسل).
- نحوه عملکرد تزریق فرمول:
زمانی که یک سلول صفحهگسترده با کاراکترهایی مانند
=,@,+یا-شروع میشود، اکسل محتوا را بهعنوان یک فرمول تفسیر میکند. اگر یک مهاجم ورودیای که بهصورت CSV یا XLSX به یک صفحهگسترده صادر میشود (مانند فیلد “Comments” بدون پاکسازی در یک برنامه وب) را کنترل کند، میتواند تزریق کند:=cmd|'/C powershell.exe -w hidden -enc <base64_payload>'!A0 - هنگامی که باز میشود، اکسل فرمول را ارزیابی میکند، با یک پیام هشدار به کاربر دربارهٔ شروع یک برنامه خارجی اطلاع میدهد و در صورت تأیید، شل سیستم را اجرا میکند.
ماکروهای قدیمی Excel 4.0 (XLM)
قبل از معرفی VBA در سال 1993، اکسل از یک سیستم ماکرو مبتنی بر فرمول به نام ماکروهای Excel 4.0 (XLM) استفاده میکرد. این ماکروها در داخل شیتهای ماکرو اختصاصی قرار میگیرند نه در یک پروژه VBA جداگانه.
به دلیل اینکه ماکروهای XLM بهصورت فرمولهای سلولی (مانند =EXEC(\"calc.exe\")) نوشته میشوند، بسیاری از موتورهای بازرسی ایستای استاندارد VBA را دور میزنند. مهاجمان در اواخر دهه ۲۰۱۰ و اوایل ۲۰۲۰ به ماکروهای XLM ترجیح میدادند تا از شناسایی خودکار فرار کنند، پیش از این که مایکروسافت آنها را بهصورت پیشفرض در نسخههای جدید سازمانی غیرفعال کند.
اتصالات خارجی مخرب و اشیاء OLE
یک کتاب کار .xlsx معمولی همچنان میتواند از طریق منابع خارجی خطر ایجاد کند:
- پکیجهای OLE جاسازیشده: یک مهاجم میتواند یک فایل اجرایی مخفیشده بهصورت آیکون PDF جاسازیشده را مستقیماً درون شیت وارد کند.
- لینکهای کتاب کار خارجی و پرسوجوهای وب: یک فایل XLSX میتواند شامل مراجع خارجی باشد که بهصورت خودکار درخواستهای HTTP GET به سرورهای فرمان و کنترل (C2) تحت کنترل مهاجم هنگام باز کردن فایل ارسال میکند، که عمدتاً برای شناسایی یا حملات جمعآوری هش netNTLM استفاده میشود.
5. تقویت سازمانی و استراتژیهای دفاع در عمق
دفاع در برابر تهدیدات ناشی از اکسل نیاز به رویکرد لایهای دارد که شامل بازرسی شبکه، پیکربندی سیستم، کنترلهای دسترسی و فرآیندهای عملیاتی میشود.
+─────────────────────────────────────────────────────────+
| ENTERPRISE DEFENSE LAYERS |
+─────────────────────────────────────────────────────────+
| PERIMETER: Drop inbound .xlsm, .xla, and .xltm at mail |
| gateway unless cryptographically signed or exempted. |
+---------------------------------------------------------+
| IDENTITY & POLICY: Enforce ASR rules and apply |
| Mark of the Web (MotW) macro execution blocks. |
+---------------------------------------------------------+
| RUNTIME: Hook AMSI into Office to evaluate dynamic |
| VBA buffers directly before execution. |
+---------------------------------------------------------+
| STORAGE: Restrict macro execution exclusively to |
| managed, centralized Trusted Locations. |
+─────────────────────────────────────────────────────────+
1. اعمال علامت وب (MotW) برای مسدودسازی ماکروها
در سال ۲۰۲۲، مایکروسافت رفتار پیشفرض برنامههای Office را بهروزرسانی کرد: ماکروها در فایلهایی که از اینترنت آمدهاند بهصورت بهطور پیشفرض مسدود میشوند.
هنگامی که کاربر فایلی را از طریق مرورگر یا کلاینت خارجی دانلود میکند، ویندوز فایل را با یک جریان داده جایگزین (ADS) به نام Zone.Identifier (منطقه ۳ نشاندهنده اینترنت است) برچسب میزند. برای فایلهایی که این علامت را دارند، اکسل ماکروها را بهطور کامل غیرفعال میکند و بنر امنیتی قرمز نشان میدهد: > “ریسک امنیتی: مایکروسافت ماکروها را از اجرا مسدود کرده است زیرا منبع این فایل غیرقابل اعتماد است.”
اقدام اداری: اطمینان حاصل کنید که این رفتار از طریق Group Policy اعمال میشود و کاربران نهایی نمیتوانند آن را نادیده بگیرند:
- مسیر GPO:
User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center - تنظیم: فعالسازی “مسدود کردن ماکروها از اجرا در فایلهای Office از اینترنت”.
2. پیکربندی قوانین کاهش سطح حمله (ASR)
سازمانهایی که از Microsoft Defender for Endpoint استفاده میکنند باید قوانین اصلی کاهش سطح حمله (Attack Surface Reduction) که بهطور خاص برای برنامههای Office طراحی شدهاند را فعال کنند:
Block Office applications from creating child processes(GUID:D4F940AB-401B-4EFC-AADC-AD5F3C50688A)- از راهاندازی PowerShell، CMD یا موتورهای اسکریپت توسط Excel جلوگیری میکند.
مسدود کردن برنامههای Office از تزریق کد به فرآیندهای دیگر(GUID:75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)مسدود کردن فراخوانیهای Win32 API از ماکروهای Office(GUID:92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)
3. بهرهگیری از رابط اسکن ضدبدافزار (AMSI)
نسخههای مدرن Microsoft 365 اجرای VBA را مستقیماً با AMSI یکپارچه میکنند. حتی اگر یک مهاجم از مبهمسازی پیچیده رشتهها یا VBA stomping استفاده کند، موتور زمان اجرا VBA دستورات بازسازیشده و بدون رمزگذاری را دقیقاً یک میلیثانیه قبل از اجرا به موتور آنتیویروس/EDR نصبشده شما میفرستد. اطمینان حاصل کنید که حفاظت نقطه انتهایی شما بهطور فعال رویدادهای زمان اجرا AMSI را نظارت میکند.
4. انتقال به مکانهای مورد اعتماد و گواهیهای دیجیتال
برای سازمانهایی که به صفحاتگسترده خودکار برای عملیات روزانه وابسته هستند:
- حذف فایلهای XLSM پراکنده در پوشههای دانلود یا دسکتاپ کاربران.
- استفاده از مکانهای مورد اعتماد: محدود کردن اجرای ماکروها بهطور انحصاری به اشتراکگذاریهای شبکه فقط-خواندنی که توسط مدیران فناوری اطلاعات مدیریت میشوند.
- امضای کد: اجبار به این که تمام ماکروهای داخلی توسعهیافته با استفاده از گواهی صادر شده توسط زیرساخت کلید عمومی (PKI) سازمانی بهصورت رمزنگاریشده امضا شوند. Excel را طوری تنظیم کنید که فقط ماکروهای دیجیتالی امضا شده را اجرا کند و بهصورت ساکت ماکروهای بدون امضا را مسدود سازد.
6. دیدگاه توسعهدهنده: ساخت خودکارسازی ایمن
اگر در حال ساخت نرمافزاری هستید که فایلهای Excel را تجزیه، تولید یا مصرف میکند (مثلاً خطوط لوله Python با استفاده از pandas/openpyxl، میکروسرویسهای Node.js، یا برنامههای C#/.NET)، این اقدامات ایمنی توسعه را اعمال کنید:
رد کردن فرمتهای فایل غیرمنتظره در مرز بارگذاری: اگر برنامه شما انتظار گزارشهای مالی را دارد، بهدقت صحت فایلهای ورودی را که باید با
.xlsxمطابقت داشته باشند، اعتبارسنجی کنید. بایتهای جادویی داخلی (سرآیند استاندارد zip50 4B 03 04) را بررسی کنید و اطمینان حاصل کنید که هیچ ورودیvbaProject.binدر فهرست آرشیو وجود ندارد قبل از ذخیرهسازی در سطلهای ابری یا پایگاههای داده.پاکسازی دادهها در برابر تزریق فرمول: هنگام خروجیگیری ورودیهای تولید شده توسط کاربر به فایلهای CSV یا XLSX، یک علامت کوتیشن (
') یا یک فاصله به هر سلولی که با کاراکترهای خطرناک (=,+,-,@,\t,\r) شروع میشود، اضافه کنید:def sanitize_for_spreadsheet(value: str) -> str: if value and value[0] in ('=', '+', '-', '@', '\t', '\r'): return f"'{value}" return valueانتقال از VBA به Office Scripts یا افزونههای وب: برای خودکارسازی مدرن سازمانی، VBA قدیمی را بهطور کامل حذف کنید:
- Office Scripts: نوشته شده به TypeScript، Office Scripts در یک محیط ابری ایزوله اجرا میشوند و بهصورت یکپارچه در نسخههای وب و دسکتاپ کار میکنند بدون اینکه فراخوانیهای سیستمعامل بومی را افشا کنند.
- افزونههای وب آفیس: ساخته شده با استفاده از HTML، CSS استاندارد و جاوااسکریپت مدرن، افزونههای وب از طریق APIهای مدیریتشده جاوااسکریپت ارتباط برقرار میکنند و از سیستمعامل محلی جدا هستند.
7. فهرست بررسی خلاصه برای امنیت صفحات گسترده
- اجبار
.xlsxبهصورت پیشفرض: نیازمند این است که تمام جریانهای کاری استاندارد کاربر بهصورت بدون ماکرو.xlsxذخیره شوند. - مسدود کردن ماکروهای منبع اینترنت: تأیید کنید که اجرای سیاست MotW در سراسر سازمان شما از طریق GPO یا Intune اعمال شده است.
- فعالسازی قوانین ASR: جلوگیری از این که محصولات آفیس مفسرهای دستوری یا فرآیندهای فرعی ایجاد کنند.
- منسوخسازی Excel 4.0 (XLM): اطمینان حاصل کنید که موتورهای ماکرو XLM قدیمی بهصورت دائمی در تمام ایستگاههای کاری غیرفعال شدهاند.
- پاکسازی خروجیهای برنامه: محافظت از روتینهای تولید CSV و Excel در برابر تزریق CSV/فرمول.
- انتقال به سمت Office Scripts: ماکروهای اداری قدیمی را به Office Scripts مبتنی بر TypeScript و APIهای مدیریتشده تبدیل کنید.
با در نظر گرفتن صفحات گسترده نه تنها بهعنوان فایلهای سند، بلکه بهعنوان کانتینرهای نرمافزاری ساختار یافتهای که قابلیت اجرا دارند، تیمهای امنیتی و توسعهدهندگان میتوانند بهطور مؤثر یکی از قدیمیترین مسیرهای حمله در محاسبات سازمانی را خنثی کنند.
سوالات متداول (FAQ)
سوال ۱: آیا فایلی که با پسوند .xlsx پایان مییابد میتواند ماکروی مخرب اجرا کند؟
نه، استاندارد OpenXML بهطور سختگیرانه کد ماکرو را در فایلهای .xlsx ممنوع میکند و اکسل هر پروژه VBA که به یک کانتینر واقعی .xlsx تزریق شود را رد یا حذف خواهد کرد.
سوال ۲: اگر یک فایل اکسل از من بخواهد “Enable Editing” یا “Enable Content” را فعال کنم، چه کاری باید انجام دهم؟
فقط در صورتی که فرستنده را میشناسید و فایل را انتظار داشتهاید، اجازه بدهید؛ این پیام اصلیترین نقطه بررسی است که به ماکروهای غیرقابل اعتماد اجازه اجرای کد میدهد.
سوال ۳: مایکروسافت اکسل چگونه تشخیص میدهد که یک فایل از اینترنت آمده است؟
ویندوز یک جریان مخفی "Mark of the Web" (Zone.Identifier) را به فایلهای دانلود شده اضافه میکند که به اکسل میگوید آنها را در نمای محافظتشده باز کند و بهصورت پیشفرض ماکروها را مسدود کند.
سوال ۴: آیا فایلهای CSV نسبت به فایلهای XLSX و XLSM ایمنتر هستند؟
فایلهای CSV نمیتوانند ماکروهای VBA بومی داشته باشند، اما اگر شامل دستورات مخرب باشند که توسط اکسل هنگام باز شدن اجرا میشوند، در برابر حملات تزریق فرمول آسیبپذیر میمانند.
سوال ۵: اسکریپتهای مدرن Office چگونه با ماکروهای سنتی VBA متفاوت هستند؟
اسکریپتهای Office بر پایه TypeScript در یک محیط زمان اجرا ایزوله اجرا میشوند و از دسترسی به سیستم فایل محلی، خط فرمان یا APIهای سیستمعامل جلوگیری میکنند.