🔵 عنوان مقاله
Security flaws in Freedom Chat app exposed users' phone numbers and PINs (3 minute read)

🟢 خلاصه مقاله:
در تازه‌ترین گزارش‌ها، مشکلات امنیتی جدی در برنامه گفت‌وگوی فریدام چت کشف شده است که حفره‌هایی را در حفاظت از حریم خصوصی کاربران ایجاد کرده است. این برنامه، دو نقص بزرگ داشت که یکی از آنها امکان شناسایی تعداد زیادی از شماره تلفن‌های کاربران را فراهم می‌کرد؛ به گونه‌ای که هکرها می‌توانستند با حدس‌زنی گسترده، تقریباً نزدیک به دو هزار شماره تلفن را به‌درستی در سرورهای برنامه فهرست‌بندی کنند. این روش، امنیت کاربران را به شدت تحت‌تأثیر قرار می‌داد و می‌توانست منجر به سوء استفاده‌های مختلف شود.

دومین آسیب‌پذیری نهانی‌تر، لو رفتن کدهای PIN کاربران بود، که از طریق پاسخ‌های سرور به صورت پس‌زمینه و در کانال‌های عمومی پیش‌فرض، امکان دیدن این کدها برای هر فرد در آن گروه‌های عمومی را فراهم می‌کرد. این مسئله باعث نگرانی‌های زیادی درباره حفظ حریم خصوصی و امنیت حساب‌های کاربری شد. پس از کشف این مشکلات، تیم توسعه‌دهنده فریدام چت اقدام به بازنشانی تمامی کدهای PIN کرد، محدودیت‌های سرعت ارسال درخواست‌ها را افزایش داد و شماره‌های تلفن آسیب‌پذیر را حذف نمود.

همچنین، نسخه به‌روزرسانی شده برنامه، با اصلاح سریع این نقاط ضعف روانه بازار شد تا امنیت کاربران بهبود یابد. لازم به ذکر است که این مشکلات، دومین بار است که بنیان‌گذار برنامه، تنر هاس، در توسعه یکی از اپ‌های پیام‌رسان او، با مسائل امنیتی جدی مواجه می‌شود. این موضوع نشان‌دهنده اهمیت رعایت نکات امنیتی در طراحی و نگهداری برنامه‌های پیام‌رسان است تا حریم خصوصی کاربران حفظ و سوء استفاده‌ها کاهش یابد.

#امنیت_گفتگو #حریم_خصوصی #فریدام_چت #مدیریت_امنیت

🟣لینک مقاله:
https://techcrunch.com/2025/12/11/security-flaws-in-freedom-chat-app-exposed-users-phone-numbers-and-pins/?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
AWS Lambda Managed Instances: A Security Overview (5 minute read)

🟢 خلاصه مقاله:
در همایش re:Invent 2025، شرکت آمازون وب سرویس (AWS) اعلام کرد که قابلیت جدیدی به نام "نمونه‌های مدیریتی لامبدا" (Lambda Managed Instances) عرضه کرده است. این قابلیت به توسعه‌دهندگان اجازه می‌دهد تا توابع لامبدا بر روی نمونه‌های EC2 که توسط خود AWS مدیریت می‌شوند، اجرا شوند. این تغییر، یک گزینه هیجان‌انگیز برای بهبود امنیت و کنترل در محیط‌های سرورless است، چرا که بر خلاف نمونه‌های مدیریتی دیگر، کاربران قادر نیستند نقش نمونه (Instance Role) به این نمونه‌ها اختصاص دهند. این محدودیت، سطح امنیت و کنترل بیشتری را برای کاربران فراهم می‌کند، زیرا دسترسی مستقیم به این نمونه‌ها محدود شده است.

نکته جالب دیگر این است که در حالی‌که نمونه‌های مدیریت شده در سرویس EKS به کاربران اجازه نمی‌دهند تا به صورت مستقیم از ابزارهایی مانند SSM یا EC2 Instance Connect برای دسترسی به نمونه‌ها استفاده کنند، نمونه‌های لامبدا مدیریت شده این محدودیت را ندارند. این طراحی، به منظور کاهش ریسک‌های امنیتی و جلوگیری از دستکاری غیرمجاز است و در عین حال، امکان اجرای توابع لامبدا در محیط‌های جداگانه و کنترل‌شده را فراهم می‌کند. نمونه‌های مذکور از توزیع لینوکس مخصوص کانتینرهای AWS به نام Bottlerocket OS بهره می‌برند، که برای امنیت بالا و کارایی بهینه طراحی شده است.

این نمونه‌ها توابع لامبدا را به صورت کانتینرهای containerd اجرا می‌کنند، که این امر امکان مدیریت بهتر و بهبود امنیت را فراهم می‌آورد. به طور کلی، این توسعه جدید نشان دهنده تعهد AWS به افزایش سطح امنیت و انعطاف‌پذیری در سرویس‌های سرورلس است، و فرصت جدیدی برای توسعه‌دهندگان و مدیران اکانت فراهم می‌کند تا زیرساخت‌های خود را امن‌تر و مقیاس‌پذیرتر کنند.

#آمازون_وب_سرویس #AWS #خدمات_مبتنی_بر_کلود #امنیت

🟣لینک مقاله:
https://www.offensai.com/blog/aws-lambda-managed-instances-security-overview?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
How I Ran Cypress Page Objects Inside Playwright Without Rewriting a Single Line

🟢 خلاصه مقاله:
در دنیای توسعه وب، یکی از چالش‌های اصلی، انتقال پروژه‌ها و کدهای تست از یک ابزار به ابزار دیگر است. در حالت ایده‌آل، این فرآیند باید بدون صرف وقت و هزینه زیاد انجام شود تا تیم‌ها بتوانند به سرعت و بدون مشکلاتِ فنی اضافی، امکانات جدید را آزمایش کنند. در این زمینه، نویسنده و توسعه‌دهنده Aneeshia Sasidharan یک روش غیرمعمول و کارآمد برای استفاده مجدد از اشیاء صفحه‌ی Cypress در محیط Playwright ارائه کرده است، بدون اینکه نیاز به بازنویسی یک خط کد باشد.

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

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

#تست_وب #Playwright #Cypress #توسعه_نرم‌افزار

🟣لینک مقاله:
https://cur.at/iKYs6OB?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

سایت System Design یکی از بهترین منابع برای فهم طراحی سیستم‌های بزرگیه که هر روز استفاده می‌کنیم.
خودم تقریبا هر روز یکی از مطالبش رو می‌خونم و واقعا دید خوبی برای پیاده‌سازی نرم‌افزار می‌ده؛
از WhatsApp و YouTube تا Instagram و Redis و ...

https://newsletter.systemdesign.one/

🥇 اگر عاشق تکنولوژی‌های روز دنیا هستی، اینجا هر روز تازه‌ترین و مهم‌ترین مطالب درباره:👇

🛰 فضا و اکتشافات فضایی و تکنولوژی های مرتبط فضای
⚡️ برق و انرژی‌های نو
🔌 دنیای الکترونیک و گجت‌های هوشمند و انواع پهپاد ها
🚗 خودروهای برقی و آینده حمل‌ونقل

همه چیز به‌صورت کوتاه، خلاصه و کاملاً قابل‌فهم👇👇

🥈 @futurepulse_persian

🔵 عنوان مقاله
Scaling DAA: Mastering the Action Layer with Composite Patterns

🟢 خلاصه مقاله:
در شماره گذشته، به موفقیت‌های قابل توجه معماری اقدام اعلانی در اتوماسیون آزمایش پرداختیم و مفاهیم کلیدی آن را بررسی کردیم. حال، در این بخش، تمرکز بر روی رشد و توسعه لایه عملیاتی (Action Layer) است که نقش مهمی در ساختار کلی این معماری دارد. با بهره‌گیری از الگوهای ترکیبی (Composite Patterns)، می‌توان درک بهتری از نحوه مدیریت، سازماندهی و مقیاس‌پذیری بخش عملیاتی کسب کرد. این روش‌ها به تیم‌های تست کمک می‌کنند تا عملیات پیچیده را ساده‌تر و قابل کنترل‌تر کنند، در نتیجه فرآیندهای تست را کارآمدتر و انعطاف‌پذیرتر می‌سازند.

با توسعه این مفاهیم، اهمیت استفاده از الگوهای ترکیبی در طراحی لایه‌های عملیاتی آشکار می‌شود. این الگوها امکان ترکیب اقدامات گوناگون در ساختارهای درختی را فراهم می‌کنند و نتیجه‌اش، پویایی و قابلیت برنامه‌ریزی بهتر در سیستم‌های اتوماسیون است. بنابرین، mastery در این حوزه، مهارتی است که می‌تواند سطح اتوماسیون آزمایش‌ها را به شکل قابل توجهی ارتقاء دهد.

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

کلام پایانی، تاکید بر اهمیت mastery در طراحی لایه عملیاتی (Action Layer) با استفاده از الگوهای ترکیبی است، روشی که آینده‌نگر و مؤثر در ارتقاء کیفیت و عملکرد سیستم‌های اتوماسیون است.



#اتوماسیون_آزمایش #الگوهای_ترکیبی #معماری_اقدام #توسعه_پیشرفته

🟣لینک مقاله:
https://cur.at/whVcVwF?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Weaponizing the AWS CLI for Persistence (5 minute read)

🟢 خلاصه مقاله:
در این مقاله، به بررسی روش‌های بهره‌برداری مخفیانه از ابزار AWS CLI برای ایجاد جا پای ماندگار در سیستم هدف پرداخته شده است. یکی از قابلیت‌های AWS CLI، امکان تعریف نام‌های مستعار برای دستورات است که می‌تواند این دستورات را با اجرای فرمان‌های bash دلخواه جایگزین کند. اما محدودیتی که در گذشته وجود داشت، این بود که اگر هکر نام مستعاری برای نمونه برای دستور `aws sts` تعریف کرده و آن را مخرب می‌کرد، نمی‌توانست نسخه اصلی آن را اجرا کند، چون راهی برای بازگرداندن فرمان اوریجینال در دست نبود. در این مقاله، راه‌حلی مبتکرانه و در عین حال ساده ارائه شده است؛ یک خط کد که به صورت دینامیک فایل نام‌های مستعار را تغییر می‌دهد و نسخه اصلی فرمان را مجدداً فعال می‌کند، تا بتوان در هنگام نیاز از آن استفاده کرد و پس از اجرا، دوباره قابلیت مخرب را برمی‌گرداند. این تکنیک می‌تواند برای افرادی که قصد سوء استفاده دارند، ابزار موثری باشد، زیرا به آن‌ها اجازه می‌دهد پس از حذف محدودیت‌ها، به راحتی ادامه فعالیت‌های مخرب خود را داشته باشند.

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

#امنیت_ابری #AWS #حملات_سایبری #مدیریت_امنیت

🟣لینک مقاله:
https://slayer0x.github.io/awscli/?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
HTTPS certificate industry phasing out less secure domain validation methods (4 minute read)

🟢 خلاصه مقاله:
در صنعت گواهینامه‌های امنیتی HTTPS، تمرکز روزافزون بر حذف روش‌های قدیمی و کم‌امنیت تایید دامنه است. در این راستا، برنامه ریشه‌های مرورگر Chrome و انجمن CA/Browser Forum تصمیم گرفتند با تصویب رأی‌گیری‌های SC-080، SC-090 و SC-091، روش‌های تایید کنترل دامنه که بر اساس ایمیل، تماس تلفنی، فکس، نامه پستی و بررسی معکوس DNS بودند، تا تاریخ مارس ۲۰۲۸ کنار گذاشته شوند. این تغییر عمدتاً با هدف ارتقاء سطح امنیت و جلوگیری از صدور گواهینامه‌های جعلی صورت گرفت.

در طول زمان، روش‌های قدیمی مانند تایید از طریق ایمیل یا تماس تلفنی، هم به دلیل سهولت سوءاستفاده و هم به دلیل ضعف در اثبات مالکیت واقعی دامنه، مورد انتقاد قرار گرفته بودند. بنابراین، نهادهای صادرکننده گواهینامه همگام با این تغییر، به سمت استانداردهای جدیدی حرکت می‌کنند که بیشتر مبتنی بر خودکارسازی و امنیت کریپتوگرافی است. این رویکرد، فناوری مبتنی بر پروتکل ACME را ترویج می‌کند که امکان تایید دیجیتال و خودکار اصالت گواهینامه‌ها را فراهم می‌آورد و خطر صدور گواهینامه‌های تقلبی را تا حد زیادی کاهش می‌دهد.

در نهایت، این تحولات نه تنها موجب ارتقاء امنیت فضای اینترنت می‌شود، بلکه فرآیند صدور گواهینامه‌ها را نیز کارآمدتر و قابل اعتمادتر می‌سازد، ضمن جلوگیری از فعالیت‌های مخرب و حفظ اعتماد کاربران در استفاده از صفحات وب ایمن. بنابراین، تصمیماتی مانند کنار گذاشتن روش‌های سنتی و تکیه بر فناوری‌های نوینی چون ACME، آینده‌ای مطمئن‌تر و امنیت بیشتر برای دنیای دیجیتال رقم خواهد زد.

#امنیت_وب #گواهینامه_امنیت #SSL #تایید_دامنه

🟣لینک مقاله:
https://security.googleblog.com/2025/12/https-certificate-industry-phasing-out.html?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

پاول دوروف: تلگرام 30 میلیارد دلار ارزش دارد و تنها 30 کارمند دارد که همگی از خانه کار میکنند. بدون دفتر، بدون منابع انسانی!
➖➖➖➖➖➖➖➖
👑 @futurepulse_persian

👉Amir Rahimi Nejad


یک Junior کد می‌نویسه؛
هدفش اینه که «کار کنه».
یک Mid-Level کد رو تمیز می‌کنه؛
می‌فهمه کدی که کار می‌کنه، لزوماً کد خوبی نیست.
یک Senior می‌دونه کِی کد بزنه،
کِی کد نزنه،
و کِی کد رو حذف کنه.
یک Lead جلوی اشتباه نوشته شدن کد رو می‌گیره؛
قبل از اجرا، مسئله رو درست تعریف می‌کنه.

حقیقت ساده ولی مهم اینه:
هرچی جلوتر می‌ری، کمتر کد می‌زنی
ولی مسئولیت تصمیم‌هات بیشتر می‌شه.

این سطوح به سالهایی که پای کد نشستی نیست،
طرز فکرته که سطحت رو مشخص میکنه

#SoftwareEngineering #Programming
#برنامه_نویسی #رشد_حرفه‌ای

🚀 Strong vs Eventual Consistency

از اون مفاهیمیه که خوب فهمیدنش توی مصاحبه‌های فنی به‌خصوص System Design به شدت کمکمون می‌کنه!

یا حتی موقع انتخاب و استفاده ى ابزارها!

مثلاً اگه ندونيم Redis Cluster برامون Strong Consistency رو گارانتی نمیكنه، ممکنه توی یه سری Use Case اشتباه ازش استفاده كنيم و نتایجی که انتظار نداريم اتفاق بيفته.

یا مثلاً MongoDB برای رسیدن به High Availability داره از Eventual Consistency استفاده میكنه كه البته کنارش هم داره از مکانیزم‌هایی مثل Write Concerns و Read Concerns استفاده میكنه که این نرخ ناسازگاری دیتا (یا تاخیر انتشار دیتا) رو كم كنه.


توی این ویدیو از چنل Inspect میخوایم بریم سراغش و به این سوالات جواب بدیم:

🔹 مفهوم Consistency چیه؟
🔸 چه مدل‌هایی داره؟
💡 هر کدوم چه مزایایی برامون دارند؟ (سرعت در برابر دقت و دسترسی‌پذیری)
🛠 چطوری میتونیم به دستشون بیاریم؟
🔎مفاهیمی مثل Replication و Consensus چطور به این هدف کمک می‌کنند؟


📺 ویدیو کامل: «چرا داده‌هامون فرق می‌کنه؟ | Data Consistency در سیستم‌های توزیع‌شده»

https://lnkd.in/dT94cDCi

وقتی میکروسرویس‌ها بدون API Management وارد Production می‌شن…

خیلی از تیم‌ها با هیجان می‌رن سمت معماری Microservices؛
سرویس‌ها کوچک می‌شن، تیم‌ها مستقل می‌شن، deploy سریع‌تر می‌شه…
اما یه سؤال مهم معمولاً جا می‌مونه:

چه کسی قراره این همه API رو مدیریت کنه؟
اینجاست که API Management از یک ابزار لوکس تبدیل می‌شه به یک ضرورت.
در معماری Monolith، کنترل دسترسی، rate limit، versioning و monitoring معمولاً داخل خود اپلیکیشن پیاده‌سازی می‌شه.

اما در معماری Microservices، تکرار این موارد داخل هر سرویس یعنی کد تکراری، رفتارهای ناسازگار، policyهای امنیتی متفاوت و دردسر در نگهداری

دقیقاً اینجا API Management وارد بازی می‌شه:
- یک نقطه‌ی مرکزی برای Authentication و Authorization
- اعمال Rate Limiting و Throttling به‌صورت یکپارچه
- مدیریت Versioning بدون دست‌زدن به سرویس‌ها
- امکان Observability متمرکز (Logs، Metrics، Traces)
- محافظت از سرویس‌ها در برابر traffic ناخواسته یا مخرب

نکته مهم اینه که API Manager جای Microservice رو نمی‌گیره،
بلکه مثل یک قرارداد پایدار بین سرویس‌ها و مصرف‌کننده‌ها عمل می‌کنه.
تجربه‌ی من این بوده:
هر چقدر تعداد سرویس‌ها بیشتر می‌شه، نبود API Management هزینه‌ی بیشتری به تیم تحمیل می‌کنه — چه از نظر امنیت، چه پایداری، چه سرعت توسعه. Microservices بدون API Management قابل اجرا هست…
اما به‌سختی قابل رشد و نگهداریه.


| <Mobin Mokhtarzadeh/>

بزرگترین درسی که در سِمت CTO آموختم:
اصول Clean Code اغلب دروغ هستند!

این یک اعتراف است: من سال‌ها به تیمم اجازه نمی‌دادم کدی بنویسند که برای بیزینس حیاتی بود، فقط چون از نظر فنی "تمیز" نبود.

​من یک CTO وسواسی بودم که برای رعایتِ قوانین SOLID یا داشتن یک معماری بی‌نقص، سرعت رسیدن به بازار (Time-to-Market) را قربانی می‌کردم.
ما تبدیل شده بودیم به تیمی که سریع‌ترین کدهای تاریخ را برای محصولی نوشت که هنوز مشتری نداشت!

​کمال‌گرایی فنی (Technical Perfectionism) در فاز MVP، قتلِ خاموش استارتاپ‌هاست.
کتاب‌های معروف مهندسی نرم‌افزار به ما "چگونه خوب کد زدن" را یاد می‌دهند، اما هیچوقت نمی‌گویند "چه زمانی باید به عمد بد کد بزنیم."

​بدهی فنی، اما این‌بار آگاهانه:
​امروز، دیدگاه من ۱۸۰ درجه تغییر کرده است. به جای وسواس روی "Clean Code"، تمرکز من روی "کد تاکتیکی" است.

​تصمیم‌گیری به عنوان یک CTO، مدیریت تریدآف (Trade-off) است. من بدهی فنی (Tech Debt) را نه به عنوان یک شکست، بلکه به عنوان یک ابزار استراتژیک می‌بینم:

​بدهی ناآگاهانه: نوشتن کد کثیف از روی تنبلی یا بی‌دانشی (این غیرقابل بخشش است و باید حذف شود).

​بدهی آگاهانه (وام بیزینسی): ما آگاهانه، کیفیت نگهداری را فدای سرعت عرضه می‌کنیم. این شبیه به گرفتن وام تجاری با نرخ بهره مشخص است. ما باید سریع به بازار برسیم، و قول می‌دهیم که وقتی ارزش (Value) اثبات شد، اصل و سود این وام را با Refactoring پس دهیم.

​ سه حقیقت تلخ مهندسی
​کتاب Clean Code به ما یاد داد تمیز بنویسیم، اما یاد نداد "کی" تمیز بنویسیم.
​کتاب Clean Code رابرت مارتین مقدس است، اما "Time-to-Market" مقدس‌تر.
​اگر استارتاپ هستید، معماریِ "Good Enough" (به اندازه کافی خوب)، تنها معماری درستی است که نیاز دارید.

​اگر تیم شما ۶ هفته وقت می‌گذارد تا زیرساختی بسازد که توانایی مدیریت ۵ میلیون کاربر را دارد، در حالی که شما ۱۰ کاربر هم ندارید، شما در حال "بیش‌مهندسی" (Over-engineering) هستید.

​من امروز یک کد کثیف که ارزش را به سرعت می‌رساند را به یک شاهکار معماری که هفته‌ها طول کشیده، ترجیح می‌دهم.


<Bijan Biria/>

‏⚠️ رکورد ترسناک هکرهای کره شمالی: سرقت 2.02 میلیارد رمزارز در سال 2025

▪️هکرهای وابسته به کره شمالی در سال 2025 موفق به سرقت 2.02 میلیارد دلار رمزارز شدند ؛ رقمی که حدود 60% از کل سرقت‌های رمزارزی امسال رو تشکیل میده.

▪️طبق گزارش Chainalysis، مجموع سرقت‌های رمزارزی منتسب به این کشور تاکنون به 6.75 میلیارد دلار رسیده.  گفته می‌شود دولت کره شمالی از این حملات برای تأمین مالی و دور زدن تحریم‌های بین‌المللی استفاده میکنه.

🔵 عنوان مقاله
Infostealer has entered the chat (7 minute read)

🟢 خلاصه مقاله:
با افزایش محبوبیت مرورگر Atlas شرکت OpenAI، مجرمان سایبری نیز از این فرصت سوءاستفاده کرده‌اند. آن‌ها با خرید تبلیغات در گوگل، کاربران را به سمت یک گفتگوی مشترک در ChatGPT هدایت می‌کنند که ادعا می‌کند راهنمای نصب مرورگر Atlas مخصوص مک‌اواس است. در این راهنما، کاربرانی که به دنبال نصب این مرورگر هستند، تشویق می‌شوند تا فرمان ترمینال ساده‌ای را اجرا کنند. این فرمان، به صورت مخفیانه اسکریپتی را بارگیری و اجرا می‌کند که نه تنها اطلاعات حساس کاربر، مانند رمزعبور و داده‌های مرورگر، را سرقت می‌کند، بلکه ابزارهای مخرب دیگری مانند کی‌لاگر و بدافزار AMOS را نصب می‌نماید. این ابزارهای مخرب اطلاعات مربوط به کیف پول‌های رمزارزی، فایل‌ها و اسناد مهم کاربر را جمع‌آوری می‌کنند و در کنار آن، درب پشتی را برای دسترسی همیشگی و کنترل از راه دور فعال می‌کنند. این نوع حملات نشان‌دهنده اهمیت مراقبت‌های امنیتی و اعتماد نکردن به راهنماهای ناشناخته در فضای مجازی است، مخصوصاً زمانی که منابع رسمی و معتبر نیستند.

---

با رشد روزافزون محبوبیت مرورگر Atlas از سوی کاربران، کلاهبرداران سایبری هم به همین میزان با نوشته‌ها و تبلیغات فریبنده، قصد دارند به اطلاعات حساس کاربران دست پیدا کنند. آن‌ها با تبلیغات در موتورهای جستجو، کاربران را فریب داده و به جلسات گفت‌وگو در ChatGPT هدایت می‌کنند، در حالی که در ظاهر، این گفت‌وگوها راهنمای نصب و راه‌اندازی مرورگر Atlas برای سیستم‌عامل مک‌اواس به نظر می‌رسند. در حقیقت، زمانی که کاربران فرمان ترمینال را اجرا می‌کنند، یک اسکریپت مخرب به صورت پنهانی اجرا می‌شود که نه تنها داده‌ها و رمزعبورهای آن‌ها را سرقت می‌کند، بلکه ابزارهای مخرب قدرتمندی مانند AMOS و کی‌لاگر را نصب می‌نماید. این ابزارها اطلاعات حساس، از جمله کیف پول‌های رمزارزی، اسناد مهم و تمامی داده‌های مرورگر را جمع‌آوری می‌کنند و به مهاجمین این امکان را می‌دهد که کنترل کامل بر سیستم فرد قربانی داشته باشند. نگهداری از امنیت سایبری و هوشیاری نسبت به تبلیغات و لینک‌های مشکوک، کلید مقابله با این نوع تهدیدات است؛ زیرا آن‌هایی که بدون بررسی دقیق، فرمان‌هایی را اجرا می‌کنند، ممکن است آرام‌آرام در دام حملات سایبری گرفتار شوند.

#امنیت_سایبری #حملات_مخرب #سرقت_اطلاعات #پیشگیری_امنیت

🟣لینک مقاله:
https://www.kaspersky.com/blog/share-chatgpt-chat-clickfix-macos-amos-infostealer/54928/?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Method-Based Approach for Readable E2E Tests Without Cucumber

🟢 خلاصه مقاله:
در دنیای توسعه نرم‌افزار، اطمینان از کیفیت کد و صحت عملکرد برنامه‌ها اهمیت زیادی دارد. یکی از روش‌های محبوب برای تضمین کیفیت، نوشتن آزمایش‌های End-to-End (E2E) است که تمامی روند عملکرد برنامه را در بر می‌گیرد. مسأله این است که چگونه می‌توان این آزمایش‌ها را به صورت قابل‌فهم و خوانا نوشت، بدون نیاز به استفاده از ابزارهای پیچیده مانند Cucumber یا زبان‌های خاص مانند Gherkin.

در این زمینه، جوزفین جوب نشان می‌دهد که می‌توان آزمایش‌ها را به روشی توصیفی و ساده پیاده‌سازی کرد، بدون اینکه نیاز به لایه‌های اضافی یا زبان‌های تخصصی باشد. این رویکرد به توسعه‌دهندگان امکان می‌دهد کدهای تست را طوری بنویسند که گویی داستانی کوتاه و قابل فهم برای همه باشد. این روش نه تنها فرآیند نوشتن آزمایش‌ها را ساده‌تر می‌کند، بلکه خوانایی و نگهداری آن‌ها را نیز افزایش می‌دهد. هم‌چنین، این ایده در یک بحث اخیر در ردیت مورد توجه قرار گرفت، جایی که درباره نوشتن تست‌های BDD بدون نیاز به Gherkin و ابزارهای پیچیده‌تر صحبت شد. در نتیجه، این رویکرد می‌تواند راهکار مناسبی برای تیم‌های توسعه باشد که به سادگی و خوانایی در آزمایش‌های خود اهمیت می‌دهند و می‌خواهند کیفیت کد را بدون پیچیدگی‌های اضافی تضمین کنند.

#آزمایش_EndToEnd #کیفیت_کد #توسعه_ساده #تست_خوانا

🟣لینک مقاله:
https://cur.at/DF0FTPV?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Top Automation Anti-Patterns to Avoid (With Real Examples)

🟢 خلاصه مقاله:
در دنیای توسعه نرم‌افزار، اتوماسیون تست‌ها اهمیت فراوانی دارد و می‌تواند فرآیند تست را سریع‌تر و موثرتر کند. اما گاهی اوقات، تیم‌های توسعه دچار اشتباهاتی می‌شوند که در نتیجه، کارایی و دقت فرآیند اتوماسیون کاهش می‌یابد یا حتی به مشکل‌های جدی منجر می‌شود. وولادیمیر یوسیفوسکی در مقاله‌ای خلاصه‌ای از مهم‌ترین الگوهای منفی در اتوماسیون را ارائه می‌دهد و راهکارهای عملی برای جلوگیری از این اشتباهات را با نمونه‌های واقعی بیان می‌کند.

در این مقاله، ابتدا به شایع‌ترین خطاهایی اشاره می‌شود که در فرآیند طراحی و پیاده‌سازی تست‌های اتوماتیک رخ می‌دهد. سپس، پیشنهاداتی کاربردی برای جایگزینی این الگوهای منفی و بهبود کلی فرآیند ارائه می‌شود. آگاهی از این خطاها و راه‌حل‌های پیشنهادی نقش کلیدی در ایجاد سیستم‌های اتوماسیون مطمئن و کاربردی دارد.

این راهنمایی‌ها نه تنها برای توسعه‌دهندگان و تیم‌های تست مفید است، بلکه به مدیران پروژه کمک می‌کند تا استراتژی‌های مناسب‌تری برای پیاده‌سازی اتوماسیون تعریف کنند و از اتلاف منابع و زمان جلوگیری نمایند.

در نهایت، توجه به نمونه‌های واقعی و تجربه‌های عملی، درک بهتری از چالش‌ها و روش‌های مقابله با آن‌ها فراهم می‌کند و مانع تکرار اشتباهات رایج می‌شود. این مقاله منبع ارزشمندی است که با رعایت نکات آن، می‌توان فرآیند آزمایش‌های خود را به سمت بهتر و موثرتر هدایت کرد.

#اتوماسیون #تست_نرم‌افزار #خطاهای_اتوماتیک #بهبود_کامل

🟣لینک مقاله:
https://cur.at/EWPSoor?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
NET SOAPwn Flaw Opens Door for File Writes and Remote Code Execution via Rogue WSDL (2 minute read)

🟢 خلاصه مقاله:
در طی سال‌های اخیر، توسعه‌دهندگان نرم‌افزار همواره با چالش‌های امنیتی مختلفی روبه‌رو بوده‌اند که ممکن است آسیب‌پذیری‌های جدی در سیستم‌های آن‌ها ایجاد کند. اخیراً، یک نقص طراحی در چارچوب دات‌نت (NET Framework) به نام «SOAPwn» کشف شده است که تهدیدهای جدی امنیتی را به همراه دارد. این نقص، توانسته است راه را برای حملات گسترده‌تری هموار کند، به‌طوری که مهاجمان می‌توانند با بهره‌برداری از آن، عملیات مخرب مختلفی انجام دهند.

در اصل، این مشکل امنیتی در بخش مربوط به پروتکل SOAP و WSDL وجود دارد. با وجود اینکه این پروتکل‌ها برای ارتباطات امن و ساخت برنامه‌های سرویس‌محور طراحی شده‌اند، نقص در پیاده‌سازی آن‌ها، مهاجمان را قادر می‌سازد تا با ساخت پروکسی‌های جعلی، فایل‌های دلخواه خود را روی سرورها نوشته یا درخواست‌های SOAP را به مکان‌های کنترل‌شده توسط خودشان هدایت کنند. این امکان، راه را برای سرقت اطلاعات حساس مانند «اعتبارنامه‌های NTLM» و اجرای کدهای مخرب از راه دور، هموار می‌کند.

شرکت‌هایی مانند Barracuda و Ivanti که محصولات مدیریت و امنیت شبکه ارائه می‌دهند، در نتیجه این آسیب‌پذیری، امنیت محصولاتشان را به‌روز کرده و رفع نقص‌های لازم را انجام داده‌اند. اما همچنان باید کاربر و مدیران شبکه در مراقبت از سیستم‌ها و آپدیت کردن آن‌ها هوشمندانه عمل کنند، چرا که بهره‌برداری succès‌آمیز از این نقص می‌تواند خسارت‌های زیادی به زیرساخت‌های فناوری اطلاعات وارد کند.

در نهایت، این یافته‌ها اهمیت به‌روزرسانی مداوم و مراقبت فعالانه از امنیت سیستم‌ها را بیش از پیش نشان می‌دهند و لزوم پیروی از بهترین رویه‌های امنیت سایبری در تمام سطوح را یادآوری می‌کنند.

#امنیت_سایبری #حفره_امنیتی #نقض_دات‌نت #حملات_سایبری

🟣لینک مقاله:
https://thehackernews.com/2025/12/net-soapwn-flaw-opens-door-for-file.html?utm_source=tldrinfosec

➖➖➖➖➖➖➖➖
👑 @software_Labdon

❤️یلدا بیا که با تو امید آید
❤️شب نیز صدای پای خورشید آید
❤️تاریخ اگر دوباره تکرار شود
❤️عالم به طواف تخت جمشید آید

❤️جشن آریایی میترایی یلدا،
❤️جشن باستانی شب چله
❤️بر شما عزیزان جان خجسته باد

👑👑👑👑👑👑👑
https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0

🔵 عنوان مقاله
It's not as bad as you think: Using scorecards in AI testing

🟢 خلاصه مقاله:
درک بسیاری از ما این است که قضاوت درباره‌ی عملکرد هوش مصنوعی آسان است؛ یا موفق می‌شود یا شکست می‌خورد. این نوع ارزیابی ساده و سرراست به نظر می‌رسد، اما واقعیت این است که آزمایش نتایج تولید شده توسط هوش مصنوعی پیچیدگی‌های بیشتری دارد و نیازمند روشی دقیق‌تر است. به همین دلیل، «گِل زیلبرفیلد» تصمیم گرفت ابزاری به‌نام «کارت امتیاز» توسعه دهد که بتواند فرآیند ارزیابی را منظم‌تر و قابل‌اعتمادتر کند.

هدف از این کارت‌های امتیاز، کمک به تیم‌های توسعه و ارزیابان است تا بر اساس معیارهای مشخص، نتایج آزمایش را بهتر و منسجم‌تر بسنجند. این ابزار نه تنها ارزیابی سریع‌تر، بلکه عینی‌تر و شفاف‌تر نتایج را ممکن می‌سازد و از این طریق، خطای انسانی در قضاوت‌ها کاهش می‌یابد. در واقع، این رویکرد یک گام مهم در جهت استانداردسازی فرآیندهای ارزیابی هوش مصنوعی است که می‌تواند کیفیت نهایی سیستم‌های AI را به شکل قابل توجهی بهبود بخشد.

در نهایت، اهمیت این ابزار در توانایی فنی و علمی برای «قضاوت منصفانه» درباره‌ی عملکرد هوش مصنوعی است، چیزی که در ظاهر آسان به نظر می‌رسد اما در عمل نیازمند دقت و ساختارمند بودن است. استفاده از کارت‌های امتیاز، ارائه رویکردی نظام‌مند و مبتنی بر معیارهای مشخص، راهکاری کارآمد برای تضمین کیفیت و اعتماد در توسعه فناوری‌های مبتنی بر هوش مصنوعی است.

#هوش_مصنوعی #ارزیابی_هوش_مصنوعی #کارت_امتیاز #توسعه_هوش_مصنوعی

🟣لینک مقاله:
https://cur.at/BFxcaBT?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Testing the unpredictable: Introducing Semantic Assertions

🟢 خلاصه مقاله:
در دنیای فناوری امروز، نهادینه کردن روش‌های دقیق آزمایش برنامه‌های مبتنی بر هوش مصنوعی تصمیمی حیاتی است. یکی از چالش‌های اصلی توسعه‌دهندگان، آزمایش صحت و معتبر بودن خروجی‌های مدل‌های زبانی بزرگ (LLMs) است، چرا که این مدل‌ها می‌توانند نتایج متنوع و گاهی غیرقابل پیش‌بینی ارائه دهند. در پاسخ به این نیاز، لئوناردو لانی راه‌حلی خلاقانه ارائه داده است که امکان نوشتن اعلامیه‌های شرطی ساده را فراهم می‌کند؛ این اعلامیه‌ها از هوش مصنوعی دیگری بهره می‌برند تا ارزیابی دقیقی از خروجی‌ها انجام دهند و مطمئن شوند که نتایج با انتظارات همخوانی دارند.

در این روش، توسعه‌دهندگان می‌توانند با نوشتن جملات شرطی یا assertions، کنترل و نظارت بر خروجی‌های برنامه‌های خود را افزایش دهند. این assertions به نوعی قاعده یا معیار هستند که باید خروجی بر پایه آن‌ها ارزیابی شود. نکته جالب توجه در این است که این معیارها توسط هوش مصنوعی دیگری بررسی و تفسیر می‌شوند، به این معنا که فرآیند آزمایش فراتر از الگوریتم‌های معمول است و از قابلیت‌های تحلیل پیشرفته بهره می‌گیرد. این کار کمک می‌کند تا مشکلات و خطاهای احتمالی در نتایج سریع‌تر شناسایی شوند و کیفیت نهایی برنامه ارتقاء یابد.

بنابراین، استفاده از «تأییدیه‌های معنایی» نه تنها فرایند آزمایش را ساده‌تر می‌کند بلکه به توسعه‌دهندگان این امکان را می‌دهد که در محیط‌های پویا و پیچیده، کنترل بیشتری بر عملکرد برنامه‌های خود داشته باشند. این روش، نمونه‌ای نوآورانه و موثر است که نشان می‌دهد چگونه ترکیب هوش مصنوعی‌ها می‌تواند در مسیر بهبود فرآیندهای توسعه و آزمایش تکنولوژی‌های نوین نقش‌آفرینی کند.

#هوش_مصنوعی #آزمایش_هوشمند #مدل_زبان #توسعه_نرم‌افزار

🟣لینک مقاله:
https://cur.at/cRMeUM?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon