ظاهر فرم ها بطور پیشفرض سادست ولی یه سری مواقع نیازه کاستوم بشن. یک قابلیتی که css ارائه داده و خیلی مفیده accent-color هستش.

با این قابلیت میشه حتی اجزای فرم مثل check box یا radio button ها رو هم به زیبایی کاستومشون کرد بصورت دیفالت تا با ظاهر سایت هماهنگ تر بشن👌🏾
#Css
#UI
@GoldenCodeir
(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/csaba_kissi/status/1695692651188916575?t=QCxTPRVdbovbQJ-9Z8PD7w&s=35

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

مثلا؟

وقتی یک فیلد مثل password_confirmation که فقط برای بررسی صحت پسورد قراره استفاده بشه و در نهایت نیازی به ذخیره ی اون نداریم میتونیم براش از exclude استفاده کنیم. اینجوری فقط دیتای مورد نیاز به دیتابیس ارسال میشه.
#Laravel
@GoldenCodeir
(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/_newtonjob/status/1863869299569426803?t=3EjqobGwiK4Wm5Tdiq7jfQ&s=35

چرا PHP نسبت به بقیه زبان‌ها کندتر است و راهکار چیست؟ قسمت دوم

کندی PHP برای شرکت‌ها و سازمان‌های بزرگی مانند فیسبوک به یک چالش جدی تبدیل شده بود، زیرا هر فرآیند از ابتدا شروع می‌شد و این بار اضافی برای سازمان‌ها توجیه‌پذیر نبود. به همین دلیل فیسبوک تصمیم گرفت معماری HHVM را طراحی کند، که کد PHP را به بایت‌کد تبدیل کرده و به‌صورت Just-In-Time (JIT) کامپایل می‌کرد.

حالا JIT برای PHP چه کاری انجام می‌دهد؟
برای توضیح بهتر، تصور کنید یک تعمیرکار یخچال برای تعمیر روزانه در منازل، همه ابزارهای خود را با خودش ببرد. این کار نه تنها او را خسته می‌کند، بلکه باعث مصرف بیش از حد انرژی و منابع هم می‌شود.

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

و jit دقیقاً همین کار را برای کامپایل یک برنامه انجام می‌دهد؛ یعنی هر بخش از کد فقط زمانی که به آن نیاز باشد، کامپایل و اجرا می‌شود.

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

@DevTwitter |

Authentication & Authorization =

پروتکل HTTP یک پروتکل stateless هست. اگه شخصی دوبار پشت سرهم به وب سرور درخواست بفرسته، HTTP متوجه نمیشه که این کاربر همون کاربر قبلیه که درخواست فرستاده بود یعنی وضعیت کاربر رو نگه نمیداره. واسه حل این مشکل پروتکل باید وضعیت کاربر رو جایی ذخیره کنیم(باید یک شناسه از کاربر رو نگه داریم). یکی از اولین ویژگی ها و مکانیزمی که واسه این کار به وجود اومد session بود. برنامه نویس بعد از login برای کاربر یک session سمت سرور ست میکرد که بتونه کاربر رو بشناسه و Authentication و Authorization رو میتونست هندل کنه. session سمت سرور معمولا داخل یک فایل ذخیره میشه و بعد بسته شدن مرورگر کاربر از بین میره.

*❓حالا Authentication و Authorization چین؟ Authentication مشخص میکنه من کیم و ما تو این مرحله باید ثابت کنیم که چه کسی هستیم. Authorization بعد از مرحله Authentication میاد و مشخص میکنه کاربر به چه چیز هایی دسترسی داره(سطح دسترسی های مختلفی تو یک web application وجود داره، هر کاربر فقط باید بتونه اطلاعات خودش رو ویرایش کنه و ببینه و همچنین کاربر معمولی نباید به فایل های ادمین سایت دسترسی داشته باشه)
❓کوکی یا cookie چیه؟
بخاطر مشکلی که session داشت و بعد بستن مرورگر از بین میرفت، cookie رو ساختن. Cookie تو مرورگر کاربر ذخیره میشه و طول عمرش دست برنامه نویسه و به خاطر همین کاربر میتونه مدت زمان بیشتری لاگین باشه. Session ID که سمت سرور بود رو به صورت encrypt داخل cookie قرار میدن که کاربر نتونه دست کاریش کنه. به ازای هر درخواستی که کاربر میفرسته سمت سرور، مرورگر به صورت خودکار cookie رو هم واسه اون دامنه میفرسته.
❓ انواع روش های Authentication:
1⃣ Basic Authentication
2⃣ Dijest Authentication
3⃣ Form base Authentication
4⃣ Certificate Authentication
5⃣ Integrated Windows Authentication
6⃣ Token base Authentication(JWT in header)
7⃣ OAuth
8⃣* SSO

هر کدوم از روش های Authentication محدودیت ها و آسیب پذیری های مربوط به خودش رو داره. برای مثال :
- تو token base Authentication آسیب پذیری هایی مثل csrf و cors misconfiguration و cache deception به وجود نمیاد.
- وقتی اطلاعات تو cookie یا localstorage ذخیره میشه با xss میشه اطلاعات رو خوند ولی اگه تو header باشه با xss نمیتونیم بخونیمش.
- روش Basic Authentication آسیب پذیره به MITM.
- تو OAuth یک آسیب پذیری نسبتا بی ارزش مثل open redirect میتونه منجر به Account Takeover بشه.
- روش Integrated Windows Authentication مختص شبکه های مایکروسافتیه.
- روش های certificate Authentication و Integrated Windows Authentication رو تو شبکه های داخلی معمولا استفاده میکنن.
- اگه private key تو certificate Authentication لو بره منجر به mitm میشه.
- وقتی از session استفاده بشه کاربر نمیتونه دست کاریش کنه بر خلاف سایر موارد که سمت کاربر ذخیره میشه(برنامه نویس باید با encryption جلوی تغییر cookie/jwt و.... رو بگیره).
- تو form base Authentication اگه مواردی مثل Error handling رو انجام ندیم ممکنه آسیب پذیری username enumeration به وجود بیاد.
#Authentication

🔰تعریف مهندسی معکوس

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

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

🔴وقتی جواب یک مسئله را می‌دانیم. اما نمی‌دانیم این جواب پاسخ به چه سوالی است.

🔴وقتی سوال و پاسخ را می‌دانیم. اما نمی‌دانیم مسیر و فرایند رسیدن به این پاسخ چه بوده است.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

یه آسیب پذیری ظاهرا بی ارزش =

کد زیر رو در نظر بگیرین:

```

```

سناریو اینه که این فایل مربوط به یکی از فایل های پنل ادمینه که طبیعتا باید فقط ادمین دسترسی داشته باشه، از داخل sessionی که برای هر کاربر ست کرده چک میکنه ببینه اگه سطح دسترسی ای که به این کاربر داده ادمین نبود redirect کنه به صفحه home.
مشکلی که تو این کد هست اینه که درسته redirect میکنه ولی جلوی اجرا شدن کد رو نمیگیره بعد redirect و باعث میشه مابقی کد هم اجرا بشن بعد redirect. ولی چه تهدیدی داره؟
1⃣ افشا شدن response بعد از redirect :
اگه با دستور زیر به اون مسیر curl بزنیم میتونیم کل ریسپانس رو ببینیم:

curl https://target.com/admin\_panel.php

نکته : ما فقط میتونیم response رو ببینیم نه سورس کد اپلیکیشن. ممکنه برنامه نویس از توابعی استفاده کرده باشه که اطلاعات مهمی رو روی صفحه چاپ کنه مثل echo. برای درک بهتر کد زیر رو در نظر بگیرید :

```

```

2⃣ تست آسیب پذیری های مختلف!
کد زیر رو در نظر بگیرین:

```

```

آسیب پذیری ای که این کد داره Command Injectionهست. ولی نکته ای که مهمه اینه که این صفحه چون redirect میکنه خیلیا اینجا parameter fuzz انجام نمیدن و آسیب پذیری های این صفحه فقط با دسترسی ادمین قابل دیدن و تست کردنه، ولی بخاطر اشتباه برنامه نویس مهاجم میتونه parameter fuzz انجام بده و آسیب پذیری های مختلفی رو تست کنه که بسته به logic برنامه ممکنه آسیب پذیری های مختلفی رو داشته باشه. اگه باگ هانترین حتما به این نکته توجه داشته باشین موقع مواجه شدن با redirect ها.
نمونه پیلود با curl برای تست آسیب پذیری :

curl "https://target.com/admin\_panel.php?cmd=1.1.1.1|whoami" curl "https://target.com/admin\_panel.php?cmd=1.1.1.1||whoami||" curl "https://target.com/admin\_panel.php?cmd=1.1.1.1;whoami"

نکته مهم : کد های نوشته شده با php رو اگه تو سیستمتون اجرا کنین به درستی کار نمیکنن چون باید خودتون session کاربر رو ست کنین.

*⁉️روش جلوگیری چیه؟*

بعد redirect باید جلوی اجرا شدن ادامه کد رو بگیریم که میتونیم با توابع زیر انجام بدیم:

```

```

اسم آسیب پذیری :
Execution After Redirect = EAR

#EAR
#parameter_fuzz