أمن الانترنت موضوع مثير ويجب أن يكون على رأس أولويات أي أحد لديه أي تواجد على الانترنت تحت سيطرته أمن الانترنت الغير فعال يؤدي إلى جميع الأمور التي تجعلنا نكره الانترنت : السخام، الفيروسات، سرقة الهوية، على سبيل المثال لا الحصر.

المشكلة مع أمن الانترنت هي، بقدر أهميتها، فإنها أيضا معقدة جدا. أنا متأكد أن بعض من يقرأون هذا المقال هم بالفعل جزء من شبكة حواسيب مهاجِمة (بكسر الجيم) و أن خوادمكم ترسل رسائل السخام دون علمكم أصلا. إيميلاتكم وكلمات سركم تم حصدها وبيعها لأناس يظنون أنكم تحتاجون إما ساعة جديدة، منتج للتقوية الذكورية أو رهن عقاري رخيص! الحقيقة هي، أنكم جزء من المشكلة و أنكم لا تعرفون ماذا فعلتم كي تتسببوا بها.

السبب هو أن خبراء الأمن لا يحبون كثيرا التحدث على العلن عما يفعلونه وعن أين تقع المشكلة، وبكل حزن، يمكن أن يكونوا متكبرين في آرائهم تلك. هذا قد يكون نتيجة لأناس لا يأخذون الأمن بالجدية الكافية ولا يتبعون النصيحة الأساسية للغاية، كاستخدام كلمات سر ذكية، “كلمات سر” و ليس “ليمون!!”

سبب آخر قد يكون تلك الدروس التي تخبرك كيف “تفعل كذا في خمس دقائق” وتتجاهل ببساطة ذكر التوابع الامنية لنصيحتهم. إن كان يظهر أن أمرا ما أسهل بكثير من أن يكون حقيقيا، فعلى الأرجح أنه كذلك. مثال نموذجي على ذلك هو حلول PHP التي تستخدم ملفا لتخزين البيانات وتطلب منك أن تجعله قابل للقراءة من قبل العالم بأسره. إن هذا من السهل تنفيذه، لكن ذلك سيجعل أي سبامر يكتب في هذا الملف.

إخلاء طرف: الامور التي سنتحدث عنها اليوم في هذا المقال لن تجعل منك خبيرا أمنيا، تماما كما أن شراء سكين سويسري لن يجعل منك صانع أقفال أو شراء سوط لن يجعل منك مروض أسود. الغرض هنا هو رفع الوعي وربما جعل بعض طلاسم الأمنيات قابلة للفهم بالنسبة لك.

تقرير مثير حول أمن الانترنت

شركة أمن الانترنت Cenzic أصدرت تقريرا يفصل التوجهات والأرقام ذات العلاقة بأمن الانترنت للربعين الاول والثاني من العام 2009. هناك نسخة PDF متاحة لهذا التقرير, و الأرقام معبرة جدا:

من بين أكثر الثغرات – إن صح التعبير- جدية هي Path Traversal ، cross-site scripting, cross-site request forgery and SQL injection (الطريق الملتوي، السكربتات عبر الموقع، تزييف الطلبات عبر الموقع، وحقن الـ SQL ) ما لم يذكر هو تهديد جديد، clickjacking، وأمر متعلق بواجهة المستخدم تسمى phishing قد يتوجب عليك التعامل مع كل هؤلاء كمطور ويب إن كنت تتعامل مع PHP, HTML,CSS,Javascript حتى لو لم تكن تستخدم PHP ، قد تكون أنت مسببا للكثير من المشاكل. حتى لو تكن تلمس الكود وفقط تصمم قد تكون أداة فعالة في هذا المجال. يمكنك أن تجعل الانترنت أكثر أمنا بجعل المسائل الامنية قابلة للفهم لمستخدميك.

دعنا نمر بكل هذه الأمور ونشرح ما هي وما تفعله . أول ما عليك معرفته، مع ذلك، هو كيف تعمل الـURIs.

الـ URIs الطريقة الرئيسية للهجوم على خدمة انترنت

عنوان أي مستند (أي، ملف على الانترنت) هو معرف الموارد الموحد (URI). هذا هو ما تدخله في خانة العنواين في المتصفح للوصول إلى مستند ما، وهو ما تحقنه في كودك لتشير إلى المستند. على سبيل المثال، عنوان موقعي هو http://icant.co.uk ، والمستند الذي تراه عندما تفتح الموقع في المتصفح هو http://icant.co.uk/index.php (الخادم يحولك تلقائيا إلى ذلك المستند) صورة الشعار تقع تحت الـ URI التالي : http://icant.co.uk/iconslogo.png، وصورتي وأنا أشير إليك لها الـ URI التالي : http://farm4.static.flickr.com/3172/3041842192_5b51468648.jpg

جميع هذه الـ URIs هي مفتاح لك للدخول. بعض الـ URIs ، مع ذلك، تحتوي معلومات لا يجب أن تكون متاحة للعالم الخارجي. على سبيل المثال، المجلد /etc/password على خادم ما يحوي كلمات سر ومعلومات المستخدمين ويجب ألا يتم تسريبه للانترنت.

كل واحد من هذه الـ URIs يمكنه أيضا أن يحوي بعض المتغيرات ( البارامترات parameters ) إنها تعليمات يمكنك إرسالها إلى السكربت الموجود في ذلك الـ URI ويتم إلحاقها بالـ URI بدءا بـ ؟ ومفصولة بأدوات عطف. إن أردت البحث عن الجراء في جوجل، على سبيل المثال، يمكنك استخادم الـ URI التالي http://www.google.com/search?q=puppies : وإن أردت أن تبدأ بحثك بعد الـ 50 نتيجة الاولى، يمكنك استخدام: http://www.google.com/search?q=puppies&start=50

عادة، هذه المتغيرات لا يتم إدخالها من قبل المستخدم النهائي ولكن تأتي من واجهات HTML إن نظرت إلى الكود المصدري لصفحة البداية لموقع جوجل، وبالتخلص من الأمور غير الهامة، ستصل بالنهاية إلى النموذج التالي:

<form action="/search">
<input name="hl" type="hidden" value="en" />
<input name="source" type="hidden" value="hp" />
<input name="q" />
<input name="btnG" type="submit" />
<input name="btnI" type="submit" />
<input name="aq" type="hidden" />
<input name="oq" type="hidden" />
<input name="aqi" type="hidden" />
</form>

لذا بشكل أساسي، هذا النموذج يرسل محتويات جميع تلك الحقول (fields) إلى الـ URI المسمى search و يلحقهم بهذا الـ URI. وبهذا الطريقة ينتهي بك الأمر بهذا :

http://www.google.com/search?hl=en&source=hp&q=puppies&aq=f&oq=&aqi=

حين ترسل النموذج. لاحظ، مثلا، أنه لا يوجد لدي المتغير btnG لأنني استخدمت زر Enter لارسال النموذج.

في صفحة نتائج البحث، يمكنك رؤية وصلات الترقيم في الأسفل ( الـ 1،2،3 إلخ تحت شعار Goooooooooogle) ، ويمكنك ترسل نفس البيانات للـ URI وتضيف متغير من نوع start

<a href="/search?hl=en&amp;q=puppies&amp;&lt;b&gt;start=40&lt;/b&gt;&amp;sa=N">5</a>

يمكنك ارسال متغيرات لسكربت من خلال الـ URI عن طريق حقول النموذج (form fields)، الوصلات (links) أو أي شيء آخر في HTML يحتوي على URI : صور، وصلات، إطارات، أي شيء يمكنه أخذ نوع (أي attribute ) مثل href أو src . إن استطاع المهاجم (attacker) أن يتغلب على أي من تلك، أو أن يضيف صورة جديدة لكود الـ HTML الخاص بك دون أن تعلم، فهو أيضا قادر على أن يشير(يوجه أو point to) إلى عنوان URI الخاص به وأن يرسل متغيراته.

عليك أن تكون حذرا بشان ما تحتويه متغيراتك وإلى أين تشير، وهو ما قد يكون خادم أحدهم ( كي يحصل على المزيد من الكود) أو أجزاء من خادمك أنت لكنك لا تريد إظهارها أو ارسالها الى خادم آخر.

أنواع الهجوم المختلفة. ماذا تعنيه هذه الكلمات؟

دعنا نمر سريعا على الأنواع المختلفة المذكورة في الرسم أعلاه، ونشرح ما هي وما تعنيه.

حقن أكواد SQL

بـ حقن أكواد SQL, يمكن للمهاجم الوصول الى قاعدة بياناتك عن طريق ارسال أوامر SQL غلى خادمك من خلال الـ URI أو حقول النموذج. يمكن التغلب على ذلك بسهولة من خلال ما يسمى بالتعقيم sanitizing, لكن تجاهل عمل ذلك قد يكون مميتا لموقعك كما يظهر في التالي : XKCD comic

XKCD comic يظهر كيف يمكن لحقن أكواد SQL أن تحذف قاعدة بياناتك.

Cross-Site Scripting (XSS)

هذه الطريقة هي ربما اكبر وأكثر المشاكل شيوعا. من خلالها، يمكن للمهاجم حقن كود Javascript في مستندك من خلال إضافته إلى نهاية الـ URI كمتغير أو من خلال حقل في فورم.

هب أنك تريد أن تظهر بالمظهر اللطيف و أن تسمح لزوارك بتغيير بعض الألوان في صفحتك. يمكنك عمل ذلك بسهولة باستخدام PHP

<!--   #intro{     /* color is set by PHP */     color:;     /* background is set by PHP */     background:;     font-family:helvetica,arial,sans-serif;     font-size:200%;     padding:10px;   } -->

Cool intro block, customizable, too!

حتى الآن، كل شيء مباح، ونحن لا نستخدم أي ستايل داخلي (inline style) إن قمت بحفظ هذا كـ test.php واستدعيته من خادمك عن طريق المتصفح، بالـ URI التالي : http://example.com/test.php ، سوف تحصل على مربع نص بحيث لونه أسود على أبيض. إن متغيرات الـ $_GET[]تأتي من الـ URI كمتغير (بارامتر)، ولأنها ليست مفعلة (not set)لا شيء يتغير. إن أردت الألوان أن تكون أحمر على وردي، يمكك عمل ذلك كالتالي: http://example.com/test.php?color=red&background=pink.

لكن لأنك تسمح بأي قيمة لتلك المتغيرات، المهاجم يمكنه إرسال التالي:

http://example.com/test.php?color=green&amp;background=<script type="text/javascript"><!--mce:0--></script>

هذا سوف يقوم فعليا بإغلاق بلوك الستايل قبل الأوان ويضيف سكربت للمستند. في هذه الحالة، كل ما سنفعله هو أن نكتب الكلمة XSS، لكن يمكننا عمل أي شيء يمكن للـ JavaScript عمله. يمكنك رؤية النتيجة في الصورة التالية :

حالما تكون قد حقنت JavaScript بنجاح، ستتمكن من قراءة الـ cookies ، تفتح الفورمز وتطلب من المستخدمين أن يكتبوا كلمات سرهم أو أرقام بطاقات ائتمانهم، أن تقوم بتنفيذ الفيروسات، الديدان و أي شيء تريده. السبب هو أن JavaScript ليست محددة بأي إطار أمني، أي سكربت في الصفحة له نفس الحقوق، بغض النظر عن الخادم الذي أتى منه. وهذه مشكلة كبيرة مع الـ JavaScript وهو امر يعمل عليه الناس الأذكياء حاليا.

XSS هي مشكلة شائعة كثيرا. المواقع من قبيل XSSED.org تظهر للعالم يوميا كم عدد المواقع المعرضة لذلك النوع من الخطر.

العلاج لـ XSS هو أن تصاب بجنون الشك بشأن أي شيء يأتي من خلال الفورمز أو الـ URI عليك أيضا أن تكون واثقا من أن الـ PHP الخاص بك تم تثبيته بشكل صحيح) سوف نتعرض لبعض الطرق لاختبار ذلك وكيفية كتابة كود جيد لاحقا).

Path Traversal

السماح باجتياز المسار (path) أو الدليل (directory) هي فكرة غبية للغاية. سوف تسمح عندها للزوار بأن يعرض مجلداتك على هيئة قوائم (list the folders) في خادمك وأن يتنقل من واحد إلى آخر. هذا يسمح للمهاجم بالوصول إلى مجلدات بها معلومات حساسة أو بعض أجزاء الموقع الفعالة ، أو مجرد التسلية. الصورة التالية هي لي وأنا أصل إلى قاعدة بيانات شركة شطيرة (sandwich) و أبعث ايميلات من خادمهم و أنظر إلى سجل الطلبات:

لقد استطعت الوصول إلى كل هذه المعلومات بمجرد وصولي إلى مجلد cgi-bin ، والذي كان غير محمي من عملية العرض على هيئة قوائم (listing the folders). لذا، بدلا من الذهاب لـ http://example.com, ذهبت لـ http://example.com/cgi-bin/ في متصفحي. عرفت أن هناك مشكلة ما في موقعهم الفلاشي الكبير عندما ضغطت على القائمة. لقد ظهرت في نافذة جديدة وكان لها URI مثل

http://www.example.com/cgi/food_db/db.cgi?db=default&uid=default&Category=Sandwiches&Subcategory=Sandwiches&Product=Chicken%20and%20Bacon&Soup_size=&Drinks_milk_type=&ww=on&view_records=yes

مما أعطاني كل المعلومات التي أحتاجها لبدء اللعب.

المشكلة الأخرى في جعل المجلدات قابلة لان تعرض كقوائم هي أن محركات البحث سوف تسرد (index) جميع معلوماتك مما يسمح لأي شخص أن يستخدم جوجل كأداة اختراق. بما أن الخوادم تقوم بإنشاء صفحات بعنوان (title) وعنوان رئيسي (headline) لاسم المجلد، هذه جميعها يتم سردها من قبل جوجل.

يمكنك أن تبحث عن، مثلا “index of /ebooks” كي تجد الكتب الالكترونية على الشبكة، أو “index of /photos” لتجد الصور. لترى تجارب البحث على جوجل مثل السابقة، ألق نظرة على مقالGoogle a Dream Come True الذي عرض الكثير منهم وذلك في العام 2003 !!

هذه الطريقة في البحث كانت أكثر فعالية في الماضي، بالمناسبة: لكن ليس لأن الناس يحمون خوادمهم بشكل أفضل الآن، لكن لأن السبامبرز الذين أرادو عرض منتجاتهم المخادعة، أدركوا أن الناس أصلا يقومون بعمليات بحث عن منتجات مشابهة، فقاموا بعمل تحسين (optimize) بما يتناسب مع محركات البحث.

Cross-Site Request Forgery

Cross-site request forgery إن هذه الطريقة تستغل المتصفحات و المواقع التي تسمح للإجراءات (functionality) بان يتم استدعائها دون أن تعلم هل الذي بدئها مستخدم حقيقي أم لا.(Forgery تعني تزييف). لنفرض أن لديك فورم في موقعك http://example.com والذي يعمل بـ GET ويرسل بعض الأمور لقاعدة بياناتك:

<form action="add_to_db.php" method="get">
 
<div>
    <label for="name">Name</label>
<input id="name" name="name" type="text" /></div>
 
 
<div>
    <label for="email">email</label>
<input id="email" name="email" type="text" /></div>
 
 
<div>
    <label for="comment">Comment</label>
    <textarea id="comment" name="comment"></textarea></div>
 
 
<div>
<input type="submit" value="tell me more" /></div>
 
</form>

النماذج يمكن إرسالها بطريقتين : الـ GET ترسل جميع المتغيرات الى الـ URI الظاهر في شريط العناوين (address bar) بينما POST ترسلهم بشكل مخفي POST(under the hood) أيضا تسمح لك بإرسال كمية أكبر من البيانات. هذا تبسيط للموضوع لكنه كاف في هذه المرحلة.

إن كان السكربت الذي يقوم بالإضافة إلى قاعدة البيانات، لا يتحقق أن النموذج قادم بالفعل من خادمك أنت، عندها سأستطيع أن أضيف صورة إلى أي موقع بعمل التالي:

<img src="http://example.com/add_to_db.php? name=cheap%20rolex&amp;email=susan@hotchicks.com&amp;comment=mortgage%20help" alt="" width="1" height="1" />

أي زائر لموقعي سيتمكن الىن من إضافة تعليق ما إلى قاعدة بياناتك. يمكنني استخدام صورة أو وصلة CSS أو سكربت أو أي شيء يمكنه أن يجعل الـ URI معرفا ومحمّلا من قبل المتصفح عندما يتم معالجة (rendering) كود الـ HTML في حالة الـ CSS ، قد تكون هذه صورة خلفية.

CSRF تصبح أكثر خطرا عندما تكون مسجلا للدخول و موثق (authenticated) من قبل نظام ما. صورة ما في أي لسان تبويب في متصفحك يمكنها أن تنفذ (execute) عملية تحويل للأموال، أن تقرأ ايميلاتك وترسلها وأمور أخرى كثيرة.

حالة مثيرة للاهتمام كمثال على CSRF ( ولو أنها بريئة بعض الشيء) حدثت عام 2006، عندما قامت جوجل بطرح أداة Web accelerator tool (GWA).والتي قد انقطعت الآن. الفكرة كانت في التحميل/البحث المسبق (pre-fetch) للوصلات الموجودة في مستند ما (صفحة انترنت ما)، وبذلك يتم توفير الوقت وجعل التصفح أسرع. كان يئا جيدا ورائعا…إلى أن انتهى بك المطاف بوصلات محذوفة كالتالي:

<a href="/app/delete_entry.php?id=12">delete</a>

ولأن بعض التطبيقات لم تكن تتأكد من أن هذا الحذف قد تم بدؤه فعلا أم أنه مجرد محاولة من GWA لإعادة تحميل الصفحة، قامت الاداة بحذف مدونات بأكملها وقواعد بيانات أيضا. جوجل لم ترتكب أي خطأ، لكن المجتمع تعلم الكثير عن CSRP في ذلك اليوم.

الآن، قد تفترض أن نقل الفورمز خاصتك من GET إلى POST سيجعلها أكثر امنا، أليس كذلك ؟ جزئيا، نعم، لكن المهاجم مازال بإمكانه استخدام النموذج وخداع الناس كي ينقروا على زر لعمل هذا الطلب :

<form action="add_to_db.php" method="post">
 
<div>
<input name="name" type="hidden" value="bob" />
<input name="email" type="hidden" value="bob@experts.com" />
<input name="comment" type="hidden" value="awesome article, buy cialis now!" />
<input type="submit" value="see beautiful kittens now!" /></div>
 
</form>

يمكنك حتى أن تستخدم JavaScript لإرسال النموذج اوتوماتيكيا أو أي سكربت آخر موجود على خادم آخر لعمل طلب POST من المكان البعيد (back-end). هناك عدة طرق لاستغلال CSRF و الحماية منها ليست أمرا صعبا.

Remote File Inclusion (RFI) إدخال الملفات عن بعد

بعملية Remote file inclusion أو code injection, يمكن للمهاجم أن يستخدم فيضا flow في موقعك لحقن كود من خادم آخر بحيث يعمل الكود على خادمك. إنها من نفس عائلة الـ XSS لكنها أكثر تسببا للمشاكل، لأن لديك إذن دخول كامل (full access)لخادمك (باستخدام JavaScript ، يمكنك سرقة الكعكات cookies وكل الاكواد الأخرى، لكن لا يمكنك الوصول إلى نظام الملفات دون أن تلجأ إلى حيل بالفلاش أو Java Applets)

أي كود يحقن في خادمك بمتغير غير مجرب، و بأمر include() ، على سبيل المثال، يمكنه أن يقوم بتشغيل أوامر الخادم، أن يتفقد كلمات السر في خادمك، أو أي شيء يمكنك عمله عن طريق سطر الاوامر comman line باستخدام PHP أو ASP إن كان خادمك يسمح بذلك.

هذا على الأرجح أسوا ما يمكن أن يحصل لخادمك، لأنه بالوصول إلى خط الأوامر، يمكنني أن أحوله إلى ماكينة مهاجمة ضمن شبكة خوادم مهاجمة، و أن استمع بصمت إلى كل ما تقوم بفعله أنت ومستخدميك وكل ما ترسلونه عبر مصادر الانترنت الأخرى، و أن اخزن المعلومات والفيروسات، و أن أقوم بحقن وصلات السخام spam ، على سبيل المثال لا الحصر.

الفكرة هي في تعطيل gloabls وعدم تجميع الـ URI من متغيرات أو من بيانات فورم ما (المزيد حول ذلك لاحقا في قسم الـ PHP من هذا الدرس).

Phishing

Phishing هي طريقة لخداع الناس كي يدخلوا معلومات في مواقع سيئة. عليك أن تظهر للناس واجهة تبدوا موثوقة ( لبنك مثلا ) ولكن هذا في الواقع يرسل معلوماتهم إلى قاعدة بياناتك. لأن الـ phishing جريمة، لا يمكنني أن أريك تجربة.

الحيلة هنا هي ان تجعل النموذج يبدو فعلا كأنه أتى من موقع موثوق به. لقد وصلتك ايميلات على الرجح تقول لك أن حسابك البنكي في بنك كذا تم سرقته/التلاعب به، و أنت تعرف ان هذا هراء لأنك لا تملك أصلا حسابا في ذلك البنك ( المفترض). إن هذه هي محاولة phishing بمدى تخمين واسع، وهي عادة غير فعالة.

على الانترنت، مع ذلك، المهاجم يمكنه أن يقوم بحيلة JavaScript أين كنت. كما أظهر Jeremiah Grossman , قبل عدة سنوات، يمكنك استخدام JavaScript لتحديد حالة وصلة ما في الصفحة. لأن ألوان الوصلات التي تمت زيارتها تختلف عن تلك التي لم تتم زيارتها، يمكننا أن نعرف أي موقع قد زاره المستخدم وعندها يمكننا عرض الشعار المناسب فوق النموذج . هذا العرض البسيط يظهر ذلك بفعالية. ومما يثير الضحك، يمكنك استخدام ذلك لأغراض حسنة أيضا، عن طريق أن تظهر للناس فقط الأزرار التي تخص مواقع الإعلام الاجتماعي التي يستخدمونها.

Clickjacking

Clickjacking هي طريقة شديدة الذكاء لاستخدام CSS والفورمز الداخلية inline frames لخداع المستخدمين لجعلهم ينقرون على أمر ما دون أن يعلموا أصلا. على الأرجح فإن أشهر مثال على ذلك كان استغلال “لا تنقر هنا” في موقع تويتر قبل عدة أشهر. فجأة، تويتر كان مليئا بالرسائل التي تشير إلى موقع به زر مكتوب فيه “Don’t click me” هنا مثال على تيار جاسون كوتك Jason Kottke’s stream

البشر غريبون فعلا، فكثير من الناس ضغطوا ذلك الزر، الذي عمليا لم يكن يفعل شيء. ما كان يفعله، فعليا، هو وضع صفحة تويتر الخاصة بك أعلى الزر كإطار، بدرجة إعتام مقدارها 0 في الـ CSS الحقل المحدث كان موجودا مع الـ tweet التي تشير إلى الصفحة الصور التالية تجعل الامر أكثر وضوحا، ودرجة الإعتام هنا تساوي 0.5

بواسطة الـ clickjacking، يمكك أن تجبر المستخدمين على فعل أشياء دون علمهم. كل فعل على الموقع يمكن عمله بنقرة بسيطة، يمكن استغلاله بتلك الحيلة.
إن clickjacking هي مشكلة كبيرة لأنها تتم من خلال CSS ، وليس من خلال سكربت ما. مالم تقم المتصفحات بحظر أن تكون الإطارات لها درجة إعتام 0 فلا توجد طريقة بسيطة للالتفاف على تلك الحيلة. الطريقة الرئيسة التي يقاوم بها الناس تلك الحيلة هي بمنع الإدماج في الإطارات باستخدام الجافا سكربت (disallow embedding in frames using JavaScript) لكن، حتى مع إطفاء الـ JavaScript، الـ clickjacking ما تزال تعمل.