حملات و دفاعهایی برای اسیب پذیری دهه اخیر
چکیده سرریزهای بافمتدلترین شکل اسیب امنیتی در طی ده سال گذشته است. ضمنا، شدن حوزۀ آسیب های نفوذ شبکه از راه دور را شامل می شود در جایی که یک کاربر اینترنت درصدد بدست آوردن کنترل نسبی میزبان است. اگر آسیب های لبریزی بافر بطور موثر حذف گردد، بخش زیادب از تهدیدهای امنیتی جدی نیز حذف می شود در این مقاله به انواع آسیب های لبریزی بافر و حملات مربوطه اشاره می کنیم و اقدامات دفاعی مختلف را بررسی می کنیم که شامل روش Guard Stack است. سپس ترکیبات روش هایی را که می توانند مشکل عملکرد سیستم های موجود را حذف کنند بررسی می کنیم در حالیکه عملکرد سیستم های موجود حفظ می گردد.
مقدمه : لبریزی بافر شایع ترین مشکل آسیب امنیتی در ده های اخیر بوده است آسیب های لبریزی بافر در حوزۀ آسیب های نفوذ شبکه از راه دور حکمفرماست در جایی که یک کاربر اینترنت به جستجوی کنترل کامل یا نسبی یک میزبان است چون این نوع حملات هر کسی را قادر می سازد که کنترل کلی یک میزبان را به عهده بگیرد آنها یکی از جدی ترین حملات هرکسی را قادر می سازد که کنترل کلی یک میزبان را به عهده بگیرد آنها یکی از جدی ترین مولود تهدید های امنیتی محسوب می شوند حملات لبریزی بافر یک بخش مهم از حملات امنیتی را تشکیل می دهند زیرا آسیب های لبریزی به آسانی کشف می گردند. با اینحال آسیب های لبریزی بافر در گروه حملات نفوذ از راه دور قرار می گیرند زیرا یک آسیب پذیری لبریزی بافر مهاجم را با آنچه که نیاز دارد نشان می دهد یعنی توانایی تزریق و اجرای رمز (کد) حمله. کد حملۀ تزریق شده با برنامۀ آسیب پذیر کار می کند و به مهاجم امکان آن را می دهد که عملکرد لازم دیگر برای کنترل رایانۀ میزبان را در اختیار بگیرد. مثلا از بین بردن حملات بکار رفته در ارزیابی آشکار سازی تهاجم در ازمایشگاه لینکلن در 1998 سه مورد از نوع حملات مهندسی اجتماعی اساسی بودند که به اعتبارات کاربر حمله کردند و دو مورد از نوع لبریزی های بافر بودند و 9 مورد از 13 مورد مشاوره های CERT از 1948 شامل لبریزی های بافر بود و حداقل نیمی از مشاوره های CERT 1998 شامل اینحال لبریزی های بافر بود بررسی غیر رسمی درباره خدمت آسیب پذیری امنیتی نشان داد که تقریبا 2/3 پاسخ دهندگان عقیده داشتند که لبریزیهای بافر علت اصلی آسیب پذیری امنیتی است. آسیب پذیری های لبریزی بافر و حملات در یک سری از شکل ها می آید که ما در بخش 2 شرح می دهیم و طبقه بندی می کنیم2) ) دفاع در برابر حملات لبریزی بافر بطور مشابه در یک سری شکل ها ظاهر می شود که در بخش 3 شرح می دهیم که شامل انواع حملات و اسیب پذیری هایی است که این دفاع ها در برابر آنها موثر است پروژه Immunix مکانیزم دفاعی Guard Stack را تو سعه داده است که در دفاع از حملات بدون لطمه به عملکرد یا سازگاری سیستم بسیار موثر بوده است . بخش 4 به بررسی ترکیبی از دفاع هایی می پردازد که یکدیگر را پوشش می دهند. بخش 5 نتیجه گیری ها را شامل می گردد.
2 ) آسیب پذیری های لبریزی بافر و حملات
هدف کلی بک حملۀ لبریزی بافر، خنثی کردن عملکرد یک برنامه ممتاز است طوری که مهاجم بتواند کنترل آن برنامه را بعهده بگیرد. و اگر برنامه بقدر کافی پیشرفته باشد بتواند کنترل میزبان را انجام دهد. مهاجم به یک برنامه root ریشه حمله می کند و فورا کد مشابه با "exec(sh)" را اجرا می کند تا به یک لایه root برسد
برای انجام این هدف، مهاجم باید به دو هدف دست یابد:
کد مناسب را آرایش دهد تا در فضای نشانی برنامه باشد 2) از برنامه برای پرش به آن کد استفاده کند و پارامترهای مناسب بداخل حافظه و رجیسترها لود شوند.
ما حملات لبریزی بافر را بر حسب حصول این اهداف دسته بندی می کنیم بخش 2.1 نحوه قرار گرفتن کد حمله در فضای نشانی برنامه قربانی را شرح می دهد. بخش 2.2 شرح می دهد که چونه مهاجم یک بافر برنامه را لبریز می کند تا حالت برنامه مجاور را تغییر دهد که جایی است که قسمت لبریزی از آنجا می آید تا باعث شد که برنامه قربانی به کد حمله پرشی نماید بخش 2.3 موضوعات مربوطه را در ترکیب کردن روشهای تزریق کد از بخش 2.1 با روش ها ی وقفۀ جریان کنترل از بخش 2.2 بحث می کند. 2.1 روش های آرایشی کد مناسب برای فضای نشانی برنامه : دو روش برای آرایش کد حمله برای فضای نشانی برنامه قربانی وجود دارد: تزریق یا کاربرد آن چه که قبلاً در آنجا وجود دارد.
تزریق آن: مهاجم یک رشته را بصورت ورودی برای برنامه فراهم می کند که برنامه در یک بافر ذخیره شود. رشته شامل بایت هایی است که دستورالعمل های CPU برای سکوی مورد حمله می باشند در اینجا حمله کننده از بافر های برنامه قربانی برای ذخیره کردن کد حمله استفاده می کند. بعضی موارد مربوط به این روش به این شرح است:
مهاجم مجبور نیست هر بافری را برای انجام این کار لبریز کند: بارگیری کافی کافی می تواند بداخل بافرهای کاملا سالم تزریق شود بافر می تواند در هر جایی قرار بگیرد.
روی متغیرهای خودکار روی متغیرهایی mallocell در ناحیه ایتای استاتیک (مقدار طی شده اولیه یا نشده) قبلا در آنجا وجود دارد: اغلب کد برای انجام آنچه که مهاجم می خواهد انجام دهد قبلا در فضای نشانی برنامه وجود دارد و مهاجم فقط لازم است که کد را پارامتر بندی کند و سپس باعث پرش برنامه به آن شودمثلا اگر کد حمله لازم باشد تا ("/bin/sh") exel را انجام دهد در جایی که arg یک آرگومان مکان نمایی رشته است آنگاه مهاجم باید یک مکان نما را تغییر دهد تا به ("/bin/sh") اشاره کند و به دستور العمل های مناسب در کتابخانه libe پرش نماید.
2.2 راههایی که برنامه باعث پرش به کد مهاجم می شود: تمام این روشها قصد دارند تا جریان کنترل برنامه را تغییر بدهند طوری که برنامه به کد حمله پرش کند. روش اصلی عبارت اند از لبریزی یک بافر است که دارای حدود غیر موجود یا ضعیف ای است که ورودی را با هدف از بین بردن یک قسمت مجاور برنامه کنترل می کند مثلا مکان نماهای مجاور و غیره با لبریز کردن بافر، مهاجم می تواند حالت برنامه مجاور را با یک توالی تقریبا اختیاری از بایت ها بازنویسی کند که منجر به یک میان بری اختیاری از سیستم نوع C و منطق برنامه قربانی می شود در اینجا طبقه بندی کردن از نوع حالت برنامه ای است که لبریزی باقر مهاجم قصد دارد تا در ان خرابی بوجود آورد. در اصل، این حالت می تواند هر نوع حالت ای باشد. مثلا morris worn از یک لبریزی بافر در مقابل برنامه fingerel استفاده کرد تا نام یک فایل ای را از بین ببرد که fingerd اجرا می نماید. در عکل اکثر لبریزی های بافر قصد دارند تا مکان نماهای کد را خراب نمایند.
رکوردهای فعالیت: هر بار که یک تابع انحصاری می شود یک رکورد فعالیت روی دسته قرار دارد می وشد که شامل نشانی برگشت ای است که برنامه باید پرش کند وقتی که تابع وجود دارد یعنی به کد تزریق شده در بخش 2.1 اشاره می کند. حملاتی که رکورد فعالیت را خراب می کنند متغیرهای خودکار جریان لبریزی نشانی ها را تحت تاثیر قرار می دهند یعنی بافرهای مطابق شکل با خراب کردن نشانی در رکورد فعالیت مهاجم باعث می شود که برنامه به کد مهاجم پرش کند وقتی که تابع قربانی نشانی برگشت را برمی گرداند. این شکل لبریزی یک سری حملات لبریزی بافر را باعث می شوند.
مکان های تابع:(*foo) void متغیر foo را اعلان می کند که از نوع مکان نما برای تابع ای است که viod را بر می گرداند. مکان نما های تابع می توانند در هر جایی تخصیص داده شوند و بنابراین مهاجم فقط باید یک بافر قابل لبریزی مجاور به یک مکان نمای تابع را در هر کدام از این نواحی پیدا کند و آن را لبریز کند تا مکان نمای تابع را پیدا کند پس از مدتیوقتی برنامه احضاری را از طریق این مکان نمای تابع انجام می دهد به محل مطلوب مهاجم حمله می کند یک مثال از این نوع حمله در مقابل برنامه snperprobe برای لینوکس ظاهر گردید
بافرهای پرش بلند: c شامل یک سیستم موسوم set ymp/longsmp است. اگر مهاجم بتواند حالت بافر را خراب کند آنگاه longJmp(buffer) به کد مهاجم پرش خواهد کرئ مانند مکان نما های تابع بافرهای lingJmp می توانند هر جایی تخصیص داده شوند بنابراین مهاجم فقط باید یک بافر قابل لبریزی را پیدا کند . یک مثال از این شکل حمله در مقابل perld.003 ظاهر گردیدحنله ابتدا یک بافر LongJmp را خراب کرد برای بازیابی استفاده شد وقتی که لبریزی های بافر آشکار می شوند و سپس شامل مود بازیافت بود که باعث شد که مفسر perl به کد حمله پرش کند.
2.3
ترکیب کردن تزریق کد و روش های خراب کردن و جریان کنترل
در اینجا به بررسی موضوعات ترکیب تزریق کد مهاجم و روش های خراب رکدن جریان کنترل می پردازیم. ساده ترین شکل حمله لبریزی بافر یک روش تزریق را با یک خرابی رکورد فعال سازی در یک رشته واحد ترکیب می کند مهاجم یک متغیر خودکار قابل لبریزی را قرار می دهد و به برنامه یک رشته بلند را تغذیه می کند که بطور همزمان بافر را لبریز می کند تا رکورد فعالیت را تغییر دهد و حاوی کد حمله تزریق شده است. این سکویی برای یک حمله مطرح شده توسط levey است. چون اصلاح تخصیص یک بافر محلی کوچک بسیار متداول است یک سری حالت های آسیب پذیری کد برای این شکل حمله وجود دارند . تزریق و خرابی در یک عمل انجام نمی شود. مهاجم می تواند کد را به داخل یک بافر بدون لبریز کردن آن تزریق کند و یک بافر متفاوت را برای خراب کردن یک مکان نمای کد لبریز می کند این کار تر انجام می شود اگر بافر قابل لبریزی محدودیت هایی داشته باشد که روی آن کنترل انجام شود بنابراین بافر تا تعداد معینی از بایت ها قابل لبریزی است مهاجم حمله برای قرار دادن کد بافر آسیب پذیر نمی باشد بنابراین کد به سادگی در داخل یک بافر متفاوت با اندازه کافی قرار داده می شود. اگر مهاجم سعی کند از کد قبلی بجای تزریق آن استفاده کند، آنها لازم است تا کد را پارامتر بندی کنند مثلا قطعه کدهایی در Libe وجود دارند (مرتبط با برنامه C) که something" "exel را انجام می دهند در جایی که "something" یک پارامتر است.مهاجم می تواند از لبریزی های بافر برای خراب کردن آرگومان استفاده کند و لبریزی بافر دیگری برای خراب کردن یک مکان نمای کد بکار می رود تا به libe در قطعه کد مناسب اشاره گردد.
3) دفاع های لبریزی بافر. چهار روش اصلی برای دفاع در برابر آسیب پذیری های لبریزی بافر و حملات وجود دارد روشی در بخش 3.1 شرح داده شده است روش سیستم های عامل در بخش 3.2 شرح داده می شود که برای نواحی ذخیره برای بافرهای غیر قابل اجرا است و ا زمهاجم از تزریق کد حمله حمله جلوگیری می کند. این روش بسیاری حملات را متوقف می کند. روش کامپایلر در بخش 3.3 برای اجرا کنترل یکپارچگی روی مکان نماهای کد قبل از مرجع زدایی آنهااست. این روش حملات لبریزی بافر را غیر ممکن نمی کند ولی اکثر حملات لبریزی بافر را متوقف می کند و حملاتی که متوقف نمی شوند به سختی ایجاد می شوند و مزایای عملکرد و سازگاری زیادی دارد که در بخش 3.5 شرح داده می شود
3) کد تصحیح نوشتن این اصطلاح در هنگام نوشتن به زبان مثلا c مطرح می شود وبویژه وقتی که نوشتن و اصلاح آن مطرح باشد با وجود سابقه طولانی درک نوشتن برنامه های آسیب پذیری بطور منظم در حال ظاهر شدن هستند بنابراین بعضی ابزارها و روش ها به توسعه دهندگان کمک کرده است که آسیب پذیری های لبریزی بافر را تشخیص دهند.
ساده ترین روش عبارت اند از greb که منبع برای احضارهای کتابخانه ای از قبیل stcpy و sprintf است که طول آرگون های آنها کنترل نمی کند نسخه های کتابخانه استاندارد c توسعه یافته است که برای این منظور بکار می رود. تیم های ممیزی که با هدف ممیزی کردن مقادیر زیادی از کد ظاهر شده اند و در جستجوی اسیب پذیری های امنتیتی رایج از قبیل لبریزی های با فرو شرایط سیستم فایل می باشند. با اینحال آسیب پذیری های لبریزی بافر قابل برسی است حتی کد از راههای مطمئن دیگری استفاده می کند می توانند حاوی آسیب پذیری ها ی لبریزی بافر باشند اگر کد حاوی یک ابتدایی باشد مثلا برنامه lprm دارای آسیب پذیری لبریزی بافر است اگر چه برای مسائل امنیتی مثا آسیب پذیری های لبریزی بافر ممیزی شده اند.برای رفع مشکل bug های باقیمانده ابزارهایی debug کردن پیشرفته ای توسعه یافته اند مانند ابزارهای تزریق عیب بطور تصادفی برای تزریق عیب بطور تصادفی برای تحقیق اجزای برنامه اسیب پذیر همچنین ابزارهای تحلیل ای ظاهر شده اند که می توانند آسیب پذیری های لبریزی بافر بسیاری را آشکار کنند این ابزار در توسعه برنامه های امنیتی مفید هستند ولی c دستور زبان به انها اجازه نمی دهد که تضمین کلی را فراهم کنند که تمام البریزی های بافر پیدا شده کند روش های debug کردن فقط تعداد آسیب پذیری های لبریزی بافر را کمینه می کنند ولی تضمین نمی کنندکه تمام آسیب پذیری های لبریزی بافر حذف شده باشد. اقداماتی از قبیل بخش 3.2 تا 3.4 باید بکار بروند مگر اینکه شخص مطمئن باشد که تمام اسیب پذیری های لبریزی بالقوه بافر حذف شده اند.
3.2 بافرهای غیر قابل اجرا: مفهومی کلی برای ایجاد دیتاسگمنت از فضای نشانی برنامۀ قربانی غیر قابل ااجرا بکار می رود و مهاجمان نمی توانند کدی را اجرا کنند که بداخل بافرهای ورودی برنامه تزریق می کنند.
بسیاری از رایانه های قدیمی تر به این صورت طراحی شدند وای اخیرا سیستم های ویندوز ms و unix برای وارد کردن کد دینامیک در داخل سگمنت ها ی دیتای برنامه طراحی شده اند که بهینه سازی های عملکرد بسیاری را پشتیبانی می کنند و شخص نمی تواند همۀ سگمنت دیتاها را بدون قربانی کردن سازگاری برنامه غیر قابل اجرا کند ولی شخص می تواند سگمنت stack را نیز قابل اجرا کند و سازگاری اگر برنامه را فقط کند. برای linux و Solaris این بررسی ها انجام شده اند دو مورد استثنا در مهدعط وجود دارد که کداجرایی باید روی stack قرار داده شود:
تحویل signal : Linux سیگنال های unix را procers هایی تحویل می دهد و کد را حذف م یکند تا سیگنال را روی process stack تحویا دهد و بعدا یک وقفه را باعث می شود که به کد تحویل بر روی stack پرش می کند. Stacl patch غیر قابل اجرا این امر را با مشخص کردن stack قابل اجرا در طی تحویل سیگنال ذکر می کند.
Gce Trampour نشانه هایی وجود دارند که لثز کد قابل اجرا را روی stack fvhd trampoline ها قرار می دهد. با اینحال در عمل trampoline هایی را ناتوان می کند که مشکل ای بوجود نیاورده اند آن قسمت از gcc بنظر می رسد تا مورد سوء استفاده قرار گرفته باشد.
حفاظت پیشنهاد شده توسط stack segment های غیر قابل اجرایی در برابر جملات موثر هستند که بستگی به تزریق کد حمله بداخل متغیرهای خودکار دارد ولی هیچ محافظتی در برابر سایر شکل های حمله بوجود نمی آورد. حملاتی وجود دارد که این شکل از دفاع را میان بر می زند و به یک مکان نمای کد در کدی اشاره می کند که قبلا در برنامه قرار دارد سایر حملات می توانند ایجاد شوند که کد حمله را بداخل بافرهای تخصیصی یافته تزریق می کنند
3.3 کنترل حدود حمله در حالی که کد تزریق بای یک حمله لبریزی بافر اختیاری است، خرابی جریان کنترل ضروری است بنابراین برخلاف بافرهای غیر قابل اجرا محدودیت های آرایه که توقف ها را بطور کامل کنترل می کنند را آسیب پذیری های لبریزی های بافر و حملات را متوقف می کنند اگر آرایه ها نتوانند اصلا لبریز شوند انگاه لبریزی های حمله نمی توانند برای خراب کردن حالت برنامه مجاور استفاده شوند برای اجرای کنترل محدوده های آرایه تمام خواندن و نوشتن های برای ارایه ها باید کنترل شوند تا تضمین کنند که آنها در محدودۀ تعیین شده قرار دارند. روش مستقیم عبارت اند از کنترل کردن تمام مرجع های ارایه است ولی اغلب امکان بکار گیری روش های بهینه سازی برای حذف بسیاری از این کنترل ها وجود ندارد. روش های مختلفی برای اجرای کنترل حدود آرایه وجود دارد که در پروژه های زیر مثال زده میشوند.
3.3 compal compiler- برای Alpla cpu بکار می رود که یک شکل محدود از کنترل حدود آرایه را انجام می دهد وقتی که check –bonds استفاده می شود کنترل های حدود به شیوه های زیر محدود می شوند.
- فقط مرجع های آرایه آشکارکنترل می شوند.
- چون تمام آرایه های c به مکان نماها تبدیل می شوند وقتی که بصورت آرگومان عبور داده می شوند هیچ کنترل حدودی روی دسترسی های انجام شده توسط زیر سوال ها اجرا نمیشود.
- تئابع کتابخانه ای خطرناک (strcpy ( ) ) معمولا با کنترل کردن حدود کامپایل نمی شوند و خطرناک باقی می مانند حتی اگر کنترل کردن حدود امکان پذیر باشد.
برای برنامه های C امکان استفاده از ریاضیات مکان نما برای دسترسی به آرایه ها وعبور آرایه ها بصورت آرگومان هایی برای توابع وجود دارد و این محدودیت ها جدّی هستند. ویژگی کنترل کردن حدود، کاربرد محدود برای رفع اشکال برنامه است و آسیب پذیری های لبریزی بافر کشف نمی باشند.
Jones & kelly3.2.2: کنترل کردن حدود آرایه ها برای –c جونز و کلی یک patch gcc را توسعه دادند که کنترل حدود آرایه ها کامل را برای برنامه های C انجام می دهد. برنامه های کامپایل شده با سایر مدل های gcc سازگار هستند، زیرا نمایش مکان نماها را تغییر نداده اند. آنها یک مکان نمای پایه را از هر عبارت مکان نما بدست می آورند و ویژگی های آن مکان نما را برای تعیین عبارت در محدوده تعیین شده بکار می برند. هزینه های عملکرد ضروری هستند. یک برنامه مبتنی بر مکان نما 30 *slowdown کاسلش 30 برابر را تجربه کرد چون slowdown متناسب با کاربرد مکان نما است، که در برنامه های ویژه کاملاً متداول است
عمل کامپایلر بنظر نمی آید که کامل باشد؛ برنامه های پیچیده مانند e 1000 نمی توانند اجرا شوند هنگامی که با این کامپایلر، کامپایل می شوند، با اینحال، یک نسخه جدید از کامپایلر حفظ می شود و می تواند با بسته رمز سازی نرم افزار SSH بکار برود. آزمایشات توان عملیاتی با رمز کردن نرم افزار و کامپایلر جدید توسط SSH یک 12 * Slowdown را نشان می دهد.
پروژه purify :
3.3.3 کنترل دسترسی حافظه purify (اسم است) یک ابزار رفع اشکال (debgging) کاربرد حافظه برای برنامه c است. purify از قرار دادن کد هدف برای دسترسی حافظه استفاده می کند. پس از ارتباط با رابط purify کتابخانه ها، شخص یک برنامه قابل اجرای استاندارد را بدست می آورد که تمام مراجع آرایه آن را کنترل می کند تا مطمئن شود که آنها قانونی هستند در حالیکه برنامه های حفاظت شده توسط purify بطور معمول بدون هر نوع محیط خاصی اجرا می شوند purify واقعا بصورت یک ابزار امنیتی تولید در نظر گرفته نمی شود : حفاظت purify یک Slowdown 3 تا 5 برابر را اعمال می کند، همچنین purify به سختی ایجاد و ساخته می شود و هر نسخه تولید شده آن 5000 ارزش دارد.
3.3.4 زبانهای Type safe : تمام آسیب پذیری های لبریزی بافر از فقدان ایمنی نوع در c حاصل می شوند. اگر فقط عملیات ایمنی نوع بتوانند اجرا شوند، آنگاه امکان استفاده از ورودی خلاق بکار رفته برای foo وجود ندارد تا تغییرات دلخواه را برای متغیر bav بوجود آورد. اگر کد حساس امنیتی با نوشته شود توصیه می شود که کد به زبان ایمنی ای نوشته شود مثل Java یا ML . متأسفانه، میلیون ها خط کد سرمایه گذاری شده در سیستم های عامل موجود و برنامه های کاربردی حساس به امنیت وجود دارند و قسمت اعظم آن کد به زبان C نوشته می شود. این مقاله به روش های حفاظت کد موجود از حملات لبریزی بافر اختصاص دارد. با اینحال، ( JVM ) یک برنامه C است و یکی از راههای حمله به یک JVM بکارگیری حملات لبریزی بافر برای خود JVM است. بنابراین بکاربردن روش دفاعی لبریزی بافر برای سیستم هایی که ایمنی را برای زبانهای ایمنی ایجاب می نمایند ممکن است نتایج مفیدی داشته باشد.
3.4 کنترل کردن یکپارچگی مکان نمای کد- هدف از کنترل کردن مکان نمای کد- با کنترل کردن حدود تفاوت دارد. بجای تلاش برای جلوگیری از خرابی مکان نماهای کد، کنترل کردن یکپارچگی مکان نمای کد در صدد است تا مشخص کند که یک مکان نمای کد خراب شده است قبل از اینکه مرجع زدایی شود. بنابراین در حالی که مهاجم در خراب کردن یک مکان نمای کد پیشروی می کند، مکان نمای کد خراب شده هرگز استفاده نمی شود زیرا خرابی قبل از هر کاربردی آشکار می شود. کنترل کردن یکپارچگی مکان نمای کد دارای معایبی نسبت به کنترل کردن حدودی است که بطور کامل مشکل لبریزی بافر را برطرف نمی کند لبریزی هایی که بر روی مؤلفه های حالت برنامه تأثیر می گذارند (غیر از مکان نماهای کد) هنوز موفق هستد ( جدول 3 در بخش 4 را برای جزئیات مطالعه کنید) ولی مزایای زیادی بر حسب عملکرد ناسازگاری با کد موجود و تلاش اجرایی دارد که ما در بخش 3.5 به ذکر آن می پردازیم کنترل کردن یکپارچگی مکان نمای کد در سه سطح مختلف بررسی شده است
فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد
تعداد صفحات این مقاله 29 صفحه
پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید
دانلود مقاله امنیت شبکه
