OWASP - User contributions [en]

OWASP AppSensor Project

2018-05-01T20:45:31Z

John Melton: removing dennis as project leader

=Main=

<div style="width:100%;height:120px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-header.jpg|link=]]</div>
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=OWASP_Project_Stages#tab=Flagship_Projects]]</div>

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

== OWASP AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers a comprehensive guide and a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [https://brage.bibsys.no/xmlui/handle/11250/252956 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]

[https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf 12-page US Letter booklet]

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [25 Sep 2015] [http://appsecusa2015.sched.org/event/09495faf5cced352cb4a2acc16ce9158#.VaOSoHhfk2w Presentation] at AppSec USA 2015
* [27 Jul 2015] [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc AppSensor Guide v2.0.2] published
* [09 Jun 2015] AppSensor Code v2.1.0 [https://github.com/jtmelton/appsensor/releases/tag/v2.1.0 released]
* [20 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Code
* [19 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Documentation
* [09 Apr 2015] [https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf CISO Briefing] booklet published
* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-22290600.html AppSensor Guide] and [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html CISO Briefing] can be purchased at cost as print on demand books.

==Classifications==

{| cellpadding="2" width="200"
|-
| rowspan="2" align="center" width="50%" valign="top" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" width="50%" valign="top" | [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" width="50%" valign="top" | [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| align="left" width="200" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Juan C Calderon
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*Sumanth Damaria
*August Detlefsen
*Ryan Dewhurst
*Sean Fay

| align="left" width="200" valign="top" |

*Timo Goosen
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton
*Mark Miller
* Rich Mogull
*Craig Munson

| align="left" width="200" valign="top" |

*Louis Nadeau
*Giri Nambari
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Raphael Taban
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Stephen de Vries
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

==OWASP Code Sprint 2015==
Development work was also supported by the [https://www.owasp.org/index.php/Summer_Code_Sprint2015 OWASP Summer Code Sprint 2015].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten.
v2.0.0 final was released in late January 2015.
v2.1.0 final was released in June 2015.
v2.2.0 final was released in September 2015

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== June 2015 (2.1) ===
* <strike>Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)</strike> ([https://github.com/jtmelton/appsensor/issues/19 github issue]) -> DONE
* <strike>Sample application / demo</strike> ([https://github.com/jtmelton/appsensor/issues/9 github issue]) -> DONE
* <strike>Finish up developer documentation on github and appsensor.org</strike> ([https://github.com/jtmelton/appsensor/issues/12 github issue]) -> DONE
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]] - Update - OWASP not selected

=== September 2015 (2.2) ===
* <strike>First version of administration UI for appsensor (monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])</strike> -> DONE

=== January 2016 (2.3) ===
* <strike>Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])</strike> -> DONE
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations

=== May 2016 (2.4) ===
* Trend monitoring implementation ([https://github.com/jtmelton/appsensor/issues/6 github issue])
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''September 2015''' Final release v2.2.0 code

'''June 2015''' Final release v2.1.0 code

'''April 2015''' CISO Briefing booklet published

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| align="left" width="200" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| align="left" width="200" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| align="center" width="200" valign="top" | [[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]
|}

The CISO briefing is also available to [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html buy at cost in print].

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

http://appsensor.org/

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

<nowiki>}} </nowiki>

__NOTOC__ <headertabs></headertabs>

[[Category:OWASP Project|AppSensor Project]]
[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP_Document]]
[[Category:OWASP_Download]]
[[Category:SAMM-EH-3]]
[[Category:SAMM-SA-2]]
[[Category:SAMM-VM-3]]

OWASP Code Sprint 2017

2017-06-05T02:12:25Z

John Melton: added link to previous year's GSoC work

== '''Goal''' ==
The OWASP Code Sprint 2017 is a program that aims to provide incentives to students to contribute to OWASP projects. By participating in the OWASP Code Sprint 2017 a student can get real life experience while contributing to an open source project. A student that successfully completes the program will receive in total $1500.

== '''Program details''' ==

''Projects that are eligible:'' All code/tools projects. Documentation projects are excluded.

''Duration:'' 8 weeks of full-time coding engagement .

== '''How it works''' ==

Any code/tool project can participate in the OWASP Code Sprint. Each project will be guided by an OWASP mentor. Students are evaluated in the middle and at the end of the coding period, based on success criteria identified at the beginning of the project. Successful students will receive $750 after each evaluation, a total of $1500 per student.

Projects are focused on developing security tools. It is required that the code any student produces for those projects will be released as Open Source.

Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.

== '''How you can participate''' ==

=== As a student: ===

1. Review the list of OWASP Projects currently participating in the OWASP Code Sprint 2017.

2. Get in touch with the OWASP Project mentor of your choice.

3. Agree deliverables with OWASP mentor.

4. Work away during May thru September

5. Rise to Open Source Development Glory :-)

=== [https://docs.google.com/forms/d/e/1FAIpQLSdAyBg5x9gapfLTL4Q_so7faNpR2QZmtuL3q4la2g5NZnhvyA/viewform ALL STUDENTS PLEASE APPLY HERE] ===

Student application submission is now open: [https://goo.gl/forms/it8hieQAcvCTuPG83 APPLY HERE].

=== As an OWASP Project Leader: ===

1. Edit this page adding your project and some proposed tasks as per the examples

2. Promote the initiative to your academic contacts

== '''Timeplan''' ==

'''Phase 1: Proposals'''

Project leaders who want to include their project to the program should submit some initial proposal ideas on this page. These ideas serve as guidance to the students; they are things that project leaders would like to get done, like new features, improvements, etc.

Subsequently students are invited to submit detailed proposals that can (but do not necessarily have to) be based on these ideas. Students are strongly encouraged to engage with project leaders and each project's community (e.g. through the project's mailing list) in order to discuss the details of their proposal. Proposals should provide details about the implementation, time plan, milestones, etc.

'''Phase 2: Scoring of proposals'''

After the submission of proposals, project leaders and contributors/mentors are required to review the submitted proposals and score them (on a 1 to 5 scale). Each proposal should receive at least 3 assessments/scores from different mentors. Each mentor, contributor or leader can score only proposals for their OWN project. All assessments should provide justification. Reviewers are strongly encouraged to provide constructive comments for students so that they can improve in the future.

Project leaders are responsible to attract a sufficient number of volunteer mentors to score proposals and subsequently supervise those that will get selected.

'''Phase 3: Slot allocation.'''

When proposal scoring has been completed, each project leader requests a specific number of slots. This number should be based on:
The number of truly outstanding proposals according to submitted scores.
The importance of the proposal to the project's roadmap.
The number of available mentors for the project. At least 2 mentors are needed for each proposal that gets accepted.
If the total number of requested slots is less than or equal to the available number of slots, then all projects get the requested slots. If not, the following rules apply:
All projects that have requested a slot get at least 1 slot, provided they have a high quality proposal and sufficient number of mentors.
Two mentors are required per slot allocated to the project.
The program's administrators get in touch with project leaders, especially those that have requested a large number of slots to receive additional feedback on the requested slots and explore any available possibilities for reducing the requested number of slots. A project leader might choose to donate one or more requested slots back to the pool so that other projects can get more slots. The program administrators can choose to initiate a public discussion between projects in need of more slots and projects that have requested a lot of slots in order to determine the best possible outcome for everyone.
If all else fails, slots are equally allocated to projects, i.e. all projects get 1 slot; projects that have requested 2 or more slots get an extra slot if available; projects that have requested 3 or more slots get an extra slot if available, etc. When there are no more slots available for all projects that have requested them a draw is used to allocate the remaining slots.

In any case, the program's administrators should perform a final review of the selected proposals to ensure that they are of high quality. If concerns arise they should request additional information from project leaders.

'''Phase 4: Coding.'''

This is the main phase of the program. Students implement their proposal according to the submitted timeplan and under the supervision
of their mentors.

== '''Evaluations''' ==

In the middle of the coding period, mentors should submit an evaluation of their students to ensure that they are on track and provide some feedback both to OWASP and the students.

If no/little progress has been made up to this point, the mentors could decide to fail the student in which case the student does not receive money. If successful, OWASP will pay half the amount ($750). The final evaluations are submitted at the end of the coding period and the second installment ($750) is paid to the student if all agreed deliverables are met. If the student has failed to demonstrate progress during the second period, then the second installment will not be paid and the student will get only half of the amount.
== '''Deadlines''' ==
Program announcement: May 15''', 2017'''

Deadline for Student Applications: '''June 15, 2015'''

Proposal Evaluations: from: '''June''' '''15 thru June 23 2017'''

Successful proposals announcement:: '''June 26, 2017'''

Bonding Period Announcement: June 26, 2017 - July 1, 2017

Coding Period Starts: '''July 3, 2017'''

Mid-term evaluations: Submitted from :'''July 31, 2017 thru August 4, 2017'''

Coding Period Re-starts: August 7, 2017

Coding period ends: '''September 1, 2017'''

Final evaluations:'''September 4, 2017 thru September 8, 2017'''

== '''Mailing List''' ==
Please subscribe to the following mailing list to receive updates or ask any particular questions:

[https://groups.google.com/a/owasp.org/forum/?hl=en#!forum/owasp-code-sprint-2017 OWASP Code Sprint 2017 Mailing List]

== '''Project Ideas''' ==
== OWASP ZAP ==

[[OWASP Zed Attack Proxy Project]] (ZAP) The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers. Previous GSoC students have implemented key parts of the ZAP core functionality and have been offered (and accepted) jobs based on their work on ZAP.

We have just included a few of the ideas we have here, for a more complete list see the issues on the ZAP bug tracker with the [https://github.com/zaproxy/zaproxy/issues?q=is%3Aopen+is%3Aissue+label%3Aproject project] label.

=== Field Enumeration ===
:
:This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped.
:
:The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.
:
:''' Expected Results '''
:* User able to specify a specific field to enumerate via the ZAP UI
:* A list of all valid characters to be returned from the sets of characters the user specifies
:* Ability to configure a wide range of success and failure conditions to cope with as many possible situations as possible
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' 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.
:
:''' Mentors '''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team
:

=== Scripting Code Completion ===
:
:ZAP provides a very powerful scripting interface. Unfortunately to use it effectively is only really possible with a good knowledge of the ZAP internals. Adding code completion (eg using a project like https://github.com/bobbylight/AutoComplete) would significantly help users.
:
:''' Expected Results '''
:* Code completion for all of the parameters for all available functions in the standard scripts
:* Implementations for JavaScript, JRuby and Jython
:* Helper classes with code completion for commonly required functionality
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' Knowledge Prerequisite: '''
:ZAP is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== SSRF Detector Integration ===
:
:Currently ZAP does not detect SSRF vulnerabilities, due to the lack of this sort of service. https://ssrfdetector.com/ is an online service for detecting Server Side Request Forgery vulnerabilities (SSRF). It is developed and maintained by Jake Reynolds and is open source https://github.com/jacobreynolds/ssrfdetector
:
:''' Expected Results '''
:* Extend ZAP to detect SSRF vulnerabilities and interact with other services such as outlined above.
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' Knowledge Prerequisite: '''
:ZAP is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Zest Text Representation and Parser ===
:
:Zest is a graphical scripting language from the Mozilla Security team, and is used as the ZAP macro language.
:
:A standardized text representation and parser would be very useful and help its adoption.
:
:''' Expected Results '''
:* A documented definition of a text representation for Zest
:* A parser that converts the text representation into a working Zest script
:* An option in the Zest java implementation to output Zest scripts text format
:
:''' Knowledge Prerequisite: '''
:The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Support Java as a Scripting Language ===
:
:It would be very useful to support Java in addition to the JSR223 scripting languages within the ZAP script console'.
:
:It should be possible to provide much better auto complete support than will be possible with dynamically typed scripting languages.
:
:''' Expected Results '''
:* The ability to run Java code in the ZAP Script Console to the same leval as other supported scripting languages
:* Templates for all of the current script types
:* Optionally auto complete supported
:
:''' Knowledge Prerequisite: '''
:The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Bamboo Support ===
:
:ZAP already has an official plugin for Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/zap+plugin).
:
:It would be great if we also had similar integration for Bamboo (https://www.atlassian.com/software/bamboo, https://en.wikipedia.org/wiki/Bamboo_(software))
:
:''' Expected Results '''
:* Facilitate the invocation and configuration of various ZAP functionalities from Bamboo CI. Including (but not limited to):
::*Manage Sessions (Loading/Persisting)
::*Define Context (Name, Include & Exclude URLs)
::* Attack Contexts (Spider, Ajax Spider, Active Scan)
::* Setup Autentication (Formed or Script Based)
::* Generate Reports
:* Templates for all of the current script types
:* Optionally auto complete supported
:
:''' Knowledge Prerequisite: '''
:The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of CI/CD/Bamboo would be useful.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Backslash Powered Scanner ===
:
:This is a brand new technique developed by one of the Burp guys: http://blog.portswigger.net/2016/11/backslash-powered-scanning-hunting.html
:Their implementation is open source: https://github.com/PortSwigger/backslash-powered-scanner so hopefully shouldn't be too hard to port to ZAP :)
:
:''' Expected Results '''
:* Extend ZAP's active scanner to leverage Backslash type scanning.
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' Knowledge Prerequisite: '''
:ZAP is written in Java, so a good knowledge of this language is recommended.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Your Idea ===
:
:'''Brief Explanation:'''
:
:ZAP is a great framework for building new and innovative security testing solutions. If you have an idea that is not on this list then don't worry, you can still submit it, we have accepted original projects in previous years and have even paid a student to work on their idea when we did not get enough GSoC slots to accept all of the projects we wanted.
:
:''' Getting started '''
:* Get in touch with us :)
:
:'''Expected Results:'''
:* A new feature that makes ZAP even better
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:'''Knowledge Prerequisites:'''
: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.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team
:

== BLT ==

'''Brief Explanation:'''

lets anyone report issues they find on the internet. Found something out of place on Amazon.com ? Let them know. Companies are held accountable and shows their response time and history. Get points for reporting bugs and help keep the internet bug free.

''' Getting started '''
* Get in touch with us :)

'''Expected Results:'''
* A new feature that makes Bugheist even better

'''Knowledge Prerequisites:'''
BLT is written in Python / Django, so a good knowledge of this language and framework is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentors:'''
[https://www.owasp.org/index.php/User:Sauriti Sean Auriti] [mailto:sean.auriti@owasp.org @] and the rest of the BLT Core Team

== OWASP Security Knowledge framework ==

===Brief Explanation===
The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software. It can also be used to train developers about application security. Education is the first step in the Secure Software Development Lifecycle. This software can be run on Windows/Linux/OSX using python-flask.

'''In a nutshell'''

- Training developers in writing secure code

- Security support pre-development ( Security by design, early feedback of possible security issues )

- Security support post-development ( Double check your code by means of the OWASP ASVS checklists )

- Code examples for secure coding

===Your idea / Getting started===
* Please send an email to riccardo.ten.cate@owasp.org [riccardo.ten.cate@owasp.org] or glenn.ten.cate@owasp.org [glenn.ten.cate@owasp.org] and we would love to tell you all about it! :-)

===Expected Results===
* Adding features to SKF project
* Adding more function examples to pre-development phase
* Adding/updating code examples ( PHP, Java, .NET, Go, Python, NodeJS and more )
* Adding/updating Knowledgebase items
* Adding CWE references to knowledgebase items
* Adding low/medium level verification testing guides for developers to teach how to manually verify the existence of injection/logic flaws. (pen-testing)

===Knowledge Prerequisites===

* For helping in the development of new features and functions Python flask would come in handy since the framework is written in python flask.
* For writing knowledgebase items only technical knowledge of application security is required
* For writing / updating code examples you need to know a programming language along with secure development.
* For writing the verification guide you need some penetration testing experience.

'''Mentors:'''

Riccardo ten Cate [mailto:riccardo.ten.cate@owasp.org]
Glenn ten Cate [mailto:glenn.ten.cate@owasp.org]

== OWASP ZSC ==

'''Brief Explanation:'''

OWASP ZSC is an open source software in python language which lets you generate customized shellcodes and convert scripts to an obfuscated script. This software can be run on Windows/Linux/OSX under python
https://www.owasp.org/index.php/OWASP_ZSC_Tool_Project

''' Getting started '''
* Get in touch with us on Github:
https://github.com/zscproject/OWASP-ZSC

Project Leaders:
*https://www.owasp.org/index.php/User:Ali_Razmjoo
*https://www.owasp.org/index.php/User:Johanna_Curiel

'''Expected Results:'''
We have a list of potential modules we want to build
To get familiar with the project, please check our installation and developer guidelines:
https://www.gitbook.com/book/ali-razmjoo/owasp-zsc/details

Contact us through Github, send us a question:
https://github.com/zscproject/OWASP-ZSC

* New obfuscation modules
* New shellcodes for OSX and Windows

'''Knowledge Prerequisites:'''
OWASP ZSC is written in Python, so a good knowledge of this language and framework is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentors:'''
Brian Beaudry & Patrik Patel
Please contact us through Github
https://github.com/zscproject/OWASP-ZSC

== OWASP Seraphimdroid mobile security project ==

=== Behavioral malware and intrusion analysis ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is an Android mobile app which already has a capability to statically analyze malware using machine learning (weka toolkit) relying on permissions. However, this is usually not enough and we intend to improve this with behavioral analysis. There are a number of paper in scientific literature describing how to detect malware and intrusions by dynamically analyzing its behavior (system calls, battery consumption, etc.). The idea of this project is to find the best approach that can be implemented on the device and implement it.

'''Expected Results:'''

* Reviewing scientific literature and find feasible approach we can take
* Implement and possibly improve the approach in Seraphimdroid
* Test the model and provide controls to switch algorithm on or off and possibly fine tune it
* Documenting approach as a technical report

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML
* Basic knowledge and interest in machine learning

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Framework for plugin development ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app, however, it lacks some components community can provide. We would like to provide community the way to develop plugins that can add features to OWASP Seraphimdroid app. However, the way of integrating external components into Android app may be challenge. The way of presenting GUI and integration between processes need to be examined and developed.

'''Expected Results:'''

* Examining the way of integrating third party apps through some provided API to OWASP Seraphimdroid
* Providing GUI integration with third party components
* Develop at least one test plugin
* Document the development process and API

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

== OWASP DefectDojo ==

'''Brief Explanation:'''

DefectDojo is a security automation and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, schedule scans, triage vulnerabilities and push findings into defect trackers.

'''Expected Results:'''

* Multiple opportunities for students to get involved with DefectDojo ranging in difficulty from easy to advanced
* Students will receive hands-on experience in a full-stack software development project
* Students will have the opportunity to work on a project with multiple moving parts and third-party interactions

'''Knowledge Prerequisites:'''
* Python
* HTML, Bootstrap

''' Getting started: '''
* We have a [http://defectdojo.readthedocs.io/en/latest/ Read the Docs Site]

'''Mentors:'''
* [[User:devgreg|Greg Anderson]] - OWASP DefectDojo Project Leader

== OWASP AppSensor ==

[[OWASP AppSensor Project]] The OWASP AppSensor project is a project to help you build self-defending applications through real-time event detection and response. Previous GSoC students have implemented key AppSensor contributions, and we've had very successful engagements. We look forward to hearing your ideas and hopefully working with you to execute them.

=== Machine Learning Driven Web Server Log Analysis ===
:
:'''Brief Explanation:'''
:
:The goal of this project would be to build a web server log analysis tool suite based on ML (machine learning). This tool suite will accept as input web server logs (apache, nginx) and will provide as output a determination of requests that are considered "attacks" There are a number of key points for this project:
:* Almost everybody has web server logs. It's a common format that is well understood, and is a good starting place for many security teams
:* Because the format is well understood, the data points (features) are well understood.
:* This tool suite would have applicability far beyond just our project. The goal is to give away a tool that can process a set of log files, build a custom model for the traffic, and then be used to process future log files and find attacks (outliers / anomalies)
:
:Note that this project would extend work done in last year's GSOC (https://timothy22000.github.io/event/gsoc-work-report.html) to get an initial machine learning capability developed.
:
:''' Expected Results '''
:* User provides tool suite a set of web server logs (User has option to annotate data set with known attacks)
:* System is pre-coded with knowledge of certain anomalous patterns (attacks)
:* System builds ML model for processing future log files
:* System provides mechanism for processing future logs using trained model.
:
:''' Knowledge Prerequisite: '''
:AppSensor is written in Java, so a good knowledge of this language is recommended. The toolset used previously for the ML effort was scala/spark, but this is not a hard requirement. The preference would be to use either the JVM (java/scala), or possibly python, as both of these stacks are well understood and have significant ML capabilities.
:
:''' Mentors '''
:[https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:jtmelton@gmail.com @] and the rest of the AppSensor Team
:

=== Your Idea ===
:
:'''Brief Explanation:'''
:
:AppSensor is a great tool and many organizations are starting to use it. If you have an idea that is not on this list, please submit it - we would love to give you the chance to work on an idea you came up with!
:
:''' Getting started '''
:* Get in touch with us :)
:
:'''Expected Results:'''
:* A new feature that makes AppSensor even better
:
:''' Knowledge Prerequisite: '''
:AppSensor is written in Java, so a good knowledge of this language is recommended.
:
:''' Mentors '''
:[https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:jtmelton@gmail.com @] and the rest of the AppSensor Team
:

== OWASP OWTF ==
'''[https://github.com/owtf/owtf Offensive Web Testing Framework (OWTF)]''' is a project focused on penetration testing efficiency and alignment of security tests to security standards like the OWASP Testing Guide (v3 and v4), the OWASP Top 10, PTES and NIST. Most of the ideas below focus on rewrite of some major components of OWTF to make it more modular.

=== OWASP OWTF - MiTM proxy interception and replay capabilities ===

'''Brief Explanation:'''

The OWTF man-in-the-middle proxy is written completely in Python (based on the excellent Tornado framework) and was benchmarked to be the fastest MiTM python proxy. However it lacks the useful and much need interception and replay capabilities of mitmproxy (https://github.com/mitmproxy/mitmproxy).

The current implementation of the MiTM proxy serves its purpose very well. Its fast but its not extensible. There are a number of good use cases for being extensible

* ability to intercept the transactions
* modify or replay transaction on the fly
* add additional capabilities to the proxy (such as session marking/changing) without polluting the main proxy code

Bonus:

* Design and implement a proxy plugin (middleware) architecture so that the plugins can be defined separately and the user can choose what plugins to include dynamically (from the web interface).
* Replace the current Requester (based on urllib, urllib2) with a more robust Requester based on the new urllib3 with support for a real headless browser factory. The typical flow when requested for an authenticated browser instance (using PhantomJS)

* The "Requester" module checks if there is any login parameters provided (i.e form-based or script - look at https://github.com/owtf/login-sessions-plugin)
* Create a browser instance and do the necessary login procedure
* Handle the browser for the URI
* When called to close the browser, do a clean logout and kill the browser instance.

'''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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''
Python proficiency, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn.

'''OWASP OWTF Mentors:'''
Contact: [mailto:Abraham.Aranguren@owasp.org Abraham Aranguren][mailto:viyat.bhalodia@owasp.org Viyat Bhalodia][mailto:bharadwaj.machiraju@gmail.com Bharadwaj Machiraju] OWASP OWTF Project Leaders

=== OWASP OWTF - Report enhancements ===

'''Brief explanation:'''

The current OWTF report is very interactive but it cannot be exported in its current form. A reporter service can be written (which was in the very early releases of OWTF) which exports a nice report with template, findings, and additional pentester's notes into multiple formats. A small set of export formats should be supported such as:

* HTML (pure static html here)
* PDF
* XML (for processing)
* JSON (for processing)

For background on OWASP OWTF please see: 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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''
Python, React.JS and general JavaScript proficiency, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn.

'''OWASP OWTF Mentors:'''
Contact: [mailto:Abraham.Aranguren@owasp.org Abraham Aranguren][mailto:viyat.bhalodia@owasp.org Viyat Bhalodia][mailto:bharadwaj.machiraju@gmail.com Bharadwaj Machiraju] OWASP OWTF Project Leaders

=== OWASP OWTF - Distributed architecture ===

To be updated soon!

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

For background on OWASP OWTF please see: 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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''
Python proficiency, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn.

'''OWASP OWTF Mentors:'''
Contact: [mailto:Abraham.Aranguren@owasp.org Abraham Aranguren][mailto:viyat.bhalodia@owasp.org Viyat Bhalodia][mailto:bharadwaj.machiraju@gmail.com Bharadwaj Machiraju] OWASP OWTF Project Leaders

== OWASP Hackademic Challenges Project ==

[[OWASP Hackademic Challenges Project]] The OWASP Hackademic Challenges project helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment.

=== New CMS ===

'''Brief Explanation:'''

The CMS part of the project is really old and has accumulated a significant amount of technical debt.
In addition many design decisions are either outdated or could be improved.
Therefore it may be a good idea to leverage the power of modern web frameworks to create a new CMS.
The new cms can be written in python using Django.

'''Expected Results:'''
* New cms with same functionality as the old one (3 types of users -- student, teacher, admin--, 3 types of resources -- article challenge, class--, ACL type permissions, CRUD operations on every resource/user, all functionality can be extended by Plugins.
* REST endpoints in addition to classic ones
* tests covering all routes implemented, also complete ACL unit tests, it would be embarassing if a cms by OWASP has rights vulnerabilities.
* PEP 8 code

''' Note: '''
This is a huge project, it is ok if the student implements a part of it. However whatever implemented must be up to spec.
If you decide to take on this project contact us and we can agree on a list of routes.
If you don't decide to take on this project contact us.
Generally contact us, we like it when students have insightful questions and the community is active

''' Getting Started: '''
* Install and take a brief look around the old cms so you have an idea of the functionality needed
* It's ok to scream in frustration
* If you want to contribute to get a feeling of the platform a good idea would be lettuce tests for the current functionality (which won't change and you can port in the new cms eventually)

'''Knowledge Prerequisites:'''
Python, Django, what REST is, the technologies used, some security knowledge would be nice.

'''Mentors:''' [mailto:spyros.gasteratos@owasp.org Spyros Gasteratos] - Hackademic Challenges Project Leaders

=== Course Type Challenge ===

'''Brief Explanation:'''
We have a sandbox engine which allows for complex guided challenges to be implemented.
We'd like to build a challenge that guides the user through a series of steps to an end goal and teaches more information on the subject matter on the way.
This is a very open-ended project on purpose to allow creative student to come up with nice ideas.
Bellow you will find some examples that we thought might be interesting.

Ideas on the project:
* Purposefully vulnerable web page that guides the user via javascript tooltips and hints to exploiting it using ZAP. ( Bonus: using ZAP via the ZAP api). The challenge is solved when the the student submits the contents of a text file located on the disk (obtained by exploited an RCE)

* Reversing a provided binary to extract information by providing step by step instructions to reversing using any popular reversing tool (well, you can't use IDA so gdb should have to do). Challenge is solved when the keys are extracted from the binary and submitted. Bonus points if each binary donwloaded has different keys.

* Guide to exploiting the TOP10. (Using ZAP?)

* Defensive Type challenges -- Here's how to create a patch for this kind of vulnerability -- Challenge is solved when the unit tests are run and the vulnerability isn't there.

''' Getting started '''
* Check popular javascript guide tools such as: (http://introjs.com/ and http://github.hubspot.com/shepherd/docs/welcome/ )
* If you're more interested in system or non-web challenges check serverspec and definitely check quest (https://github.com/puppetlabs/quest)
* If you think contributing is a good idea to make yourself familiar with the project you can either port one of the existing simpler 1-page challenges to a docker container and submit a pull request or write a guide on how to create such a challenge

'''Expected Results:'''

* One or more Course - style challenges provided either as a docker container or as a vagrant box.
* Concrete documentation on how to build a challenge like this.

'''Knowledge Prerequisites:'''
The technologies used.

'''Mentors:''' [mailto:spyros.gasteratos@owasp.org Spyros Gasteratos] - Hackademic Challenges Project Leaders

GSOC2017 Ideas

2017-02-03T04:07:28Z

John Melton: Adding appsensor content

=OWASP Project Requests=

'''Tips to get you started in no particular order:'''
* Read the [[GSoC SAT]]
* Check out the suggested projects below
* Contact the mentors and teams of the projects that you are interested in

== OWASP Juice Shop ==

[[OWASP Juice Shop Project]] is an intentionally insecure webapp for security trainings written entirely in Javascript which encompasses the entire OWASP Top Ten and other severe security flaws. Juice Shop is written in Node.js, Express and AngularJS. The application contains more than 30 challenges of varying difficulty where the user is supposed to exploit the underlying vulnerabilities. Apart from the hacker and awareness training use case, pentesting proxies or security scanners can use Juice Shop as a "guinea pig"-application to check how well their tools cope with Javascript-heavy application frontends and REST APIs.

=== Challenge Pack 2017 ===

'''Brief Explanation:'''

Ideas for potential new hacking challenges are collected in [https://github.com/bkimminich/juice-shop/issues?q=is%3Aissue+is%3Aopen+label%3Achallenge GitHub issues labeled "challenge"]. This project could implement a whole bunch of challenges one by one and release them over the course of several small releases. This would allow the student to work in a professional Continuous Delivery kind of way while bringing benefit to the Juice Shop over the duration of the project.

Coming up with additional ideas for challenges would be part of the project scope, as the list of pre-existing ideas might not be sufficient for a GSoC project.

'''Expected Results:'''
* 10 or more new challenges for OWASP Juice Shop (including required functional enhancements to place the challenges in, e.g. the [https://github.com/bkimminich/juice-shop/issues/244 Order Dashboard] and [https://github.com/bkimminich/juice-shop/issues/243 Pomace Recycling user stories])
* Each challenge comes with full functional unit and integration tests
* Each challenge is verified to be exploitable by corresponding end-to-end tests
* Hint and solution sections for each new challenge are added to the "Pwning OWASP Juice Shop" ebook
* Code follows existing styleguides and passes all existing quality gates regarding code smells, test coverage etc.

''' Getting started: '''
* Get familiar with the architecture and code base of the application's rich Javascript frontend and RESTful backend
* Get a feeling for the high code & test quality bar by inspecting the existing test suites and static code analysis results
* Get familiar with the CI/CD process based on Travis-CI and several associated 3rd party services
* Check out the corresponding GitHub milestone for this project: https://github.com/bkimminich/juice-shop/milestone/3

'''Knowledge Prerequisites:'''
* Javascript, Unit/Integration testing, experience with (or willingness to learn) AngularJS (1.x) and NodeJS/Express, some security knowledge would be preferable.

'''Mentors:'''
* [https://www.owasp.org/index.php/User:Bjoern_Kimminich Bjoern Kimminich] - OWASP Juice Shop Project Leader

=== Tech Stack Update ===

'''Brief Explanation:'''

Development of OWASP Juice Shop started in 2014 and was based on - back then - quite recent Javascript frameworks and modules:

* AngularJS 1.x with Bootstrap in the client
* Express on top of NodeJS on the server with
** SQLite as a database
** Sequelize as an OR-Mapper
*** sequelize-restful as an automatic API-generator on top of the DB entities
* Jasmine 1.x to specify behavioral tests
** Karma as a test runner for the client-side unit tests
** Frisby.js for API tests on a dynamically launched server
** Protractor for end-to-end testing of the challenge exploits
* NPM for running/testing the application
* Grunt for some of the custom build scripts

Several of the above frameworks or modules have moved on to new (runtime incompatible) major releases, namely [https://github.com/bkimminich/juice-shop/issues/165 Angular 2], [https://github.com/bkimminich/juice-shop/issues/167 Sequelize], [https://github.com/bkimminich/juice-shop/issues/164 Frisby and Jasmine]. Other modules are out of maintenance entirely, e.g. [https://github.com/bkimminich/juice-shop/issues/167 sequelize-restful].

Migrating the OWASP Juice Shop to the latest versions of the mentioned frameworks & modules is an important step to keep the application relevant as ''the most modern'' intentionally broken web application. Moving to entirely different frameworks might be taken into considerationas well.

'''Expected Results:'''
* High-level target architecture overview including a migration plan with intermediary milestones
* Execution of migration without breaking functionality or losing tests along the way
* Code follows existing (or new) styleguides and passes all existing (or new) quality gates regarding code smells, test coverage etc.

''' Getting started: '''
* Get familiar with the architecture and code base of the application's rich Javascript frontend and RESTful backend
* Get a feeling for the high code & test quality bar by inspecting the existing test suites and static code analysis results
* Get familiar with the CI/CD process based on Travis-CI and several associated 3rd party services
* Check out the corresponding GitHub milestone for this project: https://github.com/bkimminich/juice-shop/milestone/2

'''Knowledge Prerequisites:'''
* Javascript, experience with latest Javascript frameworks for frontend, backend, testing and building (e.g. AngularJS 2.x, Jasmine 2.x, ...)

'''Mentors:'''
* [https://www.owasp.org/index.php/User:Bjoern_Kimminich Bjoern Kimminich] - OWASP Juice Shop Project Leader

=== Your idea ===

'''Brief Explanation:'''

You have an awesome idea to improve OWASP Juice Shop that is not on this list? Great, please submit it!

''' Getting started '''
* Get in touch with [https://www.owasp.org/index.php/User:Bjoern_Kimminich Bjoern Kimminich]

'''Expected Results:'''
* A new feature that makes OWASP Juice Shop even better
* Code follows existing styleguides and passes all existing quality gates regarding code smells, test coverage etc.

'''Knowledge Prerequisites:'''
* Javascript, Unit/Integration testing, experience with (or willingness to learn) AngularJS (1.x) and NodeJS/Express, some security knowledge would be preferable.

'''Mentors:'''
* [https://www.owasp.org/index.php/User:Bjoern_Kimminich Bjoern Kimminich] - OWASP Juice Shop Project Leader

== OWASP Mobile Hacking Playground ==

The OWASP Mobile Hacking Playground (https://github.com/OWASP/OMTG-Hacking-Playground) is part of the OWASP Mobile universe, which consists at the moment of the following projects:

* Mobile Application Security Verification (MASVS). The MASVS is a list of security requirements for mobile applications that can be used by architects, developers, testers, security professionals, and consumers to define what a secure mobile application is. (https://github.com/OWASP/owasp-masvs)
* Mobile Security Testing Guide (MSTG). The OWASP MSTG is a comprehensive manual for testing the security of mobile apps. It describes technical processes for verifying the controls listed in the OWASP Mobile Application Verification Standard (MASVS). The MSTG is meant to provide a baseline set of test cases for dynamic and static security tests, and to help ensure completeness and consistency of the tests. (https://github.com/OWASP/owasp-mstg)

In order to give also practical guidance to developers, security researches and penetration testers of mobile Apps, a hacking playground was created with the goal to create different mobile App’s that contain different vulnerabilities that map to the MSTG test cases. Every test case described in the MSTG will therefore be implemented in an Android and iOS App. This has two advantages:

* A developer can identify vulnerable code in the provided App’s and can see the implications and risks if such patterns are used and can look for the best practices in the MSTG to mitigate the vulnerabilities.
* Penetration testers / security researchers can identify bad practices, dangerous methods and classes they should look for when assessing a Mobile App and can gain more knowledge through the information provided in the OMTG.

It is also encouraged to use the App(s) for education purpose during trainings and workshops.

=== Creation of Android Code Samples ===

'''Brief Explanation:'''

An Android App that maps to the MSTG test cases is already created. This App contains mostly test cases that are related to data storage on an Android device. In order to close the gap to the MSTG more test cases need to be added that show "bad practices" that lead to vulnerabilites, but also the latest security best practices to demonstrate how vulnerabilites can be mitigated.

For examples of implemented test cases, see the Wiki of the Mobile Hacking Playground: https://github.com/OWASP/OMTG-Hacking-Playground/wiki/Android-App

'''Expected Results:'''

The following categories and their test cases are not fully added to the Android App:

* Cryptography (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x08-V3-Cryptography_Verification_Requirements.md)
* Authentication and Session Management (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x09-V4-Authentication_and_Session_Management%20Requirements.md)
* Network Communication (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x10-V5-Network_communication_requirements.md)
* Environmental Interaction (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x11-V6-Interaction_with_the_environment.md)
* Code Quality (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x12-V7-Code_quality_and_build_setting_requirements.md)

For some of the testcases this also includes creating an endpoint on server side in order to fully understand the test case and possible security concerns.

As not all missing test cases can be implemented during the GSOC a subset of them will be defined with the student together.

''' Getting started: '''
Here are a few suggestion on how to get started.
* Check the Mobile Hacking Playground Android App, browse through the code and Wiki to get an understanding of what a test case look likes.
* Browse through the MASVS and check the different areas and their defined requirements.
* Read about Security vulnerabilites and best practices for Android in areas you are interested in (e.g. Cryptography).

'''Knowledge Prerequisites:'''
General interest in Mobile and Security. Basic knowledge of Android and Java.

'''Mentors:''' [mailto:sven.schleier@owasp.org Sven Schleier] - OWASP Mobile Security Testing Guide and Mobile Hacking Playground Project Leader

== OWASP ZAP ==

[[OWASP Zed Attack Proxy Project]] (ZAP) The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers. Previous GSoC students have implemented key parts of the ZAP core functionality and have been offered (and accepted) jobs based on their work on ZAP.

We have just included a few of the ideas we have here, for a more complete list see the issues on the ZAP bug tracker with the [https://github.com/zaproxy/zaproxy/issues?q=is%3Aopen+is%3Aissue+label%3Aproject project] label.

=== Field Enumeration ===
:
:This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped.
:
:The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.
:
:''' Expected Results '''
:
:* User able to specify a specific field to enumerate via the ZAP UI
:* A list of all valid characters to be returned from the sets of characters the user specifies
:* Ability to configure a wide range of success and failure conditions to cope with as many possible situations as possible
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' 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.
:
:''' Mentors '''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team
:

=== Scripting Code Completion ===
:
:ZAP provides a very powerful scripting interface. Unfortunately to use it effectively is only really possible with a good knowledge of the ZAP internals. Adding code completion (eg using a project like https://github.com/bobbylight/AutoComplete) would significantly help users.
:
:''' Expected Results '''
:
:* Code completion for all of the parameters for all available functions in the standard scripts
:* Implementations for JavaScript, JRuby and Jython
:* Helper classes with code completion for commonly required functionality
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' Knowledge Prerequisite: '''
:ZAP is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== SSRF Detector Integration ===
:
:Currently ZAP does not detect SSRF vulnerabilities, due to the lack of this sort of service. https://ssrfdetector.com/ is an online service for detecting Server Side Request Forgery vulnerabilities (SSRF). It is developed and maintained by Jake Reynolds and is open source https://github.com/jacobreynolds/ssrfdetector
:
:''' Expected Results '''
:
:* Extend ZAP to detect SSRF vulnerabilities and interact with other services such as outlined above.
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' Knowledge Prerequisite: '''
:ZAP is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Zest Text Representation and Parser ===
:
:Zest is a graphical scripting language from the Mozilla Security team, and is used as the ZAP macro language.
:
:A standardized text representation and parser would be very useful and help its adoption.
:
:''' Expected Results '''
:
:* A documented definition of a text representation for Zest
:* A parser that converts the text representation into a working Zest script
:* An option in the Zest java implementation to output Zest scripts text format
:
:''' Knowledge Prerequisite: '''
:The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Support Java as a Scripting Language ===
:
:It would be very useful to support Java in addition to the JSR223 scripting languages within the ZAP script console'.
:
:It should be possible to provide much better auto complete support than will be possible with dynamically typed scripting languages.
:
:''' Expected Results '''
:
:* The ability to run Java code in the ZAP Script Console to the same leval as other supported scripting languages
:* Templates for all of the current script types
:* Optionally auto complete supported
:
:''' Knowledge Prerequisite: '''
:The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Bamboo Support ===
:
:ZAP already has an official plugin for Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/zap+plugin).
:
:It would be great if we also had similar integration for Bamboo (https://www.atlassian.com/software/bamboo, https://en.wikipedia.org/wiki/Bamboo_(software))
:
:''' Expected Results '''
:
:* Facilitate the invocation and configuration of various ZAP functionalities from Bamboo CI. Including (but not limited to):
::*Manage Sessions (Loading/Persisting)
::*Define Context (Name, Include & Exclude URLs)
::* Attack Contexts (Spider, Ajax Spider, Active Scan)
::* Setup Autentication (Formed or Script Based)
::* Generate Reports
:* Templates for all of the current script types
:* Optionally auto complete supported
:
:''' Knowledge Prerequisite: '''
:The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of CI/CD/Bamboo would be useful.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Backslash Powered Scanner ===
:
:This is a brand new technique developed by one of the Burp guys: http://blog.portswigger.net/2016/11/backslash-powered-scanning-hunting.html
:Their implementation is open source: https://github.com/PortSwigger/backslash-powered-scanner so hopefully shouldn't be too hard to port to ZAP :)
:
:''' Expected Results '''
:
:* Extend ZAP's active scanner to leverage Backslash type scanning.
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:''' Knowledge Prerequisite: '''
:ZAP is written in Java, so a good knowledge of this language is recommended.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team

=== Your Idea ===
:
:'''Brief Explanation:'''
:
:ZAP is a great framework for building new and innovative security testing solutions. If you have an idea that is not on this list then don't worry, you can still submit it, we have accepted original projects in previous years and have even paid a student to work on their idea when we did not get enough GSoC slots to accept all of the projects we wanted.
:
:''' Getting started '''
:* Get in touch with us :)
:
:'''Expected Results:'''
:* A new feature that makes ZAP even better
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
:
:'''Knowledge Prerequisites:'''
: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.
:
:'''Mentors:'''
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:psiinon@gmail.com @] and the rest of the ZAP Core Team
:

== BLT / Bugheist ==

'''Brief Explanation:'''

Bugheist lets anyone report issues they find on the internet. Found something out of place on Amazon.com ? Let them know. Companies are held accountable and shows their response time and history. Get points for reporting bugs and help keep the internet bug free.

''' Getting started '''
* Get in touch with us :)

'''Expected Results:'''
* A new feature that makes Bugheist even better

'''Knowledge Prerequisites:'''
BLT is written in Python / Django, so a good knowledge of this language and framework is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentors:'''
[https://www.owasp.org/index.php/User:Sauriti Sean Auriti] [mailto:sean.auriti@owasp.org @] and the rest of the BLT Core Team

== OWASP Security Knowledge framework ==

===Brief Explanation===
The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software. It can also be used to train developers about application security. Education is the first step in the Secure Software Development Lifecycle. This software can be run on Windows/Linux/OSX using python-flask.

'''In a nutshell'''

- Training developers in writing secure code

- Security support pre-development ( Security by design, early feedback of possible security issues )

- Security support post-development ( Double check your code by means of the OWASP ASVS checklists )

- Code examples for secure coding

===Your idea / Getting started===
* Please send an email to riccardo.ten.cate@owasp.org [riccardo.ten.cate@owasp.org] or glenn.ten.cate@owasp.org [glenn.ten.cate@owasp.org] and we would love to tell you all about it! :-)

===Expected Results===
* Adding features to SKF project
* Adding more function examples to pre-development phase
* Adding/updating code examples ( PHP, Java, .NET, Go, Python, NodeJS and more )
* Adding/updating Knowledgebase items
* Adding CWE references to knowledgebase items
* Adding low/medium level verification testing guides for developers to teach how to manually verify the existence of injection/logic flaws. (pen-testing)

===Knowledge Prerequisites===

* For helping in the development of new features and functions Python flask would come in handy since the framework is written in python flask.
* For writing knowledgebase items only technical knowledge of application security is required
* For writing / updating code examples you need to know a programming language along with secure development.
* For writing the verification guide you need some penetration testing experience.

'''Mentors:'''

Riccardo ten Cate [mailto:riccardo.ten.cate@owasp.org]
Glenn ten Cate [mailto:glenn.ten.cate@owasp.org]

== OWASP ZSC ==

'''Brief Explanation:'''

OWASP ZSC is an open source software in python language which lets you generate customized shellcodes and convert scripts to an obfuscated script. This software can be run on Windows/Linux/OSX under python
https://www.owasp.org/index.php/OWASP_ZSC_Tool_Project

''' Getting started '''
* Get in touch with us on Github:
https://github.com/zscproject/OWASP-ZSC

Project Leaders:
*https://www.owasp.org/index.php/User:Ali_Razmjoo
*https://www.owasp.org/index.php/User:Johanna_Curiel

'''Expected Results:'''
We have a list of potential modules we want to build
To get familiar with the project, please check our installation and developer guidelines:
https://www.gitbook.com/book/ali-razmjoo/owasp-zsc/details

Contact us through Github, send us a question:
https://github.com/zscproject/OWASP-ZSC

* New obfuscation modules
* New shellcodes for OSX and Windows

'''Knowledge Prerequisites:'''
OWASP ZSC is written in Python, so a good knowledge of this language and framework is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

'''Mentors:'''
Brian Beaudry & Patrik Patel
Please contact us through Github
https://github.com/zscproject/OWASP-ZSC

== OWASP Seraphimdroid mobile security project ==

=== Behavioral malware and intrusion analysis ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is an Android mobile app which already has a capability to statically analyze malware using machine learning (weka toolkit) relying on permissions. However, this is usually not enough and we intend to improve this with behavioral analysis. There are a number of paper in scientific literature describing how to detect malware and intrusions by dynamically analyzing its behavior (system calls, battery consumption, etc.). The idea of this project is to find the best approach that can be implemented on the device and implement it.

'''Expected Results:'''

* Reviewing scientific literature and find feasible approach we can take
* Implement and possibly improve the approach in Seraphimdroid
* Test the model and provide controls to switch algorithm on or off and possibly fine tune it
* Documenting approach as a technical report

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML
* Basic knowledge and interest in machine learning

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Framework for plugin development ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app, however, it lacks some components community can provide. We would like to provide community the way to develop plugins that can add features to OWASP Seraphimdroid app. However, the way of integrating external components into Android app may be challenge. The way of presenting GUI and integration between processes need to be examined and developed.

'''Expected Results:'''

* Examining the way of integrating third party apps through some provided API to OWASP Seraphimdroid
* Providing GUI integration with third party components
* Develop at least one test plugin
* Document the development process and API

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

== OWASP DefectDojo ==

'''Brief Explanation:'''

DefectDojo is a security automation and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, schedule scans, triage vulnerabilities and push findings into defect trackers.

'''Expected Results:'''

* Multiple opportunities for students to get involved with DefectDojo ranging in difficulty from easy to advanced
* Students will receive hands-on experience in a full-stack software development project
* Students will have the opportunity to work on a project with multiple moving parts and third-party interactions

'''Knowledge Prerequisites:'''
* Python
* HTML, Bootstrap

''' Getting started: '''
* We have a [http://defectdojo.readthedocs.io/en/latest/ Read the Docs Site]

'''Mentors:'''
* [[User:devgreg|Greg Anderson]] - OWASP DefectDojo Project Leader

== OWASP AppSensor ==

[[OWASP AppSensor Project]] The OWASP AppSensor project is a project to help you build self-defending applications through real-time event detection and response. Previous GSoC students have implemented key AppSensor contributions, and we've had very successful engagements. We look forward to hearing your ideas and hopefully working with you to execute them.

=== Machine Learning Driven Web Server Log Analysis ===
:
:'''Brief Explanation:'''
:
:The goal of this project would be to build a web server log analysis tool suite based on ML (machine learning). This tool suite will accept as input web server logs (apache, nginx) and will provide as output a determination of requests that are considered "attacks" There are a number of key points for this project:
:* Almost everybody has web server logs. It's a common format that is well understood, and is a good starting place for many security teams
:* Because the format is well understood, the data points (features) are well understood.
:* This tool suite would have applicability far beyond just our project. The goal is to give away a tool that can process a set of log files, build a custom model for the traffic, and then be used to process future log files and find attacks (outliers / anomalies)
:
:Note that this project would extend work done in last year's GSOC to get an initial machine learning capability developed.
:
:''' Expected Results '''
:
:* User provides tool suite a set of web server logs (User has option to annotate data set with known attacks)
:* System is pre-coded with knowledge of certain anomalous patterns (attacks)
:* System builds ML model for processing future log files
:* System provides mechanism for processing future logs using trained model.
:
:''' Knowledge Prerequisite: '''
:AppSensor is written in Java, so a good knowledge of this language is recommended. The toolset used previously for the ML effort was scala/spark, but this is not a hard requirement. The preference would be to use either the JVM (java/scala), or possibly python, as both of these stacks are well understood and have significant ML capabilities.
:
:''' Mentors '''
:[https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:jtmelton@gmail.com @] and the rest of the AppSensor Team
:

=== Your Idea ===
:
:'''Brief Explanation:'''
:
:AppSensor is a great tool and many organizations are starting to use it. If you have an idea that is not on this list, please submit it - we would love to give you the chance to work on an idea you came up with!
:
:''' Getting started '''
:* Get in touch with us :)
:
:'''Expected Results:'''
:* A new feature that makes AppSensor even better
:
:''' Knowledge Prerequisite: '''
:AppSensor is written in Java, so a good knowledge of this language is recommended.
:
:''' Mentors '''
:[https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:jtmelton@gmail.com @] and the rest of the AppSensor Team
:

GSOC2016 Ideas

2016-03-08T20:46:53Z

John Melton: updating appsensor reverse proxy example

=OWASP Project Requests=

'''Tips to get you started in no particular order:'''
* Read the [[GSoC SAT]]
* Check the Hackademic wiki page linked above
* Contact us through the mailing list or irc channel.
* Check our [https://github.com/Hackademic/hackademic github repository] and especially the [https://github.com/Hackademic/hackademic/issues open tickets]

== OWASP Hackademic Challenges ==

[[OWASP Hackademic Challenges Project]] helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. After a wonderfull 2014 GSoC with 100 new challenges and a couple of new plugins we're mainly looking to get new features in and maybe a couple of challenges. Bellow is a list of proposed features.

=== REST API for the sandbox ===

'''Brief Explanation:'''

During the last summer code sprint Hackademic got challenge sandboxing in the form of vagrant and docker wrappers as well as an engine to start and stop the container or vm instances.
What is needed now is a rest api which supports endpoint authentication and authorization which enables the sandbox engine to be completely independed from the rest of the project.

Ideas on the project:
Since the sandbox is written in python, you will be using Django to implement the api.
The endpoint authorization can be done via certificates or plain signature or username/password type authentication. We would like to see what's your idea on the matter.
However the communication between the two has to be over a secure channel.

'''Expected Results:'''
* A REST style api which allows an authenticated remote entity control the parts of the sandbox engine it has access to.
* PEP8 compliant code
* Acceptable unit test coverage

''' Getting started: '''
Since this has been a popular project here's a suggestion on how to get started.
* Check the excellent work done by mebjas and a0xnirudh in their respective brances in the project's repository
* Take a brief look at the code and try to get a feeling of the functionality included. (Essentially it's CRUD operations on vms or containers)
* Read on what Docker and Vagrant are and take a look at their respective py-libraries
* If you think that contributing helps perhaps it would be a good idea to start with lettuce tests on the current CRUD operations of the existing functionality(which won't change and can eventually be ported to the final project)

'''Knowledge Prerequisites:'''
Python, test driven development, some idea what REST is, some security knowledge would be preferable.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== New CMS ===

'''Brief Explanation:'''

The CMS part of the project is really old and has accumulated a significant amount of technical debt.
In addition many design decisions are either outdated or could be improved.
Therefore it may be a good idea to leverage the power of modern web frameworks to create a new CMS.
The new cms can be written in python using Django.

'''Expected Results:'''
* New cms with same functionality as the old one (3 types of users -- student, teacher, admin--, 3 types of resources -- article challenge, class--, ACL type permissions, CRUD operations on every resource/user, all functionality can be extended by Plugins.
* REST endpoints in addition to classic ones
* tests covering all routes implemented, also complete ACL unit tests, it would be embarassing if a cms by OWASP has rights vulnerabilities.
* PEP 8 code

''' Note: '''
This is a huge project, it is ok if the student implements a part of it. However whatever implemented must be up to spec.
If you decide to take on this project contact us and we can agree on a list of routes.
If you don't decide to take on this project contact us.
Generally contact us, we like it when students have insightful questions and the community is active

''' Getting Started: '''
* Install and take a brief look around the old cms so you have an idea of the functionality needed
* It's ok to scream in frustration
* If you want to contribute to get a feeling of the platform a good idea would be lettuce tests for the current functionality (which won't change and you can port in the new cms eventually)

'''Knowledge Prerequisites:'''
Python, Django, what REST is, the technologies used, some security knowledge would be nice.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== First Course Type Challenge ===

'''Brief Explanation:'''
We have a wonderful sandbox engine which allows for complex guided challenges to be implemented.
We'd like to build a challenge that guides the user through a series of steps to an end goal and teaches more information on the subject matter on the way.
This is a very open-ended project on purpose to allow creative student to come up with nice ideas.
Bellow you will find some examples that we thought might be interesting.

Ideas on the project:
* Purposefully vulnerable web page that guides the user via javascript tooltips and hints to exploiting it using ZAP. ( Bonus: using ZAP via the ZAP api). The challenge is solved when the the student submits the contents of a text file located on the disk (obtained by exploited an RCE)

* Reversing a provided binary to extract information by providing step by step instructions to reversing using any popular reversing tool (well, you can't use IDA so gdb should have to do). Challenge is solved when the keys are extracted from the binary and submitted. Bonus points if each binary donwloaded has different keys.

* Guide to exploiting the TOP10. (Using ZAP?)

* Defensive Type challenges -- Here's how to create a patch for this kind of vulnerability -- Challenge is solved when the unit tests are run and the vulnerability isn't there.

''' Getting started '''
* Check popular javascript guide tools such as: (http://introjs.com/ and http://github.hubspot.com/shepherd/docs/welcome/ )
* If you're more interested in system or non-web challenges check serverspec and definitely check quest (https://github.com/puppetlabs/quest)
* If you think contributing is a good idea to make yourself familiar with the project you can either port one of the existing simpler 1-page challenges to a docker container and submit a pull request or write a guide on how to create such a challenge

'''Expected Results:'''

* One or more Course - style challenges provided either as a docker container or as a vagrant box.
* Concrete documentation on how to build a challenge like this.

'''Knowledge Prerequisites:'''
The technologies used.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Advanced Sandboxed Challenges ===

'''Brief Explanation:'''

In the spirit of the challenges above, we're looking for true ctf type challenges.
This is an open ended task. We're expecting awesome fresh ideas.

Ideas on the project:
* An application vulnerable to one or more TOP 10 elements.
* A logic flaws based ctf
* Your idea here

''' Getting started: '''
* Check what Vagrant/Docker is
* Port one simple 1-page challenge (you can use one we already have ) to docker or vagrant

'''Expected Results:'''
Docker containers or Vagrant boxes that contain complete new challenges.

'''Knowledge Prerequisites:'''
Knowledge of the technologies used

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Your idea ===

'''Brief Explanation:'''

Amazing students, in our experience, the best, most creative and unique ideas show up when we let students suggest their own feature in relation to the project.
The above should give you a general idea where we're going but don't let them constrain you.
Do you wanna do something that would fit into Hackademic? Send us an email!

Ideas on the project:
No idea, that's your turn to shine!

''' Getting started '''
* Be awesome
* Have an idea
* Be a student
* Explain definite proof of the p vs np solution(jk, an algorithm that breaks RSA in polynomial time would be totally acceptable)

'''Expected Results:'''
If it's code, code according to our coding standards.
If it's challenges, something new and interesting.
If it's something else, then written like the person who's going to maintain your code is a raging psychopath with an axe who knows where you live.

In short we'd like some quality. ;-)

'''Knowledge Prerequisites:'''

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

== OWASP OWTF ==

===OWASP OWTF - Web UI Improvements ===

'''Brief explanation:'''

The current OWTF web interface is not very optimized and needs some work to reduce the number of clicks. The OWTF report uses accordion style components to render plugin outputs. This not very efficient in terms of number of clicks, horizontal and vertical scrolling. React.js offers a simple way to build complex interfaces with the help of OWTF ReST APIs. Another part of the project will involve creating a maintainable CSS/JS system with latest frontend technologies like SASS, Compass, Gulp, and React.js (Flux).
As part of the project, you will learn about iterating your mockup designs and share those with the project leader(s) and the community for feedback. The existing stack is based on simple ReST APIs and vanilla Javascript. There are lots of features to be added, and you'll work with the project leader(s) and the community to build the most-needed and requested capabilities.

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: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
*'''CRITICAL''': Excellent reliability and performance.
*Good documentation

'''Knowledge Prerequisite:'''
Python, HTML5/CSS3/JS and React.JS experience 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.

'''OWASP OWTF Mentors:'''
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Link to the repository: [https://github.com/owtf/http-request-translator/tree/dev]'''

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

'''Feature 8) PostgreSQL (DB) health monitor'''

The pentester can should be able to see the metrics of how much RAM/CPU the DB operations like INSERT are taking so as to maintain a healthy DB (as all data is saved in DB)

'''Feature 9) Component health like MiTM proxy metrics, cache I/O, Log files'''

Ability to see the proxy metrics, cache files I/O, and point-and-click log files streaming

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python, bash and Golang experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== 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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Intercepting proxy ===

'''Brief explanation:'''

The OWTF MiTM proxy can proxify most of the traffic (inbound+outbound) but it doesn’t have an intercepting capability ie. it cannot pause the framework + let the user modify the transaction on the fly.
Most of the GUI proxy tools like Paros, mitmproxy, Burp and OWASP ZAP have this functionality.

This project is about adding intercepting proxy capabilities to OWTF which can be used through the Web UI. Unlike Burp or ZAP, OWTF can be running multiple proxified tools while the user attempts to intercept an HTTP request, which makes interception significantly more difficult. For this reason, the user will be offered several interception options

1)Intercept all the requests: Useful when user manually browses the target without any tools running in background

2) Selective Interception (default): The user here can select a number of conditions, similar to the "Break" menu in ZAP for selective interception. For example:
- The request "User Agent" header contains "xyz"
- The request "Accept" header contains "abc"
- The request is a GET/POST/DELETE request

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python, bash and experience with HTTP internals 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.

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Tool utilities module ===

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

''' OWASP Mentors '''

== OWASP ZAP ==

ZAP is one of the top OWASP projects and the most active open source web security tools.

You can follow (and join in) the GSoC discussions on the ZAP Developer Group: https://groups.google.com/d/msg/zaproxy-develop/Uy0JPkzsI_s/Bj7OTSkISCIJ

=== Bug tracker support ===

This would allow ZAP users to raise issues in bug trackers directly within ZAP. Ideally it would be implemented as an extension with a generic framework and then adaptors for specific trackers, like github and bugzilla.

The info included in the issues raised should be as configurable as possible so that users can include whatever they want, and set things like custom fields.

''' Expected Results '''

* Raise issues in github and bugzilla from alerts within the ZAP UI
* Support for raising alerts using the ZAP API
* High level of customization so that users can tune to their requirements

''' 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.

''' Mentors '''
Simon Bennetts and other members of the ZAP core team

=== Field enumeration ===

This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped.

The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.

''' Expected Results '''

* User able to specify a specific field to enumerate via the ZAP UI
* A list of all valid characters to be returned from the sets of characters the user specifies
* Ability to configure a wide range of success and failure conditions to cope with as many possible situations as possible

''' 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.

''' Mentors '''
Simon Bennetts and other members of the ZAP core team

=== Form Handling ===

The ZAP traditional and Ajax spiders explore an application by putting basic default values in all forms. These may often not be valid values, for example using "ZAP" when an email address is required.

The enhancement would allow the user to define default values based on pattern matching against the field names and/or ids.

It would also be very useful if it could show the user all forms and their associated fields for an application, and then allow the user to update the default values.

''' Expected Results '''

* User able to specify default values for all forms used by the ZAP spiders
* Display all of the forms and fields for an application and allow the user to update the default values to be used
* Full support for defining default values via the API

''' 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.

''' Mentors '''
Simon Bennetts and other members of the ZAP core team

=== Automated authentication detection and configuration ===

ZAP has extensive support for supporting application authentication, but configuring this is a manual process which can be tricky to get right.

The enhancement would allow ZAP to detect as many forms of authentication as possible and automatically configure them using the existing ZAP functionality.

''' Expected Results '''

* Automatically detect a wide range of authentication mechanisms
* Automatically configure ZAP to handle them
* Full support via the API

''' 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.

''' Mentors '''
Simon Bennetts and other members of the ZAP core team

=== Advanced padding oracle testing and exploitation ===

ZAP has currently has very minimal support in it's the (beta) [https://github.com/zaproxy/zap-extensions/blob/beta/src/org/zaproxy/zap/extension/ascanrulesBeta/PaddingOraclePlugin.java PaddingOraclePlugin] for identifying potential [https://en.wikipedia.org/wiki/Padding_oracle_attack padding oracle] vulnerabilities. Specifically, it only examines two indicators for possible oracles (changing the last byte of padding by XORing it with 0x1 and resubmitting the HTTP request with the new altered parameter to see if the HTTP response contains some error patter or to check if the returned HTTP status is a 500 error. Furthermore, it is limited to checking parameters, but encrypted values that may be susceptible to padding oracle attacks may also be in HTTP cookies or even HTTP request / response values. (In the latter case, these custom headers are usually manipulated via AJAX.) Lastly SOAP messages using [https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html W3C XML Encryption] and JSON are other potential sources of padding oracle vulnerabilities that might be examined.

The enhancement would extend the support to more a broader attack surface such as new attack vectors like cookies, HTTP headers, and possibly XML or JSON and also expand the identification of potential new oracles to not just keywords, but to any minute difference in responses (at least for idempotent GETs) or significant variations in time. Lastly, we would like to add the ability to exploit padding oracle vulnerabilities discovered which could lead to whole lot of other interesting discoveries.

''' Expected Results '''

* Detect oracle padding vulnerabilities in more situations
** Expanded attack vectors: cookies, HTTP headers, XML, JSON
** Expanded variation of recognized potential oracles: ''any'' output differences when padding correct vs. incorrect (takes much more than flipping a single padding bit), significant differences in timing, etc.
* Add the option to actually attempt to exploit discovered potential padding oracle vulnerabilities and report additional subsequent findings once the ciphertext is actually decrypted.
* Build test code to illustrate a working proof of concept

''' 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. Reading up on basic details of how padding oracle attacks operate would also be extremely helpful.

''' Mentors '''
Kevin Wall (cryptography subject matter expert) and other members of the ZAP core team

=== Zest text representation and parser ===

Zest is a graphical scripting language from the Mozilla Security team, and is used as the ZAP macro language.

A standardized text representation and parser would be very useful and help its adoption.

''' Expected Results '''

* A documented definition of a text representation for Zest
* A parser that converts the text representation into a working Zest script
* An option in the Zest java implementation to output Zest scripts text format

''' Knowledge Prerequisite: '''
The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of application security would be useful, but not essential.

''' Mentors '''
Simon Bennetts and other members of the ZAP core team

=== Your idea ===

We're always open to students coming up with their own suggestions for ZAP projects, so if you have something you think would make ZAP better then please get in touch!

''' Expected Results '''

* That depends on your project, but clearly defined goals will be necessary

''' 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.

''' Mentors '''
Simon Bennetts and other members of the ZAP core team

== OWASP AppSensor ==

[[OWASP AppSensor Project]] provides real-time application layer intrusion detection.

* Check the AppSensor wiki page linked above
* Contact us through the mailing list.
* Check our [https://github.com/jtmelton/appsensor github repository] and the [https://github.com/jtmelton/appsensor/issues open tickets]
* Also see our [http://www.appsensor.org appsensor website]

=== Dashboard UI Expansion ===

'''Brief Explanation:'''

AppSensor provides a solid base of functionality to applications, and we currently have a minimal application for data display. This project will involve expanding the default/standard UI for the AppSensor project. As part of the project, you will learn about the domain model, iterating your mockup designs and share those with the project leader(s) and the community for feedback. The existing stack is based on spring boot and reactjs. There are lots of features to be added, and you'll work with the project leader(s) and the community to build the most-needed and requested capabilities.

'''Expected Results:'''

The existing dashboard application will be expanded and will involve features like:
* Search (could involve significant back-end work to configure indexing, etc.)
* Policy Management (edit server configuration in real-time)
* Data visualization / dashboarding

Source code, tests, and associated documentation for both the back-end and UI will be delivered for this effort.

'''Knowledge Prerequisites:'''

Comfortable with UI design and development, particularly building dashboards. Comfortable with Java (with some assistance). Basic familiarity with security concepts related to intrusion detection and prevention as this is the domain.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Trend Monitoring Analysis Engine ===

'''Brief Explanation:'''

AppSensor currently supports a basic policy-driven analysis engine to determine if a series of events represents an attack (if a user triggers 5 of this type of event in 10 minutes, it's an attack). While this supports many use cases, there are times when it would be helpful to know trending information. If a particular function of the application begins to see 10 times its normal amount of traffic, that might represent an attack. This project would add an additional analysis engine to support "trend monitoring". Development of this feature would require some initial research on alternative implementation strategies, followed by the development and testing of the feature in AppSensor.

'''Expected Results:'''

The project should produce:
* A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
* Associated configuration mechanism to specify the trending rules/policy
* A small full sample demo application showing usage of the trend monitoring feature

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Expand language support for clients ===

'''Brief Explanation:'''

AppSensor supports various modes for communication with the server. The language and framework of the client application are required only to support the given mode. This flexibility is desirable, but having pre-built clients in various languages is useful for our user-base. This project would involve working with various popular languages and frameworks to build support for communicating with the appsensor server backend.

'''Expected Results:'''

The project should produce:
* Clients in multiple popular languages for interaction with appsensor server
* Evaluate the possibility for generating clients from specification as opposed to writing and maintaining the code (ie. swagger for REST)
* At a minimum, coverage for the HTTP/REST mode should be supported. Other modes (thrift, soap, kafka, etc.) will be produced as time allows.
* Several small demo applications showing usage of the given APIs

Source code and tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable working in multiple popular languages and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Implement Detection Points in Reverse Proxy ===

'''Brief Explanation:'''

AppSensor works by tracking events that are created by "detection points", essentially locations in the processing pipeline where suspicious or malicious intent is observed. This often requires business-specific detection within the application. However, the project has defined a number of detection points (https://www.owasp.org/index.php/AppSensor_DetectionPoints) and responses (https://www.owasp.org/index.php/AppSensor_ResponseActions), some of which can be generically applied across a broader set of applications, including those that are common to an entire organization or even cross-organization. For that reason, a sub-project has been created (https://github.com/jtmelton/appsensor-reverse-proxy) that provides support for detection points and responses that are generic enough to be broadly applicable. This project would expand support for these detection points and responses.

'''Expected Results:'''

The project should produce:
* New detection points and responses
** Examples:
***Look at how many cookies a session has. There is a maximum between browsers. We need to check between browsers I think the max is 255 or something. The point of checking for more cookies than that is to prevent cookie overflow.
***Look at how many characters a cookie contains.
***Some header related checks.
* Documentation for how to deploy the project and any end-user considerations
* Load testing each function as this project front-ends applications, and traffic throughput characteristics are important to our user-base.
* A small sample demo application showing the utility of the proxy. A recording of the usage for community viewing would be beneficial.

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in golang and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

== OWASP Seraphimdroid [[OWASP_SeraphimDroid_Project| ]] ==

=== Behavioral malware and intrusion analysis ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is an Android mobile app which already has a capability to statically analyze malware using machine learning (weka toolkit) relying on permissions. However, this is usually not enough and we intend to improve this with behavioral analysis. There are a number of paper in scientific literature describing how to detect malware and intrusions by dynamically analyzing its behavior (system calls, battery consumption, etc.). The idea of this project is to find the best approach that can be implemented on the device and implement it.

'''Expected Results:'''

* Reviewing scientific literature and find feasible approach we can take
* Implement and possibly improve the approach in Seraphimdroid
* Test the model and provide controls to switch algorithm on or off and possibly fine tune it
* Documenting approach as a technical report

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML
* Basic knowledge and interest in machine learning

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Framework for plugin development ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app, however, it lacks some components community can provide. We would like to provide community the way to develop plugins that can add features to OWASP Seraphimdroid app. However, the way of integrating external components into Android app may be challenge. The way of presenting GUI and integration between processes need to be examined and developed.

'''Expected Results:'''

* Examining the way of integrating third party apps through some provided API to OWASP Seraphimdroid
* Providing GUI integration with third party components
* Develop at least one test plugin
* Document the development process and API

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Educational component ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app. The initial idea of the project was to provide educational platform for common users, where by using the application, users can learn about risks for their privacy and security. Some components already has some sort of explanation, which is educational. However, it lacks of uneatable knowledge source and some of the components that monitor user's behavior do not provide sufficient information. Idea of this project is to develop monitoring of user activity and an component that can warn user about risks if he does something risky. Also, mobile security knowledge base that can be updated remotely will be a huge new asset to the application.

'''Expected Results:'''

* Develop uneatable knowledge base and GUI for it
* Develop web server where the knowledge base can be updated
* Improve current educational reporting
* Develop methodology for monitoring users and notifying them about risky activities

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

== OWASP ZSC Tool ==

'''Brief Explanation:'''

[[OWASP_ZSC_Tool_Project|OWASP ZSC]] is an open source software in python language which lets you generate customized shellcodes and convert scripts to an obfuscated script. This software can be run on Windows/Linux/OSX under python.

'''Expected Results:'''

Please take a look of our TODO list in Github to get some ideas:
https://github.com/Ali-Razmjoo/OWASP-ZSC/issues

Another ideas:
* Help us develop shellcode module for windows
* Develop shellcode module for OSX

Read about the project here:
https://ali-razmjoo.gitbooks.io/owasp-zsc/content/

Recommended reading:
http://www.vividmachines.com/shellcode/shellcode.html

'''Knowledge Prerequisites:'''
* Python
* Basic knowledge about Shellcode and assembly language

'''Mentors:'''
*Christo and Timo Goosen and Brian Beaudry- OWASP ZSC Contributors

Contact us through our mailing list for questions:
https://groups.google.com/d/forum/owasp-zsc

== OWASP-SKF (Security Knowledge Framework) ==

'''Brief Explanation:'''
The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software. It can also be used to train developers about application security. Education is the first step in the Secure Software Development Lifecycle. This software can be run on Windows/Linux/OSX under python.

The 4 Core usage of SKF:

Security Requirements OWASP ASVS for development and for third party vendor applications
Security knowledge reference (Code examples/ Knowledge Base items)
Security is part of design with the pre-development functionality in SKF
Security post-development functionality in SKF for verification with the OWASP ASVS

'''Expected Results:'''

More code examples for different languages
Better quality of the knowledge base items
More items in the pre-development phase
Editable checklists in the post-development phase

We really would love to improve the quality of the knowledge base items further, also we would love to have more code examples in the different languages like: Perl, Hack, Go, Node.js and more.

Please take a look of our TODO list in Github to get some ideas:
https://github.com/blabla1337/skf-flask/issues

Another ideas:
* Help us with stuff you think is missing in the SKF project

Read about the project here:
https://skf.readme.io

Recommended reading (here you find a link to the Online Demo):
https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework

'''Knowledge Prerequisites:'''
* Python, PHP, Hack, .NET, GO, Ruby, Perl, Java, Node.js
* Basic knowledge about programming in one of the above languages

'''Mentors:'''
*Glenn and Riccardo ten Cate- OWASP-SKF project leaders
*Martin Knobloch Chapter leader of OWASP NL

GSOC2016 Ideas

2016-02-19T06:32:46Z

John Melton: adding brief comment

=OWASP Project Requests=

'''Tips to get you started in no particular order:'''
* Read the [[GSoC SAT]]
* Check the Hackademic wiki page linked above
* Contact us through the mailing list or irc channel.
* Check our [https://github.com/Hackademic/hackademic github repository] and especially the [https://github.com/Hackademic/hackademic/issues open tickets]

== OWASP Hackademic Challenges ==

[[OWASP Hackademic Challenges Project]] helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. After a wonderfull 2014 GSoC with 100 new challenges and a couple of new plugins we're mainly looking to get new features in and maybe a couple of challenges. Bellow is a list of proposed features.

=== REST API for the sandbox ===

'''Brief Explanation:'''

During the last summer code sprint Hackademic got challenge sandboxing in the form of vagrant and docker wrappers as well as an engine to start and stop the container or vm instances.
What is needed now is a rest api which supports endpoint authentication and authorization which enables the sandbox engine to be completely independed from the rest of the project.

Ideas on the project:
Since the sandbox is written in python, you can use microframeworks such as flask to implement the api.
The endpoint authorization can be done via certificates or plain signature or username/password type authentication.
However the communication between the two has to be over a secure channel.

'''Expected Results:'''
* A REST style api which allows an authenticated remote entity control the sandbox engine.
* PEP8 compliant code
* Acceptable unit test coverage

'''Knowledge Prerequisites:'''

Python, test driven developmen, some idea what REST is, some security knowledge would be preferable.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== New CMS ===

'''Brief Explanation:'''

The CMS part of the project is really old and has accumulated a significant amount of technical debt.
In addition many design decisions are either outdated or could be improved.
Therefore it may be a good idea to leverage the power of modern web frameworks to create a new CMS.
The new cms can be written in php or python using any compoennts we agree are necesary and based on the framework we agree on.

'''Expected Results:'''
* New cms with same functionality as the old one (3 types of users -- student, teacher, admin--, 3 types of resources -- article challenge, class--, ACL type permissions, CRUD operations on every resource/user, all functionality can be extended by Plugins.
* REST endpoints in addition to classic ones
* tests covering all routes implemented
* PSR/PEP 8 code

''' Note: '''
This is a huge project, it is ok if the student implements a part of it. However whatever implemented must be up to spec.
If you decide to take on this project contact us and we can agree on a list of routes.
If you don't decide to take on this project contact us.
Generally contact us, we like it when students have insightful questions and the community is active

'''Knowledge Prerequisites:'''
Python or PHP, the framework suggested, what REST is, the technologies used, some security knowledge would be nice.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== First Course Type Challenge ===

'''Brief Explanation:'''
We have a wonderful sandbox engine which allows for complex guided challenges to be implemented.
We'd like to build a challenge that guides the user through a series of steps to an end goal and teaches more information on the subject matter on the way.
This is a very open-ended project on purpose to allow creative student to come up with nice ideas.
Bellow you will find some examples that we thought might be interesting.

Ideas on the project:
* Purposefully vulnerable web page that guides the user via javascript tooltips and hints to exploiting it using ZAP. ( Bonus: using ZAP via the ZAP api). The challenge is solved when the the student submits the contents of a text file located on the disk (obtained by exploited an RCE)

* Reversing a provided binary to extract information by providing step by step instructions to reversing using any popular reversing tool (well, you can't use IDA so gdb should have to do). Challenge is solved when the keys are extracted from the binary and submitted. Bonus points if each binary donwloaded has different keys.

* Guide to exploiting the TOP10. (Using ZAP?)

* Defensive Type challenges -- Here's how to create a patch for this kind of vulnerability -- Challenge is solved when the unit tests are run and the vulnerability isn't there.

'''Expected Results:'''

* One or more Course - style challenges provided either as a docker container or as a vagrant box.
* Concrete documentation on how to build a challenge like this.

'''Knowledge Prerequisites:'''
The technologies used.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Advanced Sandboxed Challenges ===

'''Brief Explanation:'''

In the spirit of the challenges above, we're looking for true ctf type challenges.
This is an open ended task. We're expecting awesome fresh ideas.

Ideas on the project:
* An application vulnerable to one or more TOP 10 elements.
* A logic flaws based ctf
* Your idea here

'''Expected Results:'''
Docker containers or Vagrant boxes that contain complete new challenges.

'''Knowledge Prerequisites:'''
Knowledge of the technologies used

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Your idea ===

'''Brief Explanation:'''

Amazing students, in our experience the best, most creative and unique ideas show up when we let students suggest their own feature in relation to the project.
The above should give you a general idea where we're going but don't let them constrain you.
Do you wanna do something that would fit into Hackademic? Send us an email!

Ideas on the project:
No idea, that's your turn to shine!

'''Expected Results:'''
If it's code, code according to our coding standards.
If it's challenges, something new and interesting.
If it's something else, then written like the person who's going to maintain your code is a raging psychopath with an axe who knows where you live.

In short we'd like some quality. ;-)

'''Knowledge Prerequisites:'''

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

== OWASP OWTF ==

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - JavaScript Library Sniper Improvements ===

'''Brief explanation:'''
This is a project that tries to resolve a very common problem during penetration tests:

The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.

To solve this problem, we propose a *standalone* *tool* that can:

1) Be run BOTH from inside AND outside of OWTF

2) Build and *update* a fingerprint JavaScript library database of:
* Library File hashes => JavaScript Library version
* Library File lengths => JavaScript Library version
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)

3) Build and *update* a vulnerability database of:
* JavaScript Library version => CVE - CVSS score - Vulnerability info

4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
* JavaScript Library version
* List of vulnerabilities sorted in descending CVSS score order

5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
* ALL Library/vulnerability matches described on 4)

Once the standalone tool is built and verified to be working, OWTF should be able to:

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):

1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-

2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)

Potential projects worth having a look for potential overlap/inspiration:
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]

How many JavaScript libraries should be included?
* As many as possible, but especially the major ones: jQuery, knockout, etc.
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-

Common JavaScript library fingerprinting techniques include:
* Parse the JavaScript file and grab the version from there
* Determine the JavaScript version based on a hash of the file
* Determine the JavaScript version based on the length of the file

Other Challenges:
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
* When the JavaScript file does not match a specific version:
1) The commit that matches the closest should (ideally) be found
2) The NEXT library version after that commit (if present) should be found
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Installation Improvements and Package manager ===

'''Brief explanation:'''

This project is to implement what was suggested in the following github issue:
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]

Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
Having a private server with:
* pre-installed files for VMs
* pre-configured and patched tools
* Merged Lists
* Pre-configured certificates
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
Additional ideas are welcome.

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes
* For high speed connections (Downloading the files uncompressed)
* For low speed connections (Downloading the files compressed)
and the installation crashed because i runned out of space in the vm
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== 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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Tool utilities module ===

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

''' OWASP Mentors '''

== OWASP ZAP ==

We are in the process of deciding the set of ZAP projects for Google Summer of Code 2015.

You can follow (and join in) the discussions on the ZAP Developer Group: https://groups.google.com/d/msg/zaproxy-develop/Uy0JPkzsI_s/Bj7OTSkISCIJ

=== Example Idea ===

Currently ZAP provides only a limited set of report data. While this can be extended dynamically this feature is not currently used, and there is no way for users to choose what data they get back. It also provides a set of API calls, some of which return data that could be incorporated into reports, and some of which allow the fixed report to be accessed.

==== Expected Results ====

* Report data will be a distinct type of data returned via API calls
* An add-on that provides report data - so this becomes 'plug-able'
* Report data and meta data should be fully internationalized
* Users can specify which sites / contexts report data should apply to

==== 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.

==== Mentors ====
Simon Bennetts

== OWASP AppSensor ==

[[OWASP AppSensor Project]] provides real-time application layer intrusion detection.

* Check the AppSensor wiki page linked above
* Contact us through the mailing list.
* Check our [https://github.com/jtmelton/appsensor github repository] and the [https://github.com/jtmelton/appsensor/issues open tickets]
* Also see our [http://www.appsensor.org appsensor website]

=== Dashboard UI Expansion ===

'''Brief Explanation:'''

AppSensor provides a solid base of functionality to applications, and we currently have a minimal application for data display. This project will involve expanding the default/standard UI for the AppSensor project. As part of the project, you will learn about the domain model, iterating your mockup designs and share those with the project leader(s) and the community for feedback. The existing stack is based on spring boot and reactjs. There are lots of features to be added, and you'll work with the project leader(s) and the community to build the most-needed and requested capabilities.

'''Expected Results:'''

The existing dashboard application will be expanded and will involve features like:
* Search (could involve significant back-end work to configure indexing, etc.)
* Policy Management (edit server configuration in real-time)
* Data visualization / dashboarding

Source code, tests, and associated documentation for both the back-end and UI will be delivered for this effort.

'''Knowledge Prerequisites:'''

Comfortable with UI design and development, particularly building dashboards. Comfortable with Java (with some assistance). Basic familiarity with security concepts related to intrusion detection and prevention as this is the domain.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Trend Monitoring Analysis Engine ===

'''Brief Explanation:'''

AppSensor currently supports a basic policy-driven analysis engine to determine if a series of events represents an attack (if a user triggers 5 of this type of event in 10 minutes, it's an attack). While this supports many use cases, there are times when it would be helpful to know trending information. If a particular function of the application begins to see 10 times its normal amount of traffic, that might represent an attack. This project would add an additional analysis engine to support "trend monitoring". Development of this feature would require some initial research on alternative implementation strategies, followed by the development and testing of the feature in AppSensor.

'''Expected Results:'''

The project should produce:
* A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
* Associated configuration mechanism to specify the trending rules/policy
* A small full sample demo application showing usage of the trend monitoring feature

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Expand language support for clients ===

'''Brief Explanation:'''

AppSensor supports various modes for communication with the server. The language and framework of the client application are required only to support the given mode. This flexibility is desirable, but having pre-built clients in various languages is useful for our user-base. This project would involve working with various popular languages and frameworks to build support for communicating with the appsensor server backend.

'''Expected Results:'''

The project should produce:
* Clients in multiple popular languages for interaction with appsensor server
* Evaluate the possibility for generating clients from specification as opposed to writing and maintaining the code (ie. swagger for REST)
* At a minimum, coverage for the HTTP/REST mode should be supported. Other modes (thrift, soap, kafka, etc.) will be produced as time allows.
* Several small demo applications showing usage of the given APIs

Source code and tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable working in multiple popular languages and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Implement Detection Points in Reverse Proxy ===

'''Brief Explanation:'''

AppSensor works by tracking events that are created by "detection points", essentially locations in the processing pipeline where suspicious or malicious intent is observed. This often requires business-specific detection within the application. However, the project has defined a number of detection points (https://www.owasp.org/index.php/AppSensor_DetectionPoints) and responses (https://www.owasp.org/index.php/AppSensor_ResponseActions), some of which can be generically applied across a broader set of applications, including those that are common to an entire organization or even cross-organization. For that reason, a sub-project has been created (https://github.com/jtmelton/appsensor-reverse-proxy) that provides support for detection points and responses that are generic enough to be broadly applicable. This project would expand support for these detection points and responses.

'''Expected Results:'''

The project should produce:
* New detection points and responses
* Documentation for how to deploy the project and any end-user considerations
* Load testing each function as this project front-ends applications, and traffic throughput characteristics are important to our user-base.
* A small sample demo application showing the utility of the proxy. A recording of the usage for community viewing would be beneficial.

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in golang and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

== OWASP Seraphimdroid [[OWASP_SeraphimDroid_Project| ]] ==

=== Behavioral malware and intrusion analysis ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is an Android mobile app which already has a capability to statically analyze malware using machine learning (weka toolkit) relying on permissions. However, this is usually not enough and we intend to improve this with behavioral analysis. There are a number of paper in scientific literature describing how to detect malware and intrusions by dynamically analyzing its behavior (system calls, battery consumption, etc.). The idea of this project is to find the best approach that can be implemented on the device and implement it.

'''Expected Results:'''

* Reviewing scientific literature and find feasible approach we can take
* Implement and possibly improve the approach in Seraphimdroid
* Test the model and provide controls to switch algorithm on or off and possibly fine tune it
* Documenting approach as a technical report

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML
* Basic knowledge and interest in machine learning

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Framework for plugin development ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app, however, it lacks some components community can provide. We would like to provide community the way to develop plugins that can add features to OWASP Seraphimdroid app. However, the way of integrating external components into Android app may be challenge. The way of presenting GUI and integration between processes need to be examined and developed.

'''Expected Results:'''

* Examining the way of integrating third party apps through some provided API to OWASP Seraphimdroid
* Providing GUI integration with third party components
* Develop at least one test plugin
* Document the development process and API

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Educational component ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app. The initial idea of the project was to provide educational platform for common users, where by using the application, users can learn about risks for their privacy and security. Some components already has some sort of explanation, which is educational. However, it lacks of uneatable knowledge source and some of the components that monitor user's behavior do not provide sufficient information. Idea of this project is to develop monitoring of user activity and an component that can warn user about risks if he does something risky. Also, mobile security knowledge base that can be updated remotely will be a huge new asset to the application.

'''Expected Results:'''

* Develop uneatable knowledge base and GUI for it
* Develop web server where the knowledge base can be updated
* Improve current educational reporting
* Develop methodology for monitoring users and notifying them about risky activities

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

== OWASP ZSC Tool ==

'''Brief Explanation:'''

[[OWASP_ZSC_Tool_Project|OWASP ZSC]] is an open source software in python language which lets you generate customized shellcodes and convert scripts to an obfuscated script. This software can be run on Windows/Linux/OSX under python.

'''Expected Results:'''

Please take a look of our TODO list in Github to get some ideas:
https://github.com/Ali-Razmjoo/OWASP-ZSC/issues

Another ideas:
* Help us develop shellcode module for windows
* Develop shellcode module for OSX

Read about the project here:
https://ali-razmjoo.gitbooks.io/owasp-zsc/content/

Recommended reading:
http://www.vividmachines.com/shellcode/shellcode.html

'''Knowledge Prerequisites:'''
* Python
* Basic knowledge about Shellcode and assembly language

'''Mentors:'''
*Christo and Timo Goosen and Brian Beaudry- OWASP ZSC Contributors

Contact us through our mailing list for questions:
https://groups.google.com/d/forum/owasp-zsc

GSOC2016 Ideas

2016-02-19T06:30:20Z

John Melton: adding appsensor proposals

=OWASP Project Requests=

'''Tips to get you started in no particular order:'''
* Read the [[GSoC SAT]]
* Check the Hackademic wiki page linked above
* Contact us through the mailing list or irc channel.
* Check our [https://github.com/Hackademic/hackademic github repository] and especially the [https://github.com/Hackademic/hackademic/issues open tickets]

== OWASP Hackademic Challenges ==

[[OWASP Hackademic Challenges Project]] helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. After a wonderfull 2014 GSoC with 100 new challenges and a couple of new plugins we're mainly looking to get new features in and maybe a couple of challenges. Bellow is a list of proposed features.

=== REST API for the sandbox ===

'''Brief Explanation:'''

During the last summer code sprint Hackademic got challenge sandboxing in the form of vagrant and docker wrappers as well as an engine to start and stop the container or vm instances.
What is needed now is a rest api which supports endpoint authentication and authorization which enables the sandbox engine to be completely independed from the rest of the project.

Ideas on the project:
Since the sandbox is written in python, you can use microframeworks such as flask to implement the api.
The endpoint authorization can be done via certificates or plain signature or username/password type authentication.
However the communication between the two has to be over a secure channel.

'''Expected Results:'''
* A REST style api which allows an authenticated remote entity control the sandbox engine.
* PEP8 compliant code
* Acceptable unit test coverage

'''Knowledge Prerequisites:'''

Python, test driven developmen, some idea what REST is, some security knowledge would be preferable.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== New CMS ===

'''Brief Explanation:'''

The CMS part of the project is really old and has accumulated a significant amount of technical debt.
In addition many design decisions are either outdated or could be improved.
Therefore it may be a good idea to leverage the power of modern web frameworks to create a new CMS.
The new cms can be written in php or python using any compoennts we agree are necesary and based on the framework we agree on.

'''Expected Results:'''
* New cms with same functionality as the old one (3 types of users -- student, teacher, admin--, 3 types of resources -- article challenge, class--, ACL type permissions, CRUD operations on every resource/user, all functionality can be extended by Plugins.
* REST endpoints in addition to classic ones
* tests covering all routes implemented
* PSR/PEP 8 code

''' Note: '''
This is a huge project, it is ok if the student implements a part of it. However whatever implemented must be up to spec.
If you decide to take on this project contact us and we can agree on a list of routes.
If you don't decide to take on this project contact us.
Generally contact us, we like it when students have insightful questions and the community is active

'''Knowledge Prerequisites:'''
Python or PHP, the framework suggested, what REST is, the technologies used, some security knowledge would be nice.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== First Course Type Challenge ===

'''Brief Explanation:'''
We have a wonderful sandbox engine which allows for complex guided challenges to be implemented.
We'd like to build a challenge that guides the user through a series of steps to an end goal and teaches more information on the subject matter on the way.
This is a very open-ended project on purpose to allow creative student to come up with nice ideas.
Bellow you will find some examples that we thought might be interesting.

Ideas on the project:
* Purposefully vulnerable web page that guides the user via javascript tooltips and hints to exploiting it using ZAP. ( Bonus: using ZAP via the ZAP api). The challenge is solved when the the student submits the contents of a text file located on the disk (obtained by exploited an RCE)

* Reversing a provided binary to extract information by providing step by step instructions to reversing using any popular reversing tool (well, you can't use IDA so gdb should have to do). Challenge is solved when the keys are extracted from the binary and submitted. Bonus points if each binary donwloaded has different keys.

* Guide to exploiting the TOP10. (Using ZAP?)

* Defensive Type challenges -- Here's how to create a patch for this kind of vulnerability -- Challenge is solved when the unit tests are run and the vulnerability isn't there.

'''Expected Results:'''

* One or more Course - style challenges provided either as a docker container or as a vagrant box.
* Concrete documentation on how to build a challenge like this.

'''Knowledge Prerequisites:'''
The technologies used.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Advanced Sandboxed Challenges ===

'''Brief Explanation:'''

In the spirit of the challenges above, we're looking for true ctf type challenges.
This is an open ended task. We're expecting awesome fresh ideas.

Ideas on the project:
* An application vulnerable to one or more TOP 10 elements.
* A logic flaws based ctf
* Your idea here

'''Expected Results:'''
Docker containers or Vagrant boxes that contain complete new challenges.

'''Knowledge Prerequisites:'''
Knowledge of the technologies used

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Your idea ===

'''Brief Explanation:'''

Amazing students, in our experience the best, most creative and unique ideas show up when we let students suggest their own feature in relation to the project.
The above should give you a general idea where we're going but don't let them constrain you.
Do you wanna do something that would fit into Hackademic? Send us an email!

Ideas on the project:
No idea, that's your turn to shine!

'''Expected Results:'''
If it's code, code according to our coding standards.
If it's challenges, something new and interesting.
If it's something else, then written like the person who's going to maintain your code is a raging psychopath with an axe who knows where you live.

In short we'd like some quality. ;-)

'''Knowledge Prerequisites:'''

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

== OWASP OWTF ==

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - JavaScript Library Sniper Improvements ===

'''Brief explanation:'''
This is a project that tries to resolve a very common problem during penetration tests:

The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.

To solve this problem, we propose a *standalone* *tool* that can:

1) Be run BOTH from inside AND outside of OWTF

2) Build and *update* a fingerprint JavaScript library database of:
* Library File hashes => JavaScript Library version
* Library File lengths => JavaScript Library version
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)

3) Build and *update* a vulnerability database of:
* JavaScript Library version => CVE - CVSS score - Vulnerability info

4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
* JavaScript Library version
* List of vulnerabilities sorted in descending CVSS score order

5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
* ALL Library/vulnerability matches described on 4)

Once the standalone tool is built and verified to be working, OWTF should be able to:

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):

1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-

2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)

Potential projects worth having a look for potential overlap/inspiration:
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]

How many JavaScript libraries should be included?
* As many as possible, but especially the major ones: jQuery, knockout, etc.
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-

Common JavaScript library fingerprinting techniques include:
* Parse the JavaScript file and grab the version from there
* Determine the JavaScript version based on a hash of the file
* Determine the JavaScript version based on the length of the file

Other Challenges:
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
* When the JavaScript file does not match a specific version:
1) The commit that matches the closest should (ideally) be found
2) The NEXT library version after that commit (if present) should be found
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Installation Improvements and Package manager ===

'''Brief explanation:'''

This project is to implement what was suggested in the following github issue:
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]

Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
Having a private server with:
* pre-installed files for VMs
* pre-configured and patched tools
* Merged Lists
* Pre-configured certificates
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
Additional ideas are welcome.

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes
* For high speed connections (Downloading the files uncompressed)
* For low speed connections (Downloading the files compressed)
and the installation crashed because i runned out of space in the vm
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== 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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Tool utilities module ===

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

''' OWASP Mentors '''

== OWASP ZAP ==

We are in the process of deciding the set of ZAP projects for Google Summer of Code 2015.

You can follow (and join in) the discussions on the ZAP Developer Group: https://groups.google.com/d/msg/zaproxy-develop/Uy0JPkzsI_s/Bj7OTSkISCIJ

=== Example Idea ===

Currently ZAP provides only a limited set of report data. While this can be extended dynamically this feature is not currently used, and there is no way for users to choose what data they get back. It also provides a set of API calls, some of which return data that could be incorporated into reports, and some of which allow the fixed report to be accessed.

==== Expected Results ====

* Report data will be a distinct type of data returned via API calls
* An add-on that provides report data - so this becomes 'plug-able'
* Report data and meta data should be fully internationalized
* Users can specify which sites / contexts report data should apply to

==== 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.

==== Mentors ====
Simon Bennetts

== OWASP AppSensor ==

[[OWASP AppSensor Project]] provides real-time application layer intrusion detection.

* Check the AppSensor wiki page linked above
* Contact us through the mailing list.
* Check our [https://github.com/jtmelton/appsensor github repository] and the [https://github.com/jtmelton/appsensor/issues open tickets]
* Also see our [http://www.appsensor.org appsensor website]

=== Dashboard UI Expansion ===

'''Brief Explanation:'''

AppSensor provides a solid base of functionality to applications, and we currently have a minimal application for data display. This project will involve expanding the default/standard UI for the AppSensor project. As part of the project, you will learn about the domain model, iterating your mockup designs and share those with the project leader(s) and the community for feedback. The existing stack is based on spring boot and reactjs. There are lots of features to be added, and you'll work with the project leader(s) and the community to build the most-needed and requested capabilities.

'''Expected Results:'''

The existing dashboard application will be expanded and will involve features like:
* Search (could involve significant back-end work to configure indexing, etc.)
* Policy Management (edit server configuration in real-time)
* Data visualization / dashboarding

Source code, tests, and associated documentation for both the back-end and UI will be delivered for this effort.

'''Knowledge Prerequisites:'''

Comfortable with UI design and development, particularly building dashboards. Comfortable with Java (with some assistance). Basic familiarity with security concepts related to intrusion detection and prevention as this is the domain.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Trend Monitoring Analysis Engine ===

'''Brief Explanation:'''

AppSensor currently supports a basic policy-driven analysis engine to determine if a series of events represents an attack (if a user triggers 5 of this type of event in 10 minutes, it's an attack). While this supports many use cases, there are times when it would be helpful to know trending information. If a particular function of the application begins to see 10 times its normal amount of traffic, that might represent an attack. This project would add an additional analysis engine to support "trend monitoring". Development of this feature would require some initial research on alternative implementation strategies, followed by the development and testing of the feature in AppSensor.

'''Expected Results:'''

The project should produce:
* A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
* Associated configuration mechanism to specify the trending rules/policy
* A small full sample demo application showing usage of the trend monitoring feature

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Expand language support for clients ===

'''Brief Explanation:'''

AppSensor supports various modes for communication with the server. The language and framework of the client application are required only to support the given mode. This flexibility is desirable, but having pre-built clients in various languages is useful for our user-base. This project would involve working with various popular languages and frameworks to build support for communicating with the appsensor server backend.

'''Expected Results:'''

The project should produce:
* Clients in multiple popular languages for interaction with appsensor server
* At a minimum, coverage for the HTTP/REST mode should be supported. Other modes (thrift, soap, kafka, etc.) will be produced as time allows.
* Several small demo applications showing usage of the given APIs

Source code and tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable working in multiple popular languages and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Implement Detection Points in Reverse Proxy ===

'''Brief Explanation:'''

AppSensor works by tracking events that are created by "detection points", essentially locations in the processing pipeline where suspicious or malicious intent is observed. This often requires business-specific detection within the application. However, the project has defined a number of detection points (https://www.owasp.org/index.php/AppSensor_DetectionPoints) and responses (https://www.owasp.org/index.php/AppSensor_ResponseActions), some of which can be generically applied across a broader set of applications, including those that are common to an entire organization or even cross-organization. For that reason, a sub-project has been created (https://github.com/jtmelton/appsensor-reverse-proxy) that provides support for detection points and responses that are generic enough to be broadly applicable. This project would expand support for these detection points and responses.

'''Expected Results:'''

The project should produce:
* New detection points and responses
* Documentation for how to deploy the project and any end-user considerations
* Load testing each function as this project front-ends applications, and traffic throughput characteristics are important to our user-base.
* A small sample demo application showing the utility of the proxy. A recording of the usage for community viewing would be beneficial.

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in golang and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

== OWASP Seraphimdroid [[OWASP_SeraphimDroid_Project| ]] ==

=== Behavioral malware and intrusion analysis ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is an Android mobile app which already has a capability to statically analyze malware using machine learning (weka toolkit) relying on permissions. However, this is usually not enough and we intend to improve this with behavioral analysis. There are a number of paper in scientific literature describing how to detect malware and intrusions by dynamically analyzing its behavior (system calls, battery consumption, etc.). The idea of this project is to find the best approach that can be implemented on the device and implement it.

'''Expected Results:'''

* Reviewing scientific literature and find feasible approach we can take
* Implement and possibly improve the approach in Seraphimdroid
* Test the model and provide controls to switch algorithm on or off and possibly fine tune it
* Documenting approach as a technical report

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML
* Basic knowledge and interest in machine learning

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Framework for plugin development ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app, however, it lacks some components community can provide. We would like to provide community the way to develop plugins that can add features to OWASP Seraphimdroid app. However, the way of integrating external components into Android app may be challenge. The way of presenting GUI and integration between processes need to be examined and developed.

'''Expected Results:'''

* Examining the way of integrating third party apps through some provided API to OWASP Seraphimdroid
* Providing GUI integration with third party components
* Develop at least one test plugin
* Document the development process and API

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== Educational component ===

'''Brief Explanation:'''

[[OWASP_SeraphimDroid_Project|OWASP Seraphimdroid]] is well rounded security and privacy app. The initial idea of the project was to provide educational platform for common users, where by using the application, users can learn about risks for their privacy and security. Some components already has some sort of explanation, which is educational. However, it lacks of uneatable knowledge source and some of the components that monitor user's behavior do not provide sufficient information. Idea of this project is to develop monitoring of user activity and an component that can warn user about risks if he does something risky. Also, mobile security knowledge base that can be updated remotely will be a huge new asset to the application.

'''Expected Results:'''

* Develop uneatable knowledge base and GUI for it
* Develop web server where the knowledge base can be updated
* Improve current educational reporting
* Develop methodology for monitoring users and notifying them about risky activities

'''Knowledge Prerequisites:'''
* Java
* Android
* CSV, XML

'''Mentors:'''
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

== OWASP ZSC Tool ==

'''Brief Explanation:'''

[[OWASP_ZSC_Tool_Project|OWASP ZSC]] is an open source software in python language which lets you generate customized shellcodes and convert scripts to an obfuscated script. This software can be run on Windows/Linux/OSX under python.

'''Expected Results:'''

Please take a look of our TODO list in Github to get some ideas:
https://github.com/Ali-Razmjoo/OWASP-ZSC/issues

Another ideas:
* Help us develop shellcode module for windows
* Develop shellcode module for OSX

Read about the project here:
https://ali-razmjoo.gitbooks.io/owasp-zsc/content/

Recommended reading:
http://www.vividmachines.com/shellcode/shellcode.html

'''Knowledge Prerequisites:'''
* Python
* Basic knowledge about Shellcode and assembly language

'''Mentors:'''
*Christo and Timo Goosen and Brian Beaudry- OWASP ZSC Contributors

Contact us through our mailing list for questions:
https://groups.google.com/d/forum/owasp-zsc

OWASP AppSensor Project

2016-02-18T15:51:31Z

John Melton: /* Road Map and Getting Involved */

=Main=

<div style="width:100%;height:120px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-header.jpg|link=]]</div>
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers a comprehensive guide and a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]

[https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf 12-page US Letter booklet]

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [25 Sep 2015] [http://appsecusa2015.sched.org/event/09495faf5cced352cb4a2acc16ce9158#.VaOSoHhfk2w Presentation] at AppSec USA 2015
* [27 Jul 2015] [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc AppSensor Guide v2.0.2] published
* [09 Jun 2015] AppSensor Code v2.1.0 [https://github.com/jtmelton/appsensor/releases/tag/v2.1.0 released]
* [20 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Code
* [19 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Documentation
* [09 Apr 2015] [https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf CISO Briefing] booklet published
* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-22290600.html AppSensor Guide] and [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html CISO Briefing] can be purchased at cost as print on demand books.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Juan C Calderon
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*Sumanth Damaria
*August Detlefsen
*Ryan Dewhurst
*Sean Fay

| width="200" align="left" valign="top" |

*Timo Goosen
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton
*Mark Miller
* Rich Mogull
*Craig Munson

| width="200" align="left" valign="top" |

*Louis Nadeau
*Giri Nambari
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Raphael Taban
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Stephen de Vries
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

==OWASP Code Sprint 2015==
Development work was also supported by the [https://www.owasp.org/index.php/Summer_Code_Sprint2015 OWASP Summer Code Sprint 2015].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten.
v2.0.0 final was released in late January 2015.
v2.1.0 final was released in June 2015.
v2.2.0 final was released in September 2015

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== June 2015 (2.1) ===
* <strike>Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)</strike> ([https://github.com/jtmelton/appsensor/issues/19 github issue]) -> DONE
* <strike>Sample application / demo</strike> ([https://github.com/jtmelton/appsensor/issues/9 github issue]) -> DONE
* <strike>Finish up developer documentation on github and appsensor.org</strike> ([https://github.com/jtmelton/appsensor/issues/12 github issue]) -> DONE
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]] - Update - OWASP not selected

=== September 2015 (2.2) ===
* <strike>First version of administration UI for appsensor (monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])</strike> -> DONE

=== January 2016 (2.3) ===
* <strike>Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])</strike> -> DONE
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations

=== May 2016 (2.4) ===
* Trend monitoring implementation ([https://github.com/jtmelton/appsensor/issues/6 github issue])
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''September 2015''' Final release v2.2.0 code

'''June 2015''' Final release v2.1.0 code

'''April 2015''' CISO Briefing booklet published

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | [[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]
|}

The CISO briefing is also available to [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html buy at cost in print].

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:SAMM-EH-3]] [[Category:SAMM-SA-2]] [[Category:SAMM-VM-3]]

Summer Code Sprint2015 Progress Reports

2015-08-03T19:51:31Z

John Melton: sumanth damarla week 3 appsensor

=Main=

== OWASP Summer Code Sprint 2015 Progress Reports ==

This page will track the progress reports of the different selected projects for the OWASP Summer Code Sprint 2015 projects.

= OWTF - Viyat Bhalodia =

= OWTF - Arun Sori =

= OWTF - Alexandra Sandulescu =

= Hackademic - Anirudh Anand =

= Hackademic - Minhaz AV =

= Hackademic - Tapasweni Pathak =

= AppSensor - Sumanth Damarla =

== Week 1 (2015.07.13 - 2015.07.17) ==

Operating System:
Ubuntu 15.04 Desktop
Processor: Intel Core i3 -3227U CPU @ 1.90GHz x 4
OS Type : 64-bit
Disk: 17.5GB
(Server or Desktop?) + (What hardware?)

Technologies researched on :
Overview of Time Series Databases.
Influxdb documentation.
Learnt InfluxQL (Query language for Influxdb).
Overview Elasticsearch and related tutorials.
Overview Logstash and related tutorials.
Overview Kibana and related tutorials.

Environement Setup:
Installed ElasticSearch 1.4.4, Logstash and Kibana 4.0 and Nginx environment.(To set up a reverse proxy to allow external access) individually. What versions of each component?
Working on linking all the three[how the logstash output be given to elasticsearch (the parameters to be mentioned) and how to generate metrics using Kibana from Elasticsearch inputs] but I need to configure it with private IP.(Linking all three what? )
Installed Appsensor environment.

Links I referenced (Teaching Resources):

InfluxDB Documentation: https://influxdb.com/docs/v0.9/introduction/overview.html

Logstash Documentation: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html

Elastic Search Documentation: https://www.elastic.co/guide/en/elasticsearch/guide/current/getting-started.html

Kibana: https://www.elastic.co/webinars/whats-new-in-kibana-4

Visualizing Logs Using ElasticSearch, Logstash and Kibana : https://www.youtube.com/watch?v=Kqs7UcCJquM
Logs & Metrics: Use the Force, Gain the Insight (Need to have pro access which I have xD )
https://teamtreehouse.com/library/logs-metrics-use-the-force-gain-the-insight

Step by step installation on ELK Stack on Ubuntu: https://www.digitalocean.com/community/tutorials/how-to-install-elasticsearch-logstash-and-kibana-4-on-ubuntu-14-04

== Week 2 (2015.07.20 - 2015.07.24) ==

Configured Simple Websocket Dashboard from Appsensor and deployed in Tomcat 7:

Steps to Install Tomcat7 in Ubuntu 15.04:
https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-7-on-ubuntu-14-04-via-apt-get

Building AppSensor Environment:
AppSensor is a multi-module maven project. The project requires Java version 7 or higher. Building is generally handled by the following steps

clone the repo (or your fork)
git clone https://github.com/jtmelton/appsensor.git

get into appsensor directory
cd appsensor

install multi-module parent - one time requirement per version
mvn -N install
or
sudo apt-get update
sudo apt-get install maven

run the tests - done every time you make changes
mvn test

Deploying Sample App in Standalone Container:
If you'd like to deploy one of these applications to a standalone application server or servlet container, follow these simple steps:
Download the source code (either zip download or git clone)
Go into the folder containing the application you want to deploy (e.g. 'simple-dashboard')
Execute 'mvn package'
Look in the 'target' folder that gets generated and find the '.war' file
Deploy this WAR file into your application server / servlet container and start it up
You should now be able to interact with the application locally

Deploying Sample App in IDE-managed Container:
If you'd like to deploy one of these applications to a standalone application server or servlet container, follow these simple steps:
Download the source code (either zip download or git clone)
Import the application into your IDE (using 'import maven project' mechanism)
Setup an IDE managed container if you don't have one already
Add the application to your container
Startup the container
You should now be able to interact with the application locally

Providing syslog as input for Logstash:
Syslog and its configuration options: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-syslog.html

ELK STACK has been configured

Ports used for ELK Stack:
Port 9200: Elasticsearch
Port 5610: Kibana

Plugins Installed:
Marvel: Used as GUI for Elasticsearch.
Kopf: Used as GUI for Logstash.

Sample Logs used in ELK Stack:
Manual logs are inserted from terminal.

Ingesting CSV data with Logstash and analysing in Kibana.

Current Tasks:
Researching on syslog format.
Working on importing syslog format logs into Logstash.
Learning the filters supported for syslog in ELK stack technology.

Tasks ahead:
Extracting logs (syslog format) from the applications configured with AppSensor.

Reference Links:
Centralized logging with an
ELK stack (Elasticsearch-Logstash-Kibana) on Ubuntu: https://deviantony.wordpress.com/2014/05/19/centralized-logging-with-an-elk-stack-elasticsearch-logback-kibana/
About Marvel Plugin: https://www.elastic.co/guide/en/marvel/current/index.html
About Kopf Plugin: https://github.com/lmenezes/elasticsearch-kopf
Ingesting CSV Data with Logstash: http://www.rittmanmead.com/2015/04/using-the-elk-stack-to-analyse-donors-choose-data/
Download free CSV datasheets: http://data.donorschoose.org/open-data/overview/

== Week 3 (2015.07.27 - 2015.07.31) ==

Parsed syslog with the help of “Grok” and “syslog-pri” filters.
Built sample dashboards for Appsensor logs.
Working on kv{} filter

Building Custom Dashboards using Kibana:
Follow this guide: http://blog.trifork.com/2014/05/20/advanced-kibana-dashboard/

Successfully running “simple-websocket-dashboard” but working on executing “DemoDataPopulator.java”.

Reference Links:
About Grok Filter: https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html
About Syslog_pri Filter: https://www.elastic.co/guide/en/logstash/current/plugins-filters-syslog_pri.html
About KV{} Filter: https://www.elastic.co/guide/en/logstash/current/plugins-filters-kv.html

== Week 4 ==

== Week 5 ==

== Week 6 ==

== Week 7 ==

= Seraphimdroid - Kartik Kohli =

__NOTOC__ <headertabs />

==Week one==

The student fixed bug regarding locking of application on Android 5+.

==Week two==

No activity. Student also said that he was home, so thats the reason of his slow progress, but that he will catch up from monday.

Summer Code Sprint2015 Progress Reports

2015-07-28T17:56:31Z

John Melton:

=Main=

== OWASP Summer Code Sprint 2015 Progress Reports ==

This page will track the progress reports of the different selected projects for the OWASP Summer Code Sprint 2015 projects.

= OWTF - Viyat Bhalodia =

= OWTF - Arun Sori =

= OWTF - Alexandra Sandulescu =

= Hackademic - Anirudh Anand =

= Hackademic - Minhaz AV =

= Hackademic - Tapasweni Pathak =

= AppSensor - Sumanth Damarla =

== Week 1 (2015.07.13 - 2015.07.17) ==

Operating System:
Ubuntu 15.04 Desktop
Processor: Intel Core i3 -3227U CPU @ 1.90GHz x 4
OS Type : 64-bit
Disk: 17.5GB
(Server or Desktop?) + (What hardware?)

Technologies researched on :
Overview of Time Series Databases.
Influxdb documentation.
Learnt InfluxQL (Query language for Influxdb).
Overview Elasticsearch and related tutorials.
Overview Logstash and related tutorials.
Overview Kibana and related tutorials.

Environement Setup:
Installed ElasticSearch 1.4.4, Logstash and Kibana 4.0 and Nginx environment.(To set up a reverse proxy to allow external access) individually. What versions of each component?
Working on linking all the three[how the logstash output be given to elasticsearch (the parameters to be mentioned) and how to generate metrics using Kibana from Elasticsearch inputs] but I need to configure it with private IP.(Linking all three what? )
Installed Appsensor environment.

Links I referenced (Teaching Resources):

InfluxDB Documentation: https://influxdb.com/docs/v0.9/introduction/overview.html

Logstash Documentation: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html

Elastic Search Documentation: https://www.elastic.co/guide/en/elasticsearch/guide/current/getting-started.html

Kibana: https://www.elastic.co/webinars/whats-new-in-kibana-4

Visualizing Logs Using ElasticSearch, Logstash and Kibana : https://www.youtube.com/watch?v=Kqs7UcCJquM
Logs & Metrics: Use the Force, Gain the Insight (Need to have pro access which I have xD )
https://teamtreehouse.com/library/logs-metrics-use-the-force-gain-the-insight

Step by step installation on ELK Stack on Ubuntu: https://www.digitalocean.com/community/tutorials/how-to-install-elasticsearch-logstash-and-kibana-4-on-ubuntu-14-04

== Week 2 (2015.07.20 - 2015.07.24) ==

Configured Simple Websocket Dashboard from Appsensor and deployed in Tomcat 7:

Steps to Install Tomcat7 in Ubuntu 15.04:
https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-7-on-ubuntu-14-04-via-apt-get

Building AppSensor Environment:
AppSensor is a multi-module maven project. The project requires Java version 7 or higher. Building is generally handled by the following steps

clone the repo (or your fork)
git clone https://github.com/jtmelton/appsensor.git

get into appsensor directory
cd appsensor

install multi-module parent - one time requirement per version
mvn -N install
or
sudo apt-get update
sudo apt-get install maven

run the tests - done every time you make changes
mvn test

Deploying Sample App in Standalone Container:
If you'd like to deploy one of these applications to a standalone application server or servlet container, follow these simple steps:
Download the source code (either zip download or git clone)
Go into the folder containing the application you want to deploy (e.g. 'simple-dashboard')
Execute 'mvn package'
Look in the 'target' folder that gets generated and find the '.war' file
Deploy this WAR file into your application server / servlet container and start it up
You should now be able to interact with the application locally

Deploying Sample App in IDE-managed Container:
If you'd like to deploy one of these applications to a standalone application server or servlet container, follow these simple steps:
Download the source code (either zip download or git clone)
Import the application into your IDE (using 'import maven project' mechanism)
Setup an IDE managed container if you don't have one already
Add the application to your container
Startup the container
You should now be able to interact with the application locally

Providing syslog as input for Logstash:
Syslog and its configuration options: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-syslog.html

ELK STACK has been configured

Ports used for ELK Stack:
Port 9200: Elasticsearch
Port 5610: Kibana

Plugins Installed:
Marvel: Used as GUI for Elasticsearch.
Kopf: Used as GUI for Logstash.

Sample Logs used in ELK Stack:
Manual logs are inserted from terminal.

Ingesting CSV data with Logstash and analysing in Kibana.

Current Tasks:
Researching on syslog format.
Working on importing syslog format logs into Logstash.
Learning the filters supported for syslog in ELK stack technology.

Tasks ahead:
Extracting logs (syslog format) from the applications configured with AppSensor.

Reference Links:
Centralized logging with an
ELK stack (Elasticsearch-Logstash-Kibana) on Ubuntu: https://deviantony.wordpress.com/2014/05/19/centralized-logging-with-an-elk-stack-elasticsearch-logback-kibana/
About Marvel Plugin: https://www.elastic.co/guide/en/marvel/current/index.html
About Kopf Plugin: https://github.com/lmenezes/elasticsearch-kopf
Ingesting CSV Data with Logstash: http://www.rittmanmead.com/2015/04/using-the-elk-stack-to-analyse-donors-choose-data/
Download free CSV datasheets: http://data.donorschoose.org/open-data/overview/

== Week 3 ==

== Week 4 ==

== Week 5 ==

== Week 6 ==

== Week 7 ==

= Seraphimdroid - Kartik Kohli =

__NOTOC__ <headertabs />

==Week one==

The student fixed bug regarding locking of application on Android 5+.

==Week two==

No activity. Student also said that he was home, so thats the reason of his slow progress, but that he will catch up from monday.

Summer Code Sprint2015 Progress Reports

2015-07-28T17:55:45Z

John Melton: adding appsensor week 2 report

=Main=

== OWASP Summer Code Sprint 2015 Progress Reports ==

This page will track the progress reports of the different selected projects for the OWASP Summer Code Sprint 2015 projects.

= OWTF - Viyat Bhalodia =

= OWTF - Arun Sori =

= OWTF - Alexandra Sandulescu =

= Hackademic - Anirudh Anand =

= Hackademic - Minhaz AV =

= Hackademic - Tapasweni Pathak =

= AppSensor - Sumanth Damarla =

== Week 1 (2015.07.13 - 2015.07.17) ==

Operating System:
Ubuntu 15.04 Desktop
Processor: Intel Core i3 -3227U CPU @ 1.90GHz x 4
OS Type : 64-bit
Disk: 17.5GB
(Server or Desktop?) + (What hardware?)

Technologies researched on :
Overview of Time Series Databases.
Influxdb documentation.
Learnt InfluxQL (Query language for Influxdb).
Overview Elasticsearch and related tutorials.
Overview Logstash and related tutorials.
Overview Kibana and related tutorials.

Environement Setup:
Installed ElasticSearch 1.4.4, Logstash and Kibana 4.0 and Nginx environment.(To set up a reverse proxy to allow external access) individually. What versions of each component?
Working on linking all the three[how the logstash output be given to elasticsearch (the parameters to be mentioned) and how to generate metrics using Kibana from Elasticsearch inputs] but I need to configure it with private IP.(Linking all three what? )
Installed Appsensor environment.

Links I referenced (Teaching Resources):

InfluxDB Documentation: https://influxdb.com/docs/v0.9/introduction/overview.html

Logstash Documentation: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html

Elastic Search Documentation: https://www.elastic.co/guide/en/elasticsearch/guide/current/getting-started.html

Kibana: https://www.elastic.co/webinars/whats-new-in-kibana-4

Visualizing Logs Using ElasticSearch, Logstash and Kibana : https://www.youtube.com/watch?v=Kqs7UcCJquM
Logs & Metrics: Use the Force, Gain the Insight (Need to have pro access which I have xD )
https://teamtreehouse.com/library/logs-metrics-use-the-force-gain-the-insight

Step by step installation on ELK Stack on Ubuntu: https://www.digitalocean.com/community/tutorials/how-to-install-elasticsearch-logstash-and-kibana-4-on-ubuntu-14-04

== Week 2 ==

Configured Simple Websocket Dashboard from Appsensor and deployed in Tomcat 7:

Steps to Install Tomcat7 in Ubuntu 15.04:
https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-7-on-ubuntu-14-04-via-apt-get

Building AppSensor Environment:
AppSensor is a multi-module maven project. The project requires Java version 7 or higher. Building is generally handled by the following steps

clone the repo (or your fork)
git clone https://github.com/jtmelton/appsensor.git

get into appsensor directory
cd appsensor

install multi-module parent - one time requirement per version
mvn -N install
or
sudo apt-get update
sudo apt-get install maven

run the tests - done every time you make changes
mvn test

Deploying Sample App in Standalone Container:
If you'd like to deploy one of these applications to a standalone application server or servlet container, follow these simple steps:
Download the source code (either zip download or git clone)
Go into the folder containing the application you want to deploy (e.g. 'simple-dashboard')
Execute 'mvn package'
Look in the 'target' folder that gets generated and find the '.war' file
Deploy this WAR file into your application server / servlet container and start it up
You should now be able to interact with the application locally

Deploying Sample App in IDE-managed Container:
If you'd like to deploy one of these applications to a standalone application server or servlet container, follow these simple steps:
Download the source code (either zip download or git clone)
Import the application into your IDE (using 'import maven project' mechanism)
Setup an IDE managed container if you don't have one already
Add the application to your container
Startup the container
You should now be able to interact with the application locally

Providing syslog as input for Logstash:
Syslog and its configuration options: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-syslog.html

ELK STACK has been configured

Ports used for ELK Stack:
Port 9200: Elasticsearch
Port 5610: Kibana

Plugins Installed:
Marvel: Used as GUI for Elasticsearch.
Kopf: Used as GUI for Logstash.

Sample Logs used in ELK Stack:
Manual logs are inserted from terminal.

Ingesting CSV data with Logstash and analysing in Kibana.

Current Tasks:
Researching on syslog format.
Working on importing syslog format logs into Logstash.
Learning the filters supported for syslog in ELK stack technology.

Tasks ahead:
Extracting logs (syslog format) from the applications configured with AppSensor.

Reference Links:
Centralized logging with an
ELK stack (Elasticsearch-Logstash-Kibana) on Ubuntu: https://deviantony.wordpress.com/2014/05/19/centralized-logging-with-an-elk-stack-elasticsearch-logback-kibana/
About Marvel Plugin: https://www.elastic.co/guide/en/marvel/current/index.html
About Kopf Plugin: https://github.com/lmenezes/elasticsearch-kopf
Ingesting CSV Data with Logstash: http://www.rittmanmead.com/2015/04/using-the-elk-stack-to-analyse-donors-choose-data/
Download free CSV datasheets: http://data.donorschoose.org/open-data/overview/

== Week 3 ==

== Week 4 ==

== Week 5 ==

== Week 6 ==

== Week 7 ==

= Seraphimdroid - Kartik Kohli =

__NOTOC__ <headertabs />

==Week one==

The student fixed bug regarding locking of application on Android 5+.

==Week two==

No activity. Student also said that he was home, so thats the reason of his slow progress, but that he will catch up from monday.

Summer Code Sprint2015 Progress Reports

2015-07-20T17:19:07Z

John Melton:

Summer Code Sprint2015 Progress Reports

2015-07-20T17:18:32Z

John Melton: fixing typo

Summer Code Sprint2015

2015-07-20T17:08:43Z

John Melton: add link to progress report tracking.

[[File:Summer_of_Code_Sprint_2015.png|link=https://soundcloud.com/owasp-podcast/owasp-summerofcodesprint2015-final|Listen to the OWASP 24/7 Broadcast]]

== OWASP Summer Code Sprint 2015 ==

== Progress ==

Update: Track progress on the [[Summer_Code_Sprint2015_Progress_Reports]]

== Goal ==

The OWASP Summer Code Sprint 2015 is a program that aims to provide incentives to students to contribute to OWASP projects. By participating in the OWASP Summer Code Sprint a student can get real life experience while contributing to an open source project. A student that successfully completes the program will receive in total $1500.

== Program details ==

''Projects that are eligible:'' All code/tools projects. Documentation projects are excluded.

''Duration:'' 2 months of full-time engagement.

== How it works ==

Any code/tool project can participate in the OWASP Summer Code Sprint. Each project will be guided by an OWASP mentor. Students are evaluated in the middle and at the end of the coding period, based on success criteria identified at the beginning of the project. Successful students will receive $750 after each evaluation, a total of $1500 per student.

Projects are focused on developing security tools. It is required that the code any student produces for those projects will be released as Open Source.

Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.

== How you can participate ==

=== As a student: ===

1. Review the list of OWASP Projects currently participating in the OWASP Summer Code Sprint 2015.

2. Get in touch with the OWASP Project mentor of your choice.

3. Agree deliverables with OWASP mentor.

4. Work away during Summer 2015.

5. Rise to Open Source Development Glory :-)

ALL STUDENTS PLEASE APPLY HERE >> [http://goo.gl/forms/jUFTcXVDEY FORM]

=== As an OWASP Project Leader: ===

1. Edit this page adding your project and some proposed tasks as per the examples

2. Promote the initiative to your academic contacts

== Timeplan ==

'''Phase 1: Proposals'''

Project leaders who want to include their project to the program should submit some initial proposal ideas on this page. These ideas serve as guidance to the students; they are things that project leaders would like to get done, like new features, improvements, etc.

Subsequently students are invited to submit detailed proposals that can (but do not necessarily have to) be based on these ideas. Students are strongly encouraged to engage with project leaders and each project's community (e.g. through the project's mailing list) in order to discuss the details of their proposal. Proposals should provide details about the implementation, time plan, milestones, etc.

'''Phase 2: Scoring of proposals'''

After the submission of proposals, project leaders and contributors/mentors are required to review the submitted proposals and score them (on a 1 to 5 scale). Each proposal should receive at least 3 assessments/scores from different mentors. Each mentor, contributor or leader can score only proposals for their OWN project. All assessments should provide justification. Reviewers are strongly encouraged to provide constructive comments for students so that they can improve in the future.

Project leaders are responsible to attract a sufficient number of volunteer mentors to score proposals and subsequently supervise those that will get selected.

'''Phase 3: Slot allocation.'''

When proposal scoring has been completed, each project leader requests a specific number of slots. This number should be based on:
The number of truly outstanding proposals according to submitted scores.
The importance of the proposal to the project's roadmap.
The number of available mentors for the project. At least 2 mentors are needed for each proposal that gets accepted.
If the total number of requested slots is less than or equal to the available number of slots, then all projects get the requested slots. If not, the following rules apply:
All projects that have requested a slot get at least 1 slot, provided they have a high quality proposal and sufficient number of mentors.
Two mentors are required per slot allocated to the project.
The program's administrators get in touch with project leaders, especially those that have requested a large number of slots to receive additional feedback on the requested slots and explore any available possibilities for reducing the requested number of slots. A project leader might choose to donate one or more requested slots back to the pool so that other projects can get more slots. The program administrators can choose to initiate a public discussion between projects in need of more slots and projects that have requested a lot of slots in order to determine the best possible outcome for everyone.
If all else fails, slots are equally allocated to projects, i.e. all projects get 1 slot; projects that have requested 2 or more slots get an extra slot if available; projects that have requested 3 or more slots get an extra slot if available, etc. When there are no more slots available for all projects that have requested them a draw is used to allocate the remaining slots.

In any case, the program's administrators should perform a final review of the selected proposals to ensure that they are of high quality. If concerns arise they should request additional information from project leaders.

'''Phase 4: Coding.'''

This is the main phase of the program. Students implement their proposal according to the submitted timeplan and under the supervision
of their mentors.

== Evaluations ==

In the middle of the coding period, mentors should submit an evaluation of their students to ensure that they are on track and provide some feedback both to OWASP and the students.

If no/little progress has been made up to this point, the mentors could decide to fail the student in which case the student does not receive money. If successful, OWASP will pay half the amount ($750). The final evaluations are submitted at the end of the coding period and the second installment ($750) is paid to the student if all agreed deliverables are met. If the student has failed to demonstrate progress during the second period, then the second installment will not be paid and the student will get only half of the amount.

== Deadlines ==
Program announcement: June 19th, 2015

Deadline for Student Applications: July 3rd, 2015

Proposal Evaluations: from July 6th until July 10th.

Successful proposals announcement: July 10th, 2015

Coding Period Starts: July 13th, 2015

Mid-term evaluations: Submitted from August 3rd until August 7th.

Coding period ends: August 28th, 2015.

Final evaluations: Until September 4th, 2015.

== Mailing List ==
Please subscribe to the following mailing list to receive updates or ask any particular questions:

[https://groups.google.com/d/forum/owasp-summer-code-sprint OWASP Summer Code Sprint Mailing List]

== Ideas ==

=== OWASP Hackademic ===

=== Hackademic Docker Sandboxed for challenges ===

''' Brief explanation: '''
Background problem to solve:

We are trying to enable users to freely upload vulnerable applications to the platform.
After some research we concluded that writing a python application that uses docker to deploy challenges would be the best way to go about it.
Also, we need to provide a frontend to manage the deployed containers and integrate our existing analytics gathering system into the dockerized challenges.
The installer of the application should take care of initializing both the cms and the containers without introducing too much complexity.

Proposed solution:

There is an easy to use python library for docker and there should be a frontend managing the containers we can use off the self with minimal modifications.
The feature has already had a poc using linux containers, you can find it in the open merge requests of the project's github page.

''' Expected results '''
* Integrate dockerized challenges in the platform.
* PEP-8 compliant code in all provided python code
* PSR compliant code in all php provided code
* Sphinx/phpdoc friendly comments
* Excellent reliability
* Good performance
* Unit tests / Functional tests
* Good documentation

''' Prerequisites '''

Some knowledge of test driven development, php, python, docker

''' OWASP Mentors '''
Spyros Gasteratos (spyros.gasteratos@owasp.org)

=== Hackademic: Javascript Based Development Challenges ===

Brief explanation:
Background Problem to solve:

We are looking for challenges which are aimed towards secure coding.
The user should be served with a piece of vulnerable javascript which fails the unit tests provided.
The user has to fix the vulnerability in a way that makes the unit tests pass.

Example Solution of one of the challenges:
Provide the user with the following code:
''
function sayHi(string userInput){
var hiField = document.getElementById("hiField");
hiField.innerHtml = userInput;
}
''
Use any javascript unit - testing framework to design a set of unit tests which call the function with all sorts of payloads and test if the user seems to have escaped userInput correctly,
we're not looking for completeness a solid proof of concept implementation for future reference is acceptable.

''' Expected Results '''
A complete implementation of challenges covering the top 10 according to our coding standards.

=== Hackademic - Migrate old code to the new coding standards ===

'''Brief Explanation:'''

In the last project summit we decided to introduce code style and standards compliance checking for new commits and slowly migrate the old ones to the new setting.
We also decided to prefer contributions with unit tests.

So far we have a testing framework which allows us to setup and test things easily and thus makes writing new tests less painful, but the tests cover only a few files and we don't provide line coverage yet.
We want coverage reports and as much line coverage as possible.

We're looking for someone to assist in this migration.

''''What you will have to do:'''
* Introduce PSR-4 autoloading
* Migrate all the existing code into PSR-1, PSR-2 naming and code style
* Use tools like php_codeSniffer to automate the checks for standards compliance
* If necessary, automate the use of these tools with pre-commit hooks and create a "Check everything" script
* Add code coverage reports into the testing pipeline.
* Add the remaining tests.
* Write a travis.yml file to integrate the platform to travis ci.

''' Knowledge Prerequisites: '''
* Php and bash experience
* Writing unit and functional tests
* Familiarity with Git is a plus
* Familiar or willing and able to quickly learn concepts like autoloading, the psr standard, the sniff file syntax and travis

''' Mentor''': Spyros Gasteratos (spyros.gasteratos@owasp.org)

=== Hackademic: New Frontend ===

'''Brief Explanation'''

Our current theme is written using Smarty Templates and basic html/css.
It covers all of the platform's functionality but it's from 2012 and it needs both visual and usability improvements.

Your job will be to design and implement a new shiny theme using the latest in frontend technology.

'''Expected Results'''

* Come up with suggestions on which parts of the current frontend need usability improvements.
* Write the new smarty-based template using the css and javascript frameworks you thing necessary.
* Code must be consistent with javascript and css coding standards and style.

''' Knowledge Prerequisites '''

* Experience in Javascript, CSS + experience or willing and able to learn Frameworks such as bootstrap, foundation, semantic ui or Angular, jquery etc
* Experience in web design and implementation

=== OWASP OWTF ===

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - JavaScript Library Sniper Improvements ===

'''Brief explanation:'''
This is a project that tries to resolve a very common problem during penetration tests:

The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.

To solve this problem, we propose a *standalone* *tool* that can:

1) Be run BOTH from inside AND outside of OWTF

2) Build and *update* a fingerprint JavaScript library database of:
* Library File hashes => JavaScript Library version
* Library File lengths => JavaScript Library version
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)

3) Build and *update* a vulnerability database of:
* JavaScript Library version => CVE - CVSS score - Vulnerability info

4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
* JavaScript Library version
* List of vulnerabilities sorted in descending CVSS score order

5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
* ALL Library/vulnerability matches described on 4)

Once the standalone tool is built and verified to be working, OWTF should be able to:

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):

1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-

2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)

Potential projects worth having a look for potential overlap/inspiration:
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]

How many JavaScript libraries should be included?
* As many as possible, but especially the major ones: jQuery, knockout, etc.
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-

Common JavaScript library fingerprinting techniques include:
* Parse the JavaScript file and grab the version from there
* Determine the JavaScript version based on a hash of the file
* Determine the JavaScript version based on the length of the file

Other Challenges:
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
* When the JavaScript file does not match a specific version:
1) The commit that matches the closest should (ideally) be found
2) The NEXT library version after that commit (if present) should be found
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Installation Improvements and Package manager ===

'''Brief explanation:'''

This project is to implement what was suggested in the following github issue:
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]

Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
Having a private server with:
* pre-installed files for VMs
* pre-configured and patched tools
* Merged Lists
* Pre-configured certificates
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
Additional ideas are welcome.

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes
* For high speed connections (Downloading the files uncompressed)
* For low speed connections (Downloading the files compressed)
and the installation crashed because i runned out of space in the vm
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== 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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Tool utilities module ===

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

''' OWASP Mentors '''

=== OWASP ZAP ===
ZAP is an OWASP Flagship project and is currently the most active open source web security scanner.

There are a number of ZAP related projects students can work on, including:

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Bug tracker support ===

'''Brief explanation:'''

This would allow ZAP users to raise issues in bug trackers directly within ZAP.

This should be implemented as an extension with a generic framework and then adaptors for specific trackers, like github and bugzilla.

The info included in the issues raised should be as configurable as possible so that users can include whatever they want, and set things like custom fields.

'''Expected results:'''

A new ZAP add-on which would provide:
* A generic framework for raising ZAP issues in bug trackers controllable via the UI, API and configuration
* A full implementation for github issues
* Optionally additional support for other trackers such as bugzilla

'''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] - Field enumeration ===

'''Brief explanation:'''

This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped.

The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.

'''Expected results:'''

A new ZAP add-on which would allow the user to:
* Select a specific field within a form
* Define success and failure conditions
* Define default values for other fields
* Specify character sets and ranges
* Report all of the valid and/or invalid characters of for that field

'''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] - Form handling ===

'''Brief explanation:'''

The ZAP traditional and Ajax spiders explore an application by putting basic default values in all forms. These may often not be valid values, for example using "ZAP" when an email address is required.

The enhancement would allow the user to define default values based on pattern matching against the field names and/or ids.

It would also be very useful if it could show the user all forms and their associated fields for an application, and then allow the user to update the default values.

'''Expected results:'''

* New screens that allow the user to specify default values based on pattern matching against the field names and/or ids
* API support for configuring the default values
* The traditional and Ajax spiders changed to use those default values
* Optionally new screens which show all of the forms and their associated fields for an application

'''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] - Gauntlet integration ===

'''Brief explanation:'''

Gauntlt is a framework for controlling security tools for testing web apps.

It is increasingly being used in 'secdevops' and therefore providing a plugin which allows ZAP to be run would be very desirable.

'''Expected results:'''

A Gauntlt plugin that provides ZAP integration to support:
* Spidering an application
* Actively scanning an application
* Reporting the vulnerabilities found
* Optionally configuring context information, eg to support authentication

'''Knowledge Prerequisite:'''

Gauntlt is written in Ruby, 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] - Script console code completion ===

'''Brief explanation:'''

ZAP provides a very powerful scripting interface. Unfortunately to use it effectively is only really possible with a good knowledge of the ZAP internals. Adding code completion (eg using a project like https://github.com/bobbylight/AutoComplete) would significantly help users.

'''Expected results:'''

AutoComplete supported in the ZAP Script Console for:
* Javascript
* Jython
* 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] - Support java as a scripting language ===

'''Brief explanation:'''

It would be very useful to support Java in addition to the JSR223 scripting languages within the ZAP script console'

It should be possible to provide much better auto complete support than will be possible with dynamically typed scripting languages.

'''Expected results:'''

* The ability to run Java code in the ZAP Script Console to the same leval as other supported scripting languages
* Templates for all of the current script types
* Optionally auto complete supported

'''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] - Zest text representation and parser ===

'''Brief explanation:'''

Zest is a graphical scripting language from the Mozilla Security team, and is used as the ZAP macro language.

A standardized text representation and parser would be very useful and help its adoption.

'''Expected results:'''

* A fully documented and reviewed text representation for Zest
* The Java Zest runtime changed to generate the text representation for all statements
* A parser written in java that converts the text representation into Zest JSON
* Optionally parsers written in other languages

'''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/OWASP_AppSensor_Project OWASP AppSensor] Enterprise Integrations - Reporting ===

'''Brief Explanation:'''

This is a feature request that's been driven by the community. AppSensor provides great utility by allowing applications to defend themselves. AppSensor can/will also provide a UI (another possible GSOC project) to view and manage the information produced by the applications. However, larger organizations often already have a system in place for managing system security alerts. It would provide a lot of value if we can integrate with those systems and data formats. This project will involve a bit of up-front research, then primarily systems integration work.

'''Expected Results:'''

We want to support a number of integrations. Some that have been requested by our community are:
* SNMP
* SCOM
* syslog
* AppDynamics

Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)

=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Enterprise Integrations - Transport ===

'''Brief Explanation:'''

AppSensor currently supports a number of "execution modes", which are simply a reference to the transport protocol (REST, SOAP, thrift). There are a number of protocols that are popular in enterprises that we don't currently support, but could. This would simplify integration for many organizations who already use a set of approved communication protocols. This project would be primarily integration work and testing with a number of well-known systems integration / transport protocols and mechanisms.

'''Expected Results:'''

We want to support a number of integrations. Some that have been proposed are:
* ActiveMQ
* Avro
* Protobuf

Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing. Some familiarity with distributed systems in general and message brokers in particular would be helpful.

'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)

=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Dashboard UI ===

'''Brief Explanation:'''

AppSensor provides a solid base of functionality to applications, but does not currently do a good job of presenting the resulting data. We are attacking that issue on 2 fronts. We plan to create a custom UI (this project) as well as various integrations to standard tools/formats for reporting to existing display systems. This project will involve creating the default/standard UI for the AppSensor project. As part of the project, you will learn about the domain model, iterating your mockup designs and share those with the project leader(s) and the community for feedback. We don't have an existing product, so you will have lots of responsibility for the design and implementation, as well as significant input to the decision around the technology stack.

'''Expected Results:'''

A modern, usable UI will be built that will have at least the following features (though there are many more features to build) :
* Basic Dashboard UI (the UI for the OPS wall)
* Search
* Policy Management (edit server configuration)

Source code and associated tests for the UI will be created, along with the associated end user documentation for how to setup and configure the system.

'''Knowledge Prerequisites:'''

Comfortable with UI design and development, particularly building dashboards. Comfortable with Java (with some assistance). Basic familiarity with security concepts related to intrusion detection and prevention as this is the basic domain.

'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)

=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Trend Monitoring Analysis Engine ===

'''Brief Explanation:'''

AppSensor currently supports a basic policy-driven analysis engine to determine if a series of events represents an attack (if a user triggers 5 of this type of event in 10 minutes, it's an attack). While this supports many use cases, there are times when it would be helpful to know trending information. If a particular function of the application begins to see 10 times its normal amount of traffic, that might represent an attack. This project would add an additional analysis engine to support "trend monitoring". Development of this feature would require some initial research on alternative implementation strategies, followed by the development and testing of the feature in AppSensor.

'''Expected Results:'''

The project should produce:
* A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
* Associated configuration mechanism to specify the trending rules/policy
* A small full sample demo application showing usage of the trend monitoring feature

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP Seraphimdroid] - Open Seraphimdroid for external plugin development ===

'''Brief Explanation:'''

SeraphimDroid is an privacy protection and educational application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid scans your devices and teaches you about risks and threats coming from application permissions. In the last version SeraphimDroid evolved to application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge. Now we want to open the application for plugin development and improve some protection mechanisms.

'''Expected Results:'''

The project should produce:
* Application should be modified to a platform that will allow other developers to create android application and services as a plugins to OWASP Seraphimdroid, where the collected data on data leaks, security breaches and other things application are doing could be viewed through OWASP Seraphimdroid application.
* Create a plugin application that showcases how the plugin will work
* Create a documentation on how to create new plugin (guide)

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java, XML and android development.

'''Mentors:''' [[User:Nikola Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

=== [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP Seraphimdroid] - Settings checker and improving permission ranking algorithm ===

'''Brief Explanation:'''

SeraphimDroid is an privacy protection and educational application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid scans your devices and teaches you about risks and threats coming from application permissions. In the last version SeraphimDroid evolved to application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge. Now we want improve some protection mechanisms, like check for settings and improve the ranking of application by how dangerous their permissions are. We also look for new ideas on how to improve privacy and security of mobile device users.

'''Expected Results:'''

The project should produce:
* We are also looking for a new ideas how to evaluate the dangers coming from the permissions applications are requesting. Currently there is a simple algorithm that is labelling red, yellow and green apps, but in many cases red apps just request multiple permissions. We are looking for a solution that will somehow give a weight to permissions and based on it evaluate it more realistically.
* Create a settings check - check whether settings are set according to best practices (development options turned off, debugging off, etc.)
* Fix some bugs like fixing application locker on Lollipop, update and improve recieving SMS alarming, etc.
* Document the improvements
* Bonus: Create a widget

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java, XML and android development.

'''Mentors:''' [[User:Nikola Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader

Summer Code Sprint2015 Progress Reports

2015-07-20T16:41:40Z

John Melton: creating new summer code sprint 2015 progress reports page

Summer Code Sprint2015

2015-06-18T15:35:06Z

John Melton: adding appsensor

== OWASP Summer Code Sprint 2015 ==

== Goal ==

The OWASP Summer Code Sprint 2015 is a program that aims to provide incentives to students to contribute to OWASP projects. By participating in the OWASP Summer Code Sprint a student can get real life experience while contributing to an open source project. A student that successfully completes the program will receive in total $1500.

== Program details ==

''Projects that are eligible:'' All code/tools projects. Documentation projects are excluded.

''Duration:'' 2 months of full-time engagement.

== How it works ==

Any code/tool project can participate in the OWASP Summer Code Sprint. Each project will be guided by an OWASP mentor. Students are evaluated in the middle and at the end of the coding period, based on success criteria identified at the beginning of the project. Successful students will receive $750 after each evaluation, a total of $1500 per student.

Projects are focused on developing security tools. It is required that the code any student produces for those projects will be released as Open Source.

Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.

== How you can participate ==

=== As a student: ===

1. Review the list of OWASP Projects currently participating in the OWASP Summer Code Sprint 2015.

2. Get in touch with the OWASP Project mentor of your choice.

3. Agree deliverables with OWASP mentor.

4. Work away during Summer 2015.

5. Rise to Open Source Development Glory :-)

ALL STUDENTS PLEASE APPLY HERE >> [http://goo.gl/forms/jUFTcXVDEY FORM]

=== As an OWASP Project Leader: ===

1. Edit this page adding your project and some proposed tasks as per the examples

2. Promote the initiative to your academic contacts

== Timeplan ==

'''Phase 1: Proposals'''

Project leaders who want to include their project to the program should submit some initial proposal ideas on this page. These ideas serve as guidance to the students; they are things that project leaders would like to get done, like new features, improvements, etc.

Subsequently students are invited to submit detailed proposals that can (but do not necessarily have to) be based on these ideas. Students are strongly encouraged to engage with project leaders and each project's community (e.g. through the project's mailing list) in order to discuss the details of their proposal. Proposals should provide details about the implementation, time plan, milestones, etc.

'''Phase 2: Scoring of proposals'''

After the submission of proposals, project leaders and contributors/mentors are required to review the submitted proposals and score them (on a 1 to 5 scale). Each proposal should receive at least 3 assessments/scores from different mentors. Each mentor, contributor or leader can score only proposals for their OWN project. All assessments should provide justification. Reviewers are strongly encouraged to provide constructive comments for students so that they can improve in the future.

Project leaders are responsible to attract a sufficient number of volunteer mentors to score proposals and subsequently supervise those that will get selected.

'''Phase 3: Slot allocation.'''

When proposal scoring has been completed, each project leader requests a specific number of slots. This number should be based on:
The number of truly outstanding proposals according to submitted scores.
The importance of the proposal to the project's roadmap.
The number of available mentors for the project. At least 2 mentors are needed for each proposal that gets accepted.
If the total number of requested slots is less than or equal to the available number of slots, then all projects get the requested slots. If not, the following rules apply:
All projects that have requested a slot get at least 1 slot, provided they have a high quality proposal and sufficient number of mentors.
Two mentors are required per slot allocated to the project.
The program's administrators get in touch with project leaders, especially those that have requested a large number of slots to receive additional feedback on the requested slots and explore any available possibilities for reducing the requested number of slots. A project leader might choose to donate one or more requested slots back to the pool so that other projects can get more slots. The program administrators can choose to initiate a public discussion between projects in need of more slots and projects that have requested a lot of slots in order to determine the best possible outcome for everyone.
If all else fails, slots are equally allocated to projects, i.e. all projects get 1 slot; projects that have requested 2 or more slots get an extra slot if available; projects that have requested 3 or more slots get an extra slot if available, etc. When there are no more slots available for all projects that have requested them a draw is used to allocate the remaining slots.

In any case, the program's administrators should perform a final review of the selected proposals to ensure that they are of high quality. If concerns arise they should request additional information from project leaders.

'''Phase 4: Coding.'''

This is the main phase of the program. Students implement their proposal according to the submitted timeplan and under the supervision
of their mentors.

== Evaluations ==

In the middle of the coding period, mentors should submit an evaluation of their students to ensure that they are on track and provide some feedback both to OWASP and the students.

If no/little progress has been made up to this point, the mentors could decide to fail the student in which case the student does not receive money. If successful, OWASP will pay half the amount ($750). The final evaluations are submitted at the end of the coding period and the second installment ($750) is paid to the student if all agreed deliverables are met. If the student has failed to demonstrate progress during the second period, then the second installment will not be paid and the student will get only half of the amount.

== Deadlines ==
Program announcement: June 19th, 2015

Deadline for Student Applications: July 3rd, 2015

Proposal Evaluations: from July 6th until July 10th.

Successful proposals announcement: July 10th, 2015

Coding Period Starts: July 13th, 2015

Mid-term evaluations: Submitted from August 3rd until August 7th.

Coding period ends: August 28th, 2015.

Final evaluations: Until September 4th, 2015.

== Mailing List ==
Please subscribe to the following mailing list to receive updates or ask any particular questions:

[https://groups.google.com/d/forum/owasp-summer-code-sprint OWASP Summer Code Sprint Mailing List]

== Ideas ==

=== OWASP Hackademic ===

=== Hackademic Docker Sandboxed for challenges ===

''' Brief explanation: '''
Background problem to solve:

We are trying to enable users to freely upload vulnerable applications to the platform.
After some research we concluded that writing a python application that uses docker to deploy challenges would be the best way to go about it.
Also, we need to provide a frontend to manage the deployed containers and integrate our existing analytics gathering system into the dockerized challenges.
The installer of the application should take care of initializing both the cms and the containers without introducing too much complexity.

Proposed solution:

There is an easy to use python library for docker and there should be a frontend managing the containers we can use off the self with minimal modifications.
The feature has already had a poc using linux containers, you can find it in the open merge requests of the project's github page.

''' Expected results '''
* Integrate dockerized challenges in the platform.
* PEP-8 compliant code in all provided python code
* PSR compliant code in all php provided code
* Sphinx/phpdoc friendly comments
* Excellent reliability
* Good performance
* Unit tests / Functional tests
* Good documentation

''' Prerequisites '''

Some knowledge of test driven development, php, python, docker

''' OWASP Mentors '''
Spyros Gasteratos (spyros.gasteratos@owasp.org)

=== Hackademic: Javascript Based Development Challenges ===

Brief explanation:
Background Problem to solve:

We are looking for challenges which are aimed towards secure coding.
The user should be served with a piece of vulnerable javascript which fails the unit tests provided.
The user has to fix the vulnerability in a way that makes the unit tests pass.

Example Solution of one of the challenges:
Provide the user with the following code:
''
function sayHi(string userInput){
var hiField = document.getElementById("hiField");
hiField.innerHtml = userInput;
}
''
Use any javascript unit - testing framework to design a set of unit tests which call the function with all sorts of payloads and test if the user seems to have escaped userInput correctly,
we're not looking for completeness a solid proof of concept implementation for future reference is acceptable.

''' Expected Results '''
A complete implementation of challenges covering the top 10 according to our coding standards.

=== Hackademic - Migrate old code to the new coding standards ===

'''Brief Explanation:'''

In the last project summit we decided to introduce code style and standards compliance checking for new commits and slowly migrate the old ones to the new setting.
We also decided to prefer contributions with unit tests.

So far we have a testing framework which allows us to setup and test things easily and thus makes writing new tests less painful, but the tests cover only a few files and we don't provide line coverage yet.
We want coverage reports and as much line coverage as possible.

We're looking for someone to assist in this migration.

''''What you will have to do:'''
* Introduce PSR-4 autoloading
* Migrate all the existing code into PSR-1, PSR-2 naming and code style
* Use tools like php_codeSniffer to automate the checks for standards compliance
* If necessary, automate the use of these tools with pre-commit hooks and create a "Check everything" script
* Add code coverage reports into the testing pipeline.
* Add the remaining tests.
* Write a travis.yml file to integrate the platform to travis ci.

''' Knowledge Prerequisites: '''
* Php and bash experience
* Writing unit and functional tests
* Familiarity with Git is a plus
* Familiar or willing and able to quickly learn concepts like autoloading, the psr standard, the sniff file syntax and travis

''' Mentor''': Spyros Gasteratos (spyros.gasteratos@owasp.org)

=== Hackademic: New Frontend ===

'''Brief Explanation'''

Our current theme is written using Smarty Templates and basic html/css.
It covers all of the platform's functionality but it's from 2012 and it needs both visual and usability improvements.

Your job will be to design and implement a new shiny theme using the latest in frontend technology.

'''Expected Results'''

* Come up with suggestions on which parts of the current frontend need usability improvements.
* Write the new smarty-based template using the css and javascript frameworks you thing necessary.
* Code must be consistent with javascript and css coding standards and style.

''' Knowledge Prerequisites '''

* Experience in Javascript, CSS + experience or willing and able to learn Frameworks such as bootstrap, foundation, semantic ui or Angular, jquery etc
* Experience in web design and implementation

=== OWASP OWTF ===

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - JavaScript Library Sniper Improvements ===

'''Brief explanation:'''
This is a project that tries to resolve a very common problem during penetration tests:

The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.

To solve this problem, we propose a *standalone* *tool* that can:

1) Be run BOTH from inside AND outside of OWTF

2) Build and *update* a fingerprint JavaScript library database of:
* Library File hashes => JavaScript Library version
* Library File lengths => JavaScript Library version
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)

3) Build and *update* a vulnerability database of:
* JavaScript Library version => CVE - CVSS score - Vulnerability info

4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
* JavaScript Library version
* List of vulnerabilities sorted in descending CVSS score order

5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
* ALL Library/vulnerability matches described on 4)

Once the standalone tool is built and verified to be working, OWTF should be able to:

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):

1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-

2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)

Potential projects worth having a look for potential overlap/inspiration:
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]

How many JavaScript libraries should be included?
* As many as possible, but especially the major ones: jQuery, knockout, etc.
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-

Common JavaScript library fingerprinting techniques include:
* Parse the JavaScript file and grab the version from there
* Determine the JavaScript version based on a hash of the file
* Determine the JavaScript version based on the length of the file

Other Challenges:
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
* When the JavaScript file does not match a specific version:
1) The commit that matches the closest should (ideally) be found
2) The NEXT library version after that commit (if present) should be found
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Installation Improvements and Package manager ===

'''Brief explanation:'''

This project is to implement what was suggested in the following github issue:
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]

Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
Having a private server with:
* pre-installed files for VMs
* pre-configured and patched tools
* Merged Lists
* Pre-configured certificates
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
Additional ideas are welcome.

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes
* For high speed connections (Downloading the files uncompressed)
* For low speed connections (Downloading the files compressed)
and the installation crashed because i runned out of space in the vm
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== 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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

=== OWASP OWTF - Tool utilities module ===

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

''' OWASP Mentors '''

=== OWASP ZAP ===
ZAP is an OWASP Flagship project and is currently the most active open source web security scanner.

There are a number of ZAP related projects students can work on, including:

=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Bug tracker support ===

'''Brief explanation:'''

This would allow ZAP users to raise issues in bug trackers directly within ZAP.

This should be implemented as an extension with a generic framework and then adaptors for specific trackers, like github and bugzilla.

The info included in the issues raised should be as configurable as possible so that users can include whatever they want, and set things like custom fields.

'''Expected results:'''

A new ZAP add-on which would provide:
* A generic framework for raising ZAP issues in bug trackers controllable via the UI, API and configuration
* A full implementation for github issues
* Optionally additional support for other trackers such as bugzilla

'''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] - Field enumeration ===

'''Brief explanation:'''

This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped.

The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.

'''Expected results:'''

A new ZAP add-on which would allow the user to:
* Select a specific field within a form
* Define success and failure conditions
* Define default values for other fields
* Specify character sets and ranges
* Report all of the valid and/or invalid characters of for that field

'''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] - Form handling ===

'''Brief explanation:'''

The ZAP traditional and Ajax spiders explore an application by putting basic default values in all forms. These may often not be valid values, for example using "ZAP" when an email address is required.

The enhancement would allow the user to define default values based on pattern matching against the field names and/or ids.

It would also be very useful if it could show the user all forms and their associated fields for an application, and then allow the user to update the default values.

'''Expected results:'''

* New screens that allow the user to specify default values based on pattern matching against the field names and/or ids
* API support for configuring the default values
* The traditional and Ajax spiders changed to use those default values
* Optionally new screens which show all of the forms and their associated fields for an application

'''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] - Gauntlet integration ===

'''Brief explanation:'''

Gauntlt is a framework for controlling security tools for testing web apps.

It is increasingly being used in 'secdevops' and therefore providing a plugin which allows ZAP to be run would be very desirable.

'''Expected results:'''

A Gauntlt plugin that provides ZAP integration to support:
* Spidering an application
* Actively scanning an application
* Reporting the vulnerabilities found
* Optionally configuring context information, eg to support authentication

'''Knowledge Prerequisite:'''

Gauntlt is written in Ruby, 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] - Script console code completion ===

'''Brief explanation:'''

ZAP provides a very powerful scripting interface. Unfortunately to use it effectively is only really possible with a good knowledge of the ZAP internals. Adding code completion (eg using a project like https://github.com/bobbylight/AutoComplete) would significantly help users.

'''Expected results:'''

AutoComplete supported in the ZAP Script Console for:
* Javascript
* Jython
* 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] - Support java as a scripting language ===

'''Brief explanation:'''

It would be very useful to support Java in addition to the JSR223 scripting languages within the ZAP script console'

It should be possible to provide much better auto complete support than will be possible with dynamically typed scripting languages.

'''Expected results:'''

* The ability to run Java code in the ZAP Script Console to the same leval as other supported scripting languages
* Templates for all of the current script types
* Optionally auto complete supported

'''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] - Zest text representation and parser ===

'''Brief explanation:'''

Zest is a graphical scripting language from the Mozilla Security team, and is used as the ZAP macro language.

A standardized text representation and parser would be very useful and help its adoption.

'''Expected results:'''

* A fully documented and reviewed text representation for Zest
* The Java Zest runtime changed to generate the text representation for all statements
* A parser written in java that converts the text representation into Zest JSON
* Optionally parsers written in other languages

'''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/OWASP_AppSensor_Project OWASP AppSensor] Enterprise Integrations - Reporting ===

'''Brief Explanation:'''

This is a feature request that's been driven by the community. AppSensor provides great utility by allowing applications to defend themselves. AppSensor can/will also provide a UI (another possible GSOC project) to view and manage the information produced by the applications. However, larger organizations often already have a system in place for managing system security alerts. It would provide a lot of value if we can integrate with those systems and data formats. This project will involve a bit of up-front research, then primarily systems integration work.

'''Expected Results:'''

We want to support a number of integrations. Some that have been requested by our community are:
* SNMP
* SCOM
* syslog
* AppDynamics

Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)

=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Enterprise Integrations - Transport ===

'''Brief Explanation:'''

AppSensor currently supports a number of "execution modes", which are simply a reference to the transport protocol (REST, SOAP, thrift). There are a number of protocols that are popular in enterprises that we don't currently support, but could. This would simplify integration for many organizations who already use a set of approved communication protocols. This project would be primarily integration work and testing with a number of well-known systems integration / transport protocols and mechanisms.

'''Expected Results:'''

We want to support a number of integrations. Some that have been proposed are:
* ActiveMQ
* Avro
* Protobuf

Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing. Some familiarity with distributed systems in general and message brokers in particular would be helpful.

'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)

=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Dashboard UI ===

'''Brief Explanation:'''

AppSensor provides a solid base of functionality to applications, but does not currently do a good job of presenting the resulting data. We are attacking that issue on 2 fronts. We plan to create a custom UI (this project) as well as various integrations to standard tools/formats for reporting to existing display systems. This project will involve creating the default/standard UI for the AppSensor project. As part of the project, you will learn about the domain model, iterating your mockup designs and share those with the project leader(s) and the community for feedback. We don't have an existing product, so you will have lots of responsibility for the design and implementation, as well as significant input to the decision around the technology stack.

'''Expected Results:'''

A modern, usable UI will be built that will have at least the following features (though there are many more features to build) :
* Basic Dashboard UI (the UI for the OPS wall)
* Search
* Policy Management (edit server configuration)

Source code and associated tests for the UI will be created, along with the associated end user documentation for how to setup and configure the system.

'''Knowledge Prerequisites:'''

Comfortable with UI design and development, particularly building dashboards. Comfortable with Java (with some assistance). Basic familiarity with security concepts related to intrusion detection and prevention as this is the basic domain.

'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)

=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Trend Monitoring Analysis Engine ===

'''Brief Explanation:'''

AppSensor currently supports a basic policy-driven analysis engine to determine if a series of events represents an attack (if a user triggers 5 of this type of event in 10 minutes, it's an attack). While this supports many use cases, there are times when it would be helpful to know trending information. If a particular function of the application begins to see 10 times its normal amount of traffic, that might represent an attack. This project would add an additional analysis engine to support "trend monitoring". Development of this feature would require some initial research on alternative implementation strategies, followed by the development and testing of the feature in AppSensor.

'''Expected Results:'''

The project should produce:
* A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
* Associated configuration mechanism to specify the trending rules/policy
* A small full sample demo application showing usage of the trend monitoring feature

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

OWASP AppSensor Project

2015-06-09T15:49:08Z

John Melton: /* Past activities */

=Main=

<div style="width:100%;height:120px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-header.jpg|link=]]</div>
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]

[https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf 12-page US Letter booklet]

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [9 June 2015] AppSensor Code v2.1.0 [https://github.com/jtmelton/appsensor/releases/tag/v2.1.0 released]
* [20 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Code
* [19 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Documentation
* [09 Apr 2015] [https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf CISO Briefing] booklet published
* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html AppSensor Guide] and [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html CISO Briefing] can be purchased at cost as a print on demand books.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Juan C Calderon
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Sean Fay
*Timo Goosen
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Mark Miller
*Craig Munson
*Louis Nadeau
*Giri Nambari
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Raphael Taban
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten.
v2.0.0 final was released in late January 2015.
v2.1.0 final was released in June 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== June 2015 (2.1) ===
* <strike>Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)</strike> ([https://github.com/jtmelton/appsensor/issues/19 github issue]) -> DONE
* <strike>Sample application / demo</strike> ([https://github.com/jtmelton/appsensor/issues/9 github issue]) -> DONE
* <strike>Finish up developer documentation on github and appsensor.org</strike> ([https://github.com/jtmelton/appsensor/issues/12 github issue]) -> DONE
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]] - Update - OWASP not selected

=== September 2015 (2.2) ===
* First version of administration UI for appsensor (monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])

=== January 2016 (2.3) ===
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations

=== May 2016 (2.4) ===
* Trend monitoring implementation ([https://github.com/jtmelton/appsensor/issues/6 github issue])
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''June 2015''' Final release v2.1.0 code

'''April 2015''' CISO Briefing booklet published

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | [[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]
|}

The CISO briefing is also available to [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html buy at cost in print].

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:SAMM-EH-3]] [[Category:SAMM-SA-2]]

OWASP AppSensor Project

2015-06-09T15:48:24Z

John Melton: /* v2 Code */

=Main=

<div style="width:100%;height:120px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-header.jpg|link=]]</div>
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]

[https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf 12-page US Letter booklet]

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [9 June 2015] AppSensor Code v2.1.0 [https://github.com/jtmelton/appsensor/releases/tag/v2.1.0 released]
* [20 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Code
* [19 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Documentation
* [09 Apr 2015] [https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf CISO Briefing] booklet published
* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html AppSensor Guide] and [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html CISO Briefing] can be purchased at cost as a print on demand books.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Juan C Calderon
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Sean Fay
*Timo Goosen
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Mark Miller
*Craig Munson
*Louis Nadeau
*Giri Nambari
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Raphael Taban
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten.
v2.0.0 final was released in late January 2015.
v2.1.0 final was released in June 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== June 2015 (2.1) ===
* <strike>Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)</strike> ([https://github.com/jtmelton/appsensor/issues/19 github issue]) -> DONE
* <strike>Sample application / demo</strike> ([https://github.com/jtmelton/appsensor/issues/9 github issue]) -> DONE
* <strike>Finish up developer documentation on github and appsensor.org</strike> ([https://github.com/jtmelton/appsensor/issues/12 github issue]) -> DONE
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]] - Update - OWASP not selected

=== September 2015 (2.2) ===
* First version of administration UI for appsensor (monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])

=== January 2016 (2.3) ===
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations

=== May 2016 (2.4) ===
* Trend monitoring implementation ([https://github.com/jtmelton/appsensor/issues/6 github issue])
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''April 2015''' CISO Briefing booklet published

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | [[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]
|}

The CISO briefing is also available to [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html buy at cost in print].

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:SAMM-EH-3]] [[Category:SAMM-SA-2]]

OWASP AppSensor Project

2015-06-09T15:47:15Z

John Melton: /* News and Events */

=Main=

<div style="width:100%;height:120px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-header.jpg|link=]]</div>
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]

[https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf 12-page US Letter booklet]

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [9 June 2015] AppSensor Code v2.1.0 [https://github.com/jtmelton/appsensor/releases/tag/v2.1.0 released]
* [20 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Code
* [19 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Documentation
* [09 Apr 2015] [https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf CISO Briefing] booklet published
* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html AppSensor Guide] and [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html CISO Briefing] can be purchased at cost as a print on demand books.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Juan C Calderon
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Sean Fay
*Timo Goosen
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Mark Miller
*Craig Munson
*Louis Nadeau
*Giri Nambari
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Raphael Taban
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 final was released in late January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== June 2015 (2.1) ===
* <strike>Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)</strike> ([https://github.com/jtmelton/appsensor/issues/19 github issue]) -> DONE
* <strike>Sample application / demo</strike> ([https://github.com/jtmelton/appsensor/issues/9 github issue]) -> DONE
* <strike>Finish up developer documentation on github and appsensor.org</strike> ([https://github.com/jtmelton/appsensor/issues/12 github issue]) -> DONE
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]] - Update - OWASP not selected

=== September 2015 (2.2) ===
* First version of administration UI for appsensor (monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])

=== January 2016 (2.3) ===
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations

=== May 2016 (2.4) ===
* Trend monitoring implementation ([https://github.com/jtmelton/appsensor/issues/6 github issue])
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''April 2015''' CISO Briefing booklet published

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | [[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]
|}

The CISO briefing is also available to [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html buy at cost in print].

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:SAMM-EH-3]] [[Category:SAMM-SA-2]]

Projects/OWASP AppSensor Project/Releases/AppSensor 0.1.3

2015-06-09T15:45:04Z

John Melton:

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP AppSensor Project
| project_home_page = OWASP AppSensor Project

| release_name = AppSensor v2
| release_date = June 2015 (code / final, v2.1) & May 2014 (doc / final)
| release_description =
| release_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''' for documentation] & [http://opensource.org/licenses/MIT '''MIT License''' for Tools].
| release_download_link = https://github.com/jtmelton/appsensor

| leader_name1 = Michael Coates
| leader_email1 = michael.coates@owasp.org
| leader_username1 = MichaelCoates

| leader_name[2-10] =
| leader_email[2-10] =
| leader_username[2-10] =

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes = https://github.com/jtmelton/appsensor

| links_url1 = http://www.brighttalk.com/webcast/20680
| links_name1 = Automated Application Defenses to Thwart Advanced Attackers

| links_url2 = https://www.owasp.org/index.php/File:Appsensor-pid.pdf
| links_name2 = Diagram

| links_url3 = http://www.youtube.com/watch?v=8ItfuwvLxRk
| links_name3 = Live Demo

| links_url4 = https://github.com/jtmelton/appsensor
| links_name4 = AppSensor Code

}}

OWASP AppSensor Project

2015-05-26T04:45:29Z

John Melton: updating roadmap dates - concentrating on admin UI for v2.2

=Main=

<div style="width:100%;height:120px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-header.jpg|link=]]</div>
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]

[https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf 12-page US Letter booklet]

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [20 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Code
* [19 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Documentation
* [09 Apr 2015] [https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf CISO Briefing] booklet published
* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html AppSensor Guide] and [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html CISO Briefing] can be purchased at cost as a print on demand books.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Juan C Calderon
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Sean Fay
*Timo Goosen
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Mark Miller
*Craig Munson
*Louis Nadeau
*Giri Nambari
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Raphael Taban
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 final was released in late January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== June 2015 (2.1) ===
* <strike>Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)</strike> ([https://github.com/jtmelton/appsensor/issues/19 github issue]) -> DONE
* <strike>Sample application / demo</strike> ([https://github.com/jtmelton/appsensor/issues/9 github issue]) -> DONE
* <strike>Finish up developer documentation on github and appsensor.org</strike> ([https://github.com/jtmelton/appsensor/issues/12 github issue]) -> DONE
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]] - Update - OWASP not selected

=== September 2015 (2.2) ===
* First version of administration UI for appsensor (monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])

=== January 2016 (2.3) ===
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations

=== May 2016 (2.4) ===
* Trend monitoring implementation ([https://github.com/jtmelton/appsensor/issues/6 github issue])
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''April 2015''' CISO Briefing booklet published

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | [[File:Appsensor-cisobriefing-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor-ciso-briefing.pdf]]
|}

The CISO briefing is also available to [http://www.lulu.com/shop/owasp-foundation/appsensor-ciso-briefing/paperback/product-22121723.html buy at cost in print].

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:SAMM-EH-3]] [[Category:SAMM-SA-2]]

OWASP AppSensor Project

2015-03-26T03:29:24Z

John Melton: small updates to milestones to mark 1 done, remove GSOC (not selected), and remove another that was a duplicate.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [20 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Code
* [19 May 2015] Working session at [http://2015.appsec.eu/project-summit/ OWASP Project Summit] - Documentation
* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Louis Nadeau
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 final was released in late January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== May 2015 (2.1) ===
* First version of administration UI for appsensor (monitoring UI) ([https://github.com/jtmelton/appsensor/issues/5 github issue])
* <strike>Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)</strike> ([https://github.com/jtmelton/appsensor/issues/19 github issue]) -> DONE
* Sample application / demo ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]] - Update - OWASP not selected

=== September 2015 (2.2) ===
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Extend reporting APIs / UI (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations

=== January 2016 (2.3) ===
* Trend monitoring implementation
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | Coming soon!
|}

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2015-02-27T03:17:04Z

John Melton: Updating milestone for some issues - to help groupings make more sense. Also updating based on feedback from users on mailing list of what issues are most important to them.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

[https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Two-sided US Letter or A4]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [22 Feb 2015] Proposal for [https://www.owasp.org/index.php/GSoC2015_Ideas#OWASP_AppSensor Google Summer of Code 2015]
* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Louis Nadeau
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 final was released in late January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== May 2015 (2.1) ===
* First version of administration UI for appsensor (monitoring UI) ([https://github.com/jtmelton/appsensor/issues/5 github issue])
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something) ([https://github.com/jtmelton/appsensor/issues/19 github issue])
* Workup example integration with ModSecurity CRS ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]]

=== September 2015 (2.2) ===
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Extend reporting APIs / UI (github issues [https://github.com/jtmelton/appsensor/issues/10 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Sample applications - simple implementations of the different execution modes
* Video demo of setting up appsensor (screen capture) (related to sample apps)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations
* GSOC 2015 mentoring (if selected)

=== January 2016 (2.3) ===
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | Coming soon!
|}

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

==Source Documents / Artwork==

* Guide
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc Word (content only)], DOC 11Mb
** [https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Word, images, Lulu covers, diagrams], ZIP 96Mb
* Introduction for Developers
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-a4.zip A4 Illustrator and PDF exports], ZIP 19Mb
** [https://www.owasp.org/index.php/File:Appsensor-intro-for-developers-usletter.zip US letter Illustrator and PDF exports], ZIP 19Mb
* Poster
** [https://www.owasp.org/index.php/File:Owasp-appsensor-poster-a1.zip A1 Illustrator and PDF export] ZIP, 18Mb

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2015-02-22T05:31:18Z

John Melton: Moved GSOC prep up to 2.1 and marked it as complete

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== Intro for Developers ==

[[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]

Flyer sheet [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf 2-sided-US Letter]

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [13 Feb 2015] [https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf Introduction for Developers] flyer published
* [13 Feb 2015] AppSensor project awarded OWASP flagship status
* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" rowspan="2" width="50%" | [[File:Mature projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Benjamin-Hugo LeBlanc
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Louis Nadeau
*Erlend Oftedal
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas ([http://lists.owasp.org/pipermail/owasp-appsensor-project/2015-February/000855.html see discussion and editable list of changes])
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 final was released in late January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== May 2015 (2.1) ===
* First version of administration UI for appsensor (reporting / monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/5 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Extend reporting APIs (github issues [[https://github.com/jtmelton/appsensor/issues/10 github issue])
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* Video demo of setting up appsensor (screen capture)
* <strike>Preparation for GSOC 2015 submission</strike> -> DONE - see [[GSoC2015_Ideas]]

=== September 2015 (2.2) ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations
* GSOC 2015 mentoring (if selected)

=== January 2016 (2.3) ===
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''February 2015''' Introduction for Developers flyer published

'''January 2015''' Final release v2.0.0 code

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== Introductory Briefings ==

{|
| align="center" valign="top" | Developers
|
| align="center" valign="top" | Architects
|
| align="center" valign="top" | CISOs
|-
| width="200" align="left" valign="top" | [[File:Appsensor-developer-small.jpg|link=https://www.owasp.org/index.php/File:Appsensor_intro_for_developers.pdf]]
| width="20" |
| width="200" align="left" valign="top" | [[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]
| width="20" |
| width="200" align="center" valign="top" | Coming soon!
|}

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

GSoC2015 Ideas

2015-02-22T05:05:53Z

John Melton: Adding AppSensor Projects

=OWASP Project Requests=

== OWASP Hackademic Challenges ==

[[OWASP Hackademic Challenges Project]] helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. After a wonderfull 2014 GSoC with 100 new challenges and a couple of new plugins we're mainly looking to get new features in and maybe a couple of challenges. Bellow is a list of proposed features.

'''Tips to get you started in no particular order:'''
* Read the [[GSoC SAT]]
* Check the Hackademic wiki page linked above
* Contact us through the mailing list or irc channel.
* Check our [https://github.com/Hackademic/hackademic github repository] and especially the [https://github.com/Hackademic/hackademic/issues open tickets]

=== Web Sandbox ===

'''Brief Explanation:'''

After a very successfull OWASP Winter Code Sprint we have a brand new Sandbox feature which uses Linux Containers to create virtual space for each user. So we can host properly vulnerable challenges and maybe execute some code server side. However, the sandbox is not fully complete, we need many features here and there to make it easily deployable and improve it's administration.

Ideas on the project:

* Simple sandbox administration frontend for the web. -- An admin console to start and kill sandboxes manually and to list the status and resources used by each one.
* Secure the implementation -- Now we have a functioning prototype, we know that Linux Containers are quite safe but we haven't explicitly tested our configuration and use of them.
* Your idea here...

'''Expected Results:'''

Better sandboxing

'''Knowledge Prerequisites:'''

Comfortable in Linux administration and some security knowledge depending on the specific project.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Source Code testing environment - Defensive Challenges ===

'''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. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Student performance analytics ===

'''Brief Explanation:'''

We need a better way to measure the student's performance and how it varies depending on the problem. You will write a plugin (or make changes to the core depending on your implementation proposal) to gather all sorts of performance data and present them in a meaningfull way.

'''Expected Results:'''

A page to view performance metrics of differenct students.
( Hackalytics )

'''Knowledge Prerequisites:'''

Comfortable in PHP, HTML, javascript. Some understanding of analytics.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== New Template ===

'''Brief Explanation:'''

We need a cool new template since the old one is getting pretty old.
You can do it using the latest frontend bells and whistles (like angular,bootstrap or the tools of your choice).

'''Expected Results:'''

A new template.

'''Knowledge Prerequisites:'''

Comfortable in Css, HTML, javascript and/or the tools you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Gamification ===

'''Brief Explanation:'''

Gamification is a feature widely used in many learning platforms out there and it would be nice if we could have it too.
You will need to design and implement the awards, badges and whatever other feature you have in mind. You will also implement the front and backend changes necessary to present the results.

'''Expected Results:'''

Gamification of the platform. ( Hackademicification )

'''Knowledge Prerequisites:'''

Comfortable in Css, HTML, javascript and/or the tools you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

=== Your idea ===

'''Brief Explanation:'''

Hackademic is it's community, we always welcome new ideas and cool features. Come over to the irc channel or mailing list and propose something.
We'd be happy to help you get it done.

'''Expected Results:'''

Features we didn't know we needed. ;-)

'''Knowledge Prerequisites:'''

Comfortable in whatever tools and languages you plan on using.

'''Mentors:''' Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

== OWASP WebGoat .NET - Vulnerable Website ==

'''Brief Explanation:'''

The actual WebGoat .NET is a vulnerable website built in ASP.NET using C#. There are some challenges already built in but we would like to add more vulnerable features
https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET#tab=Overview

'''Expected Results:'''

We want to add more modules such as
*WebSockets
*CSRF challenge
*Finalise testing an upgrade to the .NET framework 4.5
*Retest and clean up actual modules

'''Knowledge Prerequisites:'''

Comfortable in .NET, HTML and C#. Good understanding of Application Security, source code analysis and related vulnerabilities.

'''Mentors:''' Johanna Curiel, Jerry Hoff - OWASP WebGoat 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 first version is ready, it needs thorough testing and delivery. It also needs new challenges added and a CTF hosted on it.

'''Knowledge prerequisite:''' You just need to know PHP and SQL. Familiarity with web application security is recommended.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

==OWASP PureCaptcha==
===OWASP PureCaptcha===
'''Description:'''
[[OWASP PureCaptcha]] is an OWASP project aiming to simplify CAPTCHA usage. Instead of proving rigorous APIs and many dependencies, it is a single source code file (library) that does not depend on anything and generates secure and fast CAPTCHAs, with little memory and processor footprint.
PureCaptcha is currently released for PHP. The candidate will port this to several other programming languages (priority on web languages) and provide full test coverage.

'''Expected Results:''' PureCaptcha library for at least 3 new programming languages. Unit testing for the core version. A study on security of the generated captcha can also be performed.

'''Knowledge prerequisites:''' Any programming language you want to port into, as well as PHP.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Jesse Burns

==OWASP PHP Framework==
===OWASP PHP Framework===

'''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.
The project has been done in the last two years, and now a framework has been built upon these libraries and security best practices. The framework intends to merge security practices with practical frameworks, and aims to be simple and lightweight.

'''Expected Results: ''' A secure yet robust and practical framework for PHP developers.

'''Knowledge prerequisite:''' This project requires at least one year of experience working with different PHP projects and frameworks. It will be too hard for someone with average PHP experience.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary

'''Skill Level:''' Advanced

==OWASP RBAC Project==
===OWASP RBAC Project===
'''Description:''' ''For the last 7 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 RBAC project]] has already implemented this, has a wide audience and has released several minor and two major versions. Many new features and modifications are expected by the community behind this.

'''Expected Results:''' OWASP RBAC project more mature by porting from PHP to other programming languages, OR adding new features and testing on the PHP version.

'''Knowledge prerequisite:''' Good SQL knowledge, library development skills, familiarity with one of the programming languages as well as PHP. We recommend average experience and high skills.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]], Rahul Chaudhary, Jesse Burns

'''Skill Level:''' Advanced

For more info, visit [http://phprbac.net phprbac.net]

==OWASP PHP Widgets==
===OWASP PHP Widgets===
'''Description:''' Pull MVC (widget-based web views) has been available for many years on all major web programming languages, and even for Javascript. PHP on the other hand, lacks these and suffers a lot from forcing push MVC on its developers. There are a few libraries around, not secure and not mature at all. Providing a robust set of widgets for PHP developers not only smoothes web development process, it automatically mitigates a lot of web attacks that are based on user inputs to forms and other web elements (e.g CSRF, SQL Injection, XSS).

'''Expected Results:''' OWASP PHP Widgets is currently in beta, and the candidate will spend time testing the functionalities, providing test coverage, adding new widgets and features, and building a user community.

'''Knowledge prerequisite:''' Average PHP programming. Good experience with web applications.

'''Mentor:''' [[User:Abbas Naderi|Abbas Naderi]]

==OWASP Seraphimdroid==

'''Description:''' SeraphimDroid is educational application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid scans your devices and teaches you about risks and threats coming from application permissions. Also this project will deliver paper on android permissions, their regular use, risks and malicious use. In second version SeraphimDroid will evolve to application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge.

'''Expected Results:''' After last year's GSoC first version of project was released on Google play. However, educational component, setting check, potential android widgets are still missing and would be beneficial. Also, malicious behavior prevention mechanisms should be added and some bugs should be fixed.

'''Knowledge prerequisite:''' Average Android and JAVA programming. Knowledge of XML and SQLite Good experience with mobile applications.

'''Mentor:''' [[User:Nikola Milosevic|Nikola Milosevic]]

== OWASP OWTF ==

=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===

'''Brief explanation:'''

Background problem to solve:

We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf

VMS will have the following features:
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.

[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - HTTP Request Translator Improvements ===

'''Brief explanation:'''

Problem to solve:

There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
* Transforms with boundary strings? (TBD)
* Individually or in bulk? (TBD)

'''Essential Function: "--output" argument'''

CRITICAL: The command/script should be generated so that the request is sent as literally as possible.

Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.

NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
* http request in => curl command out
* http request in => bash script out
* http request in => python script out
* http request in => php script out
* http request in => ruby script out
* http request in => PowerShell script out

'''Basic additional arguments:'''

- "--proxy" argument: generates the command/script with the relevant proxy option

NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)

- "--string-search" argument: generates the command/script so that it:

1) performs the request

2) then searches for something in the response (i.e. literal match)

- "--regex-search" argument: generates the command/script so that it:
1) performs the request

2) then searches for something in the response (i.e. regex match)

'''OWTF integration'''

The idea here, is to invoke this tool from:

1) Single HTTP transactions:

For example, have a button to "export http request" + then show options equivalent to the flags

2) Multiple HTTP transactions:

Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).

'''Desired input formats:'''

* Read raw HTTP request from stdin -Suggested default behaviour! :)-

Example: cat path/to/http_request.txt | http-request-translator.py --output

* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"

Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"

Example:

1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)

2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given

* For bulk processing: Maybe a directory of raw http request files?

'''Nice to have: Transforms'''

In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.

Example:

NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"

Step 1) The user provides a raw HTTP request like this:

GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
Host: target.com
...

Step 2) The tool generates a bash script like the following:

#!/bin/bash

PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
curl ...... "http://target.com/path/to/$PARAM1/test"

OR a "curl command" like the following:
PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"

This feature can be valuable to shave a bit more time in script writing.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - JavaScript Library Sniper Improvements ===

'''Brief explanation:'''
This is a project that tries to resolve a very common problem during penetration tests:

The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.

To solve this problem, we propose a *standalone* *tool* that can:

1) Be run BOTH from inside AND outside of OWTF

2) Build and *update* a fingerprint JavaScript library database of:
* Library File hashes => JavaScript Library version
* Library File lengths => JavaScript Library version
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)

3) Build and *update* a vulnerability database of:
* JavaScript Library version => CVE - CVSS score - Vulnerability info

4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
* JavaScript Library version
* List of vulnerabilities sorted in descending CVSS score order

5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
* ALL Library/vulnerability matches described on 4)

Once the standalone tool is built and verified to be working, OWTF should be able to:

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):

1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-

2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)

Potential projects worth having a look for potential overlap/inspiration:
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]

How many JavaScript libraries should be included?
* As many as possible, but especially the major ones: jQuery, knockout, etc.
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-

Common JavaScript library fingerprinting techniques include:
* Parse the JavaScript file and grab the version from there
* Determine the JavaScript version based on a hash of the file
* Determine the JavaScript version based on the length of the file

Other Challenges:
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
* When the JavaScript file does not match a specific version:
1) The commit that matches the closest should (ideally) be found
2) The NEXT library version after that commit (if present) should be found
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Off-line HTTP traffic uploader ===

'''Brief explanation:'''

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

* Tools that OWTF has trouble proxying right now: skipfish, hoppy
* Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
* Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like:
skipfish, hoppy, w3af, arachni, etc.
Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

* HTTP request
* HTTP response status code
* HTTP response headers
* HTTP response body

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool
Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of *stupidly* trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Health Monitor ===

'''Brief explanation:'''

In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.

For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:

'''Feature 1) Alerting mechanisms'''

When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
* Playing an mp3 song (both local and possibly remote locations)
* Scan status overview on the CLI
* Scan status overview on the GUI

NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.

'''Feature 2) Corrective mechanisms'''

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
* Stop this tool
* Freeze this process (to continue later)
* Freeze the whole scan (to continue later)

Additional mechanisms:
* Show a ranking of files that take the most space

'''Feature 3) Target monitor'''

Brief overview:

All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).

Potential approach: Check if length of 1st page changes every 60 seconds.

NOTE: It might be needed to change this on the fly.

More background

Consider the following scenario:

Current Situation aka "problem to solve":

1) Website X goes down during a scan

2) the customer notices

3) the customer tells the boss

4) the boss tells the pentester

5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)

Desired situation aka "solution":

It would be much more professional AND efficient that:

1) The pentester notices

2) The pentester tells the boss

3) The boss tells the customer

4) OWTF stops the tool because it knows that website is DEAD anyway

A target monitor could easily do this with heartbeat requests + playing mp3s

The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"

'''Feature 4) Disk space monitor'''

Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).

Proposed solution:

Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).

'''Feature 5) Network/Internet Connectivity monitor'''

Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:

1) Detects the lack of connectivity

2) Freezes all the tools (read: processes) in progress

3) Resumes the scan when the connectivity is back.

'''Feature 6) Tool crash detection'''

Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)

'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''

OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Installation Improvements and Package manager ===

'''Brief explanation:'''

This project is to implement what was suggested in the following github issue:
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]

Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
Having a private server with:
* pre-installed files for VMs
* pre-configured and patched tools
* Merged Lists
* Pre-configured certificates
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
Additional ideas are welcome.

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes
* For high speed connections (Downloading the files uncompressed)
* For low speed connections (Downloading the files compressed)
and the installation crashed because i runned out of space in the vm
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* Good documentation

'''Knowledge Prerequisite:'''

Python and bash experience 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

=== OWASP OWTF - Tool utilities module ===

'''WARNING: This idea is taken from the 1st round of OWCS selections (Sept. 15th), please do NOT apply'''

'''Brief explanation:'''

The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.

'''Feature 1) Vulnerable software version database:'''

Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).

Example:
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]

'''Feature 2) Nmap output file merger:'''

Unify nmap files *without* losing data: XML, text and greppable formats
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).

'''Feature 3) Nmap output file vulnerability mapper'''

From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):

1) CVEs in reverse order of CVSS score, with links.

2) Metasploit modules available for each CVE / issue

NOTE: Can supply an *old* shell script for reference

3) Servers/ports affected (i.e. all server / port combinations using that software version)

'''Feature 4) URL target list creator:'''

Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF

'''Feature 5) Hydra command creator:'''

nmap file in => Hydra command list out

grep http auth / login pages in output files to identify login interfaces => Hydra command list out

'''Feature 6) WP-scan command creator:'''

look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press

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]'''
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
* Excellent reliability (i.e. proper exception handling, etc.)
* Good performance
* Unit tests / Functional tests
* 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

'''OWASP OWTF Mentor:'''

Abraham Aranguren - OWASP OWTF Project Leader - Contact: Abraham.Aranguren@owasp.org

== OWASP ZAP ==

We are in the process of deciding the set of ZAP projects for Google Summer of Code 2015.

You can follow (and join in) the discussions on the ZAP Developer Group: https://groups.google.com/d/msg/zaproxy-develop/Uy0JPkzsI_s/Bj7OTSkISCIJ

== OWASP Testing Guide ==

=== OTG Web Testing Tool Integration ===
'''Brief explanation:'''

We would like the OWASP Testing Guide to be much more easily consumable by web testing tools (such as ZAP). This would require adjustments to the Testing Guide, or separate Testing with X Guides, to explain how testing is completed with given tools. The tools would of course need to be changed to make full use of OTG and this project could include such changes to OWASP tools like ZAP.

'''Expected outputs:'''

Amended OTG or Testing with X Guides. Either option would require the document to integrate with all web testing tools (Using ZAP as the baseline).
Optional ZAP changes or add-on to make better use of the OTGs

'''Knowledge required:'''

Writing skills

'''OTG Web Testing Tool Integration mentor:'''

Andrew Muller - OTG Project Co-Leader - Contact: Andrew.muller@owasp.org

== OWASP AppSensor ==

[[OWASP AppSensor Project]] provides real-time application layer intrusion detection. The software has recently hit v2.0. We have some ambitious plans across a variety of areas for the next year to build on the recent momentum.

* Check the AppSensor wiki page linked above
* Contact us through the mailing list.
* Check our [https://github.com/jtmelton/appsensor github repository] and the [https://github.com/jtmelton/appsensor/issues open tickets]
* Also see our [http://www.appsensor.org appsensor website]

=== Enterprise Integrations - Reporting ===

'''Brief Explanation:'''

This is a feature request that's been driven by the community. AppSensor provides great utility by allowing applications to defend themselves. AppSensor can/will also provide a UI (another possible GSOC project) to view and manage the information produced by the applications. However, larger organizations often already have a system in place for managing system security alerts. It would provide a lot of value if we can integrate with those systems and data formats. This project will involve a bit of up-front research, then primarily systems integration work.

'''Expected Results:'''

We want to support a number of integrations. Some that have been requested by our community are:
* SNMP
* JMX
* SCOM
* syslog
* CEF
* AppDynamics

Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Enterprise Integrations - Transport ===

'''Brief Explanation:'''

AppSensor currently supports a number of "execution modes", which are simply a reference to the transport protocol (REST, SOAP, thrift). There are a number of protocols that are popular in enterprises that we don't currently support, but could. This would simplify integration for many organizations who already use a set of approved communication protocols. This project would be primarily integration work and testing with a number of well-known systems integration / transport protocols and mechanisms.

'''Expected Results:'''

We want to support a number of integrations. Some that have been proposed are:
* Kafka
* RabbitMQ
* ActiveMQ
* Avro
* Protobuf

Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing. Some familiarity with distributed systems in general and message brokers in particular would be helpful.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Dashboard UI ===

'''Brief Explanation:'''

AppSensor provides a solid base of functionality to applications, but does not currently do a good job of presenting the resulting data. We are attacking that issue on 2 fronts. We plan to create a custom UI (this project) as well as various integrations to standard tools/formats for reporting to existing display systems. This project will involve creating the default/standard UI for the AppSensor project. As part of the project, you will learn about the domain model, iterating your mockup designs and share those with the project leader(s) and the community for feedback. We don't have an existing product, so you will have lots of responsibility for the design and implementation, as well as significant input to the decision around the technology stack.

'''Expected Results:'''

A modern, usable UI will be built that will have at least the following features (though there are many more features to build) :
* Basic Dashboard UI (the UI for the OPS wall)
* Search
* Policy Management (edit server configuration)

Source code and associated tests for the UI will be created, along with the associated end user documentation for how to setup and configure the system.

'''Knowledge Prerequisites:'''

Comfortable with UI design and development, particularly building dashboards. Comfortable with Java (with some assistance). Basic familiarity with security concepts related to intrusion detection and prevention as this is the basic domain.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

=== Trend Monitoring Analysis Engine ===

'''Brief Explanation:'''

AppSensor currently supports a basic policy-driven analysis engine to determine if a series of events represents an attack (if a user triggers 5 of this type of event in 10 minutes, it's an attack). While this supports many use cases, there are times when it would be helpful to know trending information. If a particular function of the application begins to see 10 times its normal amount of traffic, that might represent an attack. This project would add an additional analysis engine to support "trend monitoring". Development of this feature would require some initial research on alternative implementation strategies, followed by the development and testing of the feature in AppSensor.

'''Expected Results:'''

The project should produce:
* A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
* Associated configuration mechanism to specify the trending rules/policy
* A small full sample demo application showing usage of the trend monitoring feature

Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

'''Knowledge Prerequisites:'''

Comfortable in Java and unit testing.

'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)

File:Appsensor intro for developers.pdf

2015-02-14T05:37:02Z

John Melton: This doc is a 1-page intro guide for developers.

This doc is a 1-page intro guide for developers.

OWASP AppSensor Project

2015-01-30T03:56:00Z

John Melton: /* Code Roadmap */ adjust roadmap dates based on expected availability

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [08 Jan 2015] AppSensor Code v2.0.0 RC3 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC3 released]
* [04 Nov 2014] AppSensor Code v2.0.0 RC2 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC2 released]
* [05 Oct 2014] AppSensor Code v2.0.0 RC1 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC1 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas.
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 final was released in late January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== May 2015 (2.1) ===
* First version of administration UI for appsensor (reporting / monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/5 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Extend reporting APIs (github issues [[https://github.com/jtmelton/appsensor/issues/10 github issue])
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* Video demo of setting up appsensor (screen capture)

=== September 2015 (2.2) ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission
* GSOC 2015 mentoring (if selected)

=== January 2016 (2.3) ===
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2015-01-29T16:39:32Z

John Melton: /* Code Roadmap */ completed v2 push

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [08 Jan 2015] AppSensor Code v2.0.0 RC3 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC3 released]
* [04 Nov 2014] AppSensor Code v2.0.0 RC2 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC2 released]
* [05 Oct 2014] AppSensor Code v2.0.0 RC1 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC1 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== Non code ===

* Update AppSensor Guide to keep in step with code changes and improvements to ideas.
* Create demo
* Develop training materials

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 final was released in late January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2015 (2.0) ===
* <strike>Jan - v 2.0.0 final release </strike> -> DONE

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* <strike>Jan 2015 (delay due to bug) - v 2.0.0 final </strike> -> DONE
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== Q1 2015 (2.1) ===
* First version of administration UI for appsensor (reporting / monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/5 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Extend reporting APIs (github issues [[https://github.com/jtmelton/appsensor/issues/10 github issue])
* Push v 2.1 when admin UI complete
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* Video demo of setting up appsensor (screen capture)

=== Q2 2015 (2.2) ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission

=== Q3 2015 (2.3) ===
* GSOC 2015 mentoring (if selected)
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

Projects/OWASP AppSensor Project/Releases/AppSensor 0.1.3

2015-01-29T03:38:31Z

John Melton: v2 update

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP AppSensor Project
| project_home_page = OWASP AppSensor Project

| release_name = AppSensor v2
| release_date = Jan 2015 (code / final) & May 2014 (doc / final)
| release_description =
| release_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''' for documentation] & [http://opensource.org/licenses/MIT '''MIT License''' for Tools].
| release_download_link = https://github.com/jtmelton/appsensor

| leader_name1 = Michael Coates
| leader_email1 = michael.coates@owasp.org
| leader_username1 = MichaelCoates

| leader_name[2-10] =
| leader_email[2-10] =
| leader_username[2-10] =

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes = https://github.com/jtmelton/appsensor

| links_url1 = http://www.brighttalk.com/webcast/20680
| links_name1 = Automated Application Defenses to Thwart Advanced Attackers

| links_url2 = https://www.owasp.org/index.php/File:Appsensor-pid.pdf
| links_name2 = Diagram

| links_url3 = http://www.youtube.com/watch?v=8ItfuwvLxRk
| links_name3 = Live Demo

| links_url4 = https://github.com/jtmelton/appsensor
| links_name4 = AppSensor Code

}}

OWASP AppSensor Project

2015-01-29T03:36:57Z

John Melton: /* News and Events */ added v2 release

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [28 Jan 2015] AppSensor Code v2.0.0 final [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0 released]
* [08 Jan 2015] AppSensor Code v2.0.0 RC3 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC3 released]
* [04 Nov 2014] AppSensor Code v2.0.0 RC2 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC2 released]
* [05 Oct 2014] AppSensor Code v2.0.0 RC1 [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-RC1 released]
* [18 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. v2.0.0 RC3 was released in early January 2015.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* Jan 2015 (delay due to bug) - v 2.0.0 final
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== Q1 2015 (2.1) ===
* First version of administration UI for appsensor (reporting / monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/5 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Extend reporting APIs (github issues [[https://github.com/jtmelton/appsensor/issues/10 github issue])
* Push v 2.1 when admin UI complete
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* Video demo of setting up appsensor (screen capture)

=== Q2 2015 (2.2) ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission

=== Q3 2015 (2.3) ===
* GSOC 2015 mentoring (if selected)
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Proposed Documentation Roadmap ==

=== Q4 2014 ===

Update AppSensor Guide to keep in step with code changes and improvements to ideas.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2015-01-04T04:13:58Z

John Melton: /* Q4 2014 (2.0) */

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [18-19 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. A [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta v2.0.0 beta was released for review] on 13 September 2014.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* Jan 2015 (delay due to bug) - v 2.0.0 final
* <strike>Additional unit tests</strike> -> DONE
* <strike>Move appsensor.org site over from static html to python</strike> -> NOT NECESSARY
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== Q1 2015 (2.1) ===
* First version of administration UI for appsensor (reporting / monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/5 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Extend reporting APIs (github issues [[https://github.com/jtmelton/appsensor/issues/10 github issue])
* Push v 2.1 when admin UI complete
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* Video demo of setting up appsensor (screen capture)

=== Q2 2015 (2.2) ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission

=== Q3 2015 (2.3) ===
* GSOC 2015 mentoring (if selected)
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Proposed Documentation Roadmap ==

=== Q4 2014 ===

Update AppSensor Guide to keep in step with code changes and improvements to ideas.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

Projects/OWASP AppSensor Project/Releases/AppSensor 0.1.3

2014-11-08T03:37:46Z

John Melton: updating versions

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP AppSensor Project
| project_home_page = OWASP AppSensor Project

| release_name = AppSensor v2
| release_date = Nov 2014 (code / rc2) & May 2014 (doc / final)
| release_description =
| release_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''' for documentation] & [http://opensource.org/licenses/MIT '''MIT License''' for Tools].
| release_download_link = https://github.com/jtmelton/appsensor

| leader_name1 = Michael Coates
| leader_email1 = michael.coates@owasp.org
| leader_username1 = MichaelCoates

| leader_name[2-10] =
| leader_email[2-10] =
| leader_username[2-10] =

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes = https://github.com/jtmelton/appsensor

| links_url1 = http://www.brighttalk.com/webcast/20680
| links_name1 = Automated Application Defenses to Thwart Advanced Attackers

| links_url2 = https://www.owasp.org/index.php/File:Appsensor-pid.pdf
| links_name2 = Diagram

| links_url3 = http://www.youtube.com/watch?v=8ItfuwvLxRk
| links_name3 = Live Demo

| links_url4 = https://github.com/jtmelton/appsensor
| links_name4 = AppSensor Code

}}

OWASP AppSensor Project

2014-11-08T03:31:54Z

John Melton: roadmap updates: link to github issues, mark things that are complete, and add semantic version numbers for quarterly releases

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [18-19 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. A [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta v2.0.0 beta was released for review] on 13 September 2014.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2014 (2.0) ===
* <strike>Oct - v 2.0.0 release candidate</strike> -> DONE
* Nov - v 2.0.0 final
* <strike>Additional unit tests</strike> -> DONE
* Move appsensor.org site over from static html to python
* <strike>Finish up user documentation at appsensor.org</strike> -> DONE

=== Q1 2015 (2.1) ===
* First version of administration UI for appsensor (reporting / monitoring UI) (github issues [https://github.com/jtmelton/appsensor/issues/5 here] and [https://github.com/jtmelton/appsensor/issues/11 here])
* Extend reporting APIs (github issues [[https://github.com/jtmelton/appsensor/issues/10 github issue])
* Push v 2.1 when admin UI complete
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS ([https://github.com/jtmelton/appsensor/issues/9 github issue])
* Get CI server (cloudbees?) setup ([https://github.com/jtmelton/appsensor/issues/15 github issue])
* Finish up developer documentation on github and appsensor.org ([https://github.com/jtmelton/appsensor/issues/12 github issue])
* Video demo of setting up appsensor (screen capture)

=== Q2 2015 (2.2) ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations ([https://github.com/jtmelton/appsensor/issues/8 github issue])
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission

=== Q3 2015 (2.3) ===
* GSOC 2015 mentoring (if selected)
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Proposed Documentation Roadmap ==

=== Q4 2014 ===

Update AppSensor Guide to keep in step with code changes and improvements to ideas.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2014-10-05T02:19:21Z

John Melton: updating code roadmap to be final - not in review

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [18-19 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
* Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. A [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta v2.0.0 beta was released for review] on 13 September 2014.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Code Roadmap ==

=== Q4 2014 ===
* Oct - v 2.0.0 release candidate
* Nov - v 2.0.0 final
* Additional unit tests
* Move appsensor.org site over from static html to python
* Finish up user documentation at appsensor.org

=== Q1 2015 ===
* First version of administration UI for appsensor (reporting / monitoring UI)
* Extend reporting APIs
* Push v 2.1 when admin UI complete
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS
* Get CI server (cloudbees?) setup
* Finish up developer documentation on github and appsensor.org
* Video demo of setting up appsensor (screen capture)

=== Q2 2015 ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission

=== Q3 2015 ===
* GSOC 2015 mentoring (if selected)
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Proposed Documentation Roadmap ==

=== Q4 2014 ===

Update AppSensor Guide to keep in step with code changes and improvements to ideas.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

Projects/OWASP AppSensor Project/Releases/AppSensor 0.1.3

2014-09-23T02:31:28Z

John Melton: updating links and updated alpha to beta version

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP AppSensor Project
| project_home_page = OWASP AppSensor Project

| release_name = AppSensor v2 (beta)
| release_date = June 2014 (code) & May 2014 (doc)
| release_description =
| release_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''' for documentation] & [http://opensource.org/licenses/MIT '''MIT License''' for Tools].
| release_download_link = https://github.com/jtmelton/appsensor

| leader_name1 = Michael Coates
| leader_email1 = michael.coates@owasp.org
| leader_username1 = MichaelCoates

| leader_name[2-10] =
| leader_email[2-10] =
| leader_username[2-10] =

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes = https://github.com/jtmelton/appsensor

| links_url1 = http://www.brighttalk.com/webcast/20680
| links_name1 = Automated Application Defenses to Thwart Advanced Attackers

| links_url2 = https://www.owasp.org/index.php/File:Appsensor-pid.pdf
| links_name2 = Diagram

| links_url3 = http://www.youtube.com/watch?v=8ItfuwvLxRk
| links_name3 = Live Demo

| links_url4 = https://github.com/jtmelton/appsensor
| links_name4 = AppSensor Code

}}

OWASP AppSensor Project

2014-09-23T02:27:45Z

John Melton: /* Proposed Code Roadmap (IN REVIEW) */

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [18-19 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. A [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta v2.0.0 beta was released for review] on 13 September 2014.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Proposed Code Roadmap (IN REVIEW) ==

=== Q4 2014 ===
* Oct - v 2.0.0 release candidate
* Nov - v 2.0.0 final
* Additional unit tests
* Move appsensor.org site over from static html to python
* Finish up user documentation at appsensor.org

=== Q1 2015 ===
* First version of administration UI for appsensor (reporting / monitoring UI)
* Extend reporting APIs
* Push v 2.1 when admin UI complete
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Workup example integration with ModSecurity CRS
* Get CI server (cloudbees?) setup
* Finish up developer documentation on github and appsensor.org
* Video demo of setting up appsensor (screen capture)

=== Q2 2015 ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission

=== Q3 2015 ===
* GSOC 2015 mentoring (if selected)
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2014-09-23T02:26:03Z

John Melton: /* Road Map and Getting Involved */

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application. This project includes both a well documented idea (the Guide) and a reference implementation (the Code).

== AppSensor Website ==

[[File:Appsensor-website-small.jpg|link=http://appsensor.org/]]

See the [http://appsensor.org/ new AppSensor website] for an introduction and quick start instructions.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==

* [18-19 Sep 2014] Guide book giveaway and signing at [http://2014.appsecusa.org/2014/ AppSecUSA 2014]
* [17 Sep 2014] Presentation at [http://www.meetup.com/London-API-Group/events/200768922/ London API Group]
* [13 Sep 2014] AppSensor Code v2.0.0 beta [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta released]
* [12 Sep 2014] [http://appsensor.org/ AppSensor website] launched
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [08 May 2014] AppSensor Guide v2.0.1 released
* [02 May 2014] AppSensor Guide v2.0 released

== Code Repository ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. A [https://github.com/jtmelton/appsensor/releases/tag/v2.0.0-beta v2.0.0 beta was released for review] on 13 September 2014.

The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Proposed Code Roadmap (IN REVIEW) ==

=== Q4 2014 ===
* Oct - v 2.0.0 release candidate
* Nov - v 2.0.0 final
* Additional unit tests
* Move appsensor.org site over from static html to python
* Finish up user documentation at appsensor.org

=== Q1 2015 ===
* First version of administration UI for appsensor (reporting / monitoring UI)
* Extend reporting APIs
* Push v 2.1 when admin UI complete
* Add at least 1 attack emitter for DEVOPS visualization (JMX -> SNMP, syslog, SNMP, .. something)
* Get CI server (cloudbees?) setup
* Finish up developer documentation on github and appsensor.org
* Video demo of setting up appsensor (screen capture)

=== Q2 2015 ===
* Sample applications - simple implementations of the different execution modes)
* New detection point implementations
* AOP examples of detection point implementations
* Preparation for GSOC 2015 submission

=== Q3 2015 ===
* GSOC 2015 mentoring (if selected)
* Trend monitoring implementation (good for GSOC project possibly)
* Additional integrations for reporting (graphite, ganglia -> see list supported by codahale metrics)

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Website ==

[[File:Appsensor-website-large.jpg|link=http://appsensor.org/]]

[http://appsensor.org/ http://appsensor.org/]

== Code ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2014-08-10T04:41:35Z

John Melton: Remove unused links and tag old version as legacy

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [06 May 2014] AppSensor Guide v2.0 announced
* [01 May 2014] AppSensor Guide v2.0 in final production stages
* [21 Nov 2013] [http://appsecusa2013.sched.org/event/6dddc818ce383f9f16c93a6942194fcc?iframe=no&w=990&sidebar=yes&bg=no AppSensor Project presentation]

== Code Repositories ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Development ==

*v2 [https://github.com/jtmelton/appsensor Github Code]
* (LEGACY) v1 [http://code.google.com/p/appsensor/ Google Code]

== Presentations ==

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

Projects/OWASP AppSensor Project

2014-08-10T04:37:25Z

John Melton: updated versions of various things and removed old links

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP AppSensor Project
| project_home_page = :Category:OWASP AppSensor Project
| project_description =
Real Time Application Attack Detection and Response
'''Overview'''
The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the AppSensor tool which can be utilized by any existing application interested in adding detection and response capabilities.
<br>'''Detection'''
AppSensor defines over 50 different [http://www.owasp.org/index.php/AppSensor_DetectionPoints detection points] which can be used to identify a malicious attacker.
<br>'''Response'''
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen [http://www.owasp.org/index.php/AppSensor_ResponseActions response actions] are described.
<br>'''Defending the Application'''
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

| project_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''' for documentation] & [http://opensource.org/licenses/MIT '''MIT License''' for Tools]

| leader_name1 = Michael Coates
| leader_email1 = michael.coates@owasp.org
| leader_username1 = MichaelCoates

| leader_name2 = John Melton
| leader_email2 = john.melton@owasp.org
| leader_username2 = John Melton

| leader_name3 = Colin Watson
| leader_email3 = colin.watson@owasp.org
| leader_username3 = Clerkendweller

| leader_name4 = Dennis Groves
| leader_email4 = dennis.groves@owasp.org
| leader_username4 = Dennis Groves

| contributor_name1 = Ryan Barnett
| contributor_email1 = ryan.barnett@owasp.org
| contributor_username1 = Rcbarnett

| contributor_name2 = Simon Bennetts
| contributor_email2 =
| contributor_username2 = Simon Bennetts

| contributor_name3 = August Detlefsen
| contributor_email3 =
| contributor_username3 =

| contributor_name4 = Randy Janida
| contributor_email4 =
| contributor_username4 =

| contributor_name5 = Jim Manico
| contributor_email5 = jim.manico@owasp.org
| contributor_username5 = Jmanico

| contributor_name6 = Giri Nambari
| contributor_email6 =
| contributor_username6 =

| contributor_name7 = Eric Sheridan
| contributor_email7 =
| contributor_username7 = Esheridan

| contributor_name8 = John Stevens
| contributor_email8 =
| contributor_username8 = jsteven@cigital.com

| contributor_name8 = Kevin Wall
| contributor_email8 =
| contributor_username8 =

| contributor_name9 = Dennis Groves
| contributor_email9 =
| contributor_username9 =

| pamphlet_link = http://code.google.com/p/appsensor/downloads/detail?name=Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf&can=2&q=

| presentation_link = http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project

| project_road_map = http://www.owasp.org/index.php/OWASP_AppSensor_Project#tab=Project_Roadmap

| links_url1 = http://www.brighttalk.com/webcast/20680
| links_name1 = Automated Application Defenses to Thwart Advanced Attackers

| links_url2 = https://www.owasp.org/index.php/File:Appsensor-pid.pdf
| links_name2 = Diagram

| links_url3 = https://github.com/jtmelton/appsensor
| links_name3 = AppSensor v2 Code

| links_url4 = https://www.owasp.org/index.php/Project_Information:template_AppSensor_Project
| links_name4 = Former Project About

| release_1 = AppSensor v2 (alpha)

| release_2 =

| release_3 =

| release_4 =

| project_about_page = Projects/OWASP AppSensor Project
}}

Projects/OWASP AppSensor Project/Releases/AppSensor 0.1.3

2014-08-10T04:36:24Z

John Melton: updated versions of various things and removed old links

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP AppSensor Project
| project_home_page = OWASP AppSensor Project

| release_name = AppSensor v2 (alpha)
| release_date = June 2014 (code) & May 2014 (doc)
| release_description =
| release_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''' for documentation] & [http://opensource.org/licenses/MIT '''MIT License''' for Tools].
| release_download_link = https://github.com/jtmelton/appsensor

| leader_name1 = Michael Coates
| leader_email1 = michael.coates@owasp.org
| leader_username1 = MichaelCoates

| leader_name[2-10] =
| leader_email[2-10] =
| leader_username[2-10] =

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes = https://github.com/jtmelton/appsensor

| links_url1 = http://www.brighttalk.com/webcast/20680
| links_name1 = Automated Application Defenses to Thwart Advanced Attackers

| links_url2 = https://www.owasp.org/index.php/File:Appsensor-pid.pdf
| links_name2 = Diagram

| links_url3 = http://www.youtube.com/watch?v=8ItfuwvLxRk
| links_name3 = Live Demo

| links_url4 = http://code.google.com/p/appsensor/
| links_name4 = AppSensor Code

}}

OWASP AppSensor Project

2014-08-10T03:53:11Z

John Melton: adding slight update to overview statement to specify consumers

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [06 May 2014] AppSensor Guide v2.0 announced
* [01 May 2014] AppSensor Guide v2.0 in final production stages
* [21 Nov 2013] [http://appsecusa2013.sched.org/event/6dddc818ce383f9f16c93a6942194fcc?iframe=no&w=990&sidebar=yes&bg=no AppSensor Project presentation]

== Code Repositories ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Development ==

*[http://www.owasp.org/index.php/AppSensor_Developer_Guide Developer Guide]
*v2 [https://github.com/jtmelton/appsensor Github Code]
*v1 [http://code.google.com/p/appsensor/ Google Code]

== Presentations ==

[http://code.google.com/p/appsensor/source/browse/trunk/AppSensor-Tutorial/ AppSensorTutorial]

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2014-08-10T03:47:52Z

John Melton: updating license info

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use.

=== Guide ===
The guide is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

=== Reference Implementation ===
The reference implementation is licensed under the [http://opensource.org/licenses/MIT MIT License], which is a permissive (commercial-friendly) license only requiring you to include a copy of the license upon distribution or copying.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [06 May 2014] AppSensor Guide v2.0 announced
* [01 May 2014] AppSensor Guide v2.0 in final production stages
* [21 Nov 2013] [http://appsecusa2013.sched.org/event/6dddc818ce383f9f16c93a6942194fcc?iframe=no&w=990&sidebar=yes&bg=no AppSensor Project presentation]

== Code Repositories ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Development ==

*[http://www.owasp.org/index.php/AppSensor_Developer_Guide Developer Guide]
*v2 [https://github.com/jtmelton/appsensor Github Code]
*v1 [http://code.google.com/p/appsensor/ Google Code]

== Presentations ==

[http://code.google.com/p/appsensor/source/browse/trunk/AppSensor-Tutorial/ AppSensorTutorial]

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

Projects/OWASP AppSensor Project

2014-08-10T03:43:41Z

John Melton: clean up email addresses

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP AppSensor Project
| project_home_page = :Category:OWASP AppSensor Project
| project_description =
Real Time Application Attack Detection and Response
'''Overview'''
The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the AppSensor tool which can be utilized by any existing application interested in adding detection and response capabilities.
<br>'''Detection'''
AppSensor defines over 50 different [http://www.owasp.org/index.php/AppSensor_DetectionPoints detection points] which can be used to identify a malicious attacker.
<br>'''Response'''
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen [http://www.owasp.org/index.php/AppSensor_ResponseActions response actions] are described.
<br>'''Defending the Application'''
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

| project_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''' for documentation] & [http://www.opensource.org/licenses/bsd-license.php '''New BSD License''' for Tools]

| leader_name1 = Michael Coates
| leader_email1 = michael.coates@owasp.org
| leader_username1 = MichaelCoates

| leader_name2 = John Melton
| leader_email2 = john.melton@owasp.org
| leader_username2 = John Melton

| leader_name3 = Colin Watson
| leader_email3 = colin.watson@owasp.org
| leader_username3 = Clerkendweller

| leader_name4 = Dennis Groves
| leader_email4 = dennis.groves@owasp.org
| leader_username4 = Dennis Groves

| contributor_name1 = Ryan Barnett
| contributor_email1 = ryan.barnett@owasp.org
| contributor_username1 = Rcbarnett

| contributor_name2 = Simon Bennetts
| contributor_email2 =
| contributor_username2 = Simon Bennetts

| contributor_name3 = August Detlefsen
| contributor_email3 =
| contributor_username3 =

| contributor_name4 = Randy Janida
| contributor_email4 =
| contributor_username4 =

| contributor_name5 = Jim Manico
| contributor_email5 = jim.manico@owasp.org
| contributor_username5 = Jmanico

| contributor_name6 = Giri Nambari
| contributor_email6 =
| contributor_username6 =

| contributor_name7 = Eric Sheridan
| contributor_email7 =
| contributor_username7 = Esheridan

| contributor_name8 = John Stevens
| contributor_email8 =
| contributor_username8 = jsteven@cigital.com

| contributor_name8 = Kevin Wall
| contributor_email8 =
| contributor_username8 =

| contributor_name9 = Dennis Groves
| contributor_email9 =
| contributor_username9 =

| pamphlet_link = http://code.google.com/p/appsensor/downloads/detail?name=Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf&can=2&q=

| presentation_link = http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project

| project_road_map = http://www.owasp.org/index.php/OWASP_AppSensor_Project#tab=Project_Roadmap

| links_url1 = http://www.owasp.org/index.php/AppSensor_Developer_Guide
| links_name1 = AppSensor & ESAPI Developer's Guide

| links_url2 = http://code.google.com/p/appsensor/source/browse/trunk/AppSensor-Tutorial/
| links_name2 = AppSensor Tutorial

| links_url3 = https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf
| links_name3 = Download AppSensor Book - PDF

| links_url4 = https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc
| links_name4 = Download AppSensor Book - Word

| links_url5 = http://www.brighttalk.com/webcast/20680
| links_name5 = Automated Application Defenses to Thwart Advanced Attackers

| links_url6 = https://www.owasp.org/index.php/File:Appsensor-pid.pdf
| links_name6 = Diagram

| links_url7 = http://www.youtube.com/watch?v=8ItfuwvLxRk
| links_name7 = Live Demo

| links_url8 = http://code.google.com/p/appsensor/
| links_name8 = AppSensor Code

| links_url9 = https://www.owasp.org/index.php/Project_Information:template_AppSensor_Project
| links_name9 = Former Project About

| release_1 = AppSensor 0.1.3

| release_2 =

| release_3 =

| release_4 =

| project_about_page = Projects/OWASP AppSensor Project
}}

OWASP AppSensor Project

2014-08-10T03:42:57Z

John Melton:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use. It is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* [https://www.owasp.org/index.php/User:MichaelCoates Michael Coates] [mailto:michael.coates@owasp.org @]

== Project Leaders ==

* [https://www.owasp.org/index.php/User:Dennis_Groves Dennis Groves] [mailto:dennis.groves@owasp.org @]
* [https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:john.melton@owasp.org @]
* [https://www.owasp.org/index.php/User:Clerkendweller Colin Watson] [mailto:colin.watson@owasp.org @]

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [06 May 2014] AppSensor Guide v2.0 announced
* [01 May 2014] AppSensor Guide v2.0 in final production stages
* [21 Nov 2013] [http://appsecusa2013.sched.org/event/6dddc818ce383f9f16c93a6942194fcc?iframe=no&w=990&sidebar=yes&bg=no AppSensor Project presentation]

== Code Repositories ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Development ==

*[http://www.owasp.org/index.php/AppSensor_Developer_Guide Developer Guide]
*v2 [https://github.com/jtmelton/appsensor Github Code]
*v1 [http://code.google.com/p/appsensor/ Google Code]

== Presentations ==

[http://code.google.com/p/appsensor/source/browse/trunk/AppSensor-Tutorial/ AppSensorTutorial]

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

OWASP AppSensor Project

2014-08-10T03:34:42Z

John Melton:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Appsensor-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 AppSensor ==

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement [https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection intrusion detection and automated response] into applications.

== Introduction ==

If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

== Detect and Respond to Attacks from Within the Application ==

=== Detection ===
AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.
=== Response===
AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.
===Defending the Application===
An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.

==Citations==

* [http://www.crosstalkonline.org/ CrossTalk], The Journal of Defense Software Engineering
** Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

* Norwegian University of Science and Technology in Tronheim
** [http://ntnu.diva-portal.org/smash/record.jsf?pid=diva2:566091 AppSensor: Attack-Aware Applications Compared Against a Web Application Firewall and an Intrusion Detection System], Thomassen P, 2012

*US Department of Homeland Security
** [https://buildsecurityin.us-cert.gov/swa/topics/resilient-software/ Resilient Software]
** [https://buildsecurityin.us-cert.gov/swa/resources Software Assurance Resources]

==Licensing==
OWASP AppSensor is free to use. It is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], 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.

© OWASP Foundation

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

== What is AppSensor? ==

Detect and respond to attacks from within the application.

== Overview ==

[[File:Appsensor_crosstalk_small.jpg|link=http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf]]

Download the [http://www.crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf PDF] from CrossTalk Magazine.

== Project Founder ==

* Michael Coates

| leader_name1 = Michael Coates
| leader_email1 = Michael.Coates@owasp.org
| leader_username1 = MichaelCoates

== Project Leaders ==

* Dennis Groves
* John Melton
* Colin Watson

| leader_name1 = Michael Coates
| leader_email1 = Michael.Coates@owasp.org
| leader_username1 = MichaelCoates

== Related Projects ==

* [[:Category:OWASP_ModSecurity_Core_Rule_Set_Project|OWASP ModSecurity Core Rule Set]]

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

== Quick Download ==

* OWASP AppSensor Guide v2.0.1 EN
** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Hard copy]
* OWASP AppSensor Reference Implementation
** [https://github.com/jtmelton/appsensor v2 Code]

== News and Events ==
* [15 May 2014] Presentation at [https://www.owasp.org/index.php/London OWASP London]
* [06 May 2014] AppSensor Guide v2.0 announced
* [01 May 2014] AppSensor Guide v2.0 in final production stages
* [21 Nov 2013] [http://appsecusa2013.sched.org/event/6dddc818ce383f9f16c93a6942194fcc?iframe=no&w=990&sidebar=yes&bg=no AppSensor Project presentation]

== Code Repositories ==
* AppSensor v2 https://github.com/jtmelton/appsensor (Current)
Note: LEGACY AppSensor v1 https://code.google.com/p/appsensor/

== In Print ==

[[File:AppSensor2_small.jpg|link=]]

The AppSensor Guide v2.0 can be purchased at cost as a [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html print on demand book] from Lulu.com.

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-labs-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =

== Volunteers ==

All OWASP projects rely on the voluntary efforts of people in the software development and information security sectors. They have contributed their time and energy to make suggestions, provide feedback, write, review and edit documentation, give encouragement, make introductions, produce demonstration code, promote the concept, and provide OWASP support. They participated via the project’s mailing lists, by developing code, by updating the wiki, by undertaking research studies, and through contributions during the AppSensor working session at the OWASP Summit 2011 in Portugal and the AppSensor Summit at AppSec USA 2011. Without all their efforts, the project would not have progressed to this point, and this guide would not have been completed.

{| cellpadding="2"
|-
| width="200" align="left" valign="top" |

*Josh Amishav-Zlatin
*Ryan Barnett
*Simon Bennetts
*Joe Bernik
*Rex Booth
*Luke Briner
*Rauf Butt
*Fabio Cerullo
*Marc Chisinevski
*Robert Chojnacki
*Michael Coates
*Dinis Cruz
*August Detlefsen
*Ryan Dewhurst

| width="200" align="left" valign="top" |

*Erlend Oftedal
*Sean Fay
*Dennis Groves
*Randy Janida
*Chetan Karande
*Eoin Keary
*Alex Lauerman
*Junior Lazuardi
*Jason Li
*Manuel López Arredondo
*Bob Maier
*Jim Manico
*Sherif Mansour Farag
*John Melton

| width="200" align="left" valign="top" |

*Craig Munson
*Giri Nambari
*Jay Reynolds
*Chris Schmidt
*Sahil Shah
*Eric Sheridan
*John Steven
*Alex Thissen
*Don Thomas
*Christopher Tidball
*Kevin W Wall
*Colin Watson
*Mehmet Yilmaz

|}

==OWASP Summer of Code 2008==
The AppSensor Project was initially supported by the [https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008 OWASP Summer of Code 2008], leading to the publication of the book AppSensor v1.1.

==Google Summer of Code 2012==
Additional development work on [http://www.google-melange.com/gsoc/project/google/gsoc2012/edil/60002 SOAP web services] was kindly supported by the [http://www.google-melange.com/gsoc/program/home/google/gsoc2012 Google Summer of Code 2012].

== Other Acknowledgements ==
The project has also benefitted greatly from the generous contribution of time and effort by many volunteers in the OWASP community including those listed above, and contributors to the OWASP ESAPI project, members of the former OWASP Global Projects Committee, the OWASP Board, OWASP staff and support from the OWASP Project Reboot initiative. The v2 code and documentation were conceived during the AppSensor Summit held during AppSec USA 2011 in Minneapolis.

= Road Map and Getting Involved =

Please join the project's mailing lists to keep up-to-date with what's going on, and to contribute your ideas, feedback, and experience:
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project General project]
* [https://lists.owasp.org/mailman/listinfo/owasp-appsensor-dev Code development]

== Current activities ==

=== v2 Code ===

The current code being worked on is located on [https://github.com/jtmelton/appsensor GitHub]

The code has been fully rewritten. The main reason for the rewrite was to allow a client-server style model as opposed to requiring AppSensor be fully embedded in the application. You can now have a central server collecting events from multiple applications and performing analysis. These front-end applications can be in any language as long as they speak rest/soap. There's been a host of other changes, but this was the primary one. A number of starter ideas for coding, user interface and documentation have been outlined via the mailing list at [http://lists.owasp.org/pipermail/owasp-appsensor-project/2014-March/000682.html 17th March 2014].

if you want to work on ANYTHING, please let jtmelton[@]gmail.com know.

== Past activities ==

'''May 2014''' Finalisation and publication of the AppSensor Guide v2.0

'''November, 2013''' - AppSensor 2.0 hackathon, and document writing & review at AppSecUSA 2013, New York

'''2012-2013''' - Active Development of next AppSensor book

'''September, 2011''' - AppSensor Summit at AppSec USA 2011, Minneapolis

'''September, 2010''' - Presented at AppSecUSA [http://www.slideshare.net/michael_coates/real-time-application-defenses-the-reality-of-appsensor-esapi-5181743 slides]

'''June, 2010''' - Active ESAPI Integration Underway

'''November, 2009''' [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf OWASP DC, November 2009]

'''2009''' v1.2 in the works, demo application in development

'''May, 2009''' - AppSec EU Poland - Presentation ([http://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx PPT]) ([http://blip.tv/file/2198771 Video])

'''January, 2009''' - v1.1 Released - Beta Status

'''November, 2008''' - AppSensor Talk at OWASP Portugal

'''November, 2008''' - v1.0 Released - Beta Status

'''April 16, 2008''' - Project Begins

= Detection Points =

Below are the primary detection points defined within AppSensor. These are just the titles; the document contains descriptions, examples and considerations for implementing these detection points.

'''[http://www.owasp.org/index.php/AppSensor_DetectionPoints Detailed Detection Point Information Here] '''

'''[http://www.owasp.org/index.php/AppSensor_ResponseActions Response Action Information Here]'''

'''Summary of Information'''
'''Detection Categories:'''

RE - Request

AE - Authentication

SE - Session

ACE - Access Control

IE - Input

EE - Encoding

CIE - Command Injection

FIO - File IO

HT - Honey Trap

UT - User Trend

STE - System Trend

RP - Reputation

'''Signature Based Event Titles'''

ID Event

RE1 Unexpected HTTP Command

RE2 Attempt to Invoke Unsupported HTTP Method

RE3 GET When Expecting POST

RE4 POST When Expecting GET

RE5 Additional/Duplicated Data in Request

RE6 Data Missing from Request

RE7 Unexpected Quantity of Characters in Parameter

RE8 Unexpected Type of Characters in Parameter

AE1 Use Of Multiple Usernames

AE2 Multiple Failed Passwords

AE3 High Rate of Login Attempts

AE4 Unexpected Quantity of Characters in Username

AE5 Unexpected Quantity of Characters in Password

AE6 Unexpected Type of Character in Username

AE7 Unexpected Type of Character in Password

AE8 Providing Only the Username

AE9 Providing Only the Password

AE10 Adding POST Variable

AE11 Missing POST Variable

AE12 Utilization of Common Usernames

SE1 Modifying Existing Cookie

SE2 Adding New Cookie

SE3 Deleting Existing Cookie

SE4 Substituting Another User's Valid Session ID or Cookie

SE5 Source IP Address Changes During Session

SE6 Change Of User Agent Mid Session

ACE1 Modifying URL Argument Within a GET for Direct Object Access Attempt

ACE2 Modifying Parameter Within a POST for Direct Object Access Attempt

ACE3 Force Browsing Attempt

ACE4 Evading Presentation Access Control Through Custom POST

IE1 Cross Site Scripting Attempt

IE2 Violation of Implemented White Lists

IE3 Violation Of Implemented Black Lists

IE4 Violation of Input Data Integrity

IE5 Violation of Stored Business Data Integrity

IE6 Violation of Security Log Integrity

EE1 Double Encoded Character

EE2 Unexpected Encoding Used

CIE1 Blacklist Inspection for Common SQL Injection Values

CIE2 Detect Abnormal Quantity of Returned Records

CIE3 Null Byte Character in File Request

CIE4 Carriage Return or Line Feed Character In File Request

FIO1 Detect Large Individual File

FIO2 Detect Large Number of File Uploads

HT1 Alteration to Honey Trap Data

HT2 Honey Trap Resource Requested

HT3 Honey Trap Data Used

'''Behavior Based Event Titles'''<br>

UT1 Irregular Use of Application

UT2 Speed of Application Use

UT3 Frequency of Site Use

UT4 Frequency of Feature Use

STE1 High Number of Logouts Across The Site

STE2 High Number of Logins Across The Site

STE3 Significant Change in Usage of Same Transaction Across The Site

RP1 Suspicious or Disallowed User IP Address

RP2 Suspicious External User Behavior

RP3 Suspicious Client-Side Behavior

RP4 Change to Environment Threat Level

= Media =

== AppSensor Guide ==

* OWASP AppSensor Guide
** v2.0 EN
*** [https://www.owasp.org/index.php/File:Owasp-appsensor-guide-v2.pdf PDF]
*** [https://www.owasp.org/index.php/File:Owasp-appensor-guide-v2.doc DOC]
*** [http://www.lulu.com/shop/owasp-foundation/appsensor-guide/paperback/product-21608107.html Print on demand at cost hard copy]
*** ([https://4ed64fe7f7e3f627b8d0-bc104063a9fe564c2d8a75b1e218477a.ssl.cf2.rackcdn.com/appsensor-guide-2v0-owasp.zip Source files for all of above]) 96Mb zip
** v1.1 EN
*** [https://www.owasp.org/images/2/2f/OWASP_AppSensor_Beta_1.1.pdf PDF]
*** [https://www.owasp.org/images/b/b0/OWASP_AppSensor_Beta_1.1.doc DOC]

== Development ==

*[http://www.owasp.org/index.php/AppSensor_Developer_Guide Developer Guide]
*v2 [https://github.com/jtmelton/appsensor Github Code]
*v1 [http://code.google.com/p/appsensor/ Google Code]

== Presentations ==

[http://code.google.com/p/appsensor/source/browse/trunk/AppSensor-Tutorial/ AppSensorTutorial]

[http://www.brighttalk.com/webcast/20680 Automated Application Defenses to Thwart Advanced Attackers (Slides & Audio)]

July, 2010 - OWASP London (UK) - [http://www.owasp.org/index.php/File:Owasp-london-20100715-appsensor-3.pdf Real Time Application Attack Detection and Response with OWASP AppSensor]

June, 2010 - OWASP Leeds/North (UK) - OWASP AppSensor - The Self-Aware Web Application

June, 2010 - Video presentation - [http://michael-coates.blogspot.com/2010/06/online-presentation-thursday-automated.html Automated Application Defenses to Thwart Advanced Attackers]

November, 2009 - AppSec DC - [http://www.owasp.org/images/0/06/Defend_Yourself-Integrating_Real_Time_Defenses_into_Online_Applications-Michael_Coates.pdf Defend Yourself: Integrating Real Time Defenses into Online Applications]

May, 2009 - [http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 OWASP Podcast #51 ]

May, 2009 - AppSec EU Poland - [https://www.owasp.org/images/b/b7/AppsecEU09_MichaelCoates.pptx Real Time Defenses against Application Worms and Malicious Attackers]

November, 2008 - [https://www.owasp.org/images/7/77/Presentation_AppSensor.ppt OWASP Summit Portugal 2008 PPT]

==Video Demos of AppSensor==

[http://www.youtube.com/watch?v=8ItfuwvLxRk Detecting Multiple Attacks & Logging Out Attacker]

[http://www.youtube.com/watch?v=CekUMk_VRV8 Detecting XSS Probes]

[http://www.youtube.com/watch?v=LfD4y67qdWE Detecting URL Tampering]

[http://www.youtube.com/watch?v=1D6nTlmYjhY Detecting Verb Tampering]

= Project About =
{{:Projects/OWASP_AppSensor_Project | Project About}}

}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|AppSensor Project]] [[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:OWASP_Download]]

GSoC2012 Ideas

2012-03-04T05:54:24Z

John Melton: fixing formatting of appsensor

==Guidelines==
===Information for Students===
The ideas below were contributed by OWASP project leaders and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the corresponding project leaders and find out more about the particular suggestion you're looking at.
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

===Adding a Proposal===

'''Project:'''

'''Brief explanation:'''

'''Expected results:'''

'''Knowledge Prerequisite:'''

'''Mentor:'''

'''Ideas'''
How to find ideas? Obvious sources of projects are the OWASP project wiki, bugs database, and project mailing lists.

=== Generic Sample Proposal===

'''Accepted for GSoC 2011'''

'''Brief explanation:'''

KDE has developed a number of very interesting and powerful technologies, libraries and components but there is no easy way to show them to other people.

'''Expected results:'''

Something like Qt Demo but with KDE technologies.

'''Knowledge prerequisite:'''

C++ is the main language of KDE, therefore the demo should be in C++. The more you know about C++, Qt, KDE and scripting (for Kross and KDE bindings demos), the better.
This idea encompasses so much different stuff the student is not expected to know everything before he starts coding (but will certainly know a lot when he's done!).

'''Skill level:''' medium

'''Mentor:''' Pau Garcia i Quiles as general mentor and someone to ask for directions. Specific help for each technology will probably require help from its developers.

==OWASP Project Requests==

=== ZAP Proxy ===

The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

'''Website:''' https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

'''Mailing List:''' http://groups.google.com/group/zaproxy-develop

====Project 001 - Compare crawling sessions for authentication issues ====

'''Brief explanation:''' Develop a ZAP session crawler to be able to compare two crawling sessions of two logged in users and see what URLs or Actions could be performed from the other session.

'''Expected results:'''

ZAP will be able to recognise when requests are associated with different sessions.

ZAP should allow the user to view the crawled URLs for each session independantly, and show which URLs are unique to each session.

It should also be able to check if any of the 'unique' pages can in fact be accessed by the other session.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

'''Mentors:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 002 - Dynamically Configurable actions ====

'''Brief explanation:'''

ZAP provides various mechanisms which allow HTTP requests and responses to be changed dynamically. So (for example) a string in an HTTP request can automatically be changed to another string.

It also supports a scripting interface, which is very powerful but at the moment difficult to use.

This project would introduce something inbetween thess 2 options - a powerful way of defining (potentially) complex rules using a wizard based interface.

The challenge will be to make it as usable as possible while still providing a wide range of functionality.

'''Expected results:'''

This component would provide a set of highly configurable 'actions' which the user would see up via a wizard.

So they would initially define when the action applies, based on things like regex matching on request elements. And they should be able to define multiple criteria with ANDs and ORs.

Then they would define the actions, which could include:
* Changing the request (adding, removing or replacing strings)
* Raising alerts
* Breaking (to replace existing break points)
* Running custom scripts (which could do pretty much anything)
They would then be able to switch the actions on and off from the full list of defined actions using checkboxes

'''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:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 003 - Extend Web API to cover all of the ZAP functionality ====

'''Brief explanation:'''

ZAP provides a REST based API which can be used to control core aspects of the functionality provided by ZAP.

This project would extend that API to cover all/most of the ZAP functionality.

'''Expected results:''' Comprehensive Web API that will cover all of the ZAP Proxy functionality.

'''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:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 004 - Closer integration with OWASP AJAX ====

'''Brief explanation:'''

ZAP provides a basic spider that can be used to explore an application, however it is very limited, especially when used with AJAX based applications.

The OWASP AJAX crawling tool (https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool) is specifically designed to crawl AJAX applications and can already use ZAP as a proxy.

This project would develop a ZAP plugin which integrates ZAP with the OWASP AJAX crawling Tool.

'''Expected results:'''

A new ZAP plugin would be produced which allows ZAP to crawl AJAX applications using the OWASP AJAX crawling tool.

The plugin would allow the 2 tools to be tightly integrated, while still allowing them to work completely independently.

'''Knowledge Prerequisite:'''

Both ZAP and the AJAX tool are written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

'''Mentor:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP AJAX Tool Project Leader

=== ESAPI Swingset Interactive ===

The ESAPI Swingset Interactive is a web application which demonstrates common security vulnerabilities and asks users to secure the application against these vulnerabilities using the ESAPI library. The application is intended for Java Developers. The goal of the application is to teach developers about the functionality of the ESAPI library and give users a practical understanding of how it can be used to protect web applications against common security vulnerabilities.

'''Website:''' https://www.owasp.org/index.php/Projects/OWASP_ESAPI_Swingset_Interactive_Project

'''Mailing List:''' http://lists.owasp.org/pipermail/owasp-esapi-swingset/

====Project 001 - Implement a solid Authenticator class ====

'''Brief explanation:'''

Provide Swingset Interactive with a simple but fully functional implementation of the ESAPI Authenticator Interface.

'''Expected results:'''

Swingset Interactive comes with a rudimentary implementation of the ESAPI Authenticator Interface, a FileBasedAuthenticator. This implementation needs to be fixed or replaced in order to allow users of the Swingset Interactive application all of the ESAPI Authenticator methods, including registration, login, a "remember me" feature and a persistence beyond server restart.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 002 - Upgrade to ESAPI 2.0.x ====

'''Brief explanation:'''

Adapt Swingset Interactive to work with ESAPI 2.0.x. libraries.

'''Expected results:'''

Make the current Swingset Interactive application compatible with ESAPI 2.0.x. Swingset Interactive currently comes with ESAPI 1.4.Various changes and improvements were made with ESAPI 2.0.x and it is generally recommended not to use 1.4 any more for Java EE Projects.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 003 - Improve the Swingset look and feel ====

'''Brief explanation:'''

Various minor bug fixes and improvements.

'''Expected results:'''

Fix and solve a number of documented bug fixes and improvement suggestions for the Swingset Interactive and bring in your own improvement suggestions.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 004 - Platform-independent Swingset Interactive ====

'''Brief explanation:'''

Adapt Swingset Interactive to work with any OS.

'''Expected results:'''

Swingset Interactive currently runs only under Windows. Modify the Eclipse project and installation scripts to be easily installed on any OS that runs Eclipse.

'''Knowledge Prerequisite:'''

Good knowledge of Java, Apache Tomcat and a broad knowledge of various Operating Systems are required.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 005 - Mavenize the Swingset ====

'''Brief explanation:'''

Create a new Swingset Interactive Maven Archetype.

'''Expected results:'''

Offer the Swingset Interactive as a Maven Archetype.

'''Knowledge Prerequisite:'''

Good knowledge of Java, and Maven are required.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

=== AntiSamy ===

The AntiSamy project provides a Java library for developers to accept innocent HTML markup without exposing themselves to possible cross-site scripting (XSS) vulnerabilities.

'''Website:''' https://www.owasp.org/index.php/AntiSamy

'''Mailing List:''' https://lists.owasp.org/mailman/listinfo/owasp-antisamy

====Project 001 - Add a Functional Testing Suite ====

'''Brief explanation:'''

Create a set of positive test cases designed to generate assurance that AntiSamy correctly processes inert HTML.

'''Expected results:'''

As of today, AntiSamy has a large set of test cases that prove that AntiSamy is resistant to a number of known attacks. There are also test cases that make sure it doesn't crash when given bad data. There are very few test cases that ensure that it properly handles good HTML. A set of test cases that confirm how expected good data is processed by AntiSamy generates a lot of assurance that it is functional as well as secure.

'''Knowledge Prerequisite:'''

Comfort with Java, Maven, SVN and JUnit are required.

'''Mentor:''' Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

====Project 002 - Various Bug Fixes ====

'''Brief explanation:'''

There are around 30 open defects from the issue tracker.

'''Expected results:'''

A set of patches that address defects or implement features from the accepted issues in the issue tracker.

'''Knowledge Prerequisite:'''

Comfort with Java, Maven, SVN and JUnit are required.

'''Mentor:''' Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

=== AppSensor ===

==== Project 001 - SOAP web service server implementation ====

'''Brief explanation:'''

AppSensor is implementing a new service based architecture for the next version. This project would involve implementing a SOAP based web service (based on the WS-I Basic Profile standard) as a front-end to the AppSensor processing engine.

'''Expected results:'''

A new SOAP based web service would be produced which provides a front-end to the existing processing core built into AppSensor.

'''Knowledge Prerequisite:'''

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, some knowledge of SOAP-based web services (particularly the WS-I Basic Profile standard) would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.

'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 002 - REST web service server implementation ====

'''Brief explanation:'''

AppSensor is implementing a new service based architecture for the next version. This project would involve implementing a REST based web service as a front-end to the AppSensor processing engine.

'''Expected results:'''

A new REST based web service would be produced which provides a front-end to the existing processing core built into AppSensor.

'''Knowledge Prerequisite:'''

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, some knowledge of REST-based web services would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.

'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 003 - SOAP/REST web service client implementation ====

'''Brief explanation:'''

AppSensor is implementing a new service based architecture for the next version. This project would involve implementing SOAP and REST based web service clients in various languages to communicate to a back-end server that represents the AppSensor core engine.

'''Expected results:'''

New SOAP and REST based web service clients would be produced which communicate to a back-end server that represents the AppSensor core engine.

'''Knowledge Prerequisite:'''

AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Proficiency in one or more of the following languages would also be beneficial: C#, PHP, Python, Ruby. Additionally, some knowledge of REST and SOAP based web services would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.

'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 004 - Detection Point Implementation Expansion ====

'''Brief explanation:'''

AppSensor has documentation outlining around 50 different detection points. We currently have an existing implementation that supports a small handful (5-7) of those. Implementing additional detection points would increase the value of the project.

'''Expected results:'''

Implementations of existing detection points would be produced. This could be done in any number of languages.

'''Knowledge Prerequisite:'''

AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Proficiency in one or more of the following languages would also be beneficial: C#, PHP, Python, Ruby. Finally, basic knowledge of application security would be very helpful.

'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 005 - Implement new configuration file format ====

'''Brief explanation:'''

AppSensor currently uses a properties file format for configuration. A new XML file format is planned. Moving to an XML format would simplify the configuration and make it easier to extend.

'''Expected results:'''

A new implementation of the configuration file would be created. An XML file format would be created, along with the code to process that file format, as well as an XSD to validate the file.

'''Knowledge Prerequisite:'''

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, a basic understanding of XML and XSD would be useful, though not required.

'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 006 - Trend Monitoring ====

'''Brief explanation:'''

Several of the detection point concepts for AppSensor revolve around the idea of trend monitoring within an application. There is a trivial implementation currently that provides very little utility. An enhanced trend monitoring capability would allow for the implementation of more detection points and expand the capabilities of AppSensor.

'''Expected results:'''

A new implementation of the trend monitoring module would be implemented.

'''Knowledge Prerequisite:'''

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, basic knowledge of application security would be very helpful.

'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 007 - Reporting ====

'''Brief explanation:'''

AppSensor currently has very weak reporting capabilities. Enhanced reporting would provide users with better insight into the health of the applications being protected by AppSensor

'''Expected results:'''

New APIs for reporting would be implemented as SOAP and/or REST based web services. Additionally, a reference implementation of a reporting client UI would be developed.

'''Knowledge Prerequisite:'''

AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Some knowledge of REST and SOAP based web services would also be useful, but not essential. Additionally, some experience in a modern UI development framework would be beneficial, presumably an RIA style framework. Finally, basic knowledge of application security would be very helpful.

'''Mentor:''' John Melton - OWASP AppSensor Development Leader

GSoC2012 Ideas

2012-03-04T05:52:33Z

John Melton: adding appsensor ideas

==Guidelines==
===Information for Students===
The ideas below were contributed by OWASP project leaders and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the corresponding project leaders and find out more about the particular suggestion you're looking at.
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

===Adding a Proposal===

'''Project:'''

'''Brief explanation:'''

'''Expected results:'''

'''Knowledge Prerequisite:'''

'''Mentor:'''

'''Ideas'''
How to find ideas? Obvious sources of projects are the OWASP project wiki, bugs database, and project mailing lists.

=== Generic Sample Proposal===

'''Accepted for GSoC 2011'''

'''Brief explanation:'''

KDE has developed a number of very interesting and powerful technologies, libraries and components but there is no easy way to show them to other people.

'''Expected results:'''

Something like Qt Demo but with KDE technologies.

'''Knowledge prerequisite:'''

C++ is the main language of KDE, therefore the demo should be in C++. The more you know about C++, Qt, KDE and scripting (for Kross and KDE bindings demos), the better.
This idea encompasses so much different stuff the student is not expected to know everything before he starts coding (but will certainly know a lot when he's done!).

'''Skill level:''' medium

'''Mentor:''' Pau Garcia i Quiles as general mentor and someone to ask for directions. Specific help for each technology will probably require help from its developers.

==OWASP Project Requests==

=== ZAP Proxy ===

The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

'''Website:''' https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

'''Mailing List:''' http://groups.google.com/group/zaproxy-develop

====Project 001 - Compare crawling sessions for authentication issues ====

'''Brief explanation:''' Develop a ZAP session crawler to be able to compare two crawling sessions of two logged in users and see what URLs or Actions could be performed from the other session.

'''Expected results:'''

ZAP will be able to recognise when requests are associated with different sessions.

ZAP should allow the user to view the crawled URLs for each session independantly, and show which URLs are unique to each session.

It should also be able to check if any of the 'unique' pages can in fact be accessed by the other session.

'''Knowledge Prerequisite:'''

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

'''Mentors:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 002 - Dynamically Configurable actions ====

'''Brief explanation:'''

ZAP provides various mechanisms which allow HTTP requests and responses to be changed dynamically. So (for example) a string in an HTTP request can automatically be changed to another string.

It also supports a scripting interface, which is very powerful but at the moment difficult to use.

This project would introduce something inbetween thess 2 options - a powerful way of defining (potentially) complex rules using a wizard based interface.

The challenge will be to make it as usable as possible while still providing a wide range of functionality.

'''Expected results:'''

This component would provide a set of highly configurable 'actions' which the user would see up via a wizard.

So they would initially define when the action applies, based on things like regex matching on request elements. And they should be able to define multiple criteria with ANDs and ORs.

Then they would define the actions, which could include:
* Changing the request (adding, removing or replacing strings)
* Raising alerts
* Breaking (to replace existing break points)
* Running custom scripts (which could do pretty much anything)
They would then be able to switch the actions on and off from the full list of defined actions using checkboxes

'''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:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 003 - Extend Web API to cover all of the ZAP functionality ====

'''Brief explanation:'''

ZAP provides a REST based API which can be used to control core aspects of the functionality provided by ZAP.

This project would extend that API to cover all/most of the ZAP functionality.

'''Expected results:''' Comprehensive Web API that will cover all of the ZAP Proxy functionality.

'''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:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

====Project 004 - Closer integration with OWASP AJAX ====

'''Brief explanation:'''

ZAP provides a basic spider that can be used to explore an application, however it is very limited, especially when used with AJAX based applications.

The OWASP AJAX crawling tool (https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool) is specifically designed to crawl AJAX applications and can already use ZAP as a proxy.

This project would develop a ZAP plugin which integrates ZAP with the OWASP AJAX crawling Tool.

'''Expected results:'''

A new ZAP plugin would be produced which allows ZAP to crawl AJAX applications using the OWASP AJAX crawling tool.

The plugin would allow the 2 tools to be tightly integrated, while still allowing them to work completely independently.

'''Knowledge Prerequisite:'''

Both ZAP and the AJAX tool are written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

'''Mentor:''' Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP AJAX Tool Project Leader

=== ESAPI Swingset Interactive ===

The ESAPI Swingset Interactive is a web application which demonstrates common security vulnerabilities and asks users to secure the application against these vulnerabilities using the ESAPI library. The application is intended for Java Developers. The goal of the application is to teach developers about the functionality of the ESAPI library and give users a practical understanding of how it can be used to protect web applications against common security vulnerabilities.

'''Website:''' https://www.owasp.org/index.php/Projects/OWASP_ESAPI_Swingset_Interactive_Project

'''Mailing List:''' http://lists.owasp.org/pipermail/owasp-esapi-swingset/

====Project 001 - Implement a solid Authenticator class ====

'''Brief explanation:'''

Provide Swingset Interactive with a simple but fully functional implementation of the ESAPI Authenticator Interface.

'''Expected results:'''

Swingset Interactive comes with a rudimentary implementation of the ESAPI Authenticator Interface, a FileBasedAuthenticator. This implementation needs to be fixed or replaced in order to allow users of the Swingset Interactive application all of the ESAPI Authenticator methods, including registration, login, a "remember me" feature and a persistence beyond server restart.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 002 - Upgrade to ESAPI 2.0.x ====

'''Brief explanation:'''

Adapt Swingset Interactive to work with ESAPI 2.0.x. libraries.

'''Expected results:'''

Make the current Swingset Interactive application compatible with ESAPI 2.0.x. Swingset Interactive currently comes with ESAPI 1.4.Various changes and improvements were made with ESAPI 2.0.x and it is generally recommended not to use 1.4 any more for Java EE Projects.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 003 - Improve the Swingset look and feel ====

'''Brief explanation:'''

Various minor bug fixes and improvements.

'''Expected results:'''

Fix and solve a number of documented bug fixes and improvement suggestions for the Swingset Interactive and bring in your own improvement suggestions.

'''Knowledge Prerequisite:'''

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 004 - Platform-independent Swingset Interactive ====

'''Brief explanation:'''

Adapt Swingset Interactive to work with any OS.

'''Expected results:'''

Swingset Interactive currently runs only under Windows. Modify the Eclipse project and installation scripts to be easily installed on any OS that runs Eclipse.

'''Knowledge Prerequisite:'''

Good knowledge of Java, Apache Tomcat and a broad knowledge of various Operating Systems are required.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

====Project 005 - Mavenize the Swingset ====

'''Brief explanation:'''

Create a new Swingset Interactive Maven Archetype.

'''Expected results:'''

Offer the Swingset Interactive as a Maven Archetype.

'''Knowledge Prerequisite:'''

Good knowledge of Java, and Maven are required.

'''Mentor:''' Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

=== AntiSamy ===

The AntiSamy project provides a Java library for developers to accept innocent HTML markup without exposing themselves to possible cross-site scripting (XSS) vulnerabilities.

'''Website:''' https://www.owasp.org/index.php/AntiSamy

'''Mailing List:''' https://lists.owasp.org/mailman/listinfo/owasp-antisamy

====Project 001 - Add a Functional Testing Suite ====

'''Brief explanation:'''

Create a set of positive test cases designed to generate assurance that AntiSamy correctly processes inert HTML.

'''Expected results:'''

As of today, AntiSamy has a large set of test cases that prove that AntiSamy is resistant to a number of known attacks. There are also test cases that make sure it doesn't crash when given bad data. There are very few test cases that ensure that it properly handles good HTML. A set of test cases that confirm how expected good data is processed by AntiSamy generates a lot of assurance that it is functional as well as secure.

'''Knowledge Prerequisite:'''

Comfort with Java, Maven, SVN and JUnit are required.

'''Mentor:''' Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

====Project 002 - Various Bug Fixes ====

'''Brief explanation:'''

There are around 30 open defects from the issue tracker.

'''Expected results:'''

A set of patches that address defects or implement features from the accepted issues in the issue tracker.

'''Knowledge Prerequisite:'''

Comfort with Java, Maven, SVN and JUnit are required.

'''Mentor:''' Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

=== AppSensor ===

==== Project 001 - SOAP web service server implementation ====
'''Brief explanation:'''
AppSensor is implementing a new service based architecture for the next version. This project would involve implementing a SOAP based web service (based on the WS-I Basic Profile standard) as a front-end to the AppSensor processing engine.
'''Expected results:'''
A new SOAP based web service would be produced which provides a front-end to the existing processing core built into AppSensor.
'''Knowledge Prerequisite:'''
AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, some knowledge of SOAP-based web services (particularly the WS-I Basic Profile standard) would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.
'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 002 - REST web service server implementation ====
'''Brief explanation:'''
AppSensor is implementing a new service based architecture for the next version. This project would involve implementing a REST based web service as a front-end to the AppSensor processing engine.
'''Expected results:'''
A new REST based web service would be produced which provides a front-end to the existing processing core built into AppSensor.
'''Knowledge Prerequisite:'''
AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, some knowledge of REST-based web services would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.
'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 003 - SOAP/REST web service client implementation ====
'''Brief explanation:'''
AppSensor is implementing a new service based architecture for the next version. This project would involve implementing SOAP and REST based web service clients in various languages to communicate to a back-end server that represents the AppSensor core engine.
'''Expected results:'''
New SOAP and REST based web service clients would be produced which communicate to a back-end server that represents the AppSensor core engine.
'''Knowledge Prerequisite:'''
AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Proficiency in one or more of the following languages would also be beneficial: C#, PHP, Python, Ruby. Additionally, some knowledge of REST and SOAP based web services would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.
'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 004 - Detection Point Implementation Expansion ====
'''Brief explanation:'''
AppSensor has documentation outlining around 50 different detection points. We currently have an existing implementation that supports a small handful (5-7) of those. Implementing additional detection points would increase the value of the project.
'''Expected results:'''
Implementations of existing detection points would be produced. This could be done in any number of languages.
'''Knowledge Prerequisite:'''
AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Proficiency in one or more of the following languages would also be beneficial: C#, PHP, Python, Ruby. Finally, basic knowledge of application security would be very helpful.
'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 005 - Implement new configuration file format ====
'''Brief explanation:'''
AppSensor currently uses a properties file format for configuration. A new XML file format is planned. Moving to an XML format would simplify the configuration and make it easier to extend.
'''Expected results:'''
A new implementation of the configuration file would be created. An XML file format would be created, along with the code to process that file format, as well as an XSD to validate the file.
'''Knowledge Prerequisite:'''
AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, a basic understanding of XML and XSD would be useful, though not required.
'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 006 - Trend Monitoring ====
'''Brief explanation:'''
Several of the detection point concepts for AppSensor revolve around the idea of trend monitoring within an application. There is a trivial implementation currently that provides very little utility. An enhanced trend monitoring capability would allow for the implementation of more detection points and expand the capabilities of AppSensor.
'''Expected results:'''
A new implementation of the trend monitoring module would be implemented.
'''Knowledge Prerequisite:'''
AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, basic knowledge of application security would be very helpful.
'''Mentor:''' John Melton - OWASP AppSensor Development Leader

==== Project 007 - Reporting ====
'''Brief explanation:'''
AppSensor currently has very weak reporting capabilities. Enhanced reporting would provide users with better insight into the health of the applications being protected by AppSensor
'''Expected results:'''
New APIs for reporting would be implemented as SOAP and/or REST based web services. Additionally, a reference implementation of a reporting client UI would be developed.
'''Knowledge Prerequisite:'''
AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Some knowledge of REST and SOAP based web services would also be useful, but not essential. Additionally, some experience in a modern UI development framework would be beneficial, presumably an RIA style framework. Finally, basic knowledge of application security would be very helpful.
'''Mentor:''' John Melton - OWASP AppSensor Development Leader

AppSensor Developer Guide

2010-10-19T05:16:45Z

John Melton: Removed one step from the maven process (adding ESAPI to local repo) now that ESAPI is hosted in the central repo.

= AppSensor Developer Guide =

The [[:Category:OWASP AppSensor Project|AppSensor Project]] describes an application layer intrusion detection system. There is a Java implementation of this system whose basic usage can be found in the [[AppSensor_GettingStarted|Getting Started]] guide. This document describes in more technical detail for developers how to use and extend AppSensor for a specific environment and application.

== Developer Overview ==
AppSensor is an application layer intrusion detection system. The concept in implementation is roughly analogous to an intrusion detection (and prevention) system in the network security world. However, this concept can be applied inside of an application in a more specific way that (importantly) reduces false positives, which is an issue that often plagues network intrusion detection systems. This means that the core of the AppSensor system performs detection, monitoring, and (possibly) response depending on configuration settings.

AppSensor has been built to be quite extensible from the ground up. Most of the system can be appreciably modified to your needs by simply extending certain key interfaces, and modifying the appsensor configuration file appropriately. This extensible design makes it possible for various configurations to be applied depending upon the application. For instance, in a small application, you may choose to use a simple file-based model for storing intrusions that are detected, whereas for a larger application, you may have a relational database serving as your data store. See the '''Extending AppSensor''' section below for specifics on what can be extended.

A fuller description of the [http://www.owasp.org/index.php/AppSensor_DetectionPoints detection points] and [http://www.owasp.org/index.php/AppSensor_ResponseActions responses] are available - note that not all of these ideas are implemented here. The selection of detection points, where they are added, and how the application responds is application and organisation dependent.

== Obtaining AppSensor ==
The appsensor.jar can be downloaded here - [http://repo2.maven.org/maven2/org/owasp/appsensor/AppSensor/0.1.3/AppSensor-0.1.3.jar AppSensor-0.1.3.jar]

The source is available [http://code.google.com/p/appsensor/source/browse/#svn/trunk/AppSensor%3Fstate%3Dclosed here]

== Extending AppSensor ==
Below you will find the individual interfaces you are likely to extend in order to modify AppSensor for your environment.
----

==== IntrusionStore ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/IntrusionStore.java IntrusionStore] interface represents, simply enough, the storage mechanism for any intrusions that occur in the system. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector] takes care of adding the intrusions to the intrusion store. The current [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultIntrusionStore.java DefaultIntrusionStore] class stores all of the intrusions in a simple HashMap. The class is fairly small and simple, though, so it is trivial to understand it's inner workings and to use similar concepts to build an implementation that suits your environment.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the intrusion store
AppSensor.intrusionStore=org.owasp.appsensor.intrusiondetection.reference.DefaultIntrusionStore
</pre>
----

==== ResponseAction ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/ResponseAction.java ResponseAction] interface is used to simply respond to an intrusion once a threshold has been crossed. The decision for when to respond is handled by the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector], but the actual handling of the response is delegated to implementations of this interface. The only reason to not use the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] would be if you have additional response actions you need to take, or if you need to modify the handling of one of the existing responses. Again, the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] should give you a good starting point for creating your own implementation.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the response actions
AppSensor.responseAction=org.owasp.appsensor.intrusiondetection.reference.DefaultResponseAction
</pre>

[http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] supports the following actions:
<ul>
<li>"log" - logs the activity</li>
<li>"logout" - logs the currently logged in user out (if one exists)</li>
<li>"disable" - disables the account of the currently logged in user (if one exists)</li>
<li>"disableComponent" - disables access to the location of the intrusion using the AppSensorServiceController</li>
<li>"disableComponentForUser" - disables access to the location of the intrusion using the AppSensorServiceController for the currently logged in user(if one exists)</li>
<li>"emailAdmin" - Email administrator to notify of what action has occurred</li>
<li>"smsAdmin" - SMS administrator (via email to sms account) to notify of what action has occurred</li>
</ul>

<pre>
Response actions can be configured for individual detection points using properties like: IntrusionDetector.<detection point>.actions=

# list of actions you want executed in the specified order as the threshold for this intrusion is met -
# ie. log the first time, logout the user the second time, etc.
IntrusionDetector.IE99.actions=log,logout,disable,disableComponent
</pre>

----

==== ASUtilities ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/ASUtilities.java ASUtilities] interface handles a collection of concerns. It handles retrieving the current user of the application (ie. the user that made the current request and/or caused the current intrusion). In addition, it handles the retrieval of the logger as well as the current HTTP request. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/reference/DefaultASUtilities.java DefaultASUtilities] implementation simply delegates to the equivalent ESAPI method calls to retrieve the appropriate data. If you are not using ESAPI's logging and/or authentication and/or request binding utilities, you'll need to create your own implementation of this class. ''' ''Note: This is the interface you'll need to implement if you are not using ESAPI.'' '''

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the utility retriever
AppSensor.asUtilities=org.owasp.appsensor.reference.DefaultASUtilities
</pre>
----

==== TrendLogger ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/TrendLogger.java TrendLogger] interface is in place to handle the logging of events in order to monitor trends. The techniques for doing this vary widely depending upon environment. You'll most likely not want to use the existing [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/reference/InMemoryTrendLogger.java InMemoryTrendLogger] as it will scale very poorly. It is simply in place as a starting point for other implementations.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the trend logging
AppSensor.trendLogger=org.owasp.appsensor.trendmonitoring.reference.InMemoryTrendLogger
</pre>
----

== Adding AppSensor to your project ==

==== Dependencies ====
AppSensor has the following dependencies:
*OWASP ESAPI Java library
*JavaMail libraries (activation and mail jar files)
*Servlet/JSP libraries
*Logging API library (log4j by default)
----
==== With Maven ====
If you use maven as the build system for your application, then adding AppSensor to your project is very simple and requires 4 basic steps.
# Add the following configuration into the '''dependencies''' section of your POM:
#:<pre>
#:<dependency>
#: <groupId>org.owasp.appsensor</groupId>
#: <artifactId>AppSensor</artifactId>
#: <version>PUT_YOUR_VERSION_HERE</version>
#:</dependency>
#:</pre>
# Add the '''.esapi''' folder to your project in a location that ESAPI can find it. The easiest way to do this is to add the folder under the root of your '''src''' folder. Additionally, you will need to place 3 files in the .esapi folder:
#* ESAPI.properties
#* validation.properties
#* appsensor.properties
# Modify the following line in the ESAPI.properties file:
#:<pre>ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector</pre>
#:The line above should be changed to:
#:<pre>ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector</pre>
# Customize the configuration files listed above (those in the .esapi folder) to suit your own project.
# '''TODO:''' Add example appsensor configuration or examples
At this point you should have the project configured to work properly.
----

==== Without Maven ====
If you use some mechanism other than maven as the build system for your application, then adding AppSensor requires downloading and adding all required libraries to your project manually in addition to the other basic steps, and this process is outlined below:
# Download the libraries described as dependencies above, and add them to your project (likely in the '''WEB-INF/lib''' folder of your application).
# Add the '''.esapi''' folder to your project in a location that ESAPI can find it. The easiest way to do this is to add the folder under the root of your '''src''' folder. Additionally, you will need to place 3 files in the .esapi folder:
#* ESAPI.properties
#* validation.properties
#* appsensor.properties
# Modify the following line in the ESAPI.properties file:
#:<pre>ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector</pre>
#:The line above should be changed to
#:<pre>ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector</pre>
# Customize the configuration files listed above (those in the .esapi folder) to suit your own project.
At this point you should have the project configured to work properly.
----
== Using AppSensor in your project ==
Once your project is properly configured to use AppSensor, using AppSensor is very simple. It takes only 2 basic steps: '''Intrusion Detection Code''' and '''Intrusion Threshold Configuration'''.

----
==== Intrusion Detection Code ====
Here are a couple of very simple examples.

The following example involves creating an AppSensorException by hand in your application:
<pre>
//This example snippet might be placed on a jsp that handles HTTP 404 errors.
//When the page is accessed, this code notifies AppSensor that an invalid page request was made.
//Notice that the exception is created, not thrown

new AppSensorException("ACE3", "Invalid request", "Attacker is requesting a non-existent (404) page (" + requestedURI + ")");
</pre>

The following example relies on the AttackDetectorUtils class to create the exception. This class contains various methods that handle common detection points.
<pre>
//This example snippet might be placed in request handling code that expects a form POST to occur (not a GET, not a PUT, etc).
//This code notifies AppSensor that an type of HTTP request was made.

AttackDetectorUtils.verifyValidRequestMethod(request, AttackDetectorUtils.POST);
</pre>
----

==== Intrusion Threshold Configuration ====
Here the salient points to note are that the configuration can vary depending on what response actions are desired as well as what threshold is required. Additionally, you have control over these settings and can tune them to produce the desired effect. These configurations can be set in the appsensor.properties file in your .esapi folder. ''Note: While these threshold configurations can be set in the ESAPI.properties in the .esapi folder, it is not recommended for AppSensor so that the configuration can be kept together in one place. Also note some thresholds may already be configured for subclasses of ESAPI's EnterpriseSecurityException in the ESAPI.properties file - please be aware of that when setting up the configuration for your application.''

Below are two sample threshold configurations for two separate detection points.

<pre>
# http://www.owasp.org/index.php/AppSensor_DetectionPoints#ACE2:_Modifying_Parameters_Within_A_POST_For_Direct_Object_Access_Attempts
# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.ACE2.count=3
# segment of time (in seconds)
IntrusionDetector.ACE2.interval=3
# list of actions you want executed in the specified order as the threshold for this intrusion is met - ie. log the first time, logout the user the second time, etc.
IntrusionDetector.ACE2.actions=log,logout,disable,disableComponent
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponent.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponent.timeScale=m
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponentForUser.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponentForUser.timeScale=m
</pre>

<pre>
# http://www.owasp.org/index.php/AppSensor_DetectionPoints#RE3:_GET_When_Expecting_POST
# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.RE3.count=3
# segment of time (in seconds)
IntrusionDetector.RE3.interval=300
# list of actions you want executed in the specified order as the threshold for this intrusion is met - ie. log the first time, logout the user the second time, etc.
IntrusionDetector.RE3.actions=log,logout,disable
</pre>
----

This document shows that AppSensor is very simple to configure as well as to use. Once setup, you simply add detection points to your code and add and/or modify the appropriate configuration information in the ESAPI.properties and appsensor.properties files in order to let AppSensor know your appropriate thresholds for each detection point. That's it!

AppSensor Developer Guide

2010-10-19T05:14:50Z

John Melton: fixing appsensor version - adding link to latest

= AppSensor Developer Guide =

The [[:Category:OWASP AppSensor Project|AppSensor Project]] describes an application layer intrusion detection system. There is a Java implementation of this system whose basic usage can be found in the [[AppSensor_GettingStarted|Getting Started]] guide. This document describes in more technical detail for developers how to use and extend AppSensor for a specific environment and application.

== Developer Overview ==
AppSensor is an application layer intrusion detection system. The concept in implementation is roughly analogous to an intrusion detection (and prevention) system in the network security world. However, this concept can be applied inside of an application in a more specific way that (importantly) reduces false positives, which is an issue that often plagues network intrusion detection systems. This means that the core of the AppSensor system performs detection, monitoring, and (possibly) response depending on configuration settings.

AppSensor has been built to be quite extensible from the ground up. Most of the system can be appreciably modified to your needs by simply extending certain key interfaces, and modifying the appsensor configuration file appropriately. This extensible design makes it possible for various configurations to be applied depending upon the application. For instance, in a small application, you may choose to use a simple file-based model for storing intrusions that are detected, whereas for a larger application, you may have a relational database serving as your data store. See the '''Extending AppSensor''' section below for specifics on what can be extended.

A fuller description of the [http://www.owasp.org/index.php/AppSensor_DetectionPoints detection points] and [http://www.owasp.org/index.php/AppSensor_ResponseActions responses] are available - note that not all of these ideas are implemented here. The selection of detection points, where they are added, and how the application responds is application and organisation dependent.

== Obtaining AppSensor ==
The appsensor.jar can be downloaded here - [http://repo2.maven.org/maven2/org/owasp/appsensor/AppSensor/0.1.3/AppSensor-0.1.3.jar AppSensor-0.1.3.jar]

The source is available [http://code.google.com/p/appsensor/source/browse/#svn/trunk/AppSensor%3Fstate%3Dclosed here]

== Extending AppSensor ==
Below you will find the individual interfaces you are likely to extend in order to modify AppSensor for your environment.
----

==== IntrusionStore ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/IntrusionStore.java IntrusionStore] interface represents, simply enough, the storage mechanism for any intrusions that occur in the system. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector] takes care of adding the intrusions to the intrusion store. The current [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultIntrusionStore.java DefaultIntrusionStore] class stores all of the intrusions in a simple HashMap. The class is fairly small and simple, though, so it is trivial to understand it's inner workings and to use similar concepts to build an implementation that suits your environment.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the intrusion store
AppSensor.intrusionStore=org.owasp.appsensor.intrusiondetection.reference.DefaultIntrusionStore
</pre>
----

==== ResponseAction ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/ResponseAction.java ResponseAction] interface is used to simply respond to an intrusion once a threshold has been crossed. The decision for when to respond is handled by the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/AppSensorIntrusionDetector.java AppSensorIntrusionDetector], but the actual handling of the response is delegated to implementations of this interface. The only reason to not use the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] would be if you have additional response actions you need to take, or if you need to modify the handling of one of the existing responses. Again, the [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] should give you a good starting point for creating your own implementation.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the response actions
AppSensor.responseAction=org.owasp.appsensor.intrusiondetection.reference.DefaultResponseAction
</pre>

[http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/intrusiondetection/reference/DefaultResponseAction.java DefaultResponseAction] supports the following actions:
<ul>
<li>"log" - logs the activity</li>
<li>"logout" - logs the currently logged in user out (if one exists)</li>
<li>"disable" - disables the account of the currently logged in user (if one exists)</li>
<li>"disableComponent" - disables access to the location of the intrusion using the AppSensorServiceController</li>
<li>"disableComponentForUser" - disables access to the location of the intrusion using the AppSensorServiceController for the currently logged in user(if one exists)</li>
<li>"emailAdmin" - Email administrator to notify of what action has occurred</li>
<li>"smsAdmin" - SMS administrator (via email to sms account) to notify of what action has occurred</li>
</ul>

<pre>
Response actions can be configured for individual detection points using properties like: IntrusionDetector.<detection point>.actions=

# list of actions you want executed in the specified order as the threshold for this intrusion is met -
# ie. log the first time, logout the user the second time, etc.
IntrusionDetector.IE99.actions=log,logout,disable,disableComponent
</pre>

----

==== ASUtilities ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/ASUtilities.java ASUtilities] interface handles a collection of concerns. It handles retrieving the current user of the application (ie. the user that made the current request and/or caused the current intrusion). In addition, it handles the retrieval of the logger as well as the current HTTP request. The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/reference/DefaultASUtilities.java DefaultASUtilities] implementation simply delegates to the equivalent ESAPI method calls to retrieve the appropriate data. If you are not using ESAPI's logging and/or authentication and/or request binding utilities, you'll need to create your own implementation of this class. ''' ''Note: This is the interface you'll need to implement if you are not using ESAPI.'' '''

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the utility retriever
AppSensor.asUtilities=org.owasp.appsensor.reference.DefaultASUtilities
</pre>
----

==== TrendLogger ====
The [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/TrendLogger.java TrendLogger] interface is in place to handle the logging of events in order to monitor trends. The techniques for doing this vary widely depending upon environment. You'll most likely not want to use the existing [http://code.google.com/p/appsensor/source/browse/trunk/AppSensor/src/main/java/org/owasp/appsensor/trendmonitoring/reference/InMemoryTrendLogger.java InMemoryTrendLogger] as it will scale very poorly. It is simply in place as a starting point for other implementations.

<pre>
The setting you'll need to modify in appsensor.properties to enable your own implementation is:

# This is the class that handles the trend logging
AppSensor.trendLogger=org.owasp.appsensor.trendmonitoring.reference.InMemoryTrendLogger
</pre>
----

== Adding AppSensor to your project ==

==== Dependencies ====
AppSensor has the following dependencies:
*OWASP ESAPI Java library
*JavaMail libraries (activation and mail jar files)
*Servlet/JSP libraries
*Logging API library (log4j by default)
----
==== With Maven ====
If you use maven as the build system for your application, then adding AppSensor to your project is very simple and requires 4 basic steps.
# Add the following configuration into the '''dependencies''' section of your POM:
#:<pre>
#:<dependency>
#: <groupId>org.owasp.appsensor</groupId>
#: <artifactId>AppSensor</artifactId>
#: <version>PUT_YOUR_VERSION_HERE</version>
#:</dependency>
#:</pre>
# Add the ESAPI jar into your local maven repository manually using the '''mvn install''' command. This will add ESAPI to the project. ''Note: This process will change in the future once ESAPI is fully setup in the central maven repository. At that time, AppSensor's POM will add ESAPI as a dependency, and this step will go away.''
# Add the '''.esapi''' folder to your project in a location that ESAPI can find it. The easiest way to do this is to add the folder under the root of your '''src''' folder. Additionally, you will need to place 3 files in the .esapi folder:
#* ESAPI.properties
#* validation.properties
#* appsensor.properties
# Modify the following line in the ESAPI.properties file:
#:<pre>ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector</pre>
#:The line above should be changed to:
#:<pre>ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector</pre>
# Customize the configuration files listed above (those in the .esapi folder) to suit your own project.
# '''TODO:''' Add example appsensor configuration or examples
At this point you should have the project configured to work properly.
----

==== Without Maven ====
If you use some mechanism other than maven as the build system for your application, then adding AppSensor requires downloading and adding all required libraries to your project manually in addition to the other basic steps, and this process is outlined below:
# Download the libraries described as dependencies above, and add them to your project (likely in the '''WEB-INF/lib''' folder of your application).
# Add the '''.esapi''' folder to your project in a location that ESAPI can find it. The easiest way to do this is to add the folder under the root of your '''src''' folder. Additionally, you will need to place 3 files in the .esapi folder:
#* ESAPI.properties
#* validation.properties
#* appsensor.properties
# Modify the following line in the ESAPI.properties file:
#:<pre>ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector</pre>
#:The line above should be changed to
#:<pre>ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector</pre>
# Customize the configuration files listed above (those in the .esapi folder) to suit your own project.
At this point you should have the project configured to work properly.
----
== Using AppSensor in your project ==
Once your project is properly configured to use AppSensor, using AppSensor is very simple. It takes only 2 basic steps: '''Intrusion Detection Code''' and '''Intrusion Threshold Configuration'''.

----
==== Intrusion Detection Code ====
Here are a couple of very simple examples.

The following example involves creating an AppSensorException by hand in your application:
<pre>
//This example snippet might be placed on a jsp that handles HTTP 404 errors.
//When the page is accessed, this code notifies AppSensor that an invalid page request was made.
//Notice that the exception is created, not thrown

new AppSensorException("ACE3", "Invalid request", "Attacker is requesting a non-existent (404) page (" + requestedURI + ")");
</pre>

The following example relies on the AttackDetectorUtils class to create the exception. This class contains various methods that handle common detection points.
<pre>
//This example snippet might be placed in request handling code that expects a form POST to occur (not a GET, not a PUT, etc).
//This code notifies AppSensor that an type of HTTP request was made.

AttackDetectorUtils.verifyValidRequestMethod(request, AttackDetectorUtils.POST);
</pre>
----

==== Intrusion Threshold Configuration ====
Here the salient points to note are that the configuration can vary depending on what response actions are desired as well as what threshold is required. Additionally, you have control over these settings and can tune them to produce the desired effect. These configurations can be set in the appsensor.properties file in your .esapi folder. ''Note: While these threshold configurations can be set in the ESAPI.properties in the .esapi folder, it is not recommended for AppSensor so that the configuration can be kept together in one place. Also note some thresholds may already be configured for subclasses of ESAPI's EnterpriseSecurityException in the ESAPI.properties file - please be aware of that when setting up the configuration for your application.''

Below are two sample threshold configurations for two separate detection points.

<pre>
# http://www.owasp.org/index.php/AppSensor_DetectionPoints#ACE2:_Modifying_Parameters_Within_A_POST_For_Direct_Object_Access_Attempts
# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.ACE2.count=3
# segment of time (in seconds)
IntrusionDetector.ACE2.interval=3
# list of actions you want executed in the specified order as the threshold for this intrusion is met - ie. log the first time, logout the user the second time, etc.
IntrusionDetector.ACE2.actions=log,logout,disable,disableComponent
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponent.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponent.timeScale=m
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponentForUser.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponentForUser.timeScale=m
</pre>

<pre>
# http://www.owasp.org/index.php/AppSensor_DetectionPoints#RE3:_GET_When_Expecting_POST
# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.RE3.count=3
# segment of time (in seconds)
IntrusionDetector.RE3.interval=300
# list of actions you want executed in the specified order as the threshold for this intrusion is met - ie. log the first time, logout the user the second time, etc.
IntrusionDetector.RE3.actions=log,logout,disable
</pre>
----

This document shows that AppSensor is very simple to configure as well as to use. Once setup, you simply add detection points to your code and add and/or modify the appropriate configuration information in the ESAPI.properties and appsensor.properties files in order to let AppSensor know your appropriate thresholds for each detection point. That's it!

AppSensor GettingStarted

2010-06-25T19:32:43Z

John Melton:

= Getting Started with AppSensor=
The [[:Category:OWASP AppSensor Project|AppSensor Project]] describes an application layer intrusion detection system, both the concepts involved as well as offering a collection of helpful detection points to be implemented into your application. This document describes how to begin using the Java implementation of AppSensor as part of your application.

''Note: This document assumes you are planning to use ESAPI as your authentication/authorization system. This is absolutely NOT required by AppSensor, but there are reference implementations that come with AppSensor that make this usage simple and it works "out-of-the-box". If you choose to use some other mechanism to provide these functions, please also see the documentation regarding [[AppSensor_Developer_Guide|AppSensor Developer Guide]].''

== Adding AppSensor to your project ==

==== Dependencies ====
AppSensor has the following dependencies:
*OWASP ESAPI Java library
*JavaMail libraries (activation and mail jar files)
*Servlet/JSP libraries
*Logging API library (log4j by default)
----
==== With Maven ====
If you use maven as the build system for your application, then adding AppSensor to your project is very simple and requires 4 basic steps.
# Add the following configuration into the '''dependencies''' section of your POM:
#:<pre>
#:<dependency>
#: <groupId>org.owasp.appsensor</groupId>
#: <artifactId>AppSensor</artifactId>
#: <version>PUT_YOUR_VERSION_HERE</version>
#:</dependency>
#:</pre>
# Add the ESAPI jar into your local maven repository manually using the '''mvn install''' command. This will add ESAPI to the project. ''Note: This process will change in the future once ESAPI is fully setup in the central maven repository. At that time, AppSensor's POM will add ESAPI as a dependency, and this step will go away.''
# Add the '''.esapi''' folder to your project in a location that ESAPI can find it. The easiest way to do this is to add the folder under the root of your '''src''' folder. Additionally, you will need to place 3 files in the .esapi folder:
#* ESAPI.properties
#* validation.properties
#* appsensor.properties
# Modify the following line in the ESAPI.properties file:
#:<pre>ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector</pre>
#:The line above should be changed to:
#:<pre>ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector</pre>
# Customize the configuration files listed above (those in the .esapi folder) to suit your own project.
# '''TODO:''' Add example appsensor configuration or examples
At this point you should have the project configured to work properly.
----

==== Without Maven ====
If you use some mechanism other than maven as the build system for your application, then adding AppSensor requires downloading and adding all required libraries to your project manually in addition to the other basic steps, and this process is outlined below:
# Download the libraries described as dependencies above, and add them to your project (likely in the '''WEB-INF/lib''' folder of your application).
# Add the '''.esapi''' folder to your project in a location that ESAPI can find it. The easiest way to do this is to add the folder under the root of your '''src''' folder. Additionally, you will need to place 3 files in the .esapi folder:
#* ESAPI.properties
#* validation.properties
#* appsensor.properties
# Modify the following line in the ESAPI.properties file:
#:<pre>ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector</pre>
#:The line above should be changed to
#:<pre>ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector</pre>
# Customize the configuration files listed above (those in the .esapi folder) to suit your own project.
At this point you should have the project configured to work properly.
----
== Using AppSensor in your project ==
Once your project is properly configured to use AppSensor, using AppSensor is very simple. It takes only 2 basic steps: '''Intrusion Detection Code''' and '''Intrusion Threshold Configuration'''.

----
==== Intrusion Detection Code ====
Here are a couple of very simple examples.

The following example involves creating an AppSensorException by hand in your application:
<pre>
//This example snippet might be placed on a jsp that handles HTTP 404 errors.
//When the page is accessed, this code notifies AppSensor that an invalid page request was made.
//Notice that the exception is created, not thrown

new AppSensorException("ACE3", "Invalid request", "Attacker is requesting a non-existent (404) page (" + requestedURI + ")");
</pre>

The following example relies on the AttackDetectorUtils class to create the exception. This class contains various methods that handle common detection points.
<pre>
//This example snippet might be placed in request handling code that expects a form POST to occur (not a GET, not a PUT, etc).
//This code notifies AppSensor that an type of HTTP request was made.

AttackDetectorUtils.verifyValidRequestMethod(request, AttackDetectorUtils.POST);
</pre>
----

==== Intrusion Threshold Configuration ====
Here the salient points to note are that the configuration can vary depending on what response actions are desired as well as what threshold is required. Additionally, you have control over these settings and can tune them to produce the desired effect. These configurations can be set in the appsensor.properties file in your .esapi folder. ''Note: While these threshold configurations can be set in the ESAPI.properties in the .esapi folder, it is not recommended for AppSensor so that the configuration can be kept together in one place. Also note some thresholds may already be configured for subclasses of ESAPI's EnterpriseSecurityException in the ESAPI.properties file - please be aware of that when setting up the configuration for your application.''

Below are two sample threshold configurations for two separate detection points.

<pre>
# http://www.owasp.org/index.php/AppSensor_DetectionPoints#ACE2:_Modifying_Parameters_Within_A_POST_For_Direct_Object_Access_Attempts
# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.ACE2.count=3
# segment of time (in seconds)
IntrusionDetector.ACE2.interval=3
# list of actions you want executed in the specified order as the threshold for this intrusion is met - ie. log the first time, logout the user the second time, etc.
IntrusionDetector.ACE2.actions=log,logout,disable,disableComponent
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponent.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponent.timeScale=m
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponentForUser.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponentForUser.timeScale=m
</pre>

<pre>
# http://www.owasp.org/index.php/AppSensor_DetectionPoints#RE3:_GET_When_Expecting_POST
# number of intrusions in a specified segment of time that constitutes the upper threshold - once crossed, it's considered an "attack"
IntrusionDetector.RE3.count=3
# segment of time (in seconds)
IntrusionDetector.RE3.interval=300
# list of actions you want executed in the specified order as the threshold for this intrusion is met - ie. log the first time, logout the user the second time, etc.
IntrusionDetector.RE3.actions=log,logout,disable
</pre>
----

This document shows that AppSensor is very simple to configure as well as to use. Once setup, you simply add detection points to your code and add and/or modify the appropriate configuration information in the ESAPI.properties and appsensor.properties files in order to let AppSensor know your appropriate thresholds for each detection point. That's it!

[[Category:OWASP AppSensor Project]]

AppSensor GettingStarted

2010-06-25T19:22:42Z

John Melton: