State Management در ASP. NET 2.0 (بخش دوم)
در بخش اول به ضرورت مديريت state در برنامه هاي وب اشاره و در ادامه به بررسي اولين گزينه موجود (view state ) پرداختيم . در اين بخش با نحوه ايمن سازي اطلاعات ذخيره شده در view state آشنا خواهيم شد .
اطلاعات view state در يك رشته درهم آميخته مشابه زير ذخيره مي گردد .
|
<input type="hidden"
name="__VIEWSTATE"
value="/wEPDwUKMTUyMzMyNzc3NGRklXVE/6qqfC5AWkr1Yw0Xu5IpHg0="
/> |
به موازات اضافه كردن اطلاعات بيشتر به view state ، طول اين رشته طولاني تر خواهد شد . با توجه به اين كه مقدار ذخيره شده در رشته فوق به صورت متن شفاف نمي باشد ، بسياري از برنامه نويسان ASP.NET بر اين باور هستند كه داده ذخيره شده در view state به صورت رمز شده است .ولي واقعيت اينچنين نيست . در واقع ، اطلاعات view state به سادگي در حافظه به يكديگر متصل شده و به يك رشته Base64 تبديل مي شوند .يك هكر باهوش مي تواند با استفاده از مهندسي معكوس رشته فوق ، view state را بررسي و از اطلاعات ذخيره شده در آن به سرعت آگاه گردد .
كد زير نحوه رمز كردن يك رشته معمولي را به يك رشته Base64 نشان مي دهد .
|
Private Function EncodeBase64(ByVal input As String) As String
Dim strBytes() As Byte = System.Text.Encoding.UTF8.GetBytes(input)
Return System.Convert.ToBase64String(strBytes)
End Function |
كد زير نحوه رمز گشائي يك رشته Base64 را به يك رشته معمولي نشان مي دهد .
|
Private Function DecodeBase64(ByVal input As String) As String
Dim strBytes() As Byte = System.Convert.FromBase64String(input)
Return System.Text.Encoding.UTF8.GetString(strBytes)
End Function |
در صورتي كه لازم است اطلاعات ذخيره شده در view state داراي ايمني بيشتري باشند از دو گزينه مختلف مي توان استفاده كرد :
گزينه اول : به ASP. NET اعلام شود كه از يك hash code استفاده نمايد. برخي اوقات از hash code به عنوان يك checksum قدرتمند پنهاني نيز ياد مي شود . در چنين مواردي ، ASP. NET تمامي داده ذخيره شده در view state را بررسي و يك الگوريتم hashing را بر روي آن اعمال مي نمايد . الگوريتم فوق يك سگمنت كوتاه از داده را ايجاد مي نمايد كه در واقع همان hash code است . در ادامه ، كد فوق به انتهاي داده ذخيره شده در view state اضافه مي گردد .
زماني كه صفحه post back مي گردد ، ASP. NET داده موجود در view state را بررسي و مجددا" hash code را با استفاده از فرآيندي مشابه توليد مي نمايد . در ادامه مقدار محاسبه شده با مقدار موجود در رشته مقايسه مي گردد تا اين اطمينان حاصل شود كه داده ذخيره شده در view state تغيير نكرده باشد .
در صورتي كه يك كاربر بدانديش بخشي از داده موجود در view state را تغيير دهد ، ASP. NET يك hash code را توليد خواهد كرد كه با كد ذخيره شده در انتهاي view state مطابقت نخواهد كرد . در صورت تحقق چنين شرايطي ، postback بطور كامل ناديده گرفته خواهد شد .
شايد در ذهن شما اين موضوع مطرح شده باشد كه يك كاربر باهوش مي تواند با بكارگيري ترفندهائي بر مشكل اشاره شده غلبه كرده و علاوه بر توليد اطلاعات نادرست ، يك hash code مناسب و منطبق بر اطلاعات ذخيره شده در view state را نيز توليد نمايد . در پاسخ مي بايست به اين نكته اشاره كرد كه كاربران بدانديش قادر به توليد hash code صحيح نخواهند بود چراكه آنان داراي كليد رمزنگاري مشابه ASP. NET نمي باشند . اين بدان معني است كه hash code توليد شده با وضعيت موجود نمي تواند مطابقت نمايد .
hash code بطور پيش فرض فعال است . بنابراين در صورت تمايل به استفاده از پتانسيل فوق ، لازم نيست كه مراحل اضافه اي را دنبال نمود . در برخي موارد پياده كنندگان ويژگي فوق را غيرفعال مي نمايند تا از مشكلات احتمالي موجود در يك web farm پيشگيري نمايند . در چنين وضعيتي ، سرويس دهندگان مختلف داراي كليدهاي مختلفي مي باشند و مشكل زماني اتفاق مي افتد كه پس از post back صفحه ، يك سرويس دهنده جديد آن را دريافت نمايد .
در يك محيط web farm كليد مي بايست در بين تمامي سرويس دهندگان يكسان باشد . در صورتي كه كليد يكسان نباشد و صفحه براي يك سرويس دهنده متفاوت با سرويس دهنده اي كه صفحه را ايجاد كرده است ، post back گردد ، يك خطاء ايجاد خواهد شد .بنابراين در يك محيط web farm ، مي بايست پياده كنندگان يك كليد را در فايل Machine.config مشخص نمايند ( در مقابل اين كه به ASP.NET اجازه داده شود كه اين كليد را بطور اتوماتيك ايجاد نمايد) .
براي غيرفعال كردن hash codes ، مي بايست از خصلت enableViewStateMac عنصر <pages> در فايل web.config و يا machine.config به صورت زير استفاده كرد .
|
<configuration >
<system.web>
<pages enableViewStateMac="false" />
...
</system.web>
</configuration> |
گزينه دوم : با ايجاد يك كد hash ، فريمورك ASP. NET اين موضوع را بررسي خواهد كرد كه آيا داده ذخيره شده در view state دستكاري شده است ؟ علي رغم ايجاد اين لايه امنيتي ، داده موجود در view state همچنان قابل مشاهده توسط كاربران بدانديش خواهد بود .
در صورتي كه بر روي داده ذخيره شده در view state حساسيت زيادي وجود داشته باشد و بخواهيم امنيت آن را افزايش دهيم ، مي بايست رمزنگاري view state را فعال كرد . براي فعال كردن ويژگي فوق از خصلت ViewStateEncryptionMode به همراه دايركتيو page استفاده مي گردد .
|
<%@Page ViewStateEncryptionMode="Always" %> |
در صورت تمايل مي توان از خصلت فوق در فايل پيكربندي نيز استفاده كرد .
|
<configuration >
<system.web>
<pages viewStateEncryptionMode="Always" />
...
</system.web>
</configuration> |
به خصلت ViewStateEncryptionMode يكي از مقادير زير را مي توان نسبت داد :
-
Always : همواره رمزنگاري انجام مي شود .
-
Never : رمزنگاري انجام نخواهد شد .
-
Auto : رمزنگاري صرفا" در مواردي كه يك كنترل با صراحت آن را درخواست نمايد ، انجام خواهد شد .
گزينه پيش فرض Auto است . اين بدان معني است كه يك كنترل با فراخواني متد Page.RegisterRequiresViewStateEncryption رمزنگاري را درخواست مي نمايد . در صورتي كه يك كنترل به دليل عدم داشتن اطلاعات حساس از متد فوق استفاده نكند ، view state رمز نخواهد شد و عمليات بيشتري جهت رمزنگاري به سيستم تحميل نخواهد شد . به عبارت ديگر ، يك كنترل زماني مي تواند دل خود را به خدمات ارائه شده توسط متد فوق خوش نمايد كه مقدار خصلت viewStateEncryptionMode ، معادل Auto در نظر گرفته شده باشد . در صورتي كه مقدار خصلت فوق Never در نظر گرفته شده باشد ، به درخواست كنترل ها جهت رمزنگاري پاسخ داده نخواهد شد.
با توجه به اين كه رمزنگاري عمليات بيشتري را به سرويس دهنده وب تحميل مي نمايد ( هم در زمان رمزنگاري و هم در زمان رمزگشائي پس از هر post back ) در صورت عدم نياز به پتانسيل فوق و به منظور عدم تاثيرگذاري آن بر روي كارآئي برنامه هاي وب ، ضرورتي به فعال كردن آن وجود ندارد .
در بخش سوم بحث بر روي State Management را ادامه داده و بررسي نحوه نگهداري Member Variables و اشياء سفارشي در view state خواهيم پرداخت .
برگرفته از سايت سخا روش