یه مثال
CVE-2021-27905 – SSRF در Apache Solr

در این آسیب‌پذیری ، یکی از مولفه های تکرار Replication در Apache Solr ورودی مربوط به آدرس مقصد را به اندازه کافی اعتبارسنجی نمی‌کرد. در نتیجه یک هانتر از راه دور می‌توانست سرور Solr را وادار کند که درخواست‌های HTTP را به مقصدهای دلخواه ارسال کنه این نقص با شناسه CWE-918 (SSRF) ثبت شد.
چرا مهم بود؟
مشکل اصلی فقط ارسال یک درخواست HTTP نبود سرور Solr معمولاً در شبکه‌ ای قرار دارد که به سرویس‌هایی دسترسی دارد که از اینترنت قابل مشاهده نیستند بنابراین اگر برنامه درخواستی را از طرف هانتر ارسال کند ممکن است به سرویس‌های داخلی پنل‌های مدیریتی یا سرویس‌های زیرساختی دسترسی پیدا کند روت کیس آنالیز 😂
منبع:SentinelOne

نمونه های دیگه:
CVE-2021-27905 (Apache Solr)
CVE-2024-29198 (GeoServer)
CVE-2024-29736 (Apache CXF)

بیشتر مطالب از این پس در مدیوم منتشر خواهند شد.

Cipher guard

New update

Source
∆ Join VOID ∆

تری دیویس

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

داستان زندگی تری دیویس بر گرفته از هوش مصنوعی:
Terry A. Davis یکی از عجیب‌ترین و بحث‌برانگیزترین شخصیت‌های تاریخ برنامه‌نویسی بود؛ داستان زندگی‌اش ترکیبی از استعداد فنی خیلی بالا، خلاقیت، و مشکلات جدی در زندگی شخصی‌اش است.

Terry A. Davis در سال ۱۹۶۹ در آمریکا به دنیا آمد. از کودکی علاقه زیادی به کامپیوتر داشت و از همان سال‌های جوانی برنامه‌نویسی می‌کرد. او در رشته مهندسی برق تحصیل کرد و بعدها به‌عنوان برنامه‌نویس در شرکت‌های مختلف کار کرد.

در دهه ۲۰۰۰ زندگی او تغییر بزرگی کرد. تری دچار مشکلات شدید سلامت روانی شد و بعدها تشخیص داده شد که به schizophrenia مبتلاست. خودش هم درباره تجربه‌های ذهنی و مذهبی خاصی صحبت می‌کرد و باور داشت که ارتباط‌هایی الهی دریافت می‌کند. همین باورها روی بزرگ‌ترین پروژه زندگی‌اش تأثیر گذاشت.

او سال‌ها تقریباً به‌تنهایی روی چیزی کار کرد که بعدها نامش را TempleOS گذاشت. تری فقط یک سیستم‌عامل آماده نساخت؛ تقریباً همه چیز را خودش نوشت: هسته، کامپایلر، کتابخانه‌ها، ابزارها و زبان برنامه‌نویسی مخصوص خودش یعنی HolyC. این کار از نظر فنی برای یک نفر پروژه‌ای بسیار عظیم محسوب می‌شود.

TempleOS در نهایت به یک سیستم‌عامل کوچک، ساده و کاملاً متفاوت تبدیل شد؛ نه برای رقابت با ویندوز یا لینوکس، بلکه بیشتر به‌عنوان یک اثر شخصی و یک دنیای کامپیوتری ساخته‌شده توسط خودش.

سال‌های آخر زندگی تری سخت گذشت. او در اینترنت فعال بود، ویدئوها و نوشته‌های زیادی منتشر می‌کرد، اما به دلیل شرایط روحی و رفتارهای غیرمعمولش، خیلی‌ها نمی‌دانستند با او چگونه برخورد کنند. در سال ۲۰۱۸، در سن ۴۸ سالگی، هنگام راه رفتن کنار ریل قطار در کالیفرنیا با قطار برخورد کرد و از دنیا رفت.

امروز خیلی از برنامه‌نویس‌ها TempleOS را فقط یک سیستم‌عامل عجیب نمی‌بینند؛ آن را نشانه‌ای از این می‌دانند که یک نفر با وجود محدودیت‌های زیاد، توانست یک پروژه کاملاً شخصی و از صفر خلق کند. داستان تری دیویس همزمان الهام‌بخش و غم‌انگیز است: داستان یک ذهن بسیار خلاق که مسیر زندگی‌اش بسیار متفاوت از دیگران بود.

خلاصه داستان اینه طرف انقدر خفن بود که فقط نیومد یه برنامه بنویسه خودش یه زبان برنامه‌نویسی(holy c) ساخت بعد با همون زبان هسته‌ی سیستم‌عامل خودش رو نوشت و در نهایت یه سیستم‌عامل کامل بر پایه‌ی همون ساخت
یعنی از صفر تا صد یک دنیای کامپیوتری رو خودش خلق کرد
بعد ما اینجاییم که اگه چندتا اکستنشن VS Code و چندتا ابزار هوش مصنوعی کنارمون نباشه، بعضی وقتا حتی با مفاهیم پایه‌ای مثل حافظه استک و دیباگ کردن هم به مشکل می‌خوریم!
فرقش فقط توی کدنویسی نبود فرقش این بود که اون تصمیم گرفت خودش همه‌چیز رو بسازه.

سوال اینه چرا انقد قیافش شبی جفری اپستینه؟

بنده خدا هم همیشه توهم اینو داشت سیا دنبالشه

والا

این روزا

اگه کانال دارید برای فروش به این آیدی پیام بدید
@ilianox
حتما 1.5k+ member

آپدیت جدید می‌خوایم بدیم کسی ایده ای داره ؟ حتما اسمشو توی اپ تگ میکنیم

۸ میلیون برای RCE
ایران واقعاً جای عجیبیه
جالب‌ تر اینکه گزارش رو ۱۴۰۵/۰۴/۰۳ ارسال کردم و امشب مبلغ رو واریز کردن
باز جای شکرش باقیه که حداقل بانتی رو پرداخت کردن
یه رایتاپ هم امشب وقت کنم می‌زارم توی مدیوم.

خیلی هاتون وقتی وارد portfolio من میشید میگید حتما دستی ریپازتوری هاشو وارد کرده

اما همش بخاطر این ماژوله قسمت بعدی میریم برای توضیح

مرحله اول: تعریف ثابت‌ها

const GITHUB_API = "https://api.github.com";
const CACHE_KEY = "v0id_gh_cache_v1";
const CACHE_TTL_MS = 1000 * 60 * 30;

در این قسمت سه مقدار ثابت تعریف شده است:
GITHUB_API آدرس اصلی API گیت‌هاب است.
CACHE_KEY کلیدی است که برای ذخیره اطلاعات در sessionStorage استفاده می‌شود.
CACHE_TTL_MS مدت اعتبار کش را مشخص می‌کند. مقدار 1000 * 60 * 30 یعنی ۳۰ دقیقه.
بنابراین اگر اطلاعات کمتر از ۳۰ دقیقه قبل دریافت شده باشند، برنامه دوباره به GitHub درخواست ارسال نمی‌کند.
مرحله دوم: ساختار داده‌های کش

interface CachePayload {
  timestamp: number;
  repos: GithubRepo[];
}

این Interface مشخص می‌کند که اطلاعات ذخیره‌شده در مرورگر چه ساختاری دارند.
دو مقدار ذخیره می‌شود:
timestamp زمان ذخیره شدن داده‌ها
repos لیست Repositoryها
نمونه داده‌ای که در sessionStorage ذخیره می‌شود:

{
  "timestamp": 1715000000000,
  "repos": [...]
}

مرحله سوم: خواندن کش

function readCache(): GithubRepo[] | null

اولین کاری که برنامه انجام می‌دهد این است که بررسی کند آیا قبلاً اطلاعاتی ذخیره شده یا خیر.

const raw = sessionStorage.getItem(CACHE_KEY);

اگر هیچ داده‌ای وجود نداشته باشد:

return null;

در غیر این صورت داده JSON به شیء جاوااسکریپت تبدیل می‌شود.

const parsed = JSON.parse(raw);

حالا باید بررسی شود که کش هنوز معتبر است یا نه.

if (Date.now() - parsed.timestamp > CACHE_TTL_MS)

در این خط:
Date.now() زمان فعلی را بر حسب میلی‌ثانیه برمی‌گرداند.
parsed.timestamp زمان ذخیره شدن اطلاعات است.
اگر اختلاف این دو بیشتر از ۳۰ دقیقه باشد، کش منقضی شده است.
در نتیجه:

return null;

اما اگر کمتر از ۳۰ دقیقه گذشته باشد:

return parsed.repos;

و دیگر هیچ درخواستی به GitHub ارسال نمی‌شود.
مرحله چهارم: ذخیره اطلاعات در کش

function writeCache(repos: GithubRepo[])

این تابع بعد از دریافت اطلاعات از GitHub اجرا می‌شود.
ابتدا یک شیء می‌سازد:

const payload = {
    timestamp: Date.now(),
    repos
};

سپس آن را به رشته JSON تبدیل کرده و در sessionStorage ذخیره می‌کند.

sessionStorage.setItem(
    CACHE_KEY,
    JSON.stringify(payload)
);

اگر مرورگر اجازه استفاده از Storage را ندهد، برنامه کرش نمی‌کند و فقط از این مرحله عبور می‌کند.
مرحله پنجم: دریافت اطلاعات از GitHub
اصلی‌ترین قسمت برنامه این تابع است:

fetchGithubRepos(username)

ابتدا کش بررسی می‌شود.

const cached = readCache();

if (cached) {
    return cached;
}

اگر اطلاعات داخل کش موجود باشد، همان داده‌ها برگردانده می‌شوند.
اما اگر کش وجود نداشته باشد، درخواست به GitHub ارسال می‌شود.

fetch(
  `https://api.github.com/users/${username}/repos`
)

در این آدرس، مقدار username جایگزین نام کاربر می‌شود.
مثلاً:

https://api.github.com/users/octocat/repos

GitHub لیست Repositoryهای عمومی این کاربر را برمی‌گرداند.
بررسی موفق بودن درخواست
بعد از دریافت پاسخ، ابتدا وضعیت آن بررسی می‌شود.

if (!res.ok)

اگر پاسخ موفق نباشد (مانند 404 یا 403)، یک Error ساخته می‌شود.
در غیر این صورت اطلاعات JSON خوانده می‌شوند.

const data = await res.json();

مرحله ششم: حذف Repositoryهای Fork
در GitHub ممکن است کاربر پروژه‌های دیگران را Fork کرده باشد.
اگر فقط پروژه‌های اصلی خود کاربر مورد نیاز باشند، از این کد استفاده می‌شود:

const repos = data.filter((r) => !r.fork);

عبارت !r.fork یعنی فقط Repositoryهایی انتخاب شوند که مقدار fork آن‌ها false باشد.
مرحله هفتم: ذخیره نتیجه در کش
بعد از دریافت اطلاعات، آن‌ها در مرورگر ذخیره می‌شوند.

writeCache(repos);

در نتیجه اگر کاربر دوباره صفحه را باز کند، تا ۳۰ دقیقه اطلاعات از Storage خوانده می‌شوند و درخواست جدیدی ارسال نخواهد شد.
مرحله هشتم: مدیریت خطا
اگر اینترنت قطع باشد یا GitHub پاسخ ندهد، برنامه نباید متوقف شود.
به همین دلیل از try...catch استفاده شده است.

catch (err) {
    console.warn(err);
    return [];
}

به جای کرش کردن، یک آرایه خالی برگردانده می‌شود تا رابط کاربری همچنان قابل نمایش باشد.
مرحله نهم: محاسبه آمار Repositoryها
تابع

computeGithubStats()

روی Repositoryهای دریافت‌شده چند آمار تولید می‌کند.
۱- تعداد Repositoryها

repoCount: repos.length

فقط تعداد کل پروژه‌ها را محاسبه می‌کند.
۲- مجموع ستاره‌ها