ورود و ثبت نام

آموزش آسیب پذیری HTTP Parameter Pollution و نحوه اکسپلویت آن

خواندن این مطلب

20 دقیقه

زمان میبرد!

آموزش آسیب پذیری HTTP Parameter Pollution و نحوه اکسپلویت آن

سلام و درود خدمت تمامی دوستان عزیزو گرامی و امیدوارم که روزگار به کامتون باشه:)

در این مقاله قراره راجب به آسیب پذیری Http Parameter Pollution که فارسیشم میشه آلودگی پارامتر یا HPP صحبت کنیم.

 

خب ما ی مفهوم و آسیب پذیری داریم بنام HTTP Parameter Pollution (آلودگی پارامتر http) یا HPP که اینجا مثلا اگر برنامه نویس اومده باشه پارامتر id رو ست کرده باشه waf میاد روی اون پارامتر id برای جلوگیری از تزریق کد مخرب فیلتر و… میزاره و به هکر اجازه نمیده کارشو انجام بده  .. اینجا این آسیب پذیری به ما این امکان رو میده که هکر با اضافه کردن یک پارامتر مشابه به اون url میاد waf رو bypass میکنه چون بصورت پیش فرض waf فقط پارامتر اول رو بررسی میکنه و پروتکل http هم بصورت پیش فرض اگر پارامتر مشابه یا همنام وجود داشته باشه اولویت رو با آخرین پارامتر میزاره مثلا اگر پارامتر id=1 داشته باشیم با id=2 این میاد id=2 رو اولویت میزاره و اون رو اجرا میکنه و در نظر میگیره و بدین سان میتونیم با این روش waf رو دور بزنیم یا bypass کنیم و کوئری خودمون رو تزریق کنیم و… (هم روی متد GET جواب میده و هم متد POST) .. مثال : 

test.com/index.php?id=12

test.com/index.php?id=12&id=2’

test.com/index.php?s=test&s=”>hacked

,…

الان ی مقدمه ای راجب آسیب پذیری HPP داشتیم .. وقتشه بریم یکم عمیق تر شیم و ببنیم دقیقا این آسیب پذیری چیه و چیکار میکنه و اصا چجوری بوجود اومده.

 

 

 

آسیب پذیری HPP یا Http Parameter Pollution 

آلودگی پارامتر HTTP یا HPP زمانی اتفاق می‌افتد که یک وب‌سایت از کاربر ورودی میگیرد و از آن برای ارسال درخواست HTTP به سیستم دیگری (مثلا به سمت وب سرور) بدون اعتبار سنجی روی اون ورودی ، ورودی را ارسال می کند و اشکالات HPP ممکن است هم در سمت کلاینت رخ بده هم سرور .. خب الان در صورتی که یک درخواست با چندین پارامتر http همنام با مقادیر متفاوت به سمت وب سرور ارسال شود ، ممکنه که اون وب سرور به مشکل بخوره  .. که حالا اینجا هکر میاد از این قابلیت سو استفاده میکنه و input validation (اعتبارسنجی ورودی ها) رو bypass میکنه .. همچنین مهاجم میتونه با استفاده از این آسیب پذیری یکسری error ها و خطاهایی هم در اون وب اپلیکیشن ایجاد کنه و این باعث میشه تو جمع آوری اطلاعات از اون تارگت بهمون کمک کنه ینی ارور هایی که مربوط به backend سایت میشن خیلی توی جمع آوری اطلاعات بکارمون میاد مثلا اگر برنامه نویس url رو encode نکرده باشه ، هکر به راحتی میتونه بیاد و پیلود های مخرب خودش رو با استفاده از آسیب پذیری HPP به اون وب سایت تزریق کنه که در ادامه چند مثال راجب این قضیه میزنم و میگم که چجوری میشه با استفاده از این آسیب پذیری WAF یا Web Application Firewall رو bypass میتونیم bypass کنیم.

از اونجایی که Http Parameter Pollution بر کل ساختار فناوری های وب تاثیر گذاره ، یکسری حملاتی هم داره که این حملات هم ی بخشیش سمت سروره (Server Side Attack) و هم ی بخش دیگش مربوط به میشه به کلاینت ینی Client Side Attack .. در سمت کلاینت که مرورگر ماست و میتونیم اثرات تست های خودمون رو مشاهده کنیم و در بسیاری از مواقع آسیب پذیری های hpp بستگی به این داره اون کد ها و پارامتر هایی که هکر به سمت سرور ارسال کرده ، سرور چجوری باهاشون رفتار کنه و هکر چجوری اونارو کنترل کنه ، به همین دلیل پیدا کردن همین باگ هایی ممکنه یکم دشوار  می باشد و نیازه که در کنارش یکسری آسیب پذیری های دیگه هم از سایت گرفته باشیم و تست های امنیتی بیشتری نیز برای پیدا بردن و بهره برداری از این آسیب پذیری نیازه که انجام بدیم.

که در ادامه هم حملات مربوط به سرور و هم کلاینت مورد بررسی قرار میدیم.

در واقع این آسیب پذیری HPP یک قابلیتیه که توی پروتکل http وجود داره و استاندارد هایی که برای پروتکل HTTP هست هم HPP شاملشون نمیشه .. که حالا بدون وجود داشتن استانداردی در این زمینه ، وب اپلیکیشن ها به روش های مختلفی این آسیب پذیری رو مدیریت میکنن.

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

همونطور که در مباحث امنیت رفتار های غیر عادی از یک پلتفرم ضعف امنیتی محسوب میشه این HPP هم به همون شکله.

 

خیلی خب حالا فهمیدیم که این HPP چیه و چیکار میکنه ولی هنوز نفهمیدیم که دقیقا فرق بین HPP سمت client و HTTP سمت server چیه ، پس با من تا آخر این مقاله همراه باشید که قراره با هم بترکونیمو انواع مختلفی از آسیب پذیری های HPP تست کنیم و ببنیم داستانش به چه شکله .. همونطورم که جلوتر خواهید دید ، پیدا کردن آسیب پذیری های HPP نیاز به آزمایش و پشتکار داره اماااا میتونه که ارزش این همه تلاش رو داشته باشه.

پس بریم که بهش بپردازیم.

 

اول از همه بیاین با هم تفاوت بین Client Side HPP و Server Side HPP رو بررسی کنیم .

 

 

 

آلودگی پارامتر http سمت سرور یا Server-Side HPP 

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

از اونجایی که کد های که سمت سرور پردازش میشه رو ما نمیتونیم بصورت عادی بهشون دسترسی داشته باشیم ، برای تست آسیب پذیری HPP سمت سرور باید پارامتر های مختلفی رو تست کنیم تا پارامتر های آسیب پذیر رو پیدا کنیم و در اخر اون رو exploit کنیم.

 

خب الان بریم ی مثال عملی واسه HPP سمت سرور بزنیم تا بهتر این مفهوم رو درک کنید پس به این مثال پیش رو توجه کنید : 

فرض رو بر این بگیرید که وب سایت X یک وب سایت بانکیه و کارش اینه که بیاد پول رو از یجایی به یجایی دیگه انتقال بده .. و برای اینکار اون برنامه نویس اومده توش تعریف کرده که بیا پارامتر های مثلا from و to بهمراه amount رو از کاربر بگیر و عملیات انتقال پول رو انجام بده!

مثلا این آدرس رو براش در نظر بگیرید : 

www.X.com/sendMony.php?from=12345&to=67890&amount=5000

خب الان اینجا برنامه نویس در سمت سرور فرض رو بر این گذاشته که قراره از هر پارامتر فقط ی دونه پارامتر دریافت کنه ولییی بنظرتون اگه ی هکر به شرح زیر بیاد بجای اینکه از هر کدوم از اینا ی دونه پارامتر در نظر بگیره و ارسال کنه بیاد دو تا پارامتر مشابه رو به سمت سرور بفرسته چه اتفاقی میوفته هاان ؟! با من همراه باشید تا بهتون بگم اگه هکر همچین حرکتی بزنه چه اتفاقی میوفته 🙂

www.X.com/sendMony.php?from=12345&to=67890&amount=5000&from=ABCDE

این url از ابتدا به همون شکل مثال اول ساختار یافته است و موردی نداره ، فقط یک پارامتر اضافه رو بهش اضافه کردیم که با توجه به مثالمون یک حساب مبدا (پارامتر from) دیگه رو با یک مقدار دیگر مثلا همون ABCDE ست شده.

در این شرایط، مهاجم پارامتر اضافی را به این امید که برنامه با استفاده از پارامتر اول از اعتبار انتقال را تأیید کند ارسال می‌کند، اما پول از طریق پارامتر دوم برداشت میشود.

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

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

به جای انتقال 5000 دلار از حساب 12345 به 67890، کد سمت سرور از پارامتر دوم استفاده می کند و پول را از حساب ABCDEF به 67890 ارسال می کند.

 

هنگامی که یک سرور چندین پارامتر را با یک نام دریافت می کند، می تواند به روش های مختلفی پاسخ دهد. به عنوان مثال، PHP و Apache از آخرین رخداد استفاده می کنند، Apache Tomcat از اولین رخداد، ASP و IIS از همه رخدادها استفاده می کنند و غیره.

در نتیجه، هیچ فرآیند تضمینی واحدی برای رسیدگی به چندین پارامتر ارسالی با یک نام وجود ندارد، و یافتن آسیب‌پذیری‌های HPP برای تأیید نحوه عملکرد سایتی که آزمایش می‌کنید، به آزمایش نیاز دارد.

 

 

 

رفتار های مختلف در مقابل HPP و پارامتر های همنام توسط وب سرور های مختلف

جدول زیر نشان می‌دهد که فناوری‌های مختلف وب در مقابل چندین پارامتر HTTP یکسان چگونه رفتار می‌کنند.

با توجه به URL و Query String :

  http://example.com/?color=red&color=blue

وب سرور

نحوه رفتار وب سرور با پارامتر

مثال

ASP.NET / IIS

هر چند تا پارامتر همنام را با هم در نظر می گیرد و مقادیر آنها را با (،) از هم جدا می کند.

color=red,blue

ASP / IIS

هر چند تا پارامتر همنام را با هم در نظر می گیرد و مقادیر آنها را با (،) از هم جدا می کند.

color=red,blue

.NET Core 3.1 / Kestrel

هر چند تا پارامتر همنام را با هم در نظر می گیرد و مقادیر آنها را با (،) از هم جدا می کند.

color=red,blue

.NET 5 / Kestrel

هر چند تا پارامتر همنام را با هم در نظر می گیرد و مقادیر آنها را با (،) از هم جدا می کند.

color=red,blue

PHP / Apache

آخرین پارامتر همنام را در نظر می گیرد.

color=blue

PHP / Zeus

آخرین پارامتر همنام را در نظر می گیرد.

color=blue

JSP, Servlet / Apache Tomcat

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

JSP, Servlet / Oracle Application Server 10g

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

JSP, Servlet / Jetty

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

IBM Lotus Domino

فقط آخرین پارامتر همنام را در نظر می گیرد.

color=blue

IBM HTTP Server

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

node.js / express

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

mod_perl, libapreq2 / Apache

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

Perl CGI / Apache

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

mod_wsgi (Python) / Apache

فقط اولین پارامتر همنام را در نظر می گیرد.

color=red

Python / Zope

هر چند تا پارامتر همنام را با هم در نظر می گیرد و مقادیر آنها را داخل یک لیست میگذارد.

color=[‘red’,’blue’]

 

 

این ما بین به ی نکته ی ریزی هم اشاره کنم ، چون خیلیا به این چیزی که میخوام بگم توجهی ندارن .. خب یادتونه بهتون گفتم کد های backend کلا سمت سرور اجرا میشن و خروجیش برای ما برمیگرده ؟! خب معلومه که جوابتون آره هست و یادتونه .. خب الان اینجا ممکنه یکسری parameter ـهایی بصورت get (از طریق url) یا بصورت post (در بدنه ی http) داشته باشیم که برنامه نویس اون پارامتر هارو بصورت مجزا سمت سرور فقط هندلش کرده و ما اون رو نمیتونیم اما پردازش میشه .. مثلا 

x.com/mony.php?from=123&to=456&amount=5400

خب الان مثلا اینجا برنامه نویس اومده پارامتر from رو در دسترس ما گذاشته و میتونیم اونو ببنیم و بعضی وقتا هم مثلا اونو تغییر بدیم اماااا حرفف من اینه که ممکنه برنامه نویس بیاد اون عمل بالارو که from رو در دسترس قرار داده بود به شکل زیر هندلش کنه : 

x.com/mony.php?to=456&amount=5400

میبنید ؟؟ الان پارامتر from در این مثال وجود نداره ، چرا ؟! چون برنامه نویس سمت سرور دور از چشم ما اون رو هندل میکنه و ما حتی فکرشم نمیکنیم که برنامه نویس همچین حرکتی رو زده باشه .. و حالا اگررررر هکرررمون هکر حرفه ای و گانگی باشه میاد به پارامتر ها و url توجه میکنه و میبینه که ی پارامتر to داریم و ی پارامتر amount که قیمت رو مشخص میکنه و با خودش میگه که عههه پس پارامتر from کوو ؟؟ قرار که این پول ار طرف کی ارسال شهه ؟؟ خب الان اینجا هکر عزیزمون میاد پارامتر from رو بر اساس ساختاری که url و پارامتر ما داره حدس میزنه و مقدار from رو تغییر میده و تمام 🙂 و موفق میشه پول رو از یک مبدا دیگه به مقصد مورد نظرش ارسال کنه و یجورای حساب بانکی اون بنده خدا که مبدا هستش رو مورد عنایت قرارر میده به شرححح زیرر : 

x.com/mony.php?to=456&amount=5400&from=7890X

و از اونجایی که ما آسیب پذیریی بنام HPP داریم ، وب سرور میاد آخرین پارامتر از مقادیر مشترک رو در نظر میگیره !! 

خب شما الان شاید بگید تو این مثال ی دونه from که نداریم پس مقادیر مشترک … ؟! باید بگم که همونظور که گفتم هدف از زدن این مثال این بودش که شمارو اولا با حملات و طرز تفکر مختلف آشنا کنم و دوما پارامتر from اول ، سمت سرور توسط برنامه نویس پنهان شده و ما نمیبنیم و بدین سان ما اومدیم اونو حدس زدیمو تمام.

 

حالا که HPP سمت سرور رو بررسی کردیم و فهمیدیم داستانش چیه و غیره .. بریم و client side hpp رو هم مورد بررسی قرار بدیم.

 

 

 

آلودگی پارامتر http سمت کلاینت یا Client-Side HPP 


آسیب‌پذیری‌های HPP سمت کلاینت به مهاجمان این امکان را می‌دهد که پارامترهای اضافی را به URL تزریق کنند تا اثرات مخربی روی کاربر ایجاد کند.

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

در Client Side HPP دیگه میایم خودمون پارامتر تولید می کنیم و این باعث میشه مثلا اون پارامتر تولید شده اعتبار سنجی نشده باشه و… و بدین سان برسیم به آسیب پذیری های سمت کلاینت مثل xss و… ینی بیایم xss تزریق کنیم و این باعث میشه دیگه کلاینت به خطر بیوفته و اینم اسمش بشه client side hpp .

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

به url و کد زیر توجه کنید

http://host/page.php?par=123%26action=edit

➊ <? $val=htmlspecialchars($_GET[‘par’],ENT_QUOTES); ?>

➋ <a href=”/page.php?action=view&par=’.<?=$val?>.'”>View Me!</a>

این کد یک URL جدید بر اساس مقدار par، یک پارامتر وارد شده توسط کاربر ایجاد می کند. در این مثال، مهاجم مقدار 26123%action=edit را به عنوان مقدار par ارسال می کند تا یک پارامتر اضافی و ناخواسته تولید کند. مقدار کدگذاری شده با URL برای & %26 است، به این معنی که وقتی URL تجزیه می شود، %26 به صورت & تفسیر می شود. این مقدار یک پارامتر اضافی به href ایجاد شده اضافه می کند بدون اینکه پارامتر عمل در URL مشخص شود. اگر پارامتر به جای %26 از 123&action=edit استفاده می کرد، & به عنوان جداکننده دو پارامتر مختلف تفسیر می شد، اما چون سایت فقط از پارامتر par در کد خود استفاده می کند، پارامتر اقدام حذف می شود. مقدار %26 با حصول اطمینان از اینکه اقدام در ابتدا به عنوان یک پارامتر جداگانه شناسایی نمی شود، در اطراف این کار عمل می کند، و بنابراین 26123%action=edit به مقدار par تبدیل می شود.

سپس، par (با کدگذاری شدن & به عنوان %26) به تابع htmlspecialchars ➊ ارسال می شود. تابع htmlspecialchars کاراکترهای خاص مانند %26 را به مقادیر کدگذاری شده ی HTML تبدیل می کند و %26 را به &amp; (یک نوع روش encode در html هستش ینی یکسری کاراکتر های خاص در html )، جایی که آن کاراکتر ممکن است معنای خاصی داشته باشد. سپس مقدار تبدیل شده در $val ذخیره می شود. سپس یک پیوند جدید با اضافه کردن $val به مقدار href در ➋ ایجاد می‌شود. بنابراین پیوند ایجاد شده به

 <a href=”/page.php? action=view&par=123&amp;action=edit”> 

تبدیل می‌شود. در نتیجه، مهاجم موفق شده است action=edit اضافی را به URL href اضافه کند و این میتونه منجر به آسیب پذیری شود و بستگی داره به اینکه وب اپلیکیشن چگونه پارامتر اضافه شده توسط هکر را مدیریت می کند.

 

در کل خطر ایجاد شده توسط HPP بستگی به این داره که هکر چجوری اون پارامتر های آلوده رو ارسال کنه و backend یا باطن اون سایت چجوری در مقابل اون تزریق پارامتر های آلوده هکر واکنش نشون بده.

 

خب حالا که با HPP آشنا شدیم و فهمیدیم چی هستو چیکار میکنهو چند نوع هستند و و و !!

وقتشه بریم سراغ مباحث انواع حملات و کارای که میشه با HPP انجام داد بعلاوه روش های بایپس WAF به کمک HPP .

 

 

 

دور زدن اعتبار سنجی و محدودیت ورودی ها و دور زدن WAF به کمک HPP 

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

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

www.example.com/?s=test

خب این url رو در نظر بگیرید که یک پارامتر بنام s با مقدار test داره به سمت سرور ارسال می کند.

حالا مثلا اگه آقای هکر بیاد و بجای این test ی عبارت مخربی تزریق کنه و برنامه نویس هم اومده باشه اون ورودی رو امن کرده باشه و هکر ناکام بمونه ، اینجا الان بنظرتون هکر باید بره و بیخیال شه ؟! معلومه خیییر یکی از شعار های هکری اینه که یک هکر هیچوقت تسلیم نمیشه 🙂 خب حالا بریم تا داشته باشیم :‌ 

www.example.com/?s[]=<script>alert(“hacked”)</script>

خب به url بالا که هکر زده توجه کنید!

همونطور که میبنید هکر اومده به پارامتر s ی دونه [] اضافه کرده!

الان شاید بپرسید این چیه قضیش :\

خب ببینید دوستان عزیز .. بصورت پیشفرض این پارامتر ها بصورت string (رشته) به سمت وب سرور ارسال می شوند و حالا زمانی که ما بیایم [] اضافه کنیم به پارامتر ، اون پارامتر تبدیل به آرایه میشه و الان اینجا برنامه نویس اومده روی پارامتر s که بصورت رشته ای هست فیلتر و محدودیت اعمال کرده و نوع خودش اونو امنش کرده ولی غافل از اینکه هکر جماعت میتونه همچین حرکتایی هم بزنه و این مکانیزم هارو بایپس کنه .. در اینجا مشکلی که برنامه نویس داشته و بهش توجه نکرده این بوده که صرفا اومده ورودی رو sanitize کرده که باید علاوه بر sanitize اون ورودی کلا اون url رو هم sanitize می کرد.

توجه داشته باشید که در بعضی مواقع ما میتونیم با گذاشتن [] در کنار اون پارامتر در سیستم ینی در وب سرور خطا ایجاد کنیم و اگر برنامه نویس نمایش خطای سمت سرور رو غیرفعال نکرده باشه ما میتونیم خطایی که تو سیستم داده رو ببینیم و اطلاعات خوبی رو بدست بیاریم .. ینی اینجوری : 

www.example.com/?s[]=test

خب حالا فرض رو بر این میگیریم که اون وب سرور waf روشه و waf نمیزاره کارمونو انجام بدیم ولی سایت آسیب پذیره!

خب اینجا بنظرتون باید بیخیال بشیم ؟؟ معلومه که ن! اینجاست که ما از hpp برای bypass کردن waf استفاده می کنیم ، به شرح زیر : 

www.example.com/?s[]=test123&s[]=<script>alert(“hacked”)</script>

تموم waf با استفاده از این پیلود بایپس شد ، تبریک میگم 🙂

همونطور که قبلا خدمتتون گفتم وب سرور ها اگر پارامتر مشابهی براشون ارسال شه معمولا آخرین پارامتر رو در نظر میگیرن (در وب سرور های مختلف این رخداد متفاوته) و در اینجا هم به همین شکل .. فرقش با قبلی این بود که اینجا waf به اولین parameter فقط گیر میده و اولین پارامتر رو بررسی میکنه و ما تونستیم با استفاده از این روش waf رو bypass کنیم 🙂

 

همچنین ما میتونیم از payload زیر هم برای bypass waf استفاده کنیم : 

www.example.com/?s=test&s=”><script>alert(“hacked!”)</scritp>

خب ی وقتایی هست که waf کلا به تگ ها (><) حساسه و تگ بازو بسته ببینه جلومونو میگیره و سایت هم آسیب پذیری hpp داره و بعضا آرایه هم بجای رشته قبول میکنه اینجاست که ما از روش زیر برای دور زدن waf استفاده می کنیم : 

www.example.com/?s=<script&s=>alert(`hacked`)</&s=script>

همچنین از این payload هم میتونیم استفاده کنیم : 

www.example.com/?s[]=<script&s[]=>alert(`hacked`)</&s[]=script>

 

بعضیا مواقع اینجوریم میشه :‌ 

www.example.com/?s=<script&s=>alert(`hacked`)</&s=script>

 

و…

در کل باید حالت های مختلفی رو تست کنید.

خلاصه دوستان payload برا اینکارا زیاده و ما فقط بحثمون سر hpp هست .. و من اینجا برای دور زدن فیلتر ورودی ها از مثال های xss استفاده کردم حالا شما میتونید بجای xss از کوئری های sql برای تست sql injection استفاده کنید 🙂

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

 

 

 

دور زدن مکانیزم احراز هویت (Authentication Bypassing) با HPP 

یک آسیب پذیری مهم با HPP در پلتفرم وبلاگنویسی محبوب Blogger کشف شده بود که این باگ به هکر ها اجاره میداد تا با استفاده از درخواست HTTP زیر مالکیت وبلاگ قربانی رو در اختیار بگیرند : 

(https://www.blogger.com/add-authors.do):

POST /add-authors.do HTTP/1.1

[…]

security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=goldshlager19test%40gmail.com(attacker email)&ok=Invite

این مقاله دور زدن مکانیز احراز هویت با hpp هم جالب بود واسم گفتم با شما هم به اشتراک بزارم که فیز ببرید.

 

خب دوستان اینم از مبحث HPP یا Http Parameter Pollution و حملات آن .

من در ادامه روش های patch کردن این آسیب پذیری رو هم خدمتتون عرض می کنم.

 

 

 

روش های جلوگیری از بروز آسیب پذیری HPP و نحوه پچ کردن آن

  • اول از همه تمام ورودی های سایت رو نیازه که برای جلوگیری از کد های مخرب توسط هکر ، فیلتر و محدود بشوند .. مثلا یکی از راه هاش اینه که ورودی هارو بزاریم داخل تابع htmlentities و اونارو انکد کنیم تا اگر هکر کد مخرب چیزی تزریق کرد دیگه ناکام بمونه .. پس اولین را حل شد sanitize کردن ورودی کاربر به شکل مناسب.
  • اطمینان از URL-Encoded شدن ورودی کاربر .. ینی نیازه که url سایت در بخش های مختلف اگر کسی ورودی / پارامتر / عبارت چیزی بهش اضافه کرد اون عبارت urlencode شه.
  • nice کردن url ـها هم بی تاثیر نیست.
  • استفاده از WAF یا Web Application Firewall
  • و…‌!

 

و تمام!…

 

امیدوارم از این مقاله لذت کافی رو برده باشید 🙂

 

درباره نویسنده



نظرات کاربران



دیدگاهتان را بنویسید

مطالب مرتبط