#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- همواره برنامه‌ها و کتاب‌خانه‌ها را به‌روزرسانی کنید تا آسیب‌پذیری‌های احتمالی در احراز هویت و مدیریت نشست‌ها برطرف شود.

.

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

Authentication and Session Management Vulnerabilities

باگ Insecure Deserialization یک نوع باگ امنیتی است که در آن داده‌های سریالایز شده به صورت ناامن به شئ ها یا داده‌های قابل استفاده تبدیل می‌شوند. این باگ معمولاً زمانی رخ می‌دهد که برنامه‌ها از ساختار‌های مانند JSON، XML، یا دیگر فرمت‌های سریالایز شده شده برای انتقال و ذخیره‌سازی داده‌ها استفاده می‌کنند و نقاط ضعفی در تجزیه و تحلیل این داده‌ها دارند.

مثال:

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

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
  $data = $_POST['data'];
  $decoded_data = json_decode($data);

  foreach ($decoded_data['products'] as $product) {
    echo 'Product Name : ' . $product['name'] . '<br>';
    echo 'Price: ' . $product['price'] . '<br>';
    echo '----------------------<br>';
  }
}

حمله‌کننده می‌تواند با تغییر داده‌های JSON و اضافه کردن فیلدهای جدید، داده‌های تقلبی (مثل تغییر قیمت یک محصول به مقدار منفی) ارسال کند:

{"products": [{"name": "LapTop", "price": 15000000}, {"name": "Mobile", "price": -5000000}]}

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

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

1- از زبان‌های محدود و امکانات نیمه‌ای استفاده کنید تا دسترسی حساس به سیستم را محدود کنید.

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

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

4- از ساختار‌های سریالایزینگ محدود و امن استفاده کنید که دسترسی به محتوای حساس را محدود کند.

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

.

#security #bug
دسته بندی Access Control and Data Exposure

باگ Insecure Direct Object References (IDOR) یک نوع باگ امنیتی است که زمانی رخ می‌دهد که یک برنامه‌ی وب (یا نرم‌افزار دیگر) به شئ ها یا منابع مستقیما با استفاده از مقادیر قابل تغییر توسط کاربر ارجاع داده می‌شود. این ارجاع‌ها می‌توانند به داده‌ها یا منابع حساس در سیستم دسترسی پیدا کنند که قرار است توسط کاربران دیگر قابل دسترسی نباشند.

مثال:

فرض کنید یک وب‌سایت فروشگاهی به کاربران اجازه می‌دهد که به فاکتورهای خرید خود دسترسی پیدا کنند و آن‌ها را مشاهده کنند. فاکتورها با استفاده از یک شناسه یکتا (مثل شماره فاکتور) شناسایی می‌شوند و کاربران با ارسال این شناسه‌ها می‌توانند فاکتورهای خود را مشاهده کنند.

$invoice_id = $_GET['invoice_id'];

حمله‌کننده می‌تواند با تغییر شناسه فاکتور در URL، به فاکتورهای دیگر که مربوط به او نیستند، دسترسی پیدا کند:

https://example.com/view_invoice.php?invoice_id=123456

و با تغییر شناسه به شکل زیر:

https://example.com/view_invoice.php?invoice_id=987654

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

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

1- اطمینان حاصل کنید که نشانه‌ها یا شناسه‌ها برای دسترسی به منابع موثق هستند و به صورت تصادفی و قابل حدس نیستند.

2- قبل از ارجاع به یک منبع یا شئ، اعتبارسنجی دسترسی کاربر به منبع را انجام دهید و مطمئن شوید که کاربر مجاز به دسترسی به آن منبع است.

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

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

5- با استفاده از مکانیزم‌های توسعه‌یافته تحت عنوان
RBAC (Role-Based Access Control) یا ABAC (Attribute-Based Access Control)
می‌توانید سطح دسترسی‌ها را بهبود دهید.

.

#security #bug
دسته بندی Access Control and Data Exposure

باگ Security Misconfiguration زمانی رخ میدهد که تنظیمات نادرست یا ناکافی در برنامه‌ها یا سیستم‌ها پیکربندی می‌شوند. این باگ امنیتی می‌تواند باعث افشای اطلاعات حساس، آسیب به سیستم، دسترسی ناکافی یا دیگر آسیب‌های امنیتی شود.

مثال:

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

session_start();

if (!isset($_SESSION['isAdmin']) || $_SESSION['isAdmin'] !== true) {
  header("Location: /login.php");
  exit;
}

حمله‌کننده می‌تواند به سادگی با دسترسی به فایل admin_panel.php از طریق URL به پنل مدیریتی دسترسی پیدا کند حتی اگر از قبل وارد شده نباشد:

https://example.com/admin_panel.php

این امر باعث می‌شود حتی کاربرانی که دسترسی به پنل مدیریتی ندارند، اطلاعات مشتریان و دیگر اطلاعات حساس را مشاهده کنند.

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

1- از توصیه‌ها و اصول بهینه‌سازی امنیتی برای پیکربندی سیستم و برنامه‌ها استفاده کنید.

2- مطمئن شوید که اطلاعات حساس مانند رمزها، کلیدها و اطلاعات مشتریان به درستی محافظت می‌شوند و به عنوان متغیر محیطی یا فایل‌های تنظیمات به‌روزرسانی نمی‌شوند.

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

4- تنظیمات پیش‌فرض و مثال‌های غیرامن را از برنامه‌ها و سیستم‌ها حذف کنید تا از امکانات خطرناک استفاده نشود.

5- تیم توسعه‌دهنده‌ها و مدیران سیستم را در مورد تنظیمات امنیتی آموزش دهید و از توصیه‌های امنیتی به‌روزرسانی نمایند.
.

#security #bug
دسته بندی Access Control and Data Exposure

باگ File Inclusion Vulnerabilities به معنای آسیب‌پذیری‌های مرتبط با اضافه کردن فایل‌ها به یک برنامه یا سیستم است. دو نوع رایج از این آسیب‌پذیری‌ها عبارتند از:

1- Local File Inclusion (LFI):
در این حمله، حمله‌کننده سعی می‌کند فایل‌های محلی از روی سرور را به برنامه اضافه کند.
2- Remote File Inclusion (RFI):
در این حمله، حمله‌کننده به برنامه اجازه می‌دهد فایل‌های از راه دور (از سرور‌های دیگر) را به برنامه اضافه کند.

مثال:

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

$page = $_GET['page'];
include($page . '.html');

حمله‌کننده می‌تواند با تنظیم پارامتر "page" به یک مسیر محلی یا فایل مخرب، به فایل‌های محلی یا خارجی دسترسی پیدا کند:

https://example.com/index.php?page=../../etc/passwd

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

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

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

2- بهتر است از مسیرهای ثابت برای فایل‌های مورد استفاده استفاده کنید تا از حملات LFI جلوگیری شود.

3- تنظیمات دسترسی را در سیستم بهینه کنید تا کاربران توانایی دسترسی به فایل‌های حساس را نداشته باشند.

4- فایل‌ها را تنها به کاربرانی که دارای دسترسی معتبر هستند نمایش دهید.

.

#security #bug
دسته بندی Access Control and Data Exposure

باگ Cross-Origin Resource Sharing (CORS) Misconfiguration یک آسیب‌پذیری مرتبط با تنظیمات امنیتی در برنامه‌های وب است که می‌تواند منجر به دسترسی غیر مجاز به منابع مختلف (مثل فایل‌های جاوا اسکریپت یا داده‌های API) در دامنه‌های دیگر شود. این امر ممکن است باعث حملات امنیتی نظیر Cross-Site Request Forgery (CSRF) و دسترسی غیرمجاز از طریق Cross-Site Scripting (XSS) شود.

مثال:

فرض کنید شما یک وب‌سایت با دامنه‌ی example.com دارید که از یک API با دامنه‌ی api.example.org برای دریافت داده‌ها استفاده می‌کند. برای اجازه دسترسی به API، باید تنظیمات CORS در سرور API به درستی تنظیم شده باشد. اما اگر این تنظیمات نادرست باشد، حمله‌کننده می‌تواند از جاوااسکریپت نادرست در وب‌سایت‌های مخرب استفاده کند تا اطلاعات محرمانه‌ی دیگر کاربران یا حتی دسترسی به حساب کاربری آن‌ها را به دست آورد.

// attacker-site.com - Attacking site
<noscript>
  fetch('https://api.example.org/user_data', {
    method: 'GET',
    headers: {
      'Origin': 'https://attacker-site.com'
    }
  })
  .then(response => response.json())
  .then(data => {
    // Performing malicious operations with received data
  })
  .catch(error => {
    // Error handling
  });
</noscript>

اگر سرور API به‌طور نادرست تنظیمات CORS خود را تنظیم کند و همه‌ی منابع به صورت دسترسی‌پذیر (wildcard) مجاز شوند (مثل Access-Control-Allow-Origin: *)، کد مخرب اجازه دسترسی به داده‌های کاربران از دامنه‌ی مخرب خود را دریافت می‌کند.

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

1- سرور API را به‌طور دقیق تنظیم کنید تا تنها به دامنه‌های مجاز به دسترسی دسترسی داشته باشد.

Access-Control-Allow-Origin: https://example.com

2- به جای استفاده از '*' (همه) در هدر Access-Control-Allow-Origin، از دامنه‌های مجاز به دسترسی خودتان استفاده کنید.

Access-Control-Allow-Origin: https://example.com

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

Access-Control-Allow-Origin: https://example.com, https://trusted-domain.com

4- تنظیمات CORS را دوره‌ای بررسی کنید و اطمینان حاصل کنید که تنظیمات درستی دارید و منابع مجاز به دسترسی به API شما دسترسی دارند.

.

#security #bug
دسته بندی Access Control and Data Exposure



Insufficient Transport Layer Protection (Insecure SSL/TLS) 

به مشکلات امنیتی مرتبط با تضعیف یا نادرست از پروتکل‌های امنیتی SSL/TLS در ارتباطات اینترنتی اشاره دارد. استفاده نادرست از SSL/TLS می‌تواند منجر به دسترسی غیرمجاز به اطلاعات حساس کاربران، حملات "Man-in-the-Middle" و دیگر ریسک‌های امنیتی شود.

مثال:

یک وب‌سایت حاوی صفحه‌ای برای ورود کاربران به حساب کاربری است. این صفحه از ارتباط امن با استفاده از HTTPS استفاده می‌کند. اما تنظیمات نادرست SSL/TLS باعث شده تا اطلاعات ارسالی بین مرورگر کاربر و سرور به خوبی رمزگذاری نشود، به صورت دسته به مهاجم فاش شود.

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

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

1- از پروتکل HTTPS (SSL/TLS) برای ارتباطات حساس استفاده کنید تا اطلاعات بین مرورگر و سرور به‌خوبی رمزگذاری شود.

2- تنظیمات SSL/TLS سرور خود را به‌روز کنید و مطمئن شوید که از مشکلات معروف امنیتی مثل آسیب‌پذیری‌های ناشی از Cipher Suite ضعیف جلوگیری شده است.

3- معتبر بودن گواهی‌نامه SSL/TLS سرور را تأیید کنید تا از حملات "Man-in-the-Middle" جلوگیری شود.

4- تنظیمات سرور را طوری تنظیم کنید که از پروتکل‌های SSL و TLS ضعیف‌تر پشتیبانی نکند و از پروتکل‌های به‌روز و امن‌تر استفاده کند.

.

#security #bug
دسته بندی Remote Code Execution (RCE)

باگ Remote Code Execution (RCE) یکی از خطرناک‌ترین باگ‌های امنیتی است که به حمله‌کننده اجازه می‌دهد کد مخرب یا دستورات خود را بر روی سرور یا برنامه‌ای اجرا کند. این باگ می‌تواند به دسترسی نامحدود به سیستم یا دسترسی به اطلاعات حساس منجر شود.

مثال:

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

$query = $_GET['query']; 
$result = exec("grep " . $query . " data.txt");
echo "نتایج جستجو: " . $result;

حالت بدیهی این است که اگر حمله‌کننده ورودی‌هایی مخرب مانند "data.txt; rm -rf /" وارد کند، دستورات خطرناک مانند حذف همه‌ی فایل‌ها روی سرور اجرا خواهند شد.

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

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

2- از توابع و روش‌های امن در اجرای دستورات استفاده کنید. به عنوان مثال، اگر از PHP استفاده می‌کنید، از توابع مانند escapeshellcmd() یا escapeshellarg() برای اجرای دستورات استفاده کنید.

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

3- از مکانیزم‌های اجرایی امن و محدود بهره ببرید. به‌عنوان مثال، به جای استفاده از exec() در PHP، از توابع دیگری مانند shell_exec() استفاده کنید.

————-
از دیگر باگ های امنیتی این دسته بندی میتوان به Code Injection اشاره کرد که قبلا توضیح داده شده. (مشاهده)
.

#security #bug
دسته بندی Denial of Service (DoS) Attacks

این پست رو باگ نمیشه گفت یه نوع حمله هست ولی خب باید توضیح داد
حملات Denial of Service (DoS) و Distributed Denial of Service (DDoS) حملاتی هستند که هدف آن‌ها قطع یا اختلال در دسترسی به یک سرویس یا منبع خاص است. در حملات DoS، یک حمله‌کننده ترافیک زیادی به یک سرویس ارسال می‌کند تا سرویس موردنظر را به‌طور موقت یا کامل غیرفعال کند. در حملات DDoS، از یک شبکه‌ی بزرگ از دستگاه‌ها (به عنوان مثال بدافزارها) برای ارسال ترافیک مخرب به هدف استفاده می‌شود.

مثال:

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

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

1- محدودیت‌های ترافیکی را تنظیم کنید تا درخواست‌های مخرب را مهار کنید. به‌عنوان مثال، ایجاد محدودیت‌های دسترسی برای هر IP یا نرخ ترافیک.

2- سیستم‌هایی مانند Intrusion Detection Systems (IDS) یا Intrusion Prevention Systems (IPS) را برای تشخیص و جلوگیری از ترافیک مخرب استفاده کنید.

3- از مکانیزم‌های (Load Balancing) برای توزیع درخواست‌ها به صورت متوازن بین سرورهای مختلف استفاده کنید.

4- از شبکه‌های توزیع محتوا (CDN) استفاده کنید تا ترافیک از جاهای مختلف توزیع شود و باعث کاهش اثر حملات DDoS شود.

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

6- ترافیک شبکه و رفتار سرورها را به‌صورت مداوم مانیتور کنید تا هر تغییر غیرمعمولی شناسایی شود.

7- از سرویس‌های امنیتی مثل Web Application Firewall (WAF) استفاده کنید تا حملات DDoS تشخیص داده و مهار شوند.

.

#security #bug
دسته بندی Information Leakage

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

مثال:

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

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

1- پیام‌های خطا نباید حاوی جزئیات حساس باشند. به جای آن، پیام‌های کلی و مشخص کننده برای کاربران نمایش داده شوند.

2- اطلاعات حساس در پاسخ‌ها، لاگ‌ها و خروجی‌های دیگر فیلتر شوند یا به‌طور مناسب مخفی شوند.

3- اطلاعات حساس در حالت عادی به‌صورت پنهانی نمایش داده نشوند و فقط در صورت ضرورت، مانند حالت اشتباه در ورود اطلاعات، نمایش داده شوند.

4- اطمینان حاصل کنید که تنظیمات و پیکربندی‌ها (مانند فایل‌های تنظیمات) به‌طور صحیح تنظیم شده‌اند تا اطلاعات حساس منتشر نشود.

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

.