Forwarded from سید فرندز / برنامه نویسی / هک و امنیت / تکنولوژی (Mohammad Khoshnava)
پست محسن باقری CTO شرکت irantic در لینکدین :
فروش ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه!!!
یکی از نفس‌گیرترین لحظه‌ها در صنعت تیکتینگ، شروع فروش یک ایونت بزرگ هستش.
روی صفحه همه‌چیز ساده به نظر میاد: یک دکمه‌ی "خرید بلیت" و تمام.
ولی پشت صحنه چه اتفاق‌هایی باعث میشه فروشی در این مقیاس به درستی انجام بشه؟ هزاران درخواست در یک لحظه به سرورها هجوم میارن و هر ثانیه‌اش میتونه تعیین‌کننده باشه.
ما سال‌ها در Irantic روی تیکتینگ سینما کار کردیم؛ جایی که بار روی سامانه به‌صورت یکنواخت و تدریجی پخش میشه.
اما وقتی رسیدیم به کنسرت علیرضا قربانی در پارکینگ ورزشگاه آزادی، همه‌چیز فرق کرد.
استقبال عجیب کاربرها، محدود بودن صندلی‌ها و رقابت شدید باعث شد تجربه‌ای کاملاً متفاوت رو پشت سر بذاریم.
اینجا همه‌چیز به چند ثانیه بستگی داشت. باید اپلیکیشن رو برای خرید بیش از صد هزار کاربر همزمان مدیریت می‌کردیم و در عین حال جلوی Race Conditionهایی رو می‌گرفتیم که می‌تونستن کل خرید رو به هم بریزن.
برای رسیدن به این هدف، تغییرات مهمی در سیستم دادیم:
- درخواست‌ها رو با لیست‌ها و کلیدهای مختلف در Redis بازطراحی کردیم تا هر لیست مستقل مدیریت بشه.
-بهینه‌سازی حجم داده‌های اپلیکیشن یکی از سخت‌ترین چالش‌ها بود. ما باید حجم ریسپانس را طوری کاهش می‌دادیم که بدون از دست دادن اطلاعات حیاتی، به اندازه‌ای کوچک بشه که معمولاً در یک سگمنت TCP منتقل بشه. وقتی داده در حجم پایین ارسال میشه، سرعت دریافت بالاتر، تأخیر کمتر و احتمال خطا نیز کمتر خواهد بود .البته در بعضی لحظات، حجم داده بیشتر از چند بایت میشد، ولی همون بهینه‌سازی برای چند ثانیه‌ی طلایی فروش، تفاوت بزرگی ایجاد کرد.
- کش رو طوری تنظیم کردیم که هر لیست با سیاست خودش پاک بشه.
- یک مرحله‌ی میانی به رزرو اضافه کردیم تا متد اصلی سبک‌تر بمونه.
- در فرانت‌اند، مهمترین دغدغه نمایش درست و استفاده بهینه از ریسورس ها در دستگاه‌ها بود. وقتی کاربر روی موبایل یا دسکتاپ وارد میشه، انتظار داره تجربه‌ای روان و بی‌نقص داشته باشه. این یعنی رندر شدن سریع صندلی‌ها، الگوریتم‌های دقیق برای جایگذاری صندلی‌ها در حالت‌های مختلف صفحه، و جلوگیری از افت کیفیت یا کندی. کوچک‌ترین باگ در این بخش می‌تونست کل تجربه خرید رو خراب کنه
- در زیرساخت (DevOps)، پایداری و مانیتورینگ مهمترین بخش برای ما بود. آماده‌سازی برای پیک ترافیک و مانیتورینگ لحظه‌ای باعث شد حتی در اوج فشار، سامانه بدون مشکل کارش رو انجام بده.
- بخش مهم دیگه، انجام استرس‌تست‌های واقعی بود؛ جایی که با شبیه‌سازی بار سنگین روی سامانه، قبل از روز رویداد تمام نقاط ضعف احتمالی رو شناسایی و رفع کردیم. همین تست‌ها باعث شد لحظه‌ی اصلی، غافلگیر نشیم.
نتیجه؟
تمام ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه سولد اوت شد، بدون اینکه تجربه‌ی خرید کاربرها خدشه‌دار بشه.
✅ @SEYED_BAX
فروش ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه!!!
یکی از نفس‌گیرترین لحظه‌ها در صنعت تیکتینگ، شروع فروش یک ایونت بزرگ هستش.
روی صفحه همه‌چیز ساده به نظر میاد: یک دکمه‌ی "خرید بلیت" و تمام.
ولی پشت صحنه چه اتفاق‌هایی باعث میشه فروشی در این مقیاس به درستی انجام بشه؟ هزاران درخواست در یک لحظه به سرورها هجوم میارن و هر ثانیه‌اش میتونه تعیین‌کننده باشه.
ما سال‌ها در Irantic روی تیکتینگ سینما کار کردیم؛ جایی که بار روی سامانه به‌صورت یکنواخت و تدریجی پخش میشه.
اما وقتی رسیدیم به کنسرت علیرضا قربانی در پارکینگ ورزشگاه آزادی، همه‌چیز فرق کرد.
استقبال عجیب کاربرها، محدود بودن صندلی‌ها و رقابت شدید باعث شد تجربه‌ای کاملاً متفاوت رو پشت سر بذاریم.
اینجا همه‌چیز به چند ثانیه بستگی داشت. باید اپلیکیشن رو برای خرید بیش از صد هزار کاربر همزمان مدیریت می‌کردیم و در عین حال جلوی Race Conditionهایی رو می‌گرفتیم که می‌تونستن کل خرید رو به هم بریزن.
برای رسیدن به این هدف، تغییرات مهمی در سیستم دادیم:
- درخواست‌ها رو با لیست‌ها و کلیدهای مختلف در Redis بازطراحی کردیم تا هر لیست مستقل مدیریت بشه.
-بهینه‌سازی حجم داده‌های اپلیکیشن یکی از سخت‌ترین چالش‌ها بود. ما باید حجم ریسپانس را طوری کاهش می‌دادیم که بدون از دست دادن اطلاعات حیاتی، به اندازه‌ای کوچک بشه که معمولاً در یک سگمنت TCP منتقل بشه. وقتی داده در حجم پایین ارسال میشه، سرعت دریافت بالاتر، تأخیر کمتر و احتمال خطا نیز کمتر خواهد بود .البته در بعضی لحظات، حجم داده بیشتر از چند بایت میشد، ولی همون بهینه‌سازی برای چند ثانیه‌ی طلایی فروش، تفاوت بزرگی ایجاد کرد.
- کش رو طوری تنظیم کردیم که هر لیست با سیاست خودش پاک بشه.
- یک مرحله‌ی میانی به رزرو اضافه کردیم تا متد اصلی سبک‌تر بمونه.
- در فرانت‌اند، مهمترین دغدغه نمایش درست و استفاده بهینه از ریسورس ها در دستگاه‌ها بود. وقتی کاربر روی موبایل یا دسکتاپ وارد میشه، انتظار داره تجربه‌ای روان و بی‌نقص داشته باشه. این یعنی رندر شدن سریع صندلی‌ها، الگوریتم‌های دقیق برای جایگذاری صندلی‌ها در حالت‌های مختلف صفحه، و جلوگیری از افت کیفیت یا کندی. کوچک‌ترین باگ در این بخش می‌تونست کل تجربه خرید رو خراب کنه
- در زیرساخت (DevOps)، پایداری و مانیتورینگ مهمترین بخش برای ما بود. آماده‌سازی برای پیک ترافیک و مانیتورینگ لحظه‌ای باعث شد حتی در اوج فشار، سامانه بدون مشکل کارش رو انجام بده.
- بخش مهم دیگه، انجام استرس‌تست‌های واقعی بود؛ جایی که با شبیه‌سازی بار سنگین روی سامانه، قبل از روز رویداد تمام نقاط ضعف احتمالی رو شناسایی و رفع کردیم. همین تست‌ها باعث شد لحظه‌ی اصلی، غافلگیر نشیم.
نتیجه؟
تمام ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه سولد اوت شد، بدون اینکه تجربه‌ی خرید کاربرها خدشه‌دار بشه.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤5👍1
🛡️ محافظت از فرم لاگین با Django-Defender
حملات brute-force 🔐 یکی از رایج ترین روش‌های نفوذ به وبسایت ها هستند
جایی که هکرا با تلاش‌های مکرر سعی میکنن رمز عبور کاربران را حدس بزنند.
کتابخانه‌ی Django-Defender ⚡ ابزاری سبک، سریع و مطمئن برای مقابله با این حملات در پروژه‌های Django است.
✨ امکانات کلیدی
🚫 شمارش تلاش‌های ناموفق ورود و بلاک کردن کاربر یا ip
⚡ استفاده از کش (Redis یا Memcached) برای عملکرد سریع
⏱️ امکان تنظیم تعداد تلاش‌های مجاز و زمان بلاک (cool-off)
📊 ذخیره لاگ‌ها و مشاهده آنها در پنل مدیریت Django
🔐 بلاک بر اساس ip یا ترکیب یوزرنیم + ip
⚙️ نصب و راه‌اندازی
در settings.py تنظیمات پایه رو برای کانفیگ django defender اضافه کنید:
تنظیمات اصلی:
1⃣ DEFENDER_REDIS_URL :
مشخص میکنه داده های تلاش نا موفق کجا ذخیره میشن "redis://127.0.0.1:6379/0" یعنی Redis روی لوکال با پورت 6379 و‌دیتابیس شماره 0 اجرا بشه.
2⃣ DEFENDER_LOGIN_FAILURE_LIMIT:
تعداد دفعاتی که یک کاربر یا ip میتونه رمز اشتباه وارد کنه قبل از اینکه بلاک شه.
مثال: مقدار ۵ → بعد از ۵ تلاش ناموفق، بلاک فعال میشه
3⃣ DEFENDER_COOLOFF_TIME :
مدت زمان بلاک به ثانیه.
به عنوان مثال اینجا ۳۰۰ ثانیه یعنی بعد از بلاک شدن؛کاربر یا ip برای ۵ دقیقه نمیتونه لاگین کنه
4⃣ DEFENDER_LOCK_OUT_BY_COMBINATION_USER_AND_IP :
تعیین میکنه که مکانیزم بلاک چگونه عمل کنه و معیار محدودسازی کاربران چی باشه. مثلا وقتی متغیر روی True تنظیم شه، بلاک بر اساس ترکیب یوزرنیم و ip اعمال میشه؛ یعنی حتی اگر کاربر از یک ip جدید وارد شه، اگر همان یوزرنیم را استفاده کنه همچنان محدود خواهد بود و اجازه ورود نداره. اگر این متغیر روی False باشه، بلاک فقط بر اساس ip اعمال می‌شود و یوزرنیم میتونه از ip دیگر بدون مشکل وارد شه. این تنظیم باعث افزایش دقت امنیتی و جلوگیری از دور زدن محدودیت‌ها توسط تغییر ip می‌شود.
5⃣ DEFENDER_STORE_FAILURES :
اگر True باشه، تلاش‌های ناموفق در دیتابیس ذخیره میشن و میتونیم اونارو را تو پنل ادمین ببینیم
این ویژگی کمک می‌کند تحلیل و بررسی حملات راحت تر باشد
مایگریشن ها رو اجرا کنید:
🧪 تست عملکرد
5 بار با اطلاعات اشتباه سعی کنید داخل پروژه جنگویی خودتون لاگین کنید 🔑
پس از رسیدن به تعداد تلاش‌های مجاز، دسترسی موقت بلاک خواهد شد 🚫
لاگ‌ها در پنل مدیریت ذخیره می‌شوند 📊
با فعال بودن LOCK_OUT_BY_COMBINATION_USER_AND_IP، حتی با IP جدید همان یوزرنیم بلاک خواهد شد 🔒
🎯 نتیجه:
اعمال چند خط تنظیمات ساده در Django-Defender، امنیت فرم لاگین پروژه شما به شکل چشمگیری افزایش می‌یابد. این ابزار به طور مؤثر جلوی حملات brute-force را می‌گیرد، تلاش‌های ناموفق کاربران را ردیابی می‌کند و امکان مسدودسازی موقت ip یا یوزرنیم را فراهم می‌کند. با ذخیره لاگ‌ها در دیتابیس و بررسی آنها در پنل مدیریت، می‌توانید فعالیت‌های مشکوک را شناسایی کرده و امنیت کلی سایت خود را ارتقا دهید. به این ترتیب کنترل کامل بر دسترسی کاربران و حفاظت از حساب‌ها برای شما ساده و قابل اطمینان خواهد بود ✅
✍ @Django_Experience
حملات brute-force 🔐 یکی از رایج ترین روش‌های نفوذ به وبسایت ها هستند
جایی که هکرا با تلاش‌های مکرر سعی میکنن رمز عبور کاربران را حدس بزنند.
کتابخانه‌ی Django-Defender ⚡ ابزاری سبک، سریع و مطمئن برای مقابله با این حملات در پروژه‌های Django است.
✨ امکانات کلیدی
🚫 شمارش تلاش‌های ناموفق ورود و بلاک کردن کاربر یا ip
⚡ استفاده از کش (Redis یا Memcached) برای عملکرد سریع
⏱️ امکان تنظیم تعداد تلاش‌های مجاز و زمان بلاک (cool-off)
📊 ذخیره لاگ‌ها و مشاهده آنها در پنل مدیریت Django
🔐 بلاک بر اساس ip یا ترکیب یوزرنیم + ip
⚙️ نصب و راه‌اندازی
pip install django-defender
در settings.py تنظیمات پایه رو برای کانفیگ django defender اضافه کنید:
INSTALLED_APPS = [
...,
"defender",
]
MIDDLEWARE = [
...,
"defender.middleware.FailedLoginMiddleware",
]
تنظیمات اصلی:
DEFENDER_REDIS_URL = "redis://127.0.0.1:6379/0"
DEFENDER_LOGIN_FAILURE_LIMIT = 5
DEFENDER_COOLOFF_TIME = 300
DEFENDER_LOCK_OUT_BY_COMBINATION_USER_AND_IP = True
DEFENDER_STORE_FAILURES = True
1⃣ DEFENDER_REDIS_URL :
مشخص میکنه داده های تلاش نا موفق کجا ذخیره میشن "redis://127.0.0.1:6379/0" یعنی Redis روی لوکال با پورت 6379 و‌دیتابیس شماره 0 اجرا بشه.
2⃣ DEFENDER_LOGIN_FAILURE_LIMIT:
تعداد دفعاتی که یک کاربر یا ip میتونه رمز اشتباه وارد کنه قبل از اینکه بلاک شه.
مثال: مقدار ۵ → بعد از ۵ تلاش ناموفق، بلاک فعال میشه
3⃣ DEFENDER_COOLOFF_TIME :
مدت زمان بلاک به ثانیه.
به عنوان مثال اینجا ۳۰۰ ثانیه یعنی بعد از بلاک شدن؛کاربر یا ip برای ۵ دقیقه نمیتونه لاگین کنه
4⃣ DEFENDER_LOCK_OUT_BY_COMBINATION_USER_AND_IP :
تعیین میکنه که مکانیزم بلاک چگونه عمل کنه و معیار محدودسازی کاربران چی باشه. مثلا وقتی متغیر روی True تنظیم شه، بلاک بر اساس ترکیب یوزرنیم و ip اعمال میشه؛ یعنی حتی اگر کاربر از یک ip جدید وارد شه، اگر همان یوزرنیم را استفاده کنه همچنان محدود خواهد بود و اجازه ورود نداره. اگر این متغیر روی False باشه، بلاک فقط بر اساس ip اعمال می‌شود و یوزرنیم میتونه از ip دیگر بدون مشکل وارد شه. این تنظیم باعث افزایش دقت امنیتی و جلوگیری از دور زدن محدودیت‌ها توسط تغییر ip می‌شود.
5⃣ DEFENDER_STORE_FAILURES :
اگر True باشه، تلاش‌های ناموفق در دیتابیس ذخیره میشن و میتونیم اونارو را تو پنل ادمین ببینیم
این ویژگی کمک می‌کند تحلیل و بررسی حملات راحت تر باشد
مایگریشن ها رو اجرا کنید:
python manage.py migrate
🧪 تست عملکرد
5 بار با اطلاعات اشتباه سعی کنید داخل پروژه جنگویی خودتون لاگین کنید 🔑
پس از رسیدن به تعداد تلاش‌های مجاز، دسترسی موقت بلاک خواهد شد 🚫
لاگ‌ها در پنل مدیریت ذخیره می‌شوند 📊
با فعال بودن LOCK_OUT_BY_COMBINATION_USER_AND_IP، حتی با IP جدید همان یوزرنیم بلاک خواهد شد 🔒
🎯 نتیجه:
اعمال چند خط تنظیمات ساده در Django-Defender، امنیت فرم لاگین پروژه شما به شکل چشمگیری افزایش می‌یابد. این ابزار به طور مؤثر جلوی حملات brute-force را می‌گیرد، تلاش‌های ناموفق کاربران را ردیابی می‌کند و امکان مسدودسازی موقت ip یا یوزرنیم را فراهم می‌کند. با ذخیره لاگ‌ها در دیتابیس و بررسی آنها در پنل مدیریت، می‌توانید فعالیت‌های مشکوک را شناسایی کرده و امنیت کلی سایت خود را ارتقا دهید. به این ترتیب کنترل کامل بر دسترسی کاربران و حفاظت از حساب‌ها برای شما ساده و قابل اطمینان خواهد بود ✅
✍ @Django_Experience
👏16❤5👍3✍1
Forwarded from Security Analysis
⭕️ حساب NPM یه توسعه‌دهنده معروف هک شده و پکیج‌هاش که بیش از 1 میلیارد بار دانلود شدن، ممکنه کل اکوسیستم جاوااسکریپت رو به خطر بندازه. بدافزار به‌صورت مخفیانه آدرس‌های کریپتو رو عوض میکنه و پول شما رو می‌زنه به حساب هکر!
اگه کیف پول سخت‌افزاری دارید، قبل از زدن دکمه تایید، حتماً همه جزئیات تراکنش رو چک کنید.
نکته جالب این هک اینه که آدرس کیف پول کاربر با یکی از آدرس‌های هکر جایگزین میشه، اما نه به صورت تصادفی، از الگوریتم Levenshtein Distance استفاده میکنه تا آدرس جایگزین شبیه‌ترین به آدرس اصلی باشد.
جزئیات بیشتر :
jdstaerk.substack.com/p/we-just-found-malicious-code-in-the
#crypto #NPM #Wallet
@securation
اگه کیف پول سخت‌افزاری دارید، قبل از زدن دکمه تایید، حتماً همه جزئیات تراکنش رو چک کنید.
نکته جالب این هک اینه که آدرس کیف پول کاربر با یکی از آدرس‌های هکر جایگزین میشه، اما نه به صورت تصادفی، از الگوریتم Levenshtein Distance استفاده میکنه تا آدرس جایگزین شبیه‌ترین به آدرس اصلی باشد.
جزئیات بیشتر :
jdstaerk.substack.com/p/we-just-found-malicious-code-in-the
#crypto #NPM #Wallet
@securation
❤3🤔1
با لود نشدن فایل های استاتیک و سرو کردنشون توی وب سرور مشکل دارید؟ و هر بار یادتون میره راه درستش چیه؟
Anonymous Poll
49%
آره خیلی رو مخه
8%
نه. من یه چیزی رو یه بار یاد بگیرم، دیگه تمامه
13%
آخرین بار که باهاش سر و کله زدم، قلقش دستم اومد
30%
محتوا نداشتی اینو گذاشتی؟
😁8