خانه --> امنیت --> پروتکل HTTP نکات و جزئیات

پروتکل HTTP نکات و جزئیات

پروتکل HTTP (از پروتکل های لایه کاربرد در وب)

پروتکل انتقال فوق متن (Hyper text transfer Protocol )، مجموعه ای از قوانین برای انتقال فایل ها (متن , تصاویر گرافیکی ,صدا ,ویدئو و دیگر فایل های مولتی مدیا) در شبکه وب در اینترنت می باشد. وقتی شما مرورگر (Browser) خود را باز می کنید ، از همان ابتدا از پروتکل HTTP استفاده می کنید تا صفحات اینترنت را مشاهده کنید. این پروتکل کلاینت/ سرور بوده و ارتباط آن از نوع Connection less می باشد. به این معنی که ارتباط کلاینت و سرور به صورت دائمی بر قرار نمی شود و بعد از هر تبادل اطلاعات[۱]، ارتباط قطع می شود و ویژگی های ارتباط برای آن ارتباط خاص، ذخیره نمی شود.

پایه پروتکل HTTP بر مبنای این است که هر صفحه اینترنت می تواند شامل یک لینک (Hyperlink)  باشد، تا از این طریق بتوان به صفحات دیگر رفت و آنها را مشاهده کرد یا به عبارتی فایل ها میتوانند شامل ارجاعهایی به فایل های دیگر باشند که موجب درخواست های اضافی برای انتقال می شود. هر سرور وب علاوه بر صفحات موجود روی خود، یک [۲]deamon دارد که برای دریافت و پاسخگویی به درخواست ها تعبیه شده است. مرورگر وب شما در واقع یک سرویس گیرنده HTTP است که درخواست را برای سرور می فرستد. وقتی مرورگر وب کاربر با وارد کردن URL یا آدرس IP فایلی را در خواست میکند مرورگر وب، درخواستی برای آن فایل ارسال می نماید, مرورگر وب درخواست را به فرمت HTTP در می آورد و برای سرور ار سال میکند و فایل ها را بعد از دریافت از وب سرور برای برنامۀ درخواست کننده اولیه می فرستد. پیام یا تقاضایی که از کلاینت یا مرورگر به سرور ارسال میشود HTTP request و پاسخ یا پیام سرور به کلاینت را  HTTP response نام دارد. هر پیام request یا Response از سه بخش زیر تشکیل شده است.

  • Start lineیا  Request line: که شامل یک متد (جدول ۲-۸)، یک آدرس منبع (URI[3]) و ورژن پروتکل HTTP مورد استفاده می باشد. که ساختار آن به شکل زیر است.

Metod  Protocol://…  HTTP Version

مثال:

GET http://www.mysite.com HTTP/1.1

  • Header: تعداد آن در یک پیام می تواند صفر یا بیشتر باشد(جدول ۲-۱۲) و ساختار آن عبارتست از :

Field Name : Field Value

مثال:

Server:Microsoft-IIS/5.1

  • Optional Masage Body: که در صورت وجود اطلاعات تبادل شده می باشد.(که ممکن است شامل تگ های HTML یا اطلاعات کد شده با پروتکل MIME باشد که در قسمت های بعد به بررسی آن می پردازیم.)

 

معمول ترین نسخه HTTP نسخه ۱٫۱می باشد. این نسخه فایل های وب را سریعتر منتقل می کند. و آخرین سرور های وب و مرورگر ها را پشتیبانی میکند.در ادامه به طور مختصر بررسی میکنیم که چگونه نسخه ۱٫۱اطلاعات را سریعتر ارسال میکند.

ویژگی Persistant Connection در این ورژن اضافه شده به این معنی که به جای اینکه برای هر درخواست یک بار ارتباط (پورت مربوطه) باز وبسته شود, یک ارتباط طولانی تر برقرار میشود که به چندین درخواست اجازه می دهد که در بافر خروجی در صف قرار گیرند.[۴] پروتکل کنترل انتقال (TCP) میتواند چندین درخواست را در یک سیگمنت قرار داده و به لایه IP تحویل دهد.

ولی کارایی بهتری داشته و عبور از سرور های پروکسی را بهتر کنترل می کند.مرورگری که نسخه ۱٫۱را پشتیبانی میکند میتواند فایل های HTML را فشرده کند و با این عمل داده های کمتری بین سرویس گیرنده و سرور جا بجا می شود. علاوه بر مزایای فوق نسخه ۱٫۱ این قابلیت را دارد که چندین نام حوزه از یک آدرس IP مشترک استفاده کنند. این خاصیت پردازش را در سرورهای وبی که چندین وب سایت را در محیطی که اصطلاحا” (میزبان مجازی) نامیده می شود سرویس میدهند را ساده می کند.

HTTP بر روی پروتکل TCP/IP و در لایه ی Application  اجرا می شود. دلیل اینکه HTTP از پروتکل TCP استفاده می کند و نه از UDP این است که TCP پروتکلی است که درستی انتقال اطلاعات را برای گیرنده و فرستنده تضمین می کند به اصطلاح اتصال گرا است[۵] و به آن استریم نیز اطلاق میشودو چون در ارتباط HTTP نیاز ما به این عملکرد ۱۰۰% است، از این پروتکل استفاده می شود. ولی در پروتکل UDP از لحاظ صحت اطلاعات، تضمینی وجود ندارد به اصطلاح بدون اتصال است.[۶]و به دیتا گرام نیز اطلاق میشود.

پروتکل HTTP
پروتکل HTTP

پروتکل  HTTP یک پروتکل درخواست و پاسخ  است که بین یک کلاینت و یک سرور برقرار می شود . در اینجا کلاینت همان  User Agent (مرورگر شما) است و منظور از سرور یک وب سایت اینترنتی می باشد .

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

به منظور انجام یک تراکنش موفقیت آمیز بین سرویس گیرندگان وب ( نظیر IE )  و سرویس دهندگان وب ( نظیر IIS ) ، به اطلاعات زیادی نیاز خواهد بود . پس از عمل دست تکانی سه مرحله ای (three hand handshake) در پروتکل TCP مرورگر، اطلاعات گسترده ای را ‌ برای سرویس دهنده وب  ارسال می نماید .

معمولا HTTP برای برقرای ارتباط با سرور از پورت ۸۰ پروتکل TCP در لایه انتقال استفاده می کند. وب سرور با استفاده از تابع سوکت Listen() همواره به این پورت گوش میدهد. همچنین برای برقرای ارتباط با سرور، پروتکل HTTP از دستورهای خاص خود بهره می برد (نظیر Get – Head – Post – Put – …) که توضیح آنها در جدول ۲-۸ آورده شده است.

 

دستورات

عملکرد

GET

درخواست برای دریافت یک صفحه وب از یک وب سرور(سرویس دهنده وب)

PUT

درخواست برای ذخیره کردن یک صفحه وب روی یک سرویس دهنده

HEAD

درخواست برای دریافت سرایند[۷] یک صفحه وب از یک وب سرور(سرویس دهنده وب)

POST

درخواست برای ضمیمه کردن یک منبع

DELET

درخواست برای حذف یک صفحه وب

LINK

درخواست برای برقراری پیوند بین دو منبع

UNLINK

خاتمه پیوند بین دو منبع

TRACE

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

OPTIONS

سایر پتانسیل های موجود به منظور کار بر روی یک سند توسط یک سرویس گیرنده وب درخواست می گردد .

CONNECT

سرویس گیرنده وب به عنوان یک پراکسی به یک سرویس دهنده HTTPS متصل می گردد .

جدول ۲-۸ (دستورات پروتکل HTTP)

 

نکته : در برخی از سرویس دهنده های وب به دلیل افزایش امنیت از اجرای متود های PUT، POST و DELETE جلوگیری می شود.

 داده مربوط به پروتکل HTTP ، پس از هدر TCP/IP قرار می گیرد  .شکل ۲-۴ و ۲-۵ و جدول ۲-۹ زیر برخی اطلاعات مبادله شده بین سرویس گیرنده و سرویس دهنده وب را که توسط نرم افزار Wireshark[8] استخراج شده است را نشان می دهد .

نکته : User agent نوع مرورگر و سیستم عامل  سرویس گیرنده را مشخص می نماید و این موضوع می تواند  مواد اولیه لازم برای تدارک برخی حملات توسط مهاجمان را تامین نماید .

    (برخی اطلاعات مبادله شده بین سرویس گیرنده و سرویس دهنده وب توسط نرم افزار Wireshark)

 

دستورات

عملکرد

GET /HTTP/1.0\r\n

سرویس گیرنده وب یک درخواست GET را برای سرویس دهنده وب ارسال و از وی درخواست اطلاعاتی را با استفاده از  پروتکل HTTP 1.0 می نماید.

Host:

 www.google.com

وب سایتی است که سرویس گیرنده قصد ارتباط با آن را دارد .

User-agent:

 Opera 9.80 (Windows; U; Windows NT 5.1;

نوع  نرم افزار سرویس گیرنده ( در این مورد خاص   Opera 9.80 ) و  نوع سیستم عامل نصب شده بر روی کامپیوتر ( در این مورد خاص Windows version NT 5.1 و یا همان ویندوز XP  ) اعلام می گردد.

Accept-language:

en-US; q=0.9

نوع character set استفاده شده به سرویس دهنده اعلام می گردد ( در این مورد خاص از  en:us نسخه ۰٫۹ میباشد) .

Accept:

 text/xml, application/xml, application/xhtml+xml

سرویس گیرنده به سرویس دهنده وب فرمت  اطلاعاتی را که می تواند دریافت نماید ، اعلام می نماید ( در این مورد خاص هم برای متن و هم برای   application  از فرمت xml استفاده می گردد ) .

/html; q=0.9, text/plain; image/png, */*;q=0

سرویس گیرنده  به سرویس دهنده نوع فرمت متن دریافتی را اعلام می نماید ( در این مورد خاص html و یا plain text ) .

همچنین فرمت فایل های گرافیکی ( در این مورد خاص png . و سایر فرمت های متداول ) نیز اعلام می گردد .

Accept-Charset:

 ISO-8859-1, utf-8; q=0.7, *;q=0/7

لیست character set که سرویس گیرنده وب قادر به فهم آنان است،  اعلام می گردد ( در این مورد خاص  ISO-8859 , و یا utf-8  ) .

Keep-Alive:

 ۳۰۰ Connection: keep-alive

به  سرویس دهنده وب مدت زمان نگهداری  session  اعلام می گردد ( در این مورد خاص ۳۰۰ ثانیه ) .

سرویس گیرندگان می توانند با صراحت پایان یک session را اعلام نمایند . در نسخه شماره ۱ . ۱  پروتکل HTTP ، ارتباط و یا اتصال برقرار شده فعال و یا open باقی خواهد ماند تا زمانی که سرویس گیرنده خاتمه آن را اعلام  و یا مدت زمان حیات آن به اتمام رسیده باشد .

در نسخه شماره یک پروتکل HTTP ، پس از هر درخواست و اتمام تراکنش ، ارتباط ایجاد شده غیرفعال و یا close می گردد .

Cookie: PREF=ID=01a0822454acb293: LD=en:TM=1121638094

  و مقدار مربوطه  به آن اعلام می گردد. کوکی یک متن اسکی فلت می باشد که اطلاعات متفاوتی را در خود نگهداری می نماید .

مدت زمان حیات یک کوکی می تواند موقت ( تا زمانی که مرورگر فعال است ) و یا دائم ( ذخیره بر روی هارد دیسک کامپیوتر  و در یک محدوده زمانی تعریف شده ) باشد .

جدول ۲-۹ (برخی اطلاعات مبادله شده بین سرویس گیرنده و سرویس دهنده وب توسط نرم افزار Wireshark)

 

 (یک بسته اطلاعاتی نمونه)

 

فرق متد GET با POST از دیدگاه امنیتی

به منظور ارسال داده از روش های متفاوتی استفاده می گردد . روش های GET و POST دو متد متدوال در این زمینه می باشند.

متد GET

 در این روش داده موجود بر روی یک فرم که قرار است برای سرویس دهنده ارسال شود ، به انتهای URL و به شکل ” نام = مقدار” ، اضافه می گردد. متد GET، گزینه پیش فرض در خصوص نحوه ارسال اطلاعات یک فرم می باشد .

در روش GET، پارامترها به کمک query string که مستقیما در انتهای URL اضافه شده اند، به سرور ارسال میگردند.
query string به قطعه متنی که پس از علامت “?” آمده باشد میگویند.

username=admin?

اولین بخش از زوج “نام = مقدار” ، نشان دهنده “نام” و دومین بخش مقدار مورد نظر به منظور ذخیره سازی را نشان می دهد. نام و مقدار متناظر با آن به صورت اتوماتیک از یک عنصر موجود بر روی فرم نظیر یک textbox ویا checkbox ، اخذ می گردند. نام کنترل استفاده شده بر روی فرم ، نام استفاده شده در متد GET بوده و محتویاتی را که کاربر در کنترل مورد نظر درج و یا انتخاب می نماید، مقدار موردنظر را مشخص می نماید . در مثال فوق ، ‘username’ ، نام مورد نظر بوده و ‘admin’ ، مقدار مرتبط با آن است . مرورگر در زمان ارسال صفحه برای سرویس دهنده ، اطلاعات فوق را به صورت اتوماتیک به URL اضافه می نماید:

http://www.mysite.ir/testpage.aspx?username =admin

امکان استفاده بیش از یک زوج “نام = مقدار” به همراه یک URL وجود خواهد داشت . در چنین مواردی هر زوج توسط علامت “&” ( ampersand ) ، از یکدیگر جدا می گردند .

http://www.mysite.ir/testpage.aspx?username=test&password=test

ولی تنها روش موجود به منظور ارسال داده بین سرویس گیرنده و سرویس دهنده نمی باشد و در این رابطه از متد POST نیز استفاده می گردد هر چند در ظاهر سرعت عمل متد GET از متد POST بیشتر است ولی به دلایل امنیتی از متد POST برای ارسال اطلاعات استفاده می شود. البته این مورد هم جای بحث وبررسی دارد.

متد POST

از تفاوت های متد GET با POST این است که proxy server ها اگر صادق باشند[۹] اجازۀ Cach نمودن اطلاعاتی را که با متد POST ارسال شده اند را به علت جلوگیری از دسترسی افراد بد اندیش ندارند. و  البته به این ویژگی نباید زیاد دل بست و کارشناسان امنیت می بایست با استفاده از مکانیزم های محرمانگی ، از نشت اطلاعات جلوگیری کنند. (که در فصل های بعد به آن می پردازیم) از تفاوت های دیگر این است که یکی از معایب ارسال داده با استفاده از query string ، به ماهیت ارسال اطلاعات برمی گردد . درصورتی که ضرورتی و یا علاقه ای به نمایش داده ارسالی در آدرس URL را نداشته باشیم، می توان از متد POST استفاده نمود . عملکرد روش فوق تا اندازه ای شبیه متد GET بوده و تنها تفاوت اساسی بین آنان به ارسال داده در بدنۀ پیام HTTP Request برمی گردد ( نه به عنوان بخشی همراه URL ). سیاست فوق ، ایمنی بسیار بالائی را نسبت به متد GET ارائه نمی نماید و ما صرفا” داده ارسالی را در URL مشاهده نمی نمائیم. و به کمک نرم افزار های Sniffing  مقادیر آن قابل استخراج است. متد POST ، همچنین امکان ارسال حجم بیشتری از اطلاعات را فراهم می نماید. برخی از سرویس دهندگان وب دارای محدودیت حجم متن ارسالی همراه یک URL می باشند. متد POST ، دارای چنین محدودیتی نمی باشد.

(MIME) Multipurpose Internet Mail Extensions

استانداردی برای قالب بندی پیامهای ASCII  است که ارسال آنها از طریق اینترنت را ممکن می سازد. اکنون بسیاری از کلاینتهای پست الکترونیکی از قالب بندی  MIMEپشتیبانی می کنند و قادرند فایلهای گرافیکی ، صوتی و تصویری را از طریق سیستم پستی اینترنت ارسال و دریافت کنند. علاوه بر این ،MIME  از پیامهایی که مجموعه کاراکتری (Character Set) آنها به غیر از ASCII است ، حمایت می کند. استاندارد MIME علاوه بر اینکه دارای انواع ازپیش تعریف شده زیادی مثل فایلهای گرافیکی POSTSCRIPT و GIF است، می تواند ازسوی شما نیز به صورتهای مختلف تعریف شود. علاوه بر برنامه های کاربردی پست الکترونیکی ، مرورگرهای وب نیز از انواع گوناگون استاندارد MIME حمایت می کنند.

این امر به مرورگر امکان چاپ یا نمایش فایل هایی را می دهد که قالب HTML ندارند. در ١٩٢٢ گروه ویژه مهندسی اینترنت MIME (IETF)  را تعریف کرد. نسخه جدید این برنامه S/MIME نام دارد که از پیامهای مخفی شده حمایت می کند. تمامی فایل های صوتی و تصویری که به یک صفحۀ وب ضمیمه می شوند نیز با قالب [۱۰]این پروتکل انتقال میابند. بررسی دقیق این پروتکل از حوصله این کتاب خارج است لذا برای دور نماندن از مطالب اصلی به ادامه مباحث می پردازیم.

 

 ساختار URL  [۱۱]

 URL مخفف عبارت  Uniform Resource Location(مکان‏یاب منابع عمومی) است. در دنیای وب هر URL آدرس دقیق یک فایل یا یک صفحه وب محسوب میشود. که می خواهید از آن دیدن کنید در واقع word wide web (www)  از آن برای پیدا کردن فایل‌ها و اسناد کامپیوترها در روی اینترنت استفاده می‌کند.  روش آدرس دهی به سبک URL برای تمامی کامپیوتر های نا همگون در شبکه وب شناخته شده است. توجه داشته باشید که یک URL می تواند شما را به هر سایت ، شاخه ، زیر شاخه ، فایل متنی ، تصویر ، فیلم یا صدا متصل کند. هر URL جواب سه سوال را دقیقا مشخص می کند.

  • نام فایل ؟
  • محل دقیق فایل ذخیره شده ؟ ( بر روی کدام ماشین و کدام مسیر؟)
  • قانون و پروتکل دسترسی به فایل ؟

ساختار یک سند URL بصورت شکل ۲-۶ است، شامل ۴ قسمت:[۱۲]

 (ساختار یک سند URL)

۱Protocol  : پروتکلی که مورد استفاده قرار میگیرد را مشخص می کند متداول ترین آنها عبارتند از:

HTTP : برای web server است که مخفف hyper text transfer prorocol می‌باشد

FTP : مخفف کلمات File Transfer protocol که به FTP ناشناس شهرت دارد و آرشیوی از فایلهاست .

 Telnet: ایجاد یک جلسه Telnet برای دسترسی به کامپیوتر از راه دور وقتی مرورگر وب خود را انتخاب می‌کنید برای Telnet آماده خواهد شد و یک برنامه خارجی را به یک سایت مشخص اتصال پیدا می‌کند      

WAIS  : مخفف کلمات Area Indexed server سروری برای جست‌وجو موضوعات و اسناد جهت دار با استفاده از لغات کلیدی.

File   : فایل‌ها بر روی کامپیوتر شما (فلاپی ، هارد دیسک ، … ) این نوع آدرس دهی همیشه با :// دنبال می شود و آدرس اینترنت یک کامپیوتر راه دور مانند این آدرس Host.Domain.Domain.Domain

 برای مثال: http://www.yahoo.com

۲ :address of host computerآدرس کامپیوتری که سند مورد نظر در آن قرار دارد.

۳path :  مسیر کامل file مورد نظر درhost compute  

۴ : file name نام file مورد نظر.[۱۳]

نکته : البته گاهی نام فایل در URL دیده نمی شود.  به عنوان مثال www.mysite.com به این دلیل که سرویس دهندۀ وب نام فایلی پیش فرض برای یک آدرس در نظر میگیرد که این نام های پیش فرض معمولا کلماتی از قبیل index یا defult  می باشند. با این عمل آدرس های URL کوتاه تر به نظر می آیند.

دو آدرس زیر دقیقا معادل یک دیگر می باشند.

www.mysite.com

www.mysite.com\index.html

نکته : باید به این نکته توجه داشت که در برخی از سیستم عامل ها برای مشخص کردن شاخه و زیر شاخه های فایل ذخیره شده از کارکتر \ استفاده می شود ولی در آدرس URL برای جدا کردن زیر شاخه ها از کارکتر / استفاده میشود. (در قسمت های بعد از این نکته بهره برداری امنیتی و ضد امنیتی خواهیم کرد)

نکته : نام حوزه ماشین سرویس دهندۀ وب می تواند با آدرس IP مربوط به آن جایگزین شود. به عبارتی اگر نام حوزه[۱۴] www.mysite.com با آدرس  ۱۰۰٫۱۰۰٫۱۰۰٫۱ معادل باشد دو URL زیر ما را به یک مکان هدایت خواهند کرد.

نکته : استفاده از آدرس IP بجای نام حوزه به علت سختی در بخاطر سپردن مرسوم نمی باشد و به همین دلیل از نام حوزه استفاده می شود و سرویس  DNS در پشت صحنه این عمل تبدیل نام را به IP انجام میدهد.

نکته : استفاده از آدرس IP بجای URL سرعت ما را در ارتباط افزایش میدهد به دلیل آنکه از اجرای تابع سوکت Gethostbyname() صرفه نظر میشود.

نکته : در صورت خرابی DNS میتوان از آدرس IP برای اتصال به یک سایت استفاده نمود.

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

 

داستان ارتباط مرورگر وب با سرویس دهندۀ وب

سناریو  ارتباط مرورگر با سرور وب برای نمایش یک صفحۀ وب یا دریافت یک فایل به شرح زیر می باشد:

  • سرویس دهندۀ وب توسط پروسه ای دائما به پورت شماره ۸۰ با استفاده از تابع سوکت Listen() گوش میدهد(جدول ۱-۷) و منتظر تقاضای بر قراری ارتباط، توسط برنامه مرورگر میماند. (این سوکت از نوع استریم یا به عبارتی TCP  است و تمامی دستورات و داده های تبادل شده بین این دو به صورت متنی است)

فرض کنید که کاربر، URL زیر را در خط آدرس مرورگر خود وارد نموده است.

http://www.mysite.com/mydirectory/mypage.html

  • مرورگر با استفاده از توابع رشته[۱۵] آدرس URL را تحلیل میکند و قسمت ها مختلف URL را تشخیص میدهد سپس متوجه میشود که باید تقاضای خود را بر اساس پروتکل HTTP به سمت سرویس دهنده ارسال کند.
  • مرورگر به DNS تقاضای ترجمۀ نام حوزۀ mysite را ارسال میکند و DNS آدرس IP معادل با آن را برمیگرداند. فرض کنید آدرس IP سایت ۱۰۰٫۱۰۰٫۱۰۰٫۱ میباشد .مرورگر این کار را با استفاده از تابع سوکت Gethostbyname() انجام میدهد.
  • مرورگر یک تقاضای ارتبط TCP با آدرس ۱۰۰٫۱۰۰٫۱۰۰٫۱ و پورت شمارۀ ۸۰ برای سرویس دهنده HTTP ارسال میکند و البته این کار با تابع سوکت Connect() انجام میشود.
  • پس از برقراری ارتباط، توسط یکی از دستورات پروتکل HTTP (جدول ۱-۸) با نام Get رشته /mydirectory/mypage.html به سرویس دهنده ارسال میشود. در حقیقت رشته زیر با تابع سوکت Send() ارسال میگردد.

“GET /mydirectory/mypage.html”

نکته: اگر بعد از نام فایل درخواست شده عبارت if-modified-since:  همراه با یک تاریخ  و زمان ذکر شود، سرویس دهنده به شرط آن که فایل دذکور بعد از تاریخ اعلام شده تغییر داشته باشد آن فایل را ارسال میکند. مثال:

“GET /mydirectory/mypage.html HTTP/1,0 if-modified-since: sat,27 Oct 201012:45:59 “

که عبارت HTTP/1,0 نسخه [۱۶] پروتکل را مشخص مینماید.

  • سرویس دهنده پس دریافت رشته فوق آنرا تحلیل کرده و فایل html را که از نوع ابر متن[۱۷] می باشد را از شاخه /mydirectory استخراج میکند و سپس آنرا برای مرورگر ارسال مینماید.
  • مرورگر هم فایل را دریافت نموده و ارتباط TCP خود را قطع مینماید. که در حقیقت با استفاده از تابع سوکت Close() این ارتباط خاتمه میابد.
  • مرورگر فایل ابر متن را تفسیر نموده و آنرا نمایش میدهد.اگر در فایل تفسیر شده آدرس فایل های تصویری یا صوتی نیز وجود داشته باشد مراحل دریافت آن فایل ها نیز دوباره تکرار میشود. (بر خلاف سیستم های پست الکترونیکی که داده ها در ادامه متن ضمیمه میشوند.)

وقتی تقاضایی به سرویس دهنده ارسال می شود چه در صورت پذیرش و چه در صورت عدم پذیرش پاسخی متنی با ساختار شکل ۲-۷ به سمت مرورگر ارسال میشود.

 

رشته متنی (برای توضیح شماره وضعیت)

شماره وضعیت (جهت اعلام نتیجه تقاضا)

شماره نسخه/ پروتکل

شکل ۲-۷ (ساختار پاسخ سرور به یک تقاضای HTTP)

 

مثال :

HTTP/1,0 200 OK

یا

HTTP/1,1 404 Not found

شماره وضعیتها در پنج گروه متفاوت دسته بندی میشوند.(جدول ۲-۱۰) برخی از شماره های وضعیت در جدول ۲-۱۱ فهرست شده است. البته بعد از ارسال خطوط فوق چند سطر اطلاعات اضافی برای مرورگر از طرف سرور ارسال میشود که برای تحلیل و تفسیر بسیار مهم است. که در جدول ۲-۱۱ به این اطلاعات اشاره شده است. و بعد از این خطوط که سرآیند نام دارد یک خط خالی و سپس در ادامه داده های فایل درخواستی ارسال میگردد. در شکل ۲-۸ با استفاده از Telnet پاسخ سرور در برابر دستور telnet www.mysite.com 80  نمایش داده شده است.

(نمونه پاسخ سرور به یک تقاضای HTTP)

 

 

عملکرد

کد

 اطلاع رسانی برای استفاده در آینده

۱XX

 انجام موفقیت آمیز تراکنش 

۲XX

 راهنمائی مجدد

۳XX

 بروز خطاء سمت سرویس گیرنده

۴XX

 بروز خطاء سمت سرویس دهنده

۵XX

جدول ۲-۱۰ (گروه های پنج گانه کدهای وضعیت  را در ارتباط با پروتکل HTTP)

 

عملکرد

کد وضعیت

 تراکنش با موفقیت انجام شده است

۲۰۰

 دستور POST با موفقیت انجام شده است

۲۰۱

 درخواست ارسالی دریافت گردید.

۲۰۲

 منبع درخواستی در مکان های مختلفی پیدا شده است

۳۰۰

 منبع درخواستی به صورت دائم منتقل شده است

۳۰۱

 منبع درخواستی به صورت موقت  منتقل شده است

۳۰۲

 درخواست نامناسب از جانب سرویس گیرنده

۴۰۰

 درخواست غیرمجاز

۴۰۱

 منبع درخواستی پیدا نگردید

۴۰۴

 بروز خطاء بر روی سرویس دهنده

۵۰۰

 متد استفاده شده ، پیاده سازی نشده است

۵۰۱

جدول۲-۱۱ (نمونه شماره های وضعیت)

 

 

توضیحات

ساختار اطلاعات

محل فایل یا منبع درخواستی

Location: absolute URL

نام فراهم کننده سرویس و نوع سرویس دهندۀ وب

Server: Product

تاریخ و زمان آخرین تغییر فایل یا منبع در خواستی

Last-Modified: HTTP-Date

تاریخ و زمان انقضای فایل یا منبع در خواستی

Expires: HTTP-Date

نحوه و روش کد گذاری Data Message (بدنۀ پیام) (استاندارد MIME)

Content-encoding: encoding

طول داده ها بر حسب بایت (استاندارد MIME)

Content Length: Length

نوع سند ارسال شده (استاندارد MIME)

Content Type: Type

جدول  ۲-۱۲ (اطلاعات ارسالی برای مرورگر از طرف سرور)

نکته : در صورت علاقه به این مباحث خواننده محترم می تواند با رجوع به کاوشگر های سورس آزاد[۱۸] و بررسی کد آنها، در این زمینه مهارت کسب کند.

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

 

استخراج اطلاعات از URL

هر فرد با تجربه در زمینه امنیت و نفوذ در وب به خوبی میداند که اطلاعات با ارزشی را می توان از آدرس URL بدست آورد. ساختار زیر را برای یک URL در نظر بگیرید.

Protocol://Server/Path/resource?Parameter

Protocol: پروتکل لایه کاربرد را مشخص می نماید و معمولا از نوع HTTP می باشد.

Server: آدرس IP، نام حوزه یا نام Netbios یک میزبان و یا یک شبکه می باشد.

Path : مسیر ذخیره سازی منابع مثل فایل ها یا صفحات وب

Resource : نام منابع مثل فایل ها یا صفحات وب

? : جدا کنندۀ ورودی ها[۱۹] از آدرس URL

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

برای درک بیشتر این مفاهیم یک آدرس فرضی را مورد تحلیل و بررسی قرار می دهیم:

http://www.national-article.ir/shop/archive3/selection.aspx?ID=890317&category=it

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

  • پروتکل استفاده شده از نوع HTTP است و از مدل امن HTTPS استفاده نشده است.
  • national -article این عبارت نشان میدهد که احتمالااین سایت در زمینه مقالات ملی فعالیت می کند.
  • پسوند .ir نشان میدهد که حوزه فعالیت این سایت ایران است یا صاحب ایرانی دارد. و احتمالا دارای سرورهای وب متن باز یا بدون لایسنس می باشد.
  • مسیرShop/ / نشان می دهدکه احتمالا اطلاعات درون این شاخه فروشی است. پس میتواند ارزش بررسی داشته باشد.
  • شاخۀ archive3/ بیانگر این است که اطلاعات بر اساس موضوعی خاص در این شاخه قرار گرفته است ضمن اینکه این اسم نشان دهندۀ این است که امکان وجود شاخه هایی با نام های archive1/ ، archive2/ یا حتی archive4/ در این مسیر وجود دارد.
  • با نگاه به Selection.aspx متوجه میشویم که این فایل با پسوند .aspx مطمئنا یک فایل Microsoft Active Server Page می باشد.
  • از طرفی فایلهای ASPX منحصرا بر روی سرویس دهنده های Microsoft IIS Web Server اجرا می شوند. بنابر این سرور وب از نوع IIS می باشد.
  • سرویس دهنده های IIS برروی سرورهای مبتنی بر ویندوز مثل ۲۰۰۰, XP, 2003, 2008 اجرا می شوند. بنابر این سرور سایت /www.national-article.ir بر روی یک سرور از محصولات میکروسافت است پس ما با سرور ویندوزی سر و کار داریم.
  • پارامتر ID=890317 احتمالا شماره انحصاری یک مقاله در پایگاه داده است .
  • با توجه به مورد ۸ سیستم پایگاه داده این سرور از نوع  Microsoft SQL Server یا Microsoft Access می باشد.
  • با توجه بیشتر در ID=890317 متوجه می شویم که رشته ۸۹۰۳۱۷ احتمالا یک تاریخ است. پس این رکور مربوط به ۱۷ شهریور سال ۸۹ میباشد. با این استدلال میتوانیم تاریخ های دیگر را در پایگاه داده بررسی کنیم.
  • پارامتر category=it نیز نشان دهندۀ این است که این مقاله احتمالا در حوزۀ فناوری اطلات است پس احتمالا امکان وجود حوزه های دیگر وجود دارد.

تفاوت http  با https   

مهمترین تفاوت میان http با https امنیت و حفاظت از اطلاعات مربوط به کاربر است به بیان دیگر یک پروتکل (یک قرارداد) جهت رد و بدل اطلاعات میان سرور و کاربر است .کارکتر S است که تفاوت میان HTTP و HTTPS[20] را ایجاد می کند  مخفف کلمه Secure به معنی امن است و نباید آن را با S-HTTP[21] اشتباه گرفت.  HTTPS  در واقع همان HTTP است که با پروتکل SSL/TSL ترکیب شده است که به این ترتیب میکانیزم های محرمانگی، یکپارچگی و تایید هویت را برای کاربر فراهم میکند.  در موقع ورود به وب سایت‌ها، به طور معمول عبارت http:// در ابتدای آدرس URL ظاهر می‌شود. این بدین معناست که کاربر در حال ارتباط با سایت توسط از ارتباط غیر امن می باشد. به زبان دیگر یعنی ممکن است شخص سومی (مانند برنامه کامپیوتری ، نفوذگر، …) در حال شنود یا حتی دستکاری اطلاعات رد و بدل شده کاربر با وب سایتی که در آن حضور دارد، باشد .در صورت پر کردن فرمی در وب سایت، نفوذ گر ممکن است به اطلاعات وارد شده بوسیلۀ کاربر دسترسی پیدا کند.  به همین دلیل است که هرگز نباید اطلاعات کارت‌های اعتباری اینترنتی را از پروتکل http://  در سایت وارد کرد.اما در صورت شروع شدن نام وب سایت با https:// ، این بدین معناست که کامپیوتر کاربر در حال تبادل اطلاعات با سایت با مکانیزم های امنیتی است که شخص دیگری قادر به استفاده از آن نیست. در شکل () صفحۀ تایید اعتبار سایت Google آورده شده به عبارت https:// در URL و علامت قفل و توضیحات زیر آن دقت کنید.

در اینجا چند نکته قابل تامل است:

  • در https:// اطلاعات ابتدا رمز شده و به سرور ارسال می‌گردد. سپس این کد در سرور رمز گشایی شده و به زبان قابل فهم بر می‌گردد. این کار مقداری زمان بر بوده و بنابراین سرعت https از سرعت http کمتر است.
  • تعداد از شرکت‌های امنیتی مانند Verisign و Goddady این سرویس را ارائه می‌دهند که جهت تبدیل اطلاعات سروری که کاربر به آن متصل شده‌ به این سرور ها مراجعه می‌کند.
  • بعد از ورود با پروتکل https ، اطلاعاتی در رابطه با امنیت اعمال شده در سایت و گروه ارائه دهنده این امنیت نمایش داده می‌شود. این اطلاعات معمولا ( در اکثر مرورگر ها ) بصورت قفلی در پایین صفحه موجود بوده و بعد ازکلیک بر روی آن این اطلاعات را مشاهده خواهید کرد.
  • در هنگام ورود به این سایت‌ها حتما به اطلاعات امنیتی توجه کنید. ممکن است امنیت در کار نبوده و همه اینها با برنامه نویسی ساده‌ای برای شما نمایش داده شود.
  • جهت داشتن https:// هزینه ای ماهانه باید پرداخت گردد که بر اساس سرعت آن متفاوت است. هر چه سرعت بیشتر، صاحب سرور باید هزینه بیشتری پرداخت کند.
  • پروتکل https:// معمولاً برای بانک‌ها، ایجاد حساب کاربری و ورودکاربری به پورتال‌ها – سرویس دهنده‌ها پیغام الکترونیکی – ..، خریداینترنتی و فروشگاه‌های اینترنتی، ورود به صفحات با اطلاعات سری و مهم وغیره استفاده می‌شود.
  • سود اصلی HTTPS جلوگیری از Sniff کردن اطلاعات هست. یعنی برای مقابله با دزدهای اطلاعاتی که در مسیر قرار می گیرند. (به طور مثال شما هر اطلاعاتی را که در حالت عادی از HTTP انتقال بدهید یک سازمان واسطه قادراست چه با مجوز و یا بدون مجوز از اطلاعات استفاده کند.
  • سرور میزبان باید یک Public Key ثبت کند که هزینه‌ای هم نخواهد داشت. اما اثبات اینکه آیا خود میزبان کسی که ادعا می‌کند، هزینه بر است. اینکار بوسیله Verisign و غیره انجام می‌شود. بدین معنی که با پرداخت هزینه به این سرویس دهنده، کاربران مطمئن می‌شوند که سرور همان فردی یا سازمانی است که خواهان وارد کردن اطلاعات خود می باشد.

حملات به URL

مکانیزیمهای Whisker برای فریب دادن IDS .

Whisker ده روش متنوع و قدرتمند برای گول زدن IDS بکار میگیرد که من این روشها را یک به یک برای شما عزیزان معرفی خواهم کرد.

نکته: در تمام این روشها تقاضا , ارسال یک فرمان HTTP به سرویس دهندۀ وب برای فعل و انفعال با برنامۀ CGI تلقی میشود.

URL Encoding : قسمت آدرس در URL ارسالی با کدهای معمولی ASCll ارسال نمیشود. بلکه ابتدا هر کارکتر با معادل یونی کد آن ( یعنی با قالب %xx تعریف شده در MINE ) جایگزین و سپس ارسال میشود . برخی از سیستمهای IDS قادر نیستند چنین قالبی را تشخیص دهند و لذا تقاضای خطرناک کشف نخواهد شد.

/./ Directory Insertion  :  URL  ارسالی شامل کارکترهای /./ است که در برخی از سرویس دهنده های وب به این شکل تعبیرو تفسیر میشود که “لطفا به شاخۀ جاری تغییر مسیر بدهید.!” تغییر مسیر به شاخۀ جاری هیچ خاصیت یا ضرری ندارد . بلکه فقط شکل ظاهری URL را به گونه ای تغییر میدهد تا به الگوی حمله شباهت نداشته باشد. مثال:

GET /./cgi-bin/./broken.cgi http/1.0

 Premature URL Endig: در URL ارسالی اطلاعاتی در خصوص اسکریپ مورد نظر قرار داده نمیشود . در عوض این اطلاعات در بخش سراینده HTTP جا سازی میشوند به مثال زیر دقت کنید.

GET /HTTP/1.0\r\Nheader:../../cgi-bin/broken.cgi/HTTP/1.0

کسانی که با پروتکل HTTP اشنا هستند صحت این URL و اعتبار تقاضای GET را تایید میکنند.

Long URL: قسمت ادرس در URL ارسالی شامل نام بسیار طولانی یک شاخه است که وجود ندارد. در انتهای نام کارکتر /../

قرار میگیرد. بدین ترتیب در سویس دهندۀ وب از نام شاخه چشم پوشی میشود. برخی از سیستمهای IDS فقط بخش اول ادرس

URL را بررسی مکنند. و لذا یک تقاضای خطرناک کشف نخواهد شد. مثال:

GET /thisissaunchofjunktomaketheURLlonger/../cgi-bin/broken.cgi HTTP/1.0

Fake Parameter : URL ارسالی شامل پرامترهای است که هیچ خاصیت یا ضرری ندارد. فقط شکل URL را بگونه ای

تغییر میدهد تا به الگوی حمله شبیه نباشد. و IDS انرا مجاز بداند. مثال

GET /index.html?param=/../cgi-bin/broken.cgi HTTP/1.0

TAB Separation: بخشهای مختلف URL ارسالی بجای انکه با کاراکتر “فاصله” (SPACE) جدا شده باشند با کاراکتر <tab>

جدا میشوند. در این حالت شکل URL بگونهای تغییر میکند. تا به الگوی حمله شباهت نداشته باشد و IDS انرا مجاز بداند. ( برخی از سیستمهای IDS به این نحو گمراه میشوند. و به تقاضا اجازۀ اجرا میدهند. و برخی دیگر ان را حذف میکنند.) مثال

GET<tab>/cgi-bin/broken.cgi<tab>HTTP/1.0

Case Senitvity: برخی از سیستهای ,IDS انتظار URL را با حروف کوچک دارند و لیکن در تعدادی از سرویس دهندهای وب ( مثل IIS در ویندوز ) ارسال URL با حروف بزرگو کوچک فرقی نمکندو قابل اجراست. بدین ترتیب سیستم IDS فریب میخورد و تقاضایارسالی را اجرا میشود. مثال :

GET/CGI-BIN/broken.cgi HTTP/1.0

Windows Delimiter: در سیستم عامل ویندوز استفاده از علامت \ به جای / ( جدا کنندۀ شاخه) مجاز شمرده میشود در حالیکه برخی از سیستم های IDS به ان حساسیت ندارند لذا در مورد شکل URL گمراه میشوند. مثال:

GET/cgi-bin\broken.cgi HTTP/1.0

NULL Method: بسیاری از سیستهای IDS برای تحلیل رشتۀ URL از توابع رشته ای استفاده میکنند . حال اگر در بین رشتۀ URL

کاراکتر۰۰ % (NULL Character) وجود داشته باشد توابع رشته ای انرا بعنوان خاتمه رشته تلقی میکنند. و بدین نحو IDS گمراه میشود. در حالی که URL اعتبار خود را از دست نخواخد داد. مثال:

GET%00 /cgi-bin/broken.cgi HTTP/1.0

به گونه ای که خدمت شما عزیزان توضیح دادام . Whisker از روشهای ساده و قدرتمندی برای مخفی ماندن بهره میگیرد.

این نرم افزار در ادرس زیر در اختیار عموم قرار گرفته است.

نکته: این برنامه مبتنی بر Perl میباشد. و روی تمام محیط های که زبان Perlرا پشتیبانی میکنند قابل اجرا میباشد.

http://wiretrip.net/rfp/

مراجع

RFC 1945

RFC 1728

RFC  ۲۶۱۶

RFC 2660

[۱]  Request/Response

[۲] سرویس پنهان

[۳]  Universal Resource Identify

[۴]  Persistant Connection

[۵] Connection orinted

[۶] Connection less

[۷] Header

[۸]   از نرم افزار های برتر جهت Sniff بسته های اطلاعاتی در شبکه

[۹]  Honest

[۱۰] Format

[۱۱] http://webdesign.about.com/cs/beginninghtml/a/aa110201a.htm

[۱۲] http://www.santarosa.edu/library/IT/url.html

  [۱۳]  برای اطلاعات تکمیلی درباره URL می توانید به  RFC-1738 مراجعه کنید.http://www.faqs.org/rfcs/rfc1738.html

[۱۴]www.mysite.com

[۱۵]  String

[۱۶] Version

[۱۷] HTML

[۱۸]  Open Source

 [۲۰] Hypertext Transfer Protocol Scure

 [۲۱]  توضیح  S-HTTP در RFC 2660 آمده است.

آدرس کانال تلگرام سایت بیگ دیتا:

t.me/bigdata_channel

آدرس کانال سروش ما:
https://sapp.ir/bigdata_channel

جهت دیدن سرفصل های دوره های آموزشی بر روی اینجا کلیک کنید.

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *