بیوگرافی xmlrpc php. مسابقات برنامه نویسی مسدود کردن XML RPC
مقدمه ای بر XML-RPC
منابع مختلف زیادی در اینترنت وجود دارد که اطلاعات خاصی را در اختیار کاربران قرار می دهد. این به معنای صفحات ثابت معمولی نیست، بلکه به عنوان مثال، داده های بازیابی شده از یک پایگاه داده یا آرشیو است. این می‌تواند آرشیو داده‌های مالی (نرخ مبادلات، داده‌های مظنه اوراق بهادار)، داده‌های آب‌وهوا یا اطلاعات حجیم‌تر - اخبار، مقالات، پیام‌های انجمن‌ها باشد. چنین اطلاعاتی می تواند به بازدیدکننده صفحه مثلاً از طریق یک فرم به عنوان پاسخ به یک درخواست ارائه شود یا هر بار به صورت پویا تولید شود. اما مشکل این است که اغلب چنین اطلاعاتی نه چندان مورد نیاز کاربر نهایی - یک شخص، بلکه توسط سایر سیستم ها و برنامه هایی است که از این داده ها برای محاسبات یا سایر نیازهای خود استفاده می کنند.
مثال واقعی: صفحه ای از یک وب سایت بانکی که مظنه ارز را نمایش می دهد. اگر به عنوان یک کاربر معمولی به صفحه دسترسی داشته باشید، از طریق یک مرورگر، تمام طراحی صفحه، بنرها، منوها و سایر اطلاعاتی را می بینید که هدف واقعی جستجو - مظنه ارز - را "قاب می کند". اگر می‌خواهید این قیمت‌ها را در فروشگاه آنلاین خود وارد کنید، کار دیگری جز انتخاب دستی داده‌های لازم و انتقال آن به وب‌سایت خود از طریق کلیپ بورد باقی نمی‌ماند. و شما باید هر روز این کار را انجام دهید. آیا واقعاً هیچ راهی وجود ندارد؟
اگر مشکل را مستقیماً حل کنید، بلافاصله یک راه حل ایجاد می شود: یک برنامه (اسکریپت در یک وب سایت) که به داده نیاز دارد، صفحه ای را از سرور به عنوان "کاربر عادی" دریافت می کند، کد html حاصل را تجزیه (تجزیه می کند) و استخراج می کند. اطلاعات لازم از آن این را می توان با یک عبارت منظم یا با استفاده از هر تجزیه کننده html انجام داد. دشواری رویکرد در ناکارآمدی آن است. در مرحله اول، برای دریافت بخش کوچکی از داده ها (داده های ارزها به معنای واقعی کلمه یک دوجین یا دو کاراکتر است)، باید کل صفحه را دریافت کنید که حداقل چند ده کیلوبایت است. ثانیاً با هر تغییری در کد صفحه، مثلاً طرح تغییر کرده یا چیز دیگری، الگوریتم تجزیه ما باید دوباره انجام شود. و این به مقدار مناسبی از منابع نیاز دارد.
بنابراین، توسعه دهندگان تصمیم گرفتند - لازم است نوعی مکانیسم جهانی ایجاد شود که اجازه دهد شفاف (در سطح پروتکل و رسانه انتقال) و تبادل آسان داده ها بین برنامه هایی که می توانند در هر نقطه قرار گیرند، به هر زبانی نوشته شوند. و تحت هر سیستم عامل و بر روی هر پلت فرم سخت افزاری اجرا شود. اکنون چنین مکانیزمی با اصطلاحات پر سر و صدا "سرویس های وب"، "SOAP"، "معماری سرویس گرا" نامیده می شود. برای تبادل داده، از استانداردهای باز و تست شده با زمان استفاده می شود - پروتکل HTTP برای انتقال پیام ها استفاده می شود (اگرچه می توان از پروتکل های دیگری استفاده کرد - برای مثال SMTP). خود داده ها (در مثال ما، نرخ های مبادله) به صورت بسته بندی شده در قالب کراس پلتفرم - در قالب اسناد XML منتقل می شود. برای این منظور، استاندارد خاصی اختراع شد - SOAP.
بله، اکنون خدمات وب، SOAP و XML بر لبان همه است، آنها شروع به پیاده سازی فعال کرده اند، و شرکت های بزرگی مانند IBM و مایکروسافت محصولات جدیدی را منتشر می کنند که برای کمک به اجرای کلی خدمات وب طراحی شده اند.
ولی! برای مثال ما با نرخ ارز که باید از وب سایت بانک به موتور فروشگاه آنلاین منتقل شود، چنین راه حلی بسیار دشوار خواهد بود. از این گذشته، شرح استاندارد SOAP به تنهایی یک و نیم هزار صفحه زشت را به خود اختصاص می دهد و این تمام نیست. برای استفاده عملی، همچنین باید یاد بگیرید که چگونه با کتابخانه‌ها و برنامه‌های افزودنی شخص ثالث کار کنید (فقط از PHP 5.0 شروع می‌شود و شامل کتابخانه‌ای برای کار با SOAP می‌شود)، و صدها و هزاران خط از کد خود را بنویسید. و همه اینها برای به دست آوردن چند حرف و اعداد واضح است که بسیار دست و پا گیر و غیر منطقی است.
بنابراین، می توان گفت استاندارد دیگری برای تبادل اطلاعات وجود دارد - XML-RPC. این نرم افزار با مشارکت مایکروسافت توسط UserLand Software Inc توسعه یافته است و برای انتقال یکپارچه داده بین برنامه ها از طریق اینترنت طراحی شده است. می‌تواند جایگزین SOAP در هنگام ساخت سرویس‌های ساده شود که در آن به تمام قابلیت‌های سازمانی سرویس‌های وب واقعی نیازی نیست.
مخفف XML-RPC به چه معناست؟ RPC مخفف Remote Procedure Call است. این بدان معنی است که یک برنامه (چه یک اسکریپت روی سرور یا یک برنامه معمولی در رایانه مشتری) می تواند به طور شفاف از روشی استفاده کند که به صورت فیزیکی بر روی رایانه دیگری اجرا و اجرا می شود. XML در اینجا برای ارائه یک قالب جهانی برای توصیف داده های ارسال شده استفاده می شود. به عنوان یک حمل و نقل، پروتکل HTTP برای انتقال پیام ها استفاده می شود، که به شما امکان می دهد داده ها را از طریق هر دستگاه شبکه - روترها، فایروال ها، سرورهای پروکسی به طور یکپارچه مبادله کنید.
بنابراین، برای استفاده باید این موارد را داشته باشید: یک سرور XML-RPC که یک یا چند روش را ارائه می دهد، یک سرویس گیرنده XML-RPC که می تواند یک درخواست صحیح ایجاد کند و پاسخ سرور را پردازش کند، و همچنین پارامترهای سرور لازم برای عملکرد موفقیت آمیز را بداند - آدرس، نام روش و پارامترهای ارسال شده
تمام کار با XML-RPC در حالت "درخواست پاسخ" رخ می دهد، این یکی از تفاوت های بین فناوری و استاندارد SOAP است، جایی که هم مفاهیم تراکنش ها و هم توانایی برقراری تماس های تاخیری (زمانی که سرور ذخیره می کند) وجود دارد. درخواست و در زمان معینی در آینده به آن پاسخ می دهد). این ویژگی‌های اضافی برای سرویس‌های قدرتمند شرکتی مفیدتر هستند.
روند کار با XML-RPC با تشکیل یک درخواست شروع می شود. یک درخواست معمولی به این صورت است:
POST /RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
میزبان: server.localnet.com
نوع محتوا: text/xml
طول مطلب: 172
خطوط اول هدر استاندارد درخواست HTTP POST را تشکیل می دهند. پارامترهای مورد نیاز شامل میزبان، نوع داده (نوع MIME) که باید متن/xml و طول پیام باشد. این استاندارد همچنین مشخص می کند که قسمت User-Agent باید پر شود، اما می تواند حاوی یک مقدار دلخواه باشد.
سپس هدر معمولی سند XML می آید. عنصر ریشه درخواست است
خط
بعد، پارامترهای ارسال شده تنظیم می شوند. این بخش برای این کار استفاده می شود.
توضیحات همه پارامترها با بستن برچسب ها دنبال می شود. درخواست و پاسخ در XML-RPC اسناد XML معمولی هستند، بنابراین همه برچسب ها باید بسته شوند. اما هیچ برچسب واحدی در XML-RPC وجود ندارد، اگرچه در استاندارد XML وجود دارد.
حالا بیایید به پاسخ سرور نگاه کنیم. هدر پاسخ HTTP عادی است اگر درخواست با موفقیت پردازش شود، سرور یک پاسخ HTTP/1.1 200 OK را برمی‌گرداند. همانطور که در درخواست، شما باید به درستی نوع MIME، طول پیام و تاریخ تولید پاسخ را مشخص کنید.
خود بدنه پاسخ به شرح زیر است:
حالا به جای تگ ریشه
اگر هنگام پردازش درخواست شما خطایی رخ داد، به جای پاسخ حاوی عنصر خواهد بود
حال بیایید نگاهی کوتاه به انواع داده در XML-RPC بیندازیم. در کل 9 نوع داده وجود دارد - هفت نوع ساده و 2 نوع پیچیده. هر نوع با برچسب یا مجموعه ای از برچسب ها (برای انواع پیچیده) توصیف می شود.
انواع ساده:
تمام اعداد- برچسب
نوع بولی- برچسب
رشته ASCII- توصیف شده توسط برچسب
اعداد اعشاری- برچسب
تاریخ و زمان- توصیف شده توسط برچسب
آخرین نوع ساده این است رشته کد شده base64، که توسط برچسب توضیح داده شده است
انواع پیچیده با ساختارها و آرایه ها نشان داده می شوند. ساختار توسط عنصر ریشه تعیین می شود
آرایه ها نامی ندارند و با تگ توصیف می شوند
البته، کسی خواهد گفت که چنین لیستی از انواع داده ها بسیار ضعیف است و "به شما اجازه نمی دهد که گسترش دهید." بله، اگر نیاز به انتقال اشیاء پیچیده یا مقادیر زیادی داده دارید، بهتر است از SOAP استفاده کنید. و برای برنامه های کوچک و بی نیاز، XML-RPC کاملاً مناسب است، علاوه بر این، اغلب حتی توانایی های آن بسیار زیاد است. با توجه به سهولت استقرار، تعداد بسیار زیادی کتابخانه برای تقریباً هر زبان و پلتفرم و پشتیبانی گسترده در PHP، XML-RPC اغلب به سادگی هیچ رقیبی ندارد. اگرچه نمی توان بلافاصله به عنوان یک راه حل جهانی توصیه کرد - در هر مورد خاص باید با توجه به شرایط تصمیم گیری شود.
چند روز پیش متوجه شدم که بار سایت های من در هاست به میزان قابل توجهی افزایش یافته است. اگر معمولاً حدود 100-120 "طوطی" (CP) بود، در چند روز گذشته به 400-500 CP افزایش یافته است. هیچ چیز خوبی در این مورد وجود ندارد، زیرا میزبان می تواند به تعرفه های گران تر یا حتی دسترسی کامل به سایت ها را ببندد، بنابراین من شروع به بررسی آن کردم.
اما من روشی را انتخاب کردم که عملکرد XML-RPC را حفظ کند: نصب افزونه غیرفعال کردن XML-RPC Pingback. فقط روش‌های خطرناک pingback.ping و pingback.extensions.getPingbacks را حذف می‌کند و عملکرد XML-RPC را باقی می‌گذارد. پس از نصب، افزونه فقط باید فعال شود - نیازی به پیکربندی بیشتر نیست.
در طول مسیر، من تمام IP های مهاجمان را در فایل htaccess سایت هایم وارد کردم تا دسترسی آنها را مسدود کنم. من همین الان به انتهای فایل اضافه کردم:
Order Allow, Deny Allow from all Deny from 5.196.5.116 37.59.120.214 92.222.35.159
این همه است، اکنون ما با استفاده از xmlrpc.php از وبلاگ در برابر حملات بیشتر محافظت کرده ایم. سایت های ما بارگیری هاست با درخواست ها و همچنین حملات DDoS به سایت های شخص ثالث را متوقف کردند.
- پشتیبانی از ایجاد مشتری و سرور xmlrpc
- رمزگذاری و رمزگشایی و رمزگشایی کاملاً خودکار یا کاملاً دستی از مقادیر php به xmlrpc
- پشتیبانی از کدهای UTF8، Latin-1 و ASCII. با فعال کردن پسوند php mbstring، مجموعه کاراکترهای بیشتری نیز پشتیبانی می‌شوند.
- پشتیبانی از فشرده سازی http از هر دو درخواست و پاسخ، کوکی ها، پروکسی ها، احراز هویت اولیه و https، ntlm auth و keepalives با پسوند php cURL
- اعتبار سنجی اختیاری انواع پارامتر درخواست xmlrpc ورودی
- پشتیبانی از روش های system.listMethods، system.methodHelp، system.multicall و system.getCapabilities
- پشتیبانی از
و - امکان ثبت تابع php یا متدهای کلاس موجود به عنوان وب سرویس، استخراج اطلاعات ارزش افزوده از نظرات phpdoc
- یک دیباگر بصری مبتنی بر وب همراه با کتابخانه گنجانده شده است
الزامات
- PHP 5.3.0 یا بالاتر. 5.5 یا بالاتر توصیه می شود
- اگر می خواهید از SSL یا HTTP 1.1 برای برقراری ارتباط با سرورهای راه دور استفاده کنید، پسوند php "curl" مورد نیاز است.
- پسوند php "mbstring" برای اجازه دادن به دریافت درخواست ها/پاسخ ها در مجموعه های کاراکتری غیر از ASCII، Latin-1، UTF-8 مورد نیاز است.
- پسوند بومی php "xmlrpc" مورد نیاز نیست، اما در صورت نصب، هیچ تداخلی در عملکرد این کتابخانه وجود نخواهد داشت.
دانلود
اخبار
- 1 جولای 2017
نسخه های lib 4.2.0 و 3.1.0 منتشر شد.
یادداشت های انتشار در Github در دسترس هستند - 20 ژانویه 2016
نسخه lib 4.0.0 منتشر شد.
این اولین بار است - تا کنون - که API تغییرات عمده ای را مشاهده می کند و گذشته را از بین می برد و گذار به php مدرن را آغاز می کند.
فضاهای نام معرفی شده اند و نویسه های پیش فرض در صورت استفاده از UTF-8. پشتیبانی از mbstring و موارد دیگر اضافه شده است.
برای لیست کامل تغییرات، به Github بروید - 19 آوریل 2015
نسخه lib 3.0.1 منتشر شد. - 15 ژوئن 2014
نسخه lib 3.0.0 منتشر شد. - 15 دسامبر 2013
پروژه به GitHub منتقل شددیباگر آنلاین xmlrpc
یک برنامه دیباگر xmlrpc که در بالای این کتابخانه ساخته شده است، در آدرس http://gggeek.altervista.org/sw/xmlrpc/debugger/ فعال است. می توانید از دیباگر برای مثال استفاده کنید. سرور نسخه ی نمایشی SF را پرس و جو کنید، یا سرور xmlrpc شخصی خود را اشکال زدایی کنید، اگر در شبکه قابل دسترسی است.
توسعه
شرح وضعیت - به روز شده در 2009/07/26 اسناد را برای همه ویژگی‌های اضافه شده از نسخه 2 به‌روزرسانی کنید کم کم در حال پیشرفت... امکان انتخاب قالب بندی پیام های xml را اضافه کنید مشابه کاری که پسوند php native xmlrpc انجام می دهد رفع اخطارهای صادر شده هنگام اجرا با PHP 5 در حالت STRICT ممکن است قبلاً در نسخه 3.0 انجام شده باشد و php 4 compat را رها کنید... برای بهره گیری از مدیریت استثنا و برگرداندن پاسخ های خطای xmlrpc، تابع خودکار php را به wrapper متد xmlrpc گسترش دهید. گسترش مولد خودکار خرد برای تبدیل خودکار توابع php به متدهای xmlrpc برای PHP<= 5.0.2 به کد AMFPHP در مورد نحوه انجام آن نگاه کنید.
بسیاری از پیشرفت ها در نسخه 2.1
اکنون که سرور می تواند به طور خودکار توابع php را ثبت کند، نیاز کمتری به آن وجود دارد.پشتیبانی بهتر از mbstring زمانی که فعال باشد باید به عنوان مثال رمزگذاری مجموعه حروف با حدس زدن سریعتر پشتیبانی از کوکی های "نسخه 1" را بهبود بخشید امکان استفاده به جای کدهای خطای بومی را اضافه کنید سازگاری PEAR: اضافه کردن مترادف برای توابع موجود با نام های مختلف در نسخه PEAR از lib پشتیبانی از پسوند xmlrpc را اضافه کنید قابلیت راه‌اندازی مجموعه کاملی از تست‌های validator1 را به دیباگر اضافه کنید بررسی قابلیت استفاده از WSDL برای توصیف خدمات در معرض نمایش و ترجمه به/از system.methodSignature و system.describeMethods برخی مشکلات در استفاده از XSD برای تعریف دقیق xmlrpc وجود دارد. Relax NG قطعاً جایگزین بهتری است، اما در ابزارهای دیگر پشتیبانی کمی برای استفاده از آن در ارتباط با یک فایل WSDL وجود دارد. پشتیبانی از تغییر مسیرهای http (302) یک پایگاه داده کوچک به sf.net اضافه کنید تا بتوانیم یک صفحه اعتبار سنجی که کاربران ورودی را ثبت می کند، مانند آنچه در سایت xmlrpc.com وجود دارد، پیاده سازی کنیم. قابلیت آپلود نتایج در sf.net را به مجموعه معیار اضافه کنید یک پسوند php بنویسید که پرکاربردترین توابع lib را تسریع کند برای مثال ببینید adodb چگونه این کار را انجام داد افزایش سرعت/حافظه را با استفاده از simplexml و relaxng به جای تجزیه دستی xml آزمایش کنید امنیت
سومین نقض امنیتی: اوت 2005
این یک پاسخ بیشتر و پیشگیرانه به دومین نقض امنیتی زیر بود. تمام استفاده از eval() حذف شده است زیرا هنوز یک سوء استفاده بالقوه بود.
زمانی که کتابخانه در ابتدا نوشته شد، نسخه‌های php موجود در آن زمان شامل call_user_func() و همکاران نمی‌شد. بنابراین در آن محدودیت ها نوشته شد که از eval() در دو تابع فراخوانی شده توسط تجزیه کننده xml استفاده شود. با توجه به این استفاده، کلاس سرور نیز از eval() استفاده می کرد زیرا باید xml را با استفاده از همان توابع تجزیه می کرد.
این توابع کنترل کننده و آرایه مورد استفاده برای حفظ محتوای پیام اصلی، برای ساخت مقادیر php به جای ساخت کد php برای ارزیابی، بازنویسی شده اند. این باید هرگونه پتانسیل برای اجرای کد را حذف کند.
دومین نقض امنیتی: جولای 2005
آسیب‌پذیری امنیتی که جیمز برسگی از تحقیقات امنیتی GulfTech در 27 ژوئن 2005 کشف کرد، سر و صدای زیادی به پا کرد. آن را به صفحه اول Salshdot رسانده است، در Netcraft، LWN و بسیاری از سایت های دیگر ذکر شده است.
دستورالعمل های دقیق در مورد ساخت کد اکسپلویت در اینترنت منتشر شده است و بسیاری از مدیران میزبانی وب در این فکر مانده اند که بهترین طرح دفاعی چیست و خطرات واقعی آن چیست. در اینجا چند پاسخ آورده شده است.
دامنه مشکل
- این اشکال بر دو کتابخانه معروف به PEAR::XMLRPC و PHPXMLRMPC تأثیر می گذارد.
بر اجرای xmlrpc که در php تعبیه شده است و در زمان کامپایل با گزینه "--with-xmlrpc" فعال می شود، تأثیری نمی گذارد (در یونیکس، معمولاً در ویندوز با تغییر خط مناسب در php.ini فعال/غیرفعال می شود. ) - باگ (اجرای کد php تزریق شده توسط هاست های راه دور) منحصراً در فایل وجود دارد xmlrpc.incدر توزیع phpxmlrpc و RPC.phpدر توزیع گلابی
- هر دو PEAR::XMLRPC و PHPXMLRMPC نسخه های به روز شده ای از کتابخانه را منتشر کرده اند که مشکل را برطرف می کند.
- هر دو کتابخانه در تعداد زیادی از برنامه های php استفاده شده اند (لیست ناقص بالا را ببینید).
از آنجایی که کل lib اساساً از 2 فایل بسیار ساده تشکیل شده است، هر کس تمایل دارد آنها را مطابق با سلیقه/نیاز خود وصله کند و هنگام توزیع برنامه خود آنها را بسته بندی کند.
اکثر پروژه‌های پرمخاطب در انتشار نسخه‌های جدید برنامه‌های مربوطه خود بسیار سریع عمل کرده‌اند، اما زمان بیشتری طول می‌کشد تا هر کاربر سیستم خود را به‌روزرسانی کند.
باید گفت که بسیاری از برنامه ها تا همین اواخر با نسخه های بسیار قدیمی کتابخانه phpxmlrpc ارسال می شدند. اولین باگ تزریق در سال 2001 برطرف شدبدون اینکه کسی متوجه شود (...)این امر متأسفانه یافتن راه حل آسان برای این مشکل را برای sysadmin ها بسیار دشوارتر می کند: احتمال زیادی وجود دارد که در سرورهای میزبان عمومی فایل های ذکر شده در فهرست های مختلف و در بسیاری از نسخه های مختلف یافت شوند.
چگونه آسیب پذیری ایجاد می شود
- برای راه‌اندازی باگ، مهاجم باید مقداری xml خاص را در فرآیند ایجاد یک شی xmlrpcval ارزیابی کند. اشیاء Xmlrpcval زمانی ایجاد می شوند که اسکریپت سرور درخواست های xmlrpc را رمزگشایی می کند یا زمانی که برخی از اسکریپت های php به عنوان یک مشتری xmlrpc عمل می کنند و پاسخ ارسال شده توسط سرور را رمزگشایی می کنند.
اسکریپت سرور مخصوص برنامه است و اغلب نام آن server.php است (اما هر گونه پروژه یا کاربر انتخابی امکان پذیر است) و باید شامل هر دو فایل xmlrpc.inc و xmlrpcs.inc (برای نسخه گلابی، سرور) باشد. .php معادل xmlrpcs.inc است). - تنها گنجاندن xmlrpc.inc و xmlrpcs.inc در اسکریپت‌های php کاملاً ایمن است (afaik...) و همچنین فراخوانی مستقیم آنها از طریق درخواست‌های http، زیرا فقط تعریف توابع، متغیرها و کلاس‌ها در آن دو فایل انجام می‌شود. بدون اجرای فوری کد
- فایل‌های server.php و diskut.php که با phpxmlrpc lib کامل توزیع می‌شوند، در واقع یک سرور xmlrpc زنده را پیاده‌سازی می‌کنند، بنابراین ممکن است در نظر داشته باشید که دسترسی به آنها را مسدود کنید یا حتی بهتر آنها را حذف کنید اگر آنها را در سرورهای تولیدی مستقر کردید (در بالای من ذهن من می توانم نوعی حمله را تداعی کنم که شامل یک برنامه php دوم است که از نقض درج فایل php رنج می برد تا آنها را به داخل بکشد + از اشکال شناخته شده lib سوء استفاده کند)
وسیله حفاظت
- تا جایی که می توانید به فرآیند وب سرور خود امتیاز کمتری برای سیستم بدهید. در یونیکس این به طور کلی شامل اجرای Apache به عنوان کاربر هیچکس و/یا در یک محیط جیل روت/کروت شده است. از آنجایی که موتور PHP تحت همان کاربر وب سرور کار می کند، این اولین خط دفاعی است: هر کد php که توسط مهاجم تزریق می شود، به عنوان کاربر دارای حداقل امتیاز روی سرور اجرا می شود، و تمام آسیب هایی که می تواند وارد کند محدود به این خواهد بود. ایجاد اختلال در خود برنامه php
- php را در حالت امن اجرا کنید. اگر یک هاست عمومی هستید و این کار را انجام نمی دهید، به احتمال زیاد سرور شما روت شده است. این امر مانع از استفاده اسکریپت‌های php از هر تابعی می‌شود که شما آن را ناامن می‌دانید، مانند system() یا eval()
- بلوک سخت: تمام فایل های موجود phpxmlrpc (xmlrpc.inc و xmlrpcs.inc) را پیدا کرده و آنها را (chmod 0) در سراسر سیستم غیرفعال کنید.
البته این ممکن است مانع از کارکرد برخی از برنامه های کاربردی کاربر شود، بنابراین باید در زمان انجام آن به کاربران خود اطلاع دهید. - بلوک نرم: همه کپی های فایل های phpxmlrpc موجود (xmlrpc.inc و xmlrpcs.inc) را با نسخه های نسخه 1.1.1 جایگزین کنید.
متأسفانه این روش 100٪ تضمینی برای کارکرد همه برنامه ها نیست. برخی از قسمت های داخلی اشیاء lib از نسخه 0.9 به 1.0 به 1.1 تغییر کردند (به عنوان مثال نمایش هدرهای http ذخیره شده در یک شی xmlrpcresp)، و اگر کدی که روی سرورهای خود مستقر کرده اید آنها را زیر کلاس ها قرار دهد، ممکن است با مشکل مواجه شود. xml ارسال شده از طریق سیم نیز نسبت به برخی از نسخه‌های قدیمی‌تر lib تغییر کرده است (به ویژه: نسخه 1.0.99.2 نویسه‌هایی که خارج از محدوده ASCII به‌عنوان موجودیت‌های html به اشتباه کدگذاری شده‌اند، در حالی که اکنون به عنوان موجودیت‌های مجموعه نویسه‌های xml کدگذاری می‌شوند). چند کد پاسخ خطای جدید نیز اضافه شده است. با این حال، باید 95 درصد از اجرای آن اسکریپت ایمن باشید و منتظر بنشینید تا کاربران شروع به فریاد زدن کنند که چیزی خراب است... - کتابخانه PHP PEAR با دستور یک خطی قابل ارتقا است، بنابراین واقعاً مشکل بزرگی نیست:
گلابی XML_RPC را ارتقا دهید و بگویید که آیا ارتقا یافته است (1.3.1 یا جدیدتر مشکلی ندارد، آخرین نسخه در حال حاضر 1.3.2 است):
لیست گلابی | grep RPC
برخی ملاحظات اضافی
فایل xmlrpcs.inc نیز در نسخه 1.1.1 وصله شده است تا تجربه کاربری بهتری را ارائه دهد. با جزئیات بیشتر: ارسال xml با شکل نادرست خاص به سرور باعث می شود اسکریپت php به جای بازگرداندن یک پاسخ xml مناسب، یک خطای php منتشر کند.
به گفته برخی، این در واقع مستلزم یک "نقض امنیتی افشای مسیر" است (یعنی پیام خطای php نمایش داده شده معمولاً حاوی اطلاعات حساسی در مورد مسیرهای سیستم فایل است)، اما اگر sysadmin سرورهای تولیدی را با آن اجرا کند، هر اسکریپت PHP با مشکل امنیتی مشابه روبرو می شود. دستورالعمل ini display_errors=روشن.
من همچنین می دانم که مکان های زیادی در xmlrpc.inc وجود دارد که فراخوانی یک تابع با یک پارامتر غیرمنتظره باعث ایجاد اخطار یا خطا در php می شود، و من قصد ندارم به این زودی ها بررسی پارامترهای دقیق را برای هر تابع اجرا کنم - اگر برای آن هدف داشته باشید، imho، در وهله اول ممکن است در جاوا کدنویسی کنید.آیا این پایان دنیاست؟
امیدوارم اینطور نباشه.
دلیل آن این است که ده ها برنامه PHP وجود دارد که از سوء استفاده های تزریق کد رنج می برند. فقط نگاهی به مسیر امنیتی تابلوهای اعلانات بیندازید... و با این حال بسیاری از مردم هنوز فکر می کنند PHP انتخاب خوبی برای توسعه وب است.
به یاد داشته باشید: امنیت یک فرآیند است، نه وضعیتی که می توان به آن دست یافت.اولین نقض امنیتی: سپتامبر 2001
من این توصیه را از دن لیبی دریافت کردم. با اجازه او در اینجا تکثیر می شود. توجه داشته باشید که این اکسپلویت در نسخه های 1.01 و بالاتر از XML-RPC برای PHP ثابت شده است. -- Edd Dumbill سه شنبه 24 سپتامبر 2001 ============== حفره امنیتی PHP: سوء استفاده بالقوه XML-RPC =================== ========================= چکیده: با استفاده از آخرین نسخه از کتابخانه php xmlrpc Useful Inc، نسخه 1.0، این امکان برای مهاجم ساختار xml را به گونه ای بسازید که کتابخانه xml-rpc را برای اجرای کد php روی یک وب سرور فریب دهد، من توانستم کدهای دلخواه php را اجرا کنم و با خاموش بودن حالت امن php، دستورات سیستم را اجرا کنم. یک مهاجم به راحتی می تواند از این به عنوان دروازه ای برای راه اندازی ویروس ها استفاده کند. جزئیات: من مشکل را با اصلاح اسکریپت مثال server.php همراه با توزیع xmlrpc و سپس فراخوانی آن از طریق اسکریپت client.php، همچنین بخشی از توزیع، نشان دادم. من کد سرور استاندارد را دور زدم و به سادگی پاسخ‌ها را به کلاینت بازتاب دادم. توانستم کلاینت را وادار کنم تا کد php دلخواه را اجرا کند. سپس نمونه server.php را به حالت اولیه بازگرداندم و از telnet برای ارسال یک کد اصلاح شده استفاده کردم. من همچنین توانستم کد را بر روی سرور اجرا کنم، البته نیاز به یک دستور کمی متفاوت است. از آنجایی که می‌دانستم که کتابخانه xml-rpc از eval برای ساختن ساختارهای داده‌اش از ورودی xml استفاده می‌کند، فقط باید xml ورودی را طوری ساختار داد که: الف) قبل از ارسال به eval فرار نشود. ب) این کار را انجام می‌دهد. عدم ایجاد خطای نحوی php به طور معمول، تمام داده های غیر عددی قبل از ارسال به eval توسط کتابخانه فرار می کنند. با این حال، معلوم می شود که اگر شما یکبرچسب، به دنبال آن یک برچسب غیرمنتظره، مانند ، کد فرار دور زده می شود و داده های "خام" به جای آن ارزیابی می شوند. بهره برداری از مشتری: در اینجا یک پاسخ معمولی xml-rpc وجود دارد: سلام دنیا سلام دنیا
"در سمت مشتری:"، "رشته")؛ اکو " سلام دنیا
"; \$waste = آرایه("سلام دنیا
"; $waste = array("", "string") ممکن است همه چیز بین "string")؛ و \$waste را با کد دلخواه با هر طولی جایگزین کرد. در نهایت، این کدی است که محتویات را چاپ می کند. دایرکتوری فعلی:"، "رشته")؛ اکو " "؛ پژواک "لس ال"؛ اکو "
"؛ خروج؛ \$waste = آرایه("system.listMethods "، "رشته"))؛ اکو " اگر فهرست فهرستی را مشاهده کردید، من فقط php و کد سیستم را از طریق xml-rpc اجرا کردم.
"; echo "اکنون سعی می کنم با استفاده از ls -al:\n فهرست دایرکتوری را ارائه کنم"؛ پژواک "لس ال"؛ اکو " "; echo "من به راحتی می توانستم rm -rf را فراخوانی کنم، یا برنامه ای را روی دیسک بنویسم و آن را اجرا کنم (مثلاً یک ویروس) یا برخی از فایل ها را بخوانم. روز خوبی داشته باشید.
"؛ خروج؛ $waste = آرایه(آرایه(" - این اشکال بر دو کتابخانه معروف به PEAR::XMLRPC و PHPXMLRMPC تأثیر می گذارد.
استفاده از XML-RPC در PHP برای انتشار مطالب در LiveJournal.com (LJ)
ابتدا باید کتابخانه XML-RPC را دانلود کنید. به نظر من موفق ترین نسخه آزادانه از طریق sourceforge " " توزیع شده است: تمام نمونه های زیر برای این کتابخانه، نسخه 2.2 ارائه خواهد شد.
XML-RPC چیست؟ RPC مخفف Remote Procedure Call است، به این معنی که می توان آن را به روسی به عنوان فراخوانی از راه دور با استفاده از XML ترجمه کرد. خود تکنیک فراخوانی روش از راه دور برای مدت طولانی شناخته شده است و در فناوری هایی مانند DCOM، SOAP، CORBA استفاده می شود. RPC برای ساخت برنامه های کاربردی مشتری-سرور توزیع شده طراحی شده است. این امکان ساخت برنامه‌هایی را فراهم می‌کند که در شبکه‌های ناهمگن عمل می‌کنند، به عنوان مثال، روی رایانه‌های سیستم‌های مختلف، برای انجام پردازش داده‌های از راه دور و مدیریت برنامه‌های کاربردی از راه دور. به طور خاص، این پروتکل توسط وب سایت معروف livejournal.com در روسیه استفاده می شود.
بیایید به مثالی نگاه کنیم که چگونه می توانید یک ورودی سیریلیک (و این جایی است که اغلب مشکلات ایجاد می شود) در LiveJournal قرار دهید. در زیر کد کار با نظرات آمده است:
new xmlrpcval($name, "string"), "password" => new xmlrpcval($password, "string"), "event" => new xmlrpcval($text, "string"), "subject" => new xmlrpcval ($subj، "string")، "lineendings" => new xmlrpcval("unix"، "string")، "year" => new xmlrpcval($year، "int")، "mon" => new xmlrpcval( $mon, "int"), "day" => new xmlrpcval($day, "int"), "hour" => new xmlrpcval($hour, "int"), "min" => new xmlrpcval($min , "int"), "ver" => new xmlrpcval(2, "int")); /* یک ساختار بر اساس آرایه ایجاد کنید */ $post2 = array(new xmlrpcval($post, "struct")); /* یک پیام XML برای سرور ایجاد کنید */ $f = new xmlrpcmsg("LJ.XMLRPC.postevent", $post2); /* سرور را توصیف کنید */ $c = new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80); $c->request_charset_encoding = "UTF-8"; /* به صورت اختیاری به کد XML آنچه که به سرور ارسال می شود نگاه کنید */ echo nl2br(htmlentities($f->serialize())); /* یک پیام XML به سرور ارسال کنید */ $r = $c->send($f); /* نتیجه را تجزیه و تحلیل کنید */ if(!$r->faultCode()) ( /* پیام با موفقیت دریافت شد و نتیجه XML برگردانده شد */ $v = php_xmlrpc_decode($r->value()); print_r($v); ) else ( /* سرور یک خطا را برگرداند */ print "یک خطا رخ داد: "؛ چاپ "Code: ".htmlspecialchars($r->faultCode())؛ چاپ "Reason: ".htmlspecialchars($r->faultString ( )).""\n"؛ ) ?>
در این مثال، تنها یک روش LJ.XMLRPC.postevent در نظر گرفته شده است - یک لیست کامل از دستورات ممکن و نحو آنها (به زبان انگلیسی) در دسترس است:
فناوری XML-RPC در سیستم وردپرس برای ویژگی‌های خوب مختلف مانند پینگ بک، ترک بک، مدیریت از راه دور سایت بدون ورود به پنل مدیریت و غیره استفاده می‌شود. متأسفانه، مهاجمان می توانند از آن برای انجام حملات DDoS در وب سایت ها استفاده کنند. یعنی پروژه های زیبا و جالب WP را برای خود یا سفارش ایجاد می کنید و در عین حال بدون اینکه به چیزی شک کنید می توانید بخشی از یک بات نت DDoS باشید. با اتصال ده ها و صدها هزار سایت به یکدیگر، افراد بد یک حمله قدرتمند به قربانی خود ایجاد می کنند. اگرچه در همان زمان سایت شما نیز آسیب می بیند، زیرا ... بار به میزبانی که در آن قرار دارد می رود.
شواهدی از چنین فعالیت بدی می تواند در گزارش های سرور (access.log در nginx) باشد که حاوی خطوط زیر است:
103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"
اما اجازه دهید به آسیب پذیری XML-RPC برگردیم. از نظر بصری، خود را در باز شدن آهسته سایت ها روی سرور شما یا ناتوانی در بارگذاری آنها نشان می دهد (خطای 502 Bad Gateway). پشتیبانی فنی میزبان FASTVPS من حدس های من را تأیید کرد و توصیه کرد:
- وردپرس را به آخرین نسخه به همراه افزونه ها به روز کنید. به طور کلی، اگر دنبال کنید، ممکن است در مورد نیاز به نصب آخرین نسخه 4.2.3 خوانده باشید. به دلیل انتقادات امنیتی (درست مانند نسخه های قبلی). به طور خلاصه، به روز رسانی خوب است.
- افزونه Disable XML-RPC Pingback را نصب کنید.
غیرفعال کردن XML-RPC در وردپرس
قبلاً، به نظر من گزینه فعال/غیرفعال کردن XML-RPC جایی در تنظیمات سیستم بود، اما اکنون نمی توانم آن را در آنجا پیدا کنم. بنابراین، ساده ترین راه برای خلاص شدن از شر آن، استفاده از افزونه مناسب است.
Disable XML-RPC Pingback را پیدا و دانلود کنید یا آن را مستقیماً از پنل مدیریت سیستم نصب کنید. شما نیازی به پیکربندی هیچ چیز اضافی ندارید، ماژول بلافاصله شروع به کار می کند. متدهای pingback.ping و pingback.extensions.getPingbacks را از رابط XML-RPC حذف می کند. علاوه بر این، X-Pingback را از هدرهای HTTP حذف می کند.
در یکی از وبلاگ ها چند گزینه دیگر برای حذف غیرفعال کردن XML-RPC پیدا کردم.
1. XML-RPC را در قالب غیرفعال کنید.
برای انجام این کار، خط زیر را به فایل functions.php تم اضافه کنید:
من شخصا از دو روش آخر استفاده نکردم، زیرا ... من افزونه Disable XML-RPC Pingback را وصل کردم - فکر می کنم کافی باشد. فقط برای کسانی که نصب های غیر ضروری را دوست ندارند، گزینه های جایگزین را پیشنهاد دادم.