🌐مفهوم متغیرهای نشست (Session Variables)

در سمت سرور، برنامه‌نویسان از متغیرهایی (Session Variables) برای ذخیره اطلاعات کاربر استفاده می‌کنند (مانند نام کاربری، وضعیت ورود، شناسه کاربر و ...). این اطلاعات فقط در سمت سرور نگهداری می‌شوند. برای مثال:

session.isLoggedIn:
مشخص می‌کند آیا کاربر وارد شده است یا خیر.
session.userName:
نام کاربری فرد را ذخیره می‌کند.


📛سناریوی حمله این آسیب‌پذیری زمانی رخ می‌دهد که برنامه‌نویسان از یک متغیر یکسان برای فرآیندهای متفاوت استفاده می‌کنند. مراحل حمله به این صورت است:

1. ورود عادی: شما با حساب کاربری خودتان (مثلاً Bob) وارد سایت می‌شوید.

    سرور تنظیم می‌کند:
session.isLoggedIn = true
و
session.userName = bob
2. استفاده از "فراموشی رمز عبور": بدون اینکه از حساب خود خارج شوید (Log out)، در یک تب دیگر به صفحه "فراموشی رمز عبور" می‌روید. این صفحه معمولاً برای کسانی طراحی شده که وارد سایت نشده‌اند، اما اگر باز باشد، سیستم برای پیدا کردن حساب کاربری، نام کاربری را می‌پرسد.

3. تزریق نام قربانی (Stuffing): در کادر فراموشی رمز عبور، نام کاربری قربانی (مثلاً Tina) را وارد می‌کنید.

    سرور برای بررسی حساب تینا، موقتاً متغیر نشست را تغییر می‌دهد:
session.userName = tina
4. نتیجه: حالا اگر به صفحه اصلی حساب کاربری خود برگردید و صفحه را رفرش کنید، چون وضعیت ورود شما (isLoggedIn) هنوز فعال است و نام کاربری در سشن به "Tina" تغییر کرده، شما عملاً وارد حساب تینا می‌شوید و به اطلاعات او دسترسی پیدا می‌کنید.

🔰راهکار امنیتی:

1. استفاده نکردن از یک متغیر مشترک برای "ورود" و "فراموشی رمز عبور"
2. هنگام استفاده از بخش فراموشی رمز عبور، کاربر را مجبور به خروج (Logout) کنید.



https://x.com/the_IDORminator/status/2006929968371040721

آسیب‌پذیری Reverse Tabnabbing

شاید فکر کنید وقتی روی یک لینک کلیک می‌کنید و در یک Tab جدید باز می‌شود، تب قبلی (مبدا) کاملاً ایزوله و امن باقی می‌ماند. اما در دنیای وب، این تصور همیشه درست نیست!
مهاجمان با استفاده از باگ Reverse Tabnabbing می‌توانند بدون اینکه متوجه شوید، صفحه‌ای که از آن آمده‌اید را تغییر دهند.

⚔️ سناریوی حمله (The Attack Scenario)

1. قربانی در سایت معتبری مثل «اینترنت بانک» لاگین کرده است.
2. روی لینکی کلیک می‌کند که با target="_blank" در یک تب جدید باز می‌شود.
3. قربانی مشغول مطالعه تب جدید می‌شود.
4. حمله: سایت مخرب در تب جدید، با استفاده از یک خط کد جاوااسکریپت، آدرس تب اصلی (بانک) را تغییر می‌دهد و آن را به یک صفحه لاگین جعلی (Phishing) هدایت می‌کند.
5. قربانی تب جدید را می‌بندد و به تب قبلی برمی‌گردد. با دیدن صفحه لاگین، تصور می‌کند نشست (Session) او منقضی شده و دوباره نام کاربری و رمز عبور را وارد می‌کند. و تمام! اطلاعات به سرقت میرود.

🔍 ریشه فنی ماجرا

وقتی صفحه‌ای با target="_blank" باز می‌شود، صفحه جدید به شیء window.opener دسترسی دارد. این یعنی صفحه فرزند (Child) می‌تواند آدرس صفحه والد (Parent) را کنترل کند:

window.opener.location = 'https://fake-site.com';

🛡 راهکار امنیتی (Remediation)

برای جلوگیری از این حمله، توسعه‌دهندگان باید دسترسی صفحه جدید به صفحه والد را قطع کنند. این کار با اضافه کردن اتربیوت
rel
انجام می‌شود:

<a href="http://evil.com" target="_blank" rel="noopener">
  Click Me safely
</a>

مقدار noopener: دسترسی به window.opener را مسدود می‌کند.

#Tabnabbing #WebSecurity #Phishing #Pentest #Developers

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/14-Testing_for_Reverse_Tabnabbing

🚨THREAT INTEL: Django SQL Injection 🆔 CVE-2026-1207 | VT-2026-1207 🔥 Severity: High / Critical
آسیب‌پذیریSQL Injection  در ماژول django.contrib.gis  شناسایی شد. اگر در پروژه خود از PostGIS  و فیلدهای RasterField  استفاده می‌کنید، دیتابیس شما در خطر است.
🔬 تحلیل فنی (Technical Deep Dive) مشکل در کلاس RasterField و متدهای مربوط به جستجوی مکانی (Lookups) نهفته است. زمانی که روی یک فیلد رستری کوئری می‌زنید (مثل bbcontains یا سایر عملگرهای GIS)، جنگو به شما اجازه می‌دهد پارامتر band index را مشخص کنید. در نسخه‌های آسیب‌پذیر، این ورودی بدون اعتبارسنجی (Sanitization) و بدون اجبار به نوع Integer، مستقیماً وارد تابع SQL در PostGIS می‌شود.
💀 منطق اکسپلویت (PoC Logic)
فرض کنید دولوپر کدی دارد که ورودی کاربر را به کوئری GIS پاس می‌دهد:
Python

band_idx = request.GET.get('idx') # Untrusted Input
# Passing input directly to lookup
qs = MapLayer.objects.filter(
    raster__bbcontains=(geom, band_idx)
)

در سطح دیتابیس، جنگو این را به تابعی شبیه به این تبدیل می‌کند:
ST_Contains(raster, [band_index], ...)

🔻 بردار حمله (Attack Vector):

مهاجم به جای ارسال عدد (مثلاً 1)، یک رشته مخرب ارسال می‌کند تا پرانتز تابع PostGIS را ببندد و دستور SQL جدید تزریق کند.
Payload Concept:

Input:  1) OR 1=1; --
Result: ST_Contains(raster, 1) OR 1=1; --, ...)

این کار باعث Bypass شدن منطق فیلتر یا اجرای دستورات سنگین (Stacking Queries) می‌شود.

🎯 نسخه‌های آسیب‌پذیر:

• Django 6.0 < 6.0.2 • Django 5.2 < 5.2.11 • Django 4.2 < 4.2.28

🛡 راهکارهای امنیتی (Mitigation)

1️⃣ آپدیت فوری (Recommended): تیم جنگو در پچ‌های جدید ورودی این بخش را Validate می‌کند.
Bash
pip install -U django
2️⃣ هات‌فیکس دستی (Temporary):

اگر امکان آپدیت ندارید، قبل از ارسال متغیر به کوئری، حتماً آن را به int تبدیل کنید:

int(request.GET['idx'])

#Exploit #Django #SQLi #CVE_2026_1207 #Python #RedTeam #PostGIS #BlueTeam

امیدوارم حال همه دوستان خوب باشه

شرایط سختی هست از جان خود و خانواده گرامی مراقبت کنید ❤️

دوستان واقعا شرمنده تو این شرایط حس و حال مطالعه و تحقیق رو نداریم. و نمی‌تونیم هم به همون دلیل پستی بزاریم

سال نو پیشاپیش مبارک عزیزان❤️❤️❤️❤️امیدواریم در سال جدید دیگه از این خبرا نباشه و بتونیم بدون جنگ زندگی کنیم ❤️


در سال جدید اگر موقعیتش رو داشته باشیم و وضعیت اینترنت بهتر بشه کلی برنامه های آموزشی و ctfهای خفن با جایزه داریم

خب دیگه برگردیم سرکار 😁از 12 همین ماه فعالیت تیم WOS مجددا شروع میشه

🛡️ واکاوی فنی آسیب‌پذیری Copy Fail (CVE-2026-31431)

آسیب‌پذیری Copy Fail که اخیراً در هسته لینوکس افشا شده، یک نقص بحرانی از نوع Local Privilege Escalation (LPE) است که به دلیل نرخ موفقیت ۱۰۰ درصدی در اکسپلویت، در رده تهدیدات سطح بالا قرار گرفته است. این باگ که حدود ۹ سال در کدهای زیرسیستم رمزنگاری لینوکس مخفی مانده بود، توسط محققان امنیتی و با بهره‌گیری از تحلیل منطقی کد توسط هوش مصنوعی کشف شد.

📌 ریشه فنی (Root Cause):
نقص امنیتی در ماژول algif_aead.c قرار دارد. مشکل زمانی بروز می‌کند که سیستم برای افزایش کارایی، از بهینه‌سازی In-place در عملیات رمزنگاری استفاده می‌کند.

مهاجم با سوءاستفاده از رابط سوکت‌های AF_ALG و ترکیب آن با فراخوانی سیستمی splice()، می‌تواند محدودیت‌های دسترسی حافظه را دور بزند. این فرآیند منجر به Page Cache Poisoning می‌شود؛ به این معنا که مهاجم می‌تواند داده‌های مدنظر خود را مستقیماً در حافظه نهان (Cache) فایل‌هایی بنویسد که در حالت عادی فقط قابل خواندن (Read-only) هستند.

⚡ مکانیزم اکسپلویت:
برخلاف بسیاری از اکسپلویت‌های کرنل که بر پایه Race Condition هستند، Copy Fail کاملاً قطعی (Deterministic) عمل می‌کند:

تزریق داده: مهاجم با دستکاری منطق رمزگشایی در AEAD، می‌تواند ۴ بایت داده دلخواه را در حافظه مربوط به یک فایل اجرایی با سطح دسترسی بالا (مانند sudo یا su) بازنویسی کند.

تغییر جریان اجرا: با تغییر تنها این ۴ بایت، منطق احراز هویت در فایل اجرایی مذکور دور زده شده و با اجرای آن، سیستم مستقیماً دسترسی Root را در اختیار کاربر قرار می‌دهد.

🔄 مقایسه با Dirty Pipe (CVE-2022-0847):
این آسیب‌پذیری از نظر مکانیزم اثر، شباهت زیادی با باگ معروف Dirty Pipe دارد. در Dirty Pipe، مشکل در مقداردهی صحیح یک فلگ در ساختار Pipe‌ها بود که اجازه می‌داد داده به Page Cache نشت کند. اما در Copy Fail، آسیب‌پذیری عمیق‌تر است؛ چرا که از خودِ توابع رمزنگاری داخلی کرنل برای بازنویسی حافظه استفاده می‌شود که شناسایی و جلوگیری از آن برای سیستم‌های تشخیص نفوذ (IDS) دشوارتر است.

🛠️ راهکار موقت (Mitigation):
تا زمان اعمال آپدیت نهایی کرنل، پیشنهاد می‌شود با غیرفعال کردن ماژول مربوطه، سطح حمله را مسدود کنید:

echo "install algif_aead /bin/false" > /etc/modprobe.d/mitigate-cve-2026-31431.conf

# Unload the module if already active
rmmod algif_aead

اکسپلویتش هم اومد
ترسناک شد !!!!!

Release v3.8.0 · projectdiscovery/nuclei

https://github.com/projectdiscovery/nuclei/releases/tag/v3.8.0

آسیب‌پذیری بحرانی ۱۸ ساله در NGINX فاش شد: CVE-2026-42945 (NGINX Rift)

یک آسیب‌پذیری بسیار خطرناک با شدت 9.2 در وب‌سرور پرکاربرد NGINX کشف شده که میلیون‌ها سرور را در سراسر جهان تهدید می‌کند. این نقص که NGINX Rift نام گرفته، ریشه در یک باگ ۱۸ ساله دارد و می‌تواند به از کار افتادن سرویس (DoS) و در شرایطی خاص، به اجرای کد از راه دور (RCE) منجر شود.

🔹 مشخصات فنی

    شناسه: CVE-2026-42945

    نوع: Heap Buffer Overflow

    ماژول آسیب‌پذیر: ngx_http_rewrite_module (مرتبط با بازنویسی آدرس)

    علت اصلی: نقص در محاسبه طول رشته‌ها هنگام ترکیب دستورات rewrite حاوی علامت سوال ? با متغیرهای بی‌نام مانند $1. این ناهماهنگی باعث می‌شود داده‌های بزرگ‌تر از بافر تخصیص‌یافته در حافظه نوشته شوند.

🔹 محصولات و نسخه‌های تحت تأثیر

    NGINX Open Source: از نسخه 0.6.27 تا 1.30.0

    NGINX Plus: R32 تا R36

    همچنین NGINX Ingress Controller، App Protect WAF و Gateway Fabric

🔹 پیش‌نیازهای سوءاستفاده
برای آسیب‌پذیری نیاز به دو شرط است:

    پیکربندی خاصی در سرور وجود داشته باشد که دستور rewrite با ? را با متغیرهایی مثل $1 ترکیب کند.

    غیرفعال بودن ASLR (تصادفی‌سازی فضای آدرس) برای دستیابی به اجرای کد. البته با معماری چندپردازه‌ای NGINX، حتی با ASLR فعال هم احتمال سوءاستفاده وجود دارد.

🔹 خطرات اصلی

    قطع سرویس (DoS): از کار انداختن سرور بدون نیاز به احراز هویت.

    اجرای کد از راه دور (RCE): تسلط کامل مهاجم بر سرور (در صورت فعال بودن شرایط).

🔹 راهکار فوری و قطعی
  راهکار قطعی ارتقا به نسخه‌های امن است:

    NGINX Open Source:
ارتقا به نسخه 1.30.1 یا 1.31.0

    NGINX Plus:
دریافت وصله‌های R32 P6، R35 P2، R36 P4 یا مهاجرت به R37

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

موثرترین اقدام، اصلاح فایل‌های پیکربندی nginx.conf است. از آنجایی که آسیب‌پذیری در الگوی خاصی از دستورات rewrite با متغیرهای بدون نام مانند $1 و $2 نهفته است، جایگزین کردن آن‌ها با متغیرهای نام‌دار، مسیر ایجاد مشکل را مسدود می‌کند.

    الگوی خطرناک (آسیب‌پذیر):
rewrite ^/article/(\d+)$ /show.php?id=$1 last;

    الگوی امن (اصلاح‌شده):
rewrite ^/article/(?P<id>\d+)$ /show.php?id=${id} last;

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

    فعال‌سازی ASLR: در صورت امکان، برای دشوارتر کردن سوءاستفاده از آسیب‌پذیری‌، ASLR را فعال کنید.

همچنین نظارت دقیق بر لاگ‌ها پیشنهاد می‌شود.

https://nvd.nist.gov/vuln/detail/CVE-2026-42945
https://github.com/rheodev/CVE-2026-42945
https://github.com/friparia/NGINX_RIFT_SCAN_CVE_2026_42945
https://www.itnews.com.au/news/f5-patches-18-year-old-ai-found-rift-vulnerability-in-nginx-web-server-625881

https://x.com/github/status/2056949168208552080 صبح بخیر گیتهاب و زدن :)

Bypassing SSL Pinning in Flutter-Based iOS Applications
https://medium.com/@drhatab/bypassing-ssl-pinning-in-flutter-based-ios-applications-54f420d2f1a1

Tomnomnom shares practical techniques for finding vulnerabilities in modern web applications, covering parameter discovery, JavaScript analysis, recon automation, and how to build effective tooling workflows.

https://tomnomnom.com/talks/wwwww.pdf

⭕️ قسمت هفتم زیرو تاک

📌 موضوع جلسه : واقعیت ‌های باگ بانتی در ایران از جذابیت تا سختی ‌هایی که این حوزه دارد

💢 موضوعات برنامه : قسمت اول تعریف واقع بینانه باگ بانتی در ایران

🎙 مهمان برنامه : مهندس مهرشاد علیزاده

منتظر جلسه بعدی باشید.

🎤 راهبر گفتگوی امنیتی : حسین نائیجی

🆔 @RadioZeroPod
🆔 @TryHackBox
🆔 @TryHackBoxOfficial
🆔 @TryHackBoxStory

گفت گوی بنده راجب باگ بانتی با دوستان خوبم radio zero pod

از دوستان هرکسی تمایل به همکاری در شرکت آشنا ایمن ( پوزیشن تست نفوذ ) را دارد
یک رزومه برای بنده ارسال کند.

@nashenas_tm


فقط دوستان توجه کنید که شرایط همکاری به صورت حضوری و تمام وقت هست.

دوستان کسی از deepseek api استفاده کرده ؟؟؟
اگر گزینه بهتری دارید لطفاً بگید بیشتر استفاده ام برای offensive هست به همین دلیل توکن سوزی بالاست تقریبا می‌خوام چیزی باشه هم به صرفه باشه و هم قیمت مناسبی داشته باشه اگر پیشنهادی دارید حتما بگید ممنون میشم.

Android reverse engineering entirely on-device. Radare2 binary analysis, 8 Java decompilers, Flutter & Unity il2cpp support
https://github.com/UltraSina/androidReverse