Coding Lovers

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

من نمیدونم این خبر چقدر درسته، ولی یک چنل خیلی معتبر گذاشته، امیدوارم پست بزاره بگه جوک بود... https://t.me/perplexity/972

دیگه امنیت نداریم بخدا خیلی مراقب پروژه ها و سیستم هاتون باشین !!!

💻 یک ویروس جدید با احتمال یک‌ششم، سیستم‌های ایران یا اسرائیل را پاک می‌کند یک ویروس تازه کشف‌شده اسکریپتی را اجرا می‌کند که ۱ در ۶ شانس دارد سیستم‌های شناسایی‌شده در اسرائیل یا ایران را به‌طور کامل پاک کند، در حالی که عمداً ماشین‌هایی با محیط زبان روسی را نادیده می‌گیرد. هکرها کدهای مخرب را به ده‌ها مخزن متن‌باز، از جمله کتابخانه پایتون Mistral AI و بیش از ۱۵۰ بسته دیگر، تزریق کردند. به محض اینکه یک توسعه‌دهنده کتابخانه آلوده را در پروژه خود استفاده کند یا وابستگی‌ها را به‌روزرسانی نماید، ویروس فعال شده و به‌طور مخفیانه توکن‌های محرمانه و کلیدهای دسترسی به زیرساخت‌های ابری را سرقت می‌کند.

یه ویدیو رو تقریبا دو ماه پیش قبل از قطع شدن اینترنت گذاشته بودم روی یوتوب، از اون موقع پرایوت بود فردا شب پابلیک میشه ساعت 8 شب بنظرم سکوت رو کم کم بشکنیم بهتره، با هیچ کاری نکردن چیزی درست نمیشه

چیزی نیست فقط ۴ همت تومان چیز خاصی نیست که بخدا ۱ میلیارد بده من برات اینستاهم میگیرم، واتساپ که هیچی

https://t.me/jadivarlog/483 همین الان بعدیشم اومد😂😂😂😂

لینک یوتیوب جادی: https://youtu.be/0GUEoWEDqlo فیلم کم حجمشم همینجا فرستادم که بتونین ببینین اگه یوتیوب سخت براتون باز میشه

باورم نمیشه یه باگ لینوکس که فکر کنم چند ماه پیش کشف شد ( تمام لینوکس هارو در بر میگیره ) که باهاش میشه بدون هیچ چیزی به دسترسی root رسید. فقط یه اسکریپت پایتونه که ران کردنش باعث میشه به root دسترسی مستقیم پیدا کنین ...!

این یک مقالهٔ پژوهشی مهم از James Kettle (مدیر تحقیقاتی PortSwigger) است که در اوت ۲۰۲۵ منتشر شد. در ادامه، خلاصه‌ای از ایده‌های کلیدی آن آمده است: استدلال اصلی پروتکل HTTP/1.1 ذاتاً ناامن است و مرتباً میلیون‌ها وب‌سایت را در معرض تصاحب مخرب قرار می‌دهد. شش سال تلاش برای کاهش این مشکل فقط آن را پنهان کرده، اما موفق به حلش نشده است. مقاله استدلال می‌کند که HTTP/1.1 باید کنار گذاشته شود و برای ارتباطات upstream از HTTP/2 یا نسخه‌های جدیدتر استفاده شود. نقص مرگبار مرزهای درخواست‌ها در HTTP/1.1 بسیار ضعیف هستند — درخواست‌ها صرفاً روی اتصال TCP/TLS زیربنایی به هم چسبانده می‌شوند و هیچ جداکنندهٔ واقعی ندارند، ضمن اینکه چندین روش مختلف برای تعیین طول آن‌ها وجود دارد. وقتی reverse proxyها درخواست‌های چند کاربر را روی اتصال‌های مشترک عبور می‌دهند، یک اختلاف کوچک در parser بین سرور front-end و back-end به مهاجم اجازه می‌دهد دادهٔ مخرب را به ابتدای درخواست کاربران دیگر تزریق کند — که اغلب منجر به تصاحب کامل سایت می‌شود. چرا راهکارهای فعلی شکست می‌خورند سرورها و CDNها معمولاً ادعا می‌کنند از HTTP/2 پشتیبانی می‌کنند، اما در عمل درخواست‌های HTTP/2 ورودی را برای انتقال upstream به HTTP/1.1 تبدیل (downgrade) می‌کنند و در نتیجه بیشتر مزایای امنیتی از بین می‌رود. دفاع‌های مبتنی بر WAF نیز از الگوهای regex استفاده می‌کنند که به‌راحتی قابل دور زدن هستند و صرفاً «توهم امنیت» ایجاد می‌کنند. کلاس‌های جدید حمله معرفی‌شده 1. شناسایی اختلاف Parser یک ابزار متن‌باز جدید به نام HTTP Request Smuggler v3.0 به‌صورت سیستماتیک اختلاف‌های V-H (Visible-Hidden) و H-V (Hidden-Visible) بین parserهای front-end و back-end را بررسی می‌کند و امکان ایجاد desyncهای نوع CL.0 را فراهم می‌کند؛ حملاتی که WAFها معمولاً جلویشان را نمی‌گیرند. 2. حملات Desync نوع 0.CL قبلاً تصور می‌شد این حملات قابل بهره‌برداری نیستند، چون باعث deadlock می‌شوند. کلید فرار از deadlock در 0.CL پیدا کردن یک «early-response gadget» است — یعنی راهی برای وادار کردن back-end به پاسخ دادن قبل از دریافت کامل body. یکی از نمونه‌های کشف‌شده: درخواست مسیر /con روی IIS باعث فعال شدن یک رفتار قدیمی ویندوز می‌شود که پاسخ زودهنگام ایجاد می‌کند. تکنیکی به نام «double-desync» دو درخواست را زنجیره می‌کند تا حملهٔ 0.CL را به یک حملهٔ عملیاتی و قابل‌استفاده از نوع CL.0 تبدیل کند. 3. حملات Desync مبتنی بر Expect هدر Expect: 100-continue درخواست HTTP را به یک فرآیند دو مرحله‌ای تبدیل می‌کند و مدیریت صحیح آن برای reverse proxyها بسیار پیچیده است. مشخص شد که هم هدرهای Expect معمولی و هم نسخه‌های obfuscated آن می‌توانند روی زیرساخت‌های بزرگ باعث desyncهای نوع 0.CL و CL.0 شوند. یافته‌های مهم در دنیای واقعی Cloudflare: یک desync از نوع H2.0 در زیرساخت داخلی Cloudflare بیش از ۲۴ میلیون وب‌سایت را در معرض تصاحب کامل قرار داد. مشکل ظرف چند ساعت patch شد و ۷۰۰۰ دلار bounty پرداخت شد. Akamai CDN: یک desync از نوع CL.0 از طریق هدر Expect مبهم‌شده (CVE-2025-32094) تعداد بسیار زیادی از سایت‌های میزبانی‌شده روی Akamai را تحت تأثیر قرار داد. در مجموع ۷۴ bounty جداگانه ثبت شد که مجموعاً ۲۲۱ هزار دلار پرداخت داشت و رفع کامل مشکل ۶۵ روز زمان برد. Netlify: یک آسیب‌پذیری CL.0 RQP باعث شد جریان مداومی از پاسخ‌ها از تمام وب‌سایت‌های CDN نتلیفای ارسال شود و tokenهای احراز هویت و محتوای سایت‌های ثالث افشا گردد. همچنین سرویس‌های: T-Mobile GitLab LastPass (auth.lastpass.com) نیز از طریق desyncهای مبتنی بر Expect مورد نفوذ قرار گرفتند. مجموع bountyهای این تحقیق: بیش از ۳۵۰ هزار دلار راه‌حل HTTP/2 یک پروتکل باینری است که دربارهٔ طول پیام‌ها هیچ ابهامی ندارد؛ به همین دلیل احتمال بروز آسیب‌پذیری‌های desync در آن بسیار کمتر است. اما downgrade کردن HTTP/2 — یعنی زمانی که front-end با کلاینت HTTP/2 صحبت می‌کند ولی upstream را به HTTP/1.1 بازنویسی می‌کند — تقریباً مزیت امنیتی خاصی ندارد و حتی سایت‌ها را بیشتر در معرض خطر قرار می‌دهد. فروشنده‌ها و سرویس‌هایی که از HTTP/2 در upstream پشتیبانی می‌کنند: HAProxy F5 Google Cloud Imperva Apache (به‌صورت آزمایشی) Cloudflare (هرچند هنوز در داخل از HTTP/1 استفاده می‌کند) سرویس‌هایی که هنوز upstream HTTP/2 ندارند: nginx Akamai CloudFront Fastly پیام پایانی مقاله:

«حملات desync بیشتری همیشه در راه هستند»

و تنها راه‌حل واقعی این است که HTTP/1.1 در ارتباطات upstream کاملاً حذف شود.

یه مقاله مهم پیدا کردم که خالی از لطف نیست بدونیم. چرا نباید از HTTP 1.1 استفاده کرد و خطرناک است؟

دقیقا داستان همینه

واقعا چی باید گفت فکرشو بکن مثل اینه تو حق داری نفس بکشی بیان دی اکسید کربن بزنن توی هوا بعد بیان قیمت درخت رو زیاد کنن یا بیان اکسیژن بفروشن دقیقا یه چیزی مثل اینه

اینترنت پرو خیانت به مردمه، هرکسی هم که بگیره فقط شرایط رو برای بدتر شدن همین شرایط هموار کرده

تازه میگن اینترنت احتمالااااا ۴۰ تا ۹۰ روز دیگه برمیگرده حالت قبل ای بر پدرشون ...

🔥 ابزار Moon: مدیریت پروژه های monorepo بعد از تست تمام ابزار های مدیریت، بهترین‌شون رو اوردم بهتون معرفی کنم.

این ابزار فقط کم مونده بره نون بگیره بیاد.

چند زبانه برخلاف بقیه ابزارها، تمام زبان هارو ساپورت میکنه. یه CI/CD کامله درحد یک github actions قابلیت بهتون میده. میتونین دقیقا مثل اون task ( همون job ) تعریف کنین. به هم وابسته‌شون کنین. براشون متغییر های env و secret مشخص کنین. و ... به کد شما کاری نداره کانفیگ کردنش به کد شما کاری نداره. فقط به فایل های خودش ( که moon.yml هستن ) کار داره. برعکس بقیه ابزار ها که بعد یه مدت کدتونو خراب میکنن. قدرت caching قبل از بیلد کردن پروژه‌تون، بررسی میکنه که اصلا کدتون تغییری داشته یا نه؟ برای ادیتور ضعفی ایجاد نمیکنه توی بیشتر ابزار ها، شما مجبور بودین کل پروژه رو با ادیتور باز کنید. اما اینجا، فقط بخشی که میخواید رو باز کنین، و با کامند های ساده از همونجا کل پروژه رو مدیریت کنین. داکیومنت: https://moonrepo.dev/moon گیتهاب: https://github.com/moonrepo/moon @CodingLovers_OFF

پروژه های پلی‌ریپو که جزئیات خاصی ندارن. پس میریم سراغ مونوریپو. 🔥 ابزار های مدیریت monorepo برای مدیریت کردن این پروژه ها خیلی حیاتی‌عه. چندین ابزار وجود داره: - Turborepo - Nx - Lerna - pnpm workspaces - Bazel از اونجایی که همشون مزخرف هستن و دردسر هایی دارن که به مرور برنامه نویس رو خسته میکنن، میریم سراغ اصل کاری، یعنی Moon ( Moonrepo ).

✨️ نقاط قوت مونوریپو - اشتراک‌گذاری کد: کد مشترک رو یه بار مینویسی و همه پروژه ها ازش استفاده میکنن. - ریفکتور راحت تر: وقتی یه تابع یا تایپ رو عوض میکنی، همون لحظه میبینی کجاها خراب میشه. - یک CI/CD برای همه: یه pipeline داری که همه‌چیز رو مدیریت میکنه. - همکاری تیمی راحت‌تر: یه نفر میتونه همزمان روی چند بخش کار کنه.

✅️ اگه تنهایی یه پروژه کامل رو داری میاری بالا، برات فوق‌العادست؛ یا حتی برای تیم های ۲ ۳ نفره.

✨️ نقاط قوت پلی‌ریپو - استقلال کامل: هر پروژه زندگی مستقل خودشو داره. به کسی کاری نداره. - تیم های مستقل: هر تیم میتونه با ریتم خودش کار کنه. - مدیریت دسترسی راحت‌تر: میتونی مشخص کنی چه کسی به چه پروژه ای دسترسی داشته باشه.

✅️ برای تیم هایی که تعدادشون زیاده و گروهی سر هر بخش کار میکنن فوق‌العادست‌.

💥 ترکیب هردو پروژه های خیلی بزرگ، ترکیبی از هردو هستن. شرکت های بزرگی مثل گوگل همینکار رو میکنن. یک تیم بزرگ، تقسیم به تیم های کوچیک تر میشن. کل تیم روی یک Polyrepo کار میکنه، و هر بخش خودش یه Monorepo هست...

🗂️ سازماندهی پروژه های بزرگ

وقتی یک پروژه، چند تا پروژس :/

یکی از چالش هایی که هرکی بزودی باهاش روبرو میشه، اینه که از یه جایی دیگه پروژه هات فقط یه بخش نیست. یه پروژه ممکنه از تنها یک بخش تشکیل بشه، یا ممکنه یک چیز خیلی بزرگی باشه. اینارو باید کجا جا داد که ساختار تمیز در بیاد؟ 🚀 شروع: Monorepo vs Polyrepo - 📦 پلی‌ریپو: یعنی هر پروژه، کامل از بقیه جداست و ریپو و کانفیگ خودشو داره. در نگاه اول خیلی تمیزه، برای اپلیکیشن ها مناسبه. اما وقتی بخوای یک config یا کد مشترکی رو استفاده کنی، چیزی رو بین‌شون sync کنی، میفهمی عجب اشتباهی کردی! 😅 - 🏠 مونوریپو: یعنی همه‌چیز زیر یه سقف. چندین ابزار برای مدیریت همین ساخته شدن. اینجوری میتونی کد مشترک رو یه بار بنویسی و همه جا استفادش کنی. کانفیگ هارو sync کنی، با یک کامند همه چی رو ران کنی و .. 📝 جمع بندی پست اول سازماندهی پروژه‌های چندبخشی یه علم دقیق نیست، یه هنره. ولی اگه از اول یه ساختار منطقی داشته باشی، کد مشترک رو جدا کنی، و قراردادهای روشنی بین بخش‌ها تعریف کنی خیلی از دردسرهای بعدی رو از خودت دور کردی. پروژه بزرگ می‌شه ولی نه لزوماً پیچیده تر @CodingLovers_OFF

تاحالا به این فکر کردین که این پروژه های بزرگ، که خودشون از چند پروژه کوچیک تشکیل میشن، چجوری سازمان‌دهی میشن؟ مثلا یه سایت که از ۳ بخش تشکیل میشه: - پروژه فرانت‌اند - پروژه بک‌اند - پروژه فرانت داشبورد واسه هرکدوم یه ریپوزیتوری جدا میسازن مدیریت میکنن؟ یا یجا؟ همچین تجربه ای داشتین؟