نحوه ایمن سازی اطلاعات ذخیره شده در view state ASP .NET
در این بخش با نحوه ایمن سازی اطلاعات ذخیره شده در 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 ) در صورت عدم نیاز به پتانسیل فوق و به منظور عدم تاثیرگذاری آن بر روی کارآئی برنامه های وب ، ضرورتی به فعال کردن آن وجود ندارد .
