در صورت استفاده از استریپچار برای تمیز کردن ورودی کاربر، شما تنها نیستید. بسیاری از توسعهدهندگان به این نوع متکی هستند پاکسازی ورودی برای جلوگیری از تلاشهای تزریق. در نگاه اول، منطقی به نظر میرسد که کاراکترهای خطرناک را حذف کنید و payload ناپدید میشود. با این حال، این رویکرد حس امنیت کاذبی ایجاد میکند. در واقع، مهاجمان میتوانند فیلترهای سادهای مانند استریپچار با استفاده از بارهای داده مبهم، کدگذاریها یا تغییر هوشمندانهی متن. به همین دلیل است که توسعهدهندگان هوشمند به اینجا بسنده نمیکنند. در عوض، آنها از پرسوجوهای پارامتریکه از حملات تزریق در ریشه جلوگیری میکنند.
در این پست، دلیلش را خواهید فهمید استریپچار در سناریوهای دنیای واقعی با شکست مواجه میشود، مهاجمان چگونه از این فیلترها سوءاستفاده میکنند و چه جایگزینهای امنی واقعاً کار میکنند. ما به بررسی نمونههای کد خواهیم پرداخت، تکنیکهای رایج دور زدن فیلتر را نشان خواهیم داد و توضیح خواهیم داد که چگونه پاکسازی ورودی همیشه باید با محافظهای سازهای مانند ... جفت شود. پرسوجوهای پارامترییا آسیبپذیر خواهید ماند.
چی استریپچار واقعاً انجام میدهد (و انجام نمیدهد)
بسیاری از توسعهدهندگان از stripchar یا توابع مشابه برای حذف کاراکترهای ناامن از ورودی کاربر. معمولاً، علائم نگارشی، نمادهای ویژه یا هر چیزی که شامل حروف و اعداد نباشد را حذف میکند. در ابتدا، اینطور به نظر میرسد پاکسازی ورودی، اما این محافظت واقعی نیست.
بیایید آن را تجزیه کنیم. تابعی مانند این:
کاراکترهایی مانند را حذف میکند ', "، یا ;بنابراین، اگر وارد کنید:
تبدیل میشود به:
حتی اگر ورودی کاربر بینقص به نظر برسد، مهاجمان هنوز میتوانند بارهای SQL را تنها با استفاده از منطق تزریق کنند، به خصوص زمانی که برنامه از طریق الحاق رشتهها، کوئریها را میسازد. برای جلوگیری واقعی از تزریق SQL، شما باید از پرسوجوهای پارامتری و مدیریت ورودی آگاه از متن استفاده کنید. فیلترهای کاراکتری مانند stripchar() به سادگی کافی نیستند.
مطمئناً، ورودی حذفشده ممکن است در نگاه اول امنتر به نظر برسد. با این حال، این رویکرد منطق مخرب را خنثی نمیکند، بلکه فقط نحوهی نوشتن آن را تغییر میدهد. در واقع، مهاجمان اغلب با رمزگذاری فایلهای مخرب، قرار دادن فاصلهی خالی یا استفادهی استراتژیک از کاراکترهای حذفشده برای دور زدن کامل فیلتر شما، از این موضوع سوءاستفاده میکنند.
علاوه بر این، استریپچار فاقد زمینهی حیاتی است. نمیداند که آیا ورودی به سمت پایگاه داده، پوسته یا مرورگر میرود. این بدان معناست که نمیتواند escaping یا encoding مناسب را اعمال کند. sanitation کردن ورودی بدون دانستن مقصد مانند escape کردن HTML است در حالی که تهدید واقعی ... SQLi.
در پایان، استریپچار چیزی را تفسیر یا ایمن نمیکند، فقط رشتهها را ویرایش میکند. و ویرایش، امنیت نیست. اگر محافظت واقعی میخواهید، از پرسوجوهای ساختاریافته، اعتبارسنجیشده و پارامتری استفاده کنید. تمام.
برای روشنتر شدن تفاوت، در اینجا نحوه مقایسه stripchar با پرسوجوهای پارامتری در کنار هم آورده شده است:
Stripchar در مقابل پرسوجوهای پارامتری: کدام یک واقعاً از کد شما محافظت میکند؟
| ویژگی | stripchar() | پرس و جوهای پارامتری شده |
|---|---|---|
| سطح حفاظت | پاکسازی رشتهای اولیه. به راحتی با ترفندهای کدگذاری یا منطقی قابل دور زدن است. | محافظت قوی در برابر انواع حملات تزریق SQL. |
| آگاهی از زمینه | نسبت به متن (SQL، HTML، shell و غیره) بیتفاوت است. قانون یکسانی را در همه جا اعمال میکند. | کاملاً آگاه از متن. برای هر محیط از escape مناسب استفاده میکند. |
| تلاش توسعهدهنده | سریع اجرا میشود اما برای استفاده طولانی مدت قابل اعتماد نیست. | نیازمند یکپارچهسازی صحیح، اما مستحکم و مقاوم در برابر تغییرات آینده است. |
| مقاومت بای پس | کم - مهاجمان به راحتی با استفاده از فضای خالی، کدگذاری یا منطق سازگار میشوند. | سطح بالا - کد را از داده جدا میکند و تزریق را به طور قابل اعتمادی مسدود میکند. |
| اطمینان امنیتی | احساس امنیت کاذب - ممکن است مشکل را بدون رفع آن پنهان کند. | صنعت مورد اعتماد standard برای اجرای امن پرس و جو. |
چگونه مهاجمان از ایمنسازی ورودیها عبور میکنند؟
این شکلی است که یک جریان کاری آسیبپذیر معمولی وقتی توسعهدهندگان به آن متکی هستند، به نظر میرسد. استریپچار برای پاکسازی ورودی:
مهاجمان نیازی به شکستن فیلترهای شما ندارند، فقط کافی است دور آنها بگردیدوقتی توسعهدهندگان به ... تکیه میکنند استریپچار برای پاکسازی ورودی، آنها اغلب فرض میکنند که حذف کاراکترهایی مانند نقل قول یا نقطه ویرگول، تلاشهای تزریق را مسدود میکند. با این حال، مهاجمان به سرعت خود را وفق میدهند. آنها [این کار را] به شیوهای ماهرانه انجام میدهند. بارهای داده مبهم که از فیلترهای مبتنی بر regex عبور میکنند، به خصوص زمانی که آن فیلترها فاقد زمینه باشند.
برای مثال، فرض کنید سعی میکنید ورودی را به این صورت پاکسازی کنید:
حتی اگر کاربر نتواند یک اثر کلاسیک ارسال کند ' OR 1=1 --، آنها میتوانند از ترفندهای یونیکد، الحاق رشته یا سینتکس ناقصی که هنوز اجرا میشود، استفاده کنند. بارهای دادهای مانند این اغلب کار میکنند:
و یا:
اگر تابع شما کاراکترهای غیر کلمهای را حذف میکند، ممکن است بازسازی تصادفی یک دستور SQL معتبربدتر از آن، مهاجمان میتوانند مقادیر را به روشهایی رمزگذاری کنند که از فیلتر شما عبور کنند اما توسط سیستم هدف رمزگشایی شوند.
علاوه بر تزریق SQL، استریپچار در زمینههای دیگر نیز با شکست مواجه میشود، مانند دستورات پوسته، مسیرهای فایل یا حتی اجرای جاوا اسکریپت. از آنجایی که فاقد هرگونه آگاهی از محل استفاده ورودی است، نمیتواند escape یا اعتبارسنجی مناسبی را اعمال کند.
به عنوان یک نتیجه، پاکسازی ورودی با استریپچار دور زدن آن آسان است. امنیت واقعی از ... ناشی میشود. کنترلهای آگاه از متن، به خصوص پرسوجوهای پارامتری که به طور کامل از تزریق منطقی جلوگیری میکنند.
چرا باید از پرسوجوهای پارامتری استفاده کنید؟
اگر میخواهید حملات تزریق را واقعاً متوقف کنید، باید ساخت کوئری با رشتهها را متوقف کنید. اونجاست پرسوجوهای پارامتری بیا تو. برخلاف استریپچارفیلتر نمیکنند، آنها جدا کردن کد از داده در سطح موتور.
بیایید دوباره کوئری خراب را بررسی کنیم:
این خطرناک است زیرا ورودی مستقیماً به SQL تزریق میشود. حتی با حذف کاراکتر، شما هنوز در حال ساخت رشتهای هستید که میتواند مورد سوءاستفاده قرار گیرد. در عوض، از یک پرسوجوی پارامتری مانند این استفاده کنید:
در اینجا، درایور پایگاه داده میداند که userInput داده است، کد اجرایی نیستاین به طور خودکار از آن عبور میکند و تزریق را مسدود میکند، حتی اگر ورودی شامل علامت نقل قول، نقطه ویرگول یا کدهای رمزگذاری شده با هگز باشد.
در پایتون:
در PHP با PDO:
در میان همه این مثالها، پرسوجوهای پارامتری بدون نیاز به حدس زدن اینکه کدام کاراکترها ممکن است خطرناک باشند، از تزریق جلوگیری کنید. شما نیازی ندارید استریپچار، شما به ساختار پرسوجوی ساختاریافته و آگاه از متن نیاز دارید.
علاوه بر این، این تکنیک، پیلودهای مبهمسازیشده، ترفندهای یونیکد و دور زدنهای کدگذاری را مسدود میکند، همان الگوهای گریز موجود در آسیبپذیریهای XSSابزارهایی مانند Xygeni این تهدیدها را در مراحل اولیه شناسایی میکنند. SAST تحلیل.
به طور خلاصه، دفاعهای واقعی به فیلترها متکی نیستند. آنها به پروتکلها، APIهای قابل اعتماد و کل متن متکی هستند. اگر از چارچوبها یا تزریق سرویس پویا استفاده میکنید، از نحوه انتشار ورودیها در پایگاه کد خود آگاه باشید. تزریق وابستگی امن تضمین میکند که حتی جریانهای پیچیده نیز سطوح حمله جدیدی را ایجاد نکنند.
تکیه نکن به استریپچاراز Xygeni برای اجرای دفاع واقعی استفاده کنید
حتی اگر استفاده کنید پرسوجوهای پارامتریهیچ تضمینی وجود ندارد که کل کدبیس شما از یک الگو پیروی کند standardمنطق قدیمی، اسکریپتهای شخص ثالث یا خطوط نادیده گرفته شده در یک PR هنوز هم میتوانند خطرات تزریق را ایجاد کنند. این دقیقاً همان جایی است که Xygeni به شما کمک میکند.
Xygeni کد منبع شما را اسکن میکند، pull requestsو CI pipelineبرای گرفتن:
- رشتههای پرسوجو که SQL را با الحاق میسازند
- فیلترهای ضعیف یا خانگی مانند استریپچار
- منطق مشکوکی که با پیلودهای مبهم شناختهشده مطابقت دارد
لازم نیست تک تک خطوط را بررسی کنید. Xygeni الگوهای ناامن را زودتر علامتگذاری میکند و اعمال میکند. رفع خودکار در صورت امکان، و میتواند ادغامهای پرخطر را با قابلیت تنظیم مسدود کند Guardrails.
به طور خلاصه، Xygeni اطمینان حاصل میکند که پرسوجوهای پارامتری فقط یک روش بهینه نیستند، بلکه در مقیاس بزرگ اجرا میشوند. دیگر نیازی به حدس و گمان نیست. هیچ فیلتری از قلم نیفتاده است. فقط محافظت واقعی.f
میخواهید ببینید Xygeni چگونه کوئریهای ناامن را در کد شما پیدا میکند؟
نکات کلیدی: نکاتی که باید به خاطر داشته باشید استریپچار و خطرات تزریق
- استریپچار یک عملکرد امنیتی نیست — این کار شخصیتها را حذف میکند، نه خطر را.
- پاکسازی ورودی کافی نیست وقتی در حال ساخت کوئریهایی با الحاق رشتهای هستید.
- کوئریهای پارامتری، دفاع صحیح هستندو هر زبان یا چارچوب مدرنی از آنها پشتیبانی میکند.
- بارهای داده مبهم میتوانند از فیلترها عبور کنندمخصوصاً اگر ترفندهای کدگذاری در کار باشد.
- تحلیل استاتیک (SASTابزارها آنچه را که انسانها از دست میدهند، میگیرنداز جمله الگوهای ناامن پنهان شده در کد قدیمی.
- Xygeni تشخیص، اولویتبندی و حتی اصلاح را خودکار میکند بنابراین تیم شما میتواند روی نوشتن ویژگیها تمرکز کند، نه اینکه به دنبال آسیبپذیریها باشد.
نتیجهگیری: به فیلترها اعتماد نکنید. طراحی امنی دارند.
تکیه بر توابعی مانند استریپچار ممکن است به نظر یک راه حل سریع برسد، اما حس امنیت کاذبی ایجاد میکند. مهاجمان سریعتر از فیلترهای رشتهای تکامل مییابند. تنها راه قابل اعتماد برای متوقف کردن حملات تزریق، نوشتن کد ایمن از طریق طراحی و اجرای آن طراحی در همه جا است.
ابزارهایی مانند Xygeni به شما کمک میکنند تا این کار را به صورت خودکار انجام دهید. pull request به pipelineآنها آنچه را که فیلترهای شما دریافت نمیکنند، شناسایی میکنند و قبل از رسیدن به مرحله تولید، آن را تعمیر میکنند.
