تاپیک جامع آسیب پذیری Sql Injection و انواع حمله

[SafeMaster]

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

بر اساس تجربه شخصی تاکنون 70 % تارگت هایی که برای امنیت نرم افزار های تحت وب خود به پیش ما مراجعه کردند توسط این آسیب پذیری مورد حمله قرار گرفتند وقتی ui طراحی شده و یا اهمیت وبسایت هدف را مشاهده میکنیم حداقل انتظاری که از نرم افزار تحت وب مورد استفاده انتظار میرود رفع آسیب پذیری های حساس مثل همین SQL میباشد ...

با ما همراه باشید :

تزریق SQL: آسیب پذیری ها و پیشگیری از تزریق SQL

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

اگرچه حملات SQLi می تواند آسیب زننده باشد ، اما اگر بدانید چطور آنها را در برنامه نویسی فیلتر کنید ، به راحتی میتوان از آنها جلوگیری کرد. در این پست ، اصول یافتن و خنثی سازی این آسیب پذیری ها را در کد برنامه شما آموزش خواهیم داد.

حمله SQL Injection چیست؟
SQL یا Structured Query Language ، زبان استاندارد برای تعامل با پایگاه های ارتباطی است. در برنامه ها و انواع دیگر برنامه نویسی ، از پایگاه داده برای ذخیره داده های کاربر مانند نام کاربری و رمزهای عبور استفاده می شود. پایگاه های داده همچنین اغلب موثرترین و امن ترین راه حل برای ذخیره انواع دیگر داده ها از پست ها و نظرات وبلاگ عمومی به شماره های حساب بانکی محرمانه هستند.

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

مهاجمان با حمله SQL Injection چه کاری می توانند انجام دهند؟
حملات SQLi از نقاط ضعف کد در نقطه دسترسی به پایگاه داده استفاده می کند. با ربودن این کد ، مهاجمان می توانند به داده های ایمن دسترسی ، اصلاح و حتی حذف کنند.

وقتی حملات SQLi موفقیت آمیز باشد ، مهاجمان می توانند:

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


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

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

مطالعات موردی و پیامدها
حملات SQLi به دلیل سادگی آنها معمول است. آنها می توانند پیامدهای ویرانگری برای شما و کاربران شما به همراه داشته باشند.

در سال 2016 ، افشاگر ناشناس 11.5 میلیون اسناد محرمانه از موساك فونسكا ، یك شركت حقوقی پاناما درز كرد. مهاجمان قادر به سو statements استفاده از عبارات SQL در سیستم مدیریت محتوای شرکت و دیگر معماری شبکه ناامن برای دسترسی به بانک اطلاعاتی شرکت و بارگیری پرونده های محرمانه بودند. انتشار این اسناد نه تنها شرم آور بود ، بلکه پیامدهای حقوقی قابل توجهی نیز برای مشتریان به همراه داشت.

در سال 2009 ، اتباع روسیه و ایالات متحده از حملات SQLi برای دسترسی به 160 میلیون شماره کارت اعتباری از Heartland Payment Systems استفاده کردند که در آن زمان بزرگترین تخلف در اطلاعات مالی بود. مهاجمان شماره کارتهای دزدیده شده را در بازار سیاه فروختند و سایر مجرمان به سرعت اسکناس های صدها میلیون دلاری را تحویل گرفتند و به شرکتها و افراد آسیب رساندند.

حتی MySQL ، ارائه دهنده محبوب SQL ، در سال 2011 از حمله SQLi به وب سایت خود رنج برد که صدها نام کاربری و هش رمز عبور را منتشر کرد. این واقعیت که یک ارائه دهنده SQL می تواند قربانی حملات SQLi شود ، نشان می دهد که هیچ کس در برابر آن ایمنی ندارد و مهاجمان تمام تلاش خود را برای استفاده از کد ناامن انجام خواهند داد.

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

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

جلوگیری از حملات تزریق SQL
علیرغم خطرات قابل توجه حملات SQLi ، جلوگیری از آنها آسان است هنگامی که برخی از بهترین روشهای کدگذاری ایمن را که شامل روشهای اساسی است ، یاد بگیرید:

آسیب پذیری ها را کشف کنید
آسیب پذیری ها را ترمیم کنید
آسیب پذیری ها را برطرف کنید

کاهش تأثیر
تست کلید کشف آسیب پذیری در کد شما است. ابزارهای قوی مانند تجزیه و تحلیل پویا (DAST) را که از خارج به برنامه مانند مهاجم نگاه می کند و ابزارهای تجزیه و تحلیل ایستا (SAST) را که به دنبال آسیب پذیری در سطح کد هستند ، انتخاب کنید. به دنبال مناطقی باشید که برنامه شما به یک پایگاه داده متصل است (مناطق استرینگی که ارتباط با خانه های دیتابیس را برقرار میکنند همانند قسمت عددی انتهای لینک ها و یا ورودی های قابل بررسی توسط دیتابیس ) و سعی کنید مقادیر غیرمعمول را به آن منتقل کنید. به عنوان مثال ، اگر مقداری را وارد کنید که شامل یک ' باشد ، آیا برنامه شما با آن شخصیت به عنوان داده کاربر رفتار می کند یا با آن به عنوان کد رفتار می کند؟ اگر یک تست توتولوژی (مانند OR 1 = 1 ) را در ورودی خود بگنجانید ، آیا می توانید مانند اینکه رمز ورود معتبری وارد کرده اید ، دسترسی پیدا کنید؟

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

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

توسعه دهندگان هوشمند ، توسعه امن
حملات SQLi می تواند عواقب شدیدی را به دنبال داشته باشد ، چنانچه عوامل تهدید کنترل شوند ، از پایین آمدن برنامه یا وب سایت شما تا درز اطلاعات محرمانه مشتریان.

خوشبختانه در برابر حملات SQLi به راحتی محافظت می شود. شما باید به دنبال آسیب پذیری هایی باشید که در آن مهاجمین ممکن است کد SQL خود را تزریق کنند و سپس با استفاده از دستورات آماده شده ، ORMS و سایر استراتژی ها ، این آسیب پذیری ها را ترمیم کنند. اگر عبارات آماده در دسترس نباشند ، می توانید آسیب پذیری ها را با پاک کردن یا فرار از ورودی کاربر قبل از انتقال آن به یک پایگاه داده در یک درخواست SQL ، اصلاح کنید. سرانجام ، تصویب امتیازات دسترسی به پایگاه داده هوشمند می تواند تعداد و شدت حملات SQLi را قبل از اینکه برنامه شما به اجرای نمایش داده شود ، کاهش دهد.

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

ادامه دارد ...

[SafeMaster]

انواع تزریق SQL
تزریق SQL معمولاً تحت سه دسته قرار می گیرد: SQLi درون باند (کلاسیک) ، SQLi استنباطی (Blind) و SQLi خارج از باند. شما می توانید انواع تزریق SQL را بر اساس روشی که برای دسترسی به داده های backend و پتانسیل آسیب آنها استفاده می کنند ، طبقه بندی کنید.

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

SQLi مبتنی بر خطا - مهاجم اقداماتی را انجام می دهد که باعث می شود پایگاه داده پیام های خطا تولید کند. مهاجم می تواند به طور بالقوه از داده های ارائه شده توسط این پیام های خطا برای جمع آوری اطلاعات در مورد ساختار پایگاه داده استفاده کند.
Union-based SQLi - این تکنیک از عملگر UNION SQL بهره می برد ، که چندین عبارت انتخابی تولید شده توسط پایگاه داده را برای دریافت یک پاسخ HTTP واحد درهم می کند. این پاسخ ممکن است حاوی داده هایی باشد که توسط مهاجم قابل استفاده است.

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

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

Boolean - این مهاجم با جستجوی SQL به پایگاه داده ، برنامه را وادار به بازگرداندن نتیجه می کند. بسته به درست یا نادرست بودن جستجو ، نتیجه متفاوت خواهد بود. بر اساس نتیجه ، اطلاعات موجود در پاسخ HTTP اصلاح می شوند یا بدون تغییر می مانند. در صورت ایجاد پیام درست یا نادرست ، مهاجم می تواند کار کند.
مبتنی بر زمان - مهاجم یک کوئری SQL را به پایگاه داده ارسال می کند ، که باعث می شود پایگاه داده صبر کند (برای مدت زمانی در ثانیه) قبل از اینکه واکنش نشان دهد. مهاجم می تواند از زمان پاسخ دادن به پایگاه داده ، درست یا غلط بودن یک پرسش را ببیند. بر اساس نتیجه ، بلافاصله یا پس از یک دوره انتظار پاسخ HTTP ایجاد می شود. بنابراین مهاجم بدون اتکا به داده های پایگاه داده ، می تواند درست یا غلط پیامی را که استفاده کرده اند بازگرداند.
SQLi خارج از باند
مهاجم فقط زمانی می تواند این نوع حمله را انجام دهد که ویژگی های خاصی در سرور پایگاه داده مورد استفاده برنامه وب فعال باشد. این شکل از حمله در درجه اول به عنوان جایگزینی برای تکنیک های SQLi درون باند و استنباطی استفاده می شود.

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

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

به عنوان مثال ، ورودی فوق الذکر ، که اطلاعات مربوط به یک محصول خاص را جلب می کند ، می تواند برای خواندن

http://www.estore.com/items/items.as...999%20or%201=1.

تغییر یابد.

در نتیجه ، جستجوی SQL مربوطه به این شکل است:

SELECT ItemName, ItemDescription
FROM Items
WHERE ItemNumber = 999 OR 1=1

و از آنجا که جمله 1 = 1 همیشه درست است ، کوئری تمام نام ها و توضیحات محصول را در پایگاه داده برمی گرداند ، حتی مواردی که ممکن است برای دسترسی به آنها مجاز نباشید.

مهاجمان همچنین می توانند با استفاده از نویسه های نادرست فیلتر شده دستورات SQL را تغییر دهند ، از جمله با استفاده از نقطه ویرگول برای جدا کردن دو قسمت.

http://www.estore.com/items/iteams.asp?itemid=999;%20DROP

کوئری :

SELECT ItemName, ItemDescription
FROM Items
WHERE ItemNumber = 999; DROP TABLE USERS

در نتیجه ، کل پایگاه داده کاربر می تواند حذف شود.

روش دیگری که می تواند پرس و جوهای SQL را دستکاری کند ، با بیانیه UNION SELECT است. این امر دو بازیگر جستجوگر مرتبط با SELECT را برای بازیابی داده ها از جداول پایگاه داده مختلف ترکیب می کند.

http://www.estore.com/items/items.asp?itemid=999%20UNION%20SELECT%20user-name,%20password%20FROM%20USERS

کوئری :

SELECT ItemName, ItemDescription
FROM Items
WHERE ItemID = '999' UNION SELECT Username, Password FROM Users;

[SafeMaster]

تزریق SQL کور | Blind SQL Injection
شرح
تزریق Blind SQL (Structured Query Language) نوعی حمله SQL Injection است که از پایگاه داده س trueالات درست یا غلط می پرسد و پاسخ را بر اساس پاسخ برنامه ها تعیین می کند. این حمله اغلب هنگامی استفاده می شود که برنامه وب برای نشان دادن پیام های خطای عمومی پیکربندی شده باشد ، اما کدی را که در معرض تزریق SQL قرار دارد کاهش نداده است.

هنگامی که یک مهاجم از تزریق SQL سوits استفاده می کند ، گاهی اوقات برنامه وب پیام های خطایی را از پایگاه داده نشان می دهد که از نادرست بودن نحو SQL Query شکایت دارند. تزریق SQL کور تقریباً مشابه تزریق SQL طبیعی است ، تنها تفاوت در نحوه بازیابی اطلاعات از پایگاه داده است. هنگامی که پایگاه داده داده ها را به صفحه وب منتقل نمی کند ، مهاجم مجبور می شود با پرسیدن یک سری سوالات درست یا غلط از پایگاه داده ، داده ها را بدزدد. این مسئله بهره گیری از آسیب پذیری SQL Injection را دشوارتر می کند ، اما غیرممکن نیست. .

مدل سازی تهدید
همان تزریق SQL

عوامل خطر
همان تزریق SQL

مثال ها
یک مهاجم ممکن است به درستی یا نادرست بودن درخواست ارسالی را بررسی کند:

Example URL:

http://newspaper.com/items.php?id=2

کوئری زیر را به پایگاه داده ارسال می کند:

SELECT title, description, body FROM items WHERE ID = 2
سپس مهاجم ممکن است سعی کند کوئری را بازگرداند که تزریق می کند
‘false’:

http://newspaper.com/items.php?id=2 and 1=2
اکنون درخواست SQL باید به این شکل باشد:

SELECT title, description, body FROM items WHERE ID = 2 and 1=2

اگر برنامه وب در برابر SQL Injection آسیب پذیر باشد ، پس احتمالاً هیچ چیزی بر نمی گرداند. برای اطمینان ، مهاجم سوالی را تزریق می کند که «درست» برمی گردد:

http://newspaper.com/items.php?id=2%20and%201%20=%201

اگر محتوای صفحه ای که "true" برمی گرداند متفاوت از صفحه ای است که "false" را باز می گرداند ، مهاجم قادر به تشخیص درست یا نادرست بودن پرسش اجرا شده است.

هنگامی که این مورد تأیید شد ، تنها محدودیت هایی است که توسط مدیر پایگاه داده تنظیم شده است ، نحو مختلف SQL و تخیل مهاجم.

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

اگر اولین حرف از نام پایگاه داده "A" است ، 10 ثانیه صبر کنید.

اگر اولین حرف از نام پایگاه داده اول "B" است ، 10 ثانیه صبر کنید.



ادامه دارد ...

[SafeMaster]

درود عزیزان در این بخش به شما نحوه بای پس دیوار آتش در حملات Sql injection را توضیح میدهیم :

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

https://www.muetkhp.edu.pk/home/news.php?news_id=8
bug
https://www.muetkhp.edu.pk/home/news.php?news_id=8'

مرحله دوم پیدا کردن ستون های آسیب پذیر دیتابیس :

با دستور order by این مقدار را مابین 1 تا 6 بررسی کردیم و پس از مقدار 6 خطا دریافت کردیم بنا براین تعداد ستون دیتابیس مقدار 6 میباشد :

https://www.muetkhp.edu.pk/home/news.php?news_id=8+order+by+6

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

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


مرحله چهارم بدست آوردن لیست جدول های دیتابیس (به علت داشتن فایروال ما تعداد ستون های جداول را از طریق دستور limit بصورت تک تک پیدا میکنیم).





جدول users شناسایی شد حال باید عنوان ستون های جدول users را از قبیل user,password,id پیدا کنیم تا اطلاعات مدیر را از آن بکشیم بیرون این مرحله به علت اختلاف در زبان های مختلف باید انجام پذیرد به طور مثال شاید بجای user , pass از کلمه namkarbari , ramz توسط عنوان ستون استفاده شده باشد .

مرحله پنجم

در این مرحله برای اینکه اطلاعات عنوانی جدول users را بدست بیاوریم آن را به مقدار هکس و یا char code تبدیل میکنیم تا دیتابیس بتواند خروجی مناسب ما را چاپ کند :
در این مرحله نیز با دستور limit بصورت تک تک برای بای پس دیتابیس عناوین ستون users را بدست میآوریم :
Limit 1,1
Limit 2,1
Limit 3,1
Limit 4,1

user_id
username
user_email
user_password
user_privileges

مرحله ششم استخراج یوزر و پسورد در یکی از ستون ها یوزر و دیگری پسورد درخواست شده است .





همانطور که مشاهده میکنید یوزر و پسورد با موفیقت بدست آمد و دیوار آتش بای پس شد .

موفق باشید .

[SafeMaster]

بای پس صفحات ورود با استفاده از آسیب پذیری SQL INjection | تزریق SQL
تزریق SQL روشی است که با استفاده از تزریق دستورات SQL به عنوان دستورات ، از داده های کاربر از طریق ورودی صفحه وب بهره برداری می شود. اساساً می توان از این دستورات برای دستکاری وب سرور برنامه توسط کاربران مخرب استفاده کرد.

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

ساده ترین راه این است که "‘ " را در قسمت نام کاربری یا رمز عبور وارد کنید. اگر سرور هر نوع خطای SQL را در Response بازگرداند ، وب سایت احتمالاً در معرض حمله SQL Injection است. در نظر داشته باشید برخی مواقع سرور پیغام ای خطا را نشان نمیدهد و باید در هر دو صورت تارگت را تست نمائید .

دور زدن احراز هویت:

1. بعد از تأیید اینکه سایت در معرض تزریق SQL قرار دارد ، مرحله بعدی تایپ کردن (ورودی) مناسب در قسمت رمز عبور یا نام کاربری برای دسترسی به حساب است.

2. دستور زیر را در قسمت آسیب پذیر وارد کنید و منجر به یک ورود با احراز هویت موفقیت آمیز می شود.

Select
id from users
where
username = ’  username  ’ 
and  password =  ’ password ’
 or 1 = 1 - - +

در دستور بالا:

از آنجا که 1 = 1 همیشه درست است ، و ما 1 = 1 را با یک عملگر OR ترکیب کردیم ، اکنون نیازی نیست که نام کاربری یا رمز عبور را بدانیم زیرا هر نام کاربری ، رمز عبور ، 1 = 1 ما همیشه درست است بنابراین به ما امکان دسترسی به حساب را می دهد .
‘یا 1 = 1 - + (در قسمت رمز عبور)‘ قبل از اینکه دستور OR برای خاتمه دادن به نقل قول های منفرد رمز عبور استفاده شود (به عنوان مثال - شناسه را از کاربرانی که نام کاربری = "نام کاربری" و رمز عبور "رمز عبور")
به این ترتیب که بعد از اینکه "قبل از عملگر OR" را وارد کردیم ، به دستور SQL ما تبدیل می شود و برای چشم پوشی از بقیه دستورات استفاده می شود. کاربرد اصلی آن نادیده گرفتن ‘بعد از گذرواژه است و در صورت عدم استفاده از آن ، با خطای زیر مواجه خواهیم شد. اگر بخواهیم خلاصه تر توضیح دهیم یک شرط را برای ورود و بررسی پسورد در دیتابیس در نظر بگیرید ما با 1 = 1 تمامی شروط را دور زده و مقدار خود را جایگزین مینماییم که بدین صورت میتوان ورود موفقیت آمیز داشته باشیم .
بیایید پی لود را در پورتال ورود به سیستم امتحان کنیم (بدون نوشتن - + در انتهای پی لود)

یعنی اگر از - + استفاده نکنیم ، دستور sql ما این خواهد بود: شناسه را از کاربران انتخاب کنید که نام کاربری = "نام کاربری" و رمز عبور = "یا 1 = 1"
چرا ... در پایان 1؟

این کلمه عبور است که یک نقل قول را بسته می کند. به یاد داشته باشید که ما قبلاً یک کلمه رمز عبور خود را ارائه داده ایم. اما دستور SQL وب سایت ها فقط ‘را در انتهای رمز عبور ما قرار می دهد. (یعنی - هرچه در قسمت رمز عبور می نویسیم ، در داخل "" رمز عبور ذخیره می شود فرض کنید ، رمز عبور ما hello است دستور SQL مربوط به این خواهد بود: از بین کاربران ، شناسه را انتخاب کنید که نام کاربری = "نام کاربری" و رمز عبور "hello" در اینجا ، ما نقل قول ها را اضافه نکردیم ، اما دستور SQL نقل قول ها را در قسمت ورودی ما اضافه کرد). از آنجا که دستور SQL ‘را در پایان 1 = 1 ما قرار می دهد ، ماموریت ما با شکست مواجه می شود. بنابراین ، برای نادیده گرفتن این نقل قول بسته شدن رمز عبور ، از + - استفاده می کنیم.

اجرای تزریق:

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

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

توجه: گاهی اوقات ، برخی از وب سایت ها - + را مسدود می کنند ، در چنین مواردی از # استفاده می شود. هر دو کار یکسانی را انجام می دهند.

اگر در هنگام لاگین از شما ایمیل خواست در انتهای پیلود @gmail.com اضافه کنید .


گاهی اوقات نیز برنامه نویس دستورات را فیلتر میکند اما هنوز آسیب پذیری وجود دارد برای بای پس این عمل باید پی لود های متفاوت را تست نمائید که ما برای شما تعدادی از این پیلود ها را قرار میدهیم :

پیلود ها از قسمت پیوست دانلود نمائید .

[SafeMaster]

پیلود های بای پس صفحات لاگین :

همچنین کلمات کلیدی جستجو در گوگل (گوگل دورک) برای یافتن سایتهای آسیب پذیر به شرح زیر میباشد :

inurl:admin.php
inurl:admin.asp
inurl:admin.aspx
inurl:administrator.asp
inurl:login.aspx
.....

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

[SafeMaster]

با گسترش حملات تزریق sql وخسارت ها جبران ناپذیر مدیران سرور و میزبان های هاست با استفاده از دیوار ها آتش و تعریف قوانین فیلتر کاراکتر ها سعی در مقابله با عنوان حملات sql injection دارند اما همسان با امنیت نفوذ نیز این عمل را بدون جواب نمیگذارد در این پست توضیحاتی در مورد بای پس فایروال در حملات Sqlinjection را توضیح خواهیم داد با ما همراه باشید :

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

WAF یا فایروال با محافظت از سرورهای وب و فیلتر کردن / نظارت بر ترافیک HTTP در برابر حملاتی مانند جعل بین سایت ، (XSS) ، تزریق SQL ، درج پرونده در میان موارد دیگر. و همچنین موارد لایه لایه OSI مدل 7 آن. سعی در بالا بردن هر چه بیشتر امنیت نرم افزار های تحت وب را دارد .

تفاوت WAF در لیست سیاه و سفید چیست؟
WAF را می توان از سه طریق مختلف اجرا کرد که هرکدام مزایا و معایب خاص خود را دارند:

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

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

بحث امروز درباره تکنیک دور زدن WAF از طریق آسیب پذیری SQL Injection میباشد :

SQL INJECTION BYPASS WAF TECHNIQUES

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

1. Null Bytes :

برای انجام حمله null byte ، شما فقط باید یک بایت null کدگذاری شده توسط URL (٪ 00) قبل از رشته مورد نظر برای مسدود کردن بای پس (URL) ایجاد کنید.

2. SQL comment:

comment SQL / ** / به ما امکان می دهد بسیاری از فیلترها و WAF ها را دور بزنیم.

3. URL endcoding:

برخی از نویسه های فیلتر شده توسط WAF را با کد urlen جایگزین کنید:

4. رمزگذاری به hex

با تابع [/٪ 2A٪ 2A /] و [٪ 2F **٪ 2F] می توانید این کار را انجام دهید

5. تغییر پرونده

برخی از WAF ها هیچ قانون یا امضایی برای شناسایی موارد بزرگ ندارند ، و میتوان با حروف کوچک و بزرگ آنها را دور زد .

6. کلمات کلیدی جایگزین شده

برخی از برنامه ها و WAF ها از preg_replace برای حذف کلمه کلیدی SQL استفاده می کنند اما در الگوریتم بازگشتی از آن استفاده نمی کنند. بنابراین می توانید به راحتی آن را دور بزنید.

7. دور زدن WAF - استفاده از نویسه ها

می توانید از برخی نویسه ها به صورت زیر استفاده کنید: |،؟، “،، *،٪،،

[] ،؛ ،: ، \ / ، $ ، € ، ()

8. تکنیک بای پس CRLF WAF

CRLF به معنای "Carriage Return، Line Feed" است که در قالب متن خط جدید ویندوز است (\ r \ n) ، فقط LF در یونیکس (\ n). مانند مثال زیر می توانید از این روش برای دور زدن WAF استفاده کنید.

9. آلودگی پارامتر HTTP (HPP)

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

10. Buffer OverFlow

بسیاری از فایروال ها در C ساخته شده اند و می توانید آنها را با استفاده از Buffer Overflow خراب کنید.

توضیحات تکمیلی در پیوست