OWASP - User contributions [en]

Category:OWASP Project Archived Projects

2017-11-17T13:44:21Z

Rcbarnett: /* Archived /Low Activity Projects */

==Inactive/Archived/ Low Activity Projects==

====Archived /Low Activity Projects====

OWASP Archived Projects are projects that have developed outside OWASP umbrella or have become inactive. If you are interested in pursuing any of the projects below (inactive), please contact us and let us know of your interest.
* [[OWASP_File_Format_Validation_Project|OWASP_File Format Validation Project]]
*[[OWASP_SonarQube_Project|OWASP SonarQube Project]]
* [[OWASP_PHPRBAC_Project|OWASP PHPRBAC Project]]
*[[OWASP_Periodic_Table_of_Vulnerabilities|OWASP Periodic Table of Vulnerabilities]]
* [[OWASP_Mantra_OS|OWASP Mantra OS]]
*[[OWASP_Data_Exchange_Format_Project|OWASP Data Exchange Format Project]]
*[[OWASP_Encoder_Comparison_Reference_Project|OWASP Encoder Comparison Reference Project]]
*[[OWASP_iGoat_Project|OWASP iGoat Project]]
*[[OWASP_Secure_Application_Design_Project|OWASP Secure Application Design Project]]
*[[OWASP_Bricks|OWASP Bricks]]
*[[OWASP_Top_Trumps_for_Projects|OWASP Top Trumps for Projects]]
* [[https://www.owasp.org/index.php/WebGoatPHP | WebGoatPHP]]
*[[OWASP JSEC CVE Details | OWASP JSEC CVE Details]]
* [[:Category:OWASP_WebGoat.NET|OWASP WebGoat.NET]]
*[[OWASP_Top_10_Fuer_Entwickler_Project|OWASP Top 10 Fuer Entwickler Project]]
*[[Projects/OWASP_iOSForensic|OWASP iOSForensic]]
*[[OWASP_XSecurity_Project|OWASP XSecurity Project]]
*[[OWASP_Secure_TDD_Project|OWASP Secure TDD Project]]
*[[:Category:OWASP_SQLiX_Project|OWASP sqliX Project]]
*[[OWASP_NINJA_PingU_Project|OWASP NINJA PingU Project]]
*[[OWASP_Security_Frameworks_Project|OWASP Security Frameworks Project]]
* [[OWASP_ASIDE_Project|OWASP ASIDE Project]]
*[[OWASP_Bywaf_Project|OWASP Bywaf Project]]
* [https://www.owasp.org/index.php/Category:OWASP_Wapiti_Project OWASP Wapiti Project]
* [[OWASP_Security_Research_and_Development_Framework|OWASP Security Research and Development Framework]]
*[[OWASP Persian Translation Project | OWASP Persian Translation Project]]
*[[OWASP_Visual_Crime_Scene_and_Security_Incident_Education_Project#tab=Main | OWASP Visual Crime Scene and Security Incident Project]]
*[[OWASP_Secure_Development_Training|OWASP Secure Development Training]]
*[[OWASP_Global_Chapter_Meetings_Project|OWASP Global Chapter Meetings Project]]
*[[OWASP_Hacking_Lab|OWASP Hacking-Lab]]
* [[OWASP_iMAS_iOS_Mobile_Application_Security_Project|OWASP iMAS - iOS Mobile Application Security Project]]
* [[OWASP_Joomla_Vulnerability_Scanner_Project|OWASP Joomla Vulnerability Scanner Project]]
* [[OWASP_Java_File_I_O_Security_Project|OWASP Java File I/O Security Project]]

* [[OWASP_Security_Controls_in_Web_Application_Development_Lifecycle |OWASP Security Controls in Web Application Development Lifecycle Project]]
* [[OWASP_Product_Requirement_Recommendations_Library|OWASP_Product_Requirement_Recommendations_Library]]
* [[OWASP_Knowledge_Graph|OWASP_Knowledge_Graph]]
* [[OWASP_Hardened_Phalcon_Project|OWASP Hardened Phalcon Project]]
* [[OWASP System Vulnerable Code Project]]
* [[OWASP_Click_Me_Project|OWASP Click Me Project]]
* [[OWASP_ISO_IEC_27034_Application_Security_Controls_Project|OWASP ISO/IEC 27034 Application Security Controls Project]]
* [[Projects/OWASP_GoatDroid_Project|OWASP GoatDroid Project]]
* [[WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project|WASC/OWASP Web Application Firewall Evaluation Criteria (WAFEC)]]
* [[OWASP_Security_Principles_Project|OWASP Security Principles Project]]
* [[OWASP_Insecure_Web_Components_Project|OWASP Insecure Web Components Project]]
* [[OWASP_Open_Cyber_Security_Framework_Project|OWASP Open Cyber Security Framework Project]
* [[OWASP_Embedded_Application_Security|OWASP Embedded Application Security]]
* [[OWASP_STING_Game_Project|OWASP STING Game Project]]
* [[Projects/OWASP_Ruby_on_Rails_and_friends_Security_Guide|OWASP Ruby on Rails and Friends Security Guide]]
* [[OWASP_Supporting_Legacy_Web_Applications_in_the_Current_Environment_Project|OWASP Supporting Legacy Web Applications in the Current Environment Project]]
* [[OWASP_System_Vulnerable_Code_Project|OWASP System Vulnerable Code Project]]
* [[OWASP_Project_Metrics|OWASP Project Metrics]]
* [[OWASP_Store_Sheep_Project|OWASP Store Sheep Project]]
* [[OWASP_PHP_Security_Project|OWASP PHP Security Project]]11/25/2015
* [[OWASP_ASVS_Assessment_tool | OWASP Assesment Tool]]
* [[:Category:OWASP_Orizon_Project|OWASP Orizon Project]]
* [[OWASP_PHP_Portscanner_Project|OWASP PHP Portscaner Project]]
* [[OWASP_Androick_Project|OWASP Androïck Project]]
* [[OWASP_EJSF_Project|OWASP EJSF Project]]
* [https://www.owasp.org/index.php/Category:OWASP_Access_Control_Rules_Tester_Project OWASP Access Control Rules Tester Project]
* [[OWASP_URL_Checker|OWASP URL Checker]]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Metrics_Project OWASP Application Security Metrics Project]
* [https://www.owasp.org/index.php/Category:OWASP_AppSec_FAQ_Project OWASP AppSec FAQ Project]
* [https://www.owasp.org/index.php/Asdr OWASP ASDR Project]
* [https://www.owasp.org/index.php/Category:OWASP_Backend_Security_Project OWASP Backend Security Project]
* [https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls OWASP Best Practices: Use of Web Application Firewalls]
* [https://www.owasp.org/index.php/Category:OWASP_CAL9000_Project OWASP CAL9000 Project]
* [https://www.owasp.org/index.php/Category:OWASP_CLASP_Project OWASP CLASP Project]
* [https://www.owasp.org/index.php/Category:OWASP_Code_Crawler OWASP CodeCrawler Project]
* [https://www.owasp.org/index.php/Category:OWASP_Content_Validation_using_Java_Annotations_Project OWASP Content Validation using Java Annotations Project]
* [https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project OWASP DirBuster Project]
* [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project OWASP Encoding Project]
* [https://www.owasp.org/index.php/Category:OWASP_Google_Hacking_Project OWASP Google Hacking Project]
*[[OWASP_Game_Security_Framework_Project|OWASP Game Security Framework Project]]
* [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project OWASP Insecure Web App Project]
* [https://www.owasp.org/index.php/Category:OWASP_Interceptor_Project OWASP Interceptor Project]
* [https://www.owasp.org/index.php/Category:OWASP_JSP_Testing_Tool_Project OWASP JSP Testing Tool Project]
* [[OWASP_Java_XML_Templates_Project|OWASP Java XML Templates Project]]
* [https://www.owasp.org/index.php/Category:OWASP_LiveCD_Education_Project OWASP LiveCD Education Project]
* [https://www.owasp.org/index.php/Category:OWASP_Logging_Project OWASP Logging Guide]
* [https://www.owasp.org/index.php/Category:OWASP_NetBouncer_Project OWASP NetBouncer Project]
* [[OWASP_NAXSI_Project|OWASP NAXSI Project]]
* [https://www.owasp.org/index.php/Category:OWASP_OpenPGP_Extensions_for_HTTP_-_Enigform_and_mod_openpgp OWASP OpenPGP Extensions for HTTP - Enigform and mod_openpgp Project]
* [https://www.owasp.org/index.php/Category:OWASP_OpenSign_Server_Project OWASP OpenSign Server Project]
* [https://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project OWASP Pantera Web Assessment Studio Project]
* [https://www.owasp.org/index.php/Category:OWASP_PHP_Project OWASP PHP Project]
* [https://www.owasp.org/index.php/ORG_%28OWASP_Report_Generator%29 OWASP Report Generator]
* [https://www.owasp.org/index.php/Category:OWASP_SASAP_Project OWASP Scholastic Application Security Assessment Project]
* [https://www.owasp.org/index.php/Category:OWASP_Security_Analysis_of_Core_J2EE_Design_Patterns_Project OWASP Security Analysis of Core J2EE Design Patterns Project]
* [https://www.owasp.org/index.php/Category:OWASP_Security_Spending_Benchmarks OWASP Security Spending Benchmarks Project]
* [https://www.owasp.org/index.php/OWASP_SiteGenerator OWASP Site Generator Project]
* [https://www.owasp.org/index.php/Category:OWASP_Skavenger_Project OWASP Skavenger Project]
* [https://www.owasp.org/index.php/Category:OWASP_Source_Code_Flaws_Top_10_Project OWASP Source Code Flaws Top 10 Project]
* [https://www.owasp.org/index.php/Category:OWASP_Sprajax_Project OWASP Sprajax Project]
* [https://www.owasp.org/index.php/Category:OWASP_Sqlibench_Project OWASP Sqlibench Project]
* [https://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project]
* [https://www.owasp.org/index.php/Category:OWASP_Teachable_Static_Analysis_Workbench_Project OWASP Teachable Static Analysis Workbench Project]
* [https://www.owasp.org/index.php/OWASP_Tiger OWASP Tiger]
* [https://www.owasp.org/index.php/Category:OWASP_Tools_Project OWASP Tools Project]
* [https://www.owasp.org/index.php/Projects/OWASP_Uniform_Reporting_Guidelines OWASP Uniform Reporting Guidelines]
* [https://www.owasp.org/index.php/Category:OWASP_WeBekci_Project OWASP Webekci Project]
* [https://www.owasp.org/index.php/JBroFuzz JBroFuzz]
* [https://owasp.org/index.php/Category:OWASP_SWAAT_Project OWASP SWAAT Project]
* [https://www.owasp.org/index.php/OWASP_Secure_Web_Application_Framework_Manifesto OWASP Secure Web Application Framework Manifesto]
* [https://www.owasp.org/index.php/Scrubbr OWASP Scrubbr]
* [[OWASP_Scada_Security_Project|OWASP Scada Security Project]]
* [https://www.owasp.org/index.php/OWASP_JavaScript_Sandboxes OWASP JavaScript Sandboxes Project]
* [https://www.owasp.org/index.php/OWASP_Hatkit_Datafiddler_Project OWASP Hatkit Datafiddler Project]
* [https://www.owasp.org/index.php/OWASP_Hatkit_Proxy_Project OWASP Hatkit Proxy Project]
* [https://www.owasp.org/index.php/OWASP_Fiddler_Addons_for_Security_Testing_Project OWASP Fiddler Addons for Security Testing Project]
* [https://www.owasp.org/index.php/OWASP_Forward_Exploit_Tool_Project OWASP Forward Exploit Tool Project]
* [https://www.owasp.org/index.php/Category:OWASP_Fuzzing_Code_Database OWASP Fuzzing Code Database]
* [https://www.owasp.org/index.php/Category:OWASP_Cloud_‐_10_Project OWASP Cloud ‐ 10 Project]
* [https://www.owasp.org/index.php/OWASP_Web_Browser_Testing_System_Project OWASP Web Browser Testing System Project]
* [https://www.owasp.org/index.php/Webscarab OWASP WebScarab Project]
* [https://www.owasp.org/index.php/Project_Information:template_Webslayer_Project OWASP Webslayer Project]
* [https://www.owasp.org/index.php/Project_Information:template_WSFuzzer_Project OWASP WSFuzzer Project]
* [http://owasp.com/index.php/Category:OWASP_Security_Assurance_Testing_of_Virtual_Worlds_Project OWASP Security Assurance Testing of Virtual Worlds Project]
* [https://www.owasp.org/index.php/OWASP_WAF_Project OWASP WAF Project]
* [https://www.owasp.org/index.php/OWASP_VFW_Project OWASP VFW Project]
* [https://www.owasp.org/index.php/OWASP_SIMBA_Project OWASP SIMBA Project]
* [https://www.owasp.org/index.php/OWASP_ONYX OWASP ONYX]
* [https://www.owasp.org/index.php/OWASP_Java_Uncertain_Form_Submit_Prevention OWASP Java Uncertain Form Submit Prevention]
* [https://www.owasp.org/index.php/OWASP_Ecuador OWASP Ecuador]
* [https://www.owasp.org/index.php/OWASP_ESOP_Framework OWASP ESOP Framework]
* [https://www.owasp.org/index.php/OWASP_Alchemist_Project OWASP Alchemist Project]
* [https://www.owasp.org/index.php/OWASP_Secure_the_Flag_Competition_Project OWASP Secure the Flag Project]
* [https://www.owasp.org/index.php/OWASP_Browser_Security_ACID_Tests_Project OWASP Browser Security ACID Test Project]
* [https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool OWASP AJAX Crawling Tool]
* [https://www.owasp.org/index.php/OWASP_Threat_Modelling_Project OWASP Threat Modeling Project]
* [https://www.owasp.org/index.php/OWASP_Crossword_of_the_Month OWASP Crossword of the Month]
* [https://www.owasp.org/index.php/OWASP_Secure_Password_Project OWASP Secure Password Project]
* [https://www.owasp.org/index.php/OWASP_Myth_Breakers_Project OWASP Myth Breakers Project]
* [http://owasp.com/index.php/OWASP_Project_Partnership_Model OWASP Project Partnership Model]
* [https://www.owasp.org/index.php/OWASP_Browser_Security_Project OWASP Browser Security Project]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Program_for_Managers OWASP Application Security Program for Managers]
* [https://www.owasp.org/index.php/Category:OWASP_Favicon_Database_Project OWASP Favicon Database Project]
* [https://www.owasp.org/index.php/OWASP_Security_JDIs_Project OWASP Security JDIs Project]
* [https://www.owasp.org/index.php/OWASP_File_Hash_Repository OWASP File Hash Repository]
* [https://www.owasp.org/index.php/OWASP_Crowdtesting OWASP Crowdtesting]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Skills_Assessment OWASP Application Security Skills Assessment]
* [https://www.owasp.org/index.php/OWASP_Common_Numbering_Project OWASP Common Numbering Project]
* [https://www.owasp.org/index.php/OWASP_WhatTheFuzz_Project#tab=Project_About OWASP WhatTheFuzz Project]
* [https://www.owasp.org/index.php/OWASP_Security_Tools_for_Developers_Project OWASP Security Tools for Developers Project]
* [https://www.owasp.org/index.php/Category:OWASP_Proxy OWASP Proxy Project]
* [https://www.owasp.org/index.php/OWASP_AW00T OWASP AW00t]
* [https://www.owasp.org/index.php/OWASP_Framework_Security_Project OWASP Framework Security Project]
* [https://www.owasp.org/index.php/OWASP_Desktop_Goat_and_Top_5_Project OWASP Desktop Goat and Top 5 Project]
* [https://www.owasp.org/index.php/OWASP_OVAL_Content_Project OWASP OVAL Content Project]
* [https://www.owasp.org/index.php/OWASP_Software_Security_Assurance_Process OWASP Software Security Assurance Process]
* [https://www.owasp.org/index.php/OWASP_Application_Fuzzing_Framework_Project OWASP Application Fuzzing Framework Project]
* [https://www.owasp.org/index.php/OWASP_Good_Component_Practices_Project OWASP Good Component Practices Project]
* [https://www.owasp.org/index.php/OWASP_1-Liner OWASP 1-Liner]
* [https://www.owasp.org/index.php/Category:OWASP_Java_Project OWASP Java Project]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Accessibility_Project#tab=Project_About OWASP Web Application Security Accessibility Project]
* [https://www.owasp.org/index.php/OWASP_OctoMS OWASP OctoMS]
* [https://www.owasp.org/index.php/OWASP_Java_J2EE_Secure_Development_Curriculum OWASP Java/J2EE Secure Development Curriculum]
* [https://www.owasp.org/index.php/OWASP_Droid_Fusion OWASP Droid Fusion]
* [https://www.owasp.org/index.php/OWASP_iSABEL_Proxy_Server OWASP iSABEL Proxy Server]
* [https://www.owasp.org/index.php/OWASP_WS_Amplification_DoS_Project OWASP WS-Amplification DoS Project]
* [https://www.owasp.org/index.php/OWASP_Windows_Binary_Executable_Files_Security_Checks_Project OWASP Windows Binary Executable Files Security Checks Project]
* [https://www.owasp.org/index.php/OWASP_Wordpress_Security_Checklist_Project OWASP Wordpress Security Checklist Project]
* [https://www.owasp.org/index.php/OWASP_Simple_Host_Base_Incidence_Detection_System_Project OWASP Simple Host Base Incidence Detection System Project]
* [https://www.owasp.org/index.php/OWASP_Unmaskme_Project OWASP Unmaskme Project]
* [https://www.owasp.org/index.php/OWASP_HA_Vulnerability_Scanner_Project OWASP HA Vulnerability Scanner Project]
* [[OWASP_Hive_Project|OWASP Hive Project]]
* [https://www.owasp.org/index.php/OWASP_Pygoat_Project OWASP Pygoat Project]
* [https://www.owasp.org/index.php/OWASP_Security_Labeling_System_Project OWASP Security Labeling System Project]
* [https://www.owasp.org/index.php/OWASP_IoTs_Project OWASP IoTs Project]
* [https://www.owasp.org/index.php/OWASP_STeBB_Project OWASP STeBB Project]
* [https://www.owasp.org/index.php/OWASP_Ultimatum_Project OWASP Ultimatum Project]
* [https://www.owasp.org/index.php/ESAPI_Swingset OWASP ESAPI Swingset Project]
* [https://www.owasp.org/index.php/OWASP_VaultDB_Project OWASP VaultDB Project]
* [https://www.owasp.org/index.php/Category:OWASP_Mutillidae OWASP Mutillidae Project]
* [https://www.owasp.org/index.php/Project_Information:template_Yasca_Project OWASP Yasca Project]
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project OWASP AntiSamy Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project OWASP Application Security Requirements Project]
* [https://www.owasp.org/index.php/Category:OWASP_CBT_Project OWASP Computer Based Training Project (OWASP CBT Project)]
* [https://www.owasp.org/index.php/OWASP_Exams_Project OWASP Exams Project]
* [https://www.owasp.org/index.php/OWASP_Passw3rd_Project OWASP Passw3rd Project]
* [https://www.owasp.org/index.php/OWASP_XSSER OWASP XSSER]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Assessment_Standards_Project OWASP Application Security Assessment Standards Project]
* [https://www.owasp.org/index.php/OWASP_Security_Baseline_Project OWASP Security Baseline Project]
* [https://www.owasp.org/index.php/OWASP_OpenStack_Security_Project OWASP OpenStack Security Project]
* [https://www.owasp.org/index.php/OWASP_S.T.I.N.G_Project OWASP S.T.I.N.G Project]
* [https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester Project]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Awareness_Top_10_E-learning_Project OWASP Application Security Awareness Top 10 E-learning Project]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Quick_Reference_Guide_Project OWASP Web Application Security Quick Reference Guide Project]
* [[Opa|OWASP OPA]]
* [[OWASP_Focus|OWASP Focus]]
* [[OWASP_Path_Traverser|OWASP Path Traverser]]
* [[OWASP_Watiqay|OWASP Watiqay]]
* [[OWASP_Academy_Portal_Project|OWASP Academy Portal Project]]
* [[OWASP_SamuraiWTF_Project|OWASP SamuraiWTF]]
* [[OWASP_SafeNuGet_Project|OWASP SafeNuGet Project]]
* [[OWASP_Rails_Goat_Project|OWASP Rails Goat Project]]
* [[OWASP_Research_Book_Project|OWASP Research Book Project]]
* [[OWASP_WebSandBox_Project|OWASP WebSandBox Project]]
* [[OWASP_Financial_Information_Exchange_Security_Project|OWASP Financial Information Exchange Security Project]]
* [[OWASP_Skanda_SSRF_Exploitation_Framework|OWASP Skanda - SSRF Exploitation Framework]]
* [[OWASP_JAWS_Project|OWASP JAWS Project]]
* [[OWASP_Secure_Headers_Project|OWASP Secure Headers Project]]
* [[OWASP_Barbarus|OWASP Barbarus]]
*[[OWASP_LAPSE_Project|OWASP LAPSE Project]]
*[[OWASP_Press|OWASP Press]]
====Research====
* [[OWASP_WASC_Distributed_Web_Honeypots_Project|OWASP WASC Distributed Web Honeypots Project]]

Category:OWASP Project

2017-11-17T13:42:42Z

Rcbarnett: Moving project status to Archived due to low activity

__NOTOC__

{|
|-
! width="700" align="center" | 
! width="500" align="center" | 
|-
|
| align="right" |

|}

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
= Welcome =
{| style="width: 100%;"
|-
| style="width: 100%; color: rgb(0, 0, 0);" |
{| style="border: 0px solid ; background: transparent none repeat scroll 0% 0%; width: 100%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"
|-
| style="width: 95%; color: rgb(0, 0, 0);" |


=== Welcome to the OWASP Global Projects Page ===

(The Projects pages are constantly being updated. Some pages may contain outdated information. You can help OWASP to keep these pages current by visiting [[:Category:FIXME|FixME]]) Please contact Claudia Aviles Casanovas with questions using the [https://www.tfaforms.com/308703 Contact Us form]

An OWASP project is a collection of related tasks that have a defined roadmap and team members. OWASP project leaders are responsible for defining the vision, roadmap, and tasks for the project. The project leader also promotes the project and builds the team. OWASP currently has ''''''over ''''''93'''''' active projects'''''', and new project applications are submitted every week.

This is one of the most popular divisions of OWASP as it gives members an opportunity to freely test theories and ideas with the professional advice and support of the OWASP community. Every project has an associated mail list. You can view all the lists, examine their archives, and subscribe to any project by visiting the [http://lists.owasp.org/mailman/listinfo OWASP Project Mailing Lists] page. A summary of recent project announcements is available on the [[OWASP Updates]] page.

Download the '''[[Media:PROJECT_LEADER-HANDBOOK_2014.pdf|OWASP Project Handbook 2014]]'''
- 2016 Project handbook updates are in progress, [https://www.tfaforms.com/308703 Contact US] to join the collaboration team and improve the process

'''[[OWASP_2014_Project_Handbook|OWASP Project Handbook Wiki 2014]]'''

'''[[Project_Online_Resources|Project Online Resources]]'''

=== Who Should Start an OWASP Project? ===

*Application Developers.
*Software Architects.
* Information Security Authors.
*Those who would like the support of a world wide professional community to develop or test an idea.
*Anyone wishing to take advantage of the professional body of knowledge OWASP has to offer.

=== Contact Us===

If you have any questions, please do not hesitate to [http://owasp4.owasp.org/contactus.html Contact Us] by using the form provided here. Please allow five working days for your question or comment to be answered. This is due to the large amount of queries the foundation staff receive every day. We thank you for your patience.

=== Fund Details ===

* [https://docs.google.com/a/owasp.org/spreadsheets/d/1dqpSk0uPCpB4z3e93hESFgYsBMsbSkUuZh2L91WVuYk/edit?usp=sharing Project Transactions - US (Amount shown in USD)]
* [https://docs.google.com/a/owasp.org/spreadsheets/d/1RgJVtBZtUEWyusXIW0AdAyKzNOEUiHGRX2blGWtgCFA/edit?usp=sharing Project Transactions - EU (Amount shown in Euros)]

=== Please see additional OWASP PROJECT FUNDING for 2016 ===

https://www.owasp.org/index.php/OWASP_Board_Votes

=== OWASP Project Inventory ===

All OWASP tools, document, and code library projects are organized into the following [[OWASP_Project_Stages|categories:]]

* '''[[OWASP_Project_Inventory#Flagship_Projects|Flagship Projects:]]''' The OWASP Flagship designation is given to projects that have demonstrated strategic value to OWASP and application security as a whole.

* '''[[OWASP_Project_Inventory#Labs_Projects|Lab Projects:]]''' OWASP Labs projects represent projects that have produced an OWASP reviewed deliverable of value.

* '''[[OWASP_Project_Inventory#Incubator_Projects|Incubator Projects:]]''' OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway.

=== Social Media ===

We recommend using the links below to find our official OWASP social media channels. These are a great way to keep in touch with the different initiatives going on at OWASP throughout the world. They are all updated regularly by chapter leaders, project leaders, the OWASP Board Members, and our OWASP Staff. If you have any questions or concerns about any of these accounts, please drop us a line using our [https://www.tfaforms.com/308703 "Contact Us"] form found above.

[[Image:Blogger-32x32.png|32px|link=http://owasp.blogspot.co.uk/]] [[Image:Twitter-32x32.png|32px|link=https://twitter.com/OWASP]] [[Image:Facebook-32x32.png|32px|link=https://www.facebook.com/groups/172892372831444/]] [[Image:Linkedin-32x32.png|32px|link=http://www.linkedin.com/groups/Global-OWASP-Foundation-36874]] [[Image:Google-32x32.png|32px|link=https://plus.google.com/u/0/communities/105181517914716500346?cfem=1]] [[Image:Ning-32x32.png|32px|link=http://myowasp.ning.com/]]



|}

| style="border: 3px solid rgb(204, 204, 204); vertical-align: top; width: 95%; font-size: 95%; color: rgb(0, 0, 0);" |
<div style="padding:2em;padding-bottom:0px;">

[[Image:New_initiatives.png|center|300px| link=http://owasp.force.com/volunteers/GW_Volunteers__VolunteersJobListing]]

[[Image:Donate_here_banner.png|center|300px| link=http://www.regonline.com/Register/Checkin.aspx?EventID=1044369]]
</div>

{|

| style="width: 110px; font-size: 95%; color: rgb(0, 0, 0);" |
|}

| style="width: 110px; font-size: 95%; color: rgb(0, 0, 0);" |
|}


= Project Inventory =


(The Projects pages are constantly being updated. Some pages may contain outdated information. You can help OWASP to keep these pages current by visiting [[:Category:FIXME|FixME]]) Please contact Claudia Aviles Casanovas with questions using the [https://www.tfaforms.com/308703 contact us form]

==Quick Guide to Projects==

===Quick Guide for Developers===

This is a Quick Guide for Developers new to OWASP projects:

Infographic containing Hyperlinks to projects:
https://magic.piktochart.com/output/6400107-untitled-infographic

Downloadable Images:
[[File:Owasp_Dev_Guide.pdf ]]

==Flagship Projects==
[[File:Flagship_banner.jpg]]

The OWASP Flagship designation is given to projects that have demonstrated strategic value to OWASP and application security as a whole.
After a major review process [[LAB_Projects_Code_Analysis_Report|More info here]] the following projects are considered to be flagship candidate projects. These project have been evaluated more deeply to confirm their flagship status:

====Tools [Health Check January 2017]====

* [[OWASP_Zed_Attack_Proxy_Project|OWASP Zed Attack Proxy]][[File:Thumbsup.png|15px]]
* [[OWASP_Web_Testing_Environment_Project|OWASP Web Testing Environment Project]][[File:Thumbsup.png|15px]]
* [[OWASP_OWTF|OWASP OWTF]][[File:Thumbsup.png|15px]]
* [[OWASP_Dependency_Check|OWASP Dependency Check]][[File:Thumbsup.png|15px]]
* [[OWASP_Security_Shepherd|OWASP Security Shepherd]][[File:Thumbsup.png|15px]]

====Code [Health Check January 2017]====
* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set Project]][[File:Thumbsup.png|15px]]
* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRFGuard Project]][[File:Thumbsup.png|15px]]
* [[OWASP_AppSensor_Project|OWASP AppSensor Project]][[File:Thumbsup.png|15px]]

====Documentation[Health Check January 2017] ====
* [[:Category:OWASP_Application_Security_Verification_Standard_Project|OWASP Application Security Verification Standard Project]][[File:Thumbsup.png|15px]]
* [[:Category:Software_Assurance_Maturity_Model|OWASP Software Assurance Maturity Model (SAMM)]][[File:Thumbsup.png|15px]]
* [[OWASP_AppSensor_Project|OWASP AppSensor Project]][[File:Thumbsup.png|15px]]
* [[:Category:OWASP_Top_Ten_Project|OWASP Top Ten Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Testing_Project|OWASP Testing Project]][[File:Thumbsup.png|15px]]

==Labs Projects==
[[File:Lab banner.jpg]]

OWASP Labs projects represent projects that have produced a deliverable of value. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.

===Thumbs up===
Thumbs up are given to LAB projects showing a steady progress in their development, had very active and continuous releases and commits, regular update of information on their wiki page and have quite complete documentation. These projects are almost ready to become flagship

====Tools [Reviewed Janaury 2017]====
* [[O-Saft|O-Saft]][[File:Thumbsup.png|15px]]
* [[OWASP_Dependency_Track_Project|OWASP Dependency Track Project]][[File:Thumbsup.png|15px]]
* [[:Category:OWASP_EnDe|OWASP EnDe Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Hackademic_Challenges_Project|OWASP Hackademic Challenges Project]]*[[Review Needed]]
* [[OWASP_Mantra_-_Security_Framework|OWASP Mantra Security Framework]]*[[Review Needed]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security Project]][[File:Thumbsup.png|15px]]
* [[OWASP_O2_Platform|OWASP O2 Platform]][[File:Thumbsup.png|15px]]
* [[OWASP_Passfault|OWASP Passfault]] [[File:Thumbsup.png|15px]]
* [[:Category:OWASP_Security_Ninjas_AppSec_Training_Program|OWASP Security Ninjas Appsec Training Program]]*[[Review Needed]]
* [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] [[File:Thumbsup.png|15px]]
* [[OWASP_Xenotix_XSS_Exploit_Framework|OWASP Xenotix XSS Exploit Framework]][[File:Thumbsup.png|15px]]
* [[OWASP_Code_Pulse_Project|OWASP Code Pulse Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Security_Knowledge_Framework#tab=Main | OWASP Security Knowledge Framework]][[File:Thumbsup.png|15px]]
*[[OWASP_SeraphimDroid_Project|OWASP SeraphimDroid Project]][[File:Thumbsup.png|15px]]
*[[OWASP_DefectDojo_Project|OWASP DefectDojo Project]][[File:Thumbsup.png|15px]]

====Documentation [Health Check January 2017]====

* [[OWASP_Application_Security_Guide_For_CISOs_Project|OWASP Application Security Guide For CISOs]]*[[Review Needed]]
* [[Cheat_Sheets|OWASP Cheat Sheets Project]] [[File:Thumbsup.png|15px]]
* [[OWASP_CISO_Survey|OWASP CISO Survey]] [[File:Thumbsup.png|15px]]*[[Review Needed]]
* [[:Category:OWASP_Code_Review_Project|OWASP Code Review Guide Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Codes_of_Conduct|OWASP Codes of Conduct]][[File:Thumbsup.png|15px]] *[[Review Needed]]
* [[OWASP_Cornucopia|OWASP Cornucopia]][[File:Thumbsup.png|15px]]
* [[:Category:OWASP_Guide_Project|OWASP Guide Project]][[File:Thumbsup.png|15px]]*[[Review Needed]]
* [[OWASP_Podcast|OWASP Podcast Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Proactive_Controls|OWASP Proactive Controls]] [[File:Thumbsup.png|15px]]
* [[OWASP_Internet_of_Things_Top_Ten_Project|OWASP Internet of Things Top Ten Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Top_10_Privacy_Risks_Project|OWASP Top 10 Privacy Risks Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project|OWASP Reverse Engineering and Code Modification Prevention Project]]*[[Review Needed]]
* [[OWASP_Snakes_and_Ladders|OWASP Snakes and Ladders Project]] [[File:Thumbsup.png|15px]]
* [[OWASP Automated Threats to Web Applications]] [[File:Thumbsup.png|15px]]

====Contests - Health Check February 2016====
*[[OWASP_University_Challenge|OWASP University Challenge]] [[File:Thumbsup.png|15px]]
* [[:Category:OWASP_CTF_Project|OWASP CTF Project]][[File:Thumbsup.png|15px]]

====Code [Reviewed January 2017====
* [[:Category:OWASP_Enterprise_Security_API|OWASP Enterprise Security API]]*[[Review Needed]]
* [[OWASP_Python_Security_Project|OWASP Python Security Project]]*[[Review Needed]]
* [[OWASP_Security_Logging_Project|OWASP Security Logging Project]][[File:Thumbsup.png|15px]]

==Incubator Projects==
[[File:Incubator_banner.jpg]]

OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.

===Thumbs up===
Thumbs up are given to incubator projects showing a steady progress in their development, had continuous releases and commits or have delivered a complete product, including open source repository location, basic user guidelines and documentation

====Code [Reviewed January 2017]====
* [[OWASP_Java_Encoder_Project|OWASP Java Encoder Project]] [[File:Thumbsup.png|15px]]
* [[OWASP_Java_HTML_Sanitizer|OWASP Java HTML Sanitizer Project]] [[File:Thumbsup.png|15px]]
* [[Projects/OWASP_Node_js_Goat_Project|OWASP Node.js Goat Project]] [[File:Thumbsup.png|15px]]
* [[OWASP_Mth3l3m3nt_Framework_Project|OWASP Mth3l3m3nt Framework Project]][[File:Thumbsup.png|15px]]
* [[CSRFProtector_Project|OWASP CSRFProtector Project]][[needs review]]
* [[WebGoatPHP|OWASP WebGoat PHP Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Secure_Headers_Project|OWASP Secure Headers Project]]*[[Review Needed]]
* [[OWASP_Vicnum_Project | OWASP Vicnum Projct]][[File:Thumbsup.png|15px]]
* [[OWASP_DeepViolet_TLS/SSL_Scanner|OWASP DeepViolet TLS/SSL_Scanner]][[File:Thumbsup.png|15px]]
* [[OWASP_Off_the_record_4_Java_Project|OWASP Off the record 4 Java Project]][[File:Thumbsup.png|15px]]
* [[OWASP_Learning_Gateway_Project|OWASP Learning Gateway Project]] [[NEW!]]

====Research====

====Tools [Reviewed last: January 2017]====
* [[Benchmark|OWASP Benchmark]][[File:Thumbsup.png|15px]]
* [[OWASP_Wordpress_Vulnerability_Scanner_Project | OWASP Wordpress Vulnerability Scanner]]*[[Review Needed]]
* [[OWASP_Threat_Dragon | OWASP Threat Dragon]][[File:Thumbsup.png|15px]]
* [[OWASP_Faux_Bank_Project|OWASP Faux Bank Project]]*[[Review Needed]]
* [[OWASP_Droid10_Project|OWASP Droid]][[File:Thumbsup.png|15px]]*[[Review Needed]]
*[[OWASP_WAP-Web_Application_Protection|WAP Web Application_Protection]]*[[Review Needed]]
*[[OWASP_Mutillidae_2_Project|OWASP Mutillidae 2 Project]]*[[Review Needed]]
*[[OWASP_WebSpa_Project|OWASP WebSpa Project]]*[[Review Needed]]
*[[OWASP_Pyttacker_Project|OWASP Pyttacker Project]][[File:Thumbsup.png|15px]]
*[[OWASP Rainbow Maker Project | OWASP Rainbow Maker Project]] *[[Review Needed]]
* [[OWASP_ZSC_Tool_Project|OWASP ZSC Tool Project]] [[File:Thumbsup.png|15px]]
*[[OWASP_Web_Malware_Scanner_Project|OWASP_Web Malware Scanner Project]][[File:Thumbsup.png|15px]]
*[[OWASP_Basic_Expression_%26_Lexicon_Variation_Algorithms_(BELVA)_Project| OWASP Basic Expression Lexicon Variation Algorithms (Belva) Project]]][[File:Thumbsup.png|15px]]
*[[OWASP_VBScan_Project| OWASP VBScan]][[File:Thumbsup.png|15px]]
*[[OWASP_AppSec_Pipeline|OWASP Appsec Pipeline]][[File:Thumbsup.png|15px]]
*[[OWASP_Juice_Shop_Project|OWASP Juice Shop Project]][[File:Thumbsup.png|15px]]
*[[OWASP_Bug_Logging_Tool|OWASP Bug Logging Tool]][[File:Thumbsup.png|15px]]
*[[OWASP_iGoat_Tool_Project|OWASP iGoat Tool Project]]
*[[OWASP_Risk_Rating_Management|OWASP Risk Rating Management]]
*[[OWASP_DevSlop_Project|OWASP DevSlop Project]] [[New!]]
*[[OWASP_SecurityRAT_Project|OWASP SecurityRAT Project]] [[New!]]

====Documentation[Review: May 2015 - Health Check January 2017]====
*[[OWASP_Vulnerable_Web_Applications_Directory_Project|OWASP Vulnerable Web Applications Directory Project]][[File:Thumbsup.png|15px]]
*[[:Category:OWASP_.NET_Project|OWASP .NET Project]]*[[Review Needed]]
*[[OWASP_WASC_Web_Hacking_Incidents_Database_Project|OWASP WASC Web Hacking Incidents Database Project]]*[[Review Needed]]
*[[OWASP_Incident_Response_Project|OWASP Incident Response Project]][[File:Thumbsup.png|15px]]*
*[[OWASP KALP Mobile Project | OWASP KALP Mobile Project]][[File:Thumbsup.png|15px]]*[[Review Needed]]
*[[OWASP_Application_Security_Program_Quick_Start_Guide_Project|OWSP_Application_Security_Program_Quick_Start_Guide_Project]]*[[Review Needed]]
*[[OWASP_Secure_Configuration_Guide|OWASP_Secure_Configuration_Guide]]*[[Review Needed]]
*[[OWASP_Knowledge_Based_Authentication_Performance_Metrics_Project|OWASP Knowledge Based Authentication Performance Metrics Project]][[File:Thumbsup.png|15px]]
*[[OWASP_RFP-Criteria|OWASP RFP Criteria]]*[[Review Needed]]
*[[OWASP_Web_Mapper_Project|OWASP Web Mapper Project]][[File:Thumbsup.png|15px]]
*[[OWASP_Top_10_fuer_Entwickler|OWASP 10 Fuer Entwickler]]*[[Review Needed]]
*[[WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project |WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project]][[File:Thumbsup.png|15px]]
*[[OWASP_Secure_Software_Development_Lifecycle_Project]]
*[[OWASP_Mobile_Security_Testing_Guide|OWASP Mobile Security Testing Guide]][[File:Thumbsup.png|15px]]
*[[OWASP_Anti-Ransomware_Guide_Project|OWASP Ransomeware Guide Project]][[File:Thumbsup.png|15px]]
*[[OWASP_Cyber_Defense_Matrix|OWASP Cyber Defense Matrix]]
*[[OWASP_Top_5_Machine_Learning_Risks|OWASP Top 5 Machine Learning Risks]] [[New]]
*[[OWASP_Security_Operations_Center_(SOC)_Framework_Project|OWASP Security Operations Center SOC Framework Project]][[New]]

==Educational Initiatives==
====Health Check February 2017====
*[[OWASP_Student_Chapters_Program|OWASP Student Chapters Project]][[File:Thumbsup.png|15px]]
*[[:Category:OWASP_Education_Project|OWASP Education Project]][[File:Thumbsup.png|15px]]
*[[:Category:OWASP_Speakers_Project|OWASP Speakers Project]][[File:Thumbsup.png|15px]]
*[[OWASP_Media_Project|OWASP Media Project]][[File:Thumbsup.png|15px]]
*[[OWASP_PHP_Security_Training_Project|OWASP PHP Security Training Project]][[File:Thumbsup.png|15px]]
*[[OWASP_Online_Academy#tab=Main | OWASP Online Academy]][[File:Thumbsup.png|15px]]

== Low Activity Projects ==
[[File:low_activity.jpg]]
======Low Activity (LABS)[Reviewed July 2015] Health Check February 2016======

These projects had no releases in at least a year, however have shown to be valuable tools
'''Code [Low Activity]''' Health Check February 2016

* [[OWASP_Broken_Web_Applications_Project|OWASP Broken Web Applications Project]][[File:Thumbsup.png|15px]]

'''Tools Health Check February 2016'''
*[[:Category:OWASP_WebScarab_Project|WebScarab]][[File:Thumbsup.png|15px]]
*[[OWASP_HTTP_Post_Tool|OWASP HTTP POST Tool]][[File:Thumbsup.png|15px]]

'''Documentation [Low Activity]''' '''Health Check February 2016'''
* [[OWASP_Appsec_Tutorial_Series|OWASP AppSec Tutorial Series]][[File:Thumbsup.png|15px]]
* [[:Category:OWASP_Legal_Project|OWASP Legal Project]][[File:Thumbsup.png|15px]]
* [[Virtual_Patching_Best_Practices|Virtual Patching Best Practices]][[File:Thumbsup.png|15px]]
* [[OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide|OWASP Secure Coding Practices - Quick Reference Guide]][[File:Thumbsup.png|15px]]

==Donated Projects==

OWASP Donated Projects are inactive projects that have been donated to the OWASP Projects Infrastructure.

====Tools====

* [[OWASP_Excess_XSS_Project|OWASP Excess XSS Project]][[File:Thumbsup.png|15px]]
* [[OWASP_JOTP_Project|OWASP jOTP Project]][[File:Thumbsup.png|15px]]

==OWASP Archived Projects==
OWASP Archived Projects are projects that have developed outside OWASP umbrella or have become inactive. If you are interested in pursuing any of the inactive projects (click hyperlink for list), please contact us and let us know of your interest.

'''Added New Project on February 2016'''

[[:Category:OWASP_Project_Archived_Projects]]

= Former Project Task Force =

====OWASP Project Task Force====
(The Projects pages are constantly being updated. Some pages may contain outdated information. You can help OWASP to keep these pages current by visiting [[:Category:FIXME|FixME]]) Please contact Claudia Aviles Casanovas with questions using the [https://www.tfaforms.com/308703 contact us form]

{{:Task_Force/OWASP_Projects}}

= Online Resources =

===Project Online Resources===

* [https://docs.google.com/a/owasp.org/spreadsheets/d/13QM6yCqpirNuURbBdB5YZ_30mfQGbLjzBTGx0CTSNWw/edit?usp=sharing|OWASP Open Source Project Resources & Services]

Please note that some services are 100% free and some have nominal cost.

{{:Project_Online_Resources}}

= Starting a New Project =

== So you want to start a project... ==

Starting an OWASP project is quite easy, and your desire to contribute and make it happen is essential.
[[File:HowToStartProjectoWasp.png | 600px | right]]

Here are some of the guidelines for running a successful OWASP project:

-Start exploring the actual OWASP projects Inventory. Many projects handle specific areas of security it is a good idea to start looking how other successful projects do this (LABS/Flagship)

-Place your idea or project on the [[Project_Ideas_Board#From_Idea_to_Project_Incubator|Project Ideas Board]]. This phase will help you to define the project goals and also explore and exchange with other OWASP leaders and volunteers how to develop the idea into a tangible project

-Explore and research if your idea covers a unique segment in the Security arena. Think of your project as a product, if you really want people using it, think how this project will cover a necessity in the security area you are working on

-Define what kind of project you would like to start. Is it a code, tool or documentation?

-Communicate through the Project leader mailing list about your idea and get feedback and meet potential contributors

-Develop your project based on the type of project. For example if you are willing to start a documentation project, begin by defining a Table of Content and work it through with potential contributors. First of all begin by creating a Road-map for your project. This is essential to submit your project. We highly recommend to read documentation such as "[http://www2.econ.iastate.edu/tesfatsi/ProducingOSS.KarlFogel2005.pdf How to start /run a successful Open Source Projects]".

[[File:RoadmapIncubatorProjectExample2.PNG | 500px | left]]

Some recommendations on how to start a documentation project
[[:File:Document_Guide_(1).png| Document Guide Project]]

===Importance of a well thought out Road-map===
Many Incubator project leaders struggle with creating a realistic planning, which should be based on their available resources and time. A well thought out plan makes a difference between a procrastinating project and a successful one. The important aspect of this is, that the project leader is able to create a plan based on his situation. The following is an example of a Roadmap, which has focused to produce a Documentation first release in a year and a basic outline how they plan to cover 4 essential aspects which are Research & Development, Marketing, Planning and Goals.

"Your [project] roadmap should tell a coherent story about the likely growth of your product. Each release should build on the previous one and move you closer towards your vision. Your roadmap should be convincing and realistic: Don’t speculate or oversell your [project]. Be clear who your audience is: An internal roadmap talks to development, marketing, sales, service, and the other groups involved in making your [project] a success; and external one talks to existing and prospective customers."
Extracted from : "[[http://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/ 10 Tips for Creating an Agile Product Roadmap]]"

* Start defining a development, documentation and marketing plan for your project. Set short , medium and long term plans. Include promotion of your project, this is very important in order to engage users and consumers of your project. Contact project coordinator and the Project Task Force to help you achieve this goal. You ''can'' run a single person project, but it's usually best to get the community involved. You should be prepared to support a mailing list, build a team, speak at conferences, and promote your project.

* You can contribute existing documents or tools to OWASP! Assuming you have the intellectual property rights to a work, you can open it to the world as an OWASP Project. Please coordinate this with OWASP by contacting owasp(at)owasp.org.

* Available Grants to consider if you need funding - [[Grants|Click Here]]

* You should promote your project through the OWASP channels as well as by outside means. Get people to blog about it!

== '''Creating a New Project''' ==
Once you have passed the Project Ideas phase, then you will be ready to start a new project

'''[https://www.tfaforms.com/263506 Please submit a new project application here].''''''

'''2016 OWASP Project Process'''

'''Existing WORKFLOW''' [https://docs.google.com/viewer?a=v&pid=forums&srcid=MDM4NTc0NDY0NjkwMzEwMTMzMzkBMDIxODM3MDc5ODA4OTMxNjAzNjkBSFlWTDZaTE5Ed0FKATAuMQFvd2FzcC5vcmcBdjI Incubator Project Flow]

'''Step 1:'''
New Project Leader submits New Project Request Form it is logged in the system and an alert is sent to the Project Coordinator

'''Step 2:'''
New Project Request is received and reviewed by Project Coordinator for complete information .It must contain the following information to qualify as an acceptable submission:
You will need to gather the following information together for your application:

*Project Name,
*Project purpose / overview,
*Project Roadmap,
*Project links (if any) to external sites,
*[[Guidelines_for_OWASP_Projects#Project_Licensing|Project License],]
*Project Leader name,
*Project Leader email address,
*Project Leader wiki account - the username (you'll need this to edit the wiki),
*Project Contributor(s) (if any) - name email and wiki account (if any),
*Project Main Links (if any).
*==>For Documentation: A table of Contents
*==>For Code: A prototype hosted in an open source repository of your choice.

'''Step 3:'''
If all information is completed following the minimum criteria for Projects (Code/Tool/documentation), The Project Coordinator notifies the Project Leader that the request has been accepted, and at the same time notifies the Review team that a new project has been submitted, including all the information requested in the project criteria

'''Step 4:'''
Project Coordinator proceeds to create a new Wiki page for the project including all the information sent by the project leader. project coordinator uses one of these project wiki template:
*For Docs: https://www.owasp.org/index.php/OWASP_Documentation_Project_Template
*For Code: https://www.owasp.org/index.php/OWASP_Code_Project_Template
*For Tool: https://www.owasp.org/index.php/OWASP_Tool_Project_Template
Also Project coordinator creates a mailing list for the project leader and sets him as admin

'''Step 5:'''
Project Coordinator notifies project leader and Review team about the created wiki page, providing the link to the wiki page.
*Review team might provide comments for further improvement of the wiki page if necessary
*Project leader should request a wiki account to be able to update his own wiki page afterwards if he has not one yet

'''Step 6:'''
Project coordinator updates the Wiki project inventory, Dashboard and open hub with the information regarding the new created project

'''Step 7:'''
Project is set in the agenda by the Project Coordinator for monitoring over the next 3 months to check how has been developing.

'''Step 8:'''
Every 3 months, project coordinator monitors the activity on the wiki page for new updates and on the Openhub for commits and level of activity . Findings are then reported on the Dashboard as comments and CC through email to the review team

'''Step 9:'''
if the project has not been updated and has no activities after six months of creation, project coordinator sends an email to the project leader requesting an update and status to see how has been developing, CC: project review team regarding the lack of activity .Findings are then updated on the dashboard.

'''Step 10:'''
Over the next 6 months the project is monitored again for activity. If no updates have occurred since its inception after 12 months, project is then set as inactive and project leader and review team is notified about the status.
Project coordinators updates :
* Wiki page of the project is labeled as 'inactive' (inactive banner)
*The Project is set under the 'inactive category'
*Dashboard is updated with comments and set as inactive

<hr>

'''Reference Material'''

[https://www.openhub.net/orgs/OWASP Openhub]

[https://docs.google.com/spreadsheets/d/1lO8UoQgIFET3MC5v2OVVdtkTe1IbWiJLMnINx6Hm2jE/edit?ts=56a159b7#gid=0 Dashboard]

[[Project_Reviews_Guideline|Project Review Guidelines]]

[http://owasp.github.io/ProjectReviews/index.html GITHUB OWASP]

[https://docs.google.com/presentation/d/1tGdmgzDGjoHVtHZbV9dqGR2XQVlT8TR1cet-4r0C8RY/edit?ts=56a16be2#slide=id.gee0716e2f_0_1 Projects Slides]

* Check out the '''[[Guidelines for OWASP Projects]]'''.
* [[Grant_Spending_Policy|Grant Spending Policy]]
* [[Project_Spending_Policy|Project Spending Policy]]
* [[Project_Sponsorship_Operational_Guidelines|Project Sponsorship Operational Guidelines]]

==OWASP Recommended Licenses==

{{Recommended_Licenses}}

==Funding your Project==
An OWASP project does not receive any funding for development at project inception; however, a new project does have the opportunity to submit a request to receive funds if they are available for the year. Additionally, project leaders have the option of seeking sponsorship from outside organizations, but project leaders are required to seek funding through their own initiative. Please contact the OWASP Projects Manager for more information.

== Project Release ==

As your project reaches a point that you'd like OWASP to assist in its promotion, the will need the following information to help spread the word about your project:

# Short 5 sentence paragraph outlining what your project is about, what you hope to accomplish with your project, what value your project brings to software security, and contributor and project leader names and contact information.
# Link to your wiki page.
# Link to your code repository or a link to where readers can download your project.
# Latest Release description answering the following questions: What is it?, What does it do?, Where can I get it?, Who should I contact if something goes wrong?.

==Project Process Forms==
These forms were created to help project leaders, and those interested in a going through a process in the OWASP projects infrastructure. They facilitate the management of each query based on the specific task an applicant will need help with. The forms are described below, and they are linked with their designated online application form.

* [https://www.tfaforms.com/264422 Project Transition Application]:The OWASP project transition form gives current project leaders an easy way of handing over project administration information to individuals wishing to take over a project.

* [https://www.tfaforms.com/264413 Project Review Application]:This form is for current project leaders to request a review of their project based on OWASP graduation criteria. The aim is to designate an OWASP volunteer to review these projects within 3 months time.

* [http://www.tfaforms.com/264418 Project Donation Application]:This form is for projects outside of the OWASP project infrastructure. Project Leaders for these open source projects can choose to partner or give their project to OWASP directly through this form.

* [https://www.tfaforms.com/264428 Project Adoption Request]:This form is used when someone is interested in adopting an archived project.

* [https://www.tfaforms.com/264426 Project Abandonment Request]:The OWASP project abandonment form gives current project leaders an easy way of letting the OWASP Foundation know that they wish to resign their project leader duties. This form should be used when no replacement project leader exists to take over these duties.

* [https://www.tfaforms.com/264392 Incubator Project Graduation Application]:This application form is for Incubator Projects to apply for Labs Project status.

= Participating in a Project =


== Joining a Project... ==

OWASP projects are community driven and most projects are open for anyone motivated to join.

The first step is to find a project you are interested to be part of. The list of all projects can be found in the {{#switchtablink:Project_Inventory|Project Inventory}}. Further steps then depend on the status of the project you selected.

If the project is active, the best way is to join the mailing list and get in touch with the people actively participating. Other ways would be contacting the project leader team or just starting to participate by testing the software, writing blogs or documentation, report issues via tracker or even propose code modifications. In general, the more you show your interest and motivation, the easier it is to find yourself as a member of the team.

Some projects are of low activity or even inactive. In this case there is no possibility to join an existing team, but it would rather be a re-boot. If you feel eager to do this, please contact the general OWASP administrators. It is however important that you are sure about the commitment you are about to make.

Some things are important:

- Don’t be shy. If you wish to be part of the OWASP initiative, you will find a task that suits your experience and your level of possible time investment.

- Baby steps are easier than huge commitments. Just start helping with small tasks and get known by the project team. You will grow into the project in a natural way.

Please read more about the general project workflow on the {{#switchtablink:Starting_a_New_Project|Starting a New Project}} page.

== Archives ==

[[Projects_Reboot_2012_Homepage|Archive of the 'Project Reboot 2012' page]]

= Project Assessments =

==OWASP Project Lifecycle==
The OWASP Projects Lifecycle represents a balance between keeping a very loose structure around OWASP projects, and ensuring that OWASP consumers are not confused about a project’s maturity and quality. The lifecycle stage allows consumers to easily identify mature projects, and projects that are proofs of concept, experimental, and classified as prototypes in their current state. The greater the maturity of the project, the greater the level of responsibility for the project leader. These responsibilities are not trivial as OWASP provides incentives and benefits (Section 7) for projects who take on these added responsibilities.

====The OWASP Project Lifecycle is broken down into the following stages:====

'''Incubator Projects''': OWASP Incubator projects represent the experimental playground where projects are still being designed, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity; moreover, the label allows project leaders to leverage the OWASP name while their project is still maturing. OWASP Incubator projects are given a place on the OWASP Projects Portal to leverage the organizations' infrastructure, and establish their presence and project history.

'''Lab Projects''': OWASP Labs projects represent projects that have produced a deliverable of significant value. Leaders of OWASP Labs projects are expected to stand behind the quality of their projects as these projects have matured to the point where they are accepted by a significant portion of the OWASP community. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are ready for mainstream usage. OWASP Labs Projects are meant to be the collection of established projects that have gained community support and acclaim by undergoing the project review process.

'''Flagship Projects''': The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole. Eligible projects are selected from the OWASP Labs project pool. This selection process generally ensures that there is only one project of each type covering any particular security space. OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining. The core mission of OWASP is to make application security visible and so as an organization, OWASP has a vested interest in the success of its Flagship projects. Since Flagship projects have such high visibility, these projects are expected to uphold the most stringent requirements of all OWASP Projects.

'''Code Projects''': OWASP code projects are very important for the cyber security solutions. Because these projects are used to find out the application security problems and try to solve those problems.

== OWASP Project Stage Benefits==
This section outlines the benefits of starting an OWASP project, and the benefits of being at each different stage in the projects lifecycle. In my short time here at OWASP as the PM, I have had several potential project leaders ask me what the benefits are of starting their project with OWASP. Below is my proposal for each Stage’s benefits.

'''Incubator'''
* Financial Donation Management Assistance
* Project Review Support
* WASPY Awards Nominations
* OWASP OSS and OPT Participation
* Opportunity to submit proposal: $500 for Development.
* Community Engagement and Support
* Recognition and visibility of being associated with the OWASP Brand.

'''Labs'''
* All benefits given to Incubator Projects
* Technical Writing Support
* Graphic Design Support
* Project Promotion Support
* OWASP OSS and OPT: Preference

'''Flagship'''
* All benefits given to Incubator & Labs Projects
* Grant finding and proposal writing help
* Yearly marketing plan development
* OWASP OSS and OPT participation preference

For more detailed information on OWASP Project Stage Benefits, please see the Project Handbook.

== Project Monitoring Incubator/Documentation ==
Every 6 months, a project monitoring assessment takes place to evaluate if projects had any releases during this period.A warning will be sent to projects without any activity in 90 days and after 180 days, the project will be set automatically as inactive.
You can set your project active at any time, as long as:
* There has been commits to the project's open repository or
* There has been a beta release of the documentation produced so far or
* Provide a detailed Roadmap

===Importance of a well thought out Roadmap===
Many Incubator project leaders struggle with creating a realistic planning, which should be based on their available resources and time. A well thought out plan makes a difference between a procrastinating project and a successful one. The important aspect of this is, that the project leader is able to create a plan based on his situation. The following is an example of a Roadmap, which has focused to produce a Documentation first release in a year and a basic outline how they plan to cover 4 essential aspects which are Research & Development, Marketing, Planning and Goals.

[[File:RoadmapIncubatorProjectExample2.PNG | 600px]]

"Your [project] roadmap should tell a coherent story about the likely growth of your product. Each release should build on the previous one and move you closer towards your vision. Your roadmap should be convincing and realistic: Don’t speculate or oversell your [project]. Be clear who your audience is: An internal roadmap talks to development, marketing, sales, service, and the other groups involved in making your [project] a success; and external one talks to existing and prospective customers."
Extracted from : "[[http://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/ 10 Tips for Creating an Agile Product Roadmap]]"

==Project Monitoring for LABS/Flagship==
These project represent the best OWASP has to offer, therefore monitoring of these projects is closely supervised.
===For Code and Tools===
For projects holding Flagship status, we closely monitor their health every 6 months on the following, among other key indicators:
*Can the project be built correctly?
*Does the project has any activity(commits) in the last 6 months?
*Does the project had any releases in the last 6 months?
*Has the project leaders updated his wiki or website to reflect latest releases?
===For Documentation===
For this part, we are working on the development of an adequate assessment criteria
The following is a draft of the new process proposal: [[:File:Qualitative_and_Quantitative_Content_Audit.pdf|Proposal for Reviewing OWASP Document projects]]

== OWASP Project Graduation==
The Project Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs. In order to be considered for OWASP Labs, an Incubator project must have submitted an OWASP reviewed deliverable, and obtained at least two (2) positive responses for each of the core criteria project health questions.

The review centers around the following core questions. Each core question has three (3) specific questions made up of binary queries. A project must receive at least two (2) positive responses from each reviewer in two of the binary questions, to warrant a postive response for the core question. Each core question must receive a positive response from both project reviewers to pass the Project Health Assessment for Incubator Projects.

* [https://docs.google.com/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE Project Graduation Criteria Checklist]

==OWASP Project Health Assessment==
The Project Health Assessment is an optional process undertaken at the request of a project leader when he/she applies for Project Graduation for projects going from Incubator to LAB and from LAB to Flagship. The purpose of this assessment is to determine whether a project meets the minimum criteria of an OWASP Project outlined in the [https://docs.google.com/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE Project Health Assessment Criteria Document]. If a project passes the assessment, it then becomes eligible to graduate into the OWASP Labs Project stage. In order to be considered for OWASP Labs, an Incubator project must have submitted an OWASP reviewed deliverable, and obtained at least two (2) positive responses for each of the core criteria project health questions.

==OWASP Project Deliverable/Release Assessment==
The Project Deliverable/Release Review is an optional process undertaken at the request of a project leader using the Project Deliverable Review Form. The purpose of this process is to review a project’s progress, and to make sure the project is heading in the right direction based on the roadmap they provided at project inception.

Reviews must be performed by two (2) OWASP Chapter or Project Leaders, and their review must answer affirmatively to at least the first two (2) core Project Deliverable/Release Review questions. A project must pass the OWASP Project Deliverable/Release Assessment in order to graduate into the OWASP Labs Project stage.

* [https://docs.google.com/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE Project Deliverable/Release Assessment Criteria Checklist]

= Brand Resources =


==The Brand Usage Rules==
See OWASP's [[Marketing/Resources#tab=BRAND_GUIDELINES|The Brand Usage Rules]] for details.

==Project Icons & Templates==
See OWASP'S [[Marketing/Resources#PROJECT_RESOURCES|Project Icons & Templates]] for details.

(Following links and images are provided for a quick overview only, the primary page is [[Marketing/Resources#PROJECT_RESOURCES|Project Icons & Templates]]).

If you require more assistance with these files and/or templates, please contact the OWASP staff for assistance

'''[[OWASP_Operations_Project_Template|OWASP Operational Wiki Template]]'''

'''[[OWASP_Documentation_Project_Template|OWASP Example Template: DO NOT EDIT]]'''

[[Image:OWASP_Project_Header.jpg|Owasp logo|500px]]

[[Image:Project_Type_Files_TOOL.jpg|Owasp logo|200px]] [[Image:Project_Type_Files_DOC.jpg||Owasp logo 1c|200px]]

[[Image:Project_Type_Files_CODE.jpg|Owasp logo|200px]] [[Image:Owasp-defenders-small.png|Owasp logo|100px]] [[Image:Owasp-builders-small.png|Owasp logo|100px]] [[Image:Owasp-breakers-small.png|Owasp logo|100px]]

[[Image:Owasp-incubator-trans-200.png|Owasp logo rev icon|100px]] [[Image:Owasp-labs-trans-85.png|Owasp logo flat|100px]] [[Image:Owasp-flagship-trans-85.png|Owasp logo icon|100px]]

===OpenSAMM===
'''[[Media:OpenSAMM_icons.zip|OpenSAMM Icons]]'''

'''Construction:'''

[[Image:Construction black.png| Construction black| 100px]] [[Image:Construction blue.png| Construction blue| 100px]] [[image:Construction olive.png |construction olive|100px]]

'''Deployment:'''

[[image:Deployment black.png| Deployment black| 100px]] [[image:Deployment blue.png| Deployment blue| 100px]] [[image:Deployment olive.png | Deployment olive| 100px]]

'''Governance:'''

[[image:Governance black.png| governance black| 100px]] [[image:Governance blue.png | governance blue | 100px]] [[image:Governance olive.png | governance olive| 100px]]

'''Verification:'''

[[image:Verification black.png | Verification black | 100px]] [[image:Verification blue.png | verification blue | 100px]] [[image: Verification olive.png | Verification olive | 100px]]

==Book Cover Files==
See OWASP's [[Marketing/Resources#PROJECT_RESOURCES|Project Icons & Templates]] for details.

[[Media:Lulu-guide.pdf|Lulu Guide]]

'''[https://www.dropbox.com/s/h27gsbe5m7idg0y/Finished%20Covers.zip Download the Book Cover Zip File]'''
{|
|-
! width="500" align="center" | 
! width="300" align="center" | 
|-
| align="center" | [[Image:BookImage_01.jpg‎|500px| link=https://www.dropbox.com/s/h27gsbe5m7idg0y/Finished%20Covers.zip]]
| align="center" |

|}

= Terminology =

== OWASP Project Infrastructure ==

*'''OWASP Project Lifecycle:''' The OWASP Projects Lifecycle represents a balance between keeping a very loose structure around OWASP projects, and ensuring that OWASP consumers are not confused about a project’s maturity and quality. The lifecycle stage allows consumers to easily identify mature projects, and projects that are proofs of concept, experimental, and classified as prototypes in their current state.

*'''Incubator Project:''' OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.

*'''Labs Project:''' OWASP Labs projects represent projects that have produced a deliverable of value. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.

*'''Flagship Project:''' The OWASP Flagship designation is given to projects that have demonstrated strategic value to OWASP and application security as a whole.

*'''Project Benefits:''' The standard list of resources and incentives made available to project leaders based on their project's current maturity level.

== OWASP Project Reviews ==

*'''Project Reviews:''' Project reviews are the method OWASP uses to establish a minimal baseline of project characteristics and release quality. Reviews are not mandatory, but they are necessary if a project leader wishes to graduate to the next level of maturity within the OWASP Global Projects infrastructure. Projects can be reviewed when an Incubator project wishes to graduate into the OWASP Labs designation, and project releases can be reviewed if they want the quality of their deliverable to be vouched for by OWASP.

*'''Project Reviewer Pool:''' The project reviewer pool is made up of veteran reviewers who have proven themselves dedicated to executing quality reviews of projects.

*'''Project Graduation:''' The Project Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs.

*'''Project Health Assessment:''' The Project Health Assessment is an optional process undertaken at the request of a project leader when he/she applies for Project Graduation The purpose of this assessment is to determine whether a project meets the minimum criteria of an OWASP Project outlined in the [https://docs.google.com/a/owasp.org/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE#gid=1 Project Health Assessment Criteria Document].

*'''Project Release:''' A project release refers to the final deliverable a project produces. It is the final product of the project.

*'''Project Deliverable/Release Review:''' The Project Deliverable/Release Review is an optional process undertaken at the request of a project leader using the Project Deliverable Review Form. The purpose of this process is to review a project’s progress, and to make sure the project is heading in the right direction based on the roadmap they provided at project inception.

== OWASP Projects Processes ==

*'''Project Processes:''' The set of streamlined processes that exist to help projects move smoothly through the OWASP Project Lifecycle.

*'''Project Inception Process:''' The Project Inception Process is how a brand new idea becomes an OWASP Project. Such projects are labeled as OWASP Incubator projects. The process involves submitting the proposed project name, project leader information, project description, project roadmap, and selecting an appropriate open-source license for the project using the New Project Form on the Projects Portal.

*'''Project Donation Process:''' The Project Donation Process is used for a project that has an existing functional release, but is not currently associated with OWASP. This process is the primary mechanism by which individuals or organizations can transfer the ownership of their project’s copyright to OWASP.

*'''Project Transition Process:''' The Project Transition Process is used to transition leadership of a project to a new project leader. This is a simple automated process to transfer the relevant accounts, mailing lists, and other project resources to the new project leader.

*'''Project Abandonment Process:''' The Project Abandonment Process was put in place for those occasions in which a project leader is no longer able to manage their project, and has not been able to find a suitable replacement for the leader role. Project Abandonment can also occur when the project leader feels his/her project has become obsolete. Under these circumstances, the acting project leader is encourage do submit the Project Abandonment Form found in the Projects Portal.

*'''Incubator Graduation Process:''' The Incubator Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs.

== Projects at Conferences ==

*'''AppSec Conferences:''' OWASP AppSec conferences bring together industry, government, security researchers, and practitioners to discuss the state of the art in application security. This series was launched in the United States in 2004 and Europe in 2005. Global AppSec conferences are held annually in North America, Latin America, Europe, and Asia Pacific.

*'''Open Source Showcase:''' The Open Source Showcase is an OWASP AppSec Conference event module designed to give Open Source project leaders the opportunity to demo their projects.

*'''OWASP Project Track:''' The OWASP Project Track is an OWASP AppSec Conference event module designed to give OWASP Project leaders the opportunity to showcase their projects as an official conference presenter.

== OWASP Projects General ==

*'''OWASP Code of Ethics:''' The OWASP Code of Ethics are the set of guidelines and principles that the OWASP Foundation expects all of its members and conference attendees to abide by. A copy of the Code of Ethics can be found here in the [[About_The_Open_Web_Application_Security_Project#Code_of_Ethics|OWASP About page]].

= Sponsorships and Donations =


==Donate to OWASP Global Projects ==
OWASP Projects, a global division of the OWASP Foundation, is run under the same world wide not-for-profit charitable status as all the foundation strategic groups. OWASP provides a platform for contributors to share their work while providing them with the project and community support they need throughout their project development. All OWASP Projects are run by volunteers and they rely on personal donations and sponsorship to continue their development. Donate to OWASP Projects, and we promise to spend your money wisely on open source initiatives.

'''This is how your money can help:'''

* $20 could help us spread the word on the importance of open source initiatives in the Application Security industry.
* $100 could help fund OWASP project demos at major conferences.
* $250 could help get our volunteer Project Leaders to speaking engagements.

[[Image:Donate_Button.jpg | link=http://www.regonline.com/Register/Checkin.aspx?EventID=1044369]]

= Contact US =


If you need any help with anything projects related, or if you simply need some more information, please do not hesitate to [https://www.tfaforms.com/308703 Contact Us].


= Current Project Review Guidelines =


PROJECT REVIEWS RESTART November 2016

Steps for Project Graduation Review:

Process Starts when Project Leader Requests a Graduation Review this is done through a [https://www.tfaforms.com/308703| contact us form].

Project Coordinator send link to the the Project Review Form for the Project Leader to provide the assessment.

Senior Techinical Coordinator reviews the assessment received and works with the Project Leader if there are any questions. Once reviewed the assessment is passed to the Project Coordinator..

Project Coordinator Reviews the request and adds to the Volunteer Job Board for outreach to the community - http://owasp.force.com/volunteers/GW_Volunteers__Volunteerhttps://www.tfaforms.com/393806sJobListing
Once volunteer signs up and chooses a project review then the Project Coordinator sends the link to the Volunteer with instructions to the google doc for the Project Review (Sample DOC)

There will need to be at least two reviewers for each Project Review along with the Senior Technical Coordinator to finalize the results.

Senior Technical Coordinator could process a review if the there is lack of reviewers.

Senior Technical Coordinator/Volunteers has about 2-4 weeks to complete the Project Review .

Senior Technical/ Volunteer works with the Project Leader on any information or questions.

The time to complete can be extended to up to a an additional week.

Senior Technical Coordinator provides recommendations.

Project Coordinator sends Project Review to the community for feedback.

Community Leaders can also process a review if they choose to disagree with the review.

Project Graduation is announced by Connector and other social media

Current OWASP Project Review Guidelines Link below:
[[Project Reviews Guideline]]

<headertabs />

Category:OWASP ModSecurity Core Rule Set Project

2016-02-22T21:16:27Z

Rcbarnett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Chaim_sanders Chaim Sanders]

Contributors:
*[[:User:Rcbarnett|Ryan Barnett]] 
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
== Project Leader ==

[[:User:Rcbarnett|Ryan Barnett]]

== Project Contributors ==

 
[[:User:Chaim_Sanders|Chaim Sanders]] 
[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
[[:User:Brian_Rectanus|Brian Rectanus]] 
[[:user:Roberto_Salgado|Roberto Salgado]] 
Nick Galbreath

== Project Users ==

OWASP/WASC Distributed Web Honeypot Project uses the Core Rule Set -
https://www.owasp.org/index.php/OWASP_WASC_Distributed_Web_Honeypots_Project

cPanel distributes the OWASP CRS with their ModSecurity package -
https://documentation.cpanel.net/display/CKB/OWASP+ModSecurity+CRS

Akamai's WAF Service is based on a previous version of the Core Rule Set -
http://www.akamai.com/html/about/press/releases/2009/press_121409.html

CloudFlare's WAF uses the logic from the OWASP ModSecurity CRS -
https://www.cloudflare.com/waf
http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-lua/

Verizon/EdgeCast WAF uses ModSecurity and the OWASP ModSecurity CRS -
http://www.edgecast.com/services/security/#waf

Varnish Web Cache/Accelerator uses a converted version of the CRS -
https://github.com/comotion/security.vcl

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
 

= Road Map and Getting Involved =
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

== v3.0 Detection Concepts ==
This page documents the goals/ideas for the next major version of the CRS.

== Goals ==
These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Detection Logic/Flow Concepts ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Contribute on the mail-list by answering questions from the community
* Report issues to our GitHub Issue tracker

=Upcoming Major Release 3.0.0=

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on [https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1 github]. The release is planned for the first quarter 2016. It brings incorporation of the <tt>@detectsqli</tt> and <tt>@detectxss</tt> operators and a general reduction of false positives for default setups.

==Infos about 3.0.0==
* [https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ Blogpost comparing CRS 2.2.x with 3.0.0-dev]

===Development===

* [[OWASP_ModSec_CRS_Paranoia_Mode | Paranoia Mode / Bringing back the rules that used to yield a high number of false positives]]

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

Category:OWASP ModSecurity Core Rule Set Project

2016-02-22T21:02:13Z

Rcbarnett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Chaim_sanders Chaim Sanders]

Contributors:
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
== Project Leader ==

[[:User:Rcbarnett|Ryan Barnett]]

== Project Contributors ==

 
[[:User:Chaim_Sanders|Chaim Sanders]] 
[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
[[:User:Brian_Rectanus|Brian Rectanus]] 
[[:user:Roberto_Salgado|Roberto Salgado]] 
Nick Galbreath

== Project Users ==

OWASP/WASC Distributed Web Honeypot Project uses the Core Rule Set -
https://www.owasp.org/index.php/OWASP_WASC_Distributed_Web_Honeypots_Project

cPanel distributes the OWASP CRS with their ModSecurity package -
https://documentation.cpanel.net/display/CKB/OWASP+ModSecurity+CRS

Akamai's WAF Service is based on a previous version of the Core Rule Set -
http://www.akamai.com/html/about/press/releases/2009/press_121409.html

CloudFlare's WAF uses the logic from the OWASP ModSecurity CRS -
https://www.cloudflare.com/waf
http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-lua/

Verizon/EdgeCast WAF uses ModSecurity and the OWASP ModSecurity CRS -
http://www.edgecast.com/services/security/#waf

Varnish Web Cache/Accelerator uses a converted version of the CRS -
https://github.com/comotion/security.vcl

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
 

= Road Map and Getting Involved =
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

== v3.0 Detection Concepts ==
This page documents the goals/ideas for the next major version of the CRS.

== Goals ==
These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Detection Logic/Flow Concepts ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Contribute on the mail-list by answering questions from the community
* Report issues to our GitHub Issue tracker

=Upcoming Major Release 3.0.0=

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on [https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1 github]. The release is planned for the first quarter 2016. It brings incorporation of the <tt>@detectsqli</tt> and <tt>@detectxss</tt> operators and a general reduction of false positives for default setups.

==Infos about 3.0.0==
* [https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ Blogpost comparing CRS 2.2.x with 3.0.0-dev]

===Development===

* [[OWASP_ModSec_CRS_Paranoia_Mode | Paranoia Mode / Bringing back the rules that used to yield a high number of false positives]]

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

Projects/OWASP ModSecurity Core Rule Set Project

2016-02-22T21:01:01Z

Rcbarnett:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ModSecurity Core Rule Set Project
| project_home_page = :Category:OWASP ModSecurity Core Rule Set Project

| project_description =
[http://www.modsecurity.org/ ModSecurity] is an Apache web server module that provides a web application firewall engine. The ModSecurity Rules Language engine is extrememly flexible and robust and has been referred to as the "Swiss Army Knife of web application firewalls." While this is certainly true, it doesn't do much implicitly on its own and requires rules to tell it what to do. In order to enable users to take full advantage of ModSecurity out of the box, we have developed the Core Rule Set (CRS) which provides critical protections against attacks across most every web architecture.

Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the CRS is based on generic rules which focus on attack payload identification in order to provide protection from zero day and unknown vulnerabilities often found in web applications, which are in most cases custom coded.

| project_license = [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License v2 (ASLv2)]

| leader_name1 = Chaim Sanders
| leader_email1 = CSanders@trustwave.com
| leader_username1 = Chaim_sanders

| contributor_name1 =
| contributor_email1 =
| contributor_username1 =

| pamphlet_link =

| presentation_link = http://www.owasp.org/images/b/b3/OWASP_ModSecurity_Core_Rule_Set.ppt

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

| project_road_map = http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project_-_Roadmap

| links_url1 = https://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/
| links_name1 = ModSecurity on SourceForge
| links_url2 = https://www.modsecurity.org/tracker/browse/CORERULES
| links_name2 = Bug Tracker
| links_url3 = http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project#tab=Installation
| links_name3 = Installation
| links_url4 = http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project#tab=Documentation
| links_name4 = Documentation
| links_url5 = http://www.owasp.org/index.php/File:OWASP_ModSecurity_Core_Rule_Set.ppt
| links_name5 = PPT Presentation
| links_url6 = https://www.owasp.org/images/0/07/OWASP6thAppSec_ModSecurityCoreRuleSet_OferShezaf.pdf
| links_name6 = PDF Withepaper

| release_1 = ModSecurity 2.0.6
| release_2 = ModSecurity 2.0.10
| release_3 = ModSecurity 2.0.12
| release_4 = ModSecurity 2.1.2
| release_5 =

| project_about_page = Projects/OWASP ModSecurity Core Rule Set Project
}}

User:Rcbarnett

2015-11-06T15:09:17Z

Rcbarnett:

* BIO: Ryan Barnet, Akamai's Threat Research Team - To see my wiki contributions, [[:Special:Contributions/Rcbarnett|click here]].

Ryan Barnett is a Principal Security Researcher working on the Akamai Threat Research Team supporting the Cloud Security Business Unit (including the Kona WAF product). In addition to his primary work at Akamai, he is also a WASC Board Member and OWASP Project Leader for: Web Hacking Incident Database (WHID), Distributed Web Honeypots and a contributor to OWASP AppSensor. Mr. Barnett has also authored two web security books: Preventing Web Attacks with Apache (Pearson) and The Web Application Defender's Cookbook: Battling Hackers and Defending Users (Wiley).

Specialties: Web Application Security, Web Application Firewalls, Intrusion Detection, Forensics and Honeypot technologies.

* Ryan can be reached at: ryan.barnett(at)owasp.org or rbarnett(at)akamai.com

Defenders

2015-11-06T15:06:07Z

Rcbarnett:

==== OWASP Defenders ====

{| width="100%"
|- valign="top"
|
'''Defenders Community'''

A community of security professionals and stakeholders with the common goal of advancing the state of security in the area of application defense, including the tools and techniques that enable the detection and response to application layer attacks.

 '''Examples'''

AppSensor, ModSecurity, Real Time Log Analysis, Application Trending Techniques

 '''Target Audience'''

Application Security Professionals, Infrastructure Security Teams, Developers looking to integrate defensive technologies

 '''What Are OWASP Communities?'''

[http://www.owasp.org/index.php/Builders Builders], [http://www.owasp.org/index.php/Breakers Breakers] and Defenders; the idea of OWASP Communities is to bring together experts in the area that they are best at with the common goal of advancing the state of application security. This approach allows similar groups of professionals and experts to tackle security problems with the involvement of the most relevant stakeholders. The intent is to drive high quality output that is immediately usable by the target audience. More information about this vision can be found [http://michael-coates.blogspot.com/2011/02/vision-for-owasp.html here]

|
[[Image:OWASP-vision.jpg]]

|}

==== The Community ====

      

{| cellspacing="1" cellpadding="1" style="width: 404px; height: 413px;"
|-
| [[Image:MichaelCoates-OWASP.jpg|100px]] 
| '''Michael Coates''' Shape Security michael.coates@owasp.org http://michael-coates.blogspot.com @_mwc
|
|
|-
| [[Image:JohnMelton-OWASP.jpg|100px]] 
| '''John Melton''' White Hat Security john.melton@owasp.org http://www.jtmelton.com 
|
|
|-
| [[Image:IvanRistic-OWASP.jpg|100px]] 
| '''Ivan Ristic''' Qualys ivanr@webkreator.com http://blog.ivanristic.com/ @ivanristic
|
|
|-
| [[Image:ColinWatson-OWASP.jpg|100px]] 
| '''Colin Watson''' Watson Hall Ltd. colin.watson@owasp.org http://www.clerkendweller.com @clerkendweller
|
|
|-
| [[Image:RyanBarnett-OWASP.jpg|100px]] 
| '''Ryan Barnett''' Akamai ryan.barnett@owasp.org http://tacticalwebappsec.blogspot.com/ @ryancbarnett
|
|
|-
| [[Image:LucasFerreira-OWASP.jpg|100px]] 
| '''Lucas C. Ferreira''' Câmara dos Deputados (Brazilian Chamber of Deputies) lucas.ferreira@owasp.org http://blog.sapao.net @lucassapao
|
|
|-
| [[Image:PrzemyslawSkowron-OWASP.jpg|100px]] 
| '''Przemyslaw Skowron''' Alior Bank S.A. przemyslaw.skowron@owasp.org - -
|
|
|-
|  
| '''Chen King'''      
|
|
|-
|  
| '''Fernando A. Damião'''      
|
|
|-
|  
| '''Yvan Boily''' yvanboily@gmail.com @ygjb  
|
|
|-
|  
| '''Josh Amishav-Zlatin''' jamuse@gmail.com @jamuse  
|

|}

Want to contribute to the OWASP Defenders Community? Add your info and send an email to [mailto:michael.coates@owasp.org michael.coates@owasp.org]
 

==== Roadmap ====
* Determine the current market need. This requires involvement from people in enterprise that are tacking these problems. No guessing about what we think people need.
* Evaluate current OWASP projects to understand match with market need and quality of projects
* Identify 3-4 projects that will be focused on for growth and promotion
* Archive other projects (within defender domain) that are abandoned or not inline with market need
* Cross training - We should all be able to help out to advance our 3-4 core projects
* Significantly advance quality of selected projects
* Community outreach for adoption
* High quality marketing efforts
* Conference presentations across multiple projects

==== Official Defender Projects ====

To be determined - see roadmap

==== All Defender Related Projects ====
All projects that are related to the OWASP Defenders community can be found at the following link: [[:Category:OWASP_Defenders]]

__NOTOC__ <headertabs />

Virtual Patching Cheat Sheet

2015-11-05T21:23:34Z

Rcbarnett:

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

The goal with this cheat Sheet is to present a concise virtual patching framework that organizations can follow to maximize the timely implementation of mitigation protections.

= Definition: Virtual Patching =

'''''A security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability.'''''

The virtual patch works when the security enforcement layer analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the web application. The resulting impact of virtual patching is that, while the actual source code of the application itself has not been modified, the exploitation attempt does not succeed.

= Why Not Just Fix the Code? =

From a purely technical perspective, the number one remediation strategy would be for an organization to correct the identified vulnerability within the source code of the web application. This concept is universally agreed upon by both web application security experts and system owners. Unfortunately, in real world business situations, there arise many scenarios where updating the source code of a web application is not easy such as:
* '''Lack of resources''' - Devs are already allocated to other projects.
* '''3rd Party Software''' - Code can not be modified by the user.
* '''Outsourced App Dev''' - Changes would require a new project.

The important point is this - '''Code level fixes and Virtual Patching are NOT mutually exclusive'''. They are processes that are executed by different team (OWASP Builders/Devs vs. OWASP Defenders/OpSec) and can be run in tandem.

= Value of Virtual Patching =
The two main goals of Virtual Patching are:
* '''Minimize Time-to-Fix''' - Fixing application source code takes time. The main purpose of a virtual patch is to implement a mitigation for the identified vulnerability as soon as possible. The urgency of this response may be different: for example if the vulnerability was identified in-house through code reviews or penetration testing vs. finding a vulnerability as part of live incident response.

* '''Attack Surface Reduction''' - Focus on minimizing the attack vector. In some cases, such as missing positive security input validation, it is possible to achieve 100% attack surface reduction. In other cases, such with missing output encoding for XSS flaws, you may only be able to limit the exposures. Keep in mind - 50% reduction in 10 minutes is better than 100% reduction in 48 hrs.

= Virtual Patching Tools =
Notice that the definition above did not list any specific tool as there are a number of different options that may be used for virtual patching efforts such as:
* Intermediary devices such as a WAF or IPS appliance
* Web server plugin such as ModSecurity
* Application layer filter such as ESAPI WAF

For example purposes, we will show virtual patching examples using the open source ModSecurity WAF tool - http://www.modsecurity.org/.

= A Virtual Patching Methodology =
Virtual Patching, like most other security processes, is not something that should be approached haphazardly. Instead, a consistent, repeatable process should be followed that will provide the best chances of success. The following virtual patching workflow mimics the industry accepted practice for conducting IT Incident Response and consists of the following phases:
* Preparation
* Identification
* Analysis
* Virtual Patch Creation
* Implementation/Testing
* Recovery/Follow Up.

= Example Public Vulnerability =
Let's take the following SQL Injection vulnerability as our example for the remainder of the article - http://www.osvdb.org/show/osvdb/88856

'''''88856 : WordPress Shopping Cart Plugin for WordPress /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php reqID Parameter SQL Injection'''''

'''''Description''': WordPress Shopping Cart Plugin for WordPress contains a flaw that may allow an attacker to carry out an SQL injection attack. The issue is due to the /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php script not properly sanitizing user-supplied input to the 'reqID' parameter. This may allow an attacker to inject or manipulate SQL queries in the back-end database, allowing for the manipulation or disclosure of arbitrary data.''

= Preparation Phase =
The importance of properly utilizing the preparation phase with regards to virtual patching cannot be overstated. You need to do a number of things to setup the virtual patching processes and framework '''''prior''''' to actually having to deal with an identified vulnerability, or worse yet, react to a live web application intrusion. The point is that during a live compromise is not the ideal time to be proposing installation of a web application firewall and the concept of a virtual patch. Tension is high during real incidents and time is of the essence, so lay the foundation of virtual patching when the waters are calm and get everything in place and ready to go when an incident does occur.

Here are a few critical items that should be addressed during the preparation phase:
* '''Public/Vendor Vulnerability Monitoring''' - Ensure that you are signed up for all vendor alert mail-lists for commercial software that you are using. This will ensure that you will be notified in the event that the vendor releases vulnerability information and patching data.
* '''Virtual Patching Pre-Authorization''' – Virtual Patches need to be implemented quickly so the normal governance processes and authorizations steps for standard software patches need to be expedited. Since virtual patches are not actually modifying source code, they do not require the same amount of regression testing as normal software patches. Categorizing virtual patches in the same group as Anti-Virus updates or Network IDS signatures helps to speed up the authorization process and minimize extended testing phases.
* '''Deploy Virtual Patching Tool In Advance''' - As time is critical during incident response, it would be a poor time to have to get approvals to install new software. For instance, you can install ModSecurity WAF in embedded mode on your Apache servers, or an Apache reverse proxy server. The advantage with this deployment is that you can create fixes for non-Apache back-end servers. Even if you do not use ModSecurity under normal circumstances, it is best to have it “on deck” ready to be enabled if need be.
* '''Increase HTTP Audit Logging''' – The standard Common Log Format (CLF) utilized by most web servers does not provide adequate data for conducting proper incident response. You need to have access to the following HTTP data:
** Request URI (including QUERY_STRING)
** Full Request Headers (including Cookies)
** Full Request Body (POST payload)
** Full Response Headers
** Full Response Body

= Identification Phase =
The Identification Phase occurs when an organization becomes aware of a vulnerability within their web application. There are generally two different methods of identifying vulnerabilities: Proactive and Reactive.

== Proactive Identification ==
This occurs when an organization takes it upon themselves to assess their web security posture and conducts the following tasks:
* '''Dynamic Application Assessments''' - Whitehat attackers conduct penetration tests or automated web assessment tools are run against the live web application to identify flaws.
* '''Source code reviews''' - Whitehat attackers use manual/automated means to analyze the source code of the web application to identify flaws.
Due to the fact that custom coded web applications are unique, these proactive identification tasks are extremely important as you are not able to rely upon 3rd party vulnerability notifications.

== Reactive Identification ==
There are three main reactive methods for identifying vulnerabilities:
* '''Vendor contact (e.g. pre-warning)''' - Occurs when a vendor discloses a vulnerability for commercial web application software that you are using. Example is Microsoft's Active Protections Program (MAPP) - http://www.microsoft.com/security/msrc/collaboration/mapp.aspx
* '''Public disclosure''' - Public vulnerability disclosure for commercial/open source web application software that you are using. The threat level for public disclosure is increased as more people know about the vulnerability.
* '''Security incident''' – This is the most urgent situation as the attack is active. In these situations, remediation must be immediate.

= Analysis Phase =
Here are the recommended steps to start the analysis phase:

# '''Determine Virtual Patching Applicability''' - Virtual patching is ideally suited for injection-type flaws but may not provide an adequate level of attack surface reduction for other attack types or categories. Thorough analysis of the underlying flaw should be conducted to determine if the virtual patching tool has adequate detection logic capabilities.
# '''Utilize Bug Tracking/Ticketing System''' - Enter the vulnerability information into a bug tracking system for tracking purposes and metrics. Recommend you use ticketing systems you already use such as Jira or you may use a specialized tool such as ThreadFix - https://code.google.com/p/threadfix/.
# '''Verify the name of the vulnerability''' - This means that you need to have the proper public vulnerability identifier (such as CVE name/number) specified by the vulnerability announcement, vulnerability scan, etc. If the vulnerability is identified proactively rather than through public announcements, then you should assign your own unique identifier to each vulnerability.
# '''Designate the impact level''' - It is always important to understand the level of criticality involved with a web vulnerability. Information leakages may not be treated in the same manner as an SQL Injection issue.
# '''Specify which versions of software are impacted''' - You need to identify what versions of software are listed so that you can determine if the version(s) you have installed are affected.
# '''List what configuration is required to trigger the problem''' - Some vulnerabilities may only manifest themselves under certain configuration settings.
# '''List Proof of Concept (PoC) exploit code or payloads used during attacks/testing''' - Many vulnerability announcements have accompanying exploit code that shows how to demonstrate the vulnerability. If this data is available, make sure to download it for analysis. This will be useful later on when both developing and testing the virtual patch.

= Virtual Patch Creation Phase =
The process of creating an accurate virtual patch is bound by two main tenants:

# '''No false positives''' - Do not ever block legitimate traffic under any circumstances.
# '''No false negatives''' - Do not ever miss attacks, even when the attacker intentionally tries to evade detection.

Care should be taken to attempt to minimize either of these two rules. It may not be possible to adhere 100% to each of these goals but remember that virtual patching is about '''Risk Reduction'''. It should be understood by business owners that while you are gaining the advantage of shortening the Time-to-Fix metric, you may not be implementing a complete fix for the flaw.

== Manual Virtual Patch Creation ==

=== Positive Security (Whitelist) Virtual Patches ('''Recommended Solution''') ===
Positive security model (whitelist) is a comprehensive security mechanism that provides an independent input validation envelope to an application. The model specifies the characteristics of valid input (character set, length, etc…) and denies anything that does not conform. By defining rules for every parameter in every page in the application the application is protected by an additional security envelop independent from its code.

==== Example Whitelist ModSecurity Virtual Patch ====
In order to create a whitelist virtual patch, you must be able to verify what the normal, expected input values are. If you have implemented proper audit logging as part of the Preparation Phase, then you should be able to review audit logs to identify the format of expected input types. In this case, the "reqID" parameter is supposed to only hold integer characters so we can use this virtual patch:
<pre>
#
# Verify we only receive 1 parameter called "reqID"
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'"
SecRule &ARGS:/reqID/ "!@eq 1"

#
# Verify reqID's payload only contains integers
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"
</pre>

This virtual patch will inspect the reqID parameter value on the specified page and prevent any characters other than integers as input.
* '''Note''' - you should make sure to assign rule IDs properly and track them in the bug tracking system.

* '''Caution''': There are numerous evasion vectors when creating virtual patches. Please consult the OWASP Best Practices: Virtual Patching document for a more thorough discussion on countering evasion methods.

=== Negative Security (Blacklist) Virtual Patches ===
A negative security model (blacklist) is based on a set of rules that detect specific known attacks rather than allow only valid traffic.

==== Example Blacklist ModSecurity Virtual Patch ====
Here is the example PoC code that was supplied by the public advisory - http://packetstormsecurity.com/files/119217/WordPress-Shopping-Cart-8.1.14-Shell-Upload-SQL-Injection.html:
<pre>
http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1
</pre>

Looking at the payload, we can see that the attacker is inserting a single quote character and then adding additional SQL query logic to the end. Based on this data, we could disallow the single quote character like this:
<pre>
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
SecRule ARGS:/reqID/ "@pm '"
</pre>

=== Which Method is Better for Virtual Patching – Positive or Negative Security? ===
A virtual patch may employ either a positive or negative security model. Which one you decide to use depends on the situation and a few different considerations. For example, negative security rules can usually be implemented more quickly, however the possible evasions are more likely.

Positive security rules, only the other hand, provides better protection however it is often a manual process and thus is not scalable and difficult to maintain for large/dynamic sites. While manual positive security rules for an entire site may not be feasible, a positive security model can be selectively employed when a vulnerability alert identifies a specific location with a problem.

=== Beware of Exploit-Specific Virtual Patches ===
You want to resist the urge to take the easy road and quickly create an '''exploit-specific virtual patch'''. For instance, if an authorized penetration test identified an XSS vulnerability on a page and used the following attack payload in the report:

'''<script>alert('XSS Test')</script>'''

It would not be wise to implement a virtual patch that simply blocks that exact payload. While it may provide some immediate protection, its long term value is significantly decreased.

== Automated Virtual Patch Creation ==

Manual patch creation may become unfeasible as the number of vulnerabilities grow and automated means may become necessary. If the vulnerabilities were identified using automated tools and an XML report is available, it is possible to leverage automated processes to auto-convert this vulnerability data into virtual patches for protection systems. Three examples include:
* '''OWASP ModSecurity Core Rule Set (CRS) Scripts''' - The OWASP CRS includes scripts to auto-convert XML output from tools such as OWASP ZAP into ModSecurity Virtual Patches. Reference - http://blog.spiderlabs.com/2012/03/modsecurity-advanced-topic-of-the-week-automated-virtual-patching-using-owasp-zed-attack-proxy.html
* '''ThreadFix Virtual Patching''' - ThreadFix also includes automated processes of converting imported vulnerability XML data into virtual patches for security tools such as ModSecurity. Reference - https://code.google.com/p/threadfix/wiki/GettingStarted#Generating_WAF_Rules
* '''Direct Importing to WAF Device''' - Many commercial WAF products have the capability to import DAST tool XML report data and automatically adjust their protection profiles.

= Implementation/Testing Phase =
In order to accurately test out the newly created virtual patches, it may be necessary to use an application other than a web browser. Some useful tools are:
* Web browser
* Command line web clients such as Curl and Wget.
* Local Proxy Servers such as OWASP ZAP (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project).
* ModSecurity AuditViewer (http://www.jwall.org/web/audit/viewer.jsp) – which allows you to load a ModSecurity audit log file, manipulate it and then re-inject the data back into any web server.

== Testing Steps ==
* Implement virtual patches initially in a "Log Only" configuration to ensure that you do not block any normal user traffic (false positives).
* If the vulnerability was identified by a specific tool or assessment team - request a retest.
* If retesting fails due to evasions, then you must go back to the Analysis phase to identify how to better fix the issue.

= Recovery/Follow-Up Phase =
* '''Update Data in Ticket System''' - Although you may need to expedite the implementation of virtual patches, you should still track them in your normal Patch Management processes. This means that you should create proper change request tickets, etc… so that their existence and functionality is documented. Updating the ticket system also helps to identify "time-to-fix" metrics for different vulnerability types. Make sure to properly log the virtual patch rule ID values.

* '''Periodic Re-assessments''' - You should also have periodic re-assessments to verify if/when you can remove previous virtual patches if the web application code has been updated with the real source code fix. I have found that many people opt to keep virtual patches in place due to better identification/logging vs. application or db capabilities.

* '''Running Virtual Patch Alert Reports''' - Run reports to identify if/when any of your virtual patches have triggered. This will show value for virtual patching in relation to windows of exposure for source code time-to-fix.

= References =
* [https://www.owasp.org/index.php/Virtual_Patching_Best_Practices OWASP Virtual Patching Best Practices]
* [https://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat with ModSecurity]

= Authors and Primary Editors =

[[:User:Rcbarnett|Ryan Barnett (Main Author)]] 
[[:User:Josh Amishav-Zlatin|Josh Zlatin (Editor/Contributing Author)]] 
[[:User:dune73|Christian Folini (Review)]] 

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

[[Category:Cheatsheets]]
[[Category:OWASP Defenders]]

Category:OWASP ModSecurity Core Rule Set Project

2015-09-17T12:29:12Z

Rcbarnett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Rcbarnett Ryan Barnett]

Contributors:
* Chaim Sanders 
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
== Project Leader ==

[[:User:Rcbarnett|Ryan Barnett]]

== Project Contributors ==

Chaim Sanders 
[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
[[:User:Brian_Rectanus|Brian Rectanus]] 
[[:user:Roberto_Salgado|Roberto Salgado]] 
Nick Galbreath

== Project Users ==

OWASP/WASC Distributed Web Honeypot Project uses the Core Rule Set -
https://www.owasp.org/index.php/OWASP_WASC_Distributed_Web_Honeypots_Project

cPanel distributes the OWASP CRS with their ModSecurity package -
https://documentation.cpanel.net/display/CKB/OWASP+ModSecurity+CRS

Akamai's WAF Service is based on a previous version of the Core Rule Set -
http://www.akamai.com/html/about/press/releases/2009/press_121409.html

CloudFlare's WAF uses the logic from the OWASP ModSecurity CRS -
https://www.cloudflare.com/waf
http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-lua/

Verizon/EdgeCast WAF uses ModSecurity and the OWASP ModSecurity CRS -
http://www.edgecast.com/services/security/#waf

Varnish Web Cache/Accelerator uses a converted version of the CRS -
https://github.com/comotion/security.vcl

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
 

= Road Map and Getting Involved =
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

== v3.0 Detection Concepts ==
This page documents the goals/ideas for the next major version of the CRS.

== Goals ==
These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Detection Logic/Flow Concepts ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Contribute on the mail-list by answering questions from the community
* Report issues to our GitHub Issue tracker

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

OWASP WASC Distributed Web Honeypots Project

2015-04-06T13:59:51Z

Rcbarnett:

OWASP WASC Distributed Web Honeypots Project

2015-03-31T20:47:35Z

Rcbarnett:

OWASP WASC Distributed Web Honeypots Project

2015-03-31T20:46:06Z

Rcbarnett:

OWASP WASC Distributed Web Honeypots Project

2015-03-31T20:45:34Z

Rcbarnett:

OWASP WASC Distributed Web Honeypots Project

2015-03-31T19:51:53Z

Rcbarnett:

OWASP WASC Distributed Web Honeypots Project

2015-03-31T19:49:51Z

Rcbarnett:

Category:OWASP ModSecurity Core Rule Set Project

2015-03-31T13:52:55Z

Rcbarnett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Rcbarnett Ryan Barnett]

Contributors:
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
== Project Leader ==

[[:User:Rcbarnett|Ryan Barnett]]

== Project Contributors ==

Chaim Sanders 
[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
[[:User:Brian_Rectanus|Brian Rectanus]] 
[[:user:Roberto_Salgado|Roberto Salgado]] 
Nick Galbreath

== Project Users ==

OWASP/WASC Distributed Web Honeypot Project uses the Core Rule Set -
https://www.owasp.org/index.php/OWASP_WASC_Distributed_Web_Honeypots_Project

cPanel distributes the OWASP CRS with their ModSecurity package -
https://documentation.cpanel.net/display/CKB/OWASP+ModSecurity+CRS

Akamai's WAF Service is based on a previous version of the Core Rule Set -
http://www.akamai.com/html/about/press/releases/2009/press_121409.html

CloudFlare's WAF uses the logic from the OWASP ModSecurity CRS -
https://www.cloudflare.com/waf
http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-lua/

Verizon/EdgeCast WAF uses ModSecurity and the OWASP ModSecurity CRS -
http://www.edgecast.com/services/security/#waf

Varnish Web Cache/Accelerator uses a converted version of the CRS -
https://github.com/comotion/security.vcl

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
 

= Road Map and Getting Involved =
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

== v3.0 Detection Concepts ==
This page documents the goals/ideas for the next major version of the CRS.

== Goals ==
These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Detection Logic/Flow Concepts ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Contribute on the mail-list by answering questions from the community
* Report issues to our GitHub Issue tracker

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP Top 10/Mapping to WHID

2015-03-12T19:50:46Z

Rcbarnett:

Here is a mapping of the [[https://www.owasp.org/index.php/Top_10_2013 | OWASP Top 10 - 2013]] to example real world entries in the [https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project OWASP/WASC Web Hacking Incident Database (WHID)]:

* A1: Injection - http://www.google.com/fusiontables/DataSource?snapid=S2086702IR5
* A2: Broken Authentication and Session Management - https://www.google.com/fusiontables/DataSource?snapid=S1536601kboC
* A3: Cross-site Scripting - https://www.google.com/fusiontables/DataSource?snapid=S856202bP-1
* A4: Insecure Direct Object Reference - http://www.google.com/fusiontables/DataSource?snapid=S208914Efwz
* A5: Security Misconfiguration - http://www.google.com/fusiontables/DataSource?snapid=S208909HtmA
* A6: Sensitive Data Exposure - http://www.google.com/fusiontables/DataSource?snapid=S2089112yxM
* A7: Missing Function Level Access Control - http://www.google.com/fusiontables/DataSource?snapid=S208910u7mt
* A8: Cross-site Request Forgery - https://www.google.com/fusiontables/DataSource?snapid=S856204sdBi
* A9: Using Components with Known Vulnerabilities - https://www.google.com/fusiontables/DataSource?snapid=S1536701c0JG
* A10: Unvalidated Redirects and Forwards - http://www.google.com/fusiontables/DataSource?snapid=S2089124qF5

OWASP Top 10/Mapping to WHID

2015-03-12T19:32:53Z

Rcbarnett:

Here is a mapping of the [[https://www.owasp.org/index.php/Top_10_2013 | OWASP Top 10 - 2013]] to example real world entries in the [https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project OWASP/WASC Web Hacking Incident Database (WHID)]:

* A1: Injection - http://www.google.com/fusiontables/DataSource?snapid=S2086702IR5
* A2: Cross-site Scripting - https://www.google.com/fusiontables/DataSource?snapid=S856202bP-1
* A3: Broken Authentication and Session Management - https://www.google.com/fusiontables/DataSource?snapid=S856203SqTh
* A4: Insecure Direct Object Reference - http://www.google.com/fusiontables/DataSource?snapid=S208914Efwz
* A5: Cross-site Request Forgery - https://www.google.com/fusiontables/DataSource?snapid=S856204sdBi
* A6: Security Misconfiguration - http://www.google.com/fusiontables/DataSource?snapid=S208909HtmA
* A8: Failure to Restrict URL Access - http://www.google.com/fusiontables/DataSource?snapid=S208910u7mt
* A9: Insufficient Transport Layer Protection - http://www.google.com/fusiontables/DataSource?snapid=S2089112yxM
* A10: Unvalidated Redirects and Forwards - http://www.google.com/fusiontables/DataSource?snapid=S2089124qF5

OWASP WASC Web Hacking Incidents Database Project

2015-03-12T19:30:41Z

Rcbarnett:

OWASP Top 10/Mapping to WHID

2015-03-10T21:45:43Z

Rcbarnett:

Here is a mapping of the [[OWASP Top 10#OWASP_Top_10_for_2010 | OWASP Top 10 - 2010]] to example real world entries in the [https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project OWASP/WASC Web Hacking Incident Database (WHID)]:

* A1: Injection - http://www.google.com/fusiontables/DataSource?snapid=S2086702IR5
* A2: Cross-site Scripting - https://www.google.com/fusiontables/DataSource?snapid=S856202bP-1
* A3: Broken Authentication and Session Management - https://www.google.com/fusiontables/DataSource?snapid=S856203SqTh
* A4: Insecure Direct Object Reference - http://www.google.com/fusiontables/DataSource?snapid=S208914Efwz
* A5: Cross-site Request Forgery - https://www.google.com/fusiontables/DataSource?snapid=S856204sdBi
* A6: Security Misconfiguration - http://www.google.com/fusiontables/DataSource?snapid=S208909HtmA
* A8: Failure to Restrict URL Access - http://www.google.com/fusiontables/DataSource?snapid=S208910u7mt
* A9: Insufficient Transport Layer Protection - http://www.google.com/fusiontables/DataSource?snapid=S2089112yxM
* A10: Unvalidated Redirects and Forwards - http://www.google.com/fusiontables/DataSource?snapid=S2089124qF5

Category:OWASP ModSecurity Core Rule Set Project

2014-11-07T18:28:54Z

Rcbarnett:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Rcbarnett Ryan Barnett]

Contributors:
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
== Project Leader ==

[[:User:Rcbarnett|Ryan Barnett]]

== Project Contributors ==

[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
[[:User:Brian_Rectanus|Brian Rectanus]] 
[[:user:Roberto_Salgado|Roberto Salgado]] 
Nick Galbreath

== Project Users ==

WASC Distributed Web Honeypot Project uses the Core Rule Set -
http://projects.webappsec.org/Distributed-Web-Honeypots

Akamai's WAF Service is based on a previous version of the Core Rule Set -
http://www.akamai.com/html/about/press/releases/2009/press_121409.html

CloudFlare's WAF uses the logic from the OWASP ModSecurity CRS -
https://www.cloudflare.com/waf
http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-lua/

Verizon/EdgeCast WAF uses ModSecurity and the OWASP ModSecurity CRS -
http://www.edgecast.com/services/security/#waf

Varnish Web Cache/Accelerator uses a converted version of the CRS -
https://github.com/comotion/security.vcl

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
 

= Road Map and Getting Involved =
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

== v3.0 Detection Concepts ==
This page documents the goals/ideas for the next major version of the CRS.

== Goals ==
These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Detection Logic/Flow Concepts ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Contribute on the mail-list by answering questions from the community
* Report issues to our GitHub Issue tracker

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Category:OWASP ModSecurity Core Rule Set Project

2014-11-07T18:08:26Z

Rcbarnett:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Rcbarnett Ryan Barnett]

Contributors:
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
== Project Leader ==

[[:User:Rcbarnett|Ryan Barnett]]

== Project Contributors ==

[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
[[:User:Brian_Rectanus|Brian Rectanus]] 
[[:user:Roberto_Salgado|Roberto Salgado]] 
Nick Galbreath

== Project Users ==

WASC Distributed Web Honeypot Project uses the Core Rule Set -
http://projects.webappsec.org/Distributed-Web-Honeypots

Akamai's WAF Service is based on a previous version of the Core Rule Set -
http://www.akamai.com/html/about/press/releases/2009/press_121409.html

Varnish Web Cache/Accelerator uses a converted version of the CRS -
https://github.com/comotion/security.vcl

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
 

= Road Map and Getting Involved =
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

== v3.0 Detection Concepts ==
This page documents the goals/ideas for the next major version of the CRS.

== Goals ==
These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Detection Logic/Flow Concepts ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Contribute on the mail-list by answering questions from the community
* Report issues to our GitHub Issue tracker

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Category:OWASP ModSecurity Core Rule Set Project

2014-11-07T17:56:54Z

Rcbarnett:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Rcbarnett Ryan Barnett]

Contributors:
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

== v3.0 Detection Concepts ==
This page documents the goals/ideas for the next major version of the CRS.

== Goals ==
These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Detection Logic/Flow Concepts ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Contribute on the mail-list by answering questions from the community
* Report issues to our GitHub Issue tracker

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Category:OWASP ModSecurity Core Rule Set Project

2014-08-28T16:22:46Z

Rcbarnett:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.

==Introduction==

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).

==Description==

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
*Trojan Protection - Detecting access to Trojans horses.
*Identification of Application Defects - alerts on application misconfigurations.
*Error Detection and Hiding - Disguising error messages sent by the server.

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

==Open HUB==
https://www.openhub.net/p/owasp-modsecurity-crs

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is OWASP ModSecurity CRS? ==

OWASP ModSecurity CRS provides:

* Baseline protection for common web application attacks.

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Project Leader ==

Project Leader:
* [https://www.owasp.org/index.php/User:Rcbarnett Ryan Barnett]

Contributors:
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]] 
*[[:user:Roberto_Salgado|Roberto Salgado]] 
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]

== Related Projects ==

*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]
*[[http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

==Donate==
<paypal>ModSecurity Core Rule Set Project</paypal>

|}

=FAQs=

== Who Leads the ModSecurity Project? ==
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
*Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].

== Background and Support ==

=== What exactly is ModSecurity? ===

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

=== Where do I get more help on ModSecurity? ===

The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.

==== Open Source/Free Help ====
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
*You can also join the #modsecurity channel on irc.freenode.net.
==== Commercial Help ====
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
*Professional Services offer by Trustwave SpiderLabs Research Team
*ModSecurity Training

=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===

Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.

=== Is there anything that I should do prior to sending emails to the mail-list? ===

Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.

=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===

The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.

=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===

No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.

=== Where can I find books about Web Application Firewalls and ModSecurity? ===

==== ModSecurity Handbook ====
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.

==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.

==== ModSecurity 2.5 ====
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.

==== Apache Security ====
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.

==== Preventing Web Attacks with Apache ====
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.

== Getting Started ==

=== What type(s) of security models does ModSecurity support? ===

There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:

*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.

*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.

*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.

=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===

There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:

In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.

Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.

Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

Support for web applications and session IDs.

Regular Expression back-references (allows one to create custom variables using transaction content).

There are now many functions that can be applied to the variables (where previously one could only use regular expressions).

XML support (parsing, validation, XPath).

For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.

=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===

Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.

=== How do I install ModSecurity 2.0? ===

The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.

=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===

The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:

*Advantages
Easy to add to an existing Apache server.

Not a point of failure with respect to traffic.

*Disadvantages
ModSecurity can only protect the local web server.

ModSecurity will consume local resources such as CPU and RAM.

Management of log files and configurations can become difficult if you have multiple installations.

=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===

The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.

*Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.

Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.

Increased performance – if SSL accelerators/caching used.

You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.

*Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.

A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.

Requires changes to the network.

== Configuring ModSecurity ==

=== Should I initially set the SecRuleEngine to On? ===

No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.

=== How do I get ModSecurity to inspect request and response bodies? ===

You need to set the the following two directives:

SecRequestBodyAccess On

SecResponseBodyAccess On

=== How can I verify exactly how ModSecurity is processing rules and requests? ===

You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.

== ModSecurity Rules Language ==

=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

=== What attacks do the Core Rules protect against? ===

In order to provide generic web applications protection, the Core Rules use the following techniques:

*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
*Common Web Attacks Protection - detecting common web application security attack.
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
*Trojan Protection - Detecting access to Trojans horses.
*Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

=== Can I use the Core Rules with ModSecurity 1.x? ===

Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.

=== How do I whitelist an IP address so it can pass through ModSecurity? ===

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===

Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.

On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.

Please refer to the following blog post for more information.

=== How do I handle False Positives and creating Custom Rules? ===

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives.
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

=== Will using a large amount of negative filtering rules impact performance? ===

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.

=== What is a Virtual Patch and why should I care? ===

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

== Managing Alerts ==

=== How do I manage ModSecurity logs if I have multiple installations? ===

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

=== Is there an open source Console to send my audit logs to? ===

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

=== Can I send ModSecurity alert log data through Syslog? ===

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

Involvement in the development and promotion of XXX is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Projects/OWASP ModSecurity Core Rule Set Project/Releases/ModSecurity 2.2.0

2014-08-28T12:54:23Z

Rcbarnett:

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP ModSecurity Core Rule Set Project
| project_home_page = :Category:OWASP ModSecurity Core Rule Set Project

| release_name = ModSecurity 2.2.8
| release_date = 06/30/2013
| release_description =
== Version 2.2.8 - 06/30/2013 ==

Security Fixes:

Improvements:
* Updatd the /util directory structure
* Added scripts to check Rule ID duplicates
* Added script to remove v2.7 actions so older ModSecurity rules will work
- https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/43
* Added new PHP rule (958977) to detect PHP exploits (Plesk 0-day from king cope)
- http://seclists.org/fulldisclosure/2013/Jun/21
- http://blog.spiderlabs.com/2013/06/honeypot-alert-active-exploits-attempts-for-plesk-vulnerability-.html

Bug Fixes:
* fix 950901 - word boundary added
- https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/48
* fix regex error
- https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/44
* Updated the Regex in 981244 to include word boundaries
- https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/36
* Problem with Regression Test (Invalid use of backslash) - Rule 960911 - Test2
- https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/34
* ModSecurity: No action id present within the rule - ignore_static.conf
- https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/17
* "Bad robots" rule blocks all Java applets on Windows XP machines
- https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/16
* duplicated rules id 981173
- https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/18

| release_license = [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License v2 (ASLv2)]

| release_download_link = https://github.com/SpiderLabs/owasp-modsecurity-crs/releases/tag/2.2.8

| leader_name1 = Ryan Barnett
| leader_email1 = Ryan.Barnett@owasp.org
| leader_username1 = Rcbarnett

| release_notes = http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project_-_ModSecurity_2.2.0_-_Notes

}}

Category:OWASP ModSecurity Core Rule Set Project

2014-07-22T18:38:03Z

Rcbarnett: /* Ohloh */

OWASP WASC Web Hacking Incidents Database Project

2014-07-17T20:36:53Z

Rcbarnett: /* Quick Downloads */

Category:OWASP ModSecurity Core Rule Set Project

2014-04-22T18:46:29Z

Rcbarnett: /* Ohloh */

Category:OWASP ModSecurity Core Rule Set Project

2014-04-22T18:44:57Z

Rcbarnett: /* Ohlo */

Category:OWASP ModSecurity Core Rule Set Project

2014-04-22T18:44:29Z

Rcbarnett: /* Licensing */

Projects/OWASP WASC Web Hacking Incidents Database Project

2014-04-21T15:15:58Z

Rcbarnett:

{{Template:Project About
| project_name =OWASP WASC Web Hacking Incidents Database Project
| project_home_page =OWASP WASC Web Hacking Incidents Database Project
| project_description =The web hacking incident database (WHID) is a project dedicated to maintaining a list of web applications related security incidents. WHID goal is to serve as a tool for raising awareness of the web application security problem and provide information for statistical analysis of web applications security incidents. The database is unique in tracking only media reported security incidents that can be associated with a web application security vulnerability. This data is in contrast to many public statistics reports on vulnerability prevalence in that it shows what types of vulnerabilities attackers are actively exploiting.
| project_license =Creative Commons Attribution ShareAlike 3.0 License
| leader_name1 =Ryan Barnett
| leader_email1 =ryan.barnett@owasp.org
| leader_username1 =Rcbarnett
| pamphlet_link =
| presentation_link = https://www.owasp.org/images/c/c3/AppSecDC_2010-WHID_Report-Ryan_Barnett.ppt
| current_release_name = LIVE WHID Dataset on Google Fusion Tables
| current_release_date =
| current_release_download_link = https://www.google.com/fusiontables/DataSource?snapid=S1257901DGNM
| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp_wasc_web_hacking_incidents_database_project
| project_road_map = https://www.owasp.org/index.php/Projects/OWASP_WASC_Web_Hacking_Incidents_Database_Project/Roadmap
| project_health_status =
| current_release_name = LIVE WHID Dataset on Google Fusion Tables
| current_release_date = April 2014
| current_release_download_link = https://www.google.com/fusiontables/DataSource?snapid=S1257901DGNM
| current_release_rating =
| current_release_leader_name = Ryan Barnett
| current_release_leader_email = ryan.barnett@owasp.org
| current_release_leader_username = Rcbarnett
| current_release_details =
}}

Category:OWASP ModSecurity Core Rule Set Project

2014-04-21T14:59:35Z

Rcbarnett: /* Classifications */

Category:OWASP ModSecurity Core Rule Set Project

2014-04-21T14:56:36Z

Rcbarnett: /* Classifications */

OWASP Project Inventory

2014-04-04T13:11:33Z

Rcbarnett: /* Flagship Projects */

__NOTOC__
{|
|-
! width="700" align="center" | 
! width="500" align="center" | 
|-
| align="right" | [[Image:Owasp_banner_web_pro.jpg|800px| link=https://www.owasp.org/index.php/Category:OWASP_Project]]
| align="right" |

|}

= Incubator Projects =
{| style="width: 100%;"
|-
| style="width: 100%; color: rgb(0, 0, 0);" |
{| style="border: 0px solid ; background: transparent none repeat scroll 0% 0%; width: 100%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"
|-
| style="width: 95%; color: rgb(0, 0, 0);" |

==Incubator Projects==

OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.

'''Code'''
* [https://www.owasp.org/index.php/Opa OWASP OPA]
* [https://www.owasp.org/index.php/OWASP_Java_Encoder_Project OWASP Java Encoder Project]
* [https://www.owasp.org/index.php/OWASP_Passfault OWASP Passfault]
* [https://www.owasp.org/index.php/OWASP_OctoMS OWASP OctoMS]
* [https://www.owasp.org/index.php/OWASP_AW00T OWASP AW00t]
* [https://www.owasp.org/index.php/OWASP_JSON_Sanitizer OWASP JSON Sanitizer]
* [https://www.owasp.org/index.php/OWASP_Security_Research_and_Development_Framework OWASP Security Research and Development Framework]
* [https://www.owasp.org/index.php/OWASP_1-Liner OWASP 1-Liner]
* [https://www.owasp.org/index.php/OWASP_Focus OWASP Focus]
* [https://www.owasp.org/index.php/OWASP_PHPRBAC_Project OWASP PHPRBAC Project]
* [https://www.owasp.org/index.php/OWASP_EJSF_Project OWASP EJSF Project]
* [https://www.owasp.org/index.php/OWASP_Barbarus OWASP Barbarus]
* [https://www.owasp.org/index.php/OWASP_iMAS_iOS_Mobile_Application_Security_Project OWASP iMAS - iOS Mobile Application Security Project]
* [https://www.owasp.org/index.php/OWASP_RBAC_Project OWASP RBAC Project]
* [https://www.owasp.org/index.php/OWASP_PHP_Security_Project OWASP PHP Security Project]
* [https://www.owasp.org/index.php/OWASP_Simple_Host_Base_Incidence_Detection_System_Project OWASP Simple Host Base Incidence Detection System Project]
* [https://www.owasp.org/index.php/OWASP_File_Format_Validation_Project OWASP File Format Validation Project]
* [https://www.owasp.org/index.php/OWASP_JAWS_Project OWASP JAWS Project]
* [https://www.owasp.org/index.php/OWASP_Node_js_Goat_Project OWASP Node.js Goat Project]
* [https://www.owasp.org/index.php/OWASP_System_Vulnerable_Code_Project OWASP System Vulnerable Code Project]
* [https://www.owasp.org/index.php/OWASP_ISO_IEC_27034_Application_Security_Controls_Project OWASP ISO/IEC 27034 Application Security Controls Project]
* [https://www.owasp.org/index.php/OWASP_Ultimatum_Project OWASP Ultimatum Project]

'''Tools'''
* [https://www.owasp.org/index.php/OWASP_WhatTheFuzz_Project#tab=Project_About OWASP WhatTheFuzz Project]
* [https://www.owasp.org/index.php/OWASP_Security_Tools_for_Developers_Project OWASP Security Tools for Developers Project]
* [https://www.owasp.org/index.php/OWASP_OVAL_Content_Project OWASP OVAL Content Project]
* [https://www.owasp.org/index.php/OWASP_NAXSI_Project OWASP NAXSI Project]
* [https://www.owasp.org/index.php/OWASP_Passw3rd_Project OWASP Passw3rd Project]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET OWASP WebGoat.NET]
* [https://www.owasp.org/index.php/OWASP_OWTF OWASP OWTF]
* [https://www.owasp.org/index.php/OWASP_Path_Traverser OWASP Path Traverser]
* [https://www.owasp.org/index.php/OWASP_OWASP_Watiqay OWASP Watiqay]
* [https://www.owasp.org/index.php/Projects/OWASP_Security_Shepherd/Roadmap OWASP Security Shepherd]
* [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework OWASP Xenotix XSS Exploit Framework]
* [https://www.owasp.org/index.php/OWASP_Mantra_OS OWASP Mantra OS]
* [https://www.owasp.org/index.php/OWASP_XSSER OWASP XSSER]
* [https://www.owasp.org/index.php/OWASP_Academy_Portal_Project OWASP Academy Portal Project]
* [https://www.owasp.org/index.php/OWASP_ASIDE_Project OWASP ASIDE Project]
* [https://www.owasp.org/index.php/OWASP_iGoat_Project OWASP iGoat Project]
* [https://www.owasp.org/index.php/Category:OWASP_Proxy OWASP Proxy Project]
* [https://www.owasp.org/index.php/OWASP_SamuraiWTF_Project OWASP SamuraiWTF]
* [https://www.owasp.org/index.php/O-Saft O-Saft]
* [https://www.owasp.org/index.php/OWASP_Crowdtesting OWASP Crowdtesting]
* [https://www.owasp.org/index.php/OWASP_OpenStack_Security_Project OWASP OpenStack Security Project]
* [https://www.owasp.org/index.php/OWASP_Desktop_Goat_and_Top_5_Project OWASP Desktop Goat and Top 5 Project]
* [https://www.owasp.org/index.php/OWASP_Bricks OWASP Bricks]
* [https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check]
* [https://www.owasp.org/index.php/OWASP_Hive_Project OWASP Hive Project]
* [https://www.owasp.org/index.php/OWASP_Droid_Fusion OWASP Droid Fusion]
* [https://www.owasp.org/index.php/OWASP_iSABEL_Proxy_Server OWASP iSABEL Proxy Server]
* [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project OWASP Rails Goat Project]
* [https://www.owasp.org/index.php/OWASP_Bywaf_Project OWASP Bywaf Project]
* [https://www.owasp.org/index.php/OWASP_S.T.I.N.G_Project OWASP S.T.I.N.G Project]
* [https://www.owasp.org/index.php/OWASP_Application_Fuzzing_Framework_Project OWASP Application Fuzzing Framework Project]
* [https://www.owasp.org/index.php/OWASP_VaultDB_Project OWASP VaultDB Project]
* [https://www.owasp.org/index.php/OWASP_WS_Amplification_DoS_Project OWASP WS-Amplification DoS Project]
* [https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project OWASP Mutillidae 2 Project]
* [https://www.owasp.org/index.php/OWASP_Skanda_SSRF_Exploitation_Framework OWASP Skanda - SSRF Exploitation Framework]
* [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP SeraphimDroid Project]
* [https://www.owasp.org/index.php/OWASP_Unmaskme_Project OWASP Unmaskme Project]
* [https://www.owasp.org/index.php/OWASP_Androick_Project OWASP Androïck Project]
* [https://www.owasp.org/index.php/OWASP_SafeNuGet_Project OWASP SafeNuGet Project]
* [https://www.owasp.org/index.php/OWASP_WebSandBox_Project OWASP WebSandBox Project]
* [https://www.owasp.org/index.php/OWASP_HA_Vulnerability_Scanner_Project OWASP HA Vulnerability Scanner Project]
* [https://www.owasp.org/index.php/OWASP_Dependency_Track_Project OWASP Dependency Track Project]
* [https://www.owasp.org/index.php/OWASP_PHP_Portscanner_Project OWASP PHP Portscaner Project]
* [https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer OWASP Java HTML Sanitizer Project]
* [https://www.owasp.org/index.php/OWASP_Pygoat_Project OWASP Pygoat Project]
* [https://www.owasp.org/index.php/OWASP_Python_Security_Project OWASP Python Security Project]
* [https://www.owasp.org/index.php/OWASP_WebSpa_Project OWASP WebSpa Project]
* [https://www.owasp.org/index.php/OWASP_Financial_Information_Exchange_Security_Project OWASP Financial Information Exchange Security Project]
* [https://www.owasp.org/index.php/OWASP_STeBB_Project OWASP STeBB Project]
* [https://www.owasp.org/index.php/OWASP_NINJA_PingU_Project OWASP NINJA PingU Project]
* [https://www.owasp.org/index.php/OWASP_Encoder_Comparison_Reference_Project OWASP Encoder Comparison Reference Project]
* [https://www.owasp.org/index.php/Category:OWASP_SQLiX_Project OWASP sqliX Project]
* [https://www.owasp.org/index.php/OWASP_LAPSE_Project OWASP LAPSE Project]
* [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]
* [https://www.owasp.org/index.php/OWASP_WASC_Distributed_Web_Honeypots_Project OWASP WASC Distributed Web Honeypots Project]
* [https://www.owasp.org/index.php/OWASP_Click_Me_Project OWASP Click Me Project]
* [https://www.owasp.org/index.php/OWASP_Secure_TDD_Project OWASP Secure TDD Project]
* [https://www.owasp.org/index.php/OWASP_XSecurity_Project OWASP XSecurity Project]
* [https://www.owasp.org/index.php/OWASP_Pyttacker_Project OWASP Pyttacker Project]
* [https://www.owasp.org/index.php/OWASP_Java_XML_Templates_Project OWASP Java XML Templates Project]

'''Documentation'''
* [https://www.owasp.org/index.php/OWASP_Data_Exchange_Format_Project OWASP Data Exchange Format Project]
* [https://www.owasp.org/index.php/Cheat_Sheets OWASP Cheat Sheets Project]
* [https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Proactive Controls]
* [https://www.owasp.org/index.php/OWASP_Java_J2EE_Secure_Development_Curriculum OWASP Java/J2EE Secure Development Curriculum]
* [https://www.owasp.org/index.php/OWASP_Security_Baseline_Project OWASP Security Baseline Project]
* [https://www.owasp.org/index.php/OWASP_Software_Security_Assurance_Process OWASP Software Security Assurance Process]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Accessibility_Project#tab=Project_About OWASP Web Application Security Accessibility Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project OWASP Application Security Requirements Project]
* [https://www.owasp.org/index.php/OWASP_Common_Numbering_Project OWASP Common Numbering Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Assessment_Standards_Project OWASP Application Security Assessment Standards Project]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Skills_Assessment OWASP Application Security Skills Assessment]
* [https://www.owasp.org/index.php/Category:OWASP_CBT_Project OWASP Computer Based Training Project (OWASP CBT Project)]
* [https://www.owasp.org/index.php/OWASP_Enterprise_Application_Security_Project OWASP Enterprise Application Security Project]
* [https://www.owasp.org/index.php/OWASP_Exams_Project OWASP Exams Project]
* [https://www.owasp.org/index.php/Projects/OWASP_GoatDroid_Project OWASP GoatDroid Project]
* [https://www.owasp.org/index.php/OWASP_RFP-Criteria OWASP Request For Proposal]
* [https://www.owasp.org/index.php/OWASP_University_Challenge OWASP University Challenge]
* [https://www.owasp.org/index.php/OWASP_Hacking_Lab OWASP Hacking-Lab]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Awareness_Top_10_E-learning_Project OWASP Application Security Awareness Top 10 E-learning Project]
* [https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities OWASP Periodic Table of Vulnerabilities]
* [https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project WASC/OWASP Web Application Firewall Evaluation Criteria (WAFEC)]
* [https://www.owasp.org/index.php/ESAPI_Swingset OWASP ESAPI Swingset Project]
* [https://www.owasp.org/index.php/OWASP_Press OWASP Press]
* [https://www.owasp.org/index.php/OWASP_CISO_Survey OWASP CISO Survey]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Guide_For_CISOs_Project OWASP Application Security Guide For CISOs]
* [https://www.owasp.org/index.php/OWASP_Scada_Security_Project OWASP Scada Security Project]
* [https://www.owasp.org/index.php/OWASP_Cornucopia OWASP Cornucopia]
* [https://www.owasp.org/index.php/OWASP_Secure_Application_Design_Project OWASP Secure Application Design Project]
* [https://www.owasp.org/index.php/OWASP_Top_10_Fuer_Entwickler_Project OWASP Top 10 Fuer Entwickler Project]
* [https://www.owasp.org/index.php/OWASP_Good_Component_Practices_Project OWASP Good Component Practices Project]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Quick_Reference_Guide_Project OWASP Web Application Security Quick Reference Guide Project]
* [https://www.owasp.org/index.php/OWASP_Windows_Binary_Executable_Files_Security_Checks_Project OWASP Windows Binary Executable Files Security Checks Project]
* [https://www.owasp.org/index.php/OWASP_Wordpress_Security_Checklist_Project OWASP Wordpress Security Checklist Project]
* [https://www.owasp.org/index.php/OWASP_Supporting_Legacy_Web_Applications_in_the_Current_Environment_Project OWASP Supporting Legacy Web Applications in the Current Environment Project]
* [https://www.owasp.org/index.php/OWASP_Security_Principles_Project OWASP Security Principles Project]
* [https://www.owasp.org/index.php/OWASP_Ruby_on_Rails_and_friends_Security_Guide OWASP Ruby on Rails and friends Security Guide Project]
* [https://www.owasp.org/index.php/OWASP_Framework_Security_Project OWASP Framework Security Project]
* [https://www.owasp.org/index.php/OWASP_Media_Project OWASP Media Project]
* [https://www.owasp.org/index.php/OWASP_Global_Chapter_Meetings_Project OWASP Global Chapter Meetings Project]
* [https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project OWASP Vulnerable Web Applications Directory Project]
* [https://www.owasp.org/index.php/OWASP_Game_Security_Framework_Project OWASP Game Security Framework Project]
* [https://www.owasp.org/index.php/OWASP_Security_Labeling_System_Project OWASP Security Labeling System Project]
* [https://www.owasp.org/index.php/OWASP_IoTs_Project OWASP IoTs Project]
* [https://www.owasp.org/index.php/OWASP_Insecure_Web_Components_Project OWASP Insecure Web Components Project]
* [https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project OWASP Reverse Engineering and Code Modification Prevention Project]
* [https://www.owasp.org/index.php/OWASP_Student_Chapters_Program OWASP Student Chapters Project]
* [https://www.owasp.org/index.php/Category:OWASP_Education_Project OWASP Education Project]
* [https://www.owasp.org/index.php/Category:OWASP_Speakers_Project OWASP Speakers Project]
* [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project OWASP Internet of Things Top Ten Project]
* [https://www.owasp.org/index.php/Category:OWASP_.NET_Project OWASP .NET Project]
* [https://www.owasp.org/index.php/OWASP_Research_Book_Project OWASP Research Book Project]
* [https://www.owasp.org/index.php/OWASP_Open_Cyber_Security_Framework_Project OWASP Open Cyber Security Framework Project]
* [https://www.owasp.org/index.php/OWASP_ISO_Project OWASP ISO Project]
* [https://www.owasp.org/index.php/OWASP_Top_10_Privacy_Risks_Project OWASP Top 10 Privacy Risks Project]
* [https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project OWASP WASC Web Hacking Incidents Database Project]
* [https://www.owasp.org/index.php/OWASP_Security_Frameworks_Project OWASP Security Frameworks Project]
* [https://www.owasp.org/index.php/OWASP_Incident_Response_Project OWASP Incident Response Project]





 

|}



                                                                                                                             
{|

| style="width: 110px; font-size: 95%; color: rgb(0, 0, 0);" |
|}

| style="width: 110px; font-size: 95%; color: rgb(0, 0, 0);" |
|}


= Labs Projects =

==Labs Projects==

OWASP Labs projects represent projects that have produced a deliverable of value. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.

'''Tools'''
* [https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project OWASP Broken Web Applications Project]
* [https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester Project]
* [https://www.owasp.org/index.php/Category:OWASP_EnDe OWASP EnDe Project]
* [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project OWASP Hackademic Challenges Project]
* [https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool OWASP HTTP POST Tool]
* [https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework OWASP Mantra Security Framework]
* [https://www.owasp.org/index.php/Category:OWASP_Mutillidae OWASP Mutillidae Project]
* [https://www.owasp.org/index.php/OWASP_O2_Platform OWASP O2 Platform]
* [https://www.owasp.org/index.php/Project_Information:template_Vicnum_Project OWASP Vicnum Project]
* [https://www.owasp.org/index.php/Category:OWASP_Wapiti_Project OWASP Wapiti Project]
* [https://www.owasp.org/index.php/Project_Information:template_Yasca_Project OWASP Yasca Project]

'''Documentation'''
* [https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series OWASP AppSec Tutorial Series]
* [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor Project]
* [https://www.owasp.org/index.php/Category:OWASP_CTF_Project OWASP CTF Project]
* [https://www.owasp.org/index.php/Category:OWASP_Legal_Project OWASP Legal Project]
* [https://www.owasp.org/index.php/OWASP_Podcast OWASP Podcast Project]
* [https://www.owasp.org/index.php/Virtual_Patching_Best_Practices Virtual Patching Best Practices]

= Flagship Projects =

==Flagship Projects==

The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole. OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining.

'''Code'''
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project OWASP AntiSamy Project]
* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API]
* [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set Project]
* [https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRFGuard Project]

'''Tools'''
* [https://www.owasp.org/index.php?title=OWASP_Web_Testing_Environment_Project OWASP Web Testing Environment Project]
* [https://www.owasp.org/index.php/Webgoat OWASP WebGoat Project]
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy]

'''Documentation'''
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard Project]
* [https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide Project]
* [https://www.owasp.org/index.php/OWASP_Codes_of_Conduct OWASP Codes of Conduct]
* [https://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide Project]
* [https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide OWASP Secure Coding Practices - Quick Reference Guide]
* [https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model OWASP Software Assurance Maturity Model (SAMM)]
* [https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing Guide Project]
* [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Project]

= Archived Projects =


== Archived Projects ==

OWASP Archived Projects are inactive Labs projects. If you are interested in pursuing any of the projects below, please contact us and let us know of your interest.

* [https://www.owasp.org/index.php/Category:OWASP_Access_Control_Rules_Tester_Project OWASP Access Control Rules Tester Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Metrics_Project OWASP Application Security Metrics Project]
* [https://www.owasp.org/index.php/Category:OWASP_AppSec_FAQ_Project OWASP AppSec FAQ Project]
* [https://www.owasp.org/index.php/Asdr OWASP ASDR Project]
* [https://www.owasp.org/index.php/Category:OWASP_Backend_Security_Project OWASP Backend Security Project]
* [https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls OWASP Best Practices: Use of Web Application Firewalls]
* [https://www.owasp.org/index.php/Category:OWASP_CAL9000_Project OWASP CAL9000 Project]
* [https://www.owasp.org/index.php/Category:OWASP_CLASP_Project OWASP CLASP Project]
* [https://www.owasp.org/index.php/Category:OWASP_Code_Crawler OWASP CodeCrawler Project]
* [https://www.owasp.org/index.php/Category:OWASP_Content_Validation_using_Java_Annotations_Project OWASP Content Validation using Java Annotations Project]
* [https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project OWASP DirBuster Project]
* [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project OWASP Encoding Project]
* [https://www.owasp.org/index.php/Category:OWASP_Google_Hacking_Project OWASP Google Hacking Project]
* [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project OWASP Insecure Web App Project]
* [https://www.owasp.org/index.php/Category:OWASP_Interceptor_Project OWASP Interceptor Project]
* [https://www.owasp.org/index.php/Category:OWASP_JSP_Testing_Tool_Project OWASP JSP Testing Tool Project]
* [https://www.owasp.org/index.php/Category:OWASP_LiveCD_Education_Project OWASP LiveCD Education Project]
* [https://www.owasp.org/index.php/Category:OWASP_Logging_Project OWASP Logging Guide]
* [https://www.owasp.org/index.php/Category:OWASP_NetBouncer_Project OWASP NetBouncer Project]
* [https://www.owasp.org/index.php/Category:OWASP_OpenPGP_Extensions_for_HTTP_-_Enigform_and_mod_openpgp OWASP OpenPGP Extensions for HTTP - Enigform and mod_openpgp Project]
* [https://www.owasp.org/index.php/Category:OWASP_OpenSign_Server_Project OWASP OpenSign Server Project]
* [https://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project OWASP Pantera Web Assessment Studio Project]
* [https://www.owasp.org/index.php/Category:OWASP_PHP_Project OWASP PHP Project]
* [https://www.owasp.org/index.php/ORG_%28OWASP_Report_Generator%29 OWASP Report Generator]
* [https://www.owasp.org/index.php/Category:OWASP_SASAP_Project OWASP Scholastic Application Security Assessment Project]
* [https://www.owasp.org/index.php/Category:OWASP_Security_Analysis_of_Core_J2EE_Design_Patterns_Project OWASP Security Analysis of Core J2EE Design Patterns Project]
* [https://www.owasp.org/index.php/Category:OWASP_Security_Spending_Benchmarks OWASP Security Spending Benchmarks Project]
* [https://www.owasp.org/index.php/OWASP_SiteGenerator OWASP Site Generator Project]
* [https://www.owasp.org/index.php/Category:OWASP_Skavenger_Project OWASP Skavenger Project]
* [https://www.owasp.org/index.php/Category:OWASP_Source_Code_Flaws_Top_10_Project OWASP Source Code Flaws Top 10 Project]
* [https://www.owasp.org/index.php/Category:OWASP_Sprajax_Project OWASP Sprajax Project]
* [https://www.owasp.org/index.php/Category:OWASP_Sqlibench_Project OWASP Sqlibench Project]
* [https://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project]
* [https://www.owasp.org/index.php/Category:OWASP_Teachable_Static_Analysis_Workbench_Project OWASP Teachable Static Analysis Workbench Project]
* [https://www.owasp.org/index.php/OWASP_Tiger OWASP Tiger]
* [https://www.owasp.org/index.php/Category:OWASP_Tools_Project OWASP Tools Project]
* [https://www.owasp.org/index.php/Projects/OWASP_Uniform_Reporting_Guidelines OWASP Uniform Reporting Guidelines]
* [https://www.owasp.org/index.php/Category:OWASP_WeBekci_Project OWASP Webekci Project]
* [https://www.owasp.org/index.php/JBroFuzz JBroFuzz]
* [https://owasp.org/index.php/Category:OWASP_SWAAT_Project OWASP SWAAT Project]
* [https://www.owasp.org/index.php/OWASP_Secure_Web_Application_Framework_Manifesto OWASP Secure Web Application Framework Manifesto]
* [https://www.owasp.org/index.php/Scrubbr OWASP Scrubbr]
* [https://www.owasp.org/index.php/OWASP_JavaScript_Sandboxes OWASP JavaScript Sandboxes Project]
* [https://www.owasp.org/index.php/Category:OWASP_Joomla_Vulnerability_Scanner_Project OWASP Joomla Vulnerability Scanner Project]
* [https://www.owasp.org/index.php/OWASP_Hatkit_Datafiddler_Project OWASP Hatkit Datafiddler Project]
* [https://www.owasp.org/index.php/OWASP_Hatkit_Proxy_Project OWASP Hatkit Proxy Project]
* [https://www.owasp.org/index.php/OWASP_Fiddler_Addons_for_Security_Testing_Project OWASP Fiddler Addons for Security Testing Project]
* [https://www.owasp.org/index.php/OWASP_Forward_Exploit_Tool_Project OWASP Forward Exploit Tool Project]
* [https://www.owasp.org/index.php/Category:OWASP_Fuzzing_Code_Database OWASP Fuzzing Code Database]
* [https://www.owasp.org/index.php/Category:OWASP_Cloud_‐_10_Project OWASP Cloud ‐ 10 Project]
* [https://www.owasp.org/index.php/OWASP_Web_Browser_Testing_System_Project OWASP Web Browser Testing System Project]
* [https://www.owasp.org/index.php/Webscarab OWASP WebScarab Project]
* [https://www.owasp.org/index.php/Project_Information:template_Webslayer_Project OWASP Webslayer Project]
* [https://www.owasp.org/index.php/Project_Information:template_WSFuzzer_Project OWASP WSFuzzer Project]
* [http://owasp.com/index.php/Category:OWASP_Security_Assurance_Testing_of_Virtual_Worlds_Project OWASP Security Assurance Testing of Virtual Worlds Project]
* [https://www.owasp.org/index.php/OWASP_WAF_Project OWASP WAF Project]
* [https://www.owasp.org/index.php/OWASP_VFW_Project OWASP VFW Project]
* [https://www.owasp.org/index.php/OWASP_SIMBA_Project OWASP SIMBA Project]
* [https://www.owasp.org/index.php/OWASP_ONYX OWASP ONYX]
* [https://www.owasp.org/index.php/OWASP_Java_Uncertain_Form_Submit_Prevention OWASP Java Uncertain Form Submit Prevention]
* [https://www.owasp.org/index.php/OWASP_Ecuador OWASP Ecuador]
* [https://www.owasp.org/index.php/OWASP_ESOP_Framework OWASP ESOP Framework]
* [https://www.owasp.org/index.php/OWASP_Alchemist_Project OWASP Alchemist Project]
* [https://www.owasp.org/index.php/OWASP_Secure_the_Flag_Competition_Project OWASP Secure the Flag Project]
* [https://www.owasp.org/index.php/OWASP_Browser_Security_ACID_Tests_Project OWASP Browser Security ACID Test Project]
* [https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool OWASP AJAX Crawling Tool]
* [https://www.owasp.org/index.php/OWASP_Threat_Modelling_Project OWASP Threat Modeling Project]
* [https://www.owasp.org/index.php/OWASP_Crossword_of_the_Month OWASP Crossword of the Month]
* [https://www.owasp.org/index.php/OWASP_Secure_Password_Project OWASP Secure Password Project]
* [https://www.owasp.org/index.php/OWASP_Myth_Breakers_Project OWASP Myth Breakers Project]
* [http://owasp.com/index.php/OWASP_Project_Partnership_Model OWASP Project Partnership Model]
* [https://www.owasp.org/index.php/OWASP_Browser_Security_Project OWASP Browser Security Project]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Program_for_Managers OWASP Application Security Program for Managers]
* [https://www.owasp.org/index.php/Category:OWASP_Favicon_Database_Project OWASP Favicon Database Project]
* [https://www.owasp.org/index.php/OWASP_Embedded_Application_Security OWASP Embedded Application Security]
* [https://www.owasp.org/index.php/OWASP_Security_JDIs_Project OWASP Security JDIs Project]
* [https://www.owasp.org/index.php/OWASP_File_Hash_Repository OWASP File Hash Repository]



= OWASP Project Types =

== Code ==
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project OWASP AntiSamy Project]
* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API]
* [https://www.owasp.org/index.php/Projects/OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set Project]
* [https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASPCSRF Guard Project]
* [https://www.owasp.org/index.php/Opa OWASP OPA]
* [https://www.owasp.org/index.php/OWASP_Java_Encoder_Project OWASP Java Encoder Project]
* [https://www.owasp.org/index.php/OWASP_Passfault OWASP Passfault]
* [https://www.owasp.org/index.php/OWASP_OctoMS OWASP OctoMS]
* [https://www.owasp.org/index.php/OWASP_AW00T OWASP AW00t]
* [https://www.owasp.org/index.php/OWASP_JSON_Sanitizer OWASP JSON Sanitizer]
* [https://www.owasp.org/index.php/OWASP_Security_Research_and_Development_Framework OWASP Security Research and Development Framework]
* [https://www.owasp.org/index.php/OWASP_1-Liner OWASP 1-Liner]
* [https://www.owasp.org/index.php/OWASP_Focus OWASP Focus]
* [https://www.owasp.org/index.php/OWASP_PHPRBAC_Project OWASP PHPRBAC Project]
* [https://www.owasp.org/index.php/OWASP_EJSF_Project OWASP EJSF Project]
* [https://www.owasp.org/index.php/OWASP_Barbarus OWASP Barbarus]
* [https://www.owasp.org/index.php/OWASP_iMAS_iOS_Mobile_Application_Security_Project OWASP iMAS - iOS Mobile Application Security Project]
* [https://www.owasp.org/index.php/OWASP_RBAC_Project OWASP RBAC Project]
* [https://www.owasp.org/index.php/OWASP_PHP_Security_Project OWASP PHP Security Project]
* [https://www.owasp.org/index.php/OWASP_Simple_Host_Base_Incidence_Detection_System_Project OWASP Simple Host Base Incidence Detection System Project]
* [https://www.owasp.org/index.php/OWASP_File_Format_Validation_Project OWASP File Format Validation Project]
* [https://www.owasp.org/index.php/OWASP_JAWS_Project OWASP JAWS Project]
* [https://www.owasp.org/index.php/OWASP_Node_js_Goat_Project OWASP Node.js Goat Project]
* [https://www.owasp.org/index.php/OWASP_System_Vulnerable_Code_Project OWASP System Vulnerable Code Project]
* [https://www.owasp.org/index.php/OWASP_ISO_IEC_27034_Application_Security_Controls_Project OWASP ISO/IEC 27034 Application Security Controls Project]
* [https://www.owasp.org/index.php/OWASP_Ultimatum_Project OWASP Ultimatum Project]

==Tools==
* [https://www.owasp.org/index.php?title=OWASP_Web_Testing_Environment_Project OWASP Web Testing Environment Project]
* [https://www.owasp.org/index.php/Webgoat OWASP WebGoat Project]
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy]
* [https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project OWASP Broken Web Applications Project]
* [https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWAsP CSRFTester Project]
* [https://www.owasp.org/index.php/Category:OWASP_EnDe OWASP EnDe Project]
* [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project OWASP Hackademic Challenges Project]
* [https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool OWASP HTTP Post Tool]
* [https://www.owasp.org/index.php/OWASP_Java_XML_Templates_Project OWASP Java XML Templates Project]
* [https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework OWASP Mantra Security Framework]
* [https://www.owasp.org/index.php/Category:OWASP_Mutillidae OWASP Mutillidae Project]
* [https://www.owasp.org/index.php/OWASP_O2_Platform OWASP O2 Platform]
* [https://www.owasp.org/index.php/Project_Information:template_Vicnum_Project OWASP Vicnum Project]
* [https://www.owasp.org/index.php/Category:OWASP_Wapiti_Project OWASP Wapiti Project]
* [https://www.owasp.org/index.php/Project_Information:template_Yasca_Project OWASP Yasca Project]
* [https://www.owasp.org/index.php/OWASP_WhatTheFuzz_Project#tab=Project_About OWASP WhatTheFuzz Project]
* [https://www.owasp.org/index.php/OWASP_Security_Tools_for_Developers_Project OWASP Security Tools for Developers Project]
* [https://www.owasp.org/index.php/OWASP_OVAL_Content_Project OWASP OVAL Content Project]
* [https://www.owasp.org/index.php/OWASP_NAXSI_Project OWASP NAXSI Project]
* [https://www.owasp.org/index.php/OWASP_Passw3rd_Project OWASP Passw3rd Project]
* [https://www.owasp.org/index.php/OWASP_File_Hash_Repository OWASP File Hash Repository]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET OWASP WebGoat.NET]
* [https://www.owasp.org/index.php/OWASP_OWTF OWASP OWTF]
* [https://www.owasp.org/index.php/OWASP_Path_Traverser OWASP Path Traverser]
* [https://www.owasp.org/index.php/OWASP_OWASP_Watiqay OWASP Watiqay]
* [https://www.owasp.org/index.php/Projects/OWASP_Security_Shepherd/Roadmap OWASP Security Shepherd]
* [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework OWASP Xenotix XSS Exploit Framework]
* [https://www.owasp.org/index.php/OWASP_Mantra_OS OWASP Mantra OS]
* [https://www.owasp.org/index.php/OWASP_XSSER OWASP XSSER]
* [https://www.owasp.org/index.php/OWASP_Academy_Portal_Project OWASP Academy Portal Project]
* [https://www.owasp.org/index.php/OWASP_ASIDE_Project OWASP ASIDE Project]
* [https://www.owasp.org/index.php/OWASP_iGoat_Project OWASP iGoat Project]
* [https://www.owasp.org/index.php/Category:OWASP_Proxy OWASP Proxy Project]
* [https://www.owasp.org/index.php/OWASP_SamuraiWTF_Project OWASP SamuraiWTF]
* [https://www.owasp.org/index.php/O-Saft O-Saft]
* [https://www.owasp.org/index.php/OWASP_Crowdtesting OWASP Crowdtesting]
* [https://www.owasp.org/index.php/OWASP_OpenStack_Security_Project OWASP OpenStack Security Project]
* [https://www.owasp.org/index.php/OWASP_Desktop_Goat_and_Top_5_Project OWASP Desktop Goat and Top 5 Project]
* [https://www.owasp.org/index.php/OWASP_Bricks OWASP Bricks]
* [https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check]
* [https://www.owasp.org/index.php/OWASP_Hive_Project OWASP Hive Project]
* [https://www.owasp.org/index.php/OWASP_Droid_Fusion OWASP Droid Fusion]
* [https://www.owasp.org/index.php/OWASP_iSABEL_Proxy_Server OWASP iSABEL Proxy Server]
* [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project OWASP Rails Goat Project]
* [https://www.owasp.org/index.php/OWASP_Bywaf_Project OWASP Bywaf Project]
* [https://www.owasp.org/index.php/OWASP_S.T.I.N.G_Project OWASP S.T.I.N.G Project]
* [https://www.owasp.org/index.php/OWASP_Application_Fuzzing_Framework_Project OWASP Application Fuzzing Framework Project]
* [https://www.owasp.org/index.php/OWASP_VaultDB_Project OWASP VaultDB Project]
* [https://www.owasp.org/index.php/OWASP_WS_Amplification_DoS_Project OWASP WS-Amplification DoS Project]
* [https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project OWASP Mutillidae 2 Project]
* [https://www.owasp.org/index.php/OWASP_Skanda_SSRF_Exploitation_Framework OWASP Skanda - SSRF Exploitation Framework]
* [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP SeraphimDroid Project]
* [https://www.owasp.org/index.php/OWASP_Unmaskme_Project OWASP Unmaskme Project]
* [https://www.owasp.org/index.php/OWASP_Androick_Project OWASP Androïck Project]
* [https://www.owasp.org/index.php/OWASP_SafeNuGet_Project OWASP SafeNuGet Project]
* [https://www.owasp.org/index.php/OWASP_WebSandBox_Project OWASP WebSandBox Project]
* [https://www.owasp.org/index.php/OWASP_HA_Vulnerability_Scanner_Project OWASP HA Vulnerability Scanner Project]
* [https://www.owasp.org/index.php/OWASP_Dependency_Track_Project OWASP Dependency Track Project]
* [https://www.owasp.org/index.php/OWASP_PHP_Portscanner_Project OWASP PHP Portscaner Project]
* [https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer OWASP Java HTML Sanitizer Project]
* [https://www.owasp.org/index.php/OWASP_Pygoat_Project OWASP Pygoat Project]
* [https://www.owasp.org/index.php/OWASP_Python_Security_Project OWASP Python Security Project]
* [https://www.owasp.org/index.php/OWASP_Web_Knocking_Project OWASP Web Knocking Project]
* [https://www.owasp.org/index.php/OWASP_Financial_Information_Exchange_Security_Project OWASP Financial Information Exchange Security Project]
* [https://www.owasp.org/index.php/OWASP_STeBB_Project OWASP STeBB Project]
* [https://www.owasp.org/index.php/OWASP_NINJA_PingU_Project OWASP NINJA PingU Project]
* [https://www.owasp.org/index.php/OWASP_Encoder_Comparison_Reference_Project OWASP Encoder Comparison Reference Project]

==Documentation==
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard Project]
* [https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Project]
* [https://www.owasp.org/index.php/OWASP_Codes_of_Conduct OWASP Codes of Conduct]
* [https://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide Project]
* [https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide OWASP Secure Coding Practices - Quick Reference Guide]
* [https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model OWASP Software Assurance Maturity Model(SAMM)]
* [https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing Guide Project]
* [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Project]
* [https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series OWASP AppSec Tutorial Series]
* [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor Project]
* [https://www.owasp.org/index.php/Category:OWASP_CTF_Project OWASP CTF Project]
* [https://www.owasp.org/index.php/Category:OWASP_Legal_Project OWASP Legal Project]
* [https://www.owasp.org/index.php/OWASP_Podcast OWASP Podcast Project]
* [https://www.owasp.org/index.php/Virtual_Patching_Best_Practices Virtual Patching Best Practices]
* [https://www.owasp.org/index.php/OWASP_Data_Exchange_Format_Project OWASP Data Exchange Format Project]
* [https://www.owasp.org/index.php/Cheat_Sheets OWASP Cheat Sheets Project]
* [https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Proactive Controls]
* [https://www.owasp.org/index.php/OWASP_Java_J2EE_Secure_Development_Curriculum OWASP Java/J2EE Secure Development Curriculum]
* [https://www.owasp.org/index.php/OWASP_Security_Baseline_Project OWASP Security Baseline Project]
* [https://www.owasp.org/index.php/OWASP_Software_Security_Assurance_Process OWASP Software Security Assurance Process]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Accessibility_Project#tab=Project_About OWASP Web Application Security Accessibility Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project OWASP Application Security Requirements Project]
* [https://www.owasp.org/index.php/OWASP_Common_Numbering_Project OWASP Common Numbering Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Assessment_Standards_Project OWASP Application Security Assessment Standards Project]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Skills_Assessment OWASP Application Security Skills Assessment]
* [https://www.owasp.org/index.php/Category:OWASP_CBT_Project OWASP Computer Based Training Project (OWASP CBT Project)]
* [https://www.owasp.org/index.php/OWASP_Enterprise_Application_Security_Project OWASP Enterprise Application Security Project]
* [https://www.owasp.org/index.php/OWASP_Exams_Project OWASP Exams Project]
* [https://www.owasp.org/index.php/Projects/OWASP_GoatDroid_Project OWASP GoatDroid Project]
* [https://www.owasp.org/index.php/OWASP_RFP-Criteria OWASP Request For Proposal]
* [https://www.owasp.org/index.php/OWASP_University_Challenge OWASP University Challenge]
* [https://www.owasp.org/index.php/OWASP_Hacking_Lab OWASP Hacking-Lab]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Awareness_Top_10_E-learning_Project OWASP Application Security Awareness Top 10 E-learning Project]
* [https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities OWASP Periodic Table of Vulnerabilities]
* [https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project WASC/OWASP Web Application Firewall Evaluation Criteria (WAFEC)]
* [https://www.owasp.org/index.php/ESAPI_Swingset OWASP ESAPI Swingset Project]
* [https://www.owasp.org/index.php/OWASP_Press OWASP Press]
* [https://www.owasp.org/index.php/OWASP_CISO_Survey OWASP CISO Survey]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Guide_For_CISOs_Project OWASP Application Security Guide For CISOs]
* [https://www.owasp.org/index.php/OWASP_Scada_Security_Project OWASP Scada Security Project]
* [https://www.owasp.org/index.php/OWASP_Cornucopia OWASP Cornucopia]
* [https://www.owasp.org/index.php/OWASP_Secure_Application_Design_Project OWASP Secure Application Design Project]
* [https://www.owasp.org/index.php/OWASP_Top_10_Fuer_Entwickler_Project OWASP Top 10 Fuer Entwickler Project]
* [https://www.owasp.org/index.php/OWASP_Good_Component_Practices_Project OWASP Good Component Practices Project]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Quick_Reference_Guide_Project OWASP Web Application Security Quick Reference Guide Project]
* [https://www.owasp.org/index.php/OWASP_Windows_Binary_Executable_Files_Security_Checks_Project OWASP Windows Binary Executable Files Security Checks Project]
* [https://www.owasp.org/index.php/OWASP_Wordpress_Security_Checklist_Project OWASP Wordpress Security Checklist Project]
* [https://www.owasp.org/index.php/OWASP_Supporting_Legacy_Web_Applications_in_the_Current_Environment_Project OWASP Supporting Legacy Web Applications in the Current Environment Project]
* [https://www.owasp.org/index.php/OWASP_Security_Principles_Project OWASP Security Principles Project]
* [https://www.owasp.org/index.php/OWASP_Ruby_on_Rails_and_friends_Security_Guide OWASP Ruby on Rails and friends Security Guide Project]
* [https://www.owasp.org/index.php/OWASP_Framework_Security_Project OWASP Framework Security Project]
* [https://www.owasp.org/index.php/OWASP_Media_Project OWASP Media Project]
* [https://www.owasp.org/index.php/OWASP_Global_Chapter_Meetings_Project OWASP Global Chapter Meetings Project]
* [https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project OWASP Vulnerable Web Applications Directory Project]
* [https://www.owasp.org/index.php/OWASP_Game_Security_Framework_Project OWASP Game Security Framework Project]
* [https://www.owasp.org/index.php/OWASP_Security_Labeling_System_Project OWASP Security Labeling System Project]
* [https://www.owasp.org/index.php/OWASP_IoTs_Project OWASP IoTs Project]
* [https://www.owasp.org/index.php/OWASP_Insecure_Web_Components_Project OWASP Insecure Web Components Project]
* [https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project OWASP Reverse Engineering and Code Modification Prevention Project]
* [https://www.owasp.org/index.php/OWASP_Student_Chapters_Program OWASP Student Chapters Project]
* [https://www.owasp.org/index.php/Category:OWASP_Education_Project OWASP Education Project]
* [https://www.owasp.org/index.php/Category:OWASP_Speakers_Project OWASP Speakers Project]
* [https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project OWASP Internet of Things Top Ten Project]
* [https://www.owasp.org/index.php/Category:OWASP_.NET_Project OWASP .NET Project]
* [https://www.owasp.org/index.php/OWASP_Research_Book_Project OWASP Research Book Project]
* [https://www.owasp.org/index.php/OWASP_Open_Cyber_Security_Framework_Project OWASP Open Cyber Security Framework Project]

<headertabs />

OWASP WASC Web Hacking Incidents Database Project

2014-03-14T16:46:53Z

Rcbarnett:

GSoC2014 Ideas

2014-03-05T14:42:22Z

Rcbarnett:

=OWASP Project Requests=

== OWASP Hackademic Challenges ==
=== OWASP Hackademic Challenges - New challenges and Improvements to the existing ones ===

'''Brief Explanation:'''

The challenges that have been implemented so far include: web application challenges covering several vulnerabilities included in the OWASP Top 10, cryptographic challenges, and entire virtual machines including several vulnerabilities.
New challenges need to be created in order to cover a broader set of vulnerabilities.
Also existing challenges can be modified to accept a broader set of valid answers, e.g. by using regular expressions.

Ideas on the project:

* Simulated simple buffer overflows
* SQL injections
* Man in the middle simulation
* Bypassing regular expression filtering
* Your idea here

'''Expected Results:'''

New cool challenges

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML and possibly Javascript. Good understanding of Application Security and related vulnerabilities.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== OWASP Hackademic Challenges - Source Code testing environment ===

'''Brief Explanation:'''

Existing challenges are based on a dynamic application testing concept. We would like to work on a project that will give the capability to the attacker to review a vulnerable piece of source code, make corrections and see the result in a realistic (but yet safe) runtime environment. The code can either be run if needed or tested for correctness and security. The implementation challenges of such a project can be numerous, including creating a realistic but also secure environment, testing submitted solutions and grading them in an automatic manner. At the same time there are now numerous sites that support submitting code and then simulate or implement a compiler's functionality.

'''Expected Results:'''

A source code testing and improvement environment where a user will be able to review, improve and test the result of a piece of source code.

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML and possibly Java. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== OWASP Hackademic Challenges - Challenge Sandbox ===

Now, in order to create a challenge, one has to validate the solution with regular expressions (or just plaintext comparison) and report success or failure to the backend,
we'd like the ability to write a normal vulnerable web application as a challenge and leave it to hackademic to make sure that the server is not affected.
Since this is probably the most difficult task proposed, if you are considering it, please get in touch with us early on so we can discuss about it and plan it correctly.

Ideas on the project:

''' *Administrator's point of view* '''

Create an infrastructure that spawns virtual environments for users while keeping the load reasonable on the server(s).
Or configure apache,php,mysql in a way that allows for multiple instances of the programms to run in parallel completely seperated from the rest of the server.
The student is expected to provide configuration scripts that do the above

''' *Coder's Way* '''

This is better explained with an example:
In order to create an sql injection challenge one should be able to call a common unsecure mysql execute statement function.
The student can override common functions like this providing their own implementation of a very temporary database (based on flat files or nosql solutions e.t.c.).
The new functions should be able to detect the sqli and apply its results in a secure way(if the student drops a table no actual tables should be dropped but the table should not be visible to the student anymore).

''' * Your solution here * '''

The above solutions are by no way complete,their intention is to start you thinking.
This is a difficult task so if you consider takling it talk to us early on so we can reach a good solution which is possible in the GSoC timeframe.

''' Expected results '''

You should be able to run a big enough subset of OWASP WebGoat PHP with minimal modification as a Hackademic Challenge

=== OWASP Hackademic Challenges - CMS improvements ===

'''Brief Explanation:'''

The new CMS was created during last year's GSOC. We have received feedback from users that suggest various improvements regarding functionality e.g. better user, teacher and challenges management. There are also some security improvements that are needed and in general any functionality that adds up to the educational nature of the project is more than welcome.

Ideas on this project:

* ''' Template''' *

Since it's creation the project has received a good number of new features, but the visual/ux/ui part has never gotten much love.
It would be good if we had a new template with proper ui design.

* '''Questionaire creation plugin''' *

We'd like the admin to be able to create questionaires, assign rules for each question (e.g. correct answer +2pts incorrect answer -2, no answer 0) and assign them to students as homework/exams.
The grading can either be done automatically (for multiple choice) or be submitted to the creator of the questionaire.

* '''Ability to show different articles on the user's home screen'''

Now each user is served the latest article in her/his home screen. We need the ability for either the teacher/admin to be able to define what article each class is served.

* '''Gamification of the user's progress''' *

A series of plugins and a template which allow the user to earn badges as they solve challenges and a better visual representation of their progress.

* '''Ability to define series of challenges'''

The teacher/admin should be able to define a series of challenges (e.g. 2,5,3,1) which are meant to be solved in that order and if one is not solved then the student can't try the next one.

* ''' Tagging of articles, users, challenges '''

A user should be able to put tags on articles and challenges if he is a student and on users, classes, articles and challenges if he is a teacher.
Also the user should be able to search according to the tags.

* '''Your idea here'''

We welcome new ideas to make the project look awesome.

'''Expected Results:'''

New features and security improvements on the CMS part of the project.

'''Knowledge Prerequisites:'''

Comfortable in PHP and HTML. Good understanding of Application Security and related vulnerabilities if you undertake security improvements.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

==OWASP WebGoatPHP==
===OWASP WebGoatPHP===
'''Description:'''
[[Webgoat]] is a deliberately insecure open source software made by OWASP using Java programming language. It has a set of challenges and steps, each providing the user with one or more web application vulnerability which user tries to solve. There are also hints and auto-detection of correct solutions.
Since Java is not the most common web application programming language, and it doesn't have many of the bugs other languages such as PHP have when it comes to security, OWASP has [[OWASP_WebGoat_Reboot2012|dedicated in 2012]] an amount of $5000 for promotion of WebGoatPHP.

If you want to know more about WebGoatPHP, I suggest downloading and giving WebGoat a try. It is one of OWASP prides (about 200000 downloads).

'''Expected Results:''' WebGoatPHP will be a deliberately insecure PHP web application which operates in different modes. A contest mode where challenges are selected by an admin and the system starts a contest. Admins can open up hints for participants and manage everything. A workshop mode, where the educator has control of the most of application features, as well as feedback of user activities and is ideal for learning environments, and a single mode where someone can browse challenges and solve them.

'''Knowledge prerequisite:''' You just need to know PHP. You are supposed to define flawed systems, which is not the hardest thing. Familiarity with web application security and SQL is recommended.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

==OWASP CSRF Guard==
===OWASP CSRF Guard===
'''Description:''' [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] is a complicated yet very effective web attack. The most important thing about CSRF is that it's hard to properly defend against it, specially when it comes to Web 2 and AJAX. We have had discussions on means of mitigating CSRF for years at OWASP, and are now ready to develop libraries for it. Many of the key ideas of this library can be found at [http://www.cs.sunysb.edu/~rpelizzi/jcsrf.pdf].

'''Expected Results:''' A transparent Apache 2 module properly mitigating all POST CSRF attacks, as well as a lightweight PHP library doing the same.

'''Knowledge prerequisites:''' Knowing CSRF and at least one way to defend against it, PHP, C/C++, Linux.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary

==OWASP PHP Security Project==
===OWASP PHP Security Project===

'''Description:'''
OWASP PHP Security project plans to gather around secure PHP libraries, and provide a full featured framework of libraries for secure web applications in PHP, both as separate de-coupled libraries and as a whole secure web application framework. Many aspects of this project are already handled, and are being added to OWASP.

'''Expected Results: ''' Result of this project is much more security among PHP applications. Most PHP applications are vulnerable and there's no central approach to secure them (due to open source nature). Many people look at OWASP for such information.

Last year, we got GSoC people working on OWASP PHPSEC, and we were the most active OWASP project. A lot of the libraries are in place, and this year, we will mostly work on the framework.

'''Knowledge prerequisite:''' Anyone with adequate PHP programming language experience (possibly web application development in PHP). There are hard and easy parts of this project. For tougher parts, familiarity with security concepts, advanced SQL, and advanced PHP and web server configuration is required.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary , Johanna Curiel

==OWASP RBAC Project==
===OWASP RBAC Project===
'''Description:''' ''For the last 6 years, improper access control has been the issue behind two of the Top Ten lists''.

RBAC stands for Role Based Access Control and is the de-facto access control and authorization standard. It simplifies access control and its maintenance for small and enterprise systems alike. NIST RBAC standard has four levels, the second level hierarchical RBAC is intended for this project.

Unfortunately because of many performance and development problems, no suitable RBAC implementation was available until recently, so developers and admins mostly used ACLs and other forms of simple access control methods, which leads to broken and unmaintainable access control over the time.

OWASP provides the RBAC project, as a stand-alone library with very fast access control checks and standard mature code-base. Currently [[PHPRBAC]] which is the PHP version of the RBAC project is released.

'''Expected Results:''' Standard NIST level 2 hierarchical RBAC libraries for different programming languages, specially web-based ones such as C/C++/Java/ASP/ASPX/Python/Perl/etc.

'''Knowledge prerequisite:''' Good SQL knowledge, library development schemes, familiarity with one of the programming languages.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary

'''Skill Level:''' Advanced

For more info, visit [http://phprbac.net phprbac.net]

== OWASP OWTF ==
=== OWASP OWTF - Flexible plugin mappings ===

'''Description:'''

Right now OWTF plugins are categorized based on [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents OWASP Testing Guide v3] , the aim of this project would be to change the existing codebase to handle multiple standard mappings like [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents OWASP Testing Guide v3], [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Testing Guide v4], [http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53 security controls] (+nice to have: [http://www.pentest-standard.org/index.php/Main_Page PTES], [http://www.isecom.org/research/osstmm.html OSSTMM]) along with the facility to add more standards at a later stage.

[https://github.com/7a/owtf/issues/113 Largely from github:]

A huge thank you to Jim Kelly who provided a mapping of the NIST 800-53 security controls to the OWASP Testing Guide!

'''Background:'''

OWTF is currently aligned to the OWASP Testing Guide v3, which is still OK since v4 is far from complete.
However, we need to make the mapping to standards a bit more flexible because:

1) OWASP is shuffling OWASP Testing Guide codes: This means we should move away from using OWASP codes in plugin names in the future.

2) There are other standards, like the NIST 800-53 security controls, that we should also try to map our plugins to.

[http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf The final NIST 800-53 document, from April 2013, can be found here]

'''Project overview''':

The idea of this project is to map the existing plugins (we will worry about the OWASP Testing Guide v4 when that is complete) to the NIST 800-53 security controls.

To do this, (alt least) the following is involved:

1) Change the web_testgroups.cfg configuration file to have a NEW column with the relevant code of the associated NIST 800-53 security control (Jim provided a file with this mapping!)

2) Create a lookup config file for NIST 800-53 security control code <-> description pairs

3) Change the OWTF report so that UNDER the OWASP Testing Guide item, we also show the relevant NIST 800-53 security control (BOTH code + description, as we do with the OWASP Testing Guide).

Aesthetics note on point 3): Maybe this could be shown with a smaller font so that it does not take a lot more space?

4) Nice touch: Add the NIST security controls to the advanced OWTF filter so that a user is able to filter by the security controls they are testing

For more information please see [https://github.com/7a/owtf/issues/113 the github issue]

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Free_Passive_Online_scanner_.2B_Remediation_Boilerplate_Templates OWASP OWTF - Free Passive Online scanner + Remediation Boilerplate Templates] if both projects are accepted.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python knowledge is very welcome but not strictly necessary if there is will to learn, previous exposure to security concepts and penetration testing is very important in this project but some lack of this can be compensated with pre-GSoC involvement and will to learn.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Free Passive Online scanner + Remediation Boilerplate Templates ===

'''Description:'''

An unfortunate reality of penetration testing is the amount of time that is gone via reporting. Explaining vulnerabilities to non technical customers is difficult. Conveying the urgency of fixing XSS, CSRF and many other issues tends to be non-trivial. Especially when the overall security background from the customer is poor (which is common).

This project aims to:
* Provide boilerplate '''vulnerability explanations''' which can easily be copy-pasted into real-world reports
* Provide boilerplate '''vulnerability fixing recommendations''' which can easily be copy-pasted into real-world reports
For example: Linking to the [https://www.owasp.org/index.php/Cheat_Sheets OWASP CheatSheets], providing platform-specific vulnerability fixing information (i.e. Apache vs. IIS vs. nginx), etc. is important here.
* Allow penetration testers to '''easily''' customise and work with alternative remediation templates
* (Obviously) map boilerplate templates to OWTF plugins so that OWTF can show/merge the templates together with the penetration tester notes :).
* Storing remediation template information in a database would be nice to provide additional flexibility to copy-paste into or even generate a msoft word doc, odt, etc.
* Implement '''database import/export functionality''' for the boilerplate templates
* Improve the OWTF interactive report to make this copy-pasting as simple as possible
* Improve the existing “magic bar” OWTF functionality (in the interactive report), which assembles all penetration tester notes in 1 easy to copy-paste page, so that it assembles the generated report like “vulnerability explanation + penetration tester notes + vulnerability fixing recommendations”.
* '''Important community features''':

'''Feature 1) Making templates available on github.io site'''

OWTF wants to help penetration testers use their time most effectively, '''even if they don’t use OWTF directly''', for this reason, as part of this project, '''we would like to setup a github.io website containing the boiler plate templates'''. [http://koto.github.io/blog-kotowicz-net-examples/cursorjacking/ Something like this], but for OWTF and with the boilerplate templates there.

This achieves a number of positive effects in our opinion:

1) Any penetration tester can easily copy-paste anything from the templates into their report, just using a browser with an internet connection (i.e. even if not using OWTF).

2) The templates will be much more exposed to public scrutiny, which will hopefully improve their quality overtime.

3) Contributions to the templates will be easier, even for people without coding experience

4) If successful, this could be thought of a public wiki to explain vulnerabilities and remediation fixes to customers, which will help penetration testers to focus more on the testing aspects of their engagements. By testing more, penetration testers will be able to find more issues and provide more value for money to their customers, which can only help the greater good in the intertubes :).

'''Feature 2) Free passive online scanner on github.io site'''

OWTF allows many passive tests, such as those using third party websites like Google, Bing, etc. searches, as well as handy "Search for vulnerability" search boxes (i.e. Fingerprinting plugin). This feature involves the creation of a '''script''' that produces an interactive OWTF report with the intention of hosting it in the github.io site.

The idea here is to have a passive, JavaScript-only interactive report available on the github.io site, so that people can try OWTF '''without installing anything''', simply visiting a URL.

This would be a normal OWTF interactive report where the user can:
* Enter a target
* Try passive plugins (only the parts that use no tools)
* Play with boilerplate templates from the OWTF interactive report
This would make all the third-party website tests from OWTF usable from any browser, without having to install anything, etc.

The thinking here is that this would make it even easier to use/try OWTF.

'''Script Ideas'''

'''LEGAL CLARIFICATION (Just in case!)''':
The passive online scanner, simply makes OWTF passive testing '''through third party websites''' more accessible to anybody, however it is the user that must 1) click the link manually + 2) do something bad with that afterwards + 3) doing 1 + 2 WITHOUT permission :). Therefore this passive online scanner does not do anything illegal [http://www.slideshare.net/abrahamaranguren/legal-and-efficient-web-app-testing-without-permission More information about why this is not illegal here] (recommended reading!)

The thought here is to have a script that does something like:
* Run "owtf.py -t passive http://demo.testfire.net"
* Modifies the output report to have a big "add target" at the beginning
* Adds necessary JavaScript to the report, so that demo.testfire.net can be changed to the value of Target field input
Essentially, anybody would be able to run (most of) the passive stuff in owtf without having anything installed, this applies mostly to third party website testing (i.e. Google/Bing/NIST/etc. searches), but also to leave the whole OWASP Testing Guide there so that people can use the reports from there too.

The placeholder becomes "demo.testfire.net" essentially, of course, things like theHarvester won't work for this, but Google/Bing/etc. searches will work.
This is somewhat like a JavaScript link generator for OWTF passive plugins, in a sense.

The script would need to "patch" the OWTF report so that the target of choice (i.e. demo.testfire.net) is replaced with a JavaScript function call, probably.
This might be slightly more complicated: Using JavaScript, the url has to be parsed and broken down into stuff like HOST_IP, HOST_PORT etc..
However, using JavaScript, we can loop through the DOM and change all links in the OWTF report, to produce the JavaScript-only, "cloud" version, to host on github.io.

This will make the OWASP Testing Guide, OWTF and the boilerplate templates much more accessible to anyone for trial, demonstration and/or learning purposes.

'''Project extent'''

Since OWTF aims to provides coverage of the [https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing guide] (via web plugins) and the [http://www.pentest-standard.org/index.php/Main_Page Penetration Testing Execution Standard] (PTES) (via net and aux plugins) it is important to realise that a big component of this project is to '''write QUALITY boilerplate templates for a VERY WIDE number of vulnerabilities''' (i.e. all major vulnerabilities!).

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Flexible_plugin_mappings OWASP OWTF - Flexible plugin mapping] if both projects are accepted.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python knowledge is very welcome but not strictly necessary if there is will to learn, previous exposure to security concepts and penetration testing is very important in this project but some lack of this can be compensated with pre-GSoC involvement and will to learn.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Automated Vulnerability Severity Rankings ===

'''Background:'''

OWTF aims to provides coverage of the [https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing guide] (via web plugins) and the [http://www.pentest-standard.org/index.php/Main_Page Penetration Testing Execution Standard] (PTES) (via net and aux plugins).

While most tools focus on fully automated approaches such as “providing the user with a report that cannot be changed”, '''a flawed approach plagued with false positives and false negatives''', OWTF tries to balance automation with the powerful out-of-the-box thinking that only a human can provide.

'''High Level Overview / Problem Introduction'''

At the moment in OWTF it is very useful that '''the human can set the severity for each finding manually'''.
The reasoning here is that the human can take severity context into account, while tools cannot. For example, SQL Injection on a database that has no data, available mechanisms to send http requests/shell commands, etc., '''cannot be ranked as “High” or “Critical”''', the risk in that context is near zero.

All the above being said, '''automated severity rankings are critical for penetration testing efficiency''', this is particularly true when the size of the scope is significant: In a 30 websites assessment, '''if OWTF provided an initial default severity ranking''' (which right now, it does not, a serious limitation), the human should know which of the 30 websites appears to be the weakest and therefore be able to focus their analysis on that based on the partial results from the first 10-30 minutes.

The goal of this project, is therefore to provide the human with an initial automated severity ranking, that the human is able to override, but assists the human to focus analysis on seemingly weaker hosts/websites.

'''Technical Overview'''

IMPORTANT: An automated severity ranking is an initial “risk guess” based on parsing plugin output.

During analysis of this proposed project we identified some possible implementation approaches:

'''Possible Approach 1) Change all OWTF plugins'''

So that they produce:
* Their usual output (as currently)
* '''An initial automated severity ranking (when possible)'''

'''Potential Advantages''':

A big advantage here is logic cohesion, the ranking logic is close to the scanning logic, which makes verification steps perhaps easier to perform (i.e. more context may be available)

'''Potential Drawbacks''':

Parsing plugin output for ranking purposes during plugin execution might slow OWTF, which is a big concern in a project where efficiency is the top goal.

'''Possible Approach 2) Have a background “severity ranker process”'''

The idea here would be to have a process running in the background, plugins do not rank their own output, instead they send a message to the severity ranker process, when this happens, the process parses the output to produce an initial automated ranking.

'''Potential Advantages'''

Plugin ranking happens in the background without slowing OWTF, cool features such as “re-rank this plugin (may send verification tests against target)” become possible from the interactive report via Plug-n-Hack.

'''Potential Drawbacks'''

The ranking logic is de-coupled from the scanning logic (where perhaps more information is available or sending “another request to double-check” might be easier)

'''Expected Outcome and Reporting Implications'''

At the end of the automated plugin severity rankings OWTF should:
1- Provide a default, automated, plugin severity ranking for each plugin
2- Since default severity rankings are less reliable (automated) they will be highlighted as such in the report, for example, providing a confidence percentage or at least a clear visual clue that the ranking is automated such as black/gray background.

If implementing a confidence percentage, OWTF would say "how sure" it is about a given automated ranking. For example "0%" would be "just guessing" and "100%" would be "exploitation verified".
3- When the human overrides or confirms the default ranking, the ranking is considered
"confirmed by a human" (i.e. more reliable) and this highlighting (i.e. black/gray background) is removed
4- A new filter to group vulnerabilities by target will be provided in the report.
5- A new filter to group vulnerabilities for all targets will be provided in the report

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Zest_support_and_ZAP_integration OWASP OWTF - Zest support and ZAP integration] if both projects are accepted.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python knowledge is very welcome but not strictly necessary if there is will to learn, previous exposure to security concepts and penetration testing is very important in this project but some lack of this can be compensated with pre-GSoC involvement and will to learn.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Zest support and ZAP integration ===

'''Brief explanation:'''

The Mozilla foundation has done great work with the Zest initiative, this provides a great automated mechanism to replicate exploitation of security vulnerabilities in a format that makes tool communication easier: For example, ZAP supports Zest, so if OWTF can create a Zest script for a vulnerability in an automated fashion, this may in turn be easier to import into ZAP and other tools.

[https://developer.mozilla.org/en-US/docs/Zest More information on Zest can be found here]

'''High level overview'''

This project, introduces the risk of seriously damaging OWTF performance, therefore, at a high level, we believe there are the following choices:

Choice 1) '''Background execution''' - You try to see if a Zest script can be
created for each plugin in the *background* while owtf keeps running

Choice 2) '''On-demand execution''' - Using some Plug-n-Hack magic, we could
have a button in the report saying "Generate Zest Scripts for plugin"

Choice 3) '''Hybrid approach''' - Implement choice 1 + 2, default to choice 2, but have choice 1
as an option (for example: owtf.py --zest on-demand/background/all)

'''Other project practicality considerations'''

1) '''Background Zest script generation'''

Makes sense on at least the output of scanner plugins (i.e. w3af finds a vuln, we create the Zest script for that vuln)

2) '''On-demand Zest script generation from plugin output'''

From the report, when you select a plugin, *could* be useful

3) '''On-demand Zest script generation from HTTP transaction'''

Selecting an HTTP transaction from the transaction log + click "generate Zest script" from there would also be very useful

4) '''ZAP integration'''

After generating the Zest script, the next step is to send the Zest script to ZAP, possibly using [http://code.google.com/p/zaproxy/wiki/ApiDetails the ZAP API], and perhaps with some help from [https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ Plug-n-Hack] (which allows us to send commands to our proxy, and from there, we could send commands to ZAP, or alternatively perhaps send commands to ZAP directly via Plug-n-Hack).

The solution will ideally be as simple and extensible as possible so that the codebase does not become unmaintanable.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Automated_Vulnerability_Severity_Rankings OWASP OWTF - Automated Plugin Severity Rankings] if both projects are accepted.

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Some previous exposure to security concepts, penetration testing, Python and development in general is important for this project.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Improved Proxification and Plug-n-Hack support ===

'''Brief explanation:'''

The Mozilla foundation has done great work with [https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ the Plug-n-Hack standard (PnH)], which allows security tools to provide better interaction with web browsers. For example, it allows us to send commands from the browser to the OWTF proxy, which opens the door to a much better user experience. Please note that '''OWTF already supports Plug-n-Hack Phase 1'''.

'''Overview'''

This project is divided in the following pieces of functionality:

'''1) Plug-n-Hack v2/v3 support'''

There are many other features in Phase 2 that could be implemented and on top of that Plug-n-Hack v3 should be available this summer.
The aim of this project would be to try to cover as much as possible from the Plug-n-Hack standard as relevant to OWTF, for example:

'''OWTF Plug-n-Hack mode'''

OWTF starts in proxy mode, waiting for instructions, the user can drive OWTF from the browser (i.e. using the browser as a GUI, instead of the command line).

'''OWTF improved report interactivity via Plug-n-Hack'''

Provide new functions from the OWTF interactive report, for example “launch this plugin again”, “send this HTTP request again”, etc.

[https://www.youtube.com/watch?v=pYFtLA2yTR8 Please see this demo to see the newest Plug-n-Hack additions]

[https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ For more information about plug and hack please see this]

'''2) Improved Tool and Plugin proxification'''

At the moment, not all Tools or plugins are proxified in OWTF. This means that not all plugins send their requests through the OWTF MiTM proxy. This is a problem because OWTF performs analysis on HTTP transactions passively, and right now it cannot see '''all HTTP requests sent''' due to some unproxified tools and plugins.

An additional component of this project is therefore to proxify most of the tools and plugins. This may be possible using a utility like proxychains and/or tweaking the inbound proxy without disturbing current functionality.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience is very welcome but not strictly necessary, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Stateful Browser with configurable authentication ===

'''Brief explanation:'''

The automated functionality of OWASP OWTF is currently limited to the non-authenticated portion of a website. We would like to implement authentication support through:

1) OWTF parameters

2) Configuration files

What we would like to do here is to leverage the [http://wwwsearch.sourceforge.net/mechanize/ powerful mechanize python library] and build at least support for the following authentication options:
* Basic authentication [https://github.com/7a/owtf/issues/9 Already implemented here]
* Cookie based authentication
* Form-based authentication
* Client-side certificates

'''Other important features'''

* GUI mechanism to make authentication setup (super-)easy for the user via [https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ Plug-n-Hack]
* Ability to '''keep track of several user roles''' and allow easy switching via [https://developer.mozilla.org/en-US/docs/Plug-n-Hack Plug-n-Hack]

Additionally, we would welcome here a feature to detect when the user has been logged off, to log OWTF back in again before retrying the next request. <-- The proxy is probably a better place to implement this since external tools would also benefit from this. This feature will have to be coordinated with the MiTM proxy feature (already implemented).

The solution will ideally be as simple and extensible as possible so that the codebase does not become unmaintanable.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with the mechanize library or HTTP state is very welcome but not strictly necessary, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Testing Framework Improvements ===

'''Brief explanation:'''

As OWASP OWTF grows it makes sense to build custom unit tests to automatically re-test that functionality has not been broken. In this project we would like to improve the existing unit testing framework so that creating OWASP OWTF unit tests is as simple as possible and all missing tests for new functionality are created. The goal of this project is to update the existing Unit Test Framework to create all missing tests as well as improve the existing ones to verify OWASP OWTF functionality in an automated fashion.

'''Top features'''

In this improvement phase, the Testing Framework should:
* (Top Prio) Focus more on functional tests
For example: Improve coverage of OWASP Testing Guide, PTES, etc. (lots of room for improvement there!)
* (Top Prio) Put together a great wiki documentation section for contributors
The goal here is to help contributors write tests for the functionality that they implement. This should be as easy as possible.
* (Top Prio) Fix the current Travis issues :)
* (Nice to have) Bring the unit tests up to speed with the codebase
This will be challenging but very worth trying after top priorities.
The wiki should be heavily updated so that contributors create their own unit tests easily moving forward.

'''General background'''

The Unit Test Framework should be able to:
* Define test categories: For example, "all plugins", "web plugins", "aux plugins", "test framework core", etc. (please see [http://www.slideshare.net/abrahamaranguren/introducing-owasp-owtf-workshop-brucon-2012 this presentation] for more background)
* Allow to regression test isolated plugins (i.e. "only test _this_ plugin")
* Allow to regression test by test categories (i.e. "test only web plugins")
* Allow to regression test everything (i.e. plugins + framework core: "test all")
* Produce meaningful statistics and easy to navigate logs to identify which tests failed and ideally also hints on how to potentially fix the problem where possible
* Allow for easy creation of _new_ unit tests specific to OWASP OWTF
* Allow for easy modification and maintenance of _existing_ unit tests specific to OWASP OWTF
* Perform well so that we can run as many tests as possible in a given period of time
* Potentially leverage the python unittest library: [http://docs.python.org/2/library/unittest.html http://docs.python.org/2/library/unittest.html]

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* Performant and automated regression testing
* Unit tests for a wide coverage of OWASP OWTF, ideally leveraging the Unit Test Framework where possible
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with unit tests and automated regression testing would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Python version upgrade and compatibility ===

'''IMPORTANT WARNING: This project is considered to be < 2 weeks of effort BUT can be proposed to complement ANOTHER OWTF idea, the last few weeks of GSoC seems the best moment to start this'''

'''Brief explanation:'''

Right now OWASP OWTF works on Python 2.6.5-2.7.3 (might work on surrounding versions too), the aim of this project would be to change the existing codebase so that it additionally works on newer python versions too, for example Python 3.3.
The intention here is to take advantage of improvements in newer python versions when available while letting OWASP OWTF work on older python versions too (i.e. 2.6.5) if that is the only option available.
The solution will ideally be as simple and extensible as possible so that the codebase does not become unmaintanable due to compatibility.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* Performant and reliable OWASP OWTF execution on multiple python versions, in particular the latest python version (i.e. 3.3.x) as well as the previous 2.6.5-2.7.3 range.
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with python version upgrades and python version compatibility implementations, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

==OWASP PCI TOOLKIT==
===OWASP PCI TOOLKIT===
[[File:Pci-toolkit-items-small.gif]] OWASP PCI toolkit is an Open Source project built using Google Engine App, that will help organizations scope the PCI-DSS requirements for their System Components. The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards.

In order to comply with this standard, organizations need to understand the PCI-DSS requirements. Many of these requirements use OWASP guidelines as their baseline.

The OWASP PCI toolkit is a project focused on helping organization understand how OWASP guidelines apply to the PCI-DSS requirements.

'''Expected results:'''

4 complete modules built as a Google App Engine:
http://pci-toolkit.appspot.com/

'''Knowledge Prerequisite:'''

Skill Level: Easy-Medium
Python, HTML, CSS, Google App Engine.

Affinity with financial institutions, Web security and credit card-online transactions

'''OWASP project page:'''

https://www.owasp.org/index.php/Category:OWASP_PCI_Project

Mentor: Johanna Curiel - emai: firstname.lastname@owasp.org

== OWASP iGoat ==
=== OWASP iGoat ===

'''Brief explanation:'''

Right now OWASP iGoat works fine as a full universal iOS app on iPhone and iPads up to iOS 6.x and Xcode 4.x. It needs to be updated to properly function under iOS 7.x and Xcode 5.x, which will require some code maintenance, GUI changes, and so on.

Although it is primarily maintenance items that need the updating, the student will gain an intimate familiarity with how the iGoat platform works, including how to write and plug-in new exercise modules. Writing additional exercises, with all due credit, will also be encouraged in an optional second phase of this project.

For background on OWASP iGoat please see: https://www.owasp.org/index.php/OWASP_iGoat_Project

'''Expected results:'''

* iGoat functions properly in all current aspects under iOS 7.x, compiled under Xcode 5.x.
* All GUI, buttons, and other presentation layer aspects of iGoat are compliant with iOS 7.x look and feel.
* (Optionally) write one or more new iGoat exercise modules, based on existing design descriptions to be provided by the project mentor.

'''Knowledge Prerequisite:'''

iOS app development in Xcode using Objective C will be quite necessary. Familiarity with iOS 7.x user interface updates additionally helpful.

'''Mentor: Ken van Wyk - OWASP iGoat Project Leader - Contact: ken@krvw.com'''

== [https://www.owasp.org/index.php/ZAP OWASP ZAP] ==
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Advanced access control testing ===

'''Brief explanation:'''

Access control testing is typically difficult for security tools to automate. However previous Google Summer of Code projects have added session, authentication, user and role handling to ZAP, which provide an ideal basis for advanced access control testing.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

This development would allow (semi) automated access control testing by:
* Maintaining and displaying different site trees (application maps) for different users/roles
* Providing tools which access all of the content accessible via one user/role which should not be accessible via another user/role
* Ideally allow resources to be tied to users/roles to allow enable horizontal privilege testing

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Scripted Add-ons ===

'''Brief explanation:'''

ZAP supports all JSR 223 scripting languages, but only for a limited number of purposes. This development would allow 'full' add-ons to be written in any JSR 223 language.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

* Users will be able to 'full' add-ons in any JSR 233 scripting language
* A set of example add-ons demonstrating as much functionality as possible should be developed in at least Java Script, Jython and Jruby.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - AMF Support ===

'''Brief explanation:'''

ZAP has only very limited support for AMF and does not provide an effective graphical representation of it.
This development will add full support for AMF.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

* De-serialise and display AMF messages in ZAP graphically (based on existing POC code)
* Expose the AMF data as parameters so that ZAP can scan them
* Add new AMF specific scan rules as required
* Implement in a way that makes it easier for ZAP to support other technologies (such as Java applets, Silverlight)

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: Colm O'Flaherty - OWASP ZAP Core team'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Web Service (SOAP) scanning ===

'''Brief explanation:'''

ZAP has only very limited support for web service scanning and has no understanding of WSDL.
This development will add full support for exploring and scanning SOAP based web services.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

The development will allow ZAP to parse WSDL and populate the Sites tree with all of the end points defined. It should also enhance the ZAP scanning capabilities to specifically attack the end points for as wide a range of vulnerabilities. Test cases should be written in [http://code.google.com/p/wavsep/ wavsep] format and contributed back to that project.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - As a long running service ===

'''Brief explanation:'''

ZAP started out as a GUI only desktop tool. It now supports a headless 'daemon' mode but it is still not suitable for running as a long running service. This will require much heavier use of the database, and ideally will allow different databases to be used.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

ZAP able to run as a (very) long running service. There must be no memory leaks code and ideally there should still be very little latency while proxying through ZAP.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - GUI unit test framework ===

'''Brief explanation:'''

While ZAP does have some low level unit tests it doesnt have any unit tests for the UI. This means that sometimes changes can break the UI without being immediately apparent.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

A unit test framework which will allow the GUI to be easily tested. A set of unit tests which test the main GUI features and can be easily extended.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

== [https://www.owasp.org/index.php/ESAPI OWASP ESAPI] 2.x ==
=== [https://www.owasp.org/index.php/ESAPI OWASP ESAPI] 2.x - Security Configuration ===

'''Brief explanation:'''
There are currently more than a half-dozen of open Google Issues in ESAPI regarding the security configuration component (e.g., see [http://code.google.com/p/owasp-esapi-java/issues/list?q=component%3DSecurityConfiguration ESAPI Security Configuration Issues]).

The ESAPI interface for its configuration (SecurityConfiguration) is overly complicated; it has a 'getter' method specific to almost every ESAPI configuration property. The rules for how and where the ESAPI.properties file is found are overly complicated making questions about it one of the most frequently asked questions on forums such as Stack Exchange and the ESAPI mailing lists. This complication leads to a unduly intricate, non-modular reference implementation (DefaultSecurityConfiguration) that makes it difficult to extend in terms of new functionality.

A new, simpler security configuration interface and implementation is needed. Such an implementation would not only be useful for ESAPI 2.x, but could very well be used to build the configurator needed by ESAPI 3.

As part of this GSoC project, expectations would not only to address as many of the open security configuration issues as possible, but to also go beyond this to allow a framework for additional extensions in terms of functionality.

'''Expected results:'''
1) An improved, but simpler API for the security configuration part of ESAPI.
2) Alternate configuration stores other than Java properties files (e.g., XML, database), to be supported.
3) The ability to split the ESAPI configuration data into smaller, more manageable chunks to result in more maintainibility and allow for better enforcement of corporate security policies.
4) Continued backward compatibility with ESAPI 2.1.x or an extremely simple migration path forward.

'''Knowledge Prequisite:'''

Since the ESAPI 2.x project is written in Java, a good knowledge of Java is essential. A strong knowledge of JUnit will also be helpful in creating unit test cases. A working knowledge of XML or JDBC may also prove helpful.

'''Mentor: [https://www.owasp.org/index.php/User:Kevin_W._Wall Kevin W. Wall] - OWASP ESAPI for Java Project Leader'''

== [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP Seraphimdroid Project] ==
=== [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP Seraphimdroid Project] ===

'''Brief explanation:'''
OWASP Seraphimdroid is relatively new OWASP project regarding Android security. Seraphimdroid Android application should become mobile device safeguard, while on the other hand it should also provide user information and knowledge about security risks on his phone (in personalized way). The idea of security guard is based solely on heuristics, that most of the risks costing money and damaging user's privacy can be stopped without huge online database with signatures, and huge malware analysis lab. As part of this GSoC project, focus will be on finding way to stop as many risks that can cost money (premium calls, sms, ussd...) or harm user privacy as possible and to enhance UX of mobile application.

'''Expected results:'''
* Building features for stopping threats that can cost money originating from third party applications (continue where it was stopped)
* Build and propose features that can stop third party application damage user's privacy by sending user's data out of the mobile device (using internet)
* Enhance UI/UX

'''Knowledge Prequisite:'''

Since the OWASP Seraphimdroid project is written in Java and Android SDK, a good knowledge of Java, Android OS and SDK are essential. Good knowledge of XML and IP protocol can be useful.

'''Mentor: [https://www.owasp.org/index.php/User:Nikola_Milosevic Nikola Milosevic] - OWASP Seraphimdroid Project Leader'''

== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] ==
=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - ModSecurity Ruby API ===
'''Brief explanation:'''
Adding the capability of rapid prototyping to ModSecurity functionalities trough scripts will open the possibility for easy rules production and customization, It also opens the possibility for a large community such as Ruby developers to create their own customization on the top of ModSecurity and so customize their own rules, analog of today's Lua support.

'''Expected results:'''
An implementation able to handle Ruby scripts which will interact to ModSecurity as Lua does.

'''References:'''
Embedding Ruby into C++ (ModSecurity is C, using C++ as reference):
http://aeditor.rubyforge.org/ruby_cplusplus/index.html
ModSecurity Reference Manual, Lua:
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecRuleScript

'''Knowledge Prerequisite:'''
C and Ruby programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - ModSecurity Python API ===
'''Brief explanation:'''
Adding the capability of rapid prototyping to ModSecurity functionalities trough scripts will open the possibility for easy rules production and customization, It also opens the possibility for a large community such as Python developers to create their own customization on the top of ModSecurity and so customize their own rules, analog of today's Lua support.

'''Expected results:'''
An implementation able to handle Python scripts which will interact to ModSecurity as Lua does.

'''References:'''
Embedding Python into C/C++:
http://docs.python.org/3.3/extending/embedding.html
ModSecurity Reference Manual, Lua:
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecRuleScript

'''Knowledge Prerequisite:'''
C and Python programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Create "Sniffer-Mode" ===

'''Brief explanation:'''

The ModSecurity code includes a "standalone" version that wraps a light weight Apache/APR around the ModSecurity code. This is used as the basis for the ports to the IIS/Nginx web server platforms. The goal for this project task is to extend this standalone version so that it can accept a data feed of network traffic (e.g. libpcap) data as input and apply the ModSecurity CRS rules. Possible solutions could be:
* Create a ModSecurity "plugin" for the Snort IDS.
* Create a ModSecurity "plugin" for the Suricata IDS.
* Add libpcap sniffer wrapper to standalone ModSecurity code to directly pull data off the wire.

'''Expected results:'''

This new sniffer mode would allow organizations to run ModSecurity/OWASP ModSecurity CRS in an out of line mode as they do IDS systems.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Implement DoS Prevention Code ===

'''Brief explanation:''' https://github.com/SpiderLabs/ModSecurity/issues/416

Implement a request velocity learning engine to identify dynamic DoS thresholds for both the site and for the particular URL.

'''Expected results:'''

The new C code in ModSecurity will allow us to add new DoS Protection methods to the OWASP ModSecurity CRS.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Create a Positive Learning/Profile Engine ===

'''Brief explanation:''' See this academic/research paper for ideas of the type of learning we are looking for - http://www.cs.ucsb.edu/~vigna/publications/2003_kruegel_vigna_ccs03.pdf

ModSecurity needs a profiling engine that implements the various AppSensor Detection Points - http://blog.spiderlabs.com/2011/08/implementing-appsensor-detection-points-in-modsecurity.html.

'''Expected results:'''

The new engine will implement more detection points to detect abnormal request attributes.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Create an Engine to Detect Application Flow Anomalies ===

'''Brief explanation:'''

Need an engine that can track normal application flow paths (click-flows) for business logic transactions - such as transferring money from accounts. After profiling normal application path flows, we want to then be able to alert to anomalies. This type of logic can help to prevent Banking Trojan attacks.

Example - let's say an application has a multi-step checkout process to purchase an item. This new engine would be able to profile/learn which URLs are accessed in what order and identify if clients skip steps or jump directly to other URLs in the flow.

'''Expected results:'''

The engine will be able to alert on anomalous application flows.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

== [https://www.owasp.org/index.php/OWASP_Bywaf_Project OWASP ByWaf (CRS)] ==
=== [https://www.owasp.org/index.php/OWASP_Bywaf_Project OWASP ByWaf (CRS)] - PEP-8 compliant ===

'''Brief explanation:'''

Need someone who make our code more pep-8 compliant.

'''Expected results:'''

Get our code with the most common accepted Python convention.

'''Knowledge Prerequisite:'''

Advanced level in Python

Knowlage in PEP-8

'''Mentor: Roey Katz and Rafael Gil - OWASP Bywaf Project Leader'''

=== [https://www.owasp.org/index.php/OWASP_Bywaf_Project OWASP ByWaf (CRS)] - Plug-in maker ===

'''Brief explanation:'''

Making some plug-ins for penetration testing, all of them with bywaf's template.

'''Expected results:'''

The following plug-ins are expected:

SQL Injection

Cross Site Scripting

Directory Traversal

WebDav detector

Put detector

Default pages (IIS and Apache)

'''Knowledge Prerequisite:'''

Python
OWASP TOP TEN
HTTP and HTML

'''Mentor: Roey Katz and Rafael Gil- OWASP Bywaf Project Leader'''

GSoC2014 Ideas

2014-03-04T14:37:20Z

Rcbarnett:

==OWASP Project Requests==

=== OWASP Hackademic Challenges - New challenges and Improvements to the existing ones ===

'''Brief Explanation:'''

The challenges that have been implemented so far include: web application challenges covering several vulnerabilities included in the OWASP Top 10, cryptographic challenges, and entire virtual machines including several vulnerabilities.
New challenges need to be created in order to cover a broader set of vulnerabilities.
Also existing challenges can be modified to accept a broader set of valid answers, e.g. by using regular expressions.

Ideas on the project:

* Simulated simple buffer overflows
* SQL injections
* Man in the middle simulation
* Bypassing regular expression filtering
* Your idea here

'''Expected Results:'''

New cool challenges

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML and possibly Javascript. Good understanding of Application Security and related vulnerabilities.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== OWASP Hackademic Challenges - Source Code testing environment ===

'''Brief Explanation:'''

Existing challenges are based on a dynamic application testing concept. We would like to work on a project that will give the capability to the attacker to review a vulnerable piece of source code, make corrections and see the result in a realistic (but yet safe) runtime environment. The code can either be run if needed or tested for correctness and security. The implementation challenges of such a project can be numerous, including creating a realistic but also secure environment, testing submitted solutions and grading them in an automatic manner. At the same time there are now numerous sites that support submitting code and then simulate or implement a compiler's functionality.

'''Expected Results:'''

A source code testing and improvement environment where a user will be able to review, improve and test the result of a piece of source code.

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML and possibly Java. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== OWASP Hackademic Challenges - Challenge Sandbox ===

Now, in order to create a challenge, one has to validate the solution with regular expressions (or just plaintext comparison) and report success or failure to the backend,
we'd like the ability to write a normal vulnerable web application as a challenge and leave it to hackademic to make sure that the server is not affected.
Since this is probably the most difficult task proposed, if you are considering it, please get in touch with us early on so we can discuss about it and plan it correctly.

Ideas on the project:

''' *Administrator's point of view* '''

Create an infrastructure that spawns virtual environments for users while keeping the load reasonable on the server(s).
Or configure apache,php,mysql in a way that allows for multiple instances of the programms to run in parallel completely seperated from the rest of the server.
The student is expected to provide configuration scripts that do the above

''' *Coder's Way* '''

This is better explained with an example:
In order to create an sql injection challenge one should be able to call a common unsecure mysql execute statement function.
The student can override common functions like this providing their own implementation of a very temporary database (based on flat files or nosql solutions e.t.c.).
The new functions should be able to detect the sqli and apply its results in a secure way(if the student drops a table no actual tables should be dropped but the table should not be visible to the student anymore).

''' * Your solution here * '''

The above solutions are by no way complete,their intention is to start you thinking.
This is a difficult task so if you consider takling it talk to us early on so we can reach a good solution which is possible in the GSoC timeframe.

''' Expected results '''

You should be able to run a big enough subset of OWASP WebGoat PHP with minimal modification as a Hackademic Challenge

=== OWASP Hackademic Challenges - CMS improvements ===

'''Brief Explanation:'''

The new CMS was created during last year's GSOC. We have received feedback from users that suggest various improvements regarding functionality e.g. better user, teacher and challenges management. There are also some security improvements that are needed and in general any functionality that adds up to the educational nature of the project is more than welcome.

Ideas on this project:

* ''' Template''' *

Since it's creation the project has received a good number of new features, but the visual/ux/ui part has never gotten much love.
It would be good if we had a new template with proper ui design.

* '''Questionaire creation plugin''' *

We'd like the admin to be able to create questionaires, assign rules for each question (e.g. correct answer +2pts incorrect answer -2, no answer 0) and assign them to students as homework/exams.
The grading can either be done automatically (for multiple choice) or be submitted to the creator of the questionaire.

* '''Ability to show different articles on the user's home screen'''

Now each user is served the latest article in her/his home screen. We need the ability for either the teacher/admin to be able to define what article each class is served.

* '''Gamification of the user's progress''' *

A series of plugins and a template which allow the user to earn badges as they solve challenges and a better visual representation of their progress.

* '''Ability to define series of challenges'''

The teacher/admin should be able to define a series of challenges (e.g. 2,5,3,1) which are meant to be solved in that order and if one is not solved then the student can't try the next one.

* ''' Tagging of articles, users, challenges '''

A user should be able to put tags on articles and challenges if he is a student and on users, classes, articles and challenges if he is a teacher.
Also the user should be able to search according to the tags.

* '''Your idea here'''

We welcome new ideas to make the project look awesome.

'''Expected Results:'''

New features and security improvements on the CMS part of the project.

'''Knowledge Prerequisites:'''

Comfortable in PHP and HTML. Good understanding of Application Security and related vulnerabilities if you undertake security improvements.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

===OWASP WebGoatPHP===
'''Description:'''
[[Webgoat]] is a deliberately insecure open source software made by OWASP using Java programming language. It has a set of challenges and steps, each providing the user with one or more web application vulnerability which user tries to solve. There are also hints and auto-detection of correct solutions.
Since Java is not the most common web application programming language, and it doesn't have many of the bugs other languages such as PHP have when it comes to security, OWASP has [[OWASP_WebGoat_Reboot2012|dedicated in 2012]] an amount of $5000 for promotion of WebGoatPHP.

If you want to know more about WebGoatPHP, I suggest downloading and giving WebGoat a try. It is one of OWASP prides (about 200000 downloads).

'''Expected Results:''' WebGoatPHP will be a deliberately insecure PHP web application which operates in different modes. A contest mode where challenges are selected by an admin and the system starts a contest. Admins can open up hints for participants and manage everything. A workshop mode, where the educator has control of the most of application features, as well as feedback of user activities and is ideal for learning environments, and a single mode where someone can browse challenges and solve them.

'''Knowledge prerequisite:''' You just need to know PHP. You are supposed to define flawed systems, which is not the hardest thing. Familiarity with web application security and SQL is recommended.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

===OWASP CSRF Guard===
'''Description:''' [[Cross-Site_Request_Forgery_(CSRF)|CSRF]] is a complicated yet very effective web attack. The most important thing about CSRF is that it's hard to properly defend against it, specially when it comes to Web 2 and AJAX. We have had discussions on means of mitigating CSRF for years at OWASP, and are now ready to develop libraries for it. Many of the key ideas of this library can be found at [http://www.cs.sunysb.edu/~rpelizzi/jcsrf.pdf].

'''Expected Results:''' A transparent Apache 2 module properly mitigating all POST CSRF attacks, as well as a lightweight PHP library doing the same.

'''Knowledge prerequisites:''' Knowing CSRF and at least one way to defend against it, PHP, C/C++, Linux.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary

===OWASP PHP Security Project===

'''Description:'''
OWASP PHP Security project plans to gather around secure PHP libraries, and provide a full featured framework of libraries for secure web applications in PHP, both as separate de-coupled libraries and as a whole secure web application framework. Many aspects of this project are already handled, and are being added to OWASP.

'''Expected Results: ''' Result of this project is much more security among PHP applications. Most PHP applications are vulnerable and there's no central approach to secure them (due to open source nature). Many people look at OWASP for such information.

Last year, we got GSoC people working on OWASP PHPSEC, and we were the most active OWASP project. A lot of the libraries are in place, and this year, we will mostly work on the framework.

'''Knowledge prerequisite:''' Anyone with adequate PHP programming language experience (possibly web application development in PHP). There are hard and easy parts of this project. For tougher parts, familiarity with security concepts, advanced SQL, and advanced PHP and web server configuration is required.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary , Johanna Curiel

===OWASP RBAC Project===
'''Description:''' ''For the last 6 years, improper access control has been the issue behind two of the Top Ten lists''.

RBAC stands for Role Based Access Control and is the de-facto access control and authorization standard. It simplifies access control and its maintenance for small and enterprise systems alike. NIST RBAC standard has four levels, the second level hierarchical RBAC is intended for this project.

Unfortunately because of many performance and development problems, no suitable RBAC implementation was available until recently, so developers and admins mostly used ACLs and other forms of simple access control methods, which leads to broken and unmaintainable access control over the time.

OWASP provides the RBAC project, as a stand-alone library with very fast access control checks and standard mature code-base. Currently [[PHPRBAC]] which is the PHP version of the RBAC project is released.

'''Expected Results:''' Standard NIST level 2 hierarchical RBAC libraries for different programming languages, specially web-based ones such as C/C++/Java/ASP/ASPX/Python/Perl/etc.

'''Knowledge prerequisite:''' Good SQL knowledge, library development schemes, familiarity with one of the programming languages.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary

'''Skill Level:''' Advanced

For more info, visit [http://phprbac.net phprbac.net]

=== OWASP OWTF - Flexible plugin mappings ===

'''Description:'''

Right now OWTF plugins are categorized based on [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents OWASP Testing Guide v3] , the aim of this project would be to change the existing codebase to handle multiple standard mappings like [https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents OWASP Testing Guide v3], [https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents OWASP Testing Guide v4], [http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53 security controls] (+nice to have: [http://www.pentest-standard.org/index.php/Main_Page PTES], [http://www.isecom.org/research/osstmm.html OSSTMM]) along with the facility to add more standards at a later stage.

[https://github.com/7a/owtf/issues/113 Largely from github:]

A huge thank you to Jim Kelly who provided a mapping of the NIST 800-53 security controls to the OWASP Testing Guide!

'''Background:'''

OWTF is currently aligned to the OWASP Testing Guide v3, which is still OK since v4 is far from complete.
However, we need to make the mapping to standards a bit more flexible because:

1) OWASP is shuffling OWASP Testing Guide codes: This means we should move away from using OWASP codes in plugin names in the future.

2) There are other standards, like the NIST 800-53 security controls, that we should also try to map our plugins to.

[http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf The final NIST 800-53 document, from April 2013, can be found here]

'''Project overview''':

The idea of this project is to map the existing plugins (we will worry about the OWASP Testing Guide v4 when that is complete) to the NIST 800-53 security controls.

To do this, (alt least) the following is involved:

1) Change the web_testgroups.cfg configuration file to have a NEW column with the relevant code of the associated NIST 800-53 security control (Jim provided a file with this mapping!)

2) Create a lookup config file for NIST 800-53 security control code <-> description pairs

3) Change the OWTF report so that UNDER the OWASP Testing Guide item, we also show the relevant NIST 800-53 security control (BOTH code + description, as we do with the OWASP Testing Guide).

Aesthetics note on point 3): Maybe this could be shown with a smaller font so that it does not take a lot more space?

4) Nice touch: Add the NIST security controls to the advanced OWTF filter so that a user is able to filter by the security controls they are testing

For more information please see [https://github.com/7a/owtf/issues/113 the github issue]

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Free_Passive_Online_scanner_.2B_Remediation_Boilerplate_Templates OWASP OWTF - Free Passive Online scanner + Remediation Boilerplate Templates] if both projects are accepted.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python knowledge is very welcome but not strictly necessary if there is will to learn, previous exposure to security concepts and penetration testing is very important in this project but some lack of this can be compensated with pre-GSoC involvement and will to learn.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Free Passive Online scanner + Remediation Boilerplate Templates ===

'''Description:'''

An unfortunate reality of penetration testing is the amount of time that is gone via reporting. Explaining vulnerabilities to non technical customers is difficult. Conveying the urgency of fixing XSS, CSRF and many other issues tends to be non-trivial. Especially when the overall security background from the customer is poor (which is common).

This project aims to:
* Provide boilerplate '''vulnerability explanations''' which can easily be copy-pasted into real-world reports
* Provide boilerplate '''vulnerability fixing recommendations''' which can easily be copy-pasted into real-world reports
For example: Linking to the [https://www.owasp.org/index.php/Cheat_Sheets OWASP CheatSheets], providing platform-specific vulnerability fixing information (i.e. Apache vs. IIS vs. nginx), etc. is important here.
* Allow penetration testers to '''easily''' customise and work with alternative remediation templates
* (Obviously) map boilerplate templates to OWTF plugins so that OWTF can show/merge the templates together with the penetration tester notes :).
* Storing remediation template information in a database would be nice to provide additional flexibility to copy-paste into or even generate a msoft word doc, odt, etc.
* Implement '''database import/export functionality''' for the boilerplate templates
* Improve the OWTF interactive report to make this copy-pasting as simple as possible
* Improve the existing “magic bar” OWTF functionality (in the interactive report), which assembles all penetration tester notes in 1 easy to copy-paste page, so that it assembles the generated report like “vulnerability explanation + penetration tester notes + vulnerability fixing recommendations”.
* '''Important community features''':

'''Feature 1) Making templates available on github.io site'''

OWTF wants to help penetration testers use their time most effectively, '''even if they don’t use OWTF directly''', for this reason, as part of this project, '''we would like to setup a github.io website containing the boiler plate templates'''. [http://koto.github.io/blog-kotowicz-net-examples/cursorjacking/ Something like this], but for OWTF and with the boilerplate templates there.

This achieves a number of positive effects in our opinion:

1) Any penetration tester can easily copy-paste anything from the templates into their report, just using a browser with an internet connection (i.e. even if not using OWTF).

2) The templates will be much more exposed to public scrutiny, which will hopefully improve their quality overtime.

3) Contributions to the templates will be easier, even for people without coding experience

4) If successful, this could be thought of a public wiki to explain vulnerabilities and remediation fixes to customers, which will help penetration testers to focus more on the testing aspects of their engagements. By testing more, penetration testers will be able to find more issues and provide more value for money to their customers, which can only help the greater good in the intertubes :).

'''Feature 2) Free passive online scanner on github.io site'''

OWTF allows many passive tests, such as those using third party websites like Google, Bing, etc. searches, as well as handy "Search for vulnerability" search boxes (i.e. Fingerprinting plugin). This feature involves the creation of a '''script''' that produces an interactive OWTF report with the intention of hosting it in the github.io site.

The idea here is to have a passive, JavaScript-only interactive report available on the github.io site, so that people can try OWTF '''without installing anything''', simply visiting a URL.

This would be a normal OWTF interactive report where the user can:
* Enter a target
* Try passive plugins (only the parts that use no tools)
* Play with boilerplate templates from the OWTF interactive report
This would make all the third-party website tests from OWTF usable from any browser, without having to install anything, etc.

The thinking here is that this would make it even easier to use/try OWTF.

'''Script Ideas'''

'''LEGAL CLARIFICATION (Just in case!)''':
The passive online scanner, simply makes OWTF passive testing '''through third party websites''' more accessible to anybody, however it is the user that must 1) click the link manually + 2) do something bad with that afterwards + 3) doing 1 + 2 WITHOUT permission :). Therefore this passive online scanner does not do anything illegal [http://www.slideshare.net/abrahamaranguren/legal-and-efficient-web-app-testing-without-permission More information about why this is not illegal here] (recommended reading!)

The thought here is to have a script that does something like:
* Run "owtf.py -t passive http://demo.testfire.net"
* Modifies the output report to have a big "add target" at the beginning
* Adds necessary JavaScript to the report, so that demo.testfire.net can be changed to the value of Target field input
Essentially, anybody would be able to run (most of) the passive stuff in owtf without having anything installed, this applies mostly to third party website testing (i.e. Google/Bing/NIST/etc. searches), but also to leave the whole OWASP Testing Guide there so that people can use the reports from there too.

The placeholder becomes "demo.testfire.net" essentially, of course, things like theHarvester won't work for this, but Google/Bing/etc. searches will work.
This is somewhat like a JavaScript link generator for OWTF passive plugins, in a sense.

The script would need to "patch" the OWTF report so that the target of choice (i.e. demo.testfire.net) is replaced with a JavaScript function call, probably.
This might be slightly more complicated: Using JavaScript, the url has to be parsed and broken down into stuff like HOST_IP, HOST_PORT etc..
However, using JavaScript, we can loop through the DOM and change all links in the OWTF report, to produce the JavaScript-only, "cloud" version, to host on github.io.

This will make the OWASP Testing Guide, OWTF and the boilerplate templates much more accessible to anyone for trial, demonstration and/or learning purposes.

'''Project extent'''

Since OWTF aims to provides coverage of the [https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing guide] (via web plugins) and the [http://www.pentest-standard.org/index.php/Main_Page Penetration Testing Execution Standard] (PTES) (via net and aux plugins) it is important to realise that a big component of this project is to '''write QUALITY boilerplate templates for a VERY WIDE number of vulnerabilities''' (i.e. all major vulnerabilities!).

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Flexible_plugin_mappings OWASP OWTF - Flexible plugin mapping] if both projects are accepted.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python knowledge is very welcome but not strictly necessary if there is will to learn, previous exposure to security concepts and penetration testing is very important in this project but some lack of this can be compensated with pre-GSoC involvement and will to learn.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Automated Vulnerability Severity Rankings ===

'''Background:'''

OWTF aims to provides coverage of the [https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing guide] (via web plugins) and the [http://www.pentest-standard.org/index.php/Main_Page Penetration Testing Execution Standard] (PTES) (via net and aux plugins).

While most tools focus on fully automated approaches such as “providing the user with a report that cannot be changed”, '''a flawed approach plagued with false positives and false negatives''', OWTF tries to balance automation with the powerful out-of-the-box thinking that only a human can provide.

'''High Level Overview / Problem Introduction'''

At the moment in OWTF it is very useful that '''the human can set the severity for each finding manually'''.
The reasoning here is that the human can take severity context into account, while tools cannot. For example, SQL Injection on a database that has no data, available mechanisms to send http requests/shell commands, etc., '''cannot be ranked as “High” or “Critical”''', the risk in that context is near zero.

All the above being said, '''automated severity rankings are critical for penetration testing efficiency''', this is particularly true when the size of the scope is significant: In a 30 websites assessment, '''if OWTF provided an initial default severity ranking''' (which right now, it does not, a serious limitation), the human should know which of the 30 websites appears to be the weakest and therefore be able to focus their analysis on that based on the partial results from the first 10-30 minutes.

The goal of this project, is therefore to provide the human with an initial automated severity ranking, that the human is able to override, but assists the human to focus analysis on seemingly weaker hosts/websites.

'''Technical Overview'''

IMPORTANT: An automated severity ranking is an initial “risk guess” based on parsing plugin output.

During analysis of this proposed project we identified some possible implementation approaches:

'''Possible Approach 1) Change all OWTF plugins'''

So that they produce:
* Their usual output (as currently)
* '''An initial automated severity ranking (when possible)'''

'''Potential Advantages''':

A big advantage here is logic cohesion, the ranking logic is close to the scanning logic, which makes verification steps perhaps easier to perform (i.e. more context may be available)

'''Potential Drawbacks''':

Parsing plugin output for ranking purposes during plugin execution might slow OWTF, which is a big concern in a project where efficiency is the top goal.

'''Possible Approach 2) Have a background “severity ranker process”'''

The idea here would be to have a process running in the background, plugins do not rank their own output, instead they send a message to the severity ranker process, when this happens, the process parses the output to produce an initial automated ranking.

'''Potential Advantages'''

Plugin ranking happens in the background without slowing OWTF, cool features such as “re-rank this plugin (may send verification tests against target)” become possible from the interactive report via Plug-n-Hack.

'''Potential Drawbacks'''

The ranking logic is de-coupled from the scanning logic (where perhaps more information is available or sending “another request to double-check” might be easier)

'''Expected Outcome and Reporting Implications'''

At the end of the automated plugin severity rankings OWTF should:
1- Provide a default, automated, plugin severity ranking for each plugin
2- Since default severity rankings are less reliable (automated) they will be highlighted as such in the report, for example, providing a confidence percentage or at least a clear visual clue that the ranking is automated such as black/gray background.

If implementing a confidence percentage, OWTF would say "how sure" it is about a given automated ranking. For example "0%" would be "just guessing" and "100%" would be "exploitation verified".
3- When the human overrides or confirms the default ranking, the ranking is considered
"confirmed by a human" (i.e. more reliable) and this highlighting (i.e. black/gray background) is removed
4- A new filter to group vulnerabilities by target will be provided in the report.
5- A new filter to group vulnerabilities for all targets will be provided in the report

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Zest_support_and_ZAP_integration OWASP OWTF - Zest support and ZAP integration] if both projects are accepted.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python knowledge is very welcome but not strictly necessary if there is will to learn, previous exposure to security concepts and penetration testing is very important in this project but some lack of this can be compensated with pre-GSoC involvement and will to learn.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Zest support and ZAP integration ===

'''Brief explanation:'''

The Mozilla foundation has done great work with the Zest initiative, this provides a great automated mechanism to replicate exploitation of security vulnerabilities in a format that makes tool communication easier: For example, ZAP supports Zest, so if OWTF can create a Zest script for a vulnerability in an automated fashion, this may in turn be easier to import into ZAP and other tools.

[https://developer.mozilla.org/en-US/docs/Zest More information on Zest can be found here]

'''High level overview'''

This project, introduces the risk of seriously damaging OWTF performance, therefore, at a high level, we believe there are the following choices:

Choice 1) '''Background execution''' - You try to see if a Zest script can be
created for each plugin in the *background* while owtf keeps running

Choice 2) '''On-demand execution''' - Using some Plug-n-Hack magic, we could
have a button in the report saying "Generate Zest Scripts for plugin"

Choice 3) '''Hybrid approach''' - Implement choice 1 + 2, default to choice 2, but have choice 1
as an option (for example: owtf.py --zest on-demand/background/all)

'''Other project practicality considerations'''

1) '''Background Zest script generation'''

Makes sense on at least the output of scanner plugins (i.e. w3af finds a vuln, we create the Zest script for that vuln)

2) '''On-demand Zest script generation from plugin output'''

From the report, when you select a plugin, *could* be useful

3) '''On-demand Zest script generation from HTTP transaction'''

Selecting an HTTP transaction from the transaction log + click "generate Zest script" from there would also be very useful

4) '''ZAP integration'''

After generating the Zest script, the next step is to send the Zest script to ZAP, possibly using [http://code.google.com/p/zaproxy/wiki/ApiDetails the ZAP API], and perhaps with some help from [https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ Plug-n-Hack] (which allows us to send commands to our proxy, and from there, we could send commands to ZAP, or alternatively perhaps send commands to ZAP directly via Plug-n-Hack).

The solution will ideally be as simple and extensible as possible so that the codebase does not become unmaintanable.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Potential project coordination'''

This project should be coordinated with [https://www.owasp.org/index.php/GSoC2014_Ideas#OWASP_OWTF_-_Automated_Vulnerability_Severity_Rankings OWASP OWTF - Automated Plugin Severity Rankings] if both projects are accepted.

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Some previous exposure to security concepts, penetration testing, Python and development in general is important for this project.

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Improved Proxification and Plug-n-Hack support ===

'''Brief explanation:'''

The Mozilla foundation has done great work with [https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ the Plug-n-Hack standard (PnH)], which allows security tools to provide better interaction with web browsers. For example, it allows us to send commands from the browser to the OWTF proxy, which opens the door to a much better user experience. Please note that '''OWTF already supports Plug-n-Hack Phase 1'''.

'''Overview'''

This project is divided in the following pieces of functionality:

'''1) Plug-n-Hack v2/v3 support'''

There are many other features in Phase 2 that could be implemented and on top of that Plug-n-Hack v3 should be available this summer.
The aim of this project would be to try to cover as much as possible from the Plug-n-Hack standard as relevant to OWTF, for example:

'''OWTF Plug-n-Hack mode'''

OWTF starts in proxy mode, waiting for instructions, the user can drive OWTF from the browser (i.e. using the browser as a GUI, instead of the command line).

'''OWTF improved report interactivity via Plug-n-Hack'''

Provide new functions from the OWTF interactive report, for example “launch this plugin again”, “send this HTTP request again”, etc.

[https://www.youtube.com/watch?v=pYFtLA2yTR8 Please see this demo to see the newest Plug-n-Hack additions]

[https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ For more information about plug and hack please see this]

'''2) Improved Tool and Plugin proxification'''

At the moment, not all Tools or plugins are proxified in OWTF. This means that not all plugins send their requests through the OWTF MiTM proxy. This is a problem because OWTF performs analysis on HTTP transactions passively, and right now it cannot see '''all HTTP requests sent''' due to some unproxified tools and plugins.

An additional component of this project is therefore to proxify most of the tools and plugins. This may be possible using a utility like proxychains and/or tweaking the inbound proxy without disturbing current functionality.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience is very welcome but not strictly necessary, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Stateful Browser with configurable authentication ===

'''Brief explanation:'''

The automated functionality of OWASP OWTF is currently limited to the non-authenticated portion of a website. We would like to implement authentication support through:

1) OWTF parameters

2) Configuration files

What we would like to do here is to leverage the [http://wwwsearch.sourceforge.net/mechanize/ powerful mechanize python library] and build at least support for the following authentication options:
* Basic authentication [https://github.com/7a/owtf/issues/9 Already implemented here]
* Cookie based authentication
* Form-based authentication
* Client-side certificates

'''Other important features'''

* GUI mechanism to make authentication setup (super-)easy for the user via [https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ Plug-n-Hack]
* Ability to '''keep track of several user roles''' and allow easy switching via [https://developer.mozilla.org/en-US/docs/Plug-n-Hack Plug-n-Hack]

Additionally, we would welcome here a feature to detect when the user has been logged off, to log OWTF back in again before retrying the next request. <-- The proxy is probably a better place to implement this since external tools would also benefit from this. This feature will have to be coordinated with the MiTM proxy feature (already implemented).

The solution will ideally be as simple and extensible as possible so that the codebase does not become unmaintanable.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* High performance
* Reliability
* Ease of use
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with the mechanize library or HTTP state is very welcome but not strictly necessary, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Testing Framework Improvements ===

'''Brief explanation:'''

As OWASP OWTF grows it makes sense to build custom unit tests to automatically re-test that functionality has not been broken. In this project we would like to improve the existing unit testing framework so that creating OWASP OWTF unit tests is as simple as possible and all missing tests for new functionality are created. The goal of this project is to update the existing Unit Test Framework to create all missing tests as well as improve the existing ones to verify OWASP OWTF functionality in an automated fashion.

'''Top features'''

In this improvement phase, the Testing Framework should:
* (Top Prio) Focus more on functional tests
For example: Improve coverage of OWASP Testing Guide, PTES, etc. (lots of room for improvement there!)
* (Top Prio) Put together a great wiki documentation section for contributors
The goal here is to help contributors write tests for the functionality that they implement. This should be as easy as possible.
* (Top Prio) Fix the current Travis issues :)
* (Nice to have) Bring the unit tests up to speed with the codebase
This will be challenging but very worth trying after top priorities.
The wiki should be heavily updated so that contributors create their own unit tests easily moving forward.

'''General background'''

The Unit Test Framework should be able to:
* Define test categories: For example, "all plugins", "web plugins", "aux plugins", "test framework core", etc. (please see [http://www.slideshare.net/abrahamaranguren/introducing-owasp-owtf-workshop-brucon-2012 this presentation] for more background)
* Allow to regression test isolated plugins (i.e. "only test _this_ plugin")
* Allow to regression test by test categories (i.e. "test only web plugins")
* Allow to regression test everything (i.e. plugins + framework core: "test all")
* Produce meaningful statistics and easy to navigate logs to identify which tests failed and ideally also hints on how to potentially fix the problem where possible
* Allow for easy creation of _new_ unit tests specific to OWASP OWTF
* Allow for easy modification and maintenance of _existing_ unit tests specific to OWASP OWTF
* Perform well so that we can run as many tests as possible in a given period of time
* Potentially leverage the python unittest library: [http://docs.python.org/2/library/unittest.html http://docs.python.org/2/library/unittest.html]

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* Performant and automated regression testing
* Unit tests for a wide coverage of OWASP OWTF, ideally leveraging the Unit Test Framework where possible
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with unit tests and automated regression testing would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

=== OWASP OWTF - Python version upgrade and compatibility ===

'''IMPORTANT WARNING: This project is considered to be < 2 weeks of effort BUT can be proposed to complement ANOTHER OWTF idea, the last few weeks of GSoC seems the best moment to start this'''

'''Brief explanation:'''

Right now OWASP OWTF works on Python 2.6.5-2.7.3 (might work on surrounding versions too), the aim of this project would be to change the existing codebase so that it additionally works on newer python versions too, for example Python 3.3.
The intention here is to take advantage of improvements in newer python versions when available while letting OWASP OWTF work on older python versions too (i.e. 2.6.5) if that is the only option available.
The solution will ideally be as simple and extensible as possible so that the codebase does not become unmaintanable due to compatibility.

For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]

'''Expected results:'''

* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* Performant and reliable OWASP OWTF execution on multiple python versions, in particular the latest python version (i.e. 3.3.x) as well as the previous 2.6.5-2.7.3 range.
* Test cases
* Good documentation

'''Knowledge Prerequisite:'''

Python, experience with python version upgrades and python version compatibility implementations, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn

'''Mentor: Abraham Aranguren - OWASP OWTF Project Leader - Contact: name.surname@owasp.org'''

===OWASP PCI TOOLKIT===
[[File:Pci-toolkit-items-small.gif]] OWASP PCI toolkit is an Open Source project built using Google Engine App, that will help organizations scope the PCI-DSS requirements for their System Components. The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards.

In order to comply with this standard, organizations need to understand the PCI-DSS requirements. Many of these requirements use OWASP guidelines as their baseline.

The OWASP PCI toolkit is a project focused on helping organization understand how OWASP guidelines apply to the PCI-DSS requirements.

'''Expected results:'''

4 complete modules built as a Google App Engine:
http://pci-toolkit.appspot.com/

'''Knowledge Prerequisite:'''

Skill Level: Easy-Medium
Python, HTML, CSS, Google App Engine.

Affinity with financial institutions, Web security and credit card-online transactions

'''OWASP project page:'''

https://www.owasp.org/index.php/Category:OWASP_PCI_Project

Mentor: Johanna Curiel - emai: firstname.lastname@owasp.org

=== OWASP iGoat ===

'''Brief explanation:'''

Right now OWASP iGoat works fine as a full universal iOS app on iPhone and iPads up to iOS 6.x and Xcode 4.x. It needs to be updated to properly function under iOS 7.x and Xcode 5.x, which will require some code maintenance, GUI changes, and so on.

Although it is primarily maintenance items that need the updating, the student will gain an intimate familiarity with how the iGoat platform works, including how to write and plug-in new exercise modules. Writing additional exercises, with all due credit, will also be encouraged in an optional second phase of this project.

For background on OWASP iGoat please see: https://www.owasp.org/index.php/OWASP_iGoat_Project

'''Expected results:'''

* iGoat functions properly in all current aspects under iOS 7.x, compiled under Xcode 5.x.
* All GUI, buttons, and other presentation layer aspects of iGoat are compliant with iOS 7.x look and feel.
* (Optionally) write one or more new iGoat exercise modules, based on existing design descriptions to be provided by the project mentor.

'''Knowledge Prerequisite:'''

iOS app development in Xcode using Objective C will be quite necessary. Familiarity with iOS 7.x user interface updates additionally helpful.

'''Mentor: Ken van Wyk - OWASP iGoat Project Leader - Contact: ken@krvw.com'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Advanced access control testing ===

'''Brief explanation:'''

Access control testing is typically difficult for security tools to automate. However previous Google Summer of Code projects have added session, authentication, user and role handling to ZAP, which provide an ideal basis for advanced access control testing.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

This development would allow (semi) automated access control testing by:
* Maintaining and displaying different site trees (application maps) for different users/roles
* Providing tools which access all of the content accessible via one user/role which should not be accessible via another user/role
* Ideally allow resources to be tied to users/roles to allow enable horizontal privilege testing

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Scripted Add-ons ===

'''Brief explanation:'''

ZAP supports all JSR 223 scripting languages, but only for a limited number of purposes. This development would allow 'full' add-ons to be written in any JSR 223 language.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

* Users will be able to 'full' add-ons in any JSR 233 scripting language
* A set of example add-ons demonstrating as much functionality as possible should be developed in at least Java Script, Jython and Jruby.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - AMF Support ===

'''Brief explanation:'''

ZAP has only very limited support for AMF and does not provide an effective graphical representation of it.
This development will add full support for AMF.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

* De-serialise and display AMF messages in ZAP graphically (based on existing POC code)
* Expose the AMF data as parameters so that ZAP can scan them
* Add new AMF specific scan rules as required
* Implement in a way that makes it easier for ZAP to support other technologies (such as Java applets, Silverlight)

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: Colm O'Flaherty - OWASP ZAP Core team'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Web Service (SOAP) scanning ===

'''Brief explanation:'''

ZAP has only very limited support for web service scanning and has no understanding of WSDL.
This development will add full support for exploring and scanning SOAP based web services.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

The development will allow ZAP to parse WSDL and populate the Sites tree with all of the end points defined. It should also enhance the ZAP scanning capabilities to specifically attack the end points for as wide a range of vulnerabilities. Test cases should be written in [http://code.google.com/p/wavsep/ wavsep] format and contributed back to that project.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - As a long running service ===

'''Brief explanation:'''

ZAP started out as a GUI only desktop tool. It now supports a headless 'daemon' mode but it is still not suitable for running as a long running service. This will require much heavier use of the database, and ideally will allow different databases to be used.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

ZAP able to run as a (very) long running service. There must be no memory leaks code and ideally there should still be very little latency while proxying through ZAP.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - GUI unit test framework ===

'''Brief explanation:'''

While ZAP does have some low level unit tests it doesnt have any unit tests for the UI. This means that sometimes changes can break the UI without being immediately apparent.

ZAP is the [https://www.ohloh.net/orgs/OWASP most active OWASP project] and was voted the [http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/ most popular security tool of 2013] by ToolsWatch.org reeaders.

'''Expected results:'''

A unit test framework which will allow the GUI to be easily tested. A set of unit tests which test the main GUI features and can be easily extended.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''

=== [https://www.owasp.org/index.php/ESAPI OWASP ESAPI] 2.x - Security Configuration ===

'''Brief explanation:'''
There are currently more than a half-dozen of open Google Issues in ESAPI regarding the security configuration component (e.g., see [http://code.google.com/p/owasp-esapi-java/issues/list?q=component%3DSecurityConfiguration ESAPI Security Configuration Issues]).

The ESAPI interface for its configuration (SecurityConfiguration) is overly complicated; it has a 'getter' method specific to almost every ESAPI configuration property. The rules for how and where the ESAPI.properties file is found are overly complicated making questions about it one of the most frequently asked questions on forums such as Stack Exchange and the ESAPI mailing lists. This complication leads to a unduly intricate, non-modular reference implementation (DefaultSecurityConfiguration) that makes it difficult to extend in terms of new functionality.

A new, simpler security configuration interface and implementation is needed. Such an implementation would not only be useful for ESAPI 2.x, but could very well be used to build the configurator needed by ESAPI 3.

As part of this GSoC project, expectations would not only to address as many of the open security configuration issues as possible, but to also go beyond this to allow a framework for additional extensions in terms of functionality.

'''Expected results:'''
1) An improved, but simpler API for the security configuration part of ESAPI.
2) Alternate configuration stores other than Java properties files (e.g., XML, database), to be supported.
3) The ability to split the ESAPI configuration data into smaller, more manageable chunks to result in more maintainibility and allow for better enforcement of corporate security policies.
4) Continued backward compatibility with ESAPI 2.1.x or an extremely simple migration path forward.

'''Knowledge Prequisite:'''

Since the ESAPI 2.x project is written in Java, a good knowledge of Java is essential. A strong knowledge of JUnit will also be helpful in creating unit test cases. A working knowledge of XML or JDBC may also prove helpful.

'''Mentor: [https://www.owasp.org/index.php/User:Kevin_W._Wall Kevin W. Wall] - OWASP ESAPI for Java Project Leader'''

=== [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP Seraphimdroid Project] ===

'''Brief explanation:'''
OWASP Seraphimdroid is relatively new OWASP project regarding Android security. Seraphimdroid Android application should become mobile device safeguard, while on the other hand it should also provide user information and knowledge about security risks on his phone (in personalized way). The idea of security guard is based solely on heuristics, that most of the risks costing money and damaging user's privacy can be stopped without huge online database with signatures, and huge malware analysis lab. As part of this GSoC project, focus will be on finding way to stop as many risks that can cost money (premium calls, sms, ussd...) or harm user privacy as possible and to enhance UX of mobile application.

'''Expected results:'''
* Building features for stopping threats that can cost money originating from third party applications (continue where it was stopped)
* Build and propose features that can stop third party application damage user's privacy by sending user's data out of the mobile device (using internet)
* Enhance UI/UX

'''Knowledge Prequisite:'''

Since the OWASP Seraphimdroid project is written in Java and Android SDK, a good knowledge of Java, Android OS and SDK are essential. Good knowledge of XML and IP protocol can be useful.

'''Mentor: [https://www.owasp.org/index.php/User:Nikola_Milosevic Nikola Milosevic] - OWASP Seraphimdroid Project Leader'''

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - ModSecurity Ruby API ===
'''Brief explanation:'''
Adding the capability of rapid prototyping to ModSecurity functionalities trough scripts will open the possibility for easy rules production and customization, It also opens the possibility for a large community such as Ruby developers to create their own customization on the top of ModSecurity and so customize their own rules, analog of today's Lua support.

'''Expected results:'''
An implementation able to handle Ruby scripts which will interact to ModSecurity as Lua does.

'''References:'''
Embedding Ruby into C++ (ModSecurity is C, using C++ as reference):
http://aeditor.rubyforge.org/ruby_cplusplus/index.html
ModSecurity Reference Manual, Lua:
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecRuleScript

'''Knowledge Prerequisite:'''
C and Ruby programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - ModSecurity Python API ===
'''Brief explanation:'''
Adding the capability of rapid prototyping to ModSecurity functionalities trough scripts will open the possibility for easy rules production and customization, It also opens the possibility for a large community such as Python developers to create their own customization on the top of ModSecurity and so customize their own rules, analog of today's Lua support.

'''Expected results:'''
An implementation able to handle Python scripts which will interact to ModSecurity as Lua does.

'''References:'''
Embedding Python into C/C++:
http://docs.python.org/3.3/extending/embedding.html
ModSecurity Reference Manual, Lua:
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecRuleScript

'''Knowledge Prerequisite:'''
C and Python programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Create "Sniffer-Mode" ===

'''Brief explanation:'''

The ModSecurity code includes a "standalone" version that wraps a light weight Apache/APR around the ModSecurity code. This is used as the basis for the ports to the IIS/Nginx web server platforms. The goal for this project task is to extend this standalone version so that it can accept a data feed of network traffic (e.g. libpcap) data as input and apply the ModSecurity CRS rules. Possible solutions could be:
* Create a ModSecurity "plugin" for the Snort IDS.
* Create a ModSecurity "plugin" for the Suricata IDS.
* Add libpcap sniffer wrapper to standalone ModSecurity code to directly pull data off the wire.

'''Expected results:'''

This new sniffer mode would allow organizations to run ModSecurity/OWASP ModSecurity CRS in an out of line mode as they do IDS systems.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Implement DoS Prevention Code ===

'''Brief explanation:''' https://github.com/SpiderLabs/ModSecurity/issues/416

Implement a request velocity learning engine to identify dynamic DoS thresholds for both the site and for the particular URL.

'''Expected results:'''

The new C code in ModSecurity will allow us to add new DoS Protection methods to the OWASP ModSecurity CRS.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Create a Positive Learning/Profile Engine ===

'''Brief explanation:''' See this academic/research paper for ideas of the type of learning we are looking for - http://www.cs.ucsb.edu/~vigna/publications/2003_kruegel_vigna_ccs03.pdf

ModSecurity needs a profiling engine that implements the various AppSensor Detection Points - http://blog.spiderlabs.com/2011/08/implementing-appsensor-detection-points-in-modsecurity.html.

'''Expected results:'''

The new engine will implement more detection points to detect abnormal request attributes.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

=== [https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set (CRS)] - Create an Engine to Detect Application Flow Anomalies ===

'''Brief explanation:'''

Need an engine that can track normal application flow paths (click-flows) for business logic transactions - such as transferring money from accounts. After profiling normal application path flows, we want to then be able to alert to anomalies. This type of logic can help to prevent Banking Trojan attacks.

Example - let's say an application has a multi-step checkout process to purchase an item. This new engine would be able to profile/learn which URLs are accessed in what order and identify if clients skip steps or jump directly to other URLs in the flow.

'''Expected results:'''

The engine will be able to alert on anomalous application flows.

'''Knowledge Prerequisite:'''

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

'''Mentor: Felipe Zimmerle Costa and Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

GSoC2014 Ideas

2014-02-28T01:26:13Z

Rcbarnett:

GSoC2014 Ideas

2014-02-27T18:53:51Z

Rcbarnett:

OWASP WASC Distributed Web Honeypots Project

2014-02-24T23:32:02Z

Rcbarnett:

OWASP WASC Distributed Web Honeypots Project

2014-02-24T23:25:34Z

Rcbarnett:

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T21:46:05Z

Rcbarnett: /* Quick Download */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T21:39:41Z

Rcbarnett: /* FAQs */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T21:23:37Z

Rcbarnett: /* Volunteers */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T21:18:23Z

Rcbarnett: /* Quick Download */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T20:10:28Z

Rcbarnett: /* Road Map and Getting Involved */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T20:05:55Z

Rcbarnett: /* News and Events */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T20:04:58Z

Rcbarnett: /* Road Map and Getting Involved */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T20:00:53Z

Rcbarnett: /* Volunteers */

OWASP WASC Web Hacking Incidents Database Project

2014-02-18T19:57:59Z

Rcbarnett: /* FAQs */