سیستم پیکربندی ASP.NET 2.0 (بخش سوم )

در این بخش به بررسی سایر تنظمیات پیکربندی خواهیم پرداخت .

پیکربندی ترجمه
ASP.NET ، صفحات وب ، سرویس های وب ، http handlers ، فایل های برنامه ( نظیر Global.asax ) و فایل های منبع  را به صورت پویا ترجمه می نماید . فایل های فوق به صورت پویا و همزمان با اولین درخواست ، ترجمه می گردند .
هر نوع تغییر در فایل ترجمه شده پویا باعث می گردد  که تمامی منابع متاثر از تغییرات شوند و به صورت پویا invalidated و مجددا" ترجمه گردند . مکانیزم فوق پیاده کنندگان را قادر می سازد که به سرعت برنامه های وب را با حداقل overhead اجراء نمایند. چراکه پس از تشخیص تغییرات و ترجمه پویا ، می توان بلافاصله از امکانات برنامه ها استفاده نمود . 
پتانسیل ترجمه پویا در ASP.NET 2.0 نسبت به ASP.NET 1.x افزایش و فایل های دیگری نظیر کلاس فایل ها را نیز تحت پوشش قرار می دهد .
برای پیکربندی تنظیمات ترجمه از بخش <compilation> در فایل های web.config و یا machine.config استفاده می گردد . ASP.NET engine ، در زمان مورد نیاز صفحه را ترجمه و کد تولید شده را در code cache ذخیره می نماید .از cache فوق در زمان اجرای صفحات ASP.NET استفاده می گردد .
کد زیر گرامر بخش <compilatioin>  را نشان می دهد .

<!-- compilation Attributes --> <compilation      tempDirectory="directory"      debug="[true|false]"      strict="[true|false]"      explicit="[true|false]"      batch="[true|false]"      batchTimeout="timeout in seconds"      maxBatchSize="max number of pages per batched compilation"      maxBatchGeneratedFileSize="max combined size in KB"      numRecompilesBeforeAppRestart="max number of recompilations ?       defaultLanguage="name of a language as specified in a <compiler/> element below"       <compilers>           <compiler language="language"               extension="ext"               type=".NET Type"               warningLevel="number"               compilerOptions="options"/>      </compilers>      <assemblies>             <add assembly="assembly"/>      </assemblies>      <codeSubDirectories>             <codeSubDirectory directoryName="sub-directory name"/>      </codeSubDirectories>      <buildproviders>             <buildprovider                 extension="file extension"                 type="type reference"/>      </buildproviders> </compilation>

توضیحات :

• batch : نوع ترجمه را مشخص می نماید (مقدار پیش فرض True است ) .

• maxBatchSize : حداکثر تعداد صفحات و یا کلاس را که می توان در یک batch ترجمه نمود، مشخص می نماید. ( مقدار پیش فرض 1000 )

• maxBatchGeneratedFileSize : حداکثر اندازه خروجی یک batch assembley ترجمه شده را نشان می دهد ( مقدار پیش فرض 3000  )

• batchTimeout : زمان ( بر حسب ثانیه ) ترجمه batch را مشخص می نماید . در صورتی که زمان فوق قبل از اتمام ترجمه به پایان رسیده باشد ، یک exception محقق می گردد ( مقدار پیش فرض پانزده ثانیه است) .

• debug : آیا می بایست اسمبلی های تولید شده را ترجمه ویا دیباگ نمود ؟ (مقدار پیش فرض False  ).

• defaultLanguage : زبان برنامه نویسی پیش فرض نظیر VB و یا #C برای استفاده در فایل های ترجمه پویا را مشخص می نماید.

• tempDirectory : دایرکتوری مورد نظر برای استفاده موقت در حین ترجمه را مشخص می نماید . به صورت پیش فرض ، ASP.NET فایل موقت را در مسیر
   [WinNTWindows]Microsoft.NETFramework[version]Temporary ASP.NET ایجاد می نماید .

• compilers : بخش <compilers> ، می تواند شامل چندین زیر عنصر <compile> باشد که از آنان به منظور ایجاد یک تعریف جدید کمپایل استفاده می گردد .

• numRecompilesBeforeAppRestart : تعداد دفعات ترجمه ، قبل از راه اندازی برنامه مشخص می نماید .

قابلیت های مرورگر
شناسائی و استفاده از پتانسیل مرورگرها برای برنامه های وب ضروری است . browser capabilities component  بگونه ای طراحی شده است  تا بتواند از مرورگرهای مختلفی نظیر  opera , netscape و IE  حمایت نماید .  با استفاده از <browserCaps> می توان تنظیمات پیکربندی را برای browser capabilities component  مشخص نمود . از عنصر فوق می توان در سطوح متفاوتی ‌نظیر ماشین ، سایت ، برنامه و زیر دایرکتوری ها استفاده نمود .
پس از دریافت یک درخواست از یک مرورگر ، browser capabilities component  قابلیت های مرورگر را از طریق هدر درخواست شناسائی و برای هر نوع مرورگر یک مجموعه از تنطیمات مرتبط با برنامه را ترجمه می نماید . تنظیمات فوق را می توان به صورت ایستا انجام و یا از هدر درخواست ارسالی استفاده نمود  . یک برنامه می تواند در صورت ضرورت تنظیمات فوق را را توسعه و یا تغییر دهد .
در ASP.NET 2.0 تمامی اطلاعات مربوط به قابلیت های مرورگر در  "فایل های تعریف مرورگر"  ارائه می گردند . این نوع فایل ها ، فایل هائی با انشعاب browser.*  و فرمت xml می باشند . یک فایل ممکن است شامل تعریف بیش از یک نوع مرورگر باشد . فایل های فوق در زمان نصب فریمورک در آدرس
[WinNTWindows]Microsoft.NETFrameworkxxxxxCONFIGBrowsers نصب می گردند . ( در ASP.NET 1.x ، اطلاعات مربوط به پتانسیل هر مرورگر در فایل های machine.config و web.config ذخیره می گردد ).

هر مرورگر به عنوان یک موجودیت و با استفاده از عنصر <browser> تعریف و دارای یک id مختص به خود  است که یک کلاس از مرورگر را به همراه کلاس parent مشخص می نماید . <browsers> ، عنصر ریشه در فایل های تعریف مرورگر است و  از خصلت id به منظور تمایز بین تعاریف هر یک از مرورگر ها ( در صورتی که بیش از یک مورد در یک فایل تعریف شده باشد ) ، استفاده می گردد .  
قبل از اجرای یک برنامه ASP.NET ، فریمورک تمامی تعاریف مرورگر را در یک اسمبلی ترجمه و آنان را در GAC ذخیره می نماید .
در صورت تغییر فایل های تعریف مرورگر در سطح سیستم ، تغییرات به صورت اتوماتیک بر روی هر یک از برنامه های ASP.NET اعمال نخواهد شد . بنابراین ، این مسئولیت پیاده کنندگان و یا ابزارهای نصب است که اطلاعات فوق را بهنگام نمایند . اطلاعات بهنگام شده مرورگر را می توان با استفاده از برنامه aspnet_regbrowsers.exe برای تمامی برنامه های ASP.NET ارسال نمود . پس از اجرای برنامه فوق ، اطلاعات مرورگر مجددا" ترجمه و اسمبلی جدید در GAC  ذخیره می گردد . از اسمبلی فوق تمامی برنامه های ASP.NET استفاده می نمایند .

 خطاهای سفارشی
در صورت بروز اشکال در هر یک از صفحات ASP.NET ، یک صفحه خطاء نمایش داده می شود که در آن کد نوشته شده به همراه مکان ( شماره خط ) بروز خطاء نشان داده می شود . نمایش کد منبع و مکان بروز خطاء در یک صفحه چالش های مختص به خود را دارد :

• نمایش کد منبع و پیام خطاء  برای کاربران عادی هیچگونه ارزش اطلاعاتی ندارد، پس چرا می بایست آنان را نمایش داد ؟  

• نمایش کد منبع و پیام خطاء بیش از همه مهاجمان فرصت طلب را خوشحال خواهد کرد چراکه شرایط مناسبی برای ارتقاء دانش آنان به منظور برنامه ریزی حملات فراهم می گردد . 

ASP.NET با ارائه یک زیرساخت مناسب امکان پیشگیری از نمایش اینگونه خطاها را در اختیار پیاده کنندگان برنامه های وب قرار می دهد . بدین منظور از بخش <customeErrors>  در فایل web.config برای تعریف پیام های خطاء سفارشی و سیاست نمایش جزئیات خطاء استفاده می گردد . نحوه استفاده از عنصر فوق به صورت زیر است :

<customErrors defaultRedirect="[url]" mode="[on/off/remote]">          <error statusCode="[statuscode]" redirect="[url]" /> </customErrors>rs>

توضیحات :

• defaultRedirect : آدرس صفحه ای را که پس از بروز خطاء مرورگر کاربران به آن هدایت می گردند را مشخص می نماید .  

• mode : مقدار نسبت داده شده به این خصلت وضعیت نمایش خطاء سفارشی را مشخص می نماید . در صورتی که مقدار این خصلت on باشد ، خطاهای سفارشی نمایش داده می شوند . در صورتی که مقدار mode معادل off باشد ، خطاهای سفارشی نمایش داده نخواهند شد و در صورتی که مقدار این خصلت remote در نظر گرفته شود ، خطاهای سفارشی صرفا" برای کاربران از راه دور نمایش داده می شود .

• customeErrors : این بخش شامل چندین زیرعنصر <error> است که از  آنان به منظور تعریف خطاهای سفارشی استفاده می گردد . هر زیر عنصر <error>  می تواند شامل یک خصلت statusCode و یک URL باشد . 

<configuration>   <system.web>     <customErrors mode="RemoteOnly" defaultRedirect="/DefaultErrorPage.htm">         <error statusCode="500" redirect="/error/ServerError.htm"/>           <error statusCode="404" redirect="/error/Filenotfound.aspx"/>           <error statusCode="403" redirect="/error/Forbidden.aspx"/>    </customErrors>   </system.web> </configuration>

در بخش چهارم به بررسی سایر تنظیمات پیکربندی خواهیم پرداخت .

سیستم پیکربندی ASP.NET 2.0 (بخش دوم )

در بخش اول با اصول اولیه سیستم پیکربندی ASP.NET 2.0 آشنا شدیم . در این بخش به بررسی برخی از تنظمیات پیکربندی خواهیم پرداخت .

‍‍‍Connection String
در ASP.NET 1.x ، اطلاعات مربوط به connection string در بخش <appSetting> ذخیره می گردید . در ASP.NET 2.0 ، تمامی اطلاعات در ارتباط با connection-string در یک  بخش جدید با نام <connectionStrings> ذخیره می گردد .
ذخیره اطلاعات connection - string در بخش <appSetting>  دارای چالش های مختص به خود است :

• زمانی که اطلاعات connection string در بخش appSetting  ذخیره می گردد ، برای یک کنترل مرتبط با داده نظیر SqlCacheDependency و یا MembershipProvider  امکان دستیابی به اطلاعات وجود ندارد . 

• ایمن سازی Connection string با استفاده از الگوریتم های رمزنگاری چالش های خاص خود را دارد .

• ویژگی فوق صرفا" در ارتباط با برنامه های ASP.NET نبوده و  تمامی برنامه های دات نت نظیر Windows Forms , Web Service و سایر موارد دیگر را نیز شامل می شود .

با توجه به این که اطلاعات connection string مستقل از بخش appSetting ذخیره می گردد ، می توان آنان را با استفاده از مجموعه متد ConnectionString بازیابی نمود .
کد زیر نحوه ذخیره  connection string در فایل Web.config  را نشان می دهد .

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">   <connectionStrings>       <add            name="MyConnectionString1"            connectionString="Data Source providerName="System.Data.SqlClient" />    </connectionStrings> </configuration>

نحوه بازیابی اطلاعات یک connection string در برنامه :

Public Sub Page_Load (sender As Object, e As EventArgs) ... Dim dbConnection as New _    SqlConnection(ConfigurationSettings.ConnectionStrings("MyConnectionString1")) ... End Sub

پیکربندی Session State
state management یکی از مسائل مهم در زمان پیاده سازی برنامه های وب است که می بایست با توجه به اهمیت آن به درستی با ابعاد آن آشنا گردید . در گذشته ای نه چندان دور ( ده سال پیش ) ، با این که برای پیاده سازی برنامه های کامپیوتری از معماری client-server  استفاده می گردید ولی عملا"  در معماری فوق ما دارای یک fat client و یک  fat server می باشیم که برای ذخیره state از امکانات موجود در سمت سرویس دهنده و یا سرویس گیرنده استفاده می شود . با توجه به این که در  معماری فوق ، یک ارتباط دائم بین سرویس گیرندگان و سرویس دهنده وجود دارد برای ذخیره و نگهداری state با مشکل خاصی مواجه نمی شویم .
در برنامه های وب گفتگوی بین یک سرویس گیرنده و یک سرویس دهنده از طریق پروتکل HTTP انجام می شود و جملگی به خوبی می دانیم که این پروتکل یک پروتکل stateless است و ارتباط با یک سرویس دهنده از راه دور در زمان مورد نیاز ایجاد و در ادامه و پس از سرویس دهی ، غیرفعال می شود . با این که HTTP 1.1 از یک روش Keep-alive استفاده می نماید ولی سرویس دهنده نمی تواند درخواست های ایجاد شده توسط یک سرویس گیرنده را تشخیص دهد . 
برای ذخیره و نگهداری state  از گزینه های متعددی استفاده می گردد که session یک نمونه در این زمینه است .شی Session متداولترین محلی است که می توان اطلاعات مربوط به وضعیت برنامه  و کاربران را  در آن ذخیره و نگهداری نمود . برای پیاده سازی session از یک Hashtable استفاده می گردد و  داده بر اساس ترکیب زوج  کلید و مقدار ذخیره می شود .
Session در ASP.NET 2.0 یک مفهوم جدید نیست و متاثر از ماهیت پروتکل HTTP  است ( Stateless ) و قبل از ASP.NET و حتی ASP کلاسیک وجود داشته است .

داده Session در چه مکانی ذخیره می گردد ؟
شی Session یک روش موثر برای ذخیره و نگهداری وضعیت یک برنامه و یا کاربران آن را ارائه می نماید. ASP.NET به همراه سه Storage Provider ارائه شده است :

• In-Process Session State Store : اطلاعات session در Cache ( حافظه ) ذخیره می گردد .

• Out-of-Process Session State Store : اطلاعات Session در State Server Service ذخیره می گردد ( asp_net_state.exe )

• Sql Session State Store : اطلاعات session در بانک اطلاعاتی SQL ذخیره می گردد . برای پیکربندی از aspnet_regsql.exe استفاده می گردد .

در  ASP.NET 2.0 ، یک قابلیت جدید با نام custome به مجموعه فوق اضافه شده است . با استفاده از گزینه فوق ، پیاده کنندگان می توانند داده session را در یک مکان دائم ذخیره نمایند . مثلا" ASP.NET 2.0 امکان ذخیره داده session را در  برخی بانک های اطلاعاتی  نظیر Oracle,DB2 و یا Sybase ندارد . در صورتی که بخواهیم داده session را در یکی از  بانک های اطلاعاتی فوق و یا یک فایل XML ذخیره نمائیم ، می توان از یک Provider class سفارشی استفاده نمود .
برای پیکربندی اطلاعات session از عنصر <sessiononState > در فایل web.config  استفاده می گردد :

<configuration>    <system.web>      <sessionState mode="Off|InProc|StateServer|SQLServer|Custom" ../>    </system.web> ... </configuration>

 
در ادامه به بررسی مختصر هر یک از گزینه های فوق خواهیم پرداخت .

In-Process Session State Store  : متداولترین و در عین حال سریعترین روش پیکربندی session state در ASP.NET 2.0 می باشد ( مقدار mode برابر inproc در نظر گرفته می شود )  .در این روش داده Session  در cache داخلی HttpRuntime ذخیره شده و به صورت live قابل دستیابی است . با توجه به این که داده session در حافطه ذخیره می گردد ، به سرعت می توان به آن دستیابی داشت ( ضرورتی ندارد  داده از یک مکان دیگر به درون حافظه انتقال یابد ).  داده seesion تا زمان اعتبار session در حافظه موجود می باشد و پس از time out فضای اشغال شده آزاد می گردد . 

Out-of-Process Session State Store : داده  session  در یک process که به عنوان یک سرویس ویندوز اجراء می گردد ، نگهداری می شود ( aspnet_state.exe ) .
 State Service به صورت پیش فرض اجراء نمی گردد و برای فعال کردن آن می توان از دستور net start aspnet_sate استفاده نمود . به صورت پیش فرض ، سرویس فوق از پورت 42424 استفاده می نماید . در صورت ضرورت می توان با استفاده از کلید ریجستری زیر آن را تغییر داد .

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesaspnet_stateParametersPort

برای استفاده از روش فوق کافی است که مقدار Inproc به StateServer در فایل web.config تغییر داد . همچنین می بایست از خصلت StateConnectionString به منظور مشخص نمودن IP و شماره پورتی که Session State Service بر روی آن اجراء شده است ، استفاده نمود .

<configuration>   <system.web>      <sessionState mode="StateServer"           stateConnectionString="tcpip=127.0.0.1:42424"/>   </system.web> </configuration>

Sql Session State Store : داده session در یک بانک اطلاعاتی SQL ذخیره می گردد .

<configuration>   <system.web>     <sessionState         mode="SQLServer"         sqlConnectionString="data source= TestSessionServer;         user id=TestWebUser;password=Test"         cookieless="false"         timeout="20"      />  </system.web> </configuration>.

Custom State Store :معماری Sessin state در ASP.NET 2.0 بگونه ای طراحی شده است که امکان افزودن Provider به آن وجود دارد ( مشتق شده از کلاس SessionStateStoreProviderBase  ) . در صورتی که بخواهیم Provider اختصاصی خود را ایجاد و یا از یک  third-party provider استفاده نمائیم ، می بایست مقدار خصلت mode را Custome در نظر گرفت . در چنین مواردی ، لازم است که custom provider assembly مشتق شده از کلاس SessionStateStoreProviderBase را مشخص نمود .

<configuration>   <system.web>     <sessionState         mode="Custom"           CustomProvider="CustomStateProvider">           <providers>              <add name="CustomStateProvider"                 type="CustomStateProviderAssembly,                 CustomStateProviderNamespace.CustomStateProviderSateProvider"/>            </providers>    </sesisonState>  </system.web> </configuration>

 مثال : کد زیر یک نمونه از پیکربندی sessionState  در فایل web.config را نشان می دهد :

<sessionState       mode="StateServer"       cookieless="false"       timeout="20"       stateConnectionString="tcpip=TestSessionStore:42424"       stateNetworkTimeout="60"       sqlConnectionString="" />

توضیحات :

• mode : نوع ذخیره سازی اطلاعات session را مشخص می نماید . در این رابطه از پنج گزینه Off, InProc, StateServer, SQLServer  و Custom استفاده می گردد . که مقدار پیش فرض InProc است .  

•  cookieless : مشخص می نماید که آیا از HTTP cookieless Session Key management حمایت می گردد .

• timeout : مدت زمان حیات Session را مشخص می نماید  . مقدار timeoute بر اساس زمان درخواست ارزیابی می گردد . مثلا" در صورتی که مقدار timeout بیست دقیقه باشد و در خواستی در ساعت ده و ده دقیقه دریافت گردد ، timeout در ساعت ده و سی دقیقه به اتمام می رسد .

• stateConnnectionString :از خصلت  فوق به منظور مشخص نمودن آدرس  TCP/IP و پورت جهت ارتباط یا  Windows Service providing state management استفاده می گردد ( در مواردی که mode=StateServer در نظر گرفته شود ) .

• stateNetworkTimeout : مقدار timeout ( بر حسب ثانیه ) را  در زمان ذخیره state در یک out-of-process session ( نظیر  StateServer ) ، مشخص می نماید . 

• sqlConnectionString : از خصلت فوق  جهت ارتباط با بانک اطلاعاتی SQL Server  برای ذخیره و بازیابی داده session استفاده می گردد ( در مواردی که mode=SQLServer در نظر گرفته شود) . 

پیکربندی Session State  با استفاده از Connection string  : کد زیر یک نمونه از پیکربندی Session State با استفاده از connection string را نشان می دهد :

<configuration>  <connectionStrings>    <add name = "TestSessionState"       connectionString = "data source=TestSessionServer;       user id=TestWebUser;password=test" />  </connectionStrings>  <system.web>    <sessionState      mode="SQLServer"      sqlConnectionString="TestSessionState"      cookieless="false"      timeout="20"     />  </system.web> </configuration>

در بخش سوم به بررسی سایر تنظیمات پیکربندی خواهیم پرداخت .

سیستم پیکربندی ASP.NET 2.0 (بخش اول)

پیاده کنندگان برنامه های وب که از  فن آوری ASP کلاسیک به منظور پیاده سازی برنامه های وب در گذشته ای نه چندان دور استفاده می کردند ( و شاید هم اینک نیز استفاده می نمایند ) ، به یاد دارند که اطلاعات پیکربندی برنامه های فوق به صورت باینری و در محلی با نام متابیس IIS ، ذخیره می گردد . پیاده کنندگان برنامه های وب برای اعمال تغییرات لازم در متابیس از دو گزینه متداول استفاده می کردند : نوشتن اسکریپت های مورد نیاز و یا استفاده از کنسول مدیریتی برنامه IIS ( سرویس دهنده وب مایکروسافت ) .
برخلاف ASP کلاسیک ، در ASP.NET 1.x حضور متابیس ها کم رنگ گردید و در مقابل ، استفاده از یک سیستم پیکربندی مبتنی بر xml مورد توجه قرار گرفت . علیرغم این که سیستم فوق دارای انعطاف بمراتب بیشتری نسبت به نسخه قبلی است ولی امکانات مدیریتی مناسبی را به منظور ویرایش فایل های پیکربندی در اختیار پیاده کنندگان برنامه های وب قرار نمی دهد . تنها گزینه موجود برای ویرایش یک فایل پیکربندی ، برخورد با فایل پیکربندی به عنوان یک فایل xml و بهنگام سازی آن فایل بر اساس ماهیت فایل های xml است .  مهمترین مشکل رویکرد فوق ، برخورد با تمامی بخش های فایل پیکربندی به عنوان گره های xml است .
در ASP.NET 2.0 ، امکانات و پتانسیل های متعددی به منظور مدیریت پیکربندی برنامه های وب ارائه شده است با این هدف که بتوان با سادگی و سرعت بیشتری پیکربندی یک برنامه وب را انجام داد .خواندن و ویرایش فایل های پیکربندی در یک ماشین محلی و یا از راه دور از جمله مهمترین ویژگی های ارائه شده در ASP.NET 2.0 می باشد .
اطلاعات پیکربندی یک برنامه ASP.NET  در دو فایل مهم Xml ذخیره می گردد . از Xml برای تشریح خصلت ها و رفتار جنبه های مختلف برنامه های ASP.NET استفاده می‌شود . سیستم  پیکربندی ASP.NET از دو فایل پیکربندی استفاده می نماید :

• machine.config : فایل پیکربندی سرویس دهنده 

• Web.Config : فایل پیکربندی برنامه

با توجه به ماهیت فایل های پیکربندی ( فایل هائی از نوع  xml ) ، عناصری که مسئولیت تشریح پیکربندی را برعهده دارند نسبت به حروف بزرگ و کوچک حساس می باشند .
در مثال زیر ، یک نمونه فایل  web.config  به همراه بخش مربوط به معرفی <sessionState> یک برنامه وب  نشان داده شده است .

<?xml version="1.0" encoding="UTF-8" ?>  <configuration>    <system.web>        <sessionState            mode="InProc"            stateConnectionString="tcpip=127.0.0.1:42424"            stateNetworkTimeout="10"            sqlConnectionString="data source=127.0.0.1; user id=sa; password=test"            cookieless="false"            timeout="20"        />     </system.web> </configuration>

مزایای استفاده از یک فایل xml برای پیکربندی (در مقابل یک متابیس باینری )

• امکان خواندن اطلاعات پیکربندی وجود داشته و می توان به سادگی و با استفاده از یک ویرایشگر متن نظیر NotePad آنان را ویرایش نمود  ( گرچه توصیه می گردد که در این رابطه از ویژوال استودیو 2005 و یا ادیتوری  که قادر به تشخیص تگ های xml می باشد ، استفاده گردد). فایل پیکربندی را می توان به سادگی از یک سرویس دهنده به سرویس دهنده دیگر منتقل نمود . ویژگی فوق در یک Web Farm بسیار مفید و موثر می باشد .

• پس از انجام تغییرات مورد نیاز  در یک فایل پیکربندی ، ASP.NET به صورت اتوماتیک تغییرات ایجاد شده را تشخیص و آنان را در ارتباط با برنامه اعمال خواهد کرد . ASP.NET بدین منظور یک نمونه جدید از برنامه را ایجاد و کاربران را به برنامه جدید هدایت می نماید .

• پس از اعمال تغییرات در پیکربندی یک برنامه ASP.NET ، ضرورتی ندارد که مدیریت برنامه سرویس دهنده وب را متوقف و مجددا" فعالیت آن را آغاز نماید . 

• سیستم پیکربندی ASP.NET قابل توسعه است و اطلاعات مرتبط با یک برنامه را می توان به سادگی ذخیره و بازیابی نمود .

• اطلاعات حساس ذخیره شده در سیستم پیکربندی ASP.NET 2.0 را می توان در صورت تمایل به صورت رمزشده ذخیره نمود ( اقدامی در جهت افزایش امنیت و ایمن سازی برنامه های وب خصوصا" اطلاعات حساس مرتبط با آنان ) .

فایل پیکربندی سرویس دهنده  : machine.config
هر سرویس دهنده ASP.NET دارای یک فایل پیکربندی با نام machine.config است که در زمان نصب فریمورک بر روی سیستم ایجاد می گردد . فایل فوق در مسیر C:WindowsMicrosoft.NETFrameworkv2.0xxxxx نصب و از محتویات آن به عنوان تنظیمات پیش فرض در تمامی برنامه های ASP.NET نصب شده بر روی سرویس دهنده استفاده می گردد . با توجه به نقش مهم این فایل در عملکرد تمامی برنامه های موجود بر روی کامپیوتر ( ویندور ، وب ) لازم است که تغییر در فایل فوق با دقت خاصی انجام شود و نسبت به نوع کار و دامنه متاثر از تغییرات شناخت کافی وجود داشته باشد .
در صورتی که بر روی سیستم چندین نسخه از فریمورک دات نت نصب شده باشد ، هر نسخه دارای فایل پیکربندی machine.config مختص به خود است  . مثلا" در صورتی که بر روی کامپیوتر نسخه های ASP.NET 1.1 ، ASP.NET 1.0 و ASP.NET 2.0  نصب شده باشد ، هر نسخه فریمورک دارای فایل machine.config مختص به خود است . این بدان معنی است که بر روی سرویس دهنده فوق سه فایل پیکربندی machine.config  وجود خواهد داشت .
علاوه بر فایل machine.config ، فریمورک دات نت دو فایل دیگر را به اسامی machine.config.default  و  machine.config.comments نیز نصب می نماید . از فایل اول به عنوان نسخه backup فایل machine.config استفاده می گردد. در صورتی که بخواهیم به تنظیمات اولیه برگردیم ، کافی است تنظیمات موجود در فایل machine.config.default را به فایل machine.config کپی نمود . در فایل دوم ( machine.config.Comments ) ، هر بخش از فایل پیکربندی تشریح  می گردد .
 ASP.NET runtime ، از دو فایل فوق استفاده نمی نماید و صرفا" بدین جهت نصب شده اند تا در صورت ضرورت از آنان به منظور برگشت به حالت اولیه استفاده نمود ( default factory setting ) .

فایل پیکربندی برنامه  : web.config
برخلاف فایل machine.config ، هر برنامه ASP.NET دارای نسخه اختصاصی تنظیمات پیکربندی مختص به خود است که در فایلی با نام web.config ذخیره می گردد . در صورتی که برنامه وب دارای چندین Subfolder باشد ، هر subfolder دارای فایل web.config مختص به خود است  که محتویات آن از تنظیمات موجود در فایل پیکربندی parent به ارث رسیده است و یا تنظیمات مورد نظر را خود تعریف می نماید . 
برای بهنگام سازی سرویس دهندگان در farm ( بر اساس تنظمیات جدید ) ، می توان به سادگی فایل web.config را به دایرکتوری مربوط به برنامه کپی نمود . در چنین مواردی ضرورتی به دستیابی سرویس دهنده محلی و راه اندازی آن وجود نداشته و برنامه ادامه فعالیت خود را به صورت طبیعی و بر اساس تنظیمات جدید انجام خواهد داد .

 نحوه بکارگیری پیکربندی
زمانی که ASP.NET runtime ، تنظمیات پیکربندی را برای یک درخواست وب بکار می گیرد ، فایل machine.config در یک مجموعه ترکیب و اطلاعات فوق در ارتباط با برنامه مورد نظر بکار گرفته می شوند . تنظیمات پیکربندی از برنامه وب parent به ارث برده می شود . فایل machine.config به عنوان parent تمامی برنامه های وب در نظر گرفته می شود .
پیکربندی هر برنامه وب منحصربفرد است گرچه این تنظیمات از parent به ارث رسیده باشند . مثلا" در صورتی که فایل web.config موجود در فهرست ریشه یک وب سایت مقدار session timeout  را معادل ده دقیقه تعریف نماید ، تنظمیات پیش فرض در فایل machine.config که مقدار session timeout را بیست دقیقه تعریف کرده است ، نادیده می گیرد . 

تشخیص تغییر در فایل پیکربندی
ASP.NET به صورت اتوماتیک تغییرات ایجاد شده در فایل های machine.config و web.config را تشخیص می دهد . تشخیص فوق توسط  رویداد file-change که توسط سیستم عامل محقق می گردد ، انجام می شود .
زمانی که یک برنامه ASP.NET فعالیت خود را آغاز می نماید ، تنظیمات پیکربندی خوانده شده و  در ASP.NET Cache ذخیره می شوند .در ادامه یک file dependency در entry مربوط به cache در فایل machine.config و یا web.config قرار می گیرد . پس از تشخیص تغییر در فایل های machine.config و یا web.config ، یک application domain جدید توسط ASP.NET ایجاد تا به درخواست های جدید سرویس دهد . application domain قدیم پس از پاسخگوئی به درخواست های جاری از بین خواهد رفت .

فرمت فایل پیکربندی
شاید تنها تفاوت اصلی فایل های web.config و machine.config ، نام آنان باشد و شکل و ساختار دو فایل فوق مشابه است . فایل های پیکربندی به چندین بخش تقسیم و هر بخش توسط یک xml element سطح بالا مشخص می گردد . عنصر ریشه xml یک فایل پیکربندی ،  <configuration>  نامیده می شود .
در مثال زیر ، یک فایل نمونه web.config نشان داده شده است ( مقادیر بین علائم [] ، در یک فایل پیکربندی واقعی ، با مقادیر واقعی جایگزین می گردند )  .

<?xml version="1.0" encoding="UTF-8"?>   <configuration>        <configSections>             <section name="[sectionSettings]" type="[Class]"/>             <sectionGroup name="[sectionGroup]">                   <section name="[sectionSettings]" type="[Class]"/>              </sectionGroup>        </configSections>    </configuration>

عنصر ریشه Xml یک فایل پیکربندی همواره <configuration>  نامیده می شود . هر section handler به همراه تنظمیات مربوطه در یک <SectionGroup> قرار می گیرند . <SectionGroup> یک ساختار سازمانی درون فایل پیکربندی را ارائه  می نماید تا به کمک آن بتوان پیکربندی مورد نیاز را در گروه های منحصربفرد انجام داد  . به عنوان نمونه بخش <system.web> درون فایل پیکربندی ، مکانی را  که اطلاعات آن در ارتباط با  ASP.NET می باشد ، مشخص می نماید.
پس از آشنائی اولیه با اصول سیستم پیکربندی ASP.NET 2.0 در بخش بعدی با برخی از تنظمیات پیکربندی آشنا خواهیم شد .

برنامه های وب مبتنی بر سرویس گیرنده : AJAX و Atlas

یکی از ویژگی های مهم برنامه های وب ، تبعیت آنان از معماری "سرویس گیرنده - سرویس دهنده"  است . این بدان معنی است که پیاده کنندگان برنامه های وب می توانند به منظور تحقق پردازش های سمت سرویس دهنده و سرویس گیرنده از فن آوری های متعددی استفاده نمایند. یکی از نکات مهم در خصوص انجام پردازش های سمت سرویس گیرنده ، میزان وابستگی آنان به اطلاعات موجود در سمت سرویس دهنده است . به عبارت دیگر ، اجرای یک event handler در سرویس گیرنده تا چه میزان وابسته به کد سمت سرویس دهنده است و  به منظور انجام آن چه میزان داده می بایست بین سرویس گیرنده و سرویس دهنده مبادله گردد ؟
صرفنظر از این که  به سوال فوق چه پاسخی داده می شود ، واقعیت این است که به منظور مدیریت رویدادهای محقق شده در سمت سرویس گیرنده ، می بایست ملزومات مورد نیاز ایجاد تا پیاده کنندگان بتوانند با استفاده از آنان پردازش های سمت سرویس گیرنده را مدیریت نمایند .

پردازش های سمت سرویس گیرنده از گذشته تاکنون
با توجه به این که پردازش های سمت سرویس گیرنده در برنامه های وب می بایست مستقل از نوع پلت فرم باشند ،  بدیهی است که تمامی تلاش های انجام شده در این عرصه ، می بایست متمرکز بر روی برنامه های مرورگر باشد تا با ایجاد پتانسیل هائی در آنها ، امکان انجام پردازش های سمت سرویس گیرنده فراهم گردد . ظهور زبان های اسکریپت نویسی نظیر جاوااسکریپت و  تجهیز مرورگرها به برنامه های مفسر مربوطه از جمله اقدامات عملی دراین عرصه است . استفاده از زبان جاوااسکریپت به منظور کدینگ پردازش های سمت سرویس گیرنده دارای قدمتی چندین ساله است . در ادامه ، قابلیت های جدیدی به مرورگرها اضافه گردید تا پیاده کنندگان بتوانند به کمک آنان برنامه های وب سمت سرویس گیرنده را ایجاد نمایند . هم اینک ، تمامی مرورگرهای متداول از یک مدل شی گراء موسوم  به DOM ( برگرفته از document object model ) استفاده می نمایند و تعداد اندکی از آنها از یک ویژگی جدید با نام XMLHTTP استفاده می نمایند  که به کمک آن ،  سرویس گیرندگان و سرویس دهندگان می توانند بدون نیاز به انجام یک postback کامل و round trip با یکدیگر و به صورت مستقیم ارتباط برقرار نمایند.
XMLHTTP  ، شامل مجموعه ای API ( رابط برنامه نویسی ) است که امکان ارسال و یا دریافت داده به صورت باینری ، HTML و XML را از سرویس دهندگان وب بر روی اینترنت و به کمک پروتکل HTTP فراهم می نماید .  در مواردی که نیاز به داده موجود در سمت سرویس دهنده می باشد ،  XMLHTTP  به صورت پیوسته اقدام به ارسال درخواست خود برای سرویس دهنده می نماید تا آخرین اطلاعات را بدون نیاز به refresh کردن مدام مرورگرها ، بازیابی نماید . در واقع ، به کمک فن آوری فوق ، سرویس گیرندگان قادر به مبادله غیرهمزمان با سرویس دهنده بوده و می توانند اقدام به ارسال و یا دریافت داده XML بدون نیاز به انجام یک round trip کامل که باعث تولید مجدد یک صفحه می گردد ، نمایند .
ماحصل این تحولات ، ظهور نسل جدیدی از برنامه های وب نظیر  Microsoft Virtual Earth  و   Microsoft Windows Live  است . ایجاد چنین برنامه های وبی کار ساده ای نخواهد بود و پیاده کنندگان می بایست شناخت مناسبی نسبت به جاوااسکریپت و مدل DOM  داشته باشند که ممکن است در هر مرورگر متفاوت باشد . علاوه بر این ، جاوااسکریپت تمامی ویژگی های یک زبان شی گراء را ارائه نمی نماید و بسیاری از ملزومات مورد نیاز پیاده کنندگان برنامه های وب در فریمورک دات نت را تامین نمی نماید ( نظیر type-safe ) .

ایجاد برنامه های وب با تاکید بر انجام پردازش سمت سرویس گیرنده ، نیازمند ملزوماتی نظیر یک زبان برنامه نویسی و پلت فرم پیاده سازی جدید  است .

AJAX ( برگرفته از asynchronous JavaScript and XML )
پیاده سازی برنامه های وب با استفاده از فن آوری های اشاره شده ( اسکریپت نویسی سمت سرویس گیرنده و مبادله غیرهمزمان با سرویس دهنده ) ،  AJAX  نامیده می شود . AJAX ، پیاده کنندگان را قادر به تولید صفحاتی می نماید که از توان پاسخگوئی بسیار مطلوبی در سمت سرویس گیرنده متناسب با رویداد ایجاده شده ، برخوردار می باشند . چراکه آنها  از اسکریپت های سمت سرویس دهنده برای دستیابی و مدیریت عناصر بخش رابط کاربر استفاده می نمایند . علاوه بر این ، با توجه به مبادله غیرهمزمان داده به منظور ارسال و دریافت داده ، امکان انجام عملیات مورد نظر بر روی داده بدون وقفه و ازدست دادن state وجود خواهد داشت .  Microsoft Virtual Earth  و برنامه سرویس گیرنده نامه های الکترونیکی Outlook Web Access  ،  دو نمونه از برنامه های سبک AJAX ، می باشند .

Atlas : تلاش‍ی در جهت ایجاد یک  پلت فرم پیاده سازی جامع 
فن آوری جدید ASP.NET با نام Atlas ، مجموعه ای از فن آوری های مایکروسافت را شامل می شود  که با تمرکز بر روی اصول AJAX ، سعی در توسعه و بهبود آن را دارد .
Atlas ، یک فن آوری جدید در عرصه پیاده سازی برنامه های وب ASP.NET است که  کتابخانه های اسکریپت سرویس گیرنده را با فریمورک پیاده سازی مبتنی بر سرویس دهنده ASP.NET 2.0 ترکیب می نماید . در واقع ، Atlas به پیاده کنندگان برنامه های وب یک پلت فرم مناسب به منظور پیاده  سازی صفحات وب مبتنی بر سرویس گیرنده را ارائه می نماید که قبلا" مشابه آن در خصوص صفحات وب مبتنی بر سرویس دهنده توسط ASP.NET ارائه شده بود . با توجه به این که Atlas ، به عنوان یک پتانسیل اضافه در کنار ASP.NET مطرح می باشد ، بدیهی است که کاملا" سازگار با سرویس های مبتنی بر سرویس دهنده باشد . با استفاده از Atlas ، می توان بخش قابل توجهی از پردازش های مورد نیاز یک برنامه را به سمت سرویس گیرنده انتقال داد ( fat-client ) . در چنین مواردی ، امکان ارتباط سرویس گیرنده با سرویس دهنده در background فراهم می گردد. ماحصل این فن آوری ، ایجاد برنامه های وبی است که علاوه بر ارائه امکانات مناسب  در لایه رابط کاربر ( UI ) ، دارای توان پاسخگوئی بالائی می باشند و به سادگی می توانند با سرویس دهنده ارتباط برقرار نمایند .

مفاهیم فنی اولیه AJAX
در AJAX ، پیاده کنندگان می توانند سرویس های وب را بطور غیرهمزمان و از طریق اسکریپت های سمت سرویس گیرنده و با استفاده از شی XMLHTTPRequest  فراخوانده تا اطلاعات به عنوان داده XML بسته بندی و در ادامه آنها را بر روی شبکه ارسال نمایند . بدین منظور شی XMLHTTPRequest یک شی پراکسی را ارائه می نماید تا به کمک آن امکان فراخوانی از راه دور و مبادله داده فراهم گردد . در فن آوری AJAX از زبان های اسکرپیت سمت سرویس گیرنده نظیر جاوااسکریپت بطرز گسترده ای استفاده می گردد . از جاوااسکریپت در مواردی نظیر فراخوانی از راه دور روتین ها ، انجام پردازش های مورد نیاز یک برنامه در سمت سرویس گیرنده و ایجاد ویژگی های پیشرفته ای در سطح لایه رابط کاربر استفاده می شود .
AJAX علاوه بر جاوااسکریپت از چندین فن آوری دیگر در سمت سرویس گیرنده نیز استفاده می نماید :

• DOM : به کمک فن آوری فوق ، عناصر موجود در یک صفحه HTML به عنوان مجموعه ای از اشیاء استاندارد ( نظیر document و windows ) در نظر گرفته می شوند . بدین ترتیب ، امکان دستیابی  و انجام عملیات دلخواه بر روی آنان از طریق کد فراهم می گردد .

• DHTML ( برگرفته از Dynamic HTML ) : فن آوری فوق ، توانمندی HTML را به منظور واکنش مناسب در خصوص عملیاتی که توسط کاربران انجام می شود ( نظیر درج داده ) با استفاده از اسکریپت های سمت سرویس گیرنده و بدون نیاز به یک round trip افزایش می دهد .

• رفتارها ، شامل روشی مناسب به منظور برخورد سیستماتیک با عملیاتی نظیر drag and drop در سطح لایه رابط کاربر و مرتبط با عناصر موجود بر روی یک صفحه می باشد .

• عناصر : اشیاء سفارشی شده جاوااسکریپت می باشند که پتانسیل های توسعه یافته ای را در سمت سرویس گیرنده ایجاد می نمایند .

چالش های فن آوری AJAX
برنامه نویسی صفحات به سبک AJAX دارای چالش های متعددی است :

• عناصر موجود در صفحات وب می بایست متناسب با شرایط هر مرورگر برنامه نویسی گردند ، چراکه هر مرورگر یک نسخه متفاوت از DOM و DHTML را ارائه می نمایند(هر چند این تفاوت ها اندک باشد) .

• برنامه نویسی سمت سرویس گیرنده صرفا" با استفاده از جاوااسکریپت انجام می شود . پیاده سازی برخی از پتانسیل های  AJAX می تواند برای پیاده کنندگان بسیار پیچیده باشد و نیازمند دانش بالائی در خصوص استفاده از جاوااسکریت است .

• جاوا اسکریپت ،  ویژگی ها و امکانات مورد نیاز پیاده کنندگان برنامه های دات نت را تامین نمی نماید ( نظیر یک رویکرد شی گراء کامل ) . علاوه بر این ، در این فن آوری از کتابخانه ای نظیر آنچه در پلت فرم دات نت ارائه شده است ،‌ استفاده نمی گردد و برنامه نویسان می بایست تمامی برنامه را از ابتدا کد نمایند  .

• جاوااسکریپت و پیاده سازی سمت سرویس گیرنده  ، عموما" بخوبی در IDEs حمایت نمی گردند .

فن آوری Atlas  ، مسائل اشاره شده را با ارائه یک فریمورک کامل برای ایجاد برنامه های وب مبتنی بر سرویس گیرنده برطرف می نماید.

فن آوری Atlas  ،  دارای عناصر سرویس گیرنده و سرویس دهنده ای است  که آن را  به خوبی با ASP.NET یکپارچه و مرتبط می نماید

مفاهیم فنی اولیه معماری Atlas
در ساده ترین حالت ، یک برنامه Atlas ، از کتابخانه های سمت سرویس گیرنده به منظور مدیریت رابط کاربر و فراخوانی عناصر مبتنی بر سرویس دهنده استفاده می نماید . Atlas ، همچنین عناصر سمت سرویس دهنده ای را ارائه می نماید  که با سرویس گیرنده مرتبط و می توانند اسکریپت سمت سرویس گیرنده از قبل تعریف شده ای را تولید نمایند .

عناصر سمت سرویس گیرنده Atlas
فن آوری Atlas برای پیاده سازی برنامه های سمت سرویس گیرنده ، از مجموعه ای کتابخانه سمت سرویس گیرنده ( فایل هائی با انشعاب Js . ) استفاده می نماید که پیامد آن تعریف یک رویکرد لایه ای برای ایجاد برنامه های مبتنی بر سرویس گیرنده است . این لایه ها عبارتند از :

• لایه مختص  مرورگرها : با استفاده از پتانسیل های ارائه شده توسط این لایه ، اسکریپت های Atlas در اکثر مرورگر سازگار بوده و ضرورتی به نوشتن اسکریت های مختص یک مرورگر وجود ندارد .

• سرویس های هسته atlas : شامل ضمائمی به جاوااسکریپت نظیر کلاس ها ، namespace ، event handler ، توارث ، نوع های داده و تسلسل اشیاء است . ویژگی های فوق یک مدل برنامه نویسی شی گراء را در اختیار پیاده کنندگان قرار می دهد تا به کمک بتوان علاوه بر سرعت در ایجاد برنامه ها از کد تولید شده نیز بدفعات استفاده نمود.

• کتابخانه کلاس پایه Atlas : شامل عناصری نظیر دیباگرها ، Timers ، ردیابی و string buliders است .

• لایه شبکه : این لایه با سرویس های مبتنی بر وب و برنامه ها ارتباط برقرار می نماید و  مدیریت فراخوانی متدها از راه دور و غیرهمزمان را برعهده می گیرد . لایه فوق ، مدیریت فراخوانی غیرهمزمان برروی XMLHTTP  را برعهده گرفته و باعث می گردد که پیاده کنندگان بدون این که درگیر پیچیدگی های موجود شوند با نوشتن چندین خط کد ، متدهای مورد نظر را فراخوانند .

• لایه UI  : در این لایه قابلیت های سرویس گیرنده Atlas نظیر رفتارها ، گرامر تعریفی Atlas ، عناصر UI و نسبت دهی داده  ارائه می گردد .

• لایه کنترل ها : این لایه کنترل های مختص atlas را برای پیاده سازی سمت سرویس گیرنده ایجاد می نماید . علاوه بر این که می توان از طریق اسکریپت به این کنترل ها دستیابی داشت ، امکان انجام عملیات متفاوتی نظیر نسبت دهی داده نیز وجود دارد. کنترل های  Navigation و data-bound listview نمونه هائی در این زمینه می باشند . 

•  یک مدل برنامه نویسی تعریفی که پیاده کنندگان را قادر می سازد عناصر atlas را با روشی مشابه کنترل های سرویس دهنده ASP.NET ایجاد نمایند .

فن آوری Atlas  را می توان به عنوان کتابخانه های اسکریپت سرویس گیرنده تصور نمود که زیرمجموعه ای از معماری ASP.NET بر روی ‌سرویس دهنده می باشند

برای پیاده سازی برنامه های وب سمت سرویس گیرنده ، فن آوری Atlas  ویژگی های متعددی را ارائه می نماید . ارائه یک مجموعه API برای پیاده سازی در جاوااسکریپت ، قابلیت سازگاری اتوماتیک با مرورگرها و یک مدل تعریفی برای پیاده سازی سمت سرویس گیرنده ، نمونه هائی در این زمینه م‍ی باشند . 

عناصر سمت سرویس دهنده Atlas
فن آوری Atlas ، صرفا" در ارتباط با اسکریپت های سمت سرویس گیرنده نمی باشد و از عناصر سمت سرویس دهنده ، سرویس ها و کنترل هائی استفاده می نماید که می توانند با اسکریپت های Atlas سمت سرویس گیرنده مرتبط گردند :

• سرویس های وب که ویژگی های ASP.NET نظیر سرویس های پروفایل ، membership ، roles ، personalization  و globalization را ارائه می نمایند .

• کنترل های سرویس دهنده Atlas که کنترل های سرویس دهنده ASP.NET را reasemble می نمایند ولی اسکریپت های سمت سرویس گیرنده Atlas را منتشر می نمایند . این نوع کنترل ها ارتباط بسیار نزدیکی با کنترل های سرویس دهنده ASP.NET نظیر دکمه ها ، Label و ... دارند .

• کنترل های سرویس دهنده Atlas که باعث می گردند جاوااسکریپت رفتارهای سمت سرویس گیرنده را تولید نماید . کنترل های  HoverBehavior  ، ClickBehavior ، Popup و  AutocompleteBehavior نمونه هائی در این زمینه می باشند .

• تمامی کنترل های سرویس دهند atlas در ویژوال استودیو نیر قابل استفاده می باشند. بنابراین می توان از آنان در زمان طراحی استفاده نمود ( همانند کنترل های سرویس دهنده ASP.NET  ) .

 فن آوری Atlas ، اسکریپت نویسی سمت سرویس گیرنده را با پیاده سازی سمت سرویس دهنده ASP.NET یکپارچه می نماید و پیاده کنندگان می توانند از پتانسیل های ASP.NET در سمت سرویس دهنده برای برنامه های Atlas نیز استفاده نمایند . 

هدف اولیه فن آوری Atlas   ،  ترکیب  ویژگی اسکریپت های سمت سرویس گیرنده با ویژگی هائی از ASP.NET بر روی سرویس دهنده است تا به کمک آن یک پلت فرم پیاده سازی جامع و فراگیر ایجاد گردد .

اصول امنیت برنامه های وب ( بخش دوم )

در  بخش اول به این موضوع اشاره گردید که به منظور ایجاد برنامه های وب ایمن ، می بایست از یک رویکرد جامع تبعیت و بر روی سه لایه متفاوت شبکه ، host و برنامه متمرکز گردید. در این بخش به  بررسی ایمن سازی شبکه خواهیم پرداخت .

ایمن سازی شبکه
شبکه ، نقطه ورود به یک برنامه وب است و  اولین لایه حفاظتی به منظور کنترل دستیابی به سرویس دهندگان متعدد موجود در محیط عملیاتی را فراهم می نماید . با این که سرویس دهندگان توسط سیستم های عامل نصب شده بر روی خود حفاظت می گردند ولی نمی بایست به این موضوع صرفا" اکتفاء نمود و لازم است که تدابیر لازم به منظور حفاظت آنها در مقابل سایر تهدیدات ( نظیر ارسال سیلابی ‌از بسته های اطلاعاتی از طریق لایه شبکه ) نیز اندیشیده گردد .
ایمن سازی شبکه ، شامل حفاظت از دستگاه های شبکه ای و داده مبادله شده بر روی آنها می باشد . روتر ،‌ فایروال و سوئیچ عناصر اولیه زیرساخت یک شبکه را تشکیل می دهند . شکل زیر نحوه استفاده از عناصر فوق را در یک شبکه نشان می دهد .  

 
  عناصر شبکه : روتر ،‌ فایروال و سوئیچ

یک برنامه وب بر روی یک زیرساخت شبکه ای ایمن فعالیت و به کاربران خود سرویس های لازم را ارائه می نماید . برای ایمن سازی شبکه ، علاوه بر این که شبکه می بایست در مقابل حملات مبتنی بر TCP/IP از خود محافظت نماید ، بلکه لازم است اقدامات متعدد دیگری نیز در این رابطه انجام شود . ایجاد اینترفیس های مدیریتی ایمن، استفاده از رمزهای عبور قدرتمند ، حصول اطمینان از صحت ترافیک ارسالی از جمله اقدامات دیگر در خصوص ایجاد یک شبکه ایمن می باشد . بدین منظور لازم است که   پورت ها و پروتکل های استفاده شده در هر لایه به دقت بررسی و در صورتی که وجود آنها غیرضروری تشخیص داده شود و یا استفاده از آنها زمینه بروز تهدیداتی را فراهم می نماید ،‌ می بایست در همان لایه با آنان برخورد و از یک راهکار مناسب امنیتی استفاده گردد . 
وجود ضعف امنیتی در یک شبکه زمینه بروز تهدیدات متعددی را فراهم می نماید . بدون شناسائی اینگونه تهدیدات ، امکان مقابله منطقی با آنان وجود نخواهد داشت . 

تهدیدات
یک مهاجم به منظور برنامه ریزی حملات خود به دنبال دستگاه های شبکه ای است که بر روی آنها پیکربندی ضعیفی اعمال شده است . تنظیمات ضعیف پیش فرض ، دستیابی بدون ضابطه به منابع موجود بر روی شبکه ، وجود دستگاه هائی که به درستی patch و یا بهنگام نشده اند، حفره های امنیتی متعددی را در یک شبکه ایجاد می نماید . وجود حفره های امنتیی فوق و عدم برخورد مناسب با آنها ، احتمال موفقیت مهاجمان را افزایش می دهد .
مهمترین تهدیدات در یک شبکه عبارتند از :

• جمع آوری اطلاعات
• sniffing
• spoofing
• session hijacking
• DoS ( برگرفته از Denial of Service )

با آگاهی از ماهیت هر یک از تهدیدات فوق و نحوه تاثیر آنها بر روی عملکرد شبکه ، می توان امکانات حفاظتی و تدافعی مناسبی را در یک شبکه پیش بینی و پیاده سازی نمود.
در ادامه به بررسی مختصر هر یک از تهدیدات فوق خواهیم پرداخت .

جمع آوری اطلاعات
مهاجمان در اولین مرحله ،‌اقدام به جمع آوری اطلاعات در رابطه با اهداف خود می نمایند . جمع آوری اطلاعات می تواند باعث افشای اطلاعات توپولوژی شبکه ، پیکربندی سیستم و دستگاه های شبکه ای گردد . یک مهاجم می تواند در ادامه با استفاده از اطلاعات جمع آوری شده بر روی نقاط آسیب پذیر متمرکز و از حفره های امنیتی موجود در جهت تامین خواسته های مخرب خود استفاده نماید .

نقاط آسیب پذیر
متداولترین نقاط آسیب پذیری که شبکه را مستعد این نوع از حملات می نماید عبارتند از :

• ماهیت غیرایمن ذاتی پروتکل TCP/IP
• پیکربندی ضعیف دستگاه های شبکه ای
• استفاده غیرایمن از سرویس هائی که به وجود آنها در یک شبکه نیاز نمی باشد .

حملات
متداولترین حملات مبتنی بر "جمع آوری اطلاعات"  عبارتند از :

• استفاده از Tracert به منظور تشخیص توپولوژی شبکه
• استفاده از Telnet به منظور باز نمودن پورت ها و جمع آوری اطلاعات اولیه 
• استفاده از پویشگرهای پورت به منظور تشخیص وضعیت پورت ها 

• استفاده از درخواست های broadcast برای شمارش تعداد host موجود بر روی یک subnet

پیشگیری و مقابله با تهدیدات 
به منظور پیشگیری و مقابله با این نوع حملات می توان از روش های زیر استفاده نمود :

• استفاده از امکاناتی که اطلاعات اضافه ای را در خصوص پیکربندی نظیر نام و شماره نسخه نرم افزار ارائه نمی نماید .
• استفاده از فایروال ها به منظور پوشش سرویس هائی که نمی بایست در معرض دید و استفاده عموم قرار داده شوند .

sniffing
sniffing که به آن "استراق سمع "  نیز گفته می شود ، مانیتورینگ ترافیک شبکه برای داده هائی نظیر رمزهای عبور ( رمزنشده) و یا اطلاعات پیکربندی است . با استفاده از یک برنامه  packet sniffer  ، می توان به سادگی تمامی ترافیک plain text  ( رمز نشده ) را مشاهده نمود .

نقاط آسیب پذیر
متداولترین نقاط آسیب پذیری که شبکه را مستعد این نوع از حملات می نماید عبارتند از :

• ضعف امنیت فیزیکی
• ضعف رمزنگاری در زمان ارسال داده حساس  و مهم
• وجود سرویس هائی که با یکدیگر به صورت متن معمولی ( رمز نشده ) ارتباط برقرار می نمایند .
• استفاده از الگوریتم های ضعیف رمزنگاری

حملات
مهاجمان با قرار دادن یک  packet sniffer  بر روی شبکه می توانند تمامی ترافیک را capture و  آنالیز نمایند .

پیشگیری و مقابله با تهدیدات 
به منظور پیشگیری و مقابله با این نوع حملات می توان از روش های زیر استفاده نمود :

• استفاده از یک سیستم امنیت فیزیکی مناسب به منظور پیشگیری از نصب دستگاه های مخرب بر روی شبکه
• رمزنگاری اطلاعات حساس و ترافیک برنامه بر روی شبکه 

Spoofing
spoofing ، که به آن "هویت مبهم "  نیز گفته می شود  ، به کتمان هویت واقعی بر روی شبکه اطلاق می گردد . در این رابطه از یک آدرس مبداء جعلی که بیانگر آدرس اولیه صادرکننده پیام نمی باشد ، استفاده می گردد . در بسیاری موارد از spoofing به منظور مخفی کردن منبع بروز یک تهاجم استفاده می شود. در برخی موارد که دستیابی به منابع موجود بر روی شبکه بر اساس آدرس متقاضیان انجام می شود ، مهاجمان با تغییر آدرس مبداء سعی می نمایند به اینگونه از منابع دستیابی پیدا نمایند .

نقاط آسیب پذیر
متداولترین نقاط آسیب پذیری که شبکه را مستعد این نوع از حملات می نماید عبارتند از :

• ماهیت غیرایمن ذاتی پروتکل TCP/IP

• ضعف در فیلترینگ بسته های اطلاعاتی ورودی و خروجی : ترافیک ورودی و خروجی شبکه به درستی کنترل و فیلتر نمی گردد (ingress & egress filtering )

 حملات
یک مهاجم می تواند از ابزارهای متعددی به منظور تغییر آدرس بسته های خروجی استفاده نماید تا اینچنین وانمود نماید که آنها از یک host و یا شبکه دیگر ارسال شده اند .

پیشگیری و مقابله با تهدیدات 
به منظور پیشگیری و مقابله با این نوع حملات می توان از از فیلترینگ egress و ingress بر روی روتر های perimeter استفاده نمود .

session Hijacking
با استفاده از این نوع حملات که به آنها man in middle نیز گفته می شود ، مهاجمان می توانند از یک برنامه برای تغییر شکل ظاهری خود  به عنوان یک سرویس گیرنده و یا سرویس دهنده موجه استفاده نمایند . بدین ترتیب ، یک سرویس دهنده و یا سرویس گیرنده واقعی فریب خورده و فکر می کنند که با یک host معتبر و مجاز ارتباط برقرار نموده اند . در واقع ، این نوع کامپیوترهای میزبان متعلق به مهاجمان بوده که سعی می نمایند با دستکاری شبکه خود را به عنوان مقصد مورد نظر وانمود نمایند . از این نوع حملات به منظور آگاهی از اطلاعات logon و دستیابی به سیستم و سایر اطلاعات محرمانه استفاده می گردد .

نقاط آسیب پذیر
متداولترین نقاط آسیب پذیری که شبکه را مستعد این نوع از حملات می نماید عبارتند از :

• ضعف در امنیت فیزیکی
• ماهیت غیرایمن ذاتی پروتکل TCP/IP
• مبادله اطلاعات به صورت رمزنشده

 حملات
یک مهاجم می تواند از ابزارهای متعددی به منظور انجام عملیات spoofing ، تغییر روتینگ و دستکاری بسته های اطلاعاتی استفاده نماید. 

پیشگیری و مقابله با تهدیدات 
به منظور پیشگیری و مقابله با این نوع حملات می توان از روش های زیر استفاده نمود :

• رمزنگاری Session
• استفاده از روش Stateful inspection در سطح فایروال

DoS
در این نوع از حملات ، امکان دستیابی کاربران مجاز به یک سرویس دهنده و یا سرویس خاص سلب می گردد .در حملات DoS لایه شبکه ، معمولا" مهاجمان با ارسال سیلابی از بسته های اطلاعاتی امکان استفاده از یک سرویس توسط سایر کاربران را سلب می نمایند . علاوه بر مشکل فوق ، در چنین مواردی از پهنای باند و منابع موجود بر روی شبکه استفاده بهینه نخواهد شد .  

نقاط آسیب پذیر
متداولترین نقاط آسیب پذیری که شبکه را مستعد این نوع از حملات می نماید عبارتند از :

• ماهیت غیرایمن ذاتی پروتکل TCP/IP
• ضعف در پیکربندی روتر و سوئیچ
• باگ در سرویسهای نرم افزاری

 حملات
متداولترین حملات DoS عبارتند از :

• ارسال سیلابی از بسته های اطلاعاتی نظیر حملات cascading broadcast
• بسته های اطلاعاتی SYN flood
• سوء استفاده از برخی سرویس ها 

پیشگیری و مقابله با تهدیدات 
به منظور پیشگیری و مقابله با این نوع حملات می توان از روش های زیر استفاده نمود : 

• فیلترینگ درخواست های broadcast
• فیلترینگ درخواست های ICMP ( برگرفته از  Internet Control Message Protocol )
• بهنگام سازی و نصب patches سرویس های نرم افزاری

بدون آنالیز صحیح تهدیدات ،  امکان ایجاد یک محیط و یا شبکه ایمن وجود نخواهد داشت .

برای ایمن سازی شبکه از کجا می بایست شروع کرد ؟
برای ایمن سازی شبکه می بایست بر روی هر یک از دستگاه های استفاده شده در شبکه متمرکز و پس از بررسی چالش های امنیتی هر یک ، از راهکارهای خاصی به منظور ایمن سازی آنها استفاده نمود.
همانگونه که اشاره گردید در زیرساخت شبکه از  روتر ، فایروال و سوئیچ استفاده می گردد که می بایست ضمن آشنائی با جایگاه آنها در یک شبکه با نحوه عملکرد و ایمن سازی آنها از منظر برنامه های وب نیز آشنا شویم . در بخش سوم به بررسی موارد فوق خواهیم پرداخت . 

اصول امنیت برنامه های وب ( بخش اول )

اینترنت و به دنبال آن وب ، دنیای نرم افزار را دستخوش تحولات فراوانی نموده است . ظهور نسل جدیدی از برنامه های کامپیوتری موسوم به "برنامه های وب " از جمله این تحولات عظیم است . پس از ارائه سرویس وب در سال 1991، وب سایت های متعددی ایجاد گردید .  اینگونه سایت ها به منظور ارائه اطلاعات به مخاطبان خود از صفحات وب ایستا استفاده می کردند . در چنین وب سایت هائی ، امکان تعامل کاربر با برنامه وجود نداشت .
با توجه به این که رویکرد فوق با ماهیت و یا روح  نرم افزار چندان سازگار نمی باشد ، تلاش های گسترده ای در جهت ایجاد محتویات پویا انجام و متعاقب آن ، فن آوری های متعددی ایجاد گردید . به عنوان نمونه ، با پیاده سازی فن آوری CGI ( برگرفته از Common Gateway Interface  ) ، امکان استفاده از برنامه های خارجی به منظور تولید محتویات پویا فراهم گردید . بدین ترتیب ، کاربران قادر به درج اطلاعات و ارسال آنها برای یک برنامه خارجی و یا اسکریپت سمت سرویس دهنده شدند . برنامه موجود در سمت سرویس دهنده پس از دریافت اطلاعات و انجام پردازش های تعریف شده ، نتایج را تولید و آنها را برای کاربر ارسال می نمود .
رویکرد فوق ،‌ به عنوان نقطه عطفی در برنامه های وب تلقی می گردد چراکه برای اولین مرتبه امکان تولید محتویات پویا در وب سایت ها فراهم گردید . از آن زمان تاکنون فن آوری های متعددی به منظور تولید برنامه های وب ایجاد شده است .  PHP و ASP.NET نمونه هائی در این زمینه می باشند .  صرفنظر از این که از کدام فن آوری به منظور ایجاد برنامه های وب استفاده می گردد ، ایمن سازی آنان از جمله اهداف مشترک تمامی پیاده کنندگان است .

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

امنیت برنامه های وب را می بایست با توجه به نوع معماری و رفتار آنان بررسی نمود .

برداشت های غیرواقعی از امنیت برنامه های وب
متاسفانه به دلیل عدم شناخت لازم در خصوص ماهیت برنامه های وب از یک طرف و از سوی دیگر عدم آشنائی لازم با مفاهیم امنیت  ،‌ شاهد برداشت های نادرست در خصوص امنیت برنامه های وب می باشیم . اجازه دهید به چند نمونه در این خصوص اشاره نمائیم :

• ما ایمن هستیم چون از یک فایروال استفاده می نمائیم . این تصور کاملا" اشتباه است و به نوع تهدید بستگی خواهد داشت . مثلا" یک فایروال قادر به تشخیص داده ورودی مخرب جهت ارسال به یک برنامه وب نمی باشد .  فایروال ها دارای عملکردی قابل قبول در رابطه با اعمال محدودیت بر روی پورت ها می باشند  و برخی از آنان می توانند همزمان با بررسی اطلاعات مبادله شده ،‌ امکانات برجسته حفاظتی را ارائه نمایند . فایروال ها جزء لاینفک در یک فریمورک امنیتی می باشند ولی نمی توان آنان را به عنوان یک راهکار جامع به منظور ایجاد و برپائی یک محیط ایمن در نظر گرفت .

• ما ایمن هستیم چون از  SSL ( برگرفته ازSecure Sokets Layer ) استفاده می نمائیم .  SSL برای رمزنگاری ترافیک موجود بر روی شبکه یک گزینه ایده آل است ولی قادر به بررسی داده ورودی یک برنامه نمی باشد .

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

با رد امنیت یک سیستم عامل نمی توان امنیت یک سیستم عامل دیگر را تائید نمود.  ( من خوبم چون شما بد هستید ! )

امنیت چیست ؟
اولین رسالت امنیت ، حفاظت از سرمایه های یک سازمان است که ممکن است شامل آیتم های ملموسی نظیر یک صفحه وب و یا بانک اطلاعاتی مشتریان و یا آیتم های غیرملموسی نظیر شهرت و اعتبار یک سازمان باشد. امنیت یک مسیر است نه یک مقصد و به موازات تجزیه و تحلیل زیرساخت و برنامه های موجود ، می بایست اقدام به شناسائی تهدیدات و خطرات ناشی از آنان نمود . در واقع ، امنیت به مدیریت خطرات و پیاده سازی یک سیستم به منظور پاسخگوئی و مقابله با تهدیدات اشاره داشته و در ارتباط با عتاصر کلیدی زیر است :

• Authentication ،  فرآیندی است که به کمک آن به صورت منحصربفرد سرویس گیرندگان یک برنامه شناسائی می گردند . کاربران ،  سرویس ها ، فرآیندها و کامپیوترها ،  نمونه هائی از سرویس گیرندگان یک برنامه می باشند . در واقع ، authentication هویت استفاده کنندگان یک برنامه را بررسی می نماید .

• Authorization ، فرآیندی است که به کمک آن دستیابی سرویس گیرندگان تائید شده به منابع و عملیاتی که قصد انجام آن را دارند بررسی و مجوز لازم صادر می گردد. فایل ها ، بانک های اطلاعاتی ، جداول ، سطرها ، منابع موجود در سطح سیستم نظیر کلیدهای ریجتسری و داده پیکربندی ، نمونه هائی از منابع مورد درخواست سرویس گیرندگان می باشند . انجام تراکنش هائی خاص نظیر خرید یک محصول ، واریز و انتقال پول از یک حساب به حساب دیگر و یا افزایش اعتبار یک کارت اعتباری از جمله عملیاتی می باشند که می بایست مجوز استفاده از آنان برای سرویس گیرندگان صادر گردد . در واقع ، authorization محدوده مجاز عملیاتی را که یک سرویس گیرنده می تواند انجام دهد را مشخص می نماید .

• Auditing :  ممیزی موثر و ثبت عملیات انجام شده یکی از اصول مهم در جلوگیری از انجام اعمال خلاف قانون است . بدین ترتیب این اطمینان ایجاد خواهد شد که یک کاربر نمی تواند باعث عدم انحام یک کار و یا فعالیت در سیستم گردد و یا یک تراکنش را مقداردهی اولیه نماید . مثلا" در یک سیستم e-commerce  می بایست از مکانیزم هائی استفاده گردد تا این اطمینان حاصل گردد که یک مصرف کننده نمی تواند سفارش انجام شده برای خرید یکصد نسخه از یک کتاب را انکار نماید .

• Confidentiality ، که از آن با نام privacy نیز نام برده می شود ، فرآیندی است که به کمک آن این اطمینان ایجاد می گردد که حریم خصوصی داده رعایت و امکان مشاهده آن توسط کاربران غیرمجاز و یا سایر افرادی که  قادر به ردیابی ترافیک یک شبکه می باشند ، وجود نخواهد داشت . 

•  Integrity ، فرآیندی است که به کمک آن این اطمینان ایجاد می گردد که داده در مقابل تغییرات تصادفی و یا تعمدی حفاظت خواهد شد . همانند privacy ، یکپارچگی اطلاعات یک فاکتور اساسی در خصوص امنیت داده محسوب می گردد ، خصوصا" در مواردی که داده در طول شبکه مبادله خواهد شد . یکپارچگی داده در حال حمل ،‌عموما" با استفاده از روش هائی نظیر hashing و یا کدهای تائید پیام انجام می شود .

• Availability ، فرآیندی است که به کمک آن این اطمینان ایجاد خواهد شد که همواره داده برای کاربران مجاز در دسترس و قابل استفاده خواهد بود . در اغلب حملات از نوع DoS ، مهاجمان این هدف را دنبال می نمایند که بتوانند امکان استفاده و در دسترس بودن برنامه برای کاربران مجاز را غیرممکن و عملا" آن را از کار بیندازند .

تعاریف اولیه برخی از  اصطلاحات امنیتی : تهدیدات ، نقاط آسیب پذیر و حملات

• تهدید ( threat ) : به هرگونه پتانسیل بروز یک رویداد مخرب و یا سایر موارد دیگر که می تواند به سرمایه های یک سازمان آسیب برساند ، تهدید  گفته می شود . به عبارت دیگر، هر رویدادی که بتواند به سرمایه های یک سازمان آسیب برساند ، در زمره تهدیدات محسوب می گردد . 

• نقاط آسیب پذیر (vulnerability) : ضعف های موجود در یک سیستم می باشند که پتانسیل اولیه بروز یک رویداد مخرب را فراهم می نمایند . ضعف در طراحی ، پیکربندی اشتباه ، استفاده از روش های کدینگ غیرایمن مهمترین دلایل ایجاد یک ضعف در سیستم می باشند . ضعف در بررسی صحت داده ورودی توسط کاربر ، نمونه ای از یک لایه آسیب پذیر در یک برنامه است که می تواند زمینه بروز یک تهاجم را فراهم نماید .

• تهاجم (attack) : عملیاتی است که محوریت آن سوء استفاده از نقاط آسیب پذیر و پتانسیل های بروز یک رویداد مخرب می باشد .  ارسال ورودی مخرب به یک برنامه و یا flooding یک شبکه به منظور از کار انداختن یک سرویس ، نمونه هائی در این زمینه می باشد .

یک تهدید پتانسیل بروز یک رویداد مخرب را فراهم می نماید که می تواند به سرمایه های یک سازمان آسیب برساند  در حالی که در یک تهاجم موفقیت آمیز از نقاط آسیب پذیر موجود در سیستم استفاده می گردد .

چگونه می توان یک برنامه وب ایمن را ایجاد نمود ؟
تا زمانی که شناخت مناسبی نسبت به تهدیدات وجود نداشته باشد ، امکان ایجاد یک برنامه وب ایمن وجود نخواهد داشت . بنابراین قبل از هر چیز لازم است که با "مدل تهدیدات " موجود آشنا شویم . هدف مدل فوق، آنالیز معماری و نحوه طراحی برنامه به منظور شناسائی نقاط آسیب پذیری است که ممکن است به صورت تصادفی توسط یک کاربر ناآگاه و یا مهاجمان با اهداف مخرب مورد سوء استفاده قرار گرفته تا با استناد به آنان بتوانند موجودیت و امنیت  سیستم را با خطر مواجه نمایند  .
پس از آسنائی با تهدیدات ، می بایست با بکارگیری مجموعه ای از اصول امنیتی اقدام به طراحی سیستم نمود . در ادامه ، پیاده کنندگان می بایست از روش های ایمن به منظور نوشتن کدهای مطمئن ، مستحکم و قابل اعتماد استفاده نمایند . پس از طراحی و پیاده سازی برنامه ، می بایست از یک شبکه ایمن ، یک host مطمئن و یک پیکربندی مناسب بر روی سرویس دهنده ،‌ استفاده گردد .
ایجاد یک برنامه وب ایمن ، مستلزم اقدامات امنیتی چند جانبه ای است  که موفقیت در تمامی آنان ، ایمن بودن برنامه های‌ وب را تضمین خواهد کرد . ایمن سازی شبکه ، host و برنامه ، رئوس مثلث امنیتی ایجاد برنامه های وب ایمن را تشکیل می دهند .

ایمن سازی شبکه ، host و برنامه
به منظور  ایجاد برنامه های وب ایمن ، تبعیت از یک رویکرد جامع امری است الزامی . بنابراین ، می بایست امنیت برنامه های‌ وب را در سه لایه متفاوت بررسی و اقدامات لازم را در هر لایه با توجه به جایگاه آن انجام داد . شکل زیر سه لایه مهم به منظور ایجاد برنامه های وب ایمن را نشان می دهد .

وجود یک نقطه آسیب پذیر در شبکه به یک مهاجم اجازه می دهد تا کنترل یک host  و یا برنامه را بدست بگیرد . وجود یک نقطه آسیب پذیر در host  به یک مهاجم اجازه می دهد تا بتواند کنترل یک شبکه و یا برنامه را بدست بگیرد . وجود یک نقطه آسیب پذیر در برنامه به یک مهاجم اجازه می دهد تا کنترل یک host  و یا شبکه را بدست بگیرد .

 در بخش دوم به بررسی هر یک از لایه های فوق خواهیم پرداخت .

روش های حفاظت از داده

به اعتقاد بسیاری از کارشناسان ، مهمترین و یا بهتر بگوئیم با ارزش ترین چیز بر روی یک کامپیوتر ، داده ایجاد شده توسط کاربر است و شاید وجود همین اطلاعات است که ضرورت استفاده از کامپیوتر و یا شبکه را توجیه می نماید . سیستم های عامل و نرم افزارها را در بسیاری از موارد و همزمان با بروز مشکل در سیستم ، می توان مجددا" نصب نمود ولی داده ایجاد شده توسط کاربر در نوع خود منحصربفرد بوده و در صورت از دست دادن ، امکان استفاده مجدد از آنها با مشکل اساسی مواجه و در  برخی موارد عملا" غیرممکن خواهد بود.
برخی از داده های ذخیره شده بر روی کامپیوتر ممکن است دارای اهمیت بیشتری نسبت به سایر اطلاعات باشند و ضمن این که هرگز علاقه مند به از دست دادن آنها نمی باشیم ، نمی بایست امکان استفاده از آنها توسط کاربران غیرمجاز نیز وجود داشته باشد . دستیابی به برخی از داده های مهم نظیر شماره کارت اعتباری و یا حساب بانکی می تواند در نهایت منجر به سرقت هویت کاربران گردد . مسائل اشاره شده ، صرفا" محدود به کاربران شخصی نبوده و سازمان ها و موسسات را نیز شامل می شود . هر سازمان دارای داده های مهم و حساسی است که از دست دادن آنها می تواند خسارات جبران ناپذیری را برای یک سازمان به دنبال داشته باشد .
برای حفاظت از اطلاعات می بایست از یک استراتژی خاص تبعیت نمود که ضمن کاهش احتمال از دست دادن داده ها ،‌ امکان استفاده از آنها توسط افراد غیرمجاز نیز وجود نداشته باشد .
در ادامه به برخی از متداولترین روش های حفاظت از اطلاعات اشاره می گردد :  

• تهیه Backup در اولین فرصت و به صورت مرتب : تهیه backup  بطور مرتب و بر اساس یک استراتژی خاص ، یکی از اقدامات اساسی در جهت حفاظت از اطلاعات می باشد . اطلاعاتی که ممکن است به هر دلیلی با مشکل مواجه و امکان استفاده از آنان وجود نداشته باشد .  برای تهیه backup ، می توان از امکانات موجود در ویندوز نظیر برنامه ntbackup استفاده نمود . با استفاده از ویزارد ارائه شده در برنامه فوق ،  می توان به سرعت و به سادگی عملیات لازم به منظور تهیه backup و یا برگرداندن اطلاعات backup گرفته شده را انجام داد . در صورت ضرورت ، می توان تهیه backup از داده های مهم موجود بر روی سیستم را به صورت یک job تعریف و برای آن یک برنامه زمانبندی خاص را در نظر گرفت .
  برای تهیه backup ، می توان از نرم افزارهای متعدد دیگری نیز استفاده نمود که امکانات بمراتب بیشتری را در مقایسه با برنامه ارائه شده در ویندوز در اختیار کاربران قرار می دهند . صرفنظر از این که از چه برنامه ای برای تهیه backup استفاده می گردد ، می بایست از اطلاعات backup گرفته شده به دقت حفاظت و آنها را در مکان هائی با ضریب ایمنی و حفاظتی بالا نگهداری کرد . 

• استفاده از مجوزهای امنیتی file-level و share-level  : به منظور حفاظت از داده در مقابل دستیابی افراد غیرمجاز ، اولین مرحله تنظیم مجوزها بر روی فایل ها و فولدرهای حاوی داده می باشد .در صورتی که می بایست داده به صورت مشترک در شبکه استفاده گردد ، می توان با تنظیم share permissions  نحوه استفاده از آنها را قانونمند نمود . بدین منظور می توان در ویندوز 2000 و یا XP  پس از انتخاب فایل و یا فولدر ، از طریق صفحه Properties گزینه Sharing و در نهایت دکمه  permission  را انتخاب نمود . تنظیمات امنیتی اشاره شده در رابطه با کاربرانی که به صورت محلی از سیستم حاوی اطلاعات حساس استفاده می نمایند ، اعمال نخواهد شد .
  در صورتی که کامپیوتر با کاربر دیگری به اشتراک گذاشته شده است ، می بایست از مجوزهای file-level استفاده نمود . به این نوع از مجوزها ، مجوزهای     NTFS  نیز گفته می شود چراکه استفاده از آنها صرفا" برای فایل ها و فولدرهای ذخیره شده بر روی پارتیشن هائی که با سیستم فایل NTFS فرمت شده اند ، امکان پذیر می باشد . برای استفاده از مجوزهای فوق ، پس از انتخاب فایل و یا فولدر مورد نظر می توان از طریق صفحه properties ، گزینه Security tab را انتخاب و مجوزها را بر اساس سیاست مورد نظر تنظیم نمود . 
  در هر دو مورد ( مجوزهای file-level و share-level ) می توان مجوزها را برای user account و groups تعریف نمود . مجوزها را می توان از  "فقط خواندنی" تا " کنترل کامل " در نظر گرفت .

• حفاظت از فایل ها و سایر مستندات توسط رمز عبور : تعداد زیادی از نرم افزارها ( نظیر نرم افزارهای آفیس و Adobe Acrobat ) ، امکان تعریف رمزعبور برای استفاده از مستندات را در اختیار کاربران قرار می دهند . پس از در نظر گرفتن یک رمز عبور ، در صورت فعال کردن ( بازنمودن ) یک مستند در ابتدا از کاربر درخواست رمز عبور خواهد شد . به منظور انجام این کار در برنامه ای نظیر Microsoft word 2003 ، از طریق منوی Tools گزینه options  و در ادامه Security tab را انتخاب می نمائیم . با استفاده از امکانات فوق ، می توان یک رمز عبور و نحوه رمزنگاری را مشخص نمود .
  متاسفانه، سیستم رمز استفاده شده در محصولات مایکروسافت ، به سادگی شکسته می گردد و کاربران غیرمجاز می توانند از برنامه های متعددی به منظور رمزگشائی مستندات استفاده نمایند. برنامه AOPR  ( برگرفته از Advanced Office Password Recovery  )  نمونه ای در این زمینه می باشد .
  در صورت لزوم می توان از  نرم افزارهائی نظیر WinZip و PKZip به منظور فشرده سازی و رمزنگاری اسناد و یا فایل ها استفاده نمود .

• استفاده از رمزنگاری EFS : ویندوز 2000 ، XP و 2003 از رمزنگاری سیستم فایل موسوم به EFS ( برگرفته از Encrypting File System ) حمایت می نمایند . از سیستم رمزنگاری فوق می توان به منظور رمزنگاری فایل ها و فولدرهای ذخیره شده بر روی پارتیشنی که با NTFS فرمت شده است ،‌استفاده نمود . بدین منظور می توان پس از انتخاب صفحه properties ، از طریق General tab گزینه Advanced button را انتخاب نمود ( بطور همزمان نمی توان از رمزنگاری EFS و مجوزهای NTFS استفاده نمود ) .
  سیستم رمزنگاری EFS به منظور افزایش امنیت و کارآئی از ترکیب رمزنگاری متقارن و نامتقارن استفاده می نماید . سیستم فوق برای حفاظت از داده های ذخیره شده بر روی دیسک استفاده می گردد و در صورتی که یک فایل رمز شده در طول شبکه حرکت کند و کاربران از یک sniffer به منظور capture بسته های اطلاعاتی استفاده نمایند ، می توانند اطلاعات موجود در فایل را مشاهده نمایند .

• استفاده از رمزنگاری ‌دیسک : با استفاده از نرم افزارهای متعددی می توان تمامی محتویات یک دیسک را رمز نمود . بدین ترتیب ، کاربران غیرمجاز قادر به  مشاهده محتویات ذخیره شده بر روی دیسک نخواهند بود .  داده بطور اتومانیک و در زمان نوشتن بر روی هارد دیسک رمز  و قبل از استقرار درون حافظه ، رمزگشائی می گردد . از اینگونه محصولات می توان به منظور رمزنگاری درایوهای USB ، فلش درایوها و ... استفاده نمود . PGP Whole Disk Encryption و DriveCrypt نمونه هائی از اینگونه برنامه ها می باشند .

• استفاده از زیرساخت کلید عمومی :  PKI ( برگرفته از public key infrastructure ) ، سیستمی برای مدیریت زوج کلید خصوصی و عمومی و گواهینامه های دیجیتال است . با توجه به این که کلید ها و گواهینامه ها توسط یک مرکز تائید شده  صادر می شوند از استحکام امنیتی بیشتری برخوردار می باشند . (سرویس دهندگان گواهینامه دیجیتال ممکن است به صورت داخلی و در یک شبکه خصوصی نصب و یا در یک شبکه عمومی ، نظیر Versign  ، نصب شده باشند ) . در چنین مواردی ، می توان داده را با استفاده از کلید عمومی کاربر مورد نظر رمز نمود . در ادامه، صرفا" کاربری قادر به رمزگشائی اطلاعات است که دارای کلید خصوصی مرتبط با کلید عمومی باشد .

• مخفی کردن داده درون داده دیگر : با استفاده از یک برنامه  steganography می توان داده مورد نظر را درون سایر داده ها مخفی نمود . به عنوان نمونه ، می توان یک پیام متن را درون یک فایل گرافیکی JPG . و یا فایل موزیک mp3 . ، مخفی نمود . اینگونه ها برنامه ها پیام ها را رمز نمی نمایند و  اغلب از آنان به همراه نرم افزارهای رمزنگاری استفاده می گردد . در چنین مواردی ، در ابتدا داده رمز و در ادامه با استفاده از نرم افزارهای  steganography مخفی می گردد . برنامه StegoMagic  یک نمونه از برنامه های  steganography  است که با استفاده از آن می توان متن مورد نظر را رمز و درون فایل هائی از نوع WAV ، . TXT . و یا BMP . ذخیره نمود .

• حفاظت داده در حال حمل : داده ارسالی در یک شبکه می تواند در زمان حرکت توسط مهاجمان شنود گردد . مهاجمان در این رابطه از نرم افزارهائی موسوم به sniffer استفاده می نمایند که امکان آنالیز پروتکل و یا مانیتورینگ شبکه را در اختیار آنان قرار می دهد. برای حفاظت داده در زمان حرکت در شبکه ، می توان از IPSec ( برگرفته از Internet Protocol Security ) استفاده نمود . در چنین مواردی ، سیستم ارسال کننده و سیستم دریافت کننده می بایست قادر به حمایت از ویژگی فوق باشند . از ویندوز 2000 به بعد ، امکانات لازم به منظور حمایت از IPSec  در سایر نسخه ها تعبیه شده است .  

• ایمن سازی مبادله داده در محیط های wireless : داده ئی که از طریق یک شبکه wireless ارسال می گردد ، دارای استعداد بیشتری به منظور بررسی و شنود توسط مهاجمان نسبت به سایر داده های ارسال شده بر روی‌ یک شبکه اترنت است ،‌ چراکه  ضرورتی ندارد مهاجمان به محیط فیزیکی شبکه و یا دستگاه های مربوطه دستیابی داشته باشند . در صورت عدم پیکربندی صحیح و ایمن access point ، مهاجمان با استفاده از یک کامپیوتر قابل حمل که دارای امکانات wireless است ، می توانند به داده ذخیره شده در شبکه دستیابی داشته باشد .  کاربران می بایست صرفا" اقدام به ارسال و دریافت داده بر روی شبکه هائی نمایند که از رمزنگاری WPA ( برگرفته از Wi-Fi Protected Access ) در مقابل WEP ( برگرفته از Wired Equivalent Protocol ) استفاده می نمایند ( WPA  ، بمرابت دارای امنیت بیشتری نسبت به WEP است ) . 

• استفاده از مدیریت حقوق به منظور حفظ کنترل  : در برخی موارد ، لازم است که داده برای سایر کاربران ارسال گردد ولی نگران نحوه برخورد آنان با داده ارسالی می باشیم ( مثلا" آیا آنان می توانند داده ارسالی را حذف و یا تغییر دهند ) . در چنین مواردی می توان از RMS ( برگرفته از Rights Management Services ) در ویندوز استفاده نمود . سیستم فوق ، مشخص می نماید که دریافت کننده پس از دریافت اطلاعات قادر به انجام چه کاری خواهد بود . به عنوان نمونه ، می توان حقوق مورد نظر را بگونه ای تنظیم نمود که صرفا" دریافت کننده قادر به مطالعه فایل ارسالی باشد و نتواند در آن تغییراتی را اعمال نماید .  همچنین ، با استفاده از سیستم فوق می توان مدت زمان استفاده از  مستندات و یا پیام ها را مشخص نمود . بدین ترتیب پس از گذشت مدت زمان مشخص شده ، اعتبار آنها به اتمام رسیده و عملا" امکان دستیابی  و استفاده از آنها وجود نخواهد داشت . 
  برای استفاده از RMS ، به ویندوز 2003 که به عنوان یک سرویس دهنده RMS پیکربندی شده است نیاز می باشد . در چنین مواردی ، کاربران نیز به یک نرم افزار خاص و یا یک add-in همراه مرورگر نیاز خواهند داشت تا بتوانند به مستندات حفاظت شده توسط RMS دستیابی داشته باشند . کاربران مجاز یک گواهینامه را از سرویس دهنده RMS دریافت می نمایند .
   

ماهیت و نحوه پیکربندی دستگاه های شبکه ای

ماهیت و نحوه پیکربندی دستگاه های شبکه ای
استفاده از فن آوری های متعدد و درعین حال پویا در طراحی ، پیاده سازی و نگهداری شبکه های کامپیوتری ، ضرورت ارتقاء مستمر دانش برای علاقه مندان فعالیت در این عرصه را به یک باید تبدیل کرده است . صرفنظر از میزان اطلاعات شما در خصوص شبکه های کامپیوتری، همواره لازم است که با یک دید جدید به بازنگری اندوخته های خود پرداخته  تا از این رهگذر یک ساختار مناسب علمی  در جهت مدیریت و اشکال زدائی بهینه شبکه در ذهن ایجاد گردد .
علاقه مندان فعالیت در عرصه مدیریت شبکه های کامپیوتری ، می بایست دارای اطلاعات مناسبی در موارد متعددی نظیر تفاوت روتر با سوئیچ و اصول اولیه آدرس دهی IP باشند. علاوه بر این ، توجه دقیق به برخی از مفاهیم کلیدی در خصوص ماهیت و نحوه پیکربندی دستگاه های شبکه ای نیز حائز اهمیت است . در ادامه به بررسی مواردی خواهیم پرداخت که توجه به آنها، مسیر ما را برای حرکت منطقی و سریع به سمت جلو هموارتر می نماید. 

نکته اول : آگاهی از تفاوت بین پروتکل های routing و routed
 واژه routing  در شبکه های کامپیوتری به انتخاب مسیر جهت ارسال داده اطلاق می گردد. پروتکل های routing ، به آندسته از پروتکل هائی اطلاق می شود که مسئولیت توزیع اطلاعات روتینگ بین سایر روترهای موجود در یک شبکه را برعهده دارند. هر روتر می بایست نسبت به سایر شبکه هائی که به وی متصل شده اند آگاهی داشته باشد . پروتکل های زیر نمونه هائی از پروتکل های routing می باشند :

• OSPF ( برگرفته از  Open Shortest Path First   )

• RIP ( برگرفته از Routing Information Protocol  )

• EIGRP ( برگرفته از Enhanced Interior Gateway Routing Protocol  )

• BGP ( برگرفته از Border Gateway Protocol  )

هر پروتکل شبکه که اطلاعات لازم در سطح لایه شبکه را ارائه می نماید تا به کمک آن یک packet بتواند از یک میزبان به میزبان دیگر ( بر اساس یک مدل آدرس دهی ) ارسال گردد ، یک پروتکل routed محسوب می گردد . این نوع پروتکل ها فرمت یک packet را تعریف و از فیلدهای موجود در آن استفاده می نمایند . پروتکل IP یک نمونه از پروتکل های routed و  NetBEUI ( برگرفته از  NetBIOS Extended User Interface ) نمونه ای از یک پروتکل non-routable است .

نکته دوم : آشنائی با حالات متفاوت مدیریت روتر
بخش رابط کاربر IOS روترهای سیسکو به چندین حالت (mode ) متفاوت تقسیم می گردد . هر command mode ، امکان پیکربندی عناصر مختلفی را بر روی روتر فراهم می نماید . با توجه به موضوع فوق ، مدیران شبکه می بایست شناخت مناسبی نسبت به هر یک از سطوح مجاز روتر داشته باشند . به  عبارت دیگر ، آگاهی و شناخت مناسب نسبت به عملکرد هر command mode  و نحوه استفاده از پتانسیل های موجود، امکان پیکربندی بهینه روتر را فراهم می نماید. 

•  User Exec Mode :  پس از log in به یک روتر سیسکو ،  به صورت پیش فرض در این mode قرار خواهیم گرفت . در mode فوق ، عملیات زیادی را نمی توان انجام داد و صرفا" امکان دستیابی و مشاهده برخی اطلاعات وجود دارد . در این mode امکان تغییر پیکربندی روتر وجود ندارد . از دستور enable برای استقرار در Privileged EXEC Mode  استفاده می گردد .
   

•  Privileged Exec Mode : پس از استقرار در این mode با استفاده از مجموعه دستورات موجود می توان به مجموعه کاملی از اطلاعات دستیابی داشت . مثلا"  با استفاده از گونه های مختلف دستور ‌show می توان اطلاعات گسترده ای در خصوص وضعیت روتر و پیکربندی آن را مشاهده نمود . در این mode  نیز نمی توان  پیکربندی روتر را تعییر داد  و می بایست از سایر مدهای زیر مجموعه ( sub modes ) استفاده نمود . از دستور config terminal به منظور استقرار در Global Configuration Mode  استفاده می گردد .
   

•  Global Configuration Mode : با استفاده از امکانات موجود در این mode می توان پیکربندی روتر را تغییر داد . از دستور exit به منظور برگشت به Privileged Exec Mod استفاده می گردد .

نکته سوم :  شناخت مناسب نسبت به گونه های مختلف دستور show
دستور show ، از جمله دستورات مهم در IOS سیسکو است که از آن در موارد متعددی استفاده می گردد . با این که می بایست با تمامی قابلیت های این دستور آشنا گردید ولی استفاده از آن در برخی موارد دارای اهمیت بیشتری است  :  

• Show ip route : دستور فوق ، مسیرهای موجود بر روی روتر را نمایش می دهد ( اطلاعات موجود در جدول روتینگ IP ) . مسیرهای روتر می توانند به صورت ایستا و یا پویا تعریف گردند . در صورت عدم تعریف یک مسیر پیش فرض و یا عدم وجود مقصدی که ترافیک روتر می بایست به آن هدایت شود ، روتر ترافیک منتقل شده به خود را نادیده گرفته و از آن صرفنظر می نماید .
   

• show running-configuration : دستور فوق ، پیکربندی جاری روتر را نشان می دهد . در صورت اعمال هرگونه تغییرات در پیکربندی روتر ، می بایست با استفاده از دستور  copy run start آنان را ذخیره نمود .
   

• show ip interface brief : دستور فوق ، خلاصه ای از وضعیت جاری تمامی اینترفیس های موجود بر روی روتر را نمایش می دهد . از خروجی این دستور می توان به منظور تشخیص تعداد و نوع اینترفیس ها ،‌ آدرس و وضعیت آنان ( فعال بودن و یا غیرفعال بودن ) ، استفاده نمود. 

نکته چهارم : آگاهی از نحوه عملکرد آدرس های IP خصوصی و NAT با یکدیگر
بر اساس RFC 1918 ، آدرس های IP خصوصی قابل route بر روی شبکه اینترنت نمی باشند .از آدرس های فوق صرفا" در شبکه های داخلی استفاده می گردد و روترهای اینترنت ترافیک دریافتی از این نوع شبکه ها را دورخواهند انداخت .

10.0.0.0 /8 or 255.0.0.0 172.16.0.0 /12 or 255.240.0.0 192.168.0.0 /16 or 255.255.0.0

 اکثر شرکت ها و شبکه های موجود در منازل در حال حاضر از آدرس های IP خصوصی استفاده می نمایند .  شاید برای شما این سوال مطرح شده باشد که با توجه به این که روترها اینگونه آدرس ها را route نخواهند کرد ، نحوه مبادله اطلاعات از طریق کاربران اینگونه شبکه ها برروی اینترنت به چه صورت است ؟  در پاسخ می بایست به این موضوع اشاره نمود که در این نوع شبکه ها از NAT ( برگرفته از network address translation   ) استفاده می گردد .  NAT ، آدرس های IP خصوصی را به آدرس های IP عمومی تبدیل ( ترجمه ) می نماید .( در زمان ارسال و برگشت درخواست کاربران ) .

نکته پنجم : آگاهی از نحوه اشکال زدائی شبکه با استفاده از مدل OSI
اشکال زدائی شبکه از جمله وظایف مهم مدیران شبکه های کامپیوتری است که در صورت عدم تبعیت از یک رویکرد علمی به منظور برخورد با آن ، اتلاف منابع موجود خصوصا" زمان را به دنبال خواهد داشت . به منظور اشکال زدائی  شبکه از روش های متفاوتی استفاده می گردد . پیشنهاد می گردد که از لایه فیزیکی ( لایه اول) مدل OSI کار شروع شود و بتدریج به سمت لایه های دیگر حرکت گردد . رویکرد فوق ، یکی از سریعترین روش های اشکال زدائی در شبکه های کامپیوتری است . 

کنترل های Validation در ASP.NET ( بخش چهارم )

کنترل های Validation در ASP.NET ( بخش چهارم )
 آنچه تاکنون گفته شده است :

• بخش اول :  ماهیت و جایگاه کنترل های validation و بررسی عملکرد کنترل های <asp:RequiredFieldValidator> و <asp:RangeValidator> 
• بخش دوم : بررسی عملکرد کنترل های <asp:CompareValidator> و <asp:CustomValidator>
• بخش سوم : آشنائی با گروه های validation  و  بررسی عملکرد کنترل <asp:ValidationSummary>

در این بخش به  بررسی برخی نکات خاص در خصوص ایمن سازی برنامه های وب با تمرکز بر روی کنترل های Validation خواهیم پرداخت .  

تهدیدات امنیتی در صورت عدم ارزیابی داده ورودی
برنامه های وب ، داده مورد نیاز خود را از طریق درخواست های مبتنی بر پروتکل HTTP  دریافت می نمایند ( در برخی موارد ممکن است داده مورد نیاز یک برنامه وب  از طریق یک فایل تامین گردد). با توجه به ماهیت پروتکل فوق ، مهاجمان می توانند هر بخشی از یک درخواست HTTP  نظیر   url ، querystring ،  هدر ، کوکی ها ، فیلدهای موجود بر روی فرم و فیلدهای مخفی را تحریف تا ضمن نادیده گرفتن مکانیزم های امنیتی بکارگرفته شده در یک سایت ، آن را با مشکلات امنتیی متعددی مواجه نمایند. حملات forced browsing, command insertion, cross site scripting, buffer overflows, format string attacks و SQL injection نمونه هائی در این زمینه می باشند . 
تعداد زیادی از برنامه های وب صرفا" از مکانیزم های سمت سرویس گیرنده به منظور بررسی و ارزیابی داده ورودی استفاده می نمایند . مهاجمان با استفاده از روش های متفاوتی می توانند مکانیزم های استفاده شده به منظور ارزیابی داده ورودی را نادیده گرفته و برنامه های وب را در مقابل داده ورودی مخرب خلع سلاح نمایند . مهاجمان ، بدین منظور می توانند با استفاده از ابزارهائی نظیر telnet درخواست های HTTP را تولید نمایند . بدیهی است در چنین مواردی نباید انتظار داشت آنان واکنش هائی را که مد نظر پیاده کنندگان برنامه های وب در سمت سرویس گیرنده است ،‌ انجام دهند . با این که بررسی و ارزیابی داده ورودی در سمت سرویس گیرنده یک ایده عالی است و می تواند به عنوان یک اقدام مناسب در  جهت افزایش کارآئی برنامه های وب تلقی گردد ولی قطعا" رویکرد فوق دارای مزیت امنیتی خاصی نخواهد بود .
به منظور ارزیابی داده ورودی می بایست از روش های سمت سرویس دهنده استفاده گردد تا یک لایه دفاعی مناسب به منظور پیشگیری از درج داده مخرب توسط مهاجمان ایجاد گردد . پس از تحقق خواسته فوق ، می توان با دقت اقدام به بهینه سازی روش های استفاده شده به منظور بررسی و ارزیابی داده ورودی در سمت سرویس گیرنده نیز نمود تا ترافیک غیرضروری بر روی سرویس دهنده به حداقل مقدار ممکن برسد .

بررسی یک نمونه  
 در برخی موارد از داده ورودی در یک TextBox به منظور ایجاد یک query در ارتباط با یک بانک اطلاعاتی استفاده می گردد . روش فوق ، ممکن است مسائل و مشکلات امنیتی متعددی را به دنبال داشته باشد ( از عدم اجرای اسکریپت ها گرفته تا بروز اشکال در بانک اطلاعاتی ) . مجددا" لازم است به این نکته مهم اشاره گردد که کنترل های validation ، به منزله اولین لایه دفاعی در مقابل درج داده مخرب محسوب می گردند و این اطمینان را ایجاد می نمایند که صرفا" داده معتبر در اختیار سایر لایه های یک برنامه خصوصا" لایه داده آن قرار داده خواهد شد .
مهاجمان می توانند از طریق TextBox استفاده شده بر روی یک فرم ،‌ کدهای مخربی را به سیستم وارد نمایند که حذف تمامی بانک اطلاعاتی را به دنبال داشته باشد . با این که همواره فرض پیاده کنندگان برنامه های وب بر این است که از TextBox برای درج داده در سیستم استفاده خواهد شد ، ولی واقعیت این است که ممکن است از آنها برای درج کد نیز استفاده گردد . SQL injection یک نمونه از تهدیدات موجود در این زمینه است .

SQL Injection
فرض کنید از یک TextBox برای درج داده بر روی یک فرم استفاده شده باشد و پس از درج داده توسط کاربر ، از آن به منظور بازیابی رکوردهائی خاص از یک بانک اطلاعاتی استفاده می گردد . بدین منظور ، از دستور SELECT به صورت زیر استفاده شده است :

SQLString = "SELECT * FROM MyTable WHERE MyKey = '" & MyTextBox.Text & "'"

دستور SELECT ، به صورت پویا از مقدار درج شده در TextBox استفاده می نماید . ظاهرا" همه چیز درست است و مشکل خاصی وجود نخواهد داشت ولی فرض کنید  کاربری کد SQL زیر را در TextBox وارد نماید :

Search :

پس از درج داده فوق در TextBox  ، وضعیت query نوشته شده در  برنامه به صورت زیر خواهد بود :

SELECT * FROM MyTable WHERE MyKey = ' ' ; DROP DATABASE MyDatabase

در چنین مواردی ، عبارت SQL شامل دو دستور مجزاء می گردد که اولین دستور آن با توجه به ماهیت داده ورودی مقدار null خواهد بود و عملا" رکوردی را برنمی گرداند و دومین عبارت SQL ، باعث حذف یک بانک اطلاعاتی خواهد شد . بدین ترتیب یک SQL injection محقق می گردد و کد مخرب با داده مورد انتظار در عبارت SQL جایگزین می شود. با این که در یک بانک اطلاعاتی اکسس ، نمی توان چندین عبارت SQL را در یک خط استفاده نمود ولی برخی از سیستم های مدیریت بانک های اطلاعاتی قادر به اجراء کد فوق خواهند بود .
پیاده کنندگان برنامه های وب می توانند از کنترل های validation به منظور بلاک نمودن اینچنین کدهائی استفاده نمایند . بدین منظور می توان طول رشته ورودی ، نوع داده ورودی و یا وجود داده ورودی در یک محدوده خاص را بررسی نمود . تست های فوق در مواردی که داده ورودی از نوع string و با طول نامشخص باشند ، کارساز نبوده و نمی توان از کنترل های اشاره شده در جهت ایجاد یک سطح حفاظتی مناسب استفاده نمود . 

راه حل چیست ؟ 
بهترین روش برای حفاظت در مقابل ورود کدهای مخرب به سیستم ، استفاده از عبارات SQL به صورت پارامتریک در مقابل بکارگیری مستقیم داده ورودی است . پارامترها ، مکان لازم برای نگهداری مقادیر داده را فراهم نموده و این اطمینان را ایجاد می نمایند که از مقادیر ورودی مستقیما" در کد استفاده نخواهد شد . 
در کد زیر از یک عبارت SELECT به منظور بازیابی رکوردهائی خاص از جدول Books در بانک اطلاعاتی BooksDB استفاده شده است . عبارت SQL به عنوان خصلت SelectCommand کنترل منبع داده AccessDataSource ( با " id="BookSource ) در نظر گرفته شده است .

Sub Get_Record (Src As Object, Args As EventArgs)   Dim SQLString As String   SQLString = "SELECT BookID, BookTitle, BookPrice FROM Books" & _                      "WHERE BookID = @BookID"   BookSource.SelectCommand = SQLString End Sub

یک پارامتر با استفاده از نام خود که به دنبال یک کاراکتر "@" می آید ( در این مثال BookID @  ) ، مشخص می گردد و یک مرجع به داده ورودی است که در عبارت SELECT و به منظور بازیابی رکوردهای مورد نظر استفاده می گردد . فرض کنید ، کاربر داده زیر را در TextBox وارد نماید :

Book ID :

مقدار ورودی در TextBox ، به عنوان مقدار پارامتر BookID @   در عبارت SELECT در نظر گرفته می شود . در چنین مواردی ، می بایست با صراحت مقدار درج شده در TextBox را با پارامتر فوق مرتبط نمود . زمانی که از کنترل AccessDataSource به منظور بازیابی داده از یک بانک اطلاعاتی استفاده می گردد ، برای مشخص کردن پارامترهای مورد نیاز در یک عبارت SELECT ، می بایست از بخش <SelectParameters>   در کنترل استفاده گردد . در این بخش می توان از یک و یا چندین کنترل <asp:ControlParameter> استفاده نمود . با استفاده از کنترل <asp:ControlParameter> ، می بایست یک نام را برای پارامتر در نظر گرفت .همچنین ، لازم است کنترلی که قرار است مقدار آن به عنوان پارامتر در نظر گرفته شود نیز مشخص گردد.
کد زیر نحوه استفاده از پارامتر BookID @  در کنترل AccessDataSource را نشان می دهد .

Book ID:   <asp:TextBox id="BookIDInput" Runat="Server"/>   <asp:Button Text="Find" OnClick="Get_Record" Runat="Server"/>   <asp:AccessDataSource id="MySource" Runat="Server" DataFile="../DB/BooksDB.mdb">      <SelectParameters>          <asp:ControlParameter Name="BookID" ControlID="BookIDInput" PropertyName="Text"/>      </SelectParameters> </asp:AccessDataSource>

توضیحات :

• کنترل  <asp:ControlParameter>  از سه خصلت به منظور ایجاد ارتباط با کنترلی که داده مورد نیاز را تامین خواهد کرد ، استفاده می نماید .

• خصلت Name ، نام در نظر گرفته شده برای پارامتر را که از آن در عبارت SELECT استفاده خواهد شد را مشخص می نماید .

• خصلت ControlID ، شناسه (id ) کنترلی است که داده مورد نیاز برای پارامتر را مشخص می نماید .
   

• PropertyName ، خصلت کنترلی است که از مقدار آن به عنوان مرجع استفاده می گردد ( در این مثال خصلت Text مربوط به کنترل TextBox ) .
   

• در مثال فوق از یک پارامتر در عبارت SELECT استفاده شده است ، بنابراین به یک کنترل  <asp:ControlParameter> نیاز می باشد. در صورتی که لازم است از چندین پارامتر استفاده شود ، می بایست برای هر یک از آنها از یک کنترل <asp:ControlParameter> استفاده گردد .

سادگی کد نویسی
با پارامتر درج شده در یک عبارت SELECT به عنوان یک مقدار داده literal برخورد می شود . بنابراین ، بر خلاف زمانی که از رشته های متصل شده به هم به منظور بکارگیری یک عبارت SQL استفاده می گردد ، احتمال درج داده مخرب بطرز مشهودی کاهش خواهد یافت . استفاده از پارامتر در عبارات SQL ، کاهش پیچیدگی کدینگ عبارات SQL را نیز به دنبال خواهد داشت .
کد زیر یک نمونه عبارت SQL را نشان می دهد که در آن از یک رشته متصل شده به هم استفاده شده است :

SQLString = "SELECT * FROM Books WHERE " & _          "BookType = '" & TypeTextBox.Text & "' AND " & _          "BookPrice > " & PriceTextBox.Text & " AND " & _          "BookQty <= " & QtyTextBox.Text & " AND " & _          "BookTitle LIKE '%" & TitleTextBox.Text & "%'"

کد فوق را می توان با عبارت زیر جایگزین نمود :

SQLString = SELECT * FROM Books WHERE " & _         "BookType = @BookType AND BookPrice > @BookPrice AND " & _         "BookQty <= @BookQty AND BookTitle LIKE @BookQty"

درون کنترل AcessDataSource ، می بایست از یک بخش SelectParameters به منظور معرفی کنترل هائی که مقدار مورد نیاز هر یک از پارامترها را تامین می نمایند ، استفاده گردد .

کنترل های Validation در ASP.NET ( بخش سوم )

کنترل های Validation در ASP.NET ( بخش سوم )
در بخش اول به ماهیت و جایگاه کنترل های validation اشاره و عملکرد دو  کنترل <asp:RequiredFieldValidator> و <asp:RangeValidator> بررسی گردید.در بخش دوم  با کنترل های <asp:CompareValidator> و <asp:CustomValidator> آشنا شدیم . در این بخش به بررسی سایر کنترل های validation خواهیم پرداخت .

گروه های validation
در زمان پیاده سازی فرم های ورود اطلاعات به مواردی برخورد خواهیم کرد که لازم است از چندین TextBox به منظور دریافت داده ورودی جهت انجام پردازش های مورد نیاز در یک اسکریپت ، استفاده گردد .همچنین ، ممکن است در مواردی لازم باشد که از چندین button در یک فرم ورود اطلاعات استفاده گردد و متناسب با این که کدام button توسط کاربران فعال شده است ، بررسی و صحت داده ورودی تعداد خاصی از کنترل های موجود بر روی فرم ورود اطلاعات ( مستقل از سایر کنترل ها ) ، انجام شود . در چنین مواردی می بایست تمامی کنترل هائی را که می خواهیم  پس از کلیک بر روی یک button خاص ،    validate شوند را عضوء یک گروه نمود و نام آن گروه را برای button مورد نظر نیز مشخص نمود . بدین ترتیب ، پس از کلیک بر روی button مورد نظر صرفا" آندسته از کنترل هائی که عضوء گروه هم نام با گروه معرفی شده به همراه button می باشند ، بررسی و ارزیابی خواهند شد .

مثال
در فرم ورود اطلاعات زیر از چندین کنترل ( چهار کنترل TextBox )  استفاده شده است که تمامی آنها عضوء یک گروه validation می باشند . پس از کلیک بر روی دکمه "ارسال اطلاعات " ، صرفا" آندسته از کنترل هائی که کنترل های validation آنها عضوء گروه مشخص شده می باشند ، validate خواهند شد .

 
فرم ورود اطلاعات : استفاده از چهار کنترل TextBox که تمامی آنها عضوء یک گروه Validation می باشند
 

<SCRIPT Runat="Server"> Sub Validate_Email (Src As Object, Args As ServerValidateEventArgs)   If InStr(Args.Value, "@") = 0 Then       EmailValidator.ErrorMessage = "لطفا یک آدرس پست الکترونیکی صحیح را وارد نمائید"       Args.IsValid = False   End If End Sub Sub Get_Data (Src As Object, Args As EventArgs)   If Page.IsValid Then      Output.Text = "You entered valid data"   End If End Sub </SCRIPT> <form Runat="Server"> <h3>فرم ورو اطلاعات</h3> <table border="0" cellpadding="2"> <tr> <td>نام:</td> <td><asp:TextBox id="FirstName" Runat="Server"/></td> <td><asp:RequiredFieldValidator Runat="Server"         ControlToValidate="FirstName"         ValidationGroup="Group1"         ErrorMessage="لطفا  نام خود را وارد نمائید"         Display="Dynamic"/></td> </tr> <tr> <td>نام خانوادگی:</td> <td><asp:TextBox id="LastName" Runat="Server"/></td> <td><asp:RequiredFieldValidator Runat="Server"          ControlToValidate="LastName"          ValidationGroup="Group1"          ErrorMessage="لطفا  نام خانوادگی خود را وارد نمائید"          Display="Dynamic"/></td> </tr> <tr> <td>سن:</td> <td><asp:TextBox id="Age" Width="50" Runat="Server"/></td> <td><asp:RangeValidator Runat="Server"          ControlToValidate="Age"          ValidationGroup="Group1"          Type="Integer"           MinimumValue="15"           MaximumValue="99"           ErrorMessage="لطفا" یک عدد بین پانزده تا نود و نه را وارد نمائید "           Display="Dynamic"/> <asp:RequiredFieldValidator Runat="Server"         ControlToValidate="Age"         ValidationGroup="Group1"         ErrorMessage="لطفا  سن خود را وارد نمائید  "         Display="Dynamic"/></td> </tr> <tr> <td>آدرس پست الکترونیکی:</td> <td><asp:TextBox id="Email" Runat="Server"/></td> <td><asp:CustomValidator id="EmailValidator" Runat="Server"          ControlToValidate="Email"          ValidationGroup="Group1"          Display="Dynamic"          OnServerValidate="Validate_Email"/> <asp:RequiredFieldValidator Runat="Server"         ControlToValidate="Email"         ValidationGroup="Group1"          ErrorMessage="لطفا  آدرس پست الکترونیکی خود را وارد نمائید"          Display="Dynamic"/></td> </tr> </table> <br/> <asp:Button Text="ارسال اطلاعات"  ValidationGroup="Group1"         OnClick="Get_Data" Runat="Server"/> <asp:Label id="Output" Runat="Server"/><br/> </form>

به دکمه "ارسال اطلاعات "  ، یک نام گروه validation  نسبت داده شده است تا پس از کلیک بر روی آن ، کنترل هائی که کنترل های validation آنها عضوء گروهی با همین نام می باشند ، بررسی و ارزیابی گردند . در صورتی که از کنترل های validation دیگر بر روی فرم استفاده شده است که عضوء گروه validation نمی باشند ، پس از کلیک بر روی دکمه "ارسال اطلاعات " ، ارزیابی نخواهند شد .
پس از کلیک بر روی هر button موجود بر روی یک فرم ، صرفا" آندسته از کنترل هائی بررسی و ارزیابی خواهند شد که تشکیل یک گروه را می دهند و از یک نام مشابه برای گروه استفاده می نمایند که همانند نام نسبت داده شده به button مورد نظر است .

 کنترل <asp:ValidationSummary>
با استفاده از کنترل <asp:ValidationSummary> ، پیام های خطاء جداگانه توسط یک کنترل تولید و با یکدیگر نمایش داده می شوند. کنترل فوق ، همچنین قادر به تولید گزارش پیام های خطاء محدود به مجموعه ای خاص از کنترل ها می باشد . 

شکل عمومی
شکل عمومی کنترل فوق به صورت زیر است :

<asp:ValidationSummary id="id" Runat="Server" DisplayMode="BulletList|List|SingleParagraph" HeaderText="string" ShowMessageBox="False|True" ShowSummary="False|True" ValidationGroup="name" />

توضیحات 

• خصلت DisplayMode ، نحوه ( فرمت ) نمایش پیام های خطاء را مشخص می نماید که به صورت پیش فرض یک لیست bulleted در نظر گرفته می شود .

• مکان نمایش گزارش پیام های خطاء در محلی است که کنترل ValidatiomSummary استفاده شده است .

• با استفاده از خصلت ShowMessageBox و نسبت دادن مقدار True به آن ، یک پیام pop-up نمایش داده خواهد شد .  بدین ترتیب ، خروجی کنترل ValidationSummary در یک PoP-Up نمایش داده می شود .

• در صورتی که خلاصه گزارش خطاء مرتبط با یک گروه validation  خاص می باشد ، می بایست نام آن گروه به خصلت ValidationGroup نسبت داده شود .

مثال
مثال زیر ، بازنویسی مثال قبل است . با این تفاوت که در مقابل نمایش جداگانه پیام های خطاء ، از یک کنترل ValidationSummary استفاده شده است .

استفاده از کنترل ValidationSummary

<SCRIPT Runat="Server"> Sub Validate_Email (Src As Object, Args As ServerValidateEventArgs)   If InStr(Args.Value, "@") = 0 Then       EmailValidator.ErrorMessage = "لطفا یک آدرس پست الکترونیکی صحیح را وارد نمائید"       Args.IsValid = False   End If End Sub Sub Get_Data (Src As Object, Args As EventArgs)  If Page.IsValid Then       Output.Text = "You entered valid data"  End If End Sub </SCRIPT> <form Runat="Server"> <h3>فرم ورو اطلاعات</h3> <table border="0" cellpadding="2"> <tr> <td>نام:</td> <td><asp:TextBox id="FirstName" Runat="Server"/></td> <td><asp:RequiredFieldValidator Runat="Server"         ControlToValidate="FirstName"         ValidationGroup="Group1"         ErrorMessage=" نام "         Display="None"/></td> </tr> <tr> <td>نام خانوادگی:</td> <td><asp:TextBox id="LastName" Runat="Server"/></td> <td><asp:RequiredFieldValidator Runat="Server"          ControlToValidate="LastName"          ValidationGroup="Group1"          ErrorMessage=" نام خانوادگی "        Display="None"/></td> </tr> <tr> <td>سن:</td> <td><asp:TextBox id="Age" Width="50" Runat="Server"/></td> <td><asp:RangeValidator Runat="Server"          ControlToValidate="Age"          ValidationGroup="Group1"          Type="Integer"           MinimumValue="15"           MaximumValue="99"           ErrorMessage="یک عدد بین پانزده تا نود و نه  "         Display="None"/> <asp:RequiredFieldValidator Runat="Server"         ControlToValidate="Age"         ValidationGroup="Group1"         ErrorMessage=" سن   "       Display="None"/></td> </tr> <tr> <td>آدرس پست الکترونیکی:</td> <td><asp:TextBox id="Email" Runat="Server"/></td> <td><asp:CustomValidator id="EmailValidator" Runat="Server"          ControlToValidate="Email"          ValidationGroup="Group1"          Display="None"/>          OnServerValidate="Validate_Email"/> <asp:RequiredFieldValidator Runat="Server"         ControlToValidate="Email"         ValidationGroup="Group1"          ErrorMessage="  آدرس پست الکترونیکی  "         Display="None"/></td> </tr> </table> <br/> <asp:Button Text="Submit" ValidationGroup="Group1"          OnClick="Get_Data" Runat="Server"/> <asp:Label id="Output" Runat="Server"/><br/> <asp:ValidationSummary Runat="Server"      ValidationGroup="Group1"      DisplayMode="BulletList"      HeaderText=" لطفا اطلاعات زیر را وارد نمائید "      ShowSummary="True"      ShowMessageBox="False"/> </form>

در بخش چهارم به بررسی برخی نکات خاص در خصوص ایمن سازی برنامه های وب با تمرکز بر روی کنترل های Validation خواهیم پرداخت .