آخرین به‌روزرسانی: 20 Aug, 2026
بهترین شیوه‌های امنیتی صفحه‌گسترده برای توسعه‌دهندگان
صفحات گسترده عملیات کسب‌وکار مدرن را اجرا می‌کنند. از پیش‌بینی‌های مالی و گزارش‌های هیئت‌مدیره اجرایی تا واردات انبوه کاربران، خروجی‌های صورتحساب و مجموعه‌های داده یادگیری ماشین، فرمت‌هایی مانند .xlsx، .xlsm و .csv پایه‌ای برای جریان‌های کاری سازمانی هستند. به دلیل این فراوانی، مهندسان نرم‌افزار به‌طور معمول کدی می‌نویسند که برای تولید، دریافت، تجزیه، تبدیل و خروجی‌گیری فایل‌های صفحه‌گسترده طراحی شده است.
با این حال، توسعه‌دهندگان اغلب صفحات گسترده را به‌عنوان داده‌های جدولی بی‌ضرر — معادل دیجیتال یک فایل متنی ساده — در نظر می‌گیرند. در واقع، صفحات گسترده مدرن محیط‌های اجرایی فعالی هستند که قادر به اجرای محاسبات پویا، حل نقاط انتهایی خارجی، فراخوانی ماکروهای سیستم، و جاسازی اشیاء باینری دلخواه می‌باشند. وقتی به‌صورت سهل‌انگارانه رفتار شود، خطوط پردازش صفحات گسترده تبدیل به اهداف سودآوری برای اجرای کد از راه دور (RCE)، تزریق فرمول (CSV Injection)، جعل درخواست سمت سرور (SSRF)، حمله به موجودیت خارجی XML (XXE) و نشت داده‌های محرمانه می‌شوند.
در ادامه راهنمای فنی برای پیاده‌سازی روش‌های مهندسی دفاعی هنگام کار با صفحات گسترده در سراسر پشته نرم‌افزاری شما ارائه شده است.
خنثی‌سازی تزریق فرمول (CSV & تزریق صفحه‌گسترده)
تزریق فرمول—که اغلب به عنوان تزریق CSV شناخته می‌شود—زمانی رخ می‌دهد که ورودی‌های نامطمئن کاربر به‌صورت مستقیم در سلول‌های صفحه‌گسترده بدون پاک‌سازی مناسب نوشته شوند.
هنگامی که یک کاربر نهایی یا مدیر فایل تولید شده را در Microsoft Excel، Google Sheets یا LibreOffice Calc باز می‌کند، هر مقدار سلولی که با کاراکترهای عملکردی خاص پیشوند داشته باشد به‌عنوان یک فرمول فعال تفسیر و اجرا می‌شود نه اینکه به‌صورت متن ثابت نمایش داده شود.
مکانیک‌های تهدید
حمله‌کنندگان از تزریق فرمول برای اجرای دو دسته اصلی حمله استفاده می‌کنند:
- استخراج داده: بهره‌برداری از توابعی مانند
HYPERLINKبرای افزودن بی‌صدا داده‌های حساس سلول‌های مجاور به پارامتر پرس‌وجوی تحت کنترل مهاجم. - اجرای فرمان: استفاده از فرمول‌های Dynamic Data Exchange (DDE) (مثلاً در پیکربندی‌های قدیمی) یا لینک‌های مدیریت پروتکل برای فعال‌سازی باینری‌های سیستم یا راه‌اندازی URLهای مخرب.
کاراکترهای پیشرو خطرناک شامل:
=(محاسبه مستقیم یا فراخوانی تابع)+(اضافه‌کردن فرمول یا فراخوانی تابع به‌صورت ضمنی)-(کاهش فرمول یا پیشوند منفی)@(فراخوانی فرمول آرایه پویا در نسخه‌های مدرن اکسل)\t(کاراکتر تب) یا\r(کاراکتر بازگشت) (برای دور زدن فیلترهای ساده استفاده می‌شود)|یا%(عملیات لوله‌ای یا فراخوانی شل در نمایشگرهای صفحه‌گسترده مبتنی بر یونیکس)
دفاع‌های مهندسی
- پیشوند کاراکتری (Escaping تک‌نقل‌قول): اگر ورودی رشته‌ای غیرقابل اعتماد با
=,+,-,@,\t, یا\rشروع شود، قبل از نوشتن به سلول، یک تک‌نقل‌قول (') به ابتدای رشته اضافه کنید. اکسل و لیبرآفیس تک‌نقل‌قول پیشرو را به‌عنوان یک دستور قالب‌بندی در نظر می‌گیرند و سلول را مجبور می‌کنند که دقیقاً به‌عنوان متن خام نمایش داده شود در حالی که این نقل‌قول از خروجی قابل مشاهده حذف می‌شود. - کتابخانه‌های سریال‌سازی سختگیرانه: هرگز فایل‌های CSV یا XLSX را با استفاده از درون‌ریزی رشته‌ای خام (مثلاً
f\"{user_input_1},{user_input_2}\n\") نساختید. به کتابخانه‌های سریال‌سازی جدولی که به‌صورت آزمایش‌شده مدیریت escaping جداکننده RFC 4180، بسته‌بندی فیلدها و دو برابر کردن نقل‌قول‌ها را به‌صورت خودکار انجام می‌دهند، تکیه کنید. - اجرای نوع سلول: هنگام تولید برنامه‌نویسی فایل‌های OpenXML (
.xlsx)، به‌طور صریح نوع داده سلول را به عنوانString(یاInlineString) تعریف کنید به‌جای اینکه موتور نوع سلول‌ها را از مقادیر استنتاج کند.
۲. سخت‌سازی ورودی و خطوط لوله تجزیه‌کننده
تجزیه و تحلیل صفحات گسترده‌ای که توسط کاربر بارگذاری می‌شوند، سامانه‌های پشتیبان را در معرض سطوح حملهٔ مهم در سطح پارسر قرار می‌دهد. فایل‌های .xlsx مدرن، آرشیوهای فشردهٔ ZIP هستند که شامل اسناد XML وابسته به یکدیگر می‌باشند و مطابق با استاندارد Open Packaging Conventions (OPC) هستند.
تجزیه XML غیرقابل اعتماد در سمت سرور، سرویس‌های شما را در معرض بهره‌برداری‌های کلاسیک پارسر قرار می‌دهد، اگر پیکربندی پارسر به تنظیمات پیش‌فرض باقی بماند.
استراتژی‌های کاهش خطر:
- غیرفعال‌سازی DTDها و موجودیت‌های خارجی (دفاع در برابر XXE): اطمینان حاصل کنید که موتور XML شما به‌صراحت تعریف‌های نوع سند (Document Type Definitions یا DTDها) را ممنوع می‌کند و حل‌کردن طرح‌واره‌های خارجی را غیرفعال می‌سازد (
disallow-doctype-decl = true,resolve-external-entities = false). عدم انجام این کار می‌تواند اجازه دهد یک فایل.xlsxبارگذاری‌شده، فایل‌های محلی سرور (مانند/etc/passwd) را بخواند یا سرویس‌های داخلی ابری را بررسی کند. - حفاظت در برابر بمب‌های فشرده‌سازی (ZIP Bombs): کاربران مخرب می‌توانند آرشیوهای کوچکی را ارسال کنند که پس از استخراج به ده‌ها گیگابایت دادهٔ XML تکراری گسترش می‌یابند و باعث سقوط حافظه و مصرف تمام فضای دیسک می‌شوند. بایت‌های غیر فشرده را در طول استخراج ردیابی کنید و محدودیت‌های سخت برای هر دو اندازهٔ آرشیو فشرده و ردپای حافظهٔ کل استخراج‌شده اعمال کنید.
- پذیرش تجزیه‌کننده‌های جریان‌دار: از بارگذاری صفحات گسترده بزرگ به نمایه‌های شیء مدل سند (DOM) در حافظه جلوگیری کنید. برای واردات دسته‌ای بزرگ، از جریان‌دار، مبتنی بر SAX، یا تکرارگرهای قطعه‌قطعه سطر به سطر استفاده کنید تا مصرف حافظهٔ پشتیبان ثابت بماند.
۳. کنترل‌های ماکرو و پاک‌سازی محتوای فعال
ماکروهای Visual Basic for Applications (VBA)، بارهای OLE (Object Linking and Embedding) و اسکریپت‌های جاسازی‌شده برخی از پایدارترین مسیرهای حمله در محاسبات دسکتاپ را تشکیل می‌دهند.
بهترین شیوه‌های توسعه‌دهنده:
- اجرای سیاست‌های سخت‌گیرانهٔ پسوند: فرمت‌های فایل فعال‌سازی ماکرو (
.xlsm،.xltm،.xlsb، یا.xlsقدیمی) را در دروازهٔ API خود رد کنید مگر اینکه نیاز تجاری تأییدشده و غیرقابل تغییر برای پردازش آن‌ها وجود داشته باشد. - اجرای فرمت‌های پاک
.xlsx: فرمت استاندارد محفظهٔ.xlsxبه‌صورت ساختاری بدون پشتیبانی از ماکرو طراحی شده است. هر کد ماکرویی که در یک فایل.xlsxوجود داشته باشد، فرمت فایل را در موتورهای Office سازگار نامعتبر می‌کند. - بازرسی و حذف جریان‌های فعال: اگر سرویس شما پیوست‌های دلخواه را پردازش می‌کند، یک مرحلهٔ خودکار پاک‌سازی یکپارچه کنید که باینری‌های پروژهٔ VBA (
vbaProject.bin)، کنترل‌های ActiveX و بسته‌های OLE جاسازی‌شده را پیش از ذخیرهٔ فایل‌ها در ذخیره‌سازی شیء یا ارائهٔ آن‌ها به سایر مشتریان حذف کند.
۴. جلوگیری از SSRF در پیش‌نمایش‌های بدون سر و تبدیل PDF
برنامه‌های سازمانی مدرن معمولاً کارت‌های پیش‌نمایش سند یا تولید خودکار گزارش‌های PDF را ارائه می‌دهند. برای انجام این کار، بک‌اندها اغلب از مجموعه‌های اداری بدون سر (مانند LibreOffice در حالت headless) یا مرورگرهای بدون سر استفاده می‌کنند.
صفحات گسترده می‌توانند وابستگی‌های خارجی پویا داشته باشند، مانند فرمول‌های تصویر پیوندی (=IMAGE("http://internal-host/..."))، لینک‌های OData دوردست، یا فریم‌های وب توکار. زمانی که پردازشگر بدون سر صفحه گسترده را رندر می‌کند، ممکن است به‌صورت خودکار این منابع پیوندی را دریافت کند و باعث دستکاری درخواست سمت سرور (SSRF) شود.
اقدامات دفاع در عمق:
- ایزوله‌سازی محیط‌های تبدیل: سرویس‌های رندرینگ بدون سر را در میکرو‑کانتینرهای ایزوله یا توابع سرورلس موقت اجرا کنید که با حداقل امتیازات سیستم مجهز شده‌اند.
- اجرای ایزولاسیون شبکه: کارگران رندرینگ سند را در زیربخش‌های محدود قرار دهید که دسترسی مسیری به VPC داخلی شما، پایگاه‌های داده خصوصی یا نقطهٔ انتهایی متادیتای ابری (
169.254.169.254) ندارند. - غیرفعال‌سازی حل منابع دوردست: پرچم‌های پیکربندی را به موتور رندرینگ خود پاس دهید تا حل دارایی‌های مبتنی بر شبکه را ممنوع کنید (مثلاً، به LibreOffice بگویید بارگذاری منابع خارجی را در طول روتین‌های خروجی رد کند).
۵. حفاظت از شیت در مقابل رمزنگاری واقعی فایل
یکی از اشتباهات مداوم در میان تیم‌های محصول، تفاوت بین محافظت بومی برگه/کتاب کار در اکسل و رمزنگاری کریپتوگرافیک است.
توهم “قفل شده” سلول‌ها
ویژگی‌های بومی اکسل “Protect Sheet” و “Protect Workbook” امکانات سطح رابط کاربری هستند که برای جلوگیری از ویرایش‌های ناخواسته توسط کارمندان اداری طراحی شده‌اند. آن‌ها از موانع دسترسی رمزنگاری‌شده استفاده نمی‌کنند. یک اسکریپت ساده می‌تواند برچسب‌های محافظت برگه را مستقیماً از فایل‌های XML زیرین داخل یک آرشیو .xlsx در عرض چند ثانیه حذف کند و محدودیت‌ها را در برابر دستکاری عمدی بی‌اثر سازد.
حفاظت رمزنگاری واقعی:
- رمزنگاری در حین انتقال و در حالت استراحت: خروجی‌های حساس صفحه‌گسترده را بر روی حجم‌های ذخیره‌سازی که با استانداردهای مدرن رمزنگاری شده‌اند (مثلاً AWS S3 SSE‑KMS، Azure Storage Encryption) ذخیره کنید و آن‌ها را صرفاً از طریق TLS 1.3 انتقال دهید.
- رمزنگاری استاندارد OpenXML: وقتی یک صفحه‌گسترده برای توزیع نیاز به محافظت با رمز عبور دارد، به جای رمزنگاری قدیمی Office XOR، از رمزنگاری AES‑256 OpenXML مطابق با استانداردهای صنعتی استفاده کنید.
- حذف سطح پایگاه‌داده (RBAC): کنترل دسترسی مبتنی بر نقش را در لایه‌های پایگاه‌داده و برنامه قبل از ساختن صفحه‌گسترده اعمال کنید. اگر کاربر صادرکننده اجازه مشاهده شماره‌های امنیتی اجتماعی، شناسه‌های حساب داخلی یا حاشیه‌های ناخالص را نداشته باشد، آن ستون‌ها را به‌طور کامل از پرس‌وجو حذف کنید. هرگز داده‌های حساس را در ردیف‌ها یا ستون‌های "پنهان" باقی نگذارید.
۶. کنترل دسترسی، توزیع، و لاگ‌های حسابرسی
چون صفحه‌گسترده‌ها فایل‌های قابل حمل و خودکفا هستند، پس از دانلود معمولاً کنترل‌های مرزی متمرکز را دور می‌زنند.
بهترین شیوه‌های توسعه‌دهندگان:
- ارائه از طریق URLهای پیش‌امضا شدهٔ معتبر و کوتاه‌مدت: هرگز خروجی‌های صفحه‌گسترده تولید شده را در سطل‌های عمومی رها نکنید. URLهای پیش‌امضا شدهٔ زمان‌دار (با انقضای کمتر از 5 دقیقه) تولید کنید که به یک نشست کاربری معتبر و مجاز مرتبط باشد.
- حسابرسی جامع صادرات: هر عمل صادرات را به‌عنوان یک رویداد دسترسی به داده‌ها در نظر بگیرید. شناسه کاربر، شناسه مستأجر، پارامترهای پرس‌وجو، زمان‌ساز تولید و آدرس IP گیرنده را در یک دفتر حسابرسی غیرقابل تغییر ثبت کنید.
- حذف متادیتا: متادیتای داخلی اشکال‌زدایی، مسیرهای فایل سرور محلی، حساب‌های نویسنده و تاریخچه‌های ویرایش فرمول‌ها را از ویژگی‌های نهایی سند حذف کنید قبل از ارائه فایل به مشتریان خارجی.
چک‌لیست خلاصه برای توسعه‌دهندگان
| دسته‌بندی تهدید | آسیب‌پذیری اصلی | کاهش اولیه |
|---|---|---|
| تولید داده | تزریق فرمول / تزریق CSV | پیشوند کاراکترهای خطرناک (=, +, -, @) با '؛ از کتابخانه‌های سریال‌سازی قوی استفاده کنید. |
| ورود فایل | XXE و بمب‌های فشرده‌سازی | DTDها و موجودیت‌های خارجی را در تجزیه‌کننده‌های XML غیرفعال کنید؛ محدودیت‌های استخراج آرشیو را اعمال کنید. |
| انواع فایل | ماکروهای مخرب و اشیاء OLE | فقط .xlsx را در فهرست سفید بگذارید؛ هنگام بارگذاری، جریان‌های ماکرو (vbaProject.bin) را حذف کنید. |
| رندرینگ | SSRF از طریق مبدل‌های سرلس | کارگران رندرینگ ایزوله؛ خروجی شبکه به VPCهای داخلی و نقاط انتهایی متادیتا را مسدود کنید. |
| محرمانگی | محافظت ناکارآمد از شیت | فیلدهای حساس را در لایهٔ پرس‌وجو حذف کنید؛ هرگز به قفل‌گذاری سلول‌های UI یا ستون‌های مخفی تکیه نکنید. |
| توزیع | افشای داده‌های کنترل‌نشده | دانلودها را از طریق URLهای پیش‌امضا و منقضی‌شونده ارائه دهید؛ ردپای ساختاریافته‌ای از تمام عملیات صادرات ثبت کنید. |
سوالات متداول (FAQ)
س.۱. آیا صادرات داده‌ها به یک فایل CSV استاندارد کاملاً از اجرای کد ایمن است؟ خیر، زیرا برنامه‌های صفحه‌گسترده به‌صورت خودکار کاراکترهای پیشرو مانند =, @, +, یا - را به‌عنوان فرمول‌های فعال تفسیر می‌کنند که می‌توانند محتویات سلول را استخراج یا دستورات محلی را فراخوانی کنند.
س.۲. آیا می‌توان از رمز عبور یک برگه Excel برای محافظت از داده‌های حساس در برابر توسعه‌دهندگان یا کاربران غیرمجاز استفاده کرد؟ خیر، رمزهای عبور حفاظت بومی برگه و کتاب کار فقط ویرایش در سطح رابط کاربری را محدود می‌کنند و می‌توانند مستقیماً از فایل‌های XML زیرین بدون ابزارهای بازیابی رمز عبور حذف شوند.
س.۳. ایمن‌ترین روش برای جلوگیری از حملات موجودیت خارجی XML (XXE) هنگام تجزیه فایل‌های .xlsx چیست؟ پارسر XML خود را طوری تنظیم کنید که به‌صورت صریح DTDهای درون‌خطی را نپذیرد و قبل از تجزیه فایل‌های XML داخلی آرشیو، حل‌وفصل طرح‌واره‌ها و موجودیت‌های خارجی را غیرفعال کند.
س.۴. چرا تکیه بر "ستون‌های مخفی" در صفحات گستردهٔ صادرشده برای پنهان‌کردن شناسه‌های داخلی حساس یا معیارها خطرناک است؟ ستون‌های مخفی به‌صورت کامل در بار دادهٔ زیرین باقی می‌مانند و می‌توانند با یک کلیک در رابط کاربری صفحه‌گسترده آشکار شوند یا مستقیماً از محتوای فایل خام خوانده شوند.
س.۵. چگونه می‌توانم از تقلب درخواست سمت سرور (SSRF) هنگام تولید خلاصه‌های PDF یا پیش‌نمایش‌های تصویر کوچک از صفحات گستردهٔ کاربر جلوگیری کنم؟ موتورهای رندرینگ را درون کانتینرهای ایزوله و محدود به شبکه اجرا کنید که به‌طور سفت و سخت دسترسی خروجی شبکه به زیرشبکه‌های خصوصی و سرویس‌های متادیتای ابری را ممنوع می‌سازند.