Insecure Deserialization

A8 2017
Insecure Deserialization
بردار حمله
App.Specific
قابلیت بهره برداری : 1

بهره برداری از diserialization تا حدودی دشوار است.\\\\r\\\\n

ضعف امنیتی
شیوع : 2
قابلیت تشخیص : 3

این مسئله در 10 Top بر اساس تحقیقات صنعت و نه بر روی داده های قابل اندازه گیری وجود دارد. برخی از ابزارها می توانند نقاط ضعف را بیابند، اما تست های انسانی اغلب برای اعتبارسنجی مشکل ضروری است. انتظار می رود که داده های شایع برای نقص های خنثی سازی افزایش یابد، زیرا ابزار توسعه برای کمک به شناسایی و رفع آن کمک می کند.

تاثیرات
فنی : 3
تجاری ؟

تاثير ضعفهاي Deserialization را نمی توان نادیده گرفت. این نقص ها می تواند به حمات کد های راه دور منجر شود، که یکی از جدی ترین حمات ممکن است. تاثیر تجاری به نیازهای حفاظت از برنامه و داده ها بستگی دارد

شناسایی آسیب پذیری

برنامه های کاربردی و API ها آسیب پذیر خواهند بود اگر آنها از اشیاء متخاصم یا دزدیده شده توسط مهاجم استفاده کنند. این می تواند به دو نوع اصلی حمات منجر شود:
• حمات مرتبط با ساختار داده ها و جایی که مهاجم منطق برنامه را تغییر می دهد یا اگر اشیاء موجود در برنامه وجود داشته باشد که می توانند رفتار را در طی یا پس از پایان دادن به کار تغییر دهند، اجرای کد دلخواه را اجرا می کند.
• داده ها را دستکاری می کند، مانند حمات مرتبط با کنترل دسترسی، که در آن ساختار داده های  موجود استفاده می شود اما محتوا تغییر می کند. 
Serialization ممکن است در برنامه های کاربردی برای:
• ارتباط از راه دور و اینترفیس )IPC / RPC)
• پروتکل های سیم، خدمات وب، کارگزاران پیام
• ذخیره سازی / پایداری
• پایگاه های داده، سرورهای ذخیره سازی، سیستم های فایل
• کوکی HTTP ،پارامترهای فرم HTML ،نشانه های تأیید API استفاده شود.

راه های جلو گیری

تنها الگوی معماری امن، تشخیص اشیاء سریالی از منابع نامشخص است یا استفاده از رسانه های سریالی که تنها نوع داده های اولیه را اجازه می دهد. اگر این امکان پذیر نیست، یکی از موارد زیر را اعمال کنید:
• پیاده سازی چک های یکپارچه مانند امضاهای دیجیتالی بر روی هر شیء سریالی برای جلوگیری از ایجاد شی خصمانه یا جاسوسی داده ها.
• اجرای محدودیت های سخت نوع در deserialization قبل از ایجاد شی به عنوان کد.
• عدم نمایش موارد استثنا و خرابی ها، از جمله اینکه کدام نوع ورودی نوع مورد انتظار نیست، یا عدم تمدید.
• محدود کردن یا نظارت بر اتصال به شبکه های ورودی و خروجی.
• نظارت بر عدم وجود هشدار.

مثال هایی از سناریوهای حمله

سناریو شماره 1 :برنامه React یک مجموعه از سرویس های مایکروسافت Boot Spring را فراخوانی می کند. برنامه نویسان سعی کردند اطمینان حاصل کنند که کد آنها تغییرناپذیر است. راه حل هایی که با آن روبرو شدیم، سریالی است و هر درخواست را به عقب و جلو منتقل می کند. یک مهاجم به امضای شی "R00 "اشاره می کند و از ابزار Killer Serial Java برای به دست آوردن اجرای کدهای راه دور در سرور برنامه استفاده می کند.
سناریو شماره 2 :یک انجمن PHP از پیاده سازی شیء برای ذخیره یک کوکی، حاوی شناسه کاربری کاربر، نقش، هش رمز عبور و حالت های دیگر استفاده می کند:
;"user":4:s;2:Mallory";i":7:s;1:i;132:i;0:i{:4:a
};"b6a8b3bea87fe0e05022f8f3c88bc960":32:s;3:i
یک مهاجم شیء سریالی را برای دادن امتیازات مدیریت خود تغییر می دهد:
;"admin":5:s;2:Alice";i":5:s;1:i;1:i;0:i{:4:a
};"b6a8b3bea87fe0e05022f8f3c88bc960":32:s;3:i

منابع

OWASP


OWASP Types of Cross-Site Scripting
OWASP XSS Prevention Cheat Sheet
OWASP DOM based XSS Prevention Cheat Sheet
OWASP Java Encoder API
ASVS: Output Encoding/Escaping Requirements (V6(
OWASP AntiSamy: Sanitization Library
Testing Guide: 1st 3 Chapters on Data Validation Testing
OWASP Code Review Guide: Chapter on XSS Review


External


OWASP XSS Filter Evasion Cheat Sheet
CWE Entry 79 on Cross-Site Scripting

جزییات بازدید : 1969

تاریخ انتشار : 23 / مرداد / 1398