بعد از کلی زمان گزاشتن روی پروژه LaraGram بلاخره در سایت تلگرام هم منتشر شد 🤝

کتابخانه ی بالایی (PTB) هم ساخت یکی از دوستان هست
فرصت داشتید STAR بدید به دو ریپوزیتوری زمان زیادی نمیبره❤️
.

#design_patterns
دیزاین پترن Repository یکی از الگوهای معماری مورد استفاده در توسعه نرم‌افزار است که به عنوان واسطی بین بخش‌های داده‌ی دائمی (مثل دیتابیس) و بخش‌های کد برنامه مورد استفاده قرار می‌گیرد. هدف اصلی این دیزاین پترن، جداسازی لایه‌های داده از لایه‌های برنامه‌نویسی و ایجاد یک واسط یکسان برای دسترسی و مدیریت داده‌ها می باشد.

فرض کنید که شما در حال توسعه یک برنامه‌ی وب برای مدیریت اطلاعات کاربران هستید. اطلاعات کاربران (مانند نام، ایمیل، رمزعبور و ...) در یک پایگاه داده‌ی رابطه‌ای (مثل MySQL) ذخیره می‌شود. به جای اینکه در کد برنامه‌ی خود مستقیماً با پایگاه داده ارتباط برقرار کنید، از دیزاین پترن Repository استفاده می‌کنیم.

مثال :

ابتدا یک Interface برای Repository تعریف می‌کنیم که متد‌هایی برای ایجاد (create)، خواندن (read)، بروزرسانی (update) و حذف (delete) اطلاعات کاربران داشته باشد.

interface UserRepositoryInterface {
  public function create(array $data): bool;
  public function read(int $id): array;
  public function update(int $id, array $data): bool;
  public function delete(int $id): bool;
}

حالا یک کلاس برای Repository برای دیتابیس MySQL ایجاد می‌کنیم و متدهای Interface را پیاده‌سازی می‌کنیم.

class MySQLUserRepository implements UserRepositoryInterface {
  private $connection;

  public function __construct(mysqli $connection) {
    $this->connection = $connection;
  }

  public function create(array $data): bool {
    // Code to create user
    return true;
  }

  public function read(int $id): array {
    // Code to select user by id
    $data = ['userDataFromDb'];
    return $data;
  }

  public function update(int $id, array $data): bool {
    // Code to update user
    return true;
  }

  public function delete(int $id): bool {
    // Code to delete user
    return true;
  }
}

حالا می‌توانیم در برنامه‌ی خود از Repository استفاده کنیم.
// create connection and repository
$connection = new mysqli("localhost", "username", "password", "database_name");
$userRepository = new MySQLUserRepository($connection);

// create new user
$newUser = [
'name' => 'John Doe',
'email' => 'john@example.com',
'password' => 'hashed_password'
];
$userRepository->create($newUser);

// select user by id
$userData = $userRepository->read(1);
print_r($userData);

// update user by id
$updatedUser = [
'name' => 'Jane Doe',
'email' => 'jane@example.com',
'password' => 'new_hashed_password'
];
$userRepository->update(1, $updatedUser);

// delete user
$userRepository->delete(1);

در این مثال، با استفاده از اینترفیس UserRepositoryInterface، وابستگی‌های کد به پایگاه داده جدا می‌شود. سپس با پیاده‌سازی کلاس MySQLUserRepository، کار با پایگاه داده‌ی MySQL به صورت مستقیم در Repository انجام می‌شود. این جداسازی باعث می‌شود تا می‌توانیم با تغییر پایگاه داده، کد برنامه‌ی خود را به راحتی تغییر داده و با اطمینان از عملکرد درست نرم‌افزار خود مطمئن شویم. همچنین، این کار باعث می‌شود که مدیریت داده‌ها و دسترسی به آن‌ها به صورت مجزا و قابل مدیریت‌تری صورت گیرد.
.

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

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

مثال:

ابتدا یک اینترفیس برای استراتژی‌ها تعریف می‌کنیم که متد محاسبه قیمت نهایی محصول را دارد.

interface PricingStrategy {
  public function calculateFinalPrice(float $price): float;
}

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

class RegularPricingStrategy implements PricingStrategy {
  public function calculateFinalPrice(float $price): float {
    return $price;
  }
}

class DiscountPricingStrategy implements PricingStrategy {
  private $discountPercentage;

  public function __construct(float $discountPercentage) {
    $this->discountPercentage = $discountPercentage;
  }

  public function calculateFinalPrice(float $price): float {
    $discountAmount = $price * ($this->discountPercentage / 100);
    return $price - $discountAmount;
  }
}

class SpecialCustomerPricingStrategy implements PricingStrategy {
  private $specialPrice;

  public function __construct(float $specialPrice) {
    $this->specialPrice = $specialPrice;
  }

  public function calculateFinalPrice(float $price): float {
    return $this->specialPrice;
  }
}

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

$strategy = new SpecialCustomerPricingStrategy(10);

$price = 100; 
$finalPrice = $strategy->calculateFinalPrice($price);

echo "Final Price: $finalPrice";

Result:
Final Price: 90

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

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

برای توسعه فرانت اپ های دسکتابی از Html, Css, Js استفاده می کنه و این یعنی توسعه اپ دسکتاپ برای توسعه دهنده های وب به سادگی آب خوردنه.

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

نکته جالب تر، از اونجایی که فرانت کار با Html, Css, Js هست شما میتونید از react یا vue هم استفاده کنید یا حتی bootstrap و tailwindcss.

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

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

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

خب با مک بوک هم سعی کردم تست بکنم ولی باگ های زیادی فعلا داره و تقریبا بی استفاده هست.
در نتیجه به بحث دیزاین پترن ها ادامه میدیم تا ورژن های جدید تر بیاد.🤝
.

#design_patterns
دیزاین پترن Facade یکی از الگوهای معماری نرم‌افزاری است که به انتزاع کردن یک رابط ساده‌تر برای دسترسی به ساب سیستم های پیچیده‌تر کمک می‌کند. این الگو، واسطی ساده‌تر برای اجزای پیچیده‌تر سیستم ایجاد می‌کند تا به کاربران اجازه دهد با سیستم برخورد کنند بدون اینکه جزئیات پیچیده را مد نظر قرار دهند.

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

مثال :

ابتدا یک کلاس Facade برای فرآیند پرداخت ایجاد می‌کنیم که به عنوان واسط ساده‌تر با کاربران ارتباط برقرار می‌کند.

class PaymentFacade {
  private $paymentGateway;
  private $transactionLogger;

  public function __construct() {
    $this->paymentGateway = new PaymentGateway();
    $this->transactionLogger = new TransactionLogger();
  }

  public function processPayment($creditCard, $amount) {
    // Communication with the bank server through PaymentGateway
    $response = $this->paymentGateway->makePayment($creditCard, $amount);

    // Register the transaction in the TransactionLogger
    $this->transactionLogger->logTransaction($creditCard, $amount, $response);

    return $response;
  }
}

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

class PaymentGateway {
  public function makePayment($creditCard, $amount) {
    // Connect to the bank server and make payment
    return "Transaction Successful";
  }
}

class TransactionLogger {
  public function logTransaction($creditCard, $amount, $response) {
    // Record the transaction in the database or log file
  }
}

حالا می‌توانیم در برنامه‌ی خود از کلاس Facade استفاده کنیم و با استفاده از یک متد ساده‌تر فرآیند پرداخت را انجام دهیم.

$paymentFacade = new PaymentFacade();

$creditCard = '1234-5678-9012-3456';
$amount = 100;

$response = $paymentFacade->processPayment($creditCard, $amount);

echo $response;

Result:
Transaction Successful

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

#design_patterns
دیزان پترن Dependency Injection یکی از دیزان پترن های نرم‌افزاری است که به کاهش وابستگی‌ها (Dependencies) در بین کلاس‌ها کمک می‌کند. این الگو، از جمله اصول اصلی SOLID است که به عنوان یک راهنمای خوب برای طراحی کد قابل‌خواندن، قابل‌تغییر و قابل‌تست در نظر گرفته می‌شود.

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

مثال:

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

class EmailSender {
  private $mailer;

  public function __construct(MailerInterface $mailer) {
    $this->mailer = $mailer;
  }

  public function sendEmail($to, $subject, $body) {
    // Send email using $this->mailer
    // ...
  }
}

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

interface MailerInterface {
  public function send($to, $subject, $body);
}

حالا می‌توانیم کلاس‌های مختلفی برای سرویس‌های ارسال ایمیل ایجاد کنیم که از اینترفیس MailerInterface ارث‌بری می‌کنند.

class SmtpMailer implements MailerInterface {
  public function send($to, $subject, $body) {
    // Send email via SMTP
  }
}

class ExternalApiMailer implements MailerInterface {
  public function send($to, $subject, $body) {
    // Send email via external API
  }
}

// etc. for other email delivery services

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

// Use SmtpMailer
$smtpMailer = new SmtpMailer();
$emailSender = new EmailSender($smtpMailer);
$emailSender->sendEmail('user@example.com', 'Test Subject', 'Test Body');

// Use ExternalApiMailer
$externalApiMailer = new ExternalApiMailer();
$emailSender = new EmailSender($externalApiMailer);
$emailSender->sendEmail('user@example.com', 'Test Subject', 'Test Body');

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

ادامه در پست بعدی ...
.

#design_patterns

... ادامه پست قبلی

در مثال بالا با تزریق وابستگی ها از طریق کاستراکتور آشنا شدیم، اما راه های دیگری نیز وجود دارد. شامل:
1 - Setter Injection :
در این روش، به جای تزریق وابستگی‌ها از طریق کانستراکتور، از متدهای Setter کلاس استفاده می‌کنیم تا وابستگی‌ها را تنظیم کنیم.

class EmailSender {
  private $mailer;

  public function setMailer(MailerInterface $mailer) {
    $this->mailer = $mailer;
  }

  public function sendEmail($to, $subject, $body) {

  }
}

$smtpMailer = new SmtpMailer();
$emailSender = new EmailSender();
$emailSender->setMailer($smtpMailer);
$emailSender->sendEmail('user@example.com', 'Test Subject', 'Test Body');

————

2 - Method Injection :
در این روش، وابستگی‌ها را به صورت آرگومان‌های ورودی به متدها تزریق می‌کنیم.

class EmailSender {
  public function sendEmail($to, $subject, $body, MailerInterface $mailer) {

  }
}

$smtpMailer = new SmtpMailer();
$emailSender = new EmailSender();
$emailSender->sendEmail('user@example.com', 'Test Subject', 'Test Body', $smtpMailer);

————

3 - Container (IoC) Injection :
در این روش، از یک کانتینر (Container) نرم‌افزاری برای ایجاد شئ ها و تزریق وابستگی‌ها استفاده می‌شود. این کانتینر مسئول ایجاد و مدیریت شئ ها و تزریق وابستگی‌ها به طور خودکار است.

$container = new Container();

$container->register('mailer', SmtpMailer::class);
$container->register('emailSender', EmailSender::class)->withArgument('mailer');
$emailSender = $container->get('emailSender');
$emailSender->sendEmail('user@example.com', 'Test Subject', 'Test Body');

تمام این روش‌ها برای تزریق وابستگی‌ها مناسب هستند و انتخاب بین آن‌ها بستگی به نیازها و معماری کد شما دارد. استفاده از Dependency Injection باعث کاهش وابستگی‌ها و افزایش انعطاف‌پذیری و قابلیت تست کد می‌شود.
.

#design_patterns
دیزاین پترن Template Method یکی از الگوهای رفتاری است که در طراحی نرم‌افزارها مورد استفاده قرار می‌گیرد. این الگو به شما امکان می‌دهد یک چارچوب اصلی برای یک الگوریتم تعریف کنید که بخش‌هایی از آن را به کلاس‌های زیرمجموعه خود می‌سپارید تا به صورت مستقل اجرا شوند. با این روش، تغییرات در الگوریتم اصلی به کلاس‌های زیرمجموعه انتقال پیدا نمی‌کند و همچنین از دسترسی به متدهای مشترک و ارتباط موثر با آن‌ها برخوردار خواهید بود.

فرض کنید که می‌خواهیم یک کلاس برای ساخت یک نوشیدنی دم‌نوش تعریف کنیم که از دو مرحله پیش‌تهیه (Prepare) و تهیه (Brew) تشکیل شده است. این کلاس باید اجازه دهد که بخش‌هایی از فرآیند دم‌نوش‌سازی توسط subclass ها (نمونه‌ها) اجرا شوند.

مثال:
ابتدا این کلاس یک الگوریتم اصلی برای ساخت نوشیدنی دم‌نوش ارائه می‌دهد که شامل مراحل Prepare و Brew است.

abstract class Beverage
{
  public function makeBeverage()
  {
    $this->boilWater();
    $this->brew();
    $this->pourInCup();
    $this->addCondiments();
  }

  public function boilWater()
  {
    echo "Boiling water...\n";
  }

  public function pourInCup()
  {
    echo "Pouring into cup...\n";
  }

  // Methods required by subclasses must be defined here
  abstract public function brew();
  abstract public function addCondiments();
}

سپس subclass ها با توجه به نوشیدنی موردنظر، متدهای brew و addCondiments را پیاده‌سازی می‌کنند.

class Tea extends Beverage
{
  public function brew()
  {
    echo "Steeping the tea...\n";
  }

  public function addCondiments()
  {
    echo "Adding lemon...\n";
  }
}

class Coffee extends Beverage
{
  public function brew()
  {
    echo "Dripping coffee through filter...\n";
  }

  public function addCondiments()
  {
    echo "Adding sugar and milk...\n";
  }
}

حالا می‌توانیم از کلاس‌ها و زیرکلاس‌های آن‌ها برای ساخت نوشیدنی دم‌نوش استفاده کنیم.

$tea = new Tea();
$tea->makeBeverage();

Result:
Boiling water...
Steeping the tea...
Pouring into cup...
Adding lemon...

$coffee = new Coffee();
$coffee->makeBeverage();

Result:
Boiling water...
Dripping coffee through filter...
Pouring into cup...
Adding sugar and milk...

در این مثال، با استفاده از دیزاین پترن Template Method، یک چارچوب اصلی برای ساخت نوشیدنی دم‌نوش با مراحل مشترک boilWater و pourInCup تعریف کردیم و بخش‌های خاص هر نوشیدنی را در subclass ها تعیین کردیم. این الگو باعث از دست رفتن تکرار کد، افزایش قابلیت توسعه و حفظ ساختار یکپارچه‌ای در کلاس‌ها می‌شود.
.

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

فرض کنید که یک کلاس به نام MyList داریم که یک لیست از اشیاء را نمایش می‌دهد. برای دسترسی به عناصر لیست به صورت مرتب شده و به ترتیب، از الگوی طراحی Iterator استفاده می‌کنیم.

مثال:

این کلاس یک لیست از اشیاء را نگهداری می‌کند و اجازه دسترسی به اشیاء به ترتیب را از طریق Iterator مرتب‌شده ارائه می‌دهد.

class MyListIterator implements Iterator
{
  private $list;
  private $index = 0;

  public function __construct(MyList $list)
  {
    $this->list = $list;
  }

  public function rewind()
  {
    $this->index = 0;
  }

  public function valid()
  {
    return $this->index < count($this->list->getItems());
  }

  public function current()
  {
    return $this->list->getItems()[$this->index];
  }

  public function key()
  {
    return $this->index;
  }

  public function next()
  {
    $this->index++;
  }
}

class MyList
{
  private $items = [];

  public function addItem($item)
  {
    $this->items[] = $item;
  }

  public function getItems()
  {
    return $this->items;
  }

  public function getIterator()
  {
    return new MyListIterator($this);
  }
}

حالا می‌توانیم از کلاس MyList برای دسترسی به اشیاء به ترتیب از طریق Iterator استفاده کنیم.

$list = new MyList();
$list->addItem('Item 1');
$list->addItem('Item 2');
$list->addItem('Item 3');

$iterator = $list->getIterator();
foreach ($iterator as $index => $item) {
  echo "Item $index: $item\n";
}

Result:
Item 0: Item 1
Item 1: Item 2
Item 2: Item 3

در این مثال، با استفاده از دیزاین پترن Iterator، یک Iterator به نام MyListIterator ایجاد کردیم که اجازه دسترسی به اشیاء لیست MyList را به ترتیب فراهم می‌آورد. این الگو باعث از دست رفتن وابستگی‌های زیرکلاس‌ها به لیست و مرتب‌سازی اشیاء می‌شود و اجازه دسترسی مستقل و ترتیب‌دار به عناصر لیست را فراهم می‌کند.
.

خب مبحث دیزاین پترن ها اینجا تموم شد.

البته که تعداد دیزاین پترن ها خیلی بیشتر از این ۱۰ تا هست، ولی خب خودم زیاد کار نکردم که بخوام توضیحی بدم، در نتیجه این مبحث اینجا تموم میشه و احتمالا در آینده اگه فعالیتم ادامه پیدا کرد بازم توضیح میدم راجبشون.

ولی به عنوان مبحث بعدی قرار شد راجب انواع باگ های امنیتی و جلوگیری ازشون توضیح بدم.
تعداد باگ هایی که قراره توضیح بدم بیشتر از ۲۰ تا هست که طبیعتا زمان بره، ولی خب با هم پیش میریم.

فقط امیدوارم بخونید مطالب رو ...
.

خب باگ هارو دسته بندی کردم و هر روز یکی از این دسته هارو توضیح میدم، مگر اینکه دسته بندی بزرگی باشه.
دسته بندی باگ ها به صورت زیر هست:
1- Injection Attacks
2- Cross-Site Attacks
3- Authentication and Session Management Vulnerabilities
4- Access Control and Data Exposure
5- Remote Code Execution (RCE)
6- Denial of Service (DoS) Attacks
7- Information Leakage
8- Business Logic Errors
9- Cryptographic Vulnerabilities
10- Privilege Escalation Vulnerabilities
11- Race Conditions
.

#security #bug
دسته بندی Injection Attacks

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

مثال:

فرض کنید یک وب‌سایت دارای صفحه‌ای است که کاربران می‌توانند با وارد کردن نام کاربری خود، اطلاعات حساب کاربری خود را مشاهده کنند. وب‌سایت ممکن است از دیتابیسی استفاده کند که دارای جدولی با نام "users" است. حالا فرض کنید کد PHP این صفحه به صورت زیر باشد:

$username = $_POST['username'];
$query = "SELECT * FROM users WHERE username='$username'";

حمله‌کننده می‌تواند در فیلد ورودی نام کاربری خود را وارد کند و در عین حال یک دستور SQL مخرب به طور همزمان وارد کند. به عنوان مثال:

' OR '1'='1' --

پس از اجرای کوئری، دستور SQL به شکل زیر تبدیل می‌شود:

SELECT * FROM users WHERE username='' OR '1'='1' --'

این دستور SQL به معنی "انتخاب همه ردیف‌ها از جدول کاربران (users) در صورتی که '1' برابر با '1' باشد" است. همچنین، بخش -- کامنت کننده باقی‌مانده‌ی دستور SQL است و هر چیزی پس از آن نادیده گرفته می‌شود.

روش های جلوگیری:

1- استفاده از Prepared Statements می‌تواند از تزریق‌های SQL جلوگیری کند. در Prepared Statements، جدا از دستور SQL اصلی، پارامتر‌ها به صورت جداگانه ارسال می‌شوند و در زمان اجرای کوئری جایگزین مقادیر ورودی می‌شوند.

2- برنامه‌نویسان باید ورودی‌ها را با دقت فیلتر سازی و تقویت کنند. این کار شامل حذف و یا اسکیپ کردن کاراکترهای غیرمجاز است.

3- اطمینان حاصل کنید که کاربران و برنامه‌ها فقط به سطح دسترسی لازم برای انجام کارهای خود دسترسی دارند.

4- اطلاعات خطا در وب‌سایت‌ها نباید جزئیاتی از دیتابیس یا سیستم را فاش کند.

5- مطمئن شوید که نسخه‌های مورد استفاده از دیتابیس و کتاب‌خانه‌های آن به‌روز هستند.

.

#security #bug
دسته بندی Injection Attacks

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

مثال :

فرض کنید یک برنامه وب با زبان PHP نوشته شده است و قصد دارد یک فایل متنی را با استفاده از نام فایل که کاربر وارد می‌کند، نمایش دهد. کد PHP به صورت زیر است:

$filename = $_GET['filename'];
$file_contents = file_get_contents('/path/to/files/' . $filename);
echo $file_contents;

حمله‌کننده می‌تواند نام فایل خود را به صورت کد اجرایی وارد کند تا اجرای کد مخرب را فراهم آورد. به عنوان مثال:

my_file.txt'; echo "Hello, I am an attacker!"; exit; //

پس از اجرای برنامه، کد PHP به شکل زیر تبدیل می‌شود:

$filename = 'my_file.txt'; echo "Hello, I am an attacker!"; exit; //';
$file_contents = file_get_contents('/path/to/files/' . $filename);
echo $file_contents;

این باعث اجرای کد مخرب "Hello, I am an attacker!" می‌شود و برنامه به پایان می‌رسد.

روش های جلوگیری:

1- همانند SQL Injection، استفاده از Prepared Statements می‌تواند از تزریق‌های کد و جلوگیری از Code Injection جلوگیری کند.

2- برنامه‌نویسان باید ورودی‌ها را با دقت فیلتر سازی و تقویت کنند. این کار شامل حذف و یا اسکیپ کردن کاراکترهای غیرمجاز است.

3- باید از تابع‌ها و دستوراتی که می‌توانند کدها را اجرا کنند، به‌عنوان ورودی در برنامه استفاده نکنید.

4- اطمینان حاصل کنید که برنامه‌ها فقط به فایل‌های مورد نیاز دسترسی دارند و به فایل‌های حساس و اجرایی دسترسی ندارند.

5- مطمئن شوید که برنامه‌ها و کاربران فقط به کمترین دسترسی لازم برای انجام کارهای خود دسترسی دارند.

6- اطلاعات خطا در برنامه‌ها نباید جزئیاتی از ساختار دیتابیس یا کدهای خطرناک را فاش کند.

.

#security #bug
دسته بندی Injection Attacks

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

مثال :

فرض کنید یک برنامه وب با زبان PHP نوشته شده است که قصد دارد یک سیستم پشتیبان‌گیری را اجرا کند و فایل‌های مورد نیاز را از یک مسیر خاص به مسیر دیگر کپی کند. کد PHP به صورت زیر است:

$source_file = $_POST['source_file'];
$destination_path = $_POST['destination_path'];

$command = "cp $source_file $destination_path";
$output = shell_exec($command);
echo "File copied successfully.";

حمله‌کننده می‌تواند در فیلد‌های ورودی، دستورات سیستم عامل را به صورت تزریق‌شده وارد کند. به عنوان مثال:
source_file: /etc/passwd
destination_path: /var/www/html/

پس از اجرای برنامه، دستورات سیستم عامل به شکل زیر تبدیل می‌شود:

cp /etc/passwd /var/www/html/

این دستور کپی فایل /etc/passwd (که یک فایل حاوی اطلاعات حساب‌های کاربری سیستم است) به مسیر /var/www/html/ اجرا می‌شود و حمله‌کننده ممکن است به اطلاعات حساب‌های کاربری سیستم دسترسی پیدا کند.

روش های جلوگیری:

1- همانند SQL Injection و Code Injection، استفاده از Prepared Statements می‌تواند از تزریق‌های دستور سیستم عامل جلوگیری کند.

2- برنامه‌نویسان باید ورودی‌ها را با دقت فیلتر سازی و تقویت کنند. این کار شامل حذف و یا اسکیپ کردن کاراکترهای غیرمجاز است.

3- از فراخوانی‌های محدود یا محدود‌سازی‌شده که فقط اجازه فراخوانی دستورات سیستم مشخص را به برنامه‌ها می‌دهد، استفاده کنید.

4- مطمئن شوید که برنامه‌ها و کاربران فقط به کمترین دسترسی لازم برای انجام کارهای خود دسترسی دارند.

5- اطلاعات خطا در برنامه‌ها نباید جزئیاتی از ساختار سیستم عامل یا کدهای خطرناک را فاش کند.

.

#security #bug
دسته بندی Injection Attacks

باگ XML External Entity (XXE) Injection یک نوع باگ امنیتی است که در برنامه‌ها و سیستم‌هایی که با فرمت XML کار می‌کنند، رخ می‌دهد. در این حمله، حمله‌کننده با درج موجودیت‌های خارجی (External Entity) در فایل‌های XML، توانایی اجرای کدها و دستورات سیستمی را به طور غیرمجاز به برنامه می‌دهد. این کار می‌تواند منجر به دسترسی به فایل‌ها و منابع حساس، اجرای دستورات سیستمی، یا نقض حریم خصوصی وب‌سرویس‌ها شود.

مثال:

فرض کنید یک وب‌سرویس با فرمت XML برای پردازش درخواست‌ها ایجاد شده است. درخواست‌ها از کلاینت‌ها به صورت یک فایل XML ارسال می‌شوند و سپس وب‌سرویس اطلاعات مورد نیاز را از فایل XML استخراج می‌کند. کد PHP وب‌سرویس به صورت زیر است:

$xml = $_POST['xml'];
$dom = new DOMDocument();
$dom->loadXML($xml);
$data = simplexml_import_dom($dom);

$username = $data->username;
$password = $data->password;
// ...

حمله‌کننده می‌تواند در فایل XML خود موجودیت‌های خارجی (External Entity) را درج کند و از طریق آن‌ها تلاش کند به فایل‌های سرور دسترسی پیدا کند. به عنوان مثال:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [  
  <!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<user>
  <username>&xxe;</username>
  <password>malicious_password</password>
</user>

وقتی وب‌سرویس این فایل XML را پردازش می‌کند، موجودیت‌های خارجی باعث می‌شود که محتوای فایل /etc/passwd (که شامل اطلاعات حساب‌های کاربری سیستم است) به جای &xxe; در فیلد username قرار گیرد. در نتیجه، محتوای فایل /etc/passwd به عنوان نام کاربری دریافت می‌شود و این اطلاعات محرمانه نمایش داده می‌شود.

روش های جلوگیری:

1- تعیین پارامتر LIBXML_NOENT در زمان پردازش XML برای غیرفعال‌سازی خودکار موجودیت‌های خارجی.

libxml_disable_entity_loader(true);

2- به‌جای دریافت XML از ورودی کاربران، بهتر است کاربران فایل XML را آپلود کنند و برنامه از مسیر فایل آپلود شده XML استفاده کند.

3- همانند سایر باگ‌های امنیتی، اعتبارسنجی دقیق ورودی‌ها و فیلتر سازی آن‌ها برای جلوگیری از درج موجودیت‌های خارجی ضروری است.

4- استفاده از کتاب‌خانه‌ها و ابزارهایی که امکان تشخیص و جلوگیری از XXE را فراهم می‌آورند.

.

#security #bug
دسته بندی Cross-Site Attacks

باگ Cross-Site Scripting (XSS) یک نوع باگ امنیتی است که در برنامه‌های وب رخ می‌دهد. در XSS، حمله‌کننده با درج کدهای مخرب یا اسکریپت‌ها در صفحات وب، می‌تواند اجرای این کدها را بر روی مرورگر کاربران دیگر فراهم کند. این کار می‌تواند منجر به دزدیدن کوکی‌ها، اطلاعات حساب کاربری و حتی اجرای دستورات مخرب بر روی دستگاه کاربران شود.

مثال:

فرض کنید یک وب‌سایت دارای صفحه‌ای است که کاربران می‌توانند نظرات خود را ارسال کنند و این نظرات در صفحه نمایش داده می‌شوند. صفحه HTML به صورت زیر است:

<body>
  <h1>Comments</h1>
  <div id="comments">
    <?php
    $comment = $_POST['comment'];
    echo $comment;
    ?>
  </div>
  <form action="" method="post">
    <textarea name="comment"></textarea>
    <br>
    <input type="submit" value="Submit">
  </form>
</body>

حمله‌کننده می‌تواند کد XSS را در فیلد نظرات وارد کند. به عنوان مثال:

<noscript>
    alert('You have been hacked!');
</noscript>

وقتی کاربر دیگری صفحه را باز می‌کند و این نظر را مشاهده می‌کند، اسکریپت ناامن اجرا می‌شود و یک پیغام هشدار نمایش داده می‌شود.

روش های جلوگیری:

1- برنامه‌نویسان باید ورودی‌ها را با دقت فیلترسازی و تقویت کنند. این کار شامل حذف و یا اسکیپ کردن کدهای خطرناک است.

2- همواره برای نمایش مقادیر متغیرها در صفحات HTML از نقل‌قول دوگانه استفاده کنید.

3- استفاده از کتابخانه ها مانند HTML Purifier که یک کتاب‌خانه PHP است که از HTML ناامن و ویژگی‌های خطرناک جلوگیری می‌کند و امنیت نمایش محتوا را تضمین می‌کند.می توانید برای زبان های دیگر جست و جو کنید و با ما به اشتراک بگزارید.

4- اعتبارسنجی دقیق اجازه‌ها و محدودیت‌هایی را برای منابع اجرایی (noscripts, stylesheets و غیره) در صفحات HTML مشخص می‌کند.

5- اجازه دسترسی به کوکی‌ها را به دامنه‌های مشخص محدود کنید تا از کلاهبرداری کوکی جلوگیری شود.

6- برای کوکی‌هایی که توسط جاوااسکریپت به دسترسی نیاز ندارند، از HTTP Only Flag استفاده کنید. همچنین برای کوکی‌هایی که باید از طریق ارتباط امن انتقال یابند، از Secure Flag استفاده کنید.

.

#security #bug
دسته بندی Cross-Site Attacks

باگ Cross-Site Request Forgery (CSRF) یک نوع باگ امنیتی است که در برنامه‌ها و وب‌سایت‌ها رخ می‌دهد. در CSRF، حمله‌کننده با استفاده از اجرای برخی از درخواست‌ها از طریق کاربران، عملیات‌های خطرناک را با اجازه‌ی کاربر اجرا می‌کند. به عبارت دیگر، کاربر در وب‌سایتی وارد شده است که مخرب است و بدون اطلاع از آن، عملیات‌های خطرناک را در سایت‌ها و برنامه‌ها دیگر اجرا می‌کند.

مثال:

فرض کنید یک برنامه وب وجود دارد که کاربران می‌توانند با استفاده از فرمی مبلغی را به حساب خود اضافه کنند. کد PHP به صورت زیر است:

<?php
session_start();
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
  $amount = $_POST['amount'];
  $user_id = $_SESSION['user_id'];
  // Add amount to user account
}
?>
<!DOCTYPE html>
<html>
<head>
  <noscript>Account Page</noscript>
</head>
<body>
  <h1>Welcome, User!</h1>
  <form action="" method="post">
    <label for="amount">Amount:</label>
    <input type="text" name="amount" id="amount">
    <input type="submit" value="Add">
  </form>
</body>
</html>

حمله‌کننده می‌تواند یک صفحه مخرب (مثلاً با نام csrf.html) ایجاد کند و کد مخرب زیر را در آن قرار دهد:

<html>
<body>
  <form action="http://victim-website.com" method="post">
    <input type="hidden" name="amount" value="1000">
  </form>
  <noscript>
    document.forms[0].submit();
  </noscript>
</body>
</html>

وقتی کاربری که وارد برنامه‌ی مخرب حمله‌کننده شده است، از طریق مرورگر به صفحه csrf.html می‌رود، این صفحه یک درخواست POST به آدرس victim-website.com ارسال می‌کند و مبلغ 1000 به حساب کاربر در این وب‌سایت اضافه می‌شود.

روش های جلوگیری:

1- اضافه کردن یک توکن CSRF به فرم‌ها تا اطمینان حاصل شود که درخواست‌ها توسط خود کاربر ارسال می‌شوند و نه از طریق حمله‌کننده.

2- بررسی Referer Header که نشان می‌دهد از کدام سایت درخواست ارسال شده است. اگر نشان‌دهنده سایت خارجی باشد، درخواست رد شود.

3- اجازه دسترسی به کوکی‌ها تنها به دامنه‌های مشخص داده شود.

4- فقط از متود POST برای عملیات‌هایی که تغییر‌های حساب‌های کاربری می‌آورند، استفاده کنید.

.

#security #bug
دسته بندی Cross-Site Attacks

باگ Server-Side Request Forgery (SSRF) یک نوع باگ امنیتی است که در برنامه‌ها و سیستم‌ها رخ می‌دهد. در این نوع حمله، حمله‌کننده با اجازه یا بدون اجازه کاربر، سیستم به سرورها و منابع دیگری دسترسی پیدا می‌کند که نباید به آن‌ها دسترسی داشته باشد. این کار می‌تواند منجر به دسترسی به منابع داخلی و محرمانه شبکه، حمله به سیستم‌های داخلی، و یا حتی دسترسی به سرویس‌های خارجی و ایجاد هزینه‌های ناخواسته برای صاحب سرویس شود.

مثال:

فرض کنید یک برنامه وب دارای ویژگی‌هایی است که اجازه می‌دهد که عکس‌ها از یک آدرس URL را در صفحه نمایش دهد. کد PHP به صورت زیر است:

<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
  $url = $_POST['url'];
  $image_data = file_get_contents($url);
  // proccess and show images
  header('Content-Type: image/jpeg');
  echo $image_data;
}
?>
<!DOCTYPE html>
<html>
<head>
  <noscript>Image</noscript>
</head>
<body>
  <h1>Image</h1>
  <form action="" method="post">
    <label for="url">Image URL:</label>
    <input type="text" name="url" id="url">
    <input type="submit" value="View Image">
  </form>
</body>
</html>

حمله‌کننده می‌تواند یک آدرس URL مخرب (مثلاً یک سرور داخلی یا آدرس آی‌پی دیگری در شبکه داخلی) را وارد کند تا به منابع داخلی سیستم یا شبکه دسترسی پیدا کند. به عنوان مثال:

http://localhost/internal/resource

این باعث می‌شود که سیستم درخواست به URL داخلی ارسال کند و احتمالاً دسترسی به منابع داخلی را فراهم کند.

روش های جلوگیری:

1- اجازه دسترسی به منابع و سرویس‌های خارجی را تنها به دامنه‌ها و آدرس‌های معتبر محدود کنید.

2- برنامه‌ها باید درخواست‌های خود را با آدرس‌های ثابت و معتبر ارسال کنند و نباید آدرس‌ها را از ورودی کاربران استخراج کنند.

3- اطمینان حاصل کنید که ورودی‌های کاربران به طور دقیق اعتبارسنجی و فیلترسازی شده‌اند و حاوی آدرس‌های معتبر هستند.

4- تنها اجازه دسترسی به منابع مجاز را با استفاده از Whitelist بدهید.

5- اطمینان حاصل کنید که کاربران فقط به منابعی دسترسی دارند که نیاز دارند و به منابع داخلی و محرمانه دسترسی ندارند.

.

#security #bug
دسته بندی Cross-Site Attacks

باگ Clickjacking یا همچنین شناخته شده به عنوان UI Redressing، یک نوع حمله امنیتی است که در آن حمله‌کننده با استفاده از انگشت‌آوری و برتری لایه‌ی کاربری (UI)، کاربران را به انجام عملیات‌هایی که می‌خواهند، نادیده می‌گیرد و آن‌ها را به انجام عملیات‌های خطرناک یا ناخواسته می‌اندازد. این حمله با استفاده از طرح‌بندی صفحات وب یا نشان‌دهنده‌های قابل مشاهده، کاربر را به کلیک بر روی عنصری که اصلاً نمی‌خواهند ترغیب می‌کند.

مثال:

فرض کنید یک سایت بانکی وجود دارد که یک فرم احراز هویت دارد و کاربران باید نام کاربری و رمزعبور خود را وارد کنند. صفحه‌ای با نام "به‌روزرسانی امنیتی" در سایت وجود دارد که از کاربران خواسته می‌شود بر روی دکمه‌ی "تأیید" کلیک کنند تا احراز هویت را کامل کنند.

<!DOCTYPE html>
<html>
<head>
  <noscript>Secure Bank</noscript>
</head>
<body>
  <h1>Welcome to Secure Bank</h1>
  <form action="/login" method="post">
    <label for="username">Username:</label>
    <input type="text" name="username" id="username">
    <br>
    <label for="password">Password:</label>
    <input type="password" name="password" id="password">
    <br>
    <input type="submit" value="Login">
  </form>
  <iframe src="http://evil-website.com/clickjack"></iframe>
</body>
</html>

حمله‌کننده می‌تواند یک صفحه‌ی وب ایجاد کند (مثلاً با نام clickjack.html) که با استفاده از CSS و مخفی کردن عنصر‌ها، طرح‌بندی متفاوتی از صفحه‌ی Secure Bank را ایجاد کند:

<!DOCTYPE html>
<html>
<head>
  <noscript>Evil Website</noscript>
  <style>
    iframe {
      opacity: 0;
      position: absolute;
      top: 0;
      left: 0;
      height: 100%;
      width: 100%;
    }
    #fake-button {
      position: absolute;
      top: 300px;
      left: 450px;
      background-color: transparent;
      border: none;
      font-size: 18px;
      color: transparent;
    }
  </style>
</head>
<body>
  <h1>Welcome to Evil Website</h1>
  <form action="http://secure-bank.com/login" method="post">
    <label for="username">Username:</label>
    <input type="text" name="username" id="username">
    <br>
    <label for="password">Password:</label>
    <input type="password" name="password" id="password">
    <br>
    <button id="fake-button" onclick="document.getElementById('real-button').click()">Click Here</button>
    <input type="submit" id="real-button" style="display:none;">
  </form>
</body>
</html>

وقتی کاربر به صفحه Secure Bank مراجعه می‌کند، حمله‌کننده این دو صفحه (Secure Bank و Evil Website) را در یک iframe قرار می‌دهد و کاربر اصلاً آگاه نیست که عملیات احراز هویت را انجام می‌دهد. به عبارت دیگر، حمله‌کننده با نمایش دکمه‌ای در صفحه Evil Website که به نظر می‌رسد از سایت Secure Bank است، کاربر را به تایید عملیات احراز هویت ترغیب می‌کند. در واقعیت، کلیک بر روی دکمه‌ی مخفی (fake-button)، عملیات کلیک بر روی دکمه‌ی واقعی (real-button) در صفحه Secure Bank را اجرا می‌کند و حمله‌کننده به اطلاعات احراز هویت کاربر دسترسی پیدا می‌کند.

روش های جلوگیری:

1- تنظیم سیاست امنیتی "X-Frame-Options" در سرور وب که مشخص می‌کند آیا اجازه‌ی نمایش صفحه در یک iframe به صورت دیگری مجاز است یا خیر.

X-Frame-Options: DENY

OR

X-Frame-Options: SAMEORIGIN

2- تنظیم سیاست امنیتی "Content Security Policy" که محدودیت‌هایی برای اجازه‌ی اجرای اسکریپت‌ها و فرم‌ها در صفحه‌ها تعیین می‌کند.

Content-Security-Policy: frame-ancestors 'self';

3- اسکریپت‌های جاوا اسکریپت که با شناسایی Clickjacking تلاش می‌کنند iframe‌ ها را نمایش ندهند یا صفحه‌ای را در پنجره‌ی کامل باز کنند.

<noscript>
  if (window.self !== window.top) {
    window.top.location = window.self.location;
  }
</noscript>

4- برخی مرورگرها از فناوری‌های جدید مانند "Frame Ancestors" در CSP یا "Content-Security-Policy-Report-Only" برای گزارش‌دهی تنظیمات امنیتی پشتیبانی می‌کنند که می‌توانند کمک کنند به تشخیص و جلوگیری از Clickjacking.

.

#security #bug
دسته بندی Authentication and Session Management
Vulnerabilities

باگ Broken Authentication and Session Management یک نوع باگ امنیتی است که زمانی رخ می‌دهد که مکانیزم‌های احراز هویت و مدیریت نشست‌ها در برنامه‌ها و وب‌سایت‌ها به درستی پیاده‌سازی نشده‌اند. این باگ باعث می‌شود که حمله‌کننده بتواند بدون نیاز به نام کاربری و رمزعبور یا با بهره‌گیری از آسیب‌پذیری‌های موجود در احراز هویت و نشست‌ها، به حساب‌ها و محتواهای کاربران دسترسی پیدا کند.

مثال:

فرض کنید یک وب‌سایت دارای سیستم احراز هویت است که کاربران باید با نام کاربری و رمزعبور وارد شوند. برنامه به طور نادرستی رمزعبور‌ها را به صورت رمزنگاری‌نشده در دیتابیس ذخیره می‌کند.

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

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
  $username = $_POST['username'];
  $password = $_POST['password'];

  $hashed_password = md5($password);

  // Authenticate user with username and password
}

session_start();
if (isset($_SESSION['user_id'])) {
  // The user is logged in and has access to the content
}

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

1- حمله‌کننده می‌تواند مستقیماً رمزعبور‌های رمزنگاری‌نشده را از دیتابیس یا فایل‌ها به دست بیاورد و به حساب‌های کاربری دسترسی پیدا کند.

2- حمله‌کننده می‌تواند یک شناسه نشست را به کاربر تزریق کند و درخواست اجرای نشست فرضی کند، یا برعکس از نشست فرضی که خود ایجاد کرده استفاده کند.

روش های جلوگیری:

1- رمزعبور‌ها را با الگوریتم‌های رمزنگاری قوی (مانند bcrypt یا Argon2) رمزنگاری کنید.

2- از کتاب‌خانه‌ها و مکانیزم‌های احراز هویت آماده استفاده کنید تا خطاهای احتمالی در احراز هویت کاربران حداقل شود.

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

4- به جای استفاده از توکن‌های نشست قابل خواندن از توکن‌های امنیتی استفاده کنید که مقدار آن‌ها به صورت اتصالی و غیرقابل پیش‌بینی تولید شود.

5- همواره برنامه‌ها و کتاب‌خانه‌ها را به‌روزرسانی کنید تا آسیب‌پذیری‌های احتمالی در احراز هویت و مدیریت نشست‌ها برطرف شود.

.