مرحبا يا هبر!
الأمن مسألة خطيرة. وغالبًا ما تظهر المشكلات في هذا المجال بشكل غير متوقع وتكون لها عواقب غير سارة للغاية. لذلك ، تعتبر المعرفة في هذا الموضوع مهمة للغاية لكل مطور ويب.
سوف أبدي تحفظًا على الفور - أنا بعيد عن المحترفين ، لكنني أسعى لتحقيق ذلك. لذلك ، سأكون سعيدًا بالانتقاد ، لكن الهدف فقط. هذه المادة للمبتدئين الذين يرغبون في زيادة احترافهم وقيمتهم كمتخصصين.
ومع ذلك ، أظهر تطبيق أبسط التعليمات البرمجية ممكن. أعرف بعض الاستثناءات ، وأعلم حول ORM ، حول الحماية المتوفرة في الأطر. هدفي هو إظهاره بوضوح حتى يفهمه الجميع.
وهكذا ، فقد حان وقت الانتهاء من المقدمة والبدء في التدريب.
الطريق من تنفيذ المبتدئ إلى أي نتيجة عاقلة
أنا لست معتادا على العمل مع النظرية. روحي تتوق إلى الممارسة. لذلك ، عند الحديث عن موضوع الأمن ، سننظر في جميع أنواع الهجمات تقريبًا من وجهة نظر عملية - كيفية التنفيذ وكيفية الدفاع عن أنفسنا. نعم ، يمكنك أن تقول إن تعليم القرصنة ليس جيدًا ، ولكن ، لا تعرف كيف يحدث الهجوم ، ولا يمكننا بناء دفاع فعال.
XSS
حسنًا ، النوع الأول من الهجوم هو XSS. نعم ، XSS القديم الجيد الذي سمع به الجميع. XSS (البرمجة النصية للمواقع) هي نوع من الهجوم يستهدف زوار الموقع. كيف يحدث هذا: من خلال حقل الإدخال ، يكتب المهاجم تعليمات برمجية ضارة تدخل قاعدة البيانات وتؤدي مهمتها. عادةً ما يتم سرقة ملفات تعريف الارتباط من المستخدمين ، مما يتيح لهم تسجيل الدخول إلى حساباتهم دون كلمة مرور وتسجيل الدخول.
نحن ننفذ مثالا أكثر ضررا.
قدم مطورنا نموذجًا بسيطًا لإضافة تعليقات:
ملف Index.php<?php $opt = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC ]; $pdo = new PDO("mysql:host=localhost;dbname=".$db,$user,$pass,$opt); $pdo->exec("SET CHARSET utf8"); $query = $pdo->prepare("SELECT * FROM `comments`"); $query->execute(); $comments = $query->fetchAll(); if ($_POST) { $username = trim($_POST['name']); $comment = trim($_POST['comment']); $query = $pdo->prepare("INSERT INTO `comments` (`username`,`message`) VALUES ('$username', '$comment')"); $query->execute(); if ($query) { echo ' !'; header("Location: index.php"); } else { echo ' !'; } } ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>XSS</title> </head> <body> <form method="POST" class="addComment"> <input type="text" name="name" placeholder="Username"> <textarea name="comment"></textarea> <input type="submit" value=" "> </form> <div class="h2"></div> <div class="comments"> <?php if ($comments): foreach ($comments as $comment):?> <div class="comment"> <div class="comment_username"><?php echo $comment['username'];?></div> <div lass="comment_comment"><?php echo $comment['message'];?></div> </div> <?php endforeach;?> <?php else:?> <div class="no_comments"> </div> <?php endif;?> </div> </body> </html>
الكود بسيط للغاية ولا يحتاج إلى شرح.
هناك متسلل - جون. أصبح جون بالملل وتعثر في موقع المطور لدينا.
يكتب جون الرسالة التالية في النموذج:
<script>document.body.style.backgroundColor = "#000";</script>
والآن جميع مستخدمي الموقع لديهم خلفية سوداء. جون راض ، والمطور اكتسب الخبرة والتوبيخ.
ماذا حدث؟
أضاف جون تعليقًا برمز JavaScript. عند إخراج البيانات إلى صفحة ، يتم تحويل تعليق نصي إلى رمز html. رمز html ، الذي يرى استخدام علامة البرنامج النصي ، أضفه إلى العلامات ، وقام المترجم بتنفيذ كود JavaScript بالفعل. وهذا يعني أن John أضاف فقط قطعة كود js الخاصة به إلى رمز الموقع الحالي.
كيف سنصلحها؟
لتصحيح سوء الفهم هذا ، تم إنشاء وظيفة htmlspecialcars. إن جوهر عملها هو أنها تستبدل شخصيات مثل علامات الاقتباس والأقواس بأحرف خاصة. على سبيل المثال ، سيتم استبدال الحرف "<" برمز الحرف المقابل له. باستخدام هذه الوظيفة ، نقوم بمعالجة البيانات من النموذج ، والآن لم يعد بإمكان رمز js js الخاص بنا الإضرار بموقعنا. بالطبع ، إذا كان هذا هو النموذج الوحيد على الموقع.
ستبدو التغييرات في الكود كما يلي:
ملف Index.php <?php if ($_POST) { $username = htmlspecialchars(trim($_POST['name'])); $comment = htmlspecialchars(trim($_POST['comment']));
حقن SQL
واحد من أكثر أنواع الهجمات شيوعًا ، والتي بدأت بالفعل في طي النسيان. ينسون ذلك لأن هناك استفسارات وأطر جاهزة.
سنتحدث عن الطلبات المعدة.
ما هو جوهر الهجوم: يقوم المهاجم بإدخال جزء من استعلام SQL في حقل الإدخال ويقدم النموذج. أثناء تنفيذ الاستعلام ، تتم إضافة البيانات المستلمة إلى قاعدة البيانات. لكن بما أن الكود يحتوي على الكود ، فإنه عند إضافة السجلات ، فإنه يعدل منطق البرنامج النصي الخاص بنا.
حسنا ، محاكاة الموقف. قام مطورنا بحماية النموذج من هجمات XSS. ويواصل جون استخدام معرفته ، مشيرًا إلى عيوب المطور المؤسف.
وهذا هو ، سوف نستمر في العمل مع نفس النموذج لإضافة التعليقات.
لنقم ببعض التغييرات:
1) قبل الاعتدال من التعليقات.
خلاصة القول هي أن تلك التعليقات التي وافق عليها المشرف فقط سيتم عرضها على الصفحة. ننفذ ما قبل الاعتدال في أبسط أشكاله حتى لا يتم صرفه عن الجزء الرئيسي من المقالة.
لتنفيذ الفكرة ، أضف الحقل "is_moderate" إلى الجدول مع التعليقات ، والتي ستأخذ قيمتين - "1" (عرض التعليق) أو "0" (لا تعرض). بشكل افتراضي ، بالطبع ، "0".
2) تغيير الطلب.
هذا هو للوضوح. دع الطلب لإضافة التعليقات يبدو كما يلي:
"INSERT INTO `comments` SET `username`='$username', `message`='$comment'"
الآن رمز النموذج هو كما يلي:
ملف Index.php <?php $opt = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC ]; $pdo = new PDO("mysql:host=localhost;dbname=".$db,$user,$pass,$opt); $pdo->exec("SET CHARSET utf8"); $query = $pdo->prepare("SELECT * FROM `comments` WHERE `is_moderate`='1'"); $query->execute(); $comments = $query->fetchAll(); if ($_POST) { $username = htmlspecialchars(trim($_POST['name'])); $comment = htmlspecialchars(trim($_POST['comment'])); $query = $pdo->prepare("INSERT INTO `comments` SET `username`='$username', `message`='$comment'"); $query->execute(); if ($query) { echo ' !'; } else { echo ' !'; } } ?>
حسنًا ، قام جون بتسجيل الدخول إلى الموقع ، ورؤية أن التعليقات بدأت في الإشراف عليها ، قرر أن يسخر من المطور. علاوة على ذلك ، فإن شكل هجمات XSS ينعكس الآن بنجاح ، وتم بالفعل حرمان جون من فرصة الاستمتاع. إنه يترك تعليقًا من هذا النوع: "LOL" ، is_moderate = '1 "ويتجاوز الاعتدال.
لماذا؟
عندما تحل محل تعليق John في طلب البحث ، تنقسم علامات الاقتباس. وهذا هو ، كما ذكر أعلاه ، كان جون قادرا على تنفيذ رمز SQL التعسفي.
عند تنفيذ طلب مع تعليق John ، يكون الطلب كما يلي:
"INSERT INTO `comments` SET `username`='John', `message`='LOL', `is_moderate`='1'"
علاوة على ذلك ، يمكن تنفيذ SQL Injection ليس فقط عند تقديم نموذج. يمكن أن يحدث هذا أيضًا عند تلقي السجلات بمعرفها ومعالجة نموذج البحث وغير ذلك من المواقف غير الواضحة.
كيفية اصلاحها؟
طريقة حل المشكلة معروفة منذ زمن طويل بالاستعلامات المعدة. الطلبات المعدة هي الطلبات التي تخضع للمعالجة الخاصة قبل تنفيذها. تتكون المعالجة من الهروب من علامات اقتباس إضافية. يجب أن تكون قد سمعت بهذه الميزة. في PHP ، يتم تطبيقه مثل هذا: "\" ".
الحل الأكثر شعبية هو شركة تنمية نفط عمان. PDO هي واجهة للعمل مع قاعدة بيانات. ما لديه واجهة مريحة إلى حد ما. فقط استخدامها بحكمة.
توفر PDO القدرة على استخدام الأقنعة والعناصر النائبة لتطبيق الاستعلامات المعدة.
عندها سيبدو طلبنا عند استخدام الأقنعة كما يلي:
ملف Index.php <?php $query = $pdo->prepare("INSERT INTO `comments` SET `username`=:username, `message`=:comment"); $params = ['username' => $username,'comment' => $comment]; $query->execute($params);
وعند استخدام العناصر النائبة مثل هذا:
ملف Index.php <?php $query = $pdo->prepare("INSERT INTO `comments` SET `username`=?, `message`=?"); $params = [$username,$comment]; $query->execute($params);
الآن لم يعد هجوم جون ذا صلة. على الأقل لهذا النموذج.
بالمناسبة ، لدينا الاعتدال ، حتى في هذا الشكل ، يحمي بالفعل ضد نوع آخر من الهجوم - الرسائل الاقتحامية. كلنا سمعنا عنه. الرسائل الاقتحامية (SPAM) هي إرسال أي رسائل ينفذ فيها المهاجمون هجماتهم بمساعدة المعرفة الاجتماعية. الآن الشخص الوحيد الذي سيتعرض للهجوم هو مدير الجلسة. وبعد ذلك ، إذا لم يكن غبيًا ، فسيقوم إما بحذف البيانات المهملة من قاعدة البيانات ، أو إذا كان كسولًا ، فسوف يرفض المنشور وهذا كل شيء.
هجوم CSRF
CSRF - تزوير طلب عبر المواقع. إنه أمر خطير لأن قلة من الناس يعرفون ذلك. على الرغم من أن القيام بذلك بسيط للغاية.
كيف يحدث ذلك: يقوم المهاجم من موقع آخر بتزوير نموذج ويجبر الضحية على اتباع هذا النموذج. وهذا هو ، يتم إرسال طلب POST. وبالتالي ، فإن طلب HTTP مزيف ويتم تنفيذ إجراء ضار على موقع الضحية.
على سبيل المثال ، يمكن للمهاجم إرسال رسالة إلى صديقك في VK نيابة عنك ، ولكنك لن تعرف ذلك.
يبدو مربكا بعض الشيء. أقترح أن تنظر في الممارسة العملية.
جعل المطور لدينا النموذج ، وقال انه جيد. إنها تعرف بالفعل كيف تدافع عن نفسها ضد حقن XSS و SQL وتحافظ على ضغط البريد العشوائي. يبدو مثل هذا:
ملف index.php على موقع المطور <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>CSRF</title> </head> <body> <form action="action.php" method="POST"> <input type="text" name="username"> <textarea name="message"></textarea> <input type="submit" value=" "> </form> </body> </html>
لكن جون ليس بهذه البساطة. يتلقى رمز النموذج (ببساطة من الكود المصدر للموقع في المتصفح) ويضيف النموذج إلى موقعه.
ملف index.php John <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>CSRF</title> <style> form input[type=submit]{ padding: 15px; font-size: 20px; color:
يرجى ملاحظة أنه على موقع John ، فإن المكان الذي تتم فيه معالجة النموذج هو ملف من موقع المطور الخاص بنا. حتى الآن أي مستخدم ينقر على الزر سوف يرسل تعليقات غير جيدة.
هذا هجوم CSRF. في أبسط نسخة ، بالطبع.
المطور لديه مشاكل مرة أخرى ...
كيفية إصلاح الثغرة الأمنية؟
عند نقطة واحدة ، سوف يقوم المطور بتطوير google ما هو csrf وسيكون منطق الحماية كما يلي: للحماية ، تحتاج إلى إنشاء رمز csrf (مجموعة من الحروف والأرقام) وتعليقه في النموذج. من الضروري أيضًا إصلاح نفس الرمز المميز للمستخدم (على سبيل المثال ، من خلال جلسة). ثم ، عند معالجة النموذج ، قارن هذه الرموز. إذا كانت متطابقة ، فيمكننا إضافة تعليق.
نحن ننفذ هذا:
ملف index.php على موقع المطور <?php session_start(); $token = ''; if (function_exists('mcrypt_create_iv')) { $token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM)); } else { $token = bin2hex(openssl_random_pseudo_bytes(32)); } $_SESSION['token'] = $token; ?> ... <form action="action.php" method="POST"> <input type="text" name="username"> <textarea name="message"></textarea> <input type="hidden" name="csrf_token" value="<?php echo $token;?>"> <input type="submit" value=" "> </form>
ملف action.php <?php session_start(); if ($_POST) { if ($_SESSION['token'] == $_POST['csrf_token']) { echo ' !'; } else { echo '!'; } }
القوة الغاشمة وكلمات Publick
ولعل أشهر نوع من الهجوم. سمعها تقريبًا كل فيلم أول عن المتسللين وما شابه.
ما هي النقطة: هناك نموذج للترخيص في لوحة إدارة الموقع. نحتاج إلى اسم مستخدم وكلمة مرور لا يعرفهما جون. لكن لديه ملف به أسماء مستخدمين وكلمات مرور مشهورة. وهو يركض بسعادة لمحاولة تجريبهم على موقعنا.
ماذا يمكن أن يعارض المطور؟ على سبيل المثال ، فرض قيود على عدد محاولات التفويض في فترة زمنية معينة.
دع الإصدار الأولي من نموذج التفويض يبدو كما يلي:
ملف Index.php <?php $opt = [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC]; $pdo = new PDO("mysql:host=localhost;dbname=".$db,$user,$pass,$opt); $pdo->exec("SET CHARSET utf8"); if (isset($_POST['autoriz'])) { $username = htmlspecialchars(trim($_POST['login'])); $password = htmlspecialchars(trim($_POST['password'])); $query = $pdo->prepare("SELECT * FROM `users` WHERE `username`=:username AND `password`=:password"); $query->execute(['username' => $username,'password' => $password]); $find_user = $query->fetchAll(); if ($find_user) { echo ' !'; } else { echo ' !'; } } ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Brute Force Public Passwords</title> </head> <body> <form method="POST"> <input type="text" name="login" placeholder="Login"> <input type="password" name="password" placeholder="Password"> <input type="submit" value="" name="autorize"> </form> </body> </html>
كيفية إصلاحه: الخيار الأبسط ، كما ذكر سابقًا ، هو الحد من عدد محاولات التفويض لكل فترة زمنية.
للقيام بذلك ، عندما نحاول تسجيل الدخول ، سنضيف القيمة الحالية للوقت للمستخدم في ملفات تعريف الارتباط. والآن ، عند محاولة تسجيل الدخول ، سنرى أنه لا يمكن للمستخدم تسجيل الدخول أكثر من مرة واحدة في 5 ثوانٍ. علاوة على ذلك ، إذا لم يتم إدخال كلمة المرور أو تسجيل الدخول بشكل صحيح ، فسوف نزيد المهلة حتى المحاولة التالية لمدة 5 ثوان.
ملف Index.php <?php $count_next_minit = $_COOKIE['count_try'] ? $_COOKIE['count_try'] : 1; $seconds_to_new_try = 5; $opt = [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC]; $pdo = new PDO("mysql:host=localhost;dbname=".$db,$user,$pass,$opt); $pdo->exec("SET CHARSET utf8"); if (isset($_POST['autorize'])) { if ($_COOKIE['last_try']) { if ($_COOKIE['last_try'] < time() - $seconds_to_new_try * $count_next_minit) { $username = htmlspecialchars(trim($_POST['login'])); $password = htmlspecialchars(trim($_POST['password'])); $query = $pdo->prepare("SELECT * FROM `users` WHERE `username`=:username AND `password`=:password"); $query->execute(['username'=>$username,'password'=>$password]); $find_user = $query->fetchAll(); setcookie('last_try', time(), time() + 3600); if ($_COOKIE['count_try']) { $old_value = (int)$_COOKIE['count_try']; setcookie('count_try', $old_value + 1, time() + 3600); } else { setcookie('count_try', 1, time() + 3600); } if ($find_user) { var_dump(' !'); } else { var_dump(' !'); } }else{ var_dump(' ! ' . $seconds_to_new_try * $count_next_minit . ' '); } }else{ setcookie('last_try', time(), time() + 3600); } } ?>
المتتبع الخلفي
Backtrace هو وسيلة للهجوم من خلال رسائل خطأ النظام. هذا هو كل من MySQL و PHP.
على سبيل المثال ، أدخل جون عنوان url غير صحيح وتم إعطاؤه خطأً يقول إنه لا يوجد سجل في قاعدة البيانات بمثل هذا المعرف (إذا تم استلام السجل من خلال المعرف من شريط العنوان - site.ru/article؟id=12). هناك حتى ما يسمى "dorks" - أنماط محددة من عناوين مواقع الويب ، عند إدخال المستخدم الذي يرى أخطاء. وهذا يفتح إمكانية لجون لاستخدام الروبوت للبحث في قائمة العناوين هذه ومحاولة إيجاد هذه الثغرة الأمنية على موقعك.
كيفية اصلاحها؟ في هذه الحالة ، سنفعل بدون أمثلة ، لأنه يتم حل المشكلة ببساطة عن طريق إغلاق إخراج الخطأ. عادةً ما يتم تنفيذ ذلك من خلال الاستضافة ، مما يوفر لك في لوحة الإدارة لكتابة السجلات إلى ملف منفصل ، ولكن لن يكون من الضروري تقييد إخراج الأخطاء بنفسك.
يمكن القيام بذلك باستخدام error_reporting () الدالة.
من بين الوسيطات التي يتطلبها الأمر: E_ERROR و E_WARNING و E_PARSE و E_NOTICE و E_ALL. الأسماء تتحدث عن نفسها.
على سبيل المثال ، إذا كنت تستخدم error_reporting (E_NOTICE) ، فسيتم إخفاء جميع الأخطاء ، باستثناء أخطاء من نوع الإشعار (التحذيرات ، على سبيل المثال ، أنه لا توجد بيانات في صفيف $ _POST).
لتعطيل إخراج جميع الأخطاء (التي نحتاجها بالفعل) ، تحتاج إلى استخدام هذه الوظيفة على النحو التالي: error_reporting (0)
الأخطاء المنطقية
الأخطاء المنطقية هي بعض من الأسوأ. لأن هذه أخطاء بسبب الإهمال. يطفو على السطح بشكل غير متوقع ، وأحيانًا لا نعرف حتى موقع جذر المشكلة. هذه أخطاء في منطق الموقع.
حسنًا ، على سبيل المثال ، قد تنسى التحقق من وجود بيانات التفويض في الجلسة وملفات تعريف الارتباط لإحدى صفحات لوحة المسؤول. لذلك فتحوا الوصول إلى هذه الصفحة لأي مستخدم.
في هذه الحالة ، سيوفر لك شيء واحد فقط - عند كتابة رمز البرنامج ، فكر في كيفية اختراقه.
DDOS
DOS هو نوع من الهجوم على تقنية ، ولا سيما جهاز كمبيوتر. يهدف الهجوم إلى تعطيل الجهاز بسبب التحميل الزائد. يختلف DDOS فقط في أن عددًا أكبر من أجهزة الكمبيوتر متورط في الهجوم.
أي أن جون يتصل بأصدقائه ويبدأون معًا في إرسال طلبات إلى الموقع. ما علاقة الروبوتات به؟ الروبوتات هي الكثير من أجهزة الكمبيوتر المصابة ، والخصوصية هي أنه يمكن للمهاجم التحكم في عملهم إلى حد ما (بدء العمليات ، وما إلى ذلك). يرسلون العديد من الطلبات التي يتعذر على الخادم تحملها ، وفي أحسن الأحوال ، يبدأ العمل ببطء شديد ، أو يرفض لفترة زمنية غير محددة.
يتم توفير الحماية من هذه الهجمات إما من قبل المضيفين أنفسهم ، أو من خلال خدمات خاصة مثل Cloudflare.
كيف تعمل الحماية: توفر لك خدمة Cloudflare خوادم DNS الخاصة بها والتي تمر عبرها حركة المرور. هناك يتم تصفيته ، ويمر عبر خوارزميات معروفة فقط لمالكي ومطوري الخدمة. وبعد ذلك يحصل المستخدم على موقعك. نعم ، بالطبع ، هناك تشغيل للخادم ، وإنشاء صفحات ، وكل شيء آخر ، لكننا لا نتحدث عن ذلك الآن.
بالإضافة إلى ذلك ، عند الحديث عن DDOS ، لا يمكن للمرء أن يفشل في ذكر حظر عنوان IP الذي يوفره Cloudflare أيضًا.
نعم ، لن يوفر كل هذا ضمانًا بنسبة 100٪ للحماية ، لكن في بعض الأحيان سيزيد من فرص بقاء موقعك واقفًا في وقت الهجوم.
MITM
رجل في الوسط هو نوع من الهجوم عندما يعترض المهاجم الحزم الخاصة بك ويزيفها. سمعنا جميعًا أن البيانات تنتقل عبر الشبكة في حزم. لذلك ، عند استخدام بروتوكول http ، يتم نقل البيانات بالشكل المعتاد وليس المشفر.
على سبيل المثال ، تكتب "مرحبا" إلى صديق ، ويتلقى "أرسل لي المال ، ها هي المحفظة".
تم حل بروتوكول https لحل هذه المشكلة. عند استخدامه ، سيتم تشفير البيانات ولن يتمكن John من فعل أي شيء مع حركة المرور المستلمة.
وللحصول على بروتوكول https للموقع ، تحتاج إلى الحصول على شهادة SSL. حسنا ، أو TLS. بشكل عام ، TLS هو في الأساس مستقبل SSL ، لأنه يستند إلى SSL 3.0. لا توجد اختلافات كبيرة في عملهم.
توفر شهادة SSL نفس Cloudflare ، مجانًا.
مستتر
وهناك نظرية أكثر قليلا. لهذا النوع من الهجوم يمكن تنفيذه بعدة طرق وتحتاج فقط إلى فهم الجوهر. Backdoor هو نوع من الهجمات السرية التي يقوم فيها البرنامج النصي نفسه بعمل شيء ما في الخلفية. في معظم الأحيان ، هذه هي الإضافات أو مظاهر WordPress التي تم تنزيلها من سيل. سيعمل البرنامج المساعد / السمة نفسها بشكل كافٍ ، لكن جزءًا معينًا من البرنامج النصي يضاف إلى رمز البرنامج المساعد / السمة سيفعل شيئًا بشكل سري. نفس الرسائل الاقتحامية ، على سبيل المثال. هذا هو السبب وراء كل التحذيرات حول عدم الرغبة في تنزيل الملفات من سيل.
في الختام
نعم ، بالطبع ، ليست هذه هي المجموعة الكاملة من الهجمات. لكن هذه المعرفة ستزيد بالفعل من أمان مشاريعك.