الثلاثاء، 6 يوليو 2010

طرق لمنع القرصنة وسرقة بيانات

ان كثيرا من المواقع تتعرض للقرصنة بشكل متواصل, طبعا هنالك العديد من الطرق للتحايل على الانظمة والوصول الى بيانات قد تعرض المستخدمين لسوء الاستعمال لبياناتهم.
اضافة لجهاز حائط النار (firewall), هناك الكثير مما يجب العمل به حتى تقلل من خطر تعرض نظامك الانترنتي للخطر, واذكر منه :

1- استعمال وحدة captcha, والهدف منها ان تمنع محاولات قرصنة روبوتية :
هذه الوحدة عبارة عن صورة مشوهه لرقم او لكلمة عشوائية يتم انتاجها اثناء دخول المستخدم لمنطقة تسجيل الدخول للموقع, يتم تخزين هذه
الكلمة او الرقم في الsession قبل عرض شاشة ادخال اسم المستخدم وكلمة السر,عند عرض شاشة الدخول يطلب من المستخدم ان يتعرف على ما في الصورة وإدخاله اضافة لأسم المستخدم وكلمة السر.
لا يسمح لللمستخدم بالتقدم للتعريف عن نفسه ان لم يتمكن من ادخال ما هو مكتوب في الصورة captcha.
عادة لا تعرض الcaptcha من اول محاولة الا بعد عدة محاولات فاشلة حتى لا تتحول لعائق للمستخدمين العاديين.
يجب ان تكون الصورة مشوهة كفاية حتى تصعب على الروبوت من تمييز فحواها, هذا ممكن بسهولة لهاكر يملك جهاز تحليل الكتابة, مع ذلك ان تكون سهلة للمستخدمين العاديين.
يمكن استعمال هذه الوحدة في اكثر من مكان في الموقع مثل "اتصل بنا" حتى لا يتم ادخال spam روبوتي.

ما الهدف ؟
بامكان اي هاكر مبتدئ ان يشغل script يدخل مباشرة اسم مستخدم وكلمة سر في المربع بصورة دورية وكل مرة مع محاولة كلمة سر
جديدة حتى محاولة اخيرة يتمكن فيها من توقع كلمة السر للمستخدم والدخول الى الموقع بإسمه.
عرض مثل هذه الصورة يقلل من هذا الخطر لان الscript غير قادر على قراءة ما هو مكتوب في الصورة (لانها مشوهه) بعكس
الانسان الذي منحه الله تعالى عقلا مميزا قادر على ان يحلل مثل هذه الكلمات المشوهه والتعرف عليها.

















2- أن تستعمل الأقفال الحساب للمستخدم بعد عدة محاولات لادخال اسم المستخدم وكلمة السر بصورة خاطئة :
يجب اقفال حساب المستخدم لفترة زمنية محدودة (نصف ساعة) في حال الإخطاء بادخال كلمة السر بعد عدة محاولات.
هذه لانه في حال ان حدث فمن الممكن ان يكون مستخدما يحاول توقع كلمة السر.
مدة الإقفال المحدودة زمنيا تمنع ان تتعرض كل حسابات المستخدمين للاقفال من طرف الهاكرز.

3- التزود بنظام ذكي الذي بمقدوره ان يمنع اي طلب شاذ عن الطلبات المعتادة.
مفلس هسا اشرح عنه, عذرا بدي انام :)

الأحد، 4 يوليو 2010

نظام انترنتي متعدد الطبقات





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

ما هي الطبقات ؟
هنالك عدة تعريفات للطبقات في هذا الخصوص, طبقات في البرنامج layers, وطبقات التوزيع الشبكي للخدم (servers tier) , ان الفصل بين مكونات التطبيق يمكًن من اضافة عناصر اخرى للحماية من الاخطار, وكذلك يضاعف من جاهزية الشركة لأضافة servers ان استدعت الحاجة لذلك.
الفصل الذي اتكلم عنه هنا هو الفصل الشبكي.

الطبقة الاولى (1):
هي الطبقة التي يكون فيها الخادم الذي يتصل به المستخدم مباشرة, عادة ما تدعى presintation (طبقة العرض)

الطبقة الثانية (2):
هي الطبقة التي تربط بين النظم الداخلية والخادم الامامي في طبقه 1. (middle tier), وتدعى في كثير من الأحيان البنية التحتية.

الشبكة الداخلية :
فيها تتواجد انظمة الشركة الاساسية (CRM, Billing, ERP, BI) واخرى.

الفاصل بين الطبقات :
ان وضع firewall يهدف لحماية الخادم والنظم من تعرضها للقرصنة بشكل اساسي. فيمكن التحكم عن طريقه بقناة اللاتصال والثغرات المفتوحة (firewall) بين الخادم وبين المسنخدم, وهو عبارة عن برنامج يمكن التحكم بمعاييره حسب الحاجه كأن يفتح port 80 فقط, لمنع الاتصال باي جهاز غير الخادم.
جهاز توزيع الضغط Load Balance والذي من وظيفته ان يستقبل الطلبات وان يوزعها على الخدم الخلفية وحسب معايير تضمن توزيع الضغط ليضمن تواصل الخدمة لكل المستخدمين, هناك عدة خوارزميات لتوزيع الضغط مثل :
1- The round-robin algorithm: واساسه ان كل خادم يتلقى الطلب القادم حسب الدور بشكل دوري فكل خادم يقدم
نفس عدد الخدمات.
2- Persistent IP : وهو توزيع الخدمة بين الخدم حسب IP المستخدم. فان ذلك يوزع الضغط بشكل عشوائي نوعا ما,
لكنه يضمن ان كل مستخدم يرجع في العمل امام نفس الخادم.

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

طرق الاتصال بين الطبقات :
هناك بروتوكولات كثيرة لربط الطبقات والإتصال بينها, من اسهلها واكثرها انتشارا webservice, rmi,com وأحدثها wcf.
طبعا هذه البروتوكولات تسهل من القدرة على توسعة التطبيقات واستغلال البنيه التحتية في عدة تطبيقات مستقبلية.

الخميس، 24 يونيو 2010

كيف تربط بين عدة تطبيقات WEB تعمل بتكنولوجيا مختلفة (weblogic and .NET)


مشاركة Session بين تطبيقات web



اذا كان عندك عدة تطبيقات كل تحت خادم مختلف لنفرض IIS والاخر weblogic وتريد ان تشارك الاولى ذات ال Session مع الاخرى, هذه الحاجة كثيرا ما تحصل في شركات التي لا تقوم ببناء التطبيقات في مبنى الشركة, وتدخل تطبيقات من تقنيات مختلفه وجاهزه (تطبيقات من الرف) لسداد احتياجاتها.

من اجل التبسيط :
لنفرض ان لديك موقع اول وفيه تعرض منتوجات للبيع (منتوج,صورة,سعر) ومن خلاله يختار الزبون المنتوجات والكمية التي يود شراءها لنفرض http://catalog4me_bmawasy.com.

وفي موقع اخر (تحت خادم اخر) لديك تطبيق معد لان يجري عملية المحاسبة والدفع,لنفرض https://pay4me_bmawasy.com
بعد ان يقوم الزبون باختار المونتوجات ويتوجه للدفع, يجب ان يكون التطبيق الثاني قادر ان يتعرف على محتويات سلة الشراء,

فكيف يمكن ذلك ؟
طبعا قد يبدو هذ الحال غريبا الا انه وارد جدا, وكثيرا ما يحصل, وان دعت الحاجة الى ذلك, وفي كثير من الاحيان اسهل من مزج التطبيقات في تطبيق واحد.

يمكنك ان تقوم بالتالي :

1- الموقع الاول وعند الضغط على زر الدفع وفي جهة الخادم (server side) وقبل الانتفال الى موقع الدفع يقوم ب :

a. بناء XML يحتوي على المتغيرات المحفوظة في الSESSION والمنتوجات التي جمعها الزبون.
مثال :


<userdata>
<attribute name="username" value="bombalia"></attribute>
<attribute name="firstName" value="عواد"></attribute>
<attribute name="lastname" value="عواودة"></attribute>
<basketitems>
<item id="1212" name="حليب" count="12" price="10" unit="علبة لتر"></item>
<item id="2351" name="بندورة" count="2" price="3" unit="كغم"></item>
</basketitems>
</userdata>



b. بناء ما يدعى token والذي هو عبارة عن رقم او جملة عشوائية طويلة يصعب توقعها, مثال
token=AsC32AVvcgbb692-dfdf5fb5w43r
c. تخزين ال token و ال userdata في قاعدة بيانات مشتركة (يمكن للتطبيقين ان يتصلا بها)
d. يوجه المتصفح عند الزبون الى عنوان الموقع الثاني (موقع الدفع) ويضم العنوان قيمة الtoken التي تم انتاجها للتو, مثال :
https://pay4me_bmawasy.com?token=AsC32AVvcgbb692-dfdf5fb5w43r&source=http://catalog4me_bmawasy.com


2- على الموقع الثاني ان يتعرف على محتويات السلة وتفاصيل الزبون التي جمعت من قبل, فعليه استعمال المتغير token
فيتوجه الى قاعدة البيانات ويطلب الXML التابع لtoken.
3- يجب محو سطر الtoken من قاعدة البيانات حتى نحفظ ان لا يتم استعماله من قبل هاكرز.
4- تعرض الفاتورة حسب ما رجع من ال XML ليدفعها الزبون ويكمل مشواره فرحا بما اشتراه :)










الثلاثاء، 22 يونيو 2010

كيف يمكن منع تعرض الموقع للتجمد !!


هنالك بعض المواقع المعدة لاعطاء الخدمة الذاتية للزبائن. ومثل هذه المواقع عليها ان تكون متصلة في كثير من الاحيان مع النظم الداخلية للشركة, وهذا الاتصال عادة ما يكون عن طريق webservice, قد يتعرض الموقع للتجمد اذا حصل التالي في ذات الوقت :
  1. اذا كان اقبال كبير على الموقع في ساعات الضغط.
  2. اذا كانت نظم الشركة تعاني الضغط في ذات الوقت بسبب إما الصيانة او تشغيل معالجة معطيات (تجهيز حساب فواتير مثلا).
في مثل هذه الحالة ما سيحصل هو عبارة عن ازدحام كما في السير الى درجة التجمد في الموقع على الweb. اذا حاولت دخوله في هذه اللحظة فانك لن تلقى اي رد من الخادم لفترة طويلة والتي قد تصل الى عدة دقائق في بعض الاحيان ان صح الحال.

لماذا يحدث هذا؟
ان الخادم قادر على ان يعطي الخدمة لحد معين من الاتصالات به requests في ذات الوقت, في حال ان قام الطلب الاول "request" والذي من خلاله على الخادم ان يشغل معالجة داخل نظم الشركة والتي تعاني الضغط عبر ال webservice فان على ال webservice الانتظار حتى ينتهي تنفيذ دوره, لكن العالم ليس ملكك وحدك, ففي ذات الوقت بينما انت في الانتظار سياتي زبزن اخر ويطلب ذات الخدمة وعليه الانتظار ايضا. والزبون الاخر سيأتي ايضا بعد ثوان او اقل, وكلما زاد الوقت زاد المنتظرون وزادوا وزادوا....... حتى ان لا يتمكن الخادم من استيعاب الطب الاخير والذي زاد الحد الذي يقدر عليه.
عندها فان الزبائن الاخرين لن يتمنكوا من عرض حتى صفحة HTML عادية خالية من اي معالجة معطيات, فما ذنبهم !! ولماذا هم ايضا ينتظرون. ولم لا نحل لهم المشكلة !!

فما الحل ؟

هناك كثير من الحلول التي يمكن ان تساعد في حل هذا الحال, ولكن يجب ان تدرس ملائمة الحل مع امكانيات الشركة المادية, الوقت المتاح لتجهيزه, وملائمته للنطم في الشركة, واذا كان من الممكن الدمج بينها فان ذلك افضل كثيرا .

الحل الاول :
قد يدور في البال اضافة خادم انترنت امامي, لكن هذا لن يساعد كثيرا ومن المرجح انه اذا وصل الحال ان تجمد الموقع من الضغط عليه فان خادم اضافي قد يخدم بعض الزبائن الاضافيين ويتجمد ايضا. فاذا دخل المستخدم الاضافي وطلب صفحة فيها معالجة معطيات تعتمد على النطم الداخلية فان عليه الانتظار طويلا (دقائق) ليضاف الى قائمة المنتظرين لنرجع لنفس الحال, هذا والاهم من ذلك فانه لن يتلقى الخدمة من الخادم فهو عادة غير مستعد للانتظار لدقائق حتى تتم معالجة معطياته.

الحل الثاني:
مما يتبين فان المشكلة ليست كامنة في خادم الانترنت بل في النظم الداخلية, فهي مصدر التعويق (عنق الزجاجة), اذا يمكن نظريا تحسين وظيفة النظم الداخلية بالبحث عن معالجات تعيق السير (مثل, SQL غير مفحوص من قبل, مشكلة في شبكة الاتصال الداخلية, مشكلة مساحات تخزين, تشغيل نظم تخزين اضافي (backup) في توقيت غير مناسب, تشغيل antivirus في توقيت غير مناسب, او معالجة بيانات ضخمة في ذات الوقت بدل ان تقسم الى مراحل مثل تجهيزحسابات وانتاج تقارير طويلة اخرى).

الحل الثالث:
اضافة خادم للنظم الداخلية حتى يتم تحسين اداءها, طبعا هذا الحل ليس سهلا ولا رخيصا دائما, وقد تكون تكوينة النظم الداخلية لا تسمح بمثل هذا الحل.

الحل الرابع :
عليك ان تدخل بعض التغييرات في تصميم التطبيق على النت ليعمل بالشكل التالي,
1.تقسيم الخدمات في الموقع الى قسمين اساسيين, عرض بيانات GET, ومعالجة طلبات (Process).

1. فيما يتعلق بمعالجة طلبات فالعمل بصورة asynchronic (طلب المعالجة لا ينتظر الرد), فان الزبون عندما يطب مثلا ان يسجل لخدمة معينة فسيتم تنفيذها لاحقا,
وتعرض له اجابة من نوع "تلقينا طلبك وسيتم تنفيذها لاحقا". وهناك طرق كثيرة لتحقيق ان ينفذ الطلب.
2.فيما يتعلق بعرض بيانات, فالهدف واضح, فان المستخدم عادة لا يقبل الانتظار طويلا امام الشاشة, فالحل الامثل هو ان تعطي في تصميم تطبيقق امكانية توقيت حد اقصى (timeout), والذي يتلائم مع نوع الخدمة.
ان ذلك يقلل من انتظار المستخدم حتى وان تلقى ردا من نوع "نأسف , هذا الخدمة غير متوفرة حاليا", وبالمقابل فان يقلل دور المنتظرين, فتحديد وقت للخدمة يعطي نتائج مضاعفة عن اضافة خادم. ان ذلك يعطيك القدرة على التحكم بالردود على الطلبات المتواردة على التطبيق, ويعطي انطباعا افضل لدى المستخدم.




السبت، 19 يونيو 2010

كيف تحافظ على نظم الشركة من الهاكرز مع ادخال خدماتك عن طريق الانترنت

ان الشركات اليوم تعمل جاهدة على تحسين الخدمة للزبائن وفي ذات الوقت ان تزيد من ارباحها.
وتجد هذه الشركات الحلول في استعمال الانترنت للتواصل مع الزبائن بصورة اسرع ومقللة من الحاجة الى توظيف موظفين في هذا المجال.
ما يجب ان يؤخذ بعين الاعتبار هو المحافظة على نظم الشركة من التعرض للقرصنة من قبل الهاكرز, لذلك يجب التقيد بالضوابط المبدأية التالية :
  1. يجب ان تحمي حظيرة الانتاج باستعمال firewall ونظام Proxy الذين يقللان بدورهما من طلب خدمات من الخادم غير متطابقه مع تصميم الموقع واهدافه
  2. ان يتم الفصل بين الخادم للانترنت والنظم الداخلية باستعمال Firewall
  3. ان يقوم الاتصال بين خادم الانترنت والنظم الداخلية عن طريق بروتوكولات اتصال معروفة ك SOAP او RMI او ,Web Services ومن خلال وحدة اتصال مركزية حتى تتم مراقبتها بصورة افضل.
  4. ان تقوم البرامج من الطرفين بتحديد نوع البيانات التي تتوقع استقبالها (رقمية تاريخ احرف خاصة او لا وطول البيانات)
  5. استخدام وسائل امنية للتاكد من خلو البيانات المتداولة بين الطرفين من جمل قرصنة (SQL Injection) مثلا او Javascript , ومحتويات خطرة اخرى.
  6. تشفير الاتصال بشيفرات SSL المعروفة (Https) والتي تمنع من سرقة (او الاطلاع على محتوى الاتصال بين الطرفين).

طبعا هذا قليل من كثير وللمزيد ساعرض التركيب المثالي لاحقا ان شاء الله بالصور.

الأربعاء، 16 يونيو 2010

كيف يمكن زيادة الاعلان من دون تكلفة









استكمالا لما بدأته من قبل فهذه مركيات لنظام بعث رسائل ميل للزبائن مع اضافة دعاية مخصصة حسب مواصفات الزبون.
لنفرض ان لديك قائمة من الزبائن من فئات مختلفة : أصحاب ورش, أصاحب مطاعم, معلمين وكذا. وبودك نشر اعلانات تتلائم وكل فئة من خلال الميل الشهري او اي ميل يصدر منك اليهم.

عليك اولا ان تتجهز بالتالي:
1- جمع بيانات عن الزبائن حسب احتياجات التقسيم الذي تنويه
2- التزود بنظام رسائل الكترونية متطور ليتحمل الكميات التي يتم بعثها
3- نظام لصق اعلانات لمحتوى الرسالة
4- نظام بناء محتوى الرسالة وتصنيف الزبون كجزء من فحوى الرسالة

كيف يعمل ذلك

هناك شركات تستعمل البريد الالكتروني بشكل اساسي للتواصل مع زبائنها, كارسال الفاتورة مثلا, او تقارير شهرية, او حتى بريد في اطار خدمة الزبون.






كما مبين في الشكل فان العملية تمر بالمراحل التالية :

1. جمع بيانات الزبائن

هذه العملية عادة ما تكون الاصعب, اذ انها مرتبطة بمدى اهتمام الشركة في هذا الامر, مدى جاهزيتها وجاهزية نظمها لجمع المعطيات من
الزبائن , واكثر صعوبة هو جاهزية الزبون للتفاعل مع الموضوع. فتفاصيله الشخصية وطبيعة العمل الذي يعمل به ليست مما يرغب الزبون ان يعطيها عادة.

جمع المعطيات يتم من خلال استغلال فرص التماس مع الزبون في مراحل مختلفة على سبيل المثال :
مرحلة عرض الشراء والبيع, عند تواجد الزبون في المتجر مثلا.

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

من المهم ان تجمع هذه البيانات في قاعدة معطيات محوسبة (قاعدة بيانات نظام CRM- نظام ادارة العلاقات مع الزبائن).

2. اعداد الدعايات
على الدعاية ان تكون من نوع html, والذي يمكن اضافته كDIV في نهاية الرسالة الاصلية. دعايات من نوع HTML يمكنها ان تكون
الامثل لعدة اسباب :
  • يمكن ان تتضمن عدة انواع (نص, فلاش, صور, رابط الى موقع الشركة للتفاصيل...)
  • يمكن ان تتضمن javascript الذي يعطي تقارير عن من يضغط على الروابط ويمكن من اعداد احصائيات عن كيفية التفاعل من قبل الزبائن.
  • ارفاق الدعاية لا يثقل فحوى الرسالة من ناحية الحجم لما في ذلك من مشاكل في خادم الميل (الرسائل)
على الدعايات ان تكون متلائمة مع تصنيف الزبائن طبعا حسب الحاجة. لكل دعاية يرفق التصنيف المعدة له.
اعداد الرسائل يمكن ان يتم عن طريق محرر HTML عادي وليس بالشيئ الخاص.


3. إرسال الرسائل - المرحله الأولى :
ان الشركات اليوم تسعى للحفاظ على البيئة :) والتقليل من نفقاتها, وفي هذا السبيل انها تعتمد المراسلة عبر الميل.
نأخذ على سبيل المثال الفاتورة الشهرية :
بعد ان جمعت بيانات الزبون يمكن تصنيفه بالتصنيف المناسب, وهذا التصنيف يدخل كجزء من موضوع الرسالة,
مثال واحد من الاتي :
*** أعمال حرة *** فاتورة حساب
*** ممرضين *** فاتورة حساب
*** فنادق *** فاتورة حساب
واترك المجال للخيال......

ابعث الرسالة عبر SMTP "خاص" الذي يعمل على اضافة الدعاية المناسبة للرسالة حسب التصنيف (هناك نظم خاصة في السوق التي تعطي هذه الخدمة.

4. إرسال الرسائل - المرحله الثانية :
يقوم ال SMTP بالتعرف على نوع الدعاية التي يجب الصاقها من خلال قراءة موضوع الرسالة:
*** تصنيف *** فاتورة حساب , فيقوم بإضافة الدعاية في نهاية الرسالة. ومن ثم يغير موضوع الرسالة فيحذف التصنيف ليبقى الموضوع "فاتورة حساب".

للمزيد من المعلومات والتفاصيل اتصل بي على العنوان الخاص او اكتب تعليقك

السبت، 12 يونيو 2010

كيفية تطبيق رزمات رسائل معلوماتية للنقال




اول البرامج اللتي ساتكلم عنها هو برنامج معد لبعث رسائل SMS للمشتركين في رزمات مختلفه مثل (جولة اخبار, عظة اليوم, نكات اليوم....)
هذا البرنامج يحتوي على المركبات الرئيسية التالية :
  1. محرر المحتويات
  2. قاعدة بيانات
  3. مجدول مهام
  4. باعث رسائل SMS








محرر المواد
هو عبارة عن واجهة WEB معد لادخال المواد, هذه الواجهة متصلة بIIS/Apache والذي بدوره يتصل مع قاعدة البيانات.
هنا يمكن ادخال المحتويات في مجموعات متنوعة التصنيف والنمط (نصوص, صور, ملفات صوتية, ملفات فيديو ...)

قاعدة بيانات
في هذا الجزء يتم حفظ البيانات التالية
  1. قائمة المستخدمين وتفاصيلهم
  2. التأشيرات للدخول والاستخدام
  3. الزبائن والرزمات اللتي سجلوا لها
  4. محتويات الرسائل
  5. نظام تسجيل الجدوله والرسائل اللتي تم بعثها

مجدول مهام
وظيفة هذا الجزء هو ان يقوم بتشغيل باعث الرسائل في كل وقت من اوقات الرزمات, اذ ان لكل رزمة لها مواعيدها المحددة.


    باعث رسائل SMS
    هذا الكائن يقوم بتجميع قائمة الزبائن المنتسبة للمرزمة التي حان وقتها حسب المجدول, ومن ثم نص الرسالة المحدد حسب تحريرها الذي تم ومن ثم ببعث الرسالة عن طريق الخدم الخاص بالرسائل الى جهاز الزبون




    للمزيد من المعلومات والتفاصيل اتصل بي على العنوان الخاص او اكتب تعليقك

    ChatGPT للأطفال : طريق آمنة وممتعة للتعلم والاستكشاف

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