https://virgool.io/feed/@amirdehghan Web Application Security Researcher fa 2026-06-16 06:39:24 https://files.virgool.io/upload/users/4213233/avatar/avatar.png?height=120&width=120 https://virgool.io/@amirdehghan https://virgool.io/@amirdehghan/%D8%A7%D8%B2-sql-injection-%D8%AA%D8%A7-%D8%A7%D9%81%D8%B4%D8%A7%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA-%D9%86%D8%B2%D8%AF%DB%8C%DA%A9-%D8%A8%D9%87-%DB%B2%DB%B0%DB%B0%DB%B0-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-a4l3vigaodhu چند وقت پیش موقع بررسی امنیت یک سامانه دانشگاهی به یک SQL Injection برخوردم. اولش فکر می‌کردم مثل خیلی از موارد دیگه با یک آسیب‌پذیری معمولی طرف هستم، اما هرچه بیشتر بررسی کردم، ابعاد ماجرا جدی‌تر شد.بعد از تأیید SQL Injection، تونستم به پنل مدیریت سایت دسترسی پیدا کنم. چیزی که انتظارش رو نداشتم این بود که داخل پنل، اطلاعات کاربران به این شکل نگهداری شده باشه.در بخش مدیریت کاربران، اطلاعات نزدیک به ۲۰۰۰ نفر قابل مشاهده بود؛ شامل ایمیل، شماره تلفن و حتی رمز عبور کاربران.بزرگ‌ترین مشکل اینجا بود که رمزها هش نشده بودند و به‌صورت Plaintext ذخیره شده بودند. یعنی هر کسی که به این بخش دسترسی پیدا می‌کرد، می‌توانست رمز واقعی کاربران را ببیند.همین موضوع باعث شد شدت آسیب‌پذیری چند برابر شود. دیگر فقط بحث دسترسی به یک پنل ادمین نبود؛ بلکه اطلاعات ورود تعداد زیادی از کاربران در معرض خطر قرار داشت.برای ارزیابی تأثیر واقعی مشکل، یکی از ایمیل را به‌صورت رندوم بررسی کردم. مشخص شد کاربر از همان رمز عبور در سرویس ایمیل خود نیز استفاده کرده است.زمانی که اطلاعات ورود را تست کردم، سرویس ایمیل تلاش برای ورود را مشکوک تشخیص داد و درخواست تأیید هویت اضافی نمایش داده شد. احتمالاً دلیل این موضوع تفاوت IP و موقعیت جغرافیایی من با محل معمول ورود صاحب حساب بود.همان لحظه دوباره یاد یکی از مهم‌ترین توصیه‌های امنیتی افتادم؛ اینکه هیچ‌وقت از یک رمز عبور برای چند سرویس مختلف استفاده نکنید.خیلی از افراد تصور می‌کنند اگر اطلاعات یک سایت نشت کند، فقط همان حساب در خطر است. اما وقتی یک رمز در چند سرویس مختلف استفاده شود، نشت اطلاعات از یک وب‌سایت می‌تواند روی ایمیل، شبکه‌های اجتماعی و سایر حساب‌های مهم کاربر هم تأثیر بگذارد.از طرف دیگر این اتفاق اهمیت احراز هویت دومرحله‌ای را هم نشان می‌دهد. حتی زمانی که رمز عبور افشا شده باشد، وجود یک لایه امنیتی اضافه می‌تواند جلوی دسترسی غیرمجاز را بگیرد.بعد از مستندسازی کامل موضوع، گزارش به مسئولانه مربوطه ارسال شد. تمام شواهد و تصاویر قبل از اشتراک‌گذاری سانسور شدند و هیچ اطلاعاتی از کاربران منتشر نشد.خوشبختانه پس از بررسی، آسیب‌پذیری رفع شد و مشکل ذخیره‌سازی ناامن رمزهای عبور نیز برطرف شد.چیزی که این مورد را برای من جالب کرد، خود SQL Injection نبود؛ بلکه زنجیره‌ای از مشکلات امنیتی بود که از دل آن بیرون آمد. یک SQL Injection ساده در نهایت به دسترسی به پنل مدیریت، مشاهده اطلاعات نزدیک به ۲۰۰۰ کاربر و آشکار شدن ضعف‌های جدی در مدیریت اطلاعات حساس منتهی شد.این تجربه یک بار دیگر ثابت کرد که گاهی یک آسیب‌پذیری به‌ظاهر کوچک، می‌تواند در عمل به یک ریسک بزرگ برای تعداد زیادی از کاربران تبدیل شود. امیرحسین دهقانی امیرحسین دهقانی Fri, 12 Jun 2026 12:17:44 +0330 https://virgool.io/@amirdehghan/%D8%AA%D8%B3%D8%AA-%D9%86%D9%81%D9%88%D8%B0-%D9%88%D8%A8-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7%DB%8C-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-graphql-syhvgq3fqfyc چند سال اخیر هر جا API مدرن می‌بینیم، احتمال اینکه پشتش GraphQL باشد کم نیست. خیلی از شرکت‌ها به خاطر انعطاف بیشتر و کاهش تعداد درخواست‌ها سراغ GraphQL رفتند. اما از دید یک تستر امنیت، GraphQL فقط یک API جدید نیست؛ یک سطح حمله جدید هم محسوب می‌شود.در این مقاله می‌خواهیم ببینیم GraphQL چیست، چطور می‌شود آن را شناسایی کرد و مهم‌تر از همه، هنگام تست نفوذ چه چیزهایی را باید بررسی کنیم.GraphQL چیست؟اگر قبلاً با REST کار کرده باشید، می‌دانید که معمولاً برای هر بخش از برنامه یک Endpoint جدا وجود دارد:/api/users /api/posts /api/commentsاما در GraphQL معمولاً فقط یک Endpoint داریم:/graphqlدر GraphQL کلاینت مشخص می‌کند دقیقاً چه داده‌ای می‌خواهد و سرور هم فقط همان داده را برمی‌گرداند.برای مثال فرض کنید می‌خواهیم اطلاعات یک کاربر و پست‌هایش را دریافت کنیم. در REST ممکن است مجبور باشیم چند درخواست جداگانه ارسال کنیم، اما در GraphQL همه چیز را می‌توان در یک Query دریافت کرد.همین انعطاف‌پذیری باعث شده GraphQL محبوب شود، اما از طرفی کار تست نفوذ را هم کمی متفاوت کرده است.ساختار GraphQL به زبان سادهدر GraphQL همه چیز حول Objectها می‌چرخد.مثلاً در یک سیستم وبلاگ می‌توانیم این Objectها را داشته باشیم:UserPostCommentهر Object تعدادی Field دارد.برای مثال User می‌تواند شامل باشد:usernameemailroleهمچنین Objectها می‌توانند با هم ارتباط داشته باشند. مثلاً یک User چند Post داشته باشد و هر Post چند Comment.به عنوان یک تستر امنیت، دقیقاً همین ارتباط‌ها هستند که باید روی آن‌ها حساس باشید؛ چون خیلی از مشکلات دسترسی از همین جا شروع می‌شوند.عملیات اصلی در GraphQLدر GraphQL سه نوع عملیات اصلی وجود دارد.Queryبرای خواندن اطلاعات استفاده می‌شود.Mutationبرای ایجاد، حذف یا ویرایش داده‌ها استفاده می‌شود.Subscriptionبرای دریافت رویدادهای لحظه‌ای استفاده می‌شود.مثلاً زمانی که در یک سیستم چت پیام جدیدی دریافت می‌کنید یا در یوتیوب کانالی که دنبال می‌کنید ویدیوی جدید منتشر می‌کند.اولین قدم: شناسایی GraphQLاولین سؤال این است که اصلاً چطور بفهمیم یک برنامه از GraphQL استفاده می‌کند؟معمولاً با مشاهده ترافیک برنامه در Burp Suite می‌توان متوجه شد.اگر درخواست‌ها به Endpointهایی مثل موارد زیر ارسال شوند، احتمالاً با GraphQL طرف هستیم:/graphql /graphiql /playground /graphql-playgroundبرای پیدا کردن Endpointها می‌توان از روش‌های مختلفی استفاده کرد:FuzzingGoogle DorkWayback MachineNucleiبررسی فایل‌های JavaScriptابزار Logger++ در Burp هم می‌تواند در شناسایی ترافیک GraphQL کمک زیادی کند.GraphiQL؛ دوست توسعه‌دهنده، دوست تستریکی از چیزهایی که هنگام تست GraphQL همیشه دنبالش می‌گردم GraphiQL است.GraphiQL یک رابط گرافیکی برای تست و دیباگ GraphQL است.اگر این رابط در محیط Production در دسترس باشد، ممکن است بتوانیم:Queryها را ببینیمMutationها را مشاهده کنیمساختار API را بررسی کنیممستندات API را بخوانیمبه همین دلیل دسترسی عمومی به GraphiQL در محیط عملیاتی معمولاً توصیه نمی‌شود.Introspection؛ مهم‌ترین بخش Reconبعد از پیدا کردن Endpoint، اولین چیزی که تست می‌کنم Introspection است.Introspection قابلیتی است که به ما اجازه می‌دهد ساختار GraphQL را مشاهده کنیم.اگر فعال باشد می‌توانیم اطلاعاتی مثل:QueryهاMutationهاTypeهاFieldهاارتباط بین Objectهارا مشاهده کنیم.به زبان ساده، Introspection مثل این است که نقشه کامل API را در اختیارمان قرار بدهند.البته فعال بودن Introspection به‌تنهایی آسیب‌پذیری محسوب نمی‌شود، اما می‌تواند فرآیند شناسایی را برای مهاجم بسیار ساده‌تر کند.برای استخراج Schema ابزارهایی مثل InQL بسیار کاربردی هستند.متدولوژی من برای تست GraphQLمعمولاً روندی که برای تست GraphQL دنبال می‌کنم به این شکل است:پیدا کردن Endpointبررسی GraphiQL یا Playgroundتست Introspectionاستخراج Schemaشناسایی Queryها و Mutationهابررسی دسترسی‌هاتست Injectionبررسی SSRFتست DoSبررسی Rate Limitingآسیب‌پذیری‌های رایج در GraphQL1. مشکلات دسترسی (Authorization)یکی از رایج‌ترین مشکلات GraphQL مربوط به کنترل دسترسی است.گاهی توسعه‌دهنده دسترسی به یک Query حساس را محدود کرده، اما همان اطلاعات از طریق یک Query دیگر یا از طریق ارتباط بین Objectها قابل دسترسی است.برای همین هنگام تست GraphQL نباید فقط روی Queryهای اصلی تمرکز کرد. گاهی مسیرهای فرعی و Nested Queryها به اطلاعات حساس دسترسی می‌دهند.2.دو InjectionGraphQL قرار نیست شما را در برابر SQL Injection یا NoSQL Injection محافظت کند.در بسیاری از برنامه‌ها ورودی کاربر از طریق Variables به Backend منتقل می‌شود و اگر اعتبارسنجی مناسب انجام نشده باشد، امکان وقوع Injection وجود دارد.به همین دلیل بخش Variables یکی از مهم‌ترین قسمت‌هایی است که باید بررسی شود.3. سه SSRFهر جا دیدید یک Query یا Mutation آدرس URL دریافت می‌کند، احتمال SSRF را در نظر بگیرید.برای مثال:Import از URLدریافت تصویر از URLWebhookURL Previewاین قابلیت‌ها می‌توانند باعث شوند سرور به درخواست‌های دلخواه مهاجم پاسخ دهد.4.چهار Resource Intensive Queriesبعضی Queryها پردازش سنگینی روی سرور انجام می‌دهند.برای مثال:تولید گزارشپردازش فایلتحلیل دادهجستجوهای پیچیدهاگر محدودیت مناسبی وجود نداشته باشد، می‌توان از این قابلیت‌ها برای مصرف منابع سرور سوءاستفاده کرد.5. پنج Batch Query Abuseبرخی پیاده‌سازی‌های GraphQL اجازه می‌دهند چند Query در یک درخواست ارسال شود.اگر محدودیتی روی تعداد عملیات وجود نداشته باشد، مهاجم می‌تواند حجم زیادی از درخواست‌ها را در یک Request اجرا کند و فشار قابل توجهی روی سرور وارد کند.6. شش Recursive Query DoSیکی از معروف‌ترین حملات GraphQL مربوط به Queryهای بازگشتی است.در GraphQL ممکن است چند Object به هم وابسته باشند.مهاجم می‌تواند با ایجاد Queryهای عمیق و تودرتو، سرور را مجبور به پردازش حجم زیادی از داده‌ها کند.به همین دلیل بسیاری از Frameworkها مکانیزم‌هایی مثل:Maximum Query DepthQuery Complexity AnalysisDEPTH_MAXرا پیاده‌سازی می‌کنند.ابزارهای کاربردیچند ابزار که هنگام تست GraphQL زیاد از آن‌ها استفاده می‌شود:Burp SuiteLogger++InQLGraphQLmapNucleiWayback Machineجمع‌بندیGraphQL امکانات بسیار خوبی برای توسعه‌دهندگان فراهم می‌کند، اما در عین حال سطح حمله متفاوتی نسبت به REST ایجاد می‌کند.اگر قصد تست نفوذ GraphQL را دارید، یادگیری مفاهیمی مثل Introspection، Schema Discovery، Authorization، Injection، SSRF و Query Complexity اهمیت زیادی دارد.هرچه شناخت بهتری از ساختار GraphQL داشته باشید، احتمال پیدا کردن باگ‌های ارزشمند نیز بیشتر خواهد شد. امیرحسین دهقانی امیرحسین دهقانی Wed, 10 Jun 2026 18:22:41 +0330 https://virgool.io/@amirdehghan/%D9%88%D9%82%D8%AA%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA-%D8%AF%DB%8C%D8%AA%D8%A7%D8%A8%DB%8C%D8%B3-%D8%A7%D8%B4%D8%AA%D8%A8%D8%A7%D9%87%DB%8C-%D8%AA%D9%88%DB%8C-%D9%81%D8%B1%D8%A7%D9%86%D8%AA-%D8%A7%D9%86%D8%AF-%D9%84%D9%88-%D9%85%DB%8C%D8%B1%D9%87-dwionmnuiyen همه‌چی از دنبال XSS گشتن شروع شد.ماجرا عجیب نبود. داشتم مثل همیشه دنبال XSS می‌گشتم و نگاهی به سورس صفحه انداختم. همون‌جا یه چیز عجیب توجه‌م رو جلب کرد: یه سری کد که به فرانت‌اند نمی‌خورد و بخش‌هایی از PHP رو نشون می‌داد. حتی اطلاعاتی که به اتصال دیتابیس مربوط می‌شدن. چیزهایی که واقعاً نباید هیچ‌وقت توی سورس برای کاربر قابل مشاهده باشن.چقدر خطرناک بود؟به‌تنهایی، این اطلاعات به هیچ‌کس اجازه نمی‌داد که لاگین کنه، دیتایی ببینه یا رکوردی دستکاری کنه. هیچ تست مخرب و استفاده‌ای هم صورت نگرفت.اما نکته مهم اینه که همین اطلاعات، وقتی با ضعف‌های دیگه ترکیب بشن، می‌تونن مسیرهای پرریسکی بسازن. این همون چیزی‌ست که اغلب توسعه‌دهنده‌ها دست‌کم می‌گیرن: ضعف‌هایی که به نظر کم‌اهمیت میان، اما در سناریوهای ترکیبی مشکل‌آفرین می‌شن.ادامه ماجرابا کمی بررسی بیشتر و استفاده از ابزار ffuf، مسیر phpMyAdmin کشف شد. در نهایت، مشکل گزارش شد و خوشبختانه برطرف شد. امیرحسین دهقانی امیرحسین دهقانی Thu, 22 Jan 2026 01:58:49 +0330 https://virgool.io/@amirdehghan/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%DA%A9%D8%B4%D9%81-%D8%A2%D8%B3%DB%8C%D8%A8-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-sql-injection-%D8%AF%D8%B1-%D9%88%D8%A8-%D8%B3%D8%A7%DB%8C%D8%AA-%DB%8C%DA%A9-%D9%86%D9%87%D8%A7%D8%AF-%D8%AF%D9%88%D9%84%D8%AA%DB%8C-%D8%AD%D8%B3%D8%A7%D8%B3-pbaufpe3hwt5 چکیدهامنیت سامانه‌های دولتی، به‌ویژه نهادهای مرتبط با زیرساخت‌های حساس، از اهمیت بالایی برخوردار است. یکی از آسیب‌پذیری‌هایی که با وجود شناخته‌شده بودن همچنان در سامانه‌های مختلف مشاهده می‌شود، SQL Injection است. در این مقاله، فرآیند شناسایی یک آسیب‌پذیری از نوع Boolean-Based Blind SQL Injection در وب‌سایت یک نهاد دولتی حساس بررسی می‌شود. این مطالعه موردی مربوط به چند ماه گذشته بوده و تمامی اطلاعات شناسایی‌کننده به‌طور کامل سانسور شده‌اند.لازم به ذکر است که سامانه‌ی مورد بررسی مربوط به ایران نبوده و هدف این مقاله صرفاً ارائه‌ی یک تحلیل آموزشی و افزایش آگاهی امنیتی است.1. مقدمهبا توسعه‌ی خدمات دولت الکترونیک، وب‌سایت‌های دولتی به اهداف جذابی برای حملات سایبری تبدیل شده‌اند. وجود ضعف‌های امنیتی در این سامانه‌ها می‌تواند منجر به افشای اطلاعات حساس و کاهش اعتماد عمومی شود. SQL Injection به‌عنوان یکی از حملات کلاسیک لایه‌ی کاربرد، همچنان در فهرست تهدیدات مهم امنیتی قرار دارد و بیانگر ضعف در پیاده‌سازی اصول توسعه‌ی امن است.2. مروری بر آسیب‌پذیری SQL InjectionSQL Injection زمانی رخ می‌دهد که ورودی‌های کاربر بدون اعتبارسنجی مناسب در کوئری‌های پایگاه داده مورد استفاده قرار گیرند. این مسئله می‌تواند باعث تغییر منطق اجرای کوئری شود.از جمله انواع رایج SQL Injection می‌توان به موارد زیر اشاره کرد:Error-Based SQL InjectionUnion-Based SQL InjectionBlind SQL Injection (Boolean-Based و Time-Based)در این مطالعه، نوع شناسایی‌شده از دسته‌ی Blind SQL Injection بوده است که تشخیص آن معمولاً از طریق تحلیل پاسخ‌های منطقی سامانه انجام می‌شود.3. معرفی مطالعه موردی (سانسورشده)مطالعه‌ی حاضر مربوط به بررسی یک پرتال وب متعلق به یک نهاد دولتی حساس در کشوری غیر از ایران است. به‌منظور رعایت اصول اخلاقی و افشای مسئولانه، نام کشور، سازمان، دامنه و جزئیات فنی شناسایی‌کننده حذف شده‌اند.مشخصات کلی سامانه:نوع سامانه: پرتال وب دولتیفناوری سمت سرور: PHPسیستم مدیریت پایگاه داده: Oracleزمان شناسایی آسیب‌پذیری: چند ماه پیشسامانه دارای بخش‌هایی برای دریافت ورودی از کاربر از طریق پارامترهای HTTP بوده است که به پایگاه داده متصل می‌شدند.4. روش شناسایی آسیب‌پذیریفرآیند شناسایی به‌صورت غیرمخرب و صرفاً در سطح تشخیص آسیب‌پذیری انجام شد. در مرحله‌ی اولیه، رفتار سامانه در برابر ورودی‌های مختلف بررسی و تفاوت‌هایی در پاسخ‌های منطقی سرور مشاهده شد که احتمال وجود تزریق SQL را مطرح می‌کرد.برای تأیید وجود آسیب‌پذیری، از ابزار متن‌باز sqlmap به‌عنوان یک ابزار خودکار تست نفوذ استفاده شد. استفاده از این ابزار محدود به شناسایی نوع آسیب‌پذیری، تشخیص DBMS و ارزیابی سطح ریسک بوده و هیچ‌گونه بهره‌برداری عملیاتی یا استخراج داده انجام نشده است.نتایج نشان داد که یکی از پارامترهای ورودی از نوع GET در برابر Boolean-Based Blind SQL Injection آسیب‌پذیر است و منطق شرطی کوئری‌های پایگاه داده تحت تأثیر ورودی کاربر قرار می‌گیرد.عکس ۲. خروجی ابزار sqlmap به‌صورت سانسور شده؛ کلیه اطلاعات شناسایی‌کننده، آدرس سامانه، پارامترها و جزئیات قابل سوءاستفاده حذف شده‌اند. این تصویر صرفاً جهت مستندسازی آموزشی ارائه شده است.5. ارزیابی ریسک و پیامدهای احتمالیدر صورت سوءاستفاده از این آسیب‌پذیری، پیامدهای زیر قابل تصور بود:دسترسی غیرمجاز به داده‌های پایگاه دادهافشای اطلاعات حساسامکان تغییر یا حذف داده‌هاکاهش سطح امنیت اطلاعات و اعتماد عمومیبا توجه به حساسیت نهاد مورد بررسی، این آسیب‌پذیری می‌توانست تبعات جدی امنیتی به همراه داشته باشد.6. افشای مسئولانهپس از شناسایی آسیب‌پذیری، موضوع از طریق کانال‌های مناسب و مطابق با اصول Responsible Disclosure گزارش شد. در این فرآیند، از انتشار عمومی جزئیات فنی که امکان سوءاستفاده را فراهم می‌کردند، خودداری گردید.7. راهکارهای پیشنهادیبرای پیشگیری از بروز آسیب‌پذیری‌های مشابه، راهکارهای زیر توصیه می‌شود:استفاده از Prepared Statements و Parameterized Queriesبهره‌گیری از ORMهای امناعتبارسنجی و پاک‌سازی ورودی‌های کاربرپیاده‌سازی Web Application Firewall (WAF)انجام تست‌های امنیتی دوره‌ایبازبینی و اصلاح کدهای قدیمی8. نتیجه‌گیریاین مطالعه موردی نشان می‌دهد که SQL Injection همچنان تهدیدی جدی حتی برای سامانه‌های دولتی حساس محسوب می‌شود. شناسایی به‌موقع این آسیب‌پذیری‌ها و گزارش مسئولانه‌ی آن‌ها نقش مهمی در افزایش سطح امنیت سایبری دارد. انتشار مطالعات آموزشی سانسورشده می‌تواند به ارتقای آگاهی توسعه‌دهندگان و متخصصان امنیت کمک کند و از تکرار چنین ضعف‌هایی در آینده جلوگیری نماید. امیرحسین دهقانی امیرحسین دهقانی Wed, 21 Jan 2026 15:35:53 +0330 https://virgool.io/@amirdehghan/%D8%A2%D8%B3%DB%8C%D8%A8-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-cors-misconfiguration-%D9%88-%D9%86%D8%AD%D9%88%D9%87-%D8%B3%D9%88%D8%A1%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D8%A2%D9%86-jbt8abt0hz8x درود دوستاناول ببینیم CORS چیه و اصلاً چرا به وجود اومده؟CORS یا Cross-Origin Resource Sharing یک مکانیزم امنیتی در سمت مرورگره که به سرور اجازه می‌ده مشخص کنه کدوم Originها می‌تونن به منابعش دسترسی داشته باشن.CORS برای حذف SOP ساخته نشده، بلکه برای دور زدن کنترل‌شده‌ی Same-Origin Policy به وجود اومده.SOP چی بود؟طبق SOP، مرورگر اجازه نمی‌ده یک وب‌سایت به پاسخ‌های وب‌سایتی با Origin متفاوت دسترسی داشته باشه.Origin از سه بخش تشکیل می‌شه:پروتکل (http / https)دامنهپورتاگه یکی از این‌ها فرق کنه، Origin متفاوت حساب می‌شه.چطور بفهمیم سایت از CORS استفاده می‌کنه؟برای این کار، هدر Origin رو به درخواست اضافه می‌کنیم.اگه در پاسخ هدر زیر وجود داشت یعنی CORS فعاله:Access-Control-Allow-Originاما برای اینکه این موضوع به یک آسیب‌پذیری واقعی تبدیل بشه، معمولاً باید هدر زیر هم وجود داشته باشه:Access-Control-Allow-Credentials: true\شروع تست آسیب‌پذیری CORSنکته مهم اینه که تست CORS بعد از احراز هویت انجام می‌شه و بهترین نقطه برای تست، بخش‌هایی مثل پروفایل کاربر یا APIهای حساس هست.مراحل تستابتدا مقدار Origin رو برابر دامنه خود سایت قرار می‌دیم (با https و بدون https تست می‌کنیم).اگر در پاسخ این هدرها برگشت:Access-Control-Allow-Origin Access-Control-Allow-Credentials: trueیعنی برنامه از CORS استفاده می‌کنه.بعد میایم Origin رو با ساب‌دامنه‌های سایت تست می‌کنیم.اگر پاسخ معتبر بود، سراغ دامنه‌های دلخواه می‌ریم، مثلاً:Origin: https://hacker.comاگر سرور این Origin رو هم قبول کرد، برنامه آسیب‌پذیره.سناریوهای پیشرفته‌تراگر به دامنه مستقیم جواب نداد:مقدار Origin رو null می‌ذاریمدامنه‌هایی با ساختار اشتباه تست می‌کنیم، مثلاً:hackertarget.comtarget.com.hacker.comدر این حالت احتمال زیادی وجود داره که برنامه‌نویس از regex اشتباه برای اعتبارسنجی Origin استفاده کرده باشه.نکته مهماین نوع آسیب‌پذیری زمانی قابل سوءاستفاده است که اپلیکیشن Cookie-based authentication داشته باشه، چون کوکی‌ها به‌صورت خودکار توسط مرورگر ارسال می‌شن. امیرحسین دهقانی امیرحسین دهقانی Wed, 21 Jan 2026 13:11:02 +0330 https://virgool.io/@amirdehghan/%D9%86%D8%B5%D8%A8-%D9%88-%D8%B1%D8%A7%D9%87-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%DB%8C-burp-suite-%D8%B1%D9%88%DB%8C-ubuntu-vsyazwob4ghr Burp Suite یکی از محبوب‌ترین ابزارهای تست امنیت وب است که توسط PortSwigger توسعه داده شده. در این مقاله گام‌به‌گام نصب و پیکربندی Burp Suite (نسخهٔ Community و نکات مربوط به نسخهٔ Professional) روی اوبونتو را توضیح می‌دهم،‌ طوری که برای باگ‌هانترها و پنتسترهای وب قابل استفاده و آماده باشد.در ابتدا اینو بگم که برای برای نصب نسخه installer نیازی به آپدیت جاوا و نیست و. با همون ورژن خود ubuntu اوکی هستیک نکته مهم اول: اگر نسخهٔ installer رسمی Burp Suite را نصب می‌کنید معمولاً نیاز به نصب یا آپدیت جداگانهٔ Java ندارید — بستهٔ نصبی معمولاً JRE مناسب را همراه دارد. اما اگر فایل *.jar را مستقیماً اجرا می‌کنید باید Java (OpenJDK 11/17/21 بسته به نسخهٔ Burp) روی سیستم نصب باشد.مرحله اول دانلود Burp Suite:به سایت رسمی PortSwigger مراجعه کرده و نسخهٔ مورد نظر را دانلود میکنیم. (Community رایگان؛ Professional نیاز به لایسنس دارد.)برای نسخه Community وارد لینک زیر میشم و روی گزینه Go straight to downloads تا دانلود شروع شهمرحله دوم باید پرمیشن رو به فایل دانلودی بدیم:میریم به مسیر کی فایل دانلودی درونش قرار دارهبعد باید بهش پرمیشن بدیم که دستورش میشه chmod a+xمرحله سوم اینکه فایل رو اجرا میکنم و برپ سویت رو نصب میکنیم:باید با سطح دسترسی روت اجراش کنیم و بعد installer اش باز میشه که چندتا next ساده هستنصب شد حالا تو اپلیکیشن ها اومدهمرحله چهارم :نصب گواهی ریشهٔ Burp (CA Certificate)برای اینکه مرورگرها به‌درستی Burp اعتماد کنند و خطای HTTPS نده، باید گواهی CAِ Burp را نصب کنیم.برپ سویت رو باز باز میکنم وارد تب proxy میشم و Intercept رو میزنیم تا فعال شه حالا باید گواهینامه برپ رو دانلود کنیم میتونیم آدرس http://burp یا http://127.0.0.1:8080 رو بزنیم تا صفحه طبق تصویر زیر بالا بیاد حالا روی گزینه Ca Certificate میزنیم تا دانلود شهحالا باید در مروگر این گواهینامه رو نصب کنیم طبق تصویر زیر ابتدا وارد setting میشویم و بعد سرچ میکنیم Certificate بعد از گزینه import اون گواهینامه برپ رو انتخاب میکنیم و تیک اول گزینه اول رو میزنیم.مرحله آخر هم اینکه بیایم ترافیک مرورگر رو پروکسی کنیم به برپ :که برای این مورد از افزونه Foxy Proxy استفاده میکنیم که هم برای کروم هست هم فایر فاکس بعد نصب طبق عکس زیر میایم و وارد تب Proxies میشم در بخش Title میام یه نام دلخواه براش میزاریم که من گزاشتم Burpو Type رو روی Http میزاریم و بعد از بخش Hostname روی آیپی لوکال هاست میزاریم که میشه 127.0.0.1 و Port روی 8080 میزاریم و تمام الان باید رو افزونه Foxy Proxy کلیک کنیم و نام که وارد کریم رو انتخاب کنیم تا ترافیک پروکسی شه روی برپ.نکته: میتوان در تنظیمات مربوط به Bu پورت رو عوض کرد. امیرحسین دهقانی امیرحسین دهقانی Tue, 14 Oct 2025 19:21:48 +0330 https://virgool.io/@amirdehghan/%DB%8C%DA%A9-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1-%DA%A9%D9%88%DA%86%DA%A9-%DB%8C%DA%A9-%D8%A8%D8%A7%DA%AF-%D8%A8%D8%B2%D8%B1%DA%AF-%D9%88%D9%82%D8%AA%DB%8C-%D8%AD%D8%B1%D9%88%D9%81-%D8%A8%D8%B2%D8%B1%DA%AF-%D9%88-%DA%A9%D9%88%DA%86%DA%A9-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B1%D8%A7-%D8%AF%D9%88%D8%B1-%D9%85%DB%8C-%D8%B2%D9%86%D9%86%D8%AF-d4cjhiul7szp داستان از جایی شروع شد که در حال بررسی امنیتی یک وب‌سایت بودم. در این وب‌سایت، با مسیری به شکل زیر مواجه شدم:index.php?cpath=23همانطور که هر تست‌کننده امنیتی می‌داند، پارامترهای عددی در URL‌ها اغلب هدف خوبی برای کشف آسیب‌پذیری‌هایی مانند SQL Injection و XSS (Cross-Site Scripting هستند. من هم بلافاصله شروع به تست این دو آسیب‌پذیری کردم.ابتدا، تلاش کردم تا با Payloadهای رایج XSS، این آسیب پذیری رو چک کنم. اما متوجه شدم که ورودی به خوبی فیلتر می‌شود و خبری از XSS نبود.ناامید نشدم و به سراغ SQL Injection رفتم. انواع Payloadهای SQLi را امتحان کردم، از Error-Based گرفته تا Time-Based و Boolean-Based. اما باز هم، نتیجه ناامیدکننده بود. به نظر می‌رسید که این پارامتر cpath به خوبی در برابر حملات SQL Injection نیز مقاوم است. داشتم کم‌کم ناامید می‌شدم و فکر می‌کردم که شاید این پارامتر اصلا آسیب‌پذیر نباشد.اینجا بود که تصمیم گرفتم از ابزار ParamSpider استفاده کنم. ParamSpider ابزاری قدرتمند برای کشف پارامترهای پنهان یا کمتر شناخته‌شده در یک وب‌سایت است. با اجرای ParamSpider بر روی دامنه مورد نظر، لیستی از پارامترهای کشف شده به من نمایش داده شد.در میان این پارامترها، یک مورد توجه من را جلب کرد:cPath=یک تفاوت ظاهراً بی‌اهمیت! این پارامتر دقیقاً همان cpath بود، اما با حرف "P" بزرگ (Camel Case).بلافاصله، URL را با پارامتر جدید تست کردم:index.php?cPath=23و اینجا بود که جادو اتفاق افتاد! با تزریق Payloadهای SQL Injection، مشخص شد که این پارامتر جدید، یعنی cPath، آسیب‌پذیر است و می‌توان از طریق آن حملات SQL Injection را با موفقیت انجام داد! امیرحسین دهقانی امیرحسین دهقانی Wed, 27 Aug 2025 23:37:16 +0330