درگیر یک مسئله ای بودم برای کراول سایت ترب که پس از یکم کلنجار رفتن خروجیش شد ماژول زیر :
[ GitHub ]
[ PyPi ]

یک ماژول ساده برای ارتباط برقرار کردن با وب سرویس ترب جهت دریافت محصولات، محصولات مشابه، اطلاعات یک محصول خاص و فروشندگانش، دریافت چارت قیمت و ... شاید توی تسکاتون گره گشا باشه.

@Ahura_Rahmani | #Ahur4 #Scrape #Torob

امروز یک تجربه با تاوانی نه چندان سنگین ( خوشبختانه ) بدست آوردم.

روی سیستم یکی از کارآموز ها یکسری دیتای کراول شده بود که باید روی سرور تست قرار میگرفت.
به علت محدودیت وقت و سرعت فوق العاده اینترنت در کشور، عجله اجازه نداد که با ftp و mongodump و mongorestore حلش کنیم؛ به همین دلیل پورت مونگو رو از روی سرور ویندوزی تست expose کردم و bindIpAll هم true کردم توی mongod.cfg ( بدون تنظیم password ) و باقیش رو سپردم به کارآموز دقیقا بعد از نهایتا یک ساعت به سرور سر زدم و متوجه شدم کل دیتای موجود حذف شده و یک کالکشن README روی دیتابیس ایجاد شده، محتواشم این بود که دیتای شما بک آپ گرفته شد و اگر میخواینش به فلان ولت انقدر واریز کنید ( کد رهگیری هم داده بودن 😂 )

دیتایی که اونا بدست آوردن دیتای open source سایت nvd بود ( ماژولی که برای دریافت اطلاعات نوشتم nvd-client ) ولی تجربه ای که من بدست آوردم باعث شد حتی در حساس ترین مواقع هم در موارد امنیتی سهل انگاری نکنم.

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

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

@Ahura_Rahmani | #Ahur4 #Database #Security

کامیت اتمی یا اتمیک کامیت ( Atomic Commit ) چیه و چه مزایا و معایبی داره ؟

کامیت اتمی یا اتمیک کامیت (Atomic Commit) در سیستم‌های کنترل نسخه مثل گیت (Git) به این معناست که شما یک تغییری روی پروژه انجام دادید و پس از اتمامش فقط همون تغییرات رو با مسیج مشخص کامیت میکنید.
شما نباید تمام تغییرات در تمام فایل هارو یک جا کامیت بزنید ( مثلا استفاده از "git add .")
شما باید پس از پیاده سازی کامل بخش مورد نظر کامیتش کنید، مثلا فرض کنید قراره یک route به پروژه اضافه بشه برای دریافت تمام یوزر ها؛ شما وقتی اون روت رو تکمیل کردید فقط تغییراتی که مربوط به این مورد هست رو کامیت میکنید ( با مسیج مثلا "get all user route added.")
در این حالت شما میتونید مطمئن بشید که هیچ کامیتی روی پروژتون ناقص نیست.

مزایای کامیت اتمی

1. حفظ سلامت کد: با کامیت اتمی، شما مطمئن می‌شید که هیچ تغییر نصفه و نیمه‌ای توی کدتون باقی نمی‌مونه. این به خصوص وقتی که چند نفر روی یک پروژه کار می‌کنن، خیلی اهمیت داره. چون باعث میشه که کد همیشه در حالت درستش باشه.

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

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

4. مرج (merge) راحت‌تر: وقتی شما کامیت‌های اتمی داشته باشید، مرج برنچ‌های مختلف پروژه خیلی راحت‌تر انجام می‌شه. چون تغییرات به وضوح مشخص هستن و احتمال کانفلیکت کمتر می‌شه.

معایب کامیت اتمی

1. افزایش تعداد کامیت‌ها: یکی از مشکلات این روش اینه که ممکنه تعداد کامیت‌ها زیاد بشه. این ممکنه مدیریت ریپو رو یه مقدار پیچیده‌تر کنه.

2. نیاز به برنامه‌ریزی دقیق‌تر: برای اینکه بتونید کامیت‌های اتمی داشته باشید، باید تغییرات رو با دقت بیشتری برنامه‌ریزی کنید. این ممکنه کمی زمانبر باشه و توسعه‌دهنده‌ها نیاز داشته باشن تا به این روش عادت کنن.

3. پیچیدگی در مرج‌های بزرگ: اگر پروژه خیلی بزرگ باشه و تعداد زیادی کامیت اتمی داشته باشید، ممکنه مرج تغییرات پیچیده‌تر بشه. چون باید تعداد زیادی کامیت رو با هم مرج کنید.

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

نتیجه‌گیری

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

@Ahura_Rahmani | #Ahur4 #Atomic_Commit #Version_Control #Develop

یه سر به فیلد های شغلی vulnerability assesment و peneration testing بزنیم.

ببینید به زبان ساده وقتی شما فقط از اسکنر های آماده برای پیدا کردن آسیب پذیری ها ( CSRF, LFI, SSRF یا Sqlinjection و XSS و ... ) استفاده میکنید و تستی روی اون ها انجام نمیدید که ببینید قابل Exploit هست یا نه دارید توی فیلد Vulnerability Assesment فعالیت میکنید.

که خب یسری بدی ها داره، برای مثال بعضی وقتا این ابزار ها ( Nexus, Acunetix و SqlMap و ... ) میان و باگی که وجود نداره رو میگن وجود داره که اصطلاحا بهش میگن False Positive عامیانش یعنی اشتباه خوب، اشتباهی که ضرر خاصی نداره.

و یا میان و یک سری آسیب پذیری هایی که وجود دارن رو نمیشناسن که بهش میگن False Negative که عامیانش میشه اشتباه بد، این خیلی مشکل ساز میشه ( البته در بعضی موارد شاید آسیب پذیری ZeroDay باشه که حق داره شناساییش نکنه. ) در این فیلد شما در نهایت خروجی ابزار های اسکنر رو به عنوان گزارش کارتون به کارفرما ارائه میدید.

در فیلد Peneration Testing شما همون کار های Vulnerability Assesment رو انجام میدید ولی با این تفاوت که هر آسیب پذیری پیدا شد سعی میکنید اون رو Exploit کنید، در این حالت ما دیگه چیزی به اسم False Positive یا False Negative نخواهیم داشت.
بلکه تمام آسیب پذیری های یافت شده راستی آزمایی میشن و گزارش کاملی به کارفرما ارائه خواهد شد.

بجز این موارد یک فیلد شغلی داریم به نام Red Team.
شخصی که در این فیلد کار میکنه وظیفش اینه که سازمان رو تحت یکسری حملات واقعی قرار بده تا سعی کنه واقعا مثل یک هکر با اتکا به دانش خودش به اطلاعات سازمان دسترسی پیدا کنه و در نهایت تمامی ضعف های اون سازمان رو بصورت گزارش دقیق و تخصصی ارائه کنه تا در واقع باعث ارتقای امنیت سازمان بشه.

معنی Exploit : بهره برداری از یک آسیب پذیری.
معنی ZeroDay : آسیب پذیریی که هیچکس بجز متخصصی که اون رو کشف کرده چیزی ازش نمیدونه.

@Ahura_Rahmani | #Ahur4 #Vulnerability_Assesment #Peneration_Testing #Security

داکر یه پلتفرم OpenSource عه که برای ران کردن برنامه هاتون بصورت کاملا ایزوله استفاده میشه و از برنامه شما یک image میسازه و اون رو در قالب یک container ران میکنه. یسری تعاریفی که بدونید خالی از لطف نیست. ۱ - اولین مورد Docker Image عه که میاد کل نیازمندی…

داکر یه پلتفرم OpenSource عه که برای ران کردن برنامه هاتون بصورت کاملا ایزوله استفاده میشه و از برنامه شما یک image میسازه و اون رو در قالب یک container ران میکنه. یسری تعاریفی که بدونید خالی از لطف نیست. ۱ - اولین مورد Docker Image عه که میاد کل نیازمندی…

داکر یه پلتفرم OpenSource عه که برای ران کردن برنامه هاتون بصورت کاملا ایزوله استفاده میشه و از برنامه شما یک image میسازه و اون رو در قالب یک container ران میکنه.

یسری تعاریفی که بدونید خالی از لطف نیست.

۱ - اولین مورد Docker Image عه که میاد کل نیازمندی های پروژتون رو به همراه سورس کد بصورت آماده تو خودش نگه میداره.

۲ - دومین مورد هم Docker Container عه که یک نمونه اجرایی از image ای هست که ساختید.

۳ - سومین مورد Dockerfile عه که شامل دستورات مورد نیاز برای ساخت یک Docker Image میشه و هر کانفیگی که نیاز دارید توی اون انجام میدید.

توی داکر فایل دستوراتی که استفاده میشن کامند های لینوکسی هستن پس اگر با Bash Script و Linux در حد Linux Essential آشنا باشید کارتون خیلی راحت تره.
البته لینوکسی یا ویندوزی بودن کامند ها بستگی به نوع سیستم عامل image داره ولی اینجا بیشتر روی لینوکس و پایتون تمرکز داریم.

اینجا یک Sample از نحوه Dockerfile نوشتن برای یک پروژه FastAPI رو با هم بررسی میکنیم :

```
# از image رسمی پایتون به عنوان image والد استفاده میکنیم
FROM python:3.9-slim

# به این شکل environment مورد نیازمون رو ست میکنیم
ENV PORT 8000

# ورک دایرکتوری‌ Container رو مشخص میکنیم
WORKDIR /app

# محتوای پروژمون رو به ورک دایرکتوری انتقال میدیم.
COPY . /app

# وابستگی های پروژمون رو نصب میکنیم
RUN pip install --no-cache-dir -r requirements.txt

# اجازه میدیم که خارج از این محیط ایزوله به پورت 8000 مون دسترسی داشته باشن
EXPOSE 8000

# در نهایت پروژمون رو ران میکنیم ( دقت کنید توی هر داکر فایل باید فقط یکبار از دستور CMD استفاده بشه )
CMD ["python", "app.py"]
```

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

docker build \-t image\_name

این دستور برای ساخت Docker image از روی Dockerfile ای هست که نوشتید.

docker run image\_name

این دستور برای ران کردن image عه که در واقع میاد از روی Docker image یک Docker Container میسازه.

docker ps

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

docker stop container\_id

با این دستور میتونید یک container در حال اجرا رو متوقف کنید.

docker rm container\_id

این دستور container مورد نظرتون رو حذف میکنه.

docker rmi image\_name

این دستور image مورد نظرتون رو حذف میکنه.

docker exec \-it container\_id command

از این دستور برای اجرای یک command در container در حال اجرا استفاده میشه. که اگر خواستید کاملا وارد container بشید میتونید بجای عبارت command تایپ کنید sh تا یک سشن ترمینال بهتون بده.

docker pull image\_name

این دستور برای دریافت یک image از docker hub یا یک registry دیگه استفاده میشه ( بصورت پیشفرض registry مورد استفاده hub.docker.com هست. )

docker images

این دستور یک لیست از تمام image های روی سیستم بهتون میده.

@Ahura_Rahmani | #Ahur4 #Docker #Linux

آخرین ورژن اسکنر امنیتی وب و شبکه Acunetix نسخه لینوکس

Password : Pwn3rzs

این اسکنر یکی از قوی ترین اسکنر های آسیب پذیری موجوده که بیش از ۷۰۰۰ آسیب پذیری رو شناسایی میکنه ( شامل تمام CVE ها و حتی برخی 0Day ها ) و در پایان یک گزارش کامل از آسیب پذیری های موجود و نحوه Fix و نحوه Exploit شون بهتون میده.

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

میتونید روی پروژه های خودتون تست نفوذ انجام بدید تا از شر باگ های امنیتی راحت بشید.

برای فیلد vulnerability assesment یک معجزست و کار peneration tester هارو هم خیلی خوب راه میندازه ( اگر آشنا نیستید نگران نباشید بعدا در موردش توضیح میدم. )

@Ahura_Rahmani | #Ahur4 #Vulnerability_Scanner #Acunetix #Vulnerability_Assesment #Peneration_Testing

هوک های pre-push و pre-commit هوک هایی هستن که برای بررسی کد های پروژتون قبل از اعمال تغییرات در استیج های push یا commit استفاده میشن.

میتونید هوک های pre-commit و pre-push رو با نصب ماژول pre-commit تعریف کنید :

pip install pre\-commit

با دستور زیر هم میتونید یکسری هوک های مرسوم رو نصب کنید :

```
# برای نصب هوک های pre-commit
pre-commit install

# برای نصب هوک های pre-push
pre-commit install --hook-type pre-push
```

بعد از انجام این مرحله باید یک فایل به نام pre-commit-config.yml در root پروژه بسازید و در اون فایل مشخص کنید که از چه hook هایی میخواین استفاده کنید.
دقت کنید که کانفیگ مربوط به pre-push هم باید توی همین فایل انجام بدید.

وقتی سعی کنید کدی که در اون تغییری ایجاد کردید رو push یا commit کنید بر اساس hook هایی که تعریف کردید یک سری بررسی ها روی کدتون اعمال میشه و در صورتی که کدتون با استاندارد های تعریف شده مغایرت داشته باشه عملیات push یا commit با شکست مواجه میشه.

یک نمونه برای فایل pre-commit-config.yml :

repos: \- repo: https://github.com/pre\-commit/pre\-commit\-hooks rev: v3.1.0 hooks: \- id: end\-of\-file\-fixer stages: [commit] \- id: trailing\-whitespace stages: [commit] \- repo: https://github.com/psf/black rev: 19.10b0 hooks: \- id: black stages: [push]

در این نمونه هوک های end\-of\-file\-fixer و trailing\-whitespace در استیج commit و هوک black در استیج push مورد استفاده قرار میگیرن.

برای جزئیات بیشتر میتونید این لینک رو بررسی بکنید.

@Ahura_Rahmani | #Ahur4 #Git #Pre_Commit #Pre_Push