Mr. Nothing
نمی دونم چرا انقد ذوق داشتم😂😂
ولی خب دیگه حمایته رو بکنید
اسیب پذیری های جدید و مراحل جدید و اضافه کنم لذتشو ببرید
اسیب پذیری های جدید و مراحل جدید و اضافه کنم لذتشو ببرید
❤1
امروز ساخت و تست Void Lab بالاخره تموم شد.
ایدهی این پروژه از قبلِ جنگ توی ذهنم بود و از همون اول تصمیم داشتم تا جای ممکن از AI کمترین استفاده رو بکنم.
تا همین امروز هم شدیداً مخالف Vibe Coding بودم. اما بعد از دیدن ویدیوی جادی و همچنین خواندن نظر لینوس توروالدز دربارهی Vibe Coding، واقعاً دیدگاهم عوض شد.
بعد با خودم گفتم: واقعاً منِ ۱۷ ساله قراره نظر یکی مثل لینوس توروالدز، خالق لینوکس، رو رد کنم؟
برای همین، توی آپدیتهای بعدی Void Lab قطعاً از Vibe Coding استفاده میکنم؛ نه برای سادهتر کردن کار، بلکه برای اینکه زمان بیشتری برای طراحی چالشهای سختتر و توسعهی بخشهای پیچیدهتر پروژه داشته باشم.
اگر به این موضوع علاقه دارید، این مقاله را هم بخوانید:
https://canartuc.medium.com/linus-torvalds-on-vibe-coding-fine-for-learning-terrible-for-production-6feb7b166b02
ایدهی این پروژه از قبلِ جنگ توی ذهنم بود و از همون اول تصمیم داشتم تا جای ممکن از AI کمترین استفاده رو بکنم.
تا همین امروز هم شدیداً مخالف Vibe Coding بودم. اما بعد از دیدن ویدیوی جادی و همچنین خواندن نظر لینوس توروالدز دربارهی Vibe Coding، واقعاً دیدگاهم عوض شد.
بعد با خودم گفتم: واقعاً منِ ۱۷ ساله قراره نظر یکی مثل لینوس توروالدز، خالق لینوکس، رو رد کنم؟
برای همین، توی آپدیتهای بعدی Void Lab قطعاً از Vibe Coding استفاده میکنم؛ نه برای سادهتر کردن کار، بلکه برای اینکه زمان بیشتری برای طراحی چالشهای سختتر و توسعهی بخشهای پیچیدهتر پروژه داشته باشم.
اگر به این موضوع علاقه دارید، این مقاله را هم بخوانید:
https://canartuc.medium.com/linus-torvalds-on-vibe-coding-fine-for-learning-terrible-for-production-6feb7b166b02
Medium
Linus Torvalds on Vibe Coding: Fine for Learning, Terrible for Production
Linus Torvalds calls vibe coding ‘fairly positive’ for learning but ‘horrible’ for production. Why the Linux creator’s maintenance warning…
🔥3
وقتی صحبت از آسیبپذیری SSRF (Server-Side Request Forgery) میشود، معمولاً اولین راهکار دفاعی، محدود کردن URLهای ورودی و اعتبارسنجی آنهاست. با این حال، تجربه نشان داده که بسیاری از این مکانیزمها بهدلیل پیادهسازی نادرست، قابل دور زدن هستند. به همین دلیل، آشنایی با مفهوم SSRF Bypass برای هر کسی که در حوزه امنیت وب فعالیت میکند، ضروری است.
منظور از SSRF Bypass، شناخت روشهایی است که ممکن است باعث شوند یک فیلتر یا مکانیزم اعتبارسنجی، مقصد واقعی یک درخواست را بهدرستی تشخیص ندهد. این موضوع میتواند به دلایل مختلفی مانند تفاوت در نحوه پردازش URLها، اعتبارسنجی ناقص ورودی یا خطاهای منطقی در طراحی برنامه رخ دهد.
در ارزیابیهای امنیتی، هدف از بررسی این موارد صرفاً پیدا کردن نقاط ضعف و گزارش آنهاست تا قبل از سوءاستفاده مهاجمان، برطرف شوند. به همین دلیل، توسعهدهندگان باید علاوه بر اعتبارسنجی صحیح ورودیها، از فهرست مجاز (Allowlist)، محدودسازی دسترسی سرور به شبکههای داخلی و بررسی دقیق مقصد درخواستها استفاده کنند.
در نهایت، شناخت مفاهیم مربوط به SSRF Bypass فقط برای اجرای تستهای امنیتی مجاز اهمیت ندارد؛ بلکه به درک بهتر نحوه عملکرد مکانیزمهای دفاعی نیز کمک میکند. هرچه این شناخت عمیقتر باشد، طراحی و پیادهسازی برنامههای امنتر نیز سادهتر خواهد بود.
منظور از SSRF Bypass، شناخت روشهایی است که ممکن است باعث شوند یک فیلتر یا مکانیزم اعتبارسنجی، مقصد واقعی یک درخواست را بهدرستی تشخیص ندهد. این موضوع میتواند به دلایل مختلفی مانند تفاوت در نحوه پردازش URLها، اعتبارسنجی ناقص ورودی یا خطاهای منطقی در طراحی برنامه رخ دهد.
در ارزیابیهای امنیتی، هدف از بررسی این موارد صرفاً پیدا کردن نقاط ضعف و گزارش آنهاست تا قبل از سوءاستفاده مهاجمان، برطرف شوند. به همین دلیل، توسعهدهندگان باید علاوه بر اعتبارسنجی صحیح ورودیها، از فهرست مجاز (Allowlist)، محدودسازی دسترسی سرور به شبکههای داخلی و بررسی دقیق مقصد درخواستها استفاده کنند.
در نهایت، شناخت مفاهیم مربوط به SSRF Bypass فقط برای اجرای تستهای امنیتی مجاز اهمیت ندارد؛ بلکه به درک بهتر نحوه عملکرد مکانیزمهای دفاعی نیز کمک میکند. هرچه این شناخت عمیقتر باشد، طراحی و پیادهسازی برنامههای امنتر نیز سادهتر خواهد بود.
👏3
Mr. Nothing
Video
توی یک لابراتوار هانتر ابتدا درخواستی را که شامل یک پارامتر URL است با Burp Suite Intercept میکند. سپس بررسی میکند که آیا سرور واقعاً از آن URL برای برقراری ارتباط استفاده میکند یا خیر.
اگر مشخص شود که درخواست از سمت سرور ارسال میشود، هانتر رفتار برنامه را در شرایط مختلف ارزیابی میکند برای مثال بررسی میکند که آیا برنامه اعتبارسنجی مناسبی روی مقصد درخواست انجام میدهد، خطاها را بهدرستی مدیریت میکند و از ارسال درخواست به منابع غیرمجاز جلوگیری میکند یا خیر.
اگر مشخص شود که درخواست از سمت سرور ارسال میشود، هانتر رفتار برنامه را در شرایط مختلف ارزیابی میکند برای مثال بررسی میکند که آیا برنامه اعتبارسنجی مناسبی روی مقصد درخواست انجام میدهد، خطاها را بهدرستی مدیریت میکند و از ارسال درخواست به منابع غیرمجاز جلوگیری میکند یا خیر.
🌭3
Mr. Nothing
Video
یه مثال
CVE-2021-27905 – SSRF در Apache Solr
در این آسیبپذیری ، یکی از مولفه های تکرار Replication در Apache Solr ورودی مربوط به آدرس مقصد را به اندازه کافی اعتبارسنجی نمیکرد. در نتیجه یک هانتر از راه دور میتوانست سرور Solr را وادار کند که درخواستهای HTTP را به مقصدهای دلخواه ارسال کنه این نقص با شناسه CWE-918 (SSRF) ثبت شد.
چرا مهم بود؟
مشکل اصلی فقط ارسال یک درخواست HTTP نبود سرور Solr معمولاً در شبکه ای قرار دارد که به سرویسهایی دسترسی دارد که از اینترنت قابل مشاهده نیستند بنابراین اگر برنامه درخواستی را از طرف هانتر ارسال کند ممکن است به سرویسهای داخلی پنلهای مدیریتی یا سرویسهای زیرساختی دسترسی پیدا کند روت کیس آنالیز 😂
منبع:SentinelOne
CVE-2021-27905 – SSRF در Apache Solr
در این آسیبپذیری ، یکی از مولفه های تکرار Replication در Apache Solr ورودی مربوط به آدرس مقصد را به اندازه کافی اعتبارسنجی نمیکرد. در نتیجه یک هانتر از راه دور میتوانست سرور Solr را وادار کند که درخواستهای HTTP را به مقصدهای دلخواه ارسال کنه این نقص با شناسه CWE-918 (SSRF) ثبت شد.
چرا مهم بود؟
مشکل اصلی فقط ارسال یک درخواست HTTP نبود سرور Solr معمولاً در شبکه ای قرار دارد که به سرویسهایی دسترسی دارد که از اینترنت قابل مشاهده نیستند بنابراین اگر برنامه درخواستی را از طرف هانتر ارسال کند ممکن است به سرویسهای داخلی پنلهای مدیریتی یا سرویسهای زیرساختی دسترسی پیدا کند روت کیس آنالیز 😂
منبع:SentinelOne
💋3
Mr. Nothing
یه مثال CVE-2021-27905 – SSRF در Apache Solr در این آسیبپذیری ، یکی از مولفه های تکرار Replication در Apache Solr ورودی مربوط به آدرس مقصد را به اندازه کافی اعتبارسنجی نمیکرد. در نتیجه یک هانتر از راه دور میتوانست سرور Solr را وادار کند که درخواستهای…
نمونه های دیگه:
CVE-2021-27905 (Apache Solr)
CVE-2024-29198 (GeoServer)
CVE-2024-29736 (Apache CXF)
CVE-2021-27905 (Apache Solr)
CVE-2024-29198 (GeoServer)
CVE-2024-29736 (Apache CXF)
🎃3
پشت این سیستمعامل عجیب، داستان یه آدم خیلی خاصه تری دیویس
تری دیویس یه برنامهنویس فوقالعاده بااستعداد بود که تقریباً تنهایی یه سیستمعامل کامل رو از صفر ساخت از هسته گرفته تا زبان برنامهنویسی خودش اسم این سیستمعامل رو گذاشت TempleOS و با یه فلسفه کاملاً متفاوت طراحیاش کرد.
شاید از نظر ظاهر و امکانات با سیستمعاملهای امروزی قابل مقایسه نباشه ولی چیزی که TempleOS رو خاص میکنه اینه که یه نفر تونسته با دست خودش یه دنیای کامپیوتری کامل بسازه برای خیلیها این پروژه نشوندهندهی خلاقیت پشتکار و نبوغ عجیب یه برنامهنویسه.
داستان تری دیویس هم به اندازه خود TempleOS عجیب و پر از فراز و نشیبه ترکیبی از استعداد فوقالعاده تنهایی و یک ذهن کاملاً متفاوت.
تری دیویس یه برنامهنویس فوقالعاده بااستعداد بود که تقریباً تنهایی یه سیستمعامل کامل رو از صفر ساخت از هسته گرفته تا زبان برنامهنویسی خودش اسم این سیستمعامل رو گذاشت TempleOS و با یه فلسفه کاملاً متفاوت طراحیاش کرد.
شاید از نظر ظاهر و امکانات با سیستمعاملهای امروزی قابل مقایسه نباشه ولی چیزی که TempleOS رو خاص میکنه اینه که یه نفر تونسته با دست خودش یه دنیای کامپیوتری کامل بسازه برای خیلیها این پروژه نشوندهندهی خلاقیت پشتکار و نبوغ عجیب یه برنامهنویسه.
داستان تری دیویس هم به اندازه خود TempleOS عجیب و پر از فراز و نشیبه ترکیبی از استعداد فوقالعاده تنهایی و یک ذهن کاملاً متفاوت.
❤3
Mr. Nothing
تری دیویس
داستان زندگی تری دیویس بر گرفته از هوش مصنوعی:
Terry A. Davis یکی از عجیبترین و بحثبرانگیزترین شخصیتهای تاریخ برنامهنویسی بود؛ داستان زندگیاش ترکیبی از استعداد فنی خیلی بالا، خلاقیت، و مشکلات جدی در زندگی شخصیاش است.
Terry A. Davis در سال ۱۹۶۹ در آمریکا به دنیا آمد. از کودکی علاقه زیادی به کامپیوتر داشت و از همان سالهای جوانی برنامهنویسی میکرد. او در رشته مهندسی برق تحصیل کرد و بعدها بهعنوان برنامهنویس در شرکتهای مختلف کار کرد.
در دهه ۲۰۰۰ زندگی او تغییر بزرگی کرد. تری دچار مشکلات شدید سلامت روانی شد و بعدها تشخیص داده شد که به schizophrenia مبتلاست. خودش هم درباره تجربههای ذهنی و مذهبی خاصی صحبت میکرد و باور داشت که ارتباطهایی الهی دریافت میکند. همین باورها روی بزرگترین پروژه زندگیاش تأثیر گذاشت.
او سالها تقریباً بهتنهایی روی چیزی کار کرد که بعدها نامش را TempleOS گذاشت. تری فقط یک سیستمعامل آماده نساخت؛ تقریباً همه چیز را خودش نوشت: هسته، کامپایلر، کتابخانهها، ابزارها و زبان برنامهنویسی مخصوص خودش یعنی HolyC. این کار از نظر فنی برای یک نفر پروژهای بسیار عظیم محسوب میشود.
TempleOS در نهایت به یک سیستمعامل کوچک، ساده و کاملاً متفاوت تبدیل شد؛ نه برای رقابت با ویندوز یا لینوکس، بلکه بیشتر بهعنوان یک اثر شخصی و یک دنیای کامپیوتری ساختهشده توسط خودش.
سالهای آخر زندگی تری سخت گذشت. او در اینترنت فعال بود، ویدئوها و نوشتههای زیادی منتشر میکرد، اما به دلیل شرایط روحی و رفتارهای غیرمعمولش، خیلیها نمیدانستند با او چگونه برخورد کنند. در سال ۲۰۱۸، در سن ۴۸ سالگی، هنگام راه رفتن کنار ریل قطار در کالیفرنیا با قطار برخورد کرد و از دنیا رفت.
امروز خیلی از برنامهنویسها TempleOS را فقط یک سیستمعامل عجیب نمیبینند؛ آن را نشانهای از این میدانند که یک نفر با وجود محدودیتهای زیاد، توانست یک پروژه کاملاً شخصی و از صفر خلق کند. داستان تری دیویس همزمان الهامبخش و غمانگیز است: داستان یک ذهن بسیار خلاق که مسیر زندگیاش بسیار متفاوت از دیگران بود.
Terry A. Davis یکی از عجیبترین و بحثبرانگیزترین شخصیتهای تاریخ برنامهنویسی بود؛ داستان زندگیاش ترکیبی از استعداد فنی خیلی بالا، خلاقیت، و مشکلات جدی در زندگی شخصیاش است.
Terry A. Davis در سال ۱۹۶۹ در آمریکا به دنیا آمد. از کودکی علاقه زیادی به کامپیوتر داشت و از همان سالهای جوانی برنامهنویسی میکرد. او در رشته مهندسی برق تحصیل کرد و بعدها بهعنوان برنامهنویس در شرکتهای مختلف کار کرد.
در دهه ۲۰۰۰ زندگی او تغییر بزرگی کرد. تری دچار مشکلات شدید سلامت روانی شد و بعدها تشخیص داده شد که به schizophrenia مبتلاست. خودش هم درباره تجربههای ذهنی و مذهبی خاصی صحبت میکرد و باور داشت که ارتباطهایی الهی دریافت میکند. همین باورها روی بزرگترین پروژه زندگیاش تأثیر گذاشت.
او سالها تقریباً بهتنهایی روی چیزی کار کرد که بعدها نامش را TempleOS گذاشت. تری فقط یک سیستمعامل آماده نساخت؛ تقریباً همه چیز را خودش نوشت: هسته، کامپایلر، کتابخانهها، ابزارها و زبان برنامهنویسی مخصوص خودش یعنی HolyC. این کار از نظر فنی برای یک نفر پروژهای بسیار عظیم محسوب میشود.
TempleOS در نهایت به یک سیستمعامل کوچک، ساده و کاملاً متفاوت تبدیل شد؛ نه برای رقابت با ویندوز یا لینوکس، بلکه بیشتر بهعنوان یک اثر شخصی و یک دنیای کامپیوتری ساختهشده توسط خودش.
سالهای آخر زندگی تری سخت گذشت. او در اینترنت فعال بود، ویدئوها و نوشتههای زیادی منتشر میکرد، اما به دلیل شرایط روحی و رفتارهای غیرمعمولش، خیلیها نمیدانستند با او چگونه برخورد کنند. در سال ۲۰۱۸، در سن ۴۸ سالگی، هنگام راه رفتن کنار ریل قطار در کالیفرنیا با قطار برخورد کرد و از دنیا رفت.
امروز خیلی از برنامهنویسها TempleOS را فقط یک سیستمعامل عجیب نمیبینند؛ آن را نشانهای از این میدانند که یک نفر با وجود محدودیتهای زیاد، توانست یک پروژه کاملاً شخصی و از صفر خلق کند. داستان تری دیویس همزمان الهامبخش و غمانگیز است: داستان یک ذهن بسیار خلاق که مسیر زندگیاش بسیار متفاوت از دیگران بود.
❤3
Mr. Nothing
Video
خلاصه داستان اینه طرف انقدر خفن بود که فقط نیومد یه برنامه بنویسه خودش یه زبان برنامهنویسی(holy c) ساخت بعد با همون زبان هستهی سیستمعامل خودش رو نوشت و در نهایت یه سیستمعامل کامل بر پایهی همون ساخت
یعنی از صفر تا صد یک دنیای کامپیوتری رو خودش خلق کرد
بعد ما اینجاییم که اگه چندتا اکستنشن VS Code و چندتا ابزار هوش مصنوعی کنارمون نباشه، بعضی وقتا حتی با مفاهیم پایهای مثل حافظه استک و دیباگ کردن هم به مشکل میخوریم!
فرقش فقط توی کدنویسی نبود فرقش این بود که اون تصمیم گرفت خودش همهچیز رو بسازه.
یعنی از صفر تا صد یک دنیای کامپیوتری رو خودش خلق کرد
بعد ما اینجاییم که اگه چندتا اکستنشن VS Code و چندتا ابزار هوش مصنوعی کنارمون نباشه، بعضی وقتا حتی با مفاهیم پایهای مثل حافظه استک و دیباگ کردن هم به مشکل میخوریم!
فرقش فقط توی کدنویسی نبود فرقش این بود که اون تصمیم گرفت خودش همهچیز رو بسازه.
❤3