- بواسطة x32x01 ||
كلمة OWASP اختصار لـ Open Web Application Security Project
وتعتبر OWASP دي Community من 2001 هدفها انها تساعد الناس علي ال Development و ال MaIntenance و ال Acquisition و ال Operation بتاعت ال Applications بتاعتهم.
الحلو ف OWASP ان هي بتعمل Report كل 3 سنين اسمه OWASP Top 10
دة بيكون فيه اشهر 10 ثغرات امنية موجودة في ال Websites و ال Web Applications في ال 3 سنين دول و كل 3 سنين ال TOP 10 دول بيتغيروا سواء بيتغيروا في الترتيب او بيتعيروا في الأهمية لأنهم مترتبين من حيث الأهمية من 1 لـ 10
فيه الي بيتغير في الترتيب و فيه الي بيطلع برة ال Report خالص و بيدخل مكانه ثغرات تانية مكانتش موجودة قبل كدة...
المهم ان احنا لحد الشهر الي فات كنا شغالين علي Report بتاع 2013 هتقولي ازاي هو مش بيطلع كل 3 سنين يعني المفروض 2016 كان يبقي فيها Report ?!
حصلت مشكلة ف OWASP السنة الي فاتت و مقدروش ينزلوا Report و هينزلوه السنة دي المتوقع انه يا ما الشهر دة او الشهر الجاي ان شاء الله بس حصلت تسريبات لل Report و هشرح دلوقتي الحاجات الجديدة الي نزلت فيه ب اختصار شديد عشان الناس يكون عندها علم ب OWASP و بال Report بتاعها...الترتيب الي هقوله دة هو الي هيكون موجود فالـ Report بتاع 2017 ان شاء الله رقم 1 بيبقي اهم Vulnerability , من بعدها بتبتدي الأهمية تقل لحد رقم 10 :
رقم واحد : و دي اهم Vulnerability في ال Reports من عشر سنين و اكتر الي هي ال Injection
و ال Injection هنا مش المقصود بيها ال SQL Injection بس لا هو يقصد كل انواع ال Injection منها ال SQL و ال XML و ال HTML و ال DLL و غيرهم و المقصود بيها هي اني بعمل Inject لـ Malicious Code ايأ كان ايه هو نوع ال code دة عشان يا اما يعمل Retrieve لـ Data انا مش مسموحلي اشوفها او يعمل Execute ل Function انا عايزها تتنفذ في ال Application و مش المفروض منها انها تتنفذ.
رقم اتنين : Broken Authentication and Session Management
و هنا المشكلة بتكون موجودة في ال Authentication Function بتاعت ال Application الي هي مسؤولة انها تاخد ال Credentials بتاعتك و تتأكد من انك Authorized انك تعدي لل Step الي بعديها المشكلة بتكون ان ال Function معمولها Implementation غلط بيسمح ان لو حد عمل Exploit يقدر يعمل Bypass و يدخل مكان ال Authorized Person اما ال Session Management Function ف دي بتكون مسؤولة عن ال Concurrent Sessions المفتوحة من ال Users المفروض دي بتكون بعد ال Authentication و ال Authorization دي برضو من الحاجات الي لما بتكون فيها مشكلة بتبقي كارثة لأن ال Session دي بيكون ليها Unique ID بيختلف عن التاني فيه Flaw او Issue اسمها Session Fixation دي بمعني ان فيه بعض ال Developers مش بيهتموا بالموضوع و بيعملوا ان ال User لما بيدخل ب Session ID انها تفضل ثابته معاه متتغيرش طول ما ال Session مفتوحة يعني طول ما هو عامل Log in علي ال Site تفضل ال Session ID بتاعته مثلاً 12538hd8cxzn14 ف دي لو حد عرفها يقدر يحطها عنده كأنها هي ال Session ID بتاعته هيقوم ال Request رايح لل Server بال Session ID دي يقوم ال Server رادد عليه بال Page الي هي مفتوحة عند ال Authorized Person و يدخل كأنه هو بالظبط و دي كارثة لأنها موجودة ف بعض مواقع تحويل الفلوس بس طبعاً مش هينفع أقول أسامي عشان ميبقاش ال Post عبارة عن Offensive Reference
رقم تلاتة : Cross-Site Scripting (XSS)
دي من أشهر ال Vulnerabilities الموجودة و الي ال Hackers بيحبوها جداً لـ 3 أسباب
أول سبب هي سهولة ال Implementation بتاعتها تاني سبب قوتها تالت سبب ان فيه منها أنواع صعب جداً ان ال Auditor يقدر يكتشف ال Exploitation بتاعها
طب ايه هي ال XSS دي أصلاً ؟!
هي اني بدخل Malicious Javascript Scripts في ال Input Fields و لو هو Vulnerable Site ال Scripts دي بتروح يحصلها Execution في ال Back End و ترجع تديني ال Data الي انا طلبتها منها في ال Scripts ال Data دي ممكن تكون ال User Sessions او انها تجيب ال Access Credentials و غيرها من ال Damages الي تقدر تعمله في ال Application
رقم أربعة : Broken Access Control
دي بتكون نتيجة عيب فيه ال Authorization Flaw بتاع ال Application انه بيخلي ال Hacker لما يعملها Exploit يقدر يعمل Bypass لل Authentication و يعمل Unauthorized Access لل Sensitive Files و ال Sensitve Data الي المفروض محدش يوصلها الا ب Authentication
رقم خمسة : Security Misconfiguration
و دي مفيش اكتر منها بسبب الأهتمام بال Development و اهمال ال Implementation ال Security Misconfiguration ليها اكتر من نوع منها ال Errors Misconfigurations ان انا مش بـHandle ال Errors الي بتطلع عشان كدة تلاقي فيه Applications كتير تدخل فيها Data غلط يقوم رادد عليك ب Error موجود فيها ال Version مثلاً بتاع ال Database Engine ولا يرد عليك ب اسم ال Tableالي في ال Database و منها انا بستخدمها اني اروح اعمل Exploit لل SQL Injection مثلاً لأني عرفت المعلومات الي انا عايز اعرفها..ف ال Security Misconfiguration هي الي بتمهد الطريق لل Hacker انه يعمل Exploit ل Vulnerabilities تانية..
رقم ستة : Sensitive Data Exposure
و دي أغلبيتها بتكون عيب Developers يعني ممكن تكون بتقرأ Source Code تلاقي فيه ال Developers سايبين Comments لبعض بيبقي فيها Passwords او معلومات تانية مهمة المفروض متكونش موجودة او مثلاً تيجي تلاقي ان ال Credentials بيحصلها Store و Backup ف صورة Clear Text او تلاقي انهم بيستعملوا HTTP من غير ما يعملوا عليه اي Security Layer ف تلاقي ال Data بيحصلها Transfer برضو ف صورة Clear Text و غيرها من الأمثلة و طبعاً ال Data دي بتبقي يا اما User Names و Passwords او Credit Cards Numbers او Transaction Session بتاع فلوس و غيرها..
لحد هنا هما هما ال TOP 6 بتوع 2017 هما هما بتوع 2013 الي جاي بعد كدة دي ال Vulnerabilities الجديدة الي أول مرة تظهر في ال Report بتاع OWASP
رقم سابعة : Insufficient Attack Protection
دي كارثة جديدة من كوارث الزمن وهي مش Technical Vulnerability علي اد ما هي Logical Vulnerability و هي ان ال Application Owners ميقدروش يعملوا بسرعة Patch لل Application عشان يسدوا ال Vulnerability الموجودة فيه لأن ساعات ال Patchف حتة معينة بيتسبب ان ال Code يضرب ف حتة تانية و دي ساعتها بتبقي خطر جداً لأن ال Owners بيبقوا عارفين ان ال Application بتاعهم Vulnerable و ال Hackers بيبقوا عارفين و كلنا بنبقي عارفين بس ال Owners لسة مقدروش يجهزوا ال Security Patch الي يمنع ال Vulnerability دي و ف نفس الوقت ميقدروش يوقفوا ال Application بتاعه عشان ميحصلش Financial Loss
رقم تمانية : Cross-Site Request Forgery (CSRF)
و دي كانت موجودة السنين الي فاتت
دي معناها ان عن طريق Script او Malicious Page او Malicious URL Request بقدر اخلي ال User انه يعمل Request من غير ما يعرف لل Server بال Function الي انا عايزها و بالتالي لما ال Server يلاقي ال Request جاي من ال Authorized User بينفذه اما ال Function دي ف بعملها انا و مزاجي بقي يعني ممكن اخليه يبعتلي ال Session ID بتاعه او يحولي فلوس اي يبعتلي ال Credentials بتاعته و غيرها من ال Scenarios الي ممكن تحصل.
رقم تسعة : Using Components with Known Vulnerabilities
و دي برضو كانت موجودة السنين الي فاتت
و دي بتبقي غلط من ال Application Owner انهم بيحطوا Libraries او Frameworks او Software Modules بتكون Vulnerable و بتكون مسموحلها انها يحصلها Run ب نفس ال Privileges بتاعت ال Application ف بتبقي النتيجة ان ال Components دي لما بيحصلها Exploit بيقدر ال Attacker انه ينفذ الي هو عايزه من غير كمان ما يحتاج يعمل Privilege Escalation لأن هو كدة كدة بيـ Run بنفس ال Privileges بتاعت ال Application
رقم عشرة : Unprotected APIs
دي بقي جديدة يعني أول مرة تظهر في ال Report زيها زي رقم سابعة
ان كل ال Modern Applications دلوقتي ال Developers بقوا يستخدموا فيها APIs كتير بدل ما يكتبوا ال Code كله جاهز او انهم يكونوا عايزين يعملوا Integration لل Application بتاعهم بـ Application تاني ف يستخدموا ال API بتاع ال Application التاني دة و ينادوا عليه في ال Application بتاعهم و ال APIs دي ليها أنواع زي ال SOAP و ال REST و ال RPC و ال GWT و غيرهم و دة بيبقي فيه جزء من اهمال ال Developers لأنهم بياخدوا ال APIs دي زي ما هي مش بيتأكدوا الأول اذا كانت Vulnerable ولا لا و دة بيبقي خطر علي ال Application بتاعهم لو ال API دة Vulnerable.
وتعتبر OWASP دي Community من 2001 هدفها انها تساعد الناس علي ال Development و ال MaIntenance و ال Acquisition و ال Operation بتاعت ال Applications بتاعتهم.
الحلو ف OWASP ان هي بتعمل Report كل 3 سنين اسمه OWASP Top 10
دة بيكون فيه اشهر 10 ثغرات امنية موجودة في ال Websites و ال Web Applications في ال 3 سنين دول و كل 3 سنين ال TOP 10 دول بيتغيروا سواء بيتغيروا في الترتيب او بيتعيروا في الأهمية لأنهم مترتبين من حيث الأهمية من 1 لـ 10
فيه الي بيتغير في الترتيب و فيه الي بيطلع برة ال Report خالص و بيدخل مكانه ثغرات تانية مكانتش موجودة قبل كدة...
المهم ان احنا لحد الشهر الي فات كنا شغالين علي Report بتاع 2013 هتقولي ازاي هو مش بيطلع كل 3 سنين يعني المفروض 2016 كان يبقي فيها Report ?!
حصلت مشكلة ف OWASP السنة الي فاتت و مقدروش ينزلوا Report و هينزلوه السنة دي المتوقع انه يا ما الشهر دة او الشهر الجاي ان شاء الله بس حصلت تسريبات لل Report و هشرح دلوقتي الحاجات الجديدة الي نزلت فيه ب اختصار شديد عشان الناس يكون عندها علم ب OWASP و بال Report بتاعها...الترتيب الي هقوله دة هو الي هيكون موجود فالـ Report بتاع 2017 ان شاء الله رقم 1 بيبقي اهم Vulnerability , من بعدها بتبتدي الأهمية تقل لحد رقم 10 :
رقم واحد : و دي اهم Vulnerability في ال Reports من عشر سنين و اكتر الي هي ال Injection
و ال Injection هنا مش المقصود بيها ال SQL Injection بس لا هو يقصد كل انواع ال Injection منها ال SQL و ال XML و ال HTML و ال DLL و غيرهم و المقصود بيها هي اني بعمل Inject لـ Malicious Code ايأ كان ايه هو نوع ال code دة عشان يا اما يعمل Retrieve لـ Data انا مش مسموحلي اشوفها او يعمل Execute ل Function انا عايزها تتنفذ في ال Application و مش المفروض منها انها تتنفذ.
رقم اتنين : Broken Authentication and Session Management
و هنا المشكلة بتكون موجودة في ال Authentication Function بتاعت ال Application الي هي مسؤولة انها تاخد ال Credentials بتاعتك و تتأكد من انك Authorized انك تعدي لل Step الي بعديها المشكلة بتكون ان ال Function معمولها Implementation غلط بيسمح ان لو حد عمل Exploit يقدر يعمل Bypass و يدخل مكان ال Authorized Person اما ال Session Management Function ف دي بتكون مسؤولة عن ال Concurrent Sessions المفتوحة من ال Users المفروض دي بتكون بعد ال Authentication و ال Authorization دي برضو من الحاجات الي لما بتكون فيها مشكلة بتبقي كارثة لأن ال Session دي بيكون ليها Unique ID بيختلف عن التاني فيه Flaw او Issue اسمها Session Fixation دي بمعني ان فيه بعض ال Developers مش بيهتموا بالموضوع و بيعملوا ان ال User لما بيدخل ب Session ID انها تفضل ثابته معاه متتغيرش طول ما ال Session مفتوحة يعني طول ما هو عامل Log in علي ال Site تفضل ال Session ID بتاعته مثلاً 12538hd8cxzn14 ف دي لو حد عرفها يقدر يحطها عنده كأنها هي ال Session ID بتاعته هيقوم ال Request رايح لل Server بال Session ID دي يقوم ال Server رادد عليه بال Page الي هي مفتوحة عند ال Authorized Person و يدخل كأنه هو بالظبط و دي كارثة لأنها موجودة ف بعض مواقع تحويل الفلوس بس طبعاً مش هينفع أقول أسامي عشان ميبقاش ال Post عبارة عن Offensive Reference
رقم تلاتة : Cross-Site Scripting (XSS)
دي من أشهر ال Vulnerabilities الموجودة و الي ال Hackers بيحبوها جداً لـ 3 أسباب
أول سبب هي سهولة ال Implementation بتاعتها تاني سبب قوتها تالت سبب ان فيه منها أنواع صعب جداً ان ال Auditor يقدر يكتشف ال Exploitation بتاعها
طب ايه هي ال XSS دي أصلاً ؟!
هي اني بدخل Malicious Javascript Scripts في ال Input Fields و لو هو Vulnerable Site ال Scripts دي بتروح يحصلها Execution في ال Back End و ترجع تديني ال Data الي انا طلبتها منها في ال Scripts ال Data دي ممكن تكون ال User Sessions او انها تجيب ال Access Credentials و غيرها من ال Damages الي تقدر تعمله في ال Application
رقم أربعة : Broken Access Control
دي بتكون نتيجة عيب فيه ال Authorization Flaw بتاع ال Application انه بيخلي ال Hacker لما يعملها Exploit يقدر يعمل Bypass لل Authentication و يعمل Unauthorized Access لل Sensitive Files و ال Sensitve Data الي المفروض محدش يوصلها الا ب Authentication
رقم خمسة : Security Misconfiguration
و دي مفيش اكتر منها بسبب الأهتمام بال Development و اهمال ال Implementation ال Security Misconfiguration ليها اكتر من نوع منها ال Errors Misconfigurations ان انا مش بـHandle ال Errors الي بتطلع عشان كدة تلاقي فيه Applications كتير تدخل فيها Data غلط يقوم رادد عليك ب Error موجود فيها ال Version مثلاً بتاع ال Database Engine ولا يرد عليك ب اسم ال Tableالي في ال Database و منها انا بستخدمها اني اروح اعمل Exploit لل SQL Injection مثلاً لأني عرفت المعلومات الي انا عايز اعرفها..ف ال Security Misconfiguration هي الي بتمهد الطريق لل Hacker انه يعمل Exploit ل Vulnerabilities تانية..
رقم ستة : Sensitive Data Exposure
و دي أغلبيتها بتكون عيب Developers يعني ممكن تكون بتقرأ Source Code تلاقي فيه ال Developers سايبين Comments لبعض بيبقي فيها Passwords او معلومات تانية مهمة المفروض متكونش موجودة او مثلاً تيجي تلاقي ان ال Credentials بيحصلها Store و Backup ف صورة Clear Text او تلاقي انهم بيستعملوا HTTP من غير ما يعملوا عليه اي Security Layer ف تلاقي ال Data بيحصلها Transfer برضو ف صورة Clear Text و غيرها من الأمثلة و طبعاً ال Data دي بتبقي يا اما User Names و Passwords او Credit Cards Numbers او Transaction Session بتاع فلوس و غيرها..
لحد هنا هما هما ال TOP 6 بتوع 2017 هما هما بتوع 2013 الي جاي بعد كدة دي ال Vulnerabilities الجديدة الي أول مرة تظهر في ال Report بتاع OWASP
رقم سابعة : Insufficient Attack Protection
دي كارثة جديدة من كوارث الزمن وهي مش Technical Vulnerability علي اد ما هي Logical Vulnerability و هي ان ال Application Owners ميقدروش يعملوا بسرعة Patch لل Application عشان يسدوا ال Vulnerability الموجودة فيه لأن ساعات ال Patchف حتة معينة بيتسبب ان ال Code يضرب ف حتة تانية و دي ساعتها بتبقي خطر جداً لأن ال Owners بيبقوا عارفين ان ال Application بتاعهم Vulnerable و ال Hackers بيبقوا عارفين و كلنا بنبقي عارفين بس ال Owners لسة مقدروش يجهزوا ال Security Patch الي يمنع ال Vulnerability دي و ف نفس الوقت ميقدروش يوقفوا ال Application بتاعه عشان ميحصلش Financial Loss
رقم تمانية : Cross-Site Request Forgery (CSRF)
و دي كانت موجودة السنين الي فاتت
دي معناها ان عن طريق Script او Malicious Page او Malicious URL Request بقدر اخلي ال User انه يعمل Request من غير ما يعرف لل Server بال Function الي انا عايزها و بالتالي لما ال Server يلاقي ال Request جاي من ال Authorized User بينفذه اما ال Function دي ف بعملها انا و مزاجي بقي يعني ممكن اخليه يبعتلي ال Session ID بتاعه او يحولي فلوس اي يبعتلي ال Credentials بتاعته و غيرها من ال Scenarios الي ممكن تحصل.
رقم تسعة : Using Components with Known Vulnerabilities
و دي برضو كانت موجودة السنين الي فاتت
و دي بتبقي غلط من ال Application Owner انهم بيحطوا Libraries او Frameworks او Software Modules بتكون Vulnerable و بتكون مسموحلها انها يحصلها Run ب نفس ال Privileges بتاعت ال Application ف بتبقي النتيجة ان ال Components دي لما بيحصلها Exploit بيقدر ال Attacker انه ينفذ الي هو عايزه من غير كمان ما يحتاج يعمل Privilege Escalation لأن هو كدة كدة بيـ Run بنفس ال Privileges بتاعت ال Application
رقم عشرة : Unprotected APIs
دي بقي جديدة يعني أول مرة تظهر في ال Report زيها زي رقم سابعة
ان كل ال Modern Applications دلوقتي ال Developers بقوا يستخدموا فيها APIs كتير بدل ما يكتبوا ال Code كله جاهز او انهم يكونوا عايزين يعملوا Integration لل Application بتاعهم بـ Application تاني ف يستخدموا ال API بتاع ال Application التاني دة و ينادوا عليه في ال Application بتاعهم و ال APIs دي ليها أنواع زي ال SOAP و ال REST و ال RPC و ال GWT و غيرهم و دة بيبقي فيه جزء من اهمال ال Developers لأنهم بياخدوا ال APIs دي زي ما هي مش بيتأكدوا الأول اذا كانت Vulnerable ولا لا و دة بيبقي خطر علي ال Application بتاعهم لو ال API دة Vulnerable.