#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- اطلاعات داخلی سیستم یا برنامه به کاربران عادی نمایش داده نشوند. این اطلاعات تنها برای اشخاصی با دسترسی مناسب قابل دسترسی باشند.

.

#security #bug
دسته بندی Business Logic Errors

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

خطای Business Logic Errors به خطاهایی اشاره دارند که در منطق کسب و کار و عملیات اصلی یک برنامه یا سیستم وجود دارند. این نوع از خطاها معمولاً به دلیل نقص در طراحی یا پیاده‌سازی منطق کسب و کار به وجود می‌آیند و می‌توانند منجر به عملکرد نادرست یا ناپایدار سیستم شوند.

مثال:

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

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

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

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

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

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

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

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

.

#security #bug

دسته بندی Cryptographic Vulnerabilities

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

مثال:

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

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

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

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

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

3- از الگوریتم‌های رمزنگاری با امنیت بالا و تاثیر ثابت مانند AES استفاده کنید.

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

5- به جز رمزنگاری، سایر اجزای سیستم را نیز به درستی محافظت کنید تا امنیت کلی تضمین شود.

6- کدها را بازبینی کرده و با تست‌های امنیتی الگوریتم‌ها و مکانیزم‌های رمزنگاری را ارزیابی کنید.

7- از مدیریت مناسب کلید‌ها و مواد رمزنگاری استفاده کنید تا از دسترسی غیرمجاز به اطلاعات جلوگیری شود.

.

#security #bug

دسته بندی Privilege Escalation Vulnerabilities

باگ Privilege Escalation Vulnerabilities به مشکلات امنیتی اشاره دارد که به حمله‌کننده اجازه می‌دهد سطح دسترسی خود را از سطح کاربر عادی به سطح دسترسی بیشتر (مانند مدیر سیستم) ارتقاء دهد. این نوع از حملات می‌توانند منجر به دسترسی غیرمجاز به منابع و عملیات حساس شوند.

مثال:

فرض کنید یک سیستم عامل با معماری چندکاربره داریم که کاربران مختلف با سطوح دسترسی متفاوت می‌توانند وارد سیستم شوند. هر کاربر به منابع معینی دسترسی دارد و کاربران معمولاً به منابع دیگر دسترسی ندارند.

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

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

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

1- به کاربران و سیستم‌ها تنها دسترسی‌های لازم را اختصاص دهید تا حداقل اصول "کمترین دسترسی" رعایت شود.

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

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

4- تست‌های امنیتی مرتب روی سیستم‌ها و نرم‌افزارها اجرا کنید تا از وجود آسیب‌پذیری‌های احتمالی آگاه شوید.

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

6- اجازه ندهید که کدهای اجرایی یا اسکریپت‌ها با دسترسی‌های بالا اجرا شوند.

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

.

#security #bug

دسته بندی Race Conditions

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

مثال:

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

حالا فرض کنید دو کاربر به طور همزمان درخواست افزایش موجودی حساب خود را می‌دهند. در صورتی که برنامه ما قابلیت همزمانی (Concurrency) را به خوبی مدیریت نکند، دو کاربر ممکن است در همان لحظه مقدار موجودی را بخوانند، هر دو مقدار جدید را محاسبه کنند و در نهایت مقدار موجودی را با توجه به محاسبات خود به روزرسانی کنند. اینجاست که Race Conditions ایجاد می‌شود؛ اگر هر دو کاربر به همان زمان به دیتابیس نوشته خود دسترسی داشته باشند، ممکن است یکی از آن‌ها تغییرات دیگری که توسط دیگری انجام داده شده است را پوشش ندهد.

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

1- برای عملیات‌هایی که به منابع مشترک دسترسی دارند، مکانیزم‌های به‌روزرسانی انحصاری (Locking) را به‌کار ببرید تا فقط یک نخ اجازه دسترسی و تغییر منبع را داشته باشد.

2- در مواردی که از پایگاه داده استفاده می‌کنید، از تراکنش‌ها برای محدود کردن دسترسی‌ها و به‌روزرسانی‌ها استفاده کنید.

3- از مکانیزم‌های Semaphore و Mutex برای مدیریت دسترسی‌های همزمانی در برنامه‌ها استفاده کنید.

4- در زبان‌های برنامه‌نویسی که از نخ‌ها (Threads) استفاده می‌کنند، از مکانیزم‌های Thread-safe مانند synchronized استفاده کنید.

5- در زبان‌های برنامه‌نویسی که از متغیرهای اتمی پشتیبانی می‌کنند، از آنها برای جلوگیری از مشکلات Race Conditions استفاده کنید.

6- طراحی مناسب و اجرای کد با رعایت اصول همزمانی و به‌روزرسانی منابع مشترک، مشکلات Race Conditions را کاهش می‌دهد.

.