OWASP - User contributions [en]

2012 BASC Speakers

2012-10-01T20:33:26Z

Rksethi:

{{2012_BASC:Header_Template | Speakers/Panelists}}

=== Michael Anderson ===
'''NetSPI''' 
Michael Anderson is a security consultant at NetSPI with experience in penetration testing, application security,
computer forensics, network architecture, and code reviews. He has presented at DEF CON 18 on cloud-based
threats, and is currently engaged in research on threats to mobile infrastructure.

=== Ray Cote ===
'''Appropriate Solutions, Inc.''' 

=== Josh Corman ===
'''Akamai Technologies''' 
Joshua Corman is the Director of Security Intelligence for Akamai Technologies and has more than a decade of experience with security and networking software. Most recently he served as Research Director for Enterprise Security at The 451 Group following his time as Principal Security Strategist for IBM Internet Security Systems. Mr. Corman's research cuts across sectors to the core security challenges plaguing the IT industry, and helps to drive evolutionary strategies toward emerging technologies and shifting economics. His research and education efforts won him the title of [http://www.networkworld.com/supp/2009/outlook/010509-tech-people-to-know.html Top Influencer of IT] by NetworkWold magazine in 2009. Mr. Corman is a candid and highly-coveted speaker with engagements at leading industry events such as RSA, DEFCON, Interop, ISACA, and SANS. As a staunch advocate for CISOs, Corman also serves as a Fellow with the Ponemon Institute, on the Faculty for IANS, and co-founded [http://www.ruggedsoftware.org/ Rugged Software] - a value-based initiative to raise awareness and usher in an era of secure digital infrastructure.

=== John Dickson ===
'''Denim Group''' 
John Dickson, CISSP, has over 15 years in the information security field including hands-on experience with intrusion detection systems, network security, and software security in the commercial and government sectors. In his current position as a Principal at Denim Group, he helps chief security officers of Fortune 500 clients and federal organizations launch and expand successful software security initiatives. John regularly speaks on the topic of application security at industry venues such as the RSA Security Conference and the Computer Security Institute’s (CSI) conferences.

=== Ehsan Foroughi ===
'''SD Elements''' 
Ehsan Foroughi is an application security expert with 8+ years of management and technical experience in security research. He has an extensive development and reverse engineering background. He led the Vulnerability Research Subscription Service for TELUS Security Labs (called Assurent before being acquired by TELUS). Under his management, the Vulnerability Research Service went through being a startup product to a service used by over 80% of the major security vendors. As an entrepreneur, he has also served as the founder and CTO of TELTUB, a successful telecommunication startup. Ehsan holds a M.Sc. from the University of Toronto in Computer Science, a B.Eng. from Sharify University of Technology, as well CISM and CISSP designations. SD Elements is a spin-off of Security Compass.

=== Rohit Sethi ===
'''SD Elements''' 
Rohit Sethi is a specialist in building security controls into the software development life cycle (SDLC). He has helped improve software security at some of the world's most security sensitive organizations in financial services, software, ecommerce, healthcare, telecom and other industries. Rohit has built and taught SANS courses on Secure J2EE development. He has spoken and taught at FS-ISAC, RSA, OWASP, Secure Development Conference, Shmoocon, CSI National, Sec Tor, Infosecurity, CFI-CIRT, and many others. Mr. Sethi has written articles for InfoQ, Dr. Dobb's Journal, TechTarget, Security Focus and the Web Application Security Consortium (WASC), has appeared on Fox News Live, and has been quoted as an expert in application security for ITWorldCanada and Computer World. He also created the OWASP Design Patterns Security Analysis project. SD Elements is a spin-off of Security Compass.


=== Roy Wattanasin ===
Roy Wattanasin is a information security professional working in the healthcare industry. He spends
most of his time on leading and developing an organization's information security program and working
on PCI-DSS compliance, privacy, regulatory efforts, education efforts and with other projects. He also
teaches information security at Brandeis University.

=== Jim Weiler ===

=== Matt Wood ===
'''Sunera''' 
Matt has been active within the security community for the past 10
years as a developer, researcher, and consultant. As a penetration
tester with Sunera, Matt has lead social engineering, mobile
application, internal/external network and web application penetration
assessments with the specific goal of vulnerability identification and
active exploitation of identified vulnerabilities. Prior to Sunera,
Matt was a senior researcher within HP's Web Security Research Group
focusing on the automated detection of vulnerabilities within web
technologies. During his tenure with HP, he also led the development
of several free tools such as HP's Scrawlr (SQLI) and SWFScan (Flash
Static-Analysis). Prior to HP/SPI Dynamics, Inc., Matt performed
research on SQL injection and automated debugging within the
Information Security program at the Georgia Tech. He has spoken at a
variety of security conferences and events such as Black Hat, RSA,
Source and OWASP.

{{2012_BASC:Footer_Template | Speakers}}

GPC Project Details/OWASP Enterprise Security API - PHP Version

2011-10-07T01:34:25Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Andrew van der Stock 10/06/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP ESAPI for PHP
| project_description = This is the PHP language version of OWASP ESAPI.
* The current release of this project '''is not''' suitable for production use
| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD license]
| leader_name = Andrew van der Stock
| leader_email = vanderaj@owasp.org
| leader_username =
| past_leaders_special_contributions = Mike Boberski
| maintainer_name =
| maintainer_email =
| maintainer_username =
| contributor_name1 = Jah Boite '''()'''
| contributor_email1 =
| contributor_username1 = Linden Darling
| contributor_name2 =
| contributor_email2 =
| contributor_username2 = Bipin Upadhyay
| contributor_name3 =
| contributor_email3 =
| contributor_username3 = Arnaud Labenne
| contributor_name4 =
| contributor_email4 =
| contributor_username4 = Martin Reiche
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name = esapi-php
| links_url1 = http://code.google.com/p/owasp-esapi-php
| links_name1 = ESAPI for PHP Google Code repository
| links_url2 = http://owasp-esapi-php.googlecode.com/files/esapi4php-contributing.pdf
| links_name2 = ESAPI for PHP Developer Onboarding Instructions
| links_url3 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Downloads
| links_name3 = General ESAPI information
| links_url4 =
| links_name4 =
| links_url5 =
| links_name5 =
| links_url6 =
| links_name6 =
| links_url7 =
| links_name7 =
| links_url8 =
| links_name8 =
| links_url9 =
| links_name9 =
| links_url10 =
| links_name10 =
| project_road_map =
| project_health_status =
| current_release_name =
| current_release_date =
| current_release_download_link =
| current_release_rating =
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details =
| last_reviewed_release_name =
| last_reviewed_release_date =
| last_reviewed_release_download_link =
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 4/10/2009
| GPC_Notes = Empty template (PHP Version)
| project_home_page = :Category:OWASP_Enterprise_Security_API
| project_details_wiki_page = GPC_Project_Details/OWASP_Enterprise_Security_API_-_PHP_Version
}}

GPC Project Details/OWASP Enterprise Security API - Python Version

2011-10-06T23:56:26Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Craig Youkins 10/6/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP ESAPI for Python
| project_description = This is the Python language version of OWASP ESAPI.
* The current release of this project '''is not''' suitable for production use
| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD license]
| leader_name = Craig Younkins
| leader_email = craig.younkins@owasp.org
| leader_username =
| past_leaders_special_contributions =
| maintainer_name =
| maintainer_email =
| maintainer_username =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| contributor_name2 =
| contributor_email2 =
| contributor_username2 =
| contributor_name3 =
| contributor_email3 =
| contributor_username3 =
| contributor_name4 =
| contributor_email4 =
| contributor_username4 =
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name =
| links_url1 = http://code.google.com/p/owasp-esapi-python
| links_name1 = ESAPI for Python Google Code repository
| links_url2 = http://www.owasp.org/index.php/ESAPI_Python_Readme
| links_name2 = ESAPI Python readme and release notes
| links_url3 = http://code.google.com/p/owasp-esapi-python/issues/
| links_name3 = ESAPI for Python issues may be reported at the Google Code ESAPI issue tracker
| links_url4 = http://owasp-esapi-python.googlecode.com/hg/doc/index.html
| links_name4 = ESAPI for Python interface documentation
| links_url5 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Downloads
| links_name5 = General ESAPI information
| links_url6 =
| links_name6 =
| links_url7 =
| links_name7 =
| links_url8 =
| links_name8 =
| links_url9 =
| links_name9 =
| links_url10 =
| links_name10 =
| project_road_map =
| project_health_status =
| current_release_name =
| current_release_date =
| current_release_download_link =
| current_release_rating =
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details =
| last_reviewed_release_name =
| last_reviewed_release_date =
| last_reviewed_release_download_link =
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 4/10/2009
| GPC_Notes = Empty template (Python Version)
| project_home_page = :Category:OWASP_Enterprise_Security_API
| project_details_wiki_page = GPC_Project_Details/OWASP_Enterprise_Security_API_-_Python_Version
}}

Projects/OWASP ESAPI C++ Project

2011-10-03T20:11:00Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Kevin Wall 10/3/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ESAPI C++ Project
| project_home_page = :Category:OWASP Enterprise Security API
| project_description =This is the C++ language version of the OWASP ESAPI.
*ESAPI for C++ is sponsored by the United States Government
*An API for helping programmers develop more secure business applications in C++.
*Provides easy to use functions for proper auditing, simple wrappers for cryptographic functions, and more.
*The current release of this project is '''not suitable''' for production use
| project_license =
| leader_name1 =David Anderson
| leader_email1 =david.anderson@aspectsecurity.com
| leader_username[1-10] =
| contributor_name1 = Dan Amodio
| contributor_email1 = dan.amodio@aspectsecurity.com
| contributor_username1 = Dan_Amodio
| contributor_name2 = Kevin Wall
| contributor_email2 = kevin.w.wall@gmail.com
| contributor_username2 = Kevin_W._Wall
| contributor_name3 = Jeff Walton
| contributor_email3 =
| contributor_username3 = Jeffrey_Walton
| pamphlet_link =
| presentation_link =
| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-esapi-c++
| project_road_map =
| links_url1 = ESAPI C++ Google Code Project
| links_name1 = http://code.google.com/p/owasp-esapi-cplusplus/
| release_1 =
| release_2 =
| release_3 =
| release_4 =

| project_about_page = Projects/OWASP ESAPI C++ Project
}}
<noinclude>[[Category: Project About]]</noinclude>

Projects/OWASP ESAPI Objective - C Project

2011-10-03T13:28:44Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Deepak Subramanian 9/30/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ESAPI Objective - C Project
| project_home_page = Category:OWASP Enterprise Security API

| project_description =
The OWASP ESAPI Objective-C is the Objective-C (Cocoa) implementation of ESAPI.
*The current release of this project '''is not''' suitable for production use

| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD License]

| leader_name1 = Deepak Subramanian
| leader_email1 = deepak.subramanian@owasp.org
| leader_username1 = Deepak Subramanian

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| pamphlet_link =

| presentation_link =

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/esapi-user

| project_road_map = http://www.owasp.org/index.php/Projects/OWASP_ESAPI_Objective_-_C_Project/Roadmap

| links_url1 = http://code.google.com/p/owasp-esapi-objective-c/
| links_name1 = ESAPI Objective-C google Code

| release_1 = ESAPI Objective - C/Release v0.0.1
| release_2 =
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP ESAPI Objective - C Project

}}

Projects/OWASP ESAPI C Project

2011-10-03T13:27:54Z

Rksethi: Undo revision 118460 by Rksethi (talk)

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ESAPI C Project
| project_home_page = :Category:OWASP Enterprise Security API
| project_description = This is the C language version of the OWASP ESAPI.
*ESAPI for C is sponsored by the United States Government
*An API for helping programmers develop more secure business applications in C.
*Provides easy to use functions for proper auditing, simple wrappers for cryptographic functions, and more.
| project_license =
| leader_name1 =David Anderson
| leader_email1 = david.anderson@aspectsecurity.com
| leader_username1 =
| contributor_name1 = Dan Amodio
| contributor_email1 = dan.amodio@aspectsecurity.com
| contributor_username1 = Dan_Amodio
| pamphlet_link =
| presentation_link =
| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-esapi-c
| project_road_map =
| links_url1 = http://code.google.com/p/owasp-esapi-c/
| links_name1 = ESAPI-C Google Code Project
| links_url2 = http://owasp-esapi-c.googlecode.com/svn/trunk/doc/html/index.html
| links_name2 = ESAPI-C Documentation
| release_1 =
| release_2 =
| release_3 =
| release_4 =

| project_about_page = Projects/OWASP ESAPI C Project
}}
<noinclude>[[Category: Project About]]</noinclude>

Projects/OWASP ESAPI C++ Project

2011-10-03T13:26:51Z

Rksethi: Undo revision 118461 by Rksethi (talk)

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ESAPI C++ Project
| project_home_page = :Category:OWASP Enterprise Security API
| project_description =This is the C++ language version of the OWASP ESAPI.
*ESAPI for C++ is sponsored by the United States Government
*An API for helping programmers develop more secure business applications in C++.
*Provides easy to use functions for proper auditing, simple wrappers for cryptographic functions, and more.
| project_license =
| leader_name1 =David Anderson
| leader_email1 =david.anderson@aspectsecurity.com
| leader_username[1-10] =
| contributor_name1 = Dan Amodio
| contributor_email1 = dan.amodio@aspectsecurity.com
| contributor_username1 = Dan_Amodio
| contributor_name2 = Kevin Wall
| contributor_email2 = kevin.w.wall@gmail.com
| contributor_username2 = Kevin_W._Wall
| contributor_name3 = Jeff Walton
| contributor_email3 =
| contributor_username3 = Jeffrey_Walton
| pamphlet_link =
| presentation_link =
| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-esapi-c++
| project_road_map =
| links_url1 = ESAPI C++ Google Code Project
| links_name1 = http://code.google.com/p/owasp-esapi-cplusplus/
| release_1 =
| release_2 =
| release_3 =
| release_4 =

| project_about_page = Projects/OWASP ESAPI C++ Project
}}
<noinclude>[[Category: Project About]]</noinclude>

Projects/OWASP ESAPI C++ Project

2011-10-03T13:26:22Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Deepak Subramanian 9/30/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ESAPI C++ Project
| project_home_page = :Category:OWASP Enterprise Security API
| project_description =This is the C++ language version of the OWASP ESAPI.
*ESAPI for C++ is sponsored by the United States Government
*An API for helping programmers develop more secure business applications in C++.
*Provides easy to use functions for proper auditing, simple wrappers for cryptographic functions, and more.
*The current release of this project '''is not''' suitable for production use
| project_license =
| leader_name1 =David Anderson
| leader_email1 =david.anderson@aspectsecurity.com
| leader_username[1-10] =
| contributor_name1 = Dan Amodio
| contributor_email1 = dan.amodio@aspectsecurity.com
| contributor_username1 = Dan_Amodio
| contributor_name2 = Kevin Wall
| contributor_email2 = kevin.w.wall@gmail.com
| contributor_username2 = Kevin_W._Wall
| contributor_name3 = Jeff Walton
| contributor_email3 =
| contributor_username3 = Jeffrey_Walton
| pamphlet_link =
| presentation_link =
| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-esapi-c++
| project_road_map =
| links_url1 = ESAPI C++ Google Code Project
| links_name1 = http://code.google.com/p/owasp-esapi-cplusplus/
| release_1 =
| release_2 =
| release_3 =
| release_4 =

| project_about_page = Projects/OWASP ESAPI C++ Project
}}
<noinclude>[[Category: Project About]]</noinclude>

Projects/OWASP ESAPI C Project

2011-10-03T13:25:43Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Deepak Subramanian 9/30/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ESAPI C Project
| project_home_page = :Category:OWASP Enterprise Security API
| project_description = This is the C language version of the OWASP ESAPI.
*ESAPI for C is sponsored by the United States Government
*An API for helping programmers develop more secure business applications in C.
*Provides easy to use functions for proper auditing, simple wrappers for cryptographic functions, and more.
*The current release of this project '''is not''' suitable for production use
| project_license =
| leader_name1 =David Anderson
| leader_email1 = david.anderson@aspectsecurity.com
| leader_username1 =
| contributor_name1 = Dan Amodio
| contributor_email1 = dan.amodio@aspectsecurity.com
| contributor_username1 = Dan_Amodio
| pamphlet_link =
| presentation_link =
| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-esapi-c
| project_road_map =
| links_url1 = http://code.google.com/p/owasp-esapi-c/
| links_name1 = ESAPI-C Google Code Project
| links_url2 = http://owasp-esapi-c.googlecode.com/svn/trunk/doc/html/index.html
| links_name2 = ESAPI-C Documentation
| release_1 =
| release_2 =
| release_3 =
| release_4 =

| project_about_page = Projects/OWASP ESAPI C Project
}}
<noinclude>[[Category: Project About]]</noinclude>

GPC Project Details/OWASP Enterprise Security API .NET Version

2011-10-03T13:24:14Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Michael Weber 9/30/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP ESAPI for .NET
| project_description = This is the .NET language version of OWASP ESAPI.
* The current release of this project '''is not''' suitable for production use
* [http://ankhsvn.open.collab.net/ AnkhSVN] is a free SVN tool that integrates with Visual Studio. Point your SVN tool at http://owasp-esapi-dotnet.googlecode.com/svn/trunk. Anonymous checkout is supported. You can also [http://code.google.com/p/owasp-esapi-dotnet/source/browse browse the source].
| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD license]
| leader_name = Alex Smolen
| leader_email = me@alexsmolen.com
| leader_username =
| past_leaders_special_contributions =
| maintainer_name = Michael Weber
| maintainer_email = michael.weber35@gmail.com
| maintainer_username =
| contributor_name1 = Paul Apostolescu
| contributor_email1 = apbogdan@gmail.com
| contributor_username1 =
| contributor_name2 =
| contributor_email2 =
| contributor_username2 =
| contributor_name3 =
| contributor_email3 =
| contributor_username3 =
| contributor_name4 =
| contributor_email4 =
| contributor_username4 =
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name = esapi-dev-dotnet
| links_url1 = http://code.google.com/p/owasp-esapi-dotnet/
| links_name1 = ESAPI for .NET Google Code repository
| links_url2 = http://owasp-esapi-dotnet.googlecode.com/files/Esapi.zip
| links_name2 = Download the latest .NET ESAPI library binary from Google Code here.
| links_url3 = http://owasp-esapi-dotnet.googlecode.com/files/Esapi_Documentation.zip
| links_name3 = Download the latest .NET ESAPI documentation from Google Code here. It is a zipped .chm (help) file.
| links_url4 = http://alexsmolen.com/dotnetesapidoc/index.html
| links_name4 = You can also browse the .NET ESAPI documentation here
| links_url5 = http://www.owasp.org/index.php/ESAPI_DotNET_Readme
| links_name5 = ESAPI .NET readme and release notes
| links_url6 = http://keepitlocked.net/archive/2009/07/29/owasp-net-esapi-0-2-released.aspx
| links_name6 = ESAPI for .NET design notes (Blog)
| links_url7 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Downloads
| links_name7 = General ESAPI information
| links_url8 =
| links_name8 =
| links_url9 =
| links_name9 =
| links_url10 =
| links_name10 =
| project_road_map =
| project_health_status =
| current_release_name =
| current_release_date =
| current_release_download_link =
| current_release_rating =
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details =
| last_reviewed_release_name =
| last_reviewed_release_date =
| last_reviewed_release_download_link =
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 4/10/2009
| GPC_Notes = Empty template (.NET_Version)
| project_home_page = :Category:OWASP_Enterprise_Security_API
| project_details_wiki_page = GPC_Project_Details/OWASP_Enterprise_Security_API_.NET_Version
}}

GPC Project Details/OWASP Enterprise Security API - Classic ASP Version

2011-10-03T13:21:17Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Juan C Calderon 9/30/2011

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP ESAPI for Classic ASP
| project_description = This is the Microsoft Classic ASP 3.x language version of OWASP ESAPI.
* The current release of this project '''is not''' suitable for production use
| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD license]
| leader_name = Juan Carlos Calderon
| leader_email = johnccr@yahoo.com
| leader_username = Jcmax
| past_leaders_special_contributions =
| maintainer_name = Juan Carlos Calderon
| maintainer_email = johnccr@yahoo.com
| maintainer_username = Jcmax
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| contributor_name2 =
| contributor_email2 =
| contributor_username2 =
| contributor_name3 =
| contributor_email3 =
| contributor_username3 =
| contributor_name4 =
| contributor_email4 =
| contributor_username4 =
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name = OWASP-Classic-ASP-Security-Project
| links_url1 = http://www.owasp.org/index.php/Classic_ASP_Security_Project
| links_name1 = OWASP Classic ASP Security Project Page
| links_url2 = http://code.google.com/p/owasp-esapi-classicasp/
| links_name2 = ESAPI for Classic ASP Google Code Repository
| links_url3 = http://www.owasp.org/index.php/ESAPI_ClassicASP_Readme
| links_name3 = ESAPI for Classic ASP readme and release notes
| links_url4 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Downloads
| links_name4 = General ESAPI information
| links_url5 =
| links_name5 =
| links_url6 =
| links_name6 =
| links_url7 =
| links_name7 =
| links_url8 =
| links_name8 =
| links_url9 =
| links_name9 =
| links_url10 =
| links_name10 =
| project_road_map = ESAPI for Classic ASP is currently "mounted" on ESAPI for .NET using interop, however the prevalence of random errors in the technology had make it non usable in real world. Starting on December 2010, the API will be re-written completely to ActiveX objects to avoid any issue related to interop and to other dependencies (.NET Framework)
| project_health_status = On Hold Until December 2010
| current_release_name =
| current_release_date = March 19, 2009
| current_release_download_link = http://www.owasp.org/index.php/File:OWASP_Classic_ASP_ESAPI.zip
| current_release_rating = Beta
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details =
| last_reviewed_release_name =
| last_reviewed_release_date = March 19, 2009
| last_reviewed_release_download_link = http://www.owasp.org/index.php/File:OWASP_Classic_ASP_ESAPI.zip
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 4/10/2009
| GPC_Notes = template updated October 29, 2009 (Classic ASP Version)
| project_home_page = :Category:OWASP_Enterprise_Security_API
| project_details_wiki_page = GPC_Project_Details/OWASP_Enterprise_Security_API_-_Classic_ASP_Version
}}

Projects/OWASP ESAPI for ColdFusion - CFML Project

2011-09-30T19:27:17Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Damon Miller on 9/30

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP ESAPI for ColdFusion/CFML Project
| project_home_page = Category:OWASP Enterprise Security API

| project_description = This is the ColdFusion/CFML language version of OWASP ESAPI.
* The current release of this project is '''not suitable''' for production use

| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD License]

| leader_name1 = Damon Miller
| leader_email1 = damonmiller513@gmail.com
| leader_username1 =

| contributor_name1 = Bill Shelton
| contributor_email1 = billshelton@comcast.net
| contributor_username1 =

| contributor_name2 = Jason Dean
| contributor_email2 = jason@12robots.com
| contributor_username2 =

| contributor_name[3-10] =
| contributor_email[3-10] =
| contributor_username[3-10] =

| pamphlet_link =

| presentation_link =

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/esapi-user

| project_road_map = http://code.google.com/p/owasp-esapi-coldfusion/wiki/RoadMap

| links_url1 = https://github.com/damonmiller/cfesapi/
| links_name1 = GitHub repository

| links_url2 = https://github.com/damonmiller/cfesapi/blob/master/README
| links_name2 =Readme and release notes

| links_url3 = https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Downloads
| links_name3 =ESAPI Downloads

| links_url4 = http://groups.google.com/group/cfesapi
| links_name4 =CFESAPI Mailing List

| release_1 =
| release_2 =
| release_3 =
| release_4 =


| project_about_page = Projects/OWASP ESAPI for ColdFusion - CFML Project
}}

GPC Project Details/OWASP Enterprise Security API JavaScript Version

2011-09-30T19:00:14Z

Rksethi: Added note that the current release of this project is not suitable for production use as per email with Chris Schmidt on 9/30

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP ESAPI for JavaScript
| project_description = This is the JavaScript language version of OWASP ESAPI.
* The current release of this project '''is not''' suitable for production use
| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD license]
| leader_name = Chris Schmidt
| leader_email =
| leader_username = Chris_Schmidt
| past_leaders_special_contributions =
| maintainer_name =
| maintainer_email =
| maintainer_username =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| contributor_name2 =
| contributor_email2 =
| contributor_username2 =
| contributor_name3 =
| contributor_email3 =
| contributor_username3 =
| contributor_name4 =
| contributor_email4 =
| contributor_username4 =
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name =
| links_url1 = http://code.google.com/p/owasp-esapi-js
| links_name1 = ESAPI for JavaScript Google Code repository
| links_url2 = http://www.owasp.org/index.php/ESAPI_JavaScript_Readme
| links_name2 = ESAPI JavaScript readme and release notes
| links_url3 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Downloads
| links_name3 = General ESAPI information
| links_url4 =
| links_name4 =
| links_url5 =
| links_name5 =
| links_url6 =
| links_name6 =
| links_url7 =
| links_name7 =
| links_url8 =
| links_name8 =
| links_url9 =
| links_name9 =
| links_url10 =
| links_name10 =
| project_road_map =
| project_health_status =
| current_release_name =
| current_release_date =
| current_release_download_link =
| current_release_rating =
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details =
| last_reviewed_release_name =
| last_reviewed_release_date =
| last_reviewed_release_download_link =
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 10/03/2010
| GPC_Notes = Empty template (JavaScript Version)
| project_home_page = :Category:OWASP_Enterprise_Security_API
| project_details_wiki_page = GPC_Project_Details/OWASP_Enterprise_Security_API_JavaScript_Version
}}

GPC Project Details/OWASP Enterprise Security API - Force.com Version

2011-09-30T18:58:07Z

Rksethi: Added note that the current release of this project is suitable for production use, as per email from Brian Soby on 9/30

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP ESAPI for Force.com
| project_description = This is the Force.com language version of OWASP ESAPI.
* The current release of this project '''is''' suitable for production use
| project_license = [http://www.opensource.org/licenses/bsd-license.php New BSD license]
| leader_name = Yoel Gluck (securecloud .at. salesforce.com)
| leader_email =
| leader_username = Yoelgluck
| past_leaders_special_contributions =
| maintainer_name =
| maintainer_email =
| maintainer_username =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| contributor_name2 =
| contributor_email2 =
| contributor_username2 =
| contributor_name3 =
| contributor_email3 =
| contributor_username3 =
| contributor_name4 =
| contributor_email4 =
| contributor_username4 =
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name =
| links_url1 = http://code.google.com/p/force-dot-com-esapi/
| links_name1 = ESAPI for Force.com Google Code repository
| links_url2 =
| links_name2 =
| links_url3 =
| links_name3 =
| links_url4 =
| links_name4 =
| links_url5 =
| links_name5 =
| links_url6 =
| links_name6 =
| links_url7 =
| links_name7 =
| links_url8 =
| links_name8 =
| links_url9 =
| links_name9 =
| links_url10 =
| links_name10 =
| project_road_map =
| project_health_status =
| current_release_name =
| current_release_date =
| current_release_download_link =
| current_release_rating =
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details =
| last_reviewed_release_name =
| last_reviewed_release_date =
| last_reviewed_release_download_link =
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 10/22/2010
| GPC_Notes = Empty template (Force.com Version)
| project_home_page = :Category:OWASP_Enterprise_Security_API
| project_details_wiki_page = GPC_Project_Details/OWASP_Enterprise_Security_API_Force.com_Version
}}

GPC Project Details/OWASP Enterprise Security API Java EE Version

2011-09-30T00:50:30Z

Rksethi: Added note that the current release of this project is suitable for production use

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP ESAPI for Java EE
| project_description = This is the Java EE language version of OWASP ESAPI. The ESAPI for Java EE is the baseline ESAPI design.
* The current release of this project '''is''' suitable for production use
* The ESAPI 2.0 branch supports Java 1.5 and above. You may view the Javadocs here http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/index.html
* The ESAPI 1.4 branch supports Java 1.4 and above. Complete information on latest 1.4 branch dependencies can be found here http://owasp-esapi-java.googlecode.com/svn/trunk_doc/1.4.4/site/dependencies.html
* The OWASP AppSensor-ESAPI integration guide is out! [[AppSensor_GettingStarted]]



| project_license = [http://en.wikipedia.org/wiki/BSD_license BSD license]
| leader_name = Jeff Williams
| leader_email = jeff.williams@owasp.org
| leader_username = Jeff_Williams
| past_leaders_special_contributions =
| maintainer_name = Jim Manico
| maintainer_email = jim.manico@owasp.org
| maintainer_username = Jmanico
| contributor_name1 = Chris Schmidt
| contributor_email1 = chrisisbeef@gmail.com
| contributor_username1 = Chris_Schmidt
| contributor_name2 = Kevin W. Wall
| contributor_email2 = kevin.w.wall@gmail.com
| contributor_username2 = Kevin_W._Wall
| contributor_name3 =
| contributor_email3 =
| contributor_username3 =
| contributor_name4 =
| contributor_email4 =
| contributor_username4 =
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name = esapi-dev
| links_url1 = http://code.google.com/p/owasp-esapi-java/downloads/list
| links_name1 = All ESAPI Downloads
| links_url2 = http://owasp-esapi-java.googlecode.com/files/ESAPI-1.4.4.zip
| links_name2 = ESAPI 1.4.4 - complete zip (Java 1.4+)
| links_url3 = http://code.google.com/p/owasp-esapi-java
| links_name3 = Google code repository for ESAPI JAVA
| links_url4 = http://code.google.com/p/owasp-esapi-java/issues/list
| links_name4 = Report a bug! (requires Google account)
| links_url5 = http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/index.html
| links_name5 = ESAPI 2.0 rc11 Javadocs
| links_url6 = http://owasp-esapi-java.googlecode.com/svn/trunk_doc/1.4.4/index.html
| links_name6 = ESAPI 1.4.4 Javadocs
| links_url7 = http://www.owasp.org/index.php/ESAPI-Building
| links_name7 = How to build ESAPI 2.0 with Maven
| links_url8 = http://www.owasp.org/index.php/ESAPI-BuildingWithEclipse
| links_name8 = How to build ESAPI 2.0 with Maven via Eclipse
| project_road_map =
| project_health_status =
| current_release_name =
| current_release_date =
| current_release_download_link =
| current_release_rating =
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details =
| last_reviewed_release_name =
| last_reviewed_release_date =
| last_reviewed_release_download_link =
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 4/10/2009
| GPC_Notes = Empty template (Java EE Version)
| project_home_page = :Category:OWASP_Enterprise_Security_API
| project_details_wiki_page = GPC_Project_Details/OWASP_Enterprise_Security_API_Java_EE_Version
}}

Projects/OWASP Secure Web Application Framework Manifesto/Releases/Current/Manifesto

2010-11-29T23:10:42Z

Rksethi:

''Secure Web Application Framework Manifesto''

Authors: Tom Aratyn, Sahba Kazerooni, Patrick Szeto, & Rohit Sethi

= Mission Statement =
The Secure Web Application Framework Manifesto is a document detailing a specific set of security requirements for developers of web application frameworks to adhere to. The manifesto centers around the following beliefs:

* Frameworks that are ‘secure by default’ will yield a dramatic reduction in the number of common web application security vulnerabilities.
* Application security experts should provide, on a regularly basis, updated guidance to framework developers on how to incorporate mechanisms to avoid newly discovered vulnerabilities.

= Introduction =
Developers are increasingly relying on scaffolding-based systems like Rails and Django to build applications. The number of web application frameworks, scaffolding or otherwise, is constantly growing and it's becoming increasingly clear that securing these frameworks will be a major boon for the future of secure web applications.

In the words of Jeff Williams, we have plenty of "painkillers" for web application framework developers to follow such as lists of vulnerabilities to avoid. The Security Analysis of Core J2EE Patterns was our first attempt at providing "vitamins" or positive advice to framework developers on what they should do to incorporate security into their design. Recognizing that many developers are gravitating to leveraging web application frameworks, we decided it was time to provide a list of positive features that these frameworks should include.

This "Secure Web Application Framework Manifesto" must, of course, be a living document. At any given point, it should provide a minimum baseline of what a web application framework should include to appeal to security-conscious developers. We contend that if such a web application framework is broadly adopted, it will have far reaching effects into web application security.

Adhering to the manifesto is only a starting point. Developers still can, and surely will, introduce vulnerabilities not covered by the manifesto; especially those pertaining to their core domain such as fine-grained authorization. Secure-by-default frameworks are compliments but not substitutes for developer security awareness.

The Manifesto is not an exhaustive specification. It is designed to provide a minimum standard for frameworks to adhere to in order to facilitate development of secure web applications. Some of these features will come with tradeoffs in performance or usability. Security features should be turned on by default with the option to turn them off explicitly. In some cases, the usability or performance trade-offs may be so great that framework developers will turn the features off by default. Such decisions should be the exception and not the norm.

== Acknowledgements ==
We owe a debt of gratitude to Arshan Dabirsiaghi and the entire OWASP [http://www.owasp.org/index.php/Category:Intrinsic_Security_Working_Group Intrinsic Security Working Group]. The ISWG aims to measure the security of various frameworks – the inverse of the Secure Web Application Framework Manifesto, which aims to provide the measuring stick itself. Although we initially started this manifesto independent of their work, cross referencing their requirements helped us identify gaps in the Manifesto.

Similarly, James Landis was kind enough to provide us with a similar body of work he put together in defining requirements for a secure web application framework. His ideas also helped shape the manifesto.

We also would like to thank the following individuals for their insight and support in creating the manifesto:

* Jim Manico
* Dinis Cruz
* James McGovern
* Paco Hope
* Paul Johnston

= Requirements =
== Injection Prevention ==
Confounding data with executable code is the cause of the most pervasive application security problems: Cross Site Scripting (XSS), SQL injection, buffer overflow and several others. The fundamental problem arises when developers can mix user-supplied or user-influenced data, such as HTTP parameters, with static or system-generated code. The resultant data is then executed or otherwise interpreted by a process which can no longer differentiate the code from the data. An obvious example of this principle at work is [http://www.owasp.org/index.php/SQL_Injection SQL injection]. Pseudo code:

bad_query = "select * from accounts where accountid = '" + user_supplied_value + "'";
DatabaseTool.executeQuery(bad_query);

In this example, the database tool has no way to differentiate which parts of the query variable came from the string literal and which parts came from the user supplied value. Most modern programming languages and development frameworks offer a way around this by offering parameterized queries or prepared statements.

Pseudo code:

PreparedStatement good_query = "select * from accounts where accountid = ?";
good_query.setParameter(1, user_supplied_value)
DatabaseTool.executeParameterizedQuery(good_query);

DatabaseTool has a few ways to protect against the vulnerability in the second example. For example, the tool could pre-compile the string literal and pass the parameters to the database separately. The database is then responsible for not misinterpreting any portion of the user supplied data as SQL code. Such an approach renders SQL injection impossible.

Another approach is to encode unsafe data in a context relevant format. For example: to mitigate against Cross Site Scripting, a secure web application framework could automatically HTML, HTML attribute, cascading style sheet, or JavaScript encode nearly all non alpha-numeric characters depending on the context. The encoding functions in the [http://code.google.com/p/owasp-esapi-java/ OWASP ESAPI project for Java] serve as an excellent reference for this approach.

=== Provide Tools that Output Data Which is Safe from Interpretation by Browsers ===
==== Requirement Description ====
Provide tools that take potentially dangerous data, such as user-supplied input, and outputs the data to Hyper Text Markup Language (HTML), Cascading Style Sheet (CSS), or client-side script. The data should be outputted in such a way that all supported web browsers will not interpret the result as including meta-characters for code. In particular, the output should not contain valid HTML markup, CSS code, or client-side script code such as JavaScript. Tag libraries must, by default, employ these tools when outputting user-supplied data.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/XSS Cross Site Scripting (XSS)]

==== Implementation Suggestions ====
The most common implementation of this feature is to escape potentially dangerous characters such that they will not be interpreted by the browser as HTML markup, CSS code, or JavaScript. Most implementations use HTML entities, CSS escaping, and JavaScript escaping respectively.

Knowing which form of escaping to use means understanding where the data will be output. The Open Web Application Security Project (OWASP) Enterprise Security Application Programming Interface (ESAPI) for Java project provides multiple [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc5/org/owasp/esapi/Encoder.html encoding functions] and requires the developer to select the correct function depending on context.

If a framework is context aware (i.e. understands whether data will be output to HTML, CSS, or JavaScript) then it can automatically select the correct encoding format. Although not always possible, such functionality is ideally suited for template-based server pages such as ASP, JSP, or PHP. See [http://googleonlinesecurity.blogspot.com/2009/03/reducing-xss-by-way-of-automatic.html Google’s template system].

An important consideration is which characters to encode versus which characters to leave unencoded. Excessive encoding may mean extra performance and transmission costs, whereas under encoding may mean missing dangerous characters and leaving applications susceptible to attack. Where possible, decide upon a whitelist of valid characters, such as characters within the Unicode Alpha or Numeric classes, and encode all other characters.

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use these tools to output data to HTML, JavaScript, or CSS.

<nowiki>The only exception should be for functions that must, by design, output valid HTML markup, JavaScript, CSS – for example, a tag that generates “” and “” markers to denote bold text.</nowiki>

=== Provide Parameterized Query Functionality for SQL Statements ===
==== Requirement Description ====
Provide tools that allow developers to create static SQL String literals with the ability to bind parameters at runtime. This functionality is commonly referred to as Parameterized Queries or Prepared Statements. Databases must not interpret bound parameters as valid SQL escape sequences, such as an apostrophe to delimit a string. Note that that term “parameterized ''query''” does not just refer to Select statements, it also refers to other common SQL statements, such as Insert, Update, and Delete

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/SQL_Injection SQL injection]

==== Implementation Suggestions ====
Two common implementations include:
* Pre-compiling the string literal and transmitting the parameters to the database separately. The database is then responsible for maintaining a distinction between the SQL statement and the parameters

* Contextual escaping, similar to the defense described in “3.1.1Data Which is Safe from Interpretation by Browsers”. Note that any such escaping should account for different possible encoding formats of the underlying database

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration '''always '''use parameterized queries; '''never '''use dynamic statements consisting of dynamically concatenated string literals and parameters.

=== Provide Tools that Output Data Which is Safe from Interpretation by XML Processors ===
==== Requirement Description ====
Provide tools that take potentially dangerous data, such as user-supplied input, and outputs the data to XML. The data should be outputted in such a way that an XML validator, parser, or other processor will not interpret the result as including meta-characters for XML code. In particular, the output should not contain XML element, XML attribute, XML comment, CData, Document Type Definition (DTD), XML Stylesheet, preprocessing, or any other XML tags.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Testing_for_XML_Injection_%28OWASP-DV-008%29 XML injection]

==== Implementation Suggestions ====
The most common implementation of this feature is to escape potentially dangerous characters using [http://www.xml.com/pub/a/2001/01/31/qanda.html XML entities] and / or [http://www.w3.org/TR/2004/REC-xml-20040204/ numeric character reference]. Unlike “3.1.1Data Which is Safe from Interpretation by Browsers”, this requirement applies to a single output type, and does not encompass the same complexities associated with Cross Site Scripting mitigation. See the Open Web Application Security Project (OWASP) Enterprise Security Application Programming Interface (ESAPI) for Java project provides an example of [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc5/org/owasp/esapi/Encoder.html XML encoding].

An important consideration is which characters to encode versus which characters to leave unencoded. Excessive encoding may mean extra performance and transmission costs, whereas under encoding may mean missing dangerous characters and leaving applications susceptible to attack. Where possible, decide upon a whitelist of valid characters, such as characters within the Unicode Alpha or Numeric classes, and encode all other characters.

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use these tools to output data to XML.

Pseudo code:

xmlText = <nowiki>“<element>” + SafeXMLFunction(userParameter) + “</element>”</nowiki>

The only exception should be for functions that must, by design, output valid XML tags – for example, a function that generates standard Simple Object Access Protocol (SOAP) element tags.

=== Provide Parameterized Query Functionality for XPath Statements ===
==== Requirement Description ====
Provide tools that allow developers to create static XPath String literals with the ability to bind parameters at runtime, similar to Parameterized Queries for SQL. XPath engines must not interpret bound parameters as valid XML escape sequences, such as an apostrophe to delimit a string.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/XPATH_Injection XPath injection]

==== Implementation Suggestions ====
As with SQL Parameterized Queries, two possible implementations include:

•Pre-compiling the string literal and transmitting the parameters to the XPath engine separately. The XPath engine is then responsible for maintaining a distinction between the XPath statement and the parameters (see [http://blogs.msdn.com/shjin/archive/2005/07/25/443077.aspx this article]<nowiki> from the Microsoft Developer Network [MSDN])</nowiki>

•Contextual escaping, similar to the defense described in “3.1.1Provide Tools that Output Data Which is Safe from Interpretation by Browsers”. Note that any such escaping should account for different possible encoding formats of the underlying database

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use these tools to perform XPath queries.

=== Provide Parameterized Query Functionality for LDAP Statements ===
==== Requirement Description ====
Provide tools that allow developers to create static Lightweight Directory Access Protocol (LDAP) String literals with the ability to bind parameters at runtime, similar to Parameterized Queries for SQL. LDAP directories must not interpret bound parameters as valid LDAP escape sequences, such as an asterisk to denote a wildcard character .

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/LDAP_injection LDAP injection]

==== Implementation Suggestions ====
As with SQL Parameterized Queries, two possible implementations include:

•Pre-compiling the string literal and transmitting the parameters to the LDAP directory separately. The LDAP engine is then responsible for maintaining a distinction between the LDAP Path statement and the parameters

•Contextual escaping, similar to the defense described in “3.1.1Provide Tools that Output Data Which is Safe from Interpretation by Browsers”. Note that any such escaping should account for different possible encoding formats of the underlying database

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use these tools to perform LDAP queries.

=== Disallow Newline Characters from Untrusted Data in HTTP Response Headers ===
==== Requirement Description ====
For all functions that can modify HTTP response headers, such as a redirect function or the “Set-Cookie” header, disallow newline characters in potentially un-trusted parameters. For example, disallow newline characters inside of a cookie value or URL for a redirect.

Note that the term disallow is purposefully undefined; framework developers should use the best approach to match their needs, such as:

* Strip newline characters out
** Note that whenever stripping a potentially malicious character, ensure the resuling string is also free from dangerous characters. For example “%%0A0A” would still result in a URL encoded newline character if the “%0A” was stripped out once.
* Cause an error condition
* Replace newline characters with a safe equivalent, such as the literal string “\n” or ”\r”

Common functions that can modify HTTP response headers include:

* Setting HTTP status code
* Setting URL for a redirect
* Setting cookie name, value, path, secure flag, HttpOnly flag, or expiry

Framework developers may wish to provide an option to turn this functionality off for compatibility, performance, or other reasons; however, it must be turned on by default for new applications. Store this configuration setting in a centralized, auditable security settings file.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/HTTP_Response_Splitting HTTP response splitting]

==== Implementation Suggestions ====
Use a regular expression to replace carriage returns and line feeds with safe equivalents; namely, the string literals “\n” and “\r”.

==== Documentation Suggestion ====
State that affected methods may not work as intended if users intentionally supply newline characters into HTTP response splitting. Indicate that solution addresses Http Response Splitting and, if appropriate, describe how to turn the feature off along with an appropriate warning of the resultant risk.

=== Provide Option to Disallow Newline Characters in Text File Logging ===
==== Requirement Description ====
Provide an option in logging functionality to automatically disallow writing newline characters in text file-based logs. Modifying all log statements may incur significant overhead, thus this requirement is an option rather than a default setting. Store this configuration setting in a centralized, auditable security settings file.

For HTML-based logging use the tools described in “3.1.1Provide Tools that Output Data Which is Safe from Interpretation by Browsers”. For XML-based logging use the tools described in “3.1.3 Data Which is Safe from Interpretation by XML Processors”.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Log_injection Log injection]

==== Implementation Suggestions ====
Use a regular expression to replace carriage returns and line feeds with safe equivalents; namely, the string literals “\n” and “\r”.

==== Documentation Suggestion ====
Provide clear instructions on how to modify this setting, as well as the security implications of keeping the default value as turned off.

== Input Validation ==
=== Provide Configurable Validation for All Forms of User-Supplied Input ===
==== Requirement Description ====
Provide a mechanism to validate the content of all user-supplied input without directly modifying other application code. For example, provide a configuration file that allows users to supply regular expressions to validate HTTP parameters for any page.

The types of input to validate must include, at a minimum:

* HTTP request parameter names
* HTTP request parameter values
* HTTP request header names
* HTTP request header values
* URLs
* Cookie names
* Cookie values
* SQL statement results
* Input from a proprietary format, such as Flash Action Message Format
* Remotely accessible Application Program Interfaces (APIs), such as Simple Object Access Protocol (SOAP) or Representational State Transfer (REST) endpoints

Where possible, store the validation configurations setting in a centralized, standard location. Ideally, developers / administrators should be able to make changes to validation logic during application deployment rather than requiring a rebuild.

Optionally, provide a tool that allows security auditors to easily determine which forms of input the application is currently validating through the validation engine.

Optionally, provide sample regular expressions useful for whitelist validation of common data types such as phone numbers, zip codes, etc.

==== Relevant Weaknesses ====
This requirement is part of a defense in depth strategy. Although providing configurable validation does not, in itself, mitigate specific vulnerabilities it does help provide defense in depth. Input validation is particularly useful as additional defense for injection attacks, such as:

* [http://www.owasp.org/index.php/XSS Cross site scripting (XSS)]
* [http://www.owasp.org/index.php/SQL_Injection SQL injection]
* [http://www.owasp.org/index.php/Testing_for_XML_Injection_%28OWASP-DV-008%29 XML injection]
* [http://www.owasp.org/index.php/XPATH_Injection XPath injection]
* [http://www.owasp.org/index.php/LDAP_injection LDAP injection]
* [http://www.owasp.org/index.php/HTTP_Response_Splitting HTTP response splitting]
* [http://www.owasp.org/index.php/Log_injection Log injection]

In addition, input validation can help against undiscovered input / injection attacks as well as attacks on downstream systems.

==== Implementation Suggestions ====
Use a configuration file similar to the [http://struts.apache.org/1.2.4/userGuide/dev_validator.html Apache Struts Validator] plug-in. Note that the Validator plugin only provides input validation for form fields; a secure framework should provide a similar mechanism for ''all'' forms of user-supplied input.

The architecture of the validation configuration should follow the default application architecture. For example, if the default application uses a single HTML page with many different command parameters to represent different transactions, then the validation framework should allow developers to specify different validation for different commands – distinguishing the “command=” parameter from other parameters.

==== Documentation Suggestion ====
Demonstrate examples of the validation logic as part of normal application development. Include validation examples in user manuals, tutorials, demonstration/sample code, and all other documentation.

=== Use Whitelist Validation for File Paths and Names in File Handling Functionality ===
==== Requirement Description ====
For each supported operating system, only allow legal characters in the file paths and file names in the file handling functionality such as open and save. Disallow, for example, null characters. This functionality is particularly important since file handling often relies on lower-level operating system commands. Strings in operating system functions may be null-terminated even if framework strings are not null-terminated.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference Insecure direct object reference]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Document how this feature works, what impact it may have on file handling, and how to turn it off along with an appropriate warning of the resultant risk.

=== Specify an Encoding Format for Every HTTP Response Page ===
==== Requirement Description ====
Assign a consistent encoding format such as UTF-8 to all HTTP response pages unless there is a specific reason to use a different format. Allow developers to define the default encoding format.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/XSS Cross site scripting (XSS)]
** [http://www.juniper.net/security/auto/vulnerabilities/vuln34917.html Obscure cross-site scripting vectors]

==== Implementation Suggestions ====
Django provides a [http://code.djangoproject.com/wiki/StringEncoding configuration option] for default character set.

==== Documentation Suggestion ====
Document how this feature works, what impact it may have on internationalization, and how to turn it off along with an appropriate warning of the resultant risk.

=== Do Not Accept Characters with Illegal Byte Sequences or Overly Long Forms for a Given Encoding ===
==== Requirement Description ====
Overly long and malformed characters in variable length encoding formats such as UTF-8 can be used to bypass filters and may sometimes be translated to the proper format after sanitization by a different component or application. Only accept legal character sequences.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://capec.mitre.org/data/definitions/80.html Filter bypass]

==== Implementation Suggestions ====
The W3C provides a [http://www.w3.org/International/questions/qa-forms-utf-8.en.php regular expression] to validate UTF-8 characters.

==== Documentation Suggestion ====
In reference documentation describe that this feature exists.

=== Provide Function to Detect HTTP Parameter Tampering ===
==== Requirement Description ====
In some cases end users should not be able to modify certain parameters, such as some hidden form fields. Provide a server-side mechanism that detects tampering of “read-only” parameters without the overhead of storing these parameters on the server.

The framework will not necessarily know about ''all ''read-only parameters; however, the framework should be able to automatically identify ''some ''read-only parameters (e.g. hidden form fields with static values), and allow individual developers to identify other read-only parameters. If applied transparently, this feature may break functionality, so provide options to turn the feature on for specific forms or across the application.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Web_Parameter_Tampering Parameter Manipulation]

==== Implementation Suggestions ====
The .Net framework provides a defense in the form of an [http://en.wikipedia.org/wiki/HMAC HMAC] for [http://msdn.microsoft.com/en-us/library/bb386448.aspx ViewState]. The HMAC solution:

* Takes a hash of read-only fields in a form prior to sending them to the client
* Encrypts that hash with a secret key stored on the server
* Adds the hashed and encrypted value as an additional hidden field in the form
* Upon form submission, rehashes and re-encrypts the read only client-supplied parameters and compares the hash with the client-supplied HMAC parameter. Any difference indicates that one or more of the read only parameters were tampered with

==== Documentation Suggestion ====
Provide detailed documentation on how to enable this feature and how it works. Include (if applicable) how the framework creates and stores cryptographic keys, how developers can change cryptographic algorithms, and how to configure the feature to work in load balanced environments. Always enable the feature for read-only form fields in samples and tutorials.

=== Automatically Generate Content Security Policy (CSP) Headers ===
==== Requirement Description ====
Mozilla proposed [http://people.mozilla.org/~bsterne/content-security-policy/ CSP] to help protect against Cross Site Scripting. Although CSP, at the time of this writing, is not fully implemented in most browsers, a secure web application framework should proactively provide this control for when CSP becomes standard.

CSP allows developers to specify which domains a web application allows to host its scripts. A browser that complies with CSP will, when instructed to, only run scripts from the whitelisted domains and avoid executing inline or event handling HTML attribute scripts. CSP also helps protect against [http://ha.ckers.org/blog/20080915/clickjacking/ Clickjacking] by specifying “which sites may embed contents from my site”. Finally, CSP provides for an optional report-url to which all policy violations will be reported, allowing detection of attacks and proactive response to protect non-CSP enabled browsers.

Automatically generate CSP headers that restrict script access to the application’s domain and prevent inline / event handling HTML attribute scripts unless necessary. Provide tools to easily extend the list of white-listed domains when required. By default, disallow all other sites from being embedded within the application’s contents unless necessary.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/XSS Cross Site Scripting (XSS)]
* [http://www.owasp.org/index.php/Clickjacking Clickjacking]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Document how this feature works, what impact it may have on embedded scripts, and how to turn it off along with an appropriate warning of the resultant risk.

=== Automatically Generate Origin Headers ===
==== Requirement Description ====
Mozilla proposed the [http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html Origin Header] to protect against Cross Site Request Forgery (CSRF). Supporting clients send information about the originating domain of each request to the server.

Where possible, verify that the origin of a request is from the expected domain. In particular, verify that application form fields originate from the application’s domain. Generate errors for requests with invalid origins.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/CSRF Cross Site Request Forgery]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Document how this feature works, what impact it may have on application integration, and how to turn it off along with an appropriate warning of the resultant risk.

=== Specify a Default Maximum Payload Size for All Inbound Interfaces ===
==== Requirement Description ====
Check the size of payloads from all inbound interfaces prior to processing. If the payload size exceeds a default maximum generate an error. Allow developers to change the default size and turn off the feature.

At a minimum, provide payload size checks for:

* HTTP Requests
** Optionally, provide different configuration for file upload functions to allow for larger payloads
* <nowiki>XML requests (e.g. Simple Object Access Protocol [SOAP])</nowiki>
* <nowiki>Any other programmatic interface (e.g. Remote Method Invocation over Internet Inter-Orb Protocol [RMI IIOP])</nowiki>

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Application_Denial_of_Service Denial of Service]

==== Implementation Suggestions ====
Web servers often provide a maximum configurable HTTP request body size. See the Apache web server [http://httpd.apache.org/docs/2.0/mod/core.html LimitRequestBody directive].

==== Documentation Suggestion ====
Document how this feature works, what impact it may have on large payloads, and how to turn it off along with an appropriate warning of the resultant risk.

== Authentication and Authorization ==
=== Enforce Default Deny Policy for Framework Managed Authorization ===
==== Requirement Description ====
Some frameworks elect to provide managed authorization services, such as determining whether a user has sufficient privileges to view a specific page. Ensure that managed authorization services always deny access by default unless explicitly instructed otherwise.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf HTTP Verb Tampering]

==== Implementation Suggestions ====
The [http://static.springsource.org/spring-security/site/docs/3.0.x/reference/authz-arch.html Spring Security authorization] module employs default deny using the [http://static.springsource.org/spring-security/site/docs/3.0.x/reference/authz-arch.html RoleVoter] for role-based access control.

==== Documentation Suggestion ====
Document the default deny behavior when describing the authorization functionality. Provide instructions on how developers can grant access to more users when necessary. If the framework provides a default-accept option, strongly discourage developers from using it and explain the associated risks.

=== Provide Indirect Object Reference Functionality ===
==== Requirement Description ====
Provide functionality that creates and translates indirect references for a specific file, a set of files, or all files in a particular directory or directories.

Applications often allow users to access sensitive resources such as user-specific files from the application server. Direct object references use the actual file name (e.g. “file=statement1.pdf”) whereas indirect object references provide an independent identifier that the application later translates into an actual filename (e.g. “file=a”, where ‘a’ later translates to statement1.pdf).The problem with the former method is that attackers can sometimes access files that they shouldn’t (e.g. “file=../config.xml”). An indirect object reference renders such an attack impossible because the application only provides access to a specified set of files (e.g. all files in a particular directory, or a predefind list of individual files). Unfortunately, the complexity of creating an indirect object reference for each file that is to be accessed by the end user means that many developers end up favoring direct object references. Providing functionality to automate this task incentivizes developers to rely on indirect object references.

Note that this control applies specifically to resources that require access control. Publicly-accessible static content such as JavaScript or Cascading Style Sheet files that are normally stored on web servers do not necessarily need this protection. On web servers, use operating system or server controls to prevent forcible [http://www.owasp.org/index.php/Path_Traversal Path Traversal] attacks.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference Insecure Direct Object Reference]

==== Implementation Suggestions ====
See the [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/reference/IntegerAccessReferenceMap.html ESAPI Java AccessReferenceMap] and [http://support.microsoft.com/kb/910442 .Net’s Web Resource mechanism] for examples of this functionality.

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use these tools for accessing server-side files except for publicly-accessible static content (e.g. common JavaScript libraries).

=== Provide a Function That Hashes and Salts Input with Random Bytes ===
Provide all the functionality necessary for a developer to implement secure authentication. In particular, authentication should use a secure hashing algorithm salted with a fixed length random byte sequence (see). Both the hashing algorithm and salt length should be configurable in case a particular hashing function is defeated in the future. Secure web application frameworks should default to stronger, slower hashing algorithms (e.g. SHA-2) instead of fast algorithms (e.g. MD5 and SHA-1) to mitigate the risk of off-line brute forcing.

==== Requirement Description ====
Provide the following two functions:

# A function that hashes user input using a configurable, strong hashing algorithm (e.g. SHA-2) and adds a configurable-length random salt value
# A function that checks equality of a plaintext value with a hashed, salted value derived from function 1)

Developers can use these two functions respectively to facilitate securely storing a new password (e.g. new user registration or password reset) and to authenticate a user against a securely stored password.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://en.wikipedia.org/wiki/Rainbow_tables Rainbow tables]
* [http://www.owasp.org/index.php/Top_10_2007-A8 Insecure cryptographic storage]

==== Implementation Suggestions ====
[http://www.jasypt.org/encrypting-passwords.html Jasypt] exposes passwordEncryptor.encryptPassword() for function 1) and passwordEncryptor.checkPassword for function 2). See [http://www.jasypt.org/howtoencryptuserpasswords.html this explanation] for details on how Jasypt stores the salt value and uses it for password comparisons.

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use these functions for new user registration, password change, and password-based authentication.

== Session Management ==
=== Use Cryptographically Secure Random Numbers for Session IDs ===
==== Requirement Description ====
Create session IDs from Cryptogaphically Strong Random Number Generators such as Java’s [http://java.sun.com/j2se/1.4.2/docs/api/java/security/SecureRandom.html SecureRandom] rather than a pseudo random number generator like the [http://www.aquaphoenix.com/ref/gnu_c_library/libc_255.html rand()] function in C.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Insufficient_entropy_in_pseudo-random_number_generator Insufficient entropy in pseudo random number generators]

==== Implementation Suggestions ====
Tomcat uses [http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html SecureRandom numbers] for Session IDs by default.

==== Documentation Suggestion ====
Describe how the framework generates session IDs in documentation.

=== Provide Automatic Anti-CSRF Tokens ===
==== Requirement Description ====
Many web application frameworks create or render links and pages derived from form submission pages. Provide an option to transparently add and validate [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet anti-CSRF tokens] to form submissions where possible.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/CSRF Cross Site Request Forgery]

==== Implementation Suggestions ====
[http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ Django] provides this functionality optionally.

==== Documentation Suggestion ====
Where possible, turn this feature on in all user manuals, tutorials, demonstration/sample code, and all other documentation. Explain how the feature works and the risk associated with not using it.

=== Automatically Reset Session IDs After Authentication ===
==== Requirement Description ====
Change the Session ID of a user after successful authentication. Note that this feature requires knowledge of when authentication occurs. Such knowledge is trivial in framework-managed authentication but more difficult if developers elect to use custom or third party authentication. Provide a hook for the developer to tell the framework when authentication occurs in cases where the framework can’t make that determination automatically (e.g. user.hasAuthenticated() ).

If developers can associate server-side state with a session then retain that state when the session ID changes.

In some cases, particularly when working with legacy components, changing session IDs after authentication may break functionality. Provide an option to disable this functionality.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Session_Fixation Session fixation]

==== Implementation Suggestions ====
Spring Security has built-in [http://static.springsource.org/spring-security/site/docs/3.0.x/reference/ns-config.html session fixation defense].

==== Documentation Suggestion ====
Always keep this functionality enabled on in all user manuals, tutorials, demonstration/sample code, and all other documentation. Explain how the feature works and the risk associated with not using it.

=== Apply HttpOnly Flag to Session ID Cookie by Default ===
==== Requirement Description ====
Append the “[http://www.owasp.org/index.php/Testing_for_cookies_attributes_%28OWASP-SM-002%29 HttpOnly]” flag to session cookies by default, with an option to turn that feature off.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/XSS Cross Site Scripting (XSS)]

==== Implementation Suggestions ====
The .Net framework provide the ability to add the [http://msdn.microsoft.com/en-us/library/system.web.httpcookie.httponly.aspx HttpOnly] flag to cookie flags, although the feature isn’t enabled by default.

==== Documentation Suggestion ====
Always keep this functionality enabled on in all user manuals, tutorials, demonstration/sample code, and all other documentation. Explain how the feature works and the risk associated with not using it.

=== Provide Configuration Option to Apply Secure Flag to Session ID Cookie ===
==== Requirement Description ====
Most development frameworks make the default assumption that the application works over plaintext HTTP. In cases where the framework can be sure that the application uses SSL for the entire session (e.g. if the application container has SSL enabled), append the “[http://www.owasp.org/index.php/Testing_for_cookies_attributes_%28OWASP-SM-002%29 secure]” flag to session cookies by default, with an option to turn that feature off.

For cases where the framework cannot be sure that the application uses SSL for the entire session (e.g. a separate hardware device provides SSL and proxies plaintext HTTP to the application server), provide a simple configuration option for developers to add the “[http://www.owasp.org/index.php/Testing_for_cookies_attributes_%28OWASP-SM-002%29 secure]” flag to session cookies.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Session_hijacking_attack Session hijacking]

==== Implementation Suggestions ====
The .Net framework provide the ability to add the [http://msdn.microsoft.com/en-us/library/system.web.httpcookie.secure%28v=VS.100%29.aspx secure] flag to cookies, although the feature isn’t enabled by default.

==== Documentation Suggestion ====
Always keep this functionality enabled on in all user manuals, tutorials, demonstration/sample code, and all other documentation. Explain how the feature works and the risk associated with not using it.

=== Provide Configurable Inactive and Absolute Session Timeouts ===
==== Requirement Description ====
Provide an option to define both inactive (i.e. after a period of inactivity) and hard/absolute session timeout (i.e. period of time, regardless of amount of activity). Provide default values for both values. Provide an option to turn either or both timeouts.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Session_hijacking_attack Session hijacking]

==== Implementation Suggestions ====
Java Servlet containers provide [http://tomcat.apache.org/tomcat-5.5-doc/appdev/web.xml.txt configurable inactive timeout] values.

==== Documentation Suggestion ====
Explain how both features work and the risk associated with not using them.

=== Provide a Configuration Option to Tie Session IDs to an IP Address, Subnet, or a List of IP Ranges ===
==== Requirement Description ====
Some application developers opt to correlate a session ID to the client’s IP address. After session generation, the application verifies that each request comes from the expected IP address thereby mitigating the risk of session hijacking. Provide an option to seamlessly deliver this functionality.

In practice, session IP correlation on large networks is difficult if not impossible due to a variety of networking features – in particular, proxy servers such as [http://webmaster.info.aol.com/proxyinfo.html AOL proxy]. Provide options to help address this by, for example, allowing developers to specify a subnet length and verifying that each request comes from the same subnet. For example, if a developer configures session subnet correlation with a 24 bit subnet, then the application should permit requests from ''10.1.1''.3 and ''10.1.1''.5 to access the same session but it should not allow requests from ''10.1.2''.3 to access the same session.

To deal with known proxy servers, such as AOL proxy, the framework should also allow developer to specify one or more lists of IP ranges. If a clients IP falls into one of ranges then ensure that all future requests for that same session come from the same list. For example, if one request comes from the set of AOL proxy IPs then all future requests for that session should come the AOL proxy IPs.

Turn this feature off by default. Each application may require considerable time to configure for this feature to work properly.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Session_hijacking_attack Session hijacking]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Document how the feature works and how to turn it on. Provide a tutorial or other guidance on how to setup this feature for an application such that it doesn’t break availability.

== XML Specific ==
=== Disable the Following Unsafe Features by Default ===
==== Requirement Description ====
Over the years, security researchers have discovered several vulnerabilities in XML libraries – particularly [http://projects.webappsec.org/XML-Attribute-Blowup parsers] and [http://msdn.microsoft.com/en-us/magazine/ee335713.aspx validators]. Disallow dangerous functionality be default, namely:

* [http://www.securiteam.com/securitynews/6D0100A5PU.html External entity] resolution
* DTDs defined [http://www.javacommerce.com/displaypage.jsp?name=dtd.sql&id=18238 internally within XML] files
* [http://www.w3.org/TR/xml-stylesheet/ XML Stylesheet Language Transforms (XSLTs) processing instructions] within an XML document’s prolog
* [http://xml.apache.org/xalan-j/extensions.html XSLT extensions] that provide direct access to the operating system, such as Java [http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html runtime objects] or .Net [http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx System.Diagnostics.Process]
** Ideally, take a default deny approach to XSLT extensions and only allow known safe extensions with the option to turn on other extensions

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.securiteam.com/securitynews/6D0100A5PU.html External entity attacks]
* [https://www.isecpartners.com/files/XMLDSIG_Command_Injection.pdf XSLT command injection]
* [http://msdn.microsoft.com/en-us/magazine/ee335713.aspx XML bombs]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Always have the unsafe features turned off in sample code, unless explicitly necessary. Explain the potential risk of turning any of these features on.

== Cryptography ==
=== Provide Tools for Transparent Database Encryption ===
==== Requirement Description ====
Provide configuration options to seamlessly encrypt columns within a database when the framework handles database interaction. Object Relational Mapping (ORM) libraries in particular should allow developers to configure column-level encryption.

See “Encrypt Passwords and Keys Stored in Configuration Files” for more information on how to protect the encryption key.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Insecure_Storage Insecure cryptographic storage]

==== Implementation Suggestions ====
[https://www.hibernate.org/415.html Hibernate in Java] provides seamless, configurable database encryption.

==== Documentation Suggestion ====
Document how the feature works and how to turn it on. Provide a tutorial or other guidance on how to use this feature.

=== Provide Configurable Cryptographic Algorithms ===
==== Requirement Description ====
Hard-coding specific encryption algorithms and parameters such as key size may leave applications vulnerable to common attacks if a particular algorithm is ever compromised. Allow developers to configure the algorithm and parameters such as key strengths.

Favor modes with secure random Initialization Vectors (IVs) rather than modes without IVs such [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation as Electronic Code Book (ECB)].

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Insecure_Storage Insecure cryptographic storage]

==== Implementation Suggestions ====
See Java’s [http://java.sun.com/j2se/1.5.0/docs/api/java/security/Provider.html security provider architecture].

Developers in non-compiled languages such as PHP, Ruby, and Python often favor scripts written in that programming language rather than static configuration files. Frameworks written in such languages should decouple application code from specific encryption algorithms, either by introducing a static configuration file or calling a utility class (e.g. HashingUtility.hash() rather than SHA2.hash()).

==== Documentation Suggestion ====
Clearly explain how to configure cryptographic algorithms. Provide strong default options (such as [http://csrc.nist.gov/groups/ST/toolkit/index.html NIST approved] algorithms and parameters).

=== Follow the TLS Protection Cheatsheet for TLS/SSL Implementations ===
==== Requirement Description ====
Attackers have discovered several attacks on TLS/SSL implementations and X509 certificates: [http://www.scanit.be/uploads/ssl%20security%20in%20be%20-%2003-2008.pdf downgrade attacks], [http://extendedsubset.com/?p=8 plaintext injection during renegotiation] [http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf null prefix attacks], [http://www.thoughtcrime.org/papers/ocsp-attack.pdf circumventing Online Certificate Status Protocol (OCSP) controls], and several [http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf others].

Reuse libraries that already account for these attacks rather than writing new libraries. Note that some of the attacks, such as [http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf null prefix attacks], are actually attacks against the client; however, these attacks also apply to the server during [http://en.wikipedia.org/wiki/Mutual_authentication mutual authentication].

Providing an exhaustive set of requirements for TLS/SSL is beyond the scope of this manifesto. Consult the [http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet Transport Layer Protection Cheatsheet] for comprehensive guidance. SSL Labs maintains an [https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009.pdf SSL Server Rating] guide that provides guidelines around certificate type, key size, cipher strength, key exchange algorithm, and protocol.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Top_10_2007-Insecure_Communications Insecure communications]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Clearly explain how to configure TLS. Provide specific guidance on how to deploy a server for optimum TLS/SSL security.

== Configuration Security ==
=== Encrypt Passwords and Keys Stored in Configuration Files ===
==== Requirement Description ====
Web application frameworks often store plaintext system passwords and keys in configuration files. For example, several frameworks use plaintext configuration files for [http://www.dotnetjohn.com/articles.aspx?articleid=3 database connection strings], [https://www.hibernate.org/415.html database encryption keys], [http://forums.asp.net/p/1086890/1651644.aspx Lightweight Directory Access Protocol (LDAP) connection strings], [http://www.digicert.com/ssl-certificate-installation-tomcat.htm keystore passwords], and other values. Attackers who are able to exploit other vulnerabilities are sometimes able to view the contents of files.

Provide native support for encrypted properties in configuration files.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Broken_Authentication_and_Session_Management Broken authentication (plaintext credential storage)]

==== Implementation Suggestions ====
Developers will always run into the problem of providing some sort of password or key to decrypt encrypted credentials. While no solution is perfect, frameworks can employ one of several password / key storage options:

* Store a private key, unique for each machine, as a binary file that can only be accessed by the application server. While this control succeeds in preventing attackers from viewing plaintext passwords in configuration files, it does not prevent attackers from first accessing the binary key and then the configuration file using the same exploit. This should be the minimum security option. See [http://download.oracle.com/docs/cd/E12840_01/wls/docs103/admin_ref/utils.html Weblogic].
* Store the decryption key / password in a file, similar to the preceding option. Use operating system controls to ensure that file is only accessible by a separate launching process – not the application server. The launching process can then pass in the key / password as a command line argument when launching the application server. This way, a user who exploits the application server may not necessarily have access to the decryption key itself.
* Support passphrases from an environment variable and/or web-form. This solution takes more work and possibly manual intervention but greatly decreases the risk of an attacker being able to find plaintext passwords in configuration files. See [http://www.jasypt.org/encrypting-configuration.html Jasypt]
* Leverage a distributed service, such as the .Net Data Protection API (DPAPI) [http://msdn.microsoft.com/en-us/library/ms998280.aspx User Store] key storage. This restricts key access to a particular user, so other users on the same machine (including local administrators) cannot access that key.

==== Documentation Suggestion ====
Always use the most secure possible credential storage in all user manuals, tutorials, demonstration/sample code, and all other documentation. Explain how the features work and the risk associated with not using them.

== File Upload ==
=== File Upload Tools Should Supports Pluggable Anti Malware Scanning Solutions ===
==== Requirement Description ====
Framework-managed file upload tools should facilitate safe file uploads by providing configuration options to support for library-based third party anti-virus scanning solutions, such as [http://www.clamav.net/ Clam AV].

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution Malicious file execution]
* [http://www.owasp.org/index.php/Unrestricted_File_Upload Unrestricted file upload]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Document how to use the pluggable anti-malware feature. Provide Application Programming Interface (API) details on how third parties can hook into the framework.

=== File Upload Tool Should Provide Options to Disallow Saving Outside of a Specified Directory ===
==== Requirement Description ====
Framework-managed file upload tools should disallow saving a file outside of a configurable specified directory and, optionally, any subdirectories (see the Unix [http://unixwiz.net/techtips/chroot-practices.html chroot] command).

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Unrestricted_File_Upload Unrestricted file upload]

==== Implementation Suggestions ====
You may wish to allow developers to specify absolute paths or relative paths to the application’s root. Restrict file upload to a relative path by default (e.g. /app/uploads directory).

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use this feature with file upload. Document the risks associated with turning this feature off.

=== Provide a File Upload Tool that Supports Pluggable Content Validation ===
==== Requirement Description ====
Framework-managed file upload tools should facilitate safe file uploads by providing configuration options to support for library-based third party solutions that validate the contents of a particular file type. For example, a PDF validator might ensure that a given file is indeed a PDF and does not contain any executable code or dangerous PDF extensions.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution Malicious file execution]
* [http://www.owasp.org/index.php/Unrestricted_File_Upload Unrestricted file upload]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Document how to use the pluggable validation feature. Provide options to associate different validation libraries for different extensions. Provide Application Programming Interface (API) details on how third parties can hook into the framework.

== Miscellaneous ==
=== Provide Security Specific Logs and Log All Attack Points Specified in AppSensor ===
==== Requirement Description ====
Provide a security-specific log and turn it on by default. Automatically log potential attacks using all of the attack points documented in the [http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project].

Ensure consistent use of event IDs (e.g. SE5 for source change of IP during session). Developers should be able to log to the security-specific log as well.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/ApplicationLayerIntrustionDetection Insufficient application intrusion detection]

==== Implementation Suggestions ====
See the [http://code.google.com/p/appsensor/source/browse/ AppSensor code].

==== Documentation Suggestion ====
Explain what the security log is, how it works, how and what to add to it, and the format for log entries. Expose details of the log format so that log analysis / Security Event Manager (SEM) tools can detect potential attacks.

=== Automatically Generate X-Frame-Options Header ===
==== Requirement Description ====
Browsers such as Internet Explorer 8+ support the [http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx X-FRAME-OPTIONS] header. Automatically set the X-FRAME-OPTIONS value to DENY by default or SAMEORIGIN if the application requires nested frames from within the same application.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.sectheory.com/clickjacking.htm Clickjacking]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
In all user manuals, tutorials, demonstration/sample code, and all other documentation, always use this feature. Document the risks associated with turning this feature off or providing an overly broad policy.

=== Provide Arithmetic Utilities that Protect Against Integer and Floating Point Overflow and Underflow ===
==== Requirement Description ====
Many programming languages such as Java are vulnerable to Integer and floating point [http://www.javacoffeebreak.com/books/extracts/javanotesv3/c9/s1.html overflow] and underflow. Provide libraries that encapsulate basic arithmetic operations (e..g addition, subtraction, multiplication, division) and throw errors / exceptions upon overflow or underflow conditions.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Integer_overflow Numeric overflow]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Always use these encapsulation functions when performing normal arithmetic in all user manuals, tutorials, demonstration/sample code, and all other documentation.

=== Provide Support for Pluggable Anti-Automation ===
==== Requirement Description ====
Provide a mechanism for application administrators to make use of third-party anti-automation techniques such as [http://recaptcha.net/captcha.html CAPTCHA] on certain pages. Which type of anti-automation mechanism and the implementation of that technique should be configurable. Provide an Application Programming Interface (API) to allow third party providers to plug-in anti automation into the framework. Using a pluggable architecture will promote loose coupling and allow developers to change anti-automation techniques with minor impact to the rest of the application. Developers should be able to change anti-automation techniques because attackers often find ways to [http://caca.zoy.org/wiki/PWNtcha break anti-automation].

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Brute_force_attack Brute force attacks]
* [http://www.owasp.org/index.php/Testing_for_user_enumeration_%28OWASP-AT-002%29 User enumeration]

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Always use anti-automation for user registration and forgot password in all user manuals, tutorials, demonstration/sample code, and all other documentation. Document how to change the automation provider. Provide Application Programming Interface (API) details on how third parties can hook into the framework.

=== Return Generic Error Pages by Default ===
==== Requirement Description ====
Generate error pages devoid of application details such as stack traces by default. In order to facilitate troubleshooting, add detailed error messages to an error log and optionally include a reference number to the log in the error page.

==== Relevant Weaknesses ====
This requirement mitigates the following weaknesses:

* [http://www.owasp.org/index.php/Missing_Error_Handling Missing error handling]

==== Implementation Suggestions ====
Developers can implement [http://msdn.microsoft.com/en-us/library/aa479319.aspx generic error pages] in ASP.Net through configuration.

==== Documentation Suggestion ====
Always keep this feature turned on in all user manuals, tutorials, demonstration/sample code, and all other documentation.

=== Centralized Security Configuration Options ===
==== Requirement Description ====
Many of the requirements in this document require configuration options (e.g. “3.2.1Provide Configurable Validation for All Forms of User-Supplied Input”). Consolidate as many security-relevant configuration options into a single security configuration file. Consolidated security configuration helps facilitate auditing.

==== Relevant Weaknesses ====
* N/.A

==== Implementation Suggestions ====
N/A

==== Documentation Suggestion ====
Describe all security configuration options in documentation.

Projects/OWASP Secure Web Application Framework Manifesto/Releases/SWAF Manifesto v0.08/Notes

2010-10-11T18:01:47Z

Rksethi:

This release represents cumulative iterations of the document prior to becoming an OWASP project. This includes a substantial amount of feedback from the community, including:
* Jim Manico
* Dinis Cruz
* James McGovern
* Paco Hope
* Paul Johnston

We also learned a substantial amount from similar efforts from:
* Arshan Dabirsiaghi
* James Landis

OWASP Secure Web Application Framework Manifesto/Roadmap

2010-10-11T17:53:25Z

Rksethi:

Short-Term Goals:

* Move to version 1.0 by Jan 2011 by collecting user feedback and updating the manifesto accordingly
* Reach out to at least 3 web application frameworks and let the know about the road map and seek their feedback on the feasibility of implementing it by Jan 2011
* Start development on integrating this into Django or a spin-off by Jan 2011
* Build a visual "feature comparison chart" by June 2011 so that frameworks can advertise their self-assessment against the manifesto. This would be similar to the kind of comparison chart that product vendors use to contrast different versions of their products.

Long-Term Goals:

* Create a new release of the manifesto every three years (analogous to the OWASP Top 10)

WebGoat Installation

2010-07-19T01:30:46Z

Rksethi: Fixed link to Google code to point to readme file, which contains build instructions

<webgoat/>[[WebGoat User Guide Table of Contents]]
__TOC__

WebGoat is a platform independent environment.
It utilizes Apache Tomcat and the JAVA development environment.
Installers are provided for Microsoft Windows and UN*X environments, together with notes for installation on other platforms.

==Installing Java and Tomcat ==
'''Note''': This may no longer be necessary for v5.

===Installing Java===
# Install and deploy the approprite version from http://java.sun.com/downloads/ (1.4.1 or later)

===Installing Tomcat===
# Install and deploy core Tomcat from http://tomcat.apache.org/download-55.cgi

==Installing to Windows ==
# Unzip WebGoat-OWASP_Standard-5.2.zip to your working environment.
# To start Tomcat, browse to the WebGoat directory unzipped above and double click "webgoat.bat"
# Start your browser and browse to: http://localhost/WebGoat/attack This link is case-sensitive. Make sure to use a large ‘W’ and ‘G’.

==Installing to Linux ==
<ol>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on lines 17, 19, and 23 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Installing to OS X (Tiger 10.4+) ==
<ol>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on line 10 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Installing on FreeBSD ==
<ol>
<li>Install Tomcat and Java from the ports collection:<pre>
cd /usr/ports/www/tomcat55
sudo make install
</pre></li>
<li>You will be required to manually [http://www.FreeBSDFoundation.org/cgi-bin/download?download=diablo-caffe-freebsd6-i386-1.5.0_07-b01.tar.bz2 download the Java JDK] to install it. Instructions are given by the ports system about when and how to do this.</li>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on lines 17, 19, and 23 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Running ==
# Start your browser and browse to: http://localhost/WebGoat/attack. Notice the capital 'W' and 'G'
# Login in as: user = guest, password = guest

==Building ==
Skip these instructions if you are only interested in running WebGoat.

WebGoat is built using eclipse WTP 1.5.x. Please read the instructions at [http://webgoat.googlecode.com/svn/trunk/webgoat/README.txt Goodle code] to build the WebGoat application.

==Installing WAR file to existing Tomcat server==
Place the .war file in your Tomcat webapps directory (it will self extract). You'll need to resolve several issues that are outlined in the [http://code.google.com/p/webgoat/wiki/FAQ Webgoat FAQ].

Return to the [[WebGoat User Guide Table of Contents]]
[[Category:OWASP WebGoat Project]]

Talk:Guide to Authentication

2009-12-02T20:44:24Z

Rksethi: Comment on Threshold Governer section

"When used in a single factor authentication method (for example, just a thumbprint with no username or password), biometrics are the weakest form of authentication available and are unsuitable for even moderate risk applications."
Biometrics is still a better single factor auth method than having a username/password based one which doesnt enforce password complexity or account lockout.

So I am removing that sentence. There are much worse implementations of single factor authentication.
---------------------------------------------

I don't know if this is strictly true:
" * Password change**
* Password resets**

(**Low value systems only - Most medium and all high value systems should not be using passwords, and thus do not possess password reset capabilities) "

Perhaps it should read "Most medium and all high value systems should use more than one factor of authentication and should not rely exclusively on passwords."

OWASP AppSec DC 2009 Schedule

2009-10-29T14:09:27Z

Rksethi: /* Back to Conference Page */

__NOTOC__

===[[OWASP AppSec DC 2009|Back to Conference Page]]===
Please note, speaking times are not final, check back regularly for updates.
====Training 11/10====
{| cellspacing="0" border="2"
|- valign="middle"
| height="60" align="center" colspan="6" style="background: rgb(64, 88, 160) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; color: white;" | '''Day 1 - Nov 10th 2009'''
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" |  
| width="150" valign="middle" height="40" bgcolor="#c0a0a0" align="center" | '''Room 154A'''
| width="150" valign="middle" height="40" bgcolor="#ffdf80" align="center" | '''Room 149B'''
| width="150" valign="middle" height="40" bgcolor="#a0c0e0" align="center" | '''Room 149A'''
| width="150" valign="middle" height="40" bgcolor="#b3ff99" align="center" | '''Room 154B'''
| width="150" valign="middle" height="40" bgcolor="#BCA57A" align="center" | '''Room 155'''
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 09:00-12:00
| width="150" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | Day 1: Assessing and Exploiting Web Applications with the open source Samurai Web Testing Framework Justin Searle
| width="150" valign="middle" height="120" bgcolor="#ffdf80" align="center" | Day 1: Java EE Secure Code Review Sahba Kazerooni [http://www.securitycompass.com Security Compass]
| width="150" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | Threat Modeling Express Krishna Raja [http://www.securitycompass.com Security Compass]
| width="150" valign="middle" height="120" bgcolor="#b3ff99" align="center" | Foundations of Web Services and XML Security Dave Wichers [http://www.aspectsecurity.com Aspect Security]
| width="150" valign="middle" height="120" bgcolor="#BCA57A" align="center" | Live CD Matt Tesauro
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" | 12:00-13:00
| valign="middle" height="40" bgcolor="#909090" align="center" colspan="5" | Lunch
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 13:00-17:00
| width="150" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | Assessing and Exploiting Web Applications with the open source Samurai Web Testing Framework Justin Searle
| width="150" valign="middle" height="120" bgcolor="#ffdf80" align="center" | Java EE Secure Code Review Sahba Kazerooni [http://www.securitycompass.com Security Compass]
| width="150" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | Threat Modeling Express Krishna Raja [http://www.securitycompass.com Security Compass]
| width="150" valign="middle" height="120" bgcolor="#b3ff99" align="center" | Foundations of Web Services and XML Security Dave Wichers [http://www.aspectsecurity.com Aspect Security]
| width="150" valign="middle" height="120" bgcolor="#BCA57A" align="center" | Live CD Matt Tesauro 
|}
====Training 11/11====
{| cellspacing="0" border="2"
|- valign="middle"
| height="60" align="center" colspan="6" style="background: rgb(64, 88, 160) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; color: white;" | '''Day 2 - Nov 11th 2009'''
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" |  
| width="150" valign="middle" height="40" bgcolor="#c0a0a0" align="center" | '''Room 154A'''
| width="150" valign="middle" height="40" bgcolor="#ffdf80" align="center" | '''Room 149B'''
| width="150" valign="middle" height="40" bgcolor="#a0c0e0" align="center" | '''Room 149A'''
| width="150" valign="middle" height="40" bgcolor="#b3ff99" align="center" | '''Room 154B'''
| width="150" valign="middle" height="40" bgcolor="#BCA57A" align="center" | '''Room 155'''
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 09:00-12:00
| width="150" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | Day 2: Assessing and Exploiting Web Applications with the open source Samurai Web Testing Framework Justin Searle
| width="150" valign="middle" height="120" bgcolor="#ffdf80" align="center" | Day 2: Java EE Secure Code Review Sahba Kazerooni [http://www.securitycompass.com Security Compass]
| width="150" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | WebAppSec.php: Developing Secure Web Applications Robert Zakon
| width="150" valign="middle" height="120" bgcolor="#b3ff99" align="center" | Leader and Manager Training - Leading the Development of Secure Applications John Pavone [http://www.aspectsecurity.com Aspect Security]
| width="150" valign="middle" height="120" bgcolor="#BCA57A" align="center" |
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" | 12:00-13:00
| valign="middle" height="40" bgcolor="#909090" align="center" colspan="5" | Lunch
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 13:00-17:00
| width="150" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | Assessing and Exploiting Web Applications with the open source Samurai Web Testing Framework Justin Searle
| width="150" valign="middle" height="120" bgcolor="#ffdf80" align="center" | Java EE Secure Code Review Sahba Kazerooni [http://www.securitycompass.com Security Compass]
| width="150" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | WebAppSec.php: Developing Secure Web Applications Robert Zakon
| width="150" valign="middle" height="120" bgcolor="#b3ff99" align="center" | Leader and Manager Training - Leading the Development of Secure Applications John Pavone [http://www.aspectsecurity.com Aspect Security]
| width="150" valign="middle" height="120" bgcolor="#BCA57A" align="center" | 
|}
====Talks 11/12====
{| cellspacing="0" border="2"
|- valign="middle"
| height="60" align="center" colspan="5" style="background: rgb(64, 88, 160) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; color: white;" | '''Day 1 - Nov 12th 2009'''
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" |  
| width="200" valign="middle" height="40" bgcolor="#c0a0a0" align="center" | '''OWASP'''
| width="200" valign="middle" height="40" bgcolor="#ffdf80" align="center" | '''Tools'''
| width="200" valign="middle" height="40" bgcolor="#a0c0e0" align="center" | '''SDLC'''
| width="200" valign="middle" height="40" bgcolor="#b3ff99" align="center" | '''Web 2.0'''
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 07:30-08:45
| valign="middle" bgcolor="#909090" align="center" colspan="4" | Registration
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 08:45-09:00
| valign="middle" height="30" bgcolor="#e0e0e0" align="center" colspan="4" | Welcome and Opening Remarks
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 09:00-10:00
| valign="middle" height="60" bgcolor="#e0e0e0" align="center" colspan="4" | Keynote: [[AppSecDC Keynote Jarzomnek|Joe Jarzombek]]
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 10:00-10:30
| valign="middle" height="30" bgcolor="#909090" align="center" colspan="4" | Coffee Break & Room Change
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 10:30-11:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[OWASP ESAPI AppSecDC|OWASP ESAPI]] Jeff Williams
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[Clubbing WebApps with a Botnet]] Gunter Ollmann
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[Enterprise Application Security - GE's approach to solving root cause and establishing a Center of Excellence|Enterprise Application Security - GE's approach to solving root cause]] Darren Challey
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[Understanding the Implications of Cloud Computing on Application Security]] Dennis Hurst
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 11:30-12:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[Software Assurance Maturity Model (SAMM)]] Pravir Chandra
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[The Case of Promiscuous Parameters and Other Ongoing Capers in Web Security]] Jacob West
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[Software Development The Next Security Frontier]] Jim Molini
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[Transparent Proxy Abuse]] Robert Auger
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 12:30-13:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[DISA's Application Security and Development STIG: How OWASP Can Help You]] Jason Li
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[OWASP ModSecurity Core Rule Set Project]] Ryan C. Barnett
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[The essential role of infosec in secure software development]] Kenneth R. van Wyk
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[Development Issues Within AJAX Applications: How to Divert Threats]] Lars Ewe
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" | 13:30-14:30
| valign="middle" height="40" bgcolor="#909090" align="center" colspan="4" | Lunch
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 14:30-15:30
| width="200" valign="middle" height="60" bgcolor="#c0a0a0" align="center" | [[Defend Yourself: Integrating Real Time Defenses into Online Applications]] Michael Coates
| width="200" valign="middle" height="60" bgcolor="#ffdf80" align="center" | [[Finding the Hotspots: Web-security testing with the Watcher tool]] Chris Weber
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" rowspan="3" | [[SDLC Panel AppSecDC|SDLC Panel]]   Pravir Chandra Dan Cornell Michael Craigue Dennis Hurst Joey Peloquin David Rook Keith Turpin
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[Social Zombies: Your Friends Want to Eat Your Brains]] Tom Eston/Kevin Johnson
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" rowspan="2" | 15:30-16:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" rowspan="2" | [[The ESAPI Web Application Firewall (ESAPI WAF)|The ESAPI Web Application Firewall]] Arshan Dabirsiaghi
| width="200" valign="middle" height="60" bgcolor="#ffdf80" align="center" | [[One Click Ownage]] Ferruh Mavituna
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" rowspan="2" | [[Cloudy with a chance of 0-day]] Jon Rose/Tom Leavey
|- valign="bottom"
| width="200" valign="middle" height="60" bgcolor="#ffdf80" align="center" | [[Web Application Security Scanner Evaluation Criteria]] Brian Shura
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" rowspan="2" | 16:30-17:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" rowspan="2" | [[OWASP Live CD: An open environment for Web Application Security]] Matt Tesauro / Brad Causey
| width="200" valign="middle" height="60" bgcolor="#ffdf80" align="center" | [[Learning by Breaking: A New Project Insecure Web Apps]] Chuck Willis
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" rowspan="2" | [[Vulnerability Management in an Application Security World]] Dan Cornell
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" rowspan="2" | [[Attacking WCF Web Services]] Brian Holyfield
|- valign="bottom"
| width="200" valign="middle" height="60" bgcolor="#ffdf80" align="center" | [[Synergy! A world where the tools communicate]] 
Josh Abraham

|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" rowspan="2" | 17:30-18:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" rowspan="2" | [[The Entrepreneur's Guide to Career Management]] Lee Kushner
| width="200" valign="middle" height="60" bgcolor="#ffdf80" align="center" | [[Advanced SSL: The good, the bad, and the ugly]] Michael Coates
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" rowspan="2" | [[Threat Modeling by John Steven|Threat Modeling]] John Steven
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" rowspan="2" | [[When Web 2.0 Attacks - Understanding Security Implications of AJAX, Flash and |When Web 2.0 Attacks - Understanding Security Implications of AJAX, Flash and "Highly Interactive" Technologies]] Rafal Los
|- valign="bottom"
| width="200" valign="middle" height="60" bgcolor="#ffdf80" align="center" | [[User input piercing for Cross Site Scripting Attacks]] Matias Blanco
|- valign="bottom"
| width="67" valign="middle" height="60" bgcolor="#7b8abd" | 19:00-????
| valign="middle" height="60" bgcolor="#c0c0c0" align="center" colspan="4" | Reception 
|}
====Talks 11/13====
{| cellspacing="0" border="2"
|- valign="middle"
| height="60" align="center" colspan="5" style="background: rgb(64, 88, 160) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; color: white;" | '''Day 2 - Nov 13th 2009'''
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" |  
| width="200" valign="middle" height="40" bgcolor="#c0a0a0" align="center" | '''Attack & Defend'''
| width="200" valign="middle" height="40" bgcolor="#ffdf80" align="center" | '''Process'''
| width="200" valign="middle" height="40" bgcolor="#a0c0e0" align="center" | '''Metrics'''
| width="200" valign="middle" height="40" bgcolor="#b3ff99" align="center" | '''Compliance'''
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 07:30-09:00
| valign="middle" bgcolor="#909090" align="center" colspan="4" | Registration
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 09:00-10:00
| valign="middle" height="60" bgcolor="#e0e0e0" align="center" colspan="4" | Keynote: TBA
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 10:00-10:30
| valign="middle" height="30" bgcolor="#909090" align="center" colspan="4" | Coffee Break & Room Change
|- valign="bottom"
| width="67" valign="middle" bgcolor="#7b8abd" | 10:30-11:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[Securing the Core JEE Patterns]] Rohit Sethi/Krishna Raja
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[The Big Picture: Web Risks and Assessments Beyond Scanning]] Matt Fisher
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[The Web Hacking Incidents Database]] Ryan C. Barnett
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[Business Logic Automatons: Friend or Foe?]] Ofer Shezaf
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 11:30-12:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[Unicode Transformations: Finding Elusive Vulnerabilities]] Chris Weber
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[Scalable Application Assessments in the Enterprise]] Tom Parker/Lars Ewe
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[Application security metrics from the organization on down to the vulnerabilities]] Chris Wysopal
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[SCAP: Automating our way out of the Vulnerability Wheel of Pain]] Ed Bellis
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 12:30-13:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[Malicious Developers and Enterprise Java Rootkits]] Jeff Williams
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[Secure Software Updates: Update Like Conficker]] Jeremy Allen
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[OWASP Top 10 2010 AppSecDC|OWASP Top 10 - 2010]] Dave Wichers
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[Secure SDLC: The Good, The Bad, and The Ugly]] Joey Peloquin
|- valign="bottom"
| width="67" valign="middle" height="40" bgcolor="#7b8abd" | 13:30-14:30
| valign="middle" height="40" bgcolor="#909090" align="center" colspan="4" | Lunch
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 14:30-15:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[The 10 least-likely and most dangerous people on the Internet]] Robert Hansen
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[Improving application security after an incident]] Cory Scott
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[Hacking by Numbers]] Tom Brennan
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" rowspan="2" | [[AppSecDC09 Federal CISO Panel|Federal CISO Panel]]
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 15:30-16:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | [[Automated vs. Manual Security: You can't filter The Stupid]] David Byrne/Charles Henderson
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | [[Custom Intrusion Detection Techniques for Monitoring Web Applications]] Matthew Olney
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[Building an in-house application security assessment team]] Keith Turpin
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" | 16:30-17:30
| width="200" valign="middle" height="120" bgcolor="#c0a0a0" align="center" | TBD
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" | TBD
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" | [[The OWASP Security Spending Benchmarks Project]] Dr. Boaz Gelbord
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" | [[Promoting Application Security within Federal Government]] Sarbari Gupta
|- valign="bottom"
| width="67" valign="middle" height="120" bgcolor="#7b8abd" rowspan="2" | 17:30-18:30
| width="200" valign="middle" height="60" bgcolor="#c0a0a0" align="center" | [[Manipulating Web Application Interfaces, a new approach to input validation]] Felipe Moreno-Strauch
| width="200" valign="middle" height="120" bgcolor="#ffdf80" align="center" rowspan="2" | [[Deploying Secure Web Applications with OWASP Resources]] Kuai Hinojosa
| width="200" valign="middle" height="120" bgcolor="#a0c0e0" align="center" rowspan="2" | [[SANS Dshield Webhoneypot Project]] Jason Lam
| width="200" valign="middle" height="120" bgcolor="#b3ff99" align="center" rowspan="2" | [[Techniques in Attacking and Defending XML/Web Services]] Mamoon Yunus/Jason Macy
|- valign="bottom"
| width="200" valign="middle" height="60" bgcolor="#c0a0a0" align="center" | [[Injectable Exploits: Two New Tools for Pwning Web Apps and Browsers]] Kevin Johnson, Justin Searle, Frank DiMaggio
|- valign="bottom"
| width="67" valign="middle" height="60" bgcolor="#7b8abd" | 18:30-19:00
| valign="middle" height="60" bgcolor="#c0c0c0" align="center" colspan="4" | Closing Remarks
|}
<headertabs />

===[[OWASP AppSec DC 2009|Back to Conference Page]]===

[[Category:OWASP_AppSec_Conference]] [[Category:OWASP_AppSec_DC_09]]

SAMM - Design Review - 2

2009-09-24T14:25:50Z

Rksethi: minor grammar edit

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Design_Review|abbr=DR|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV2|name=Design Review|obj=Offer assessment services to review software design against comprehensive best practices for security}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Formally offered assessment service to consistently review architecture for security
* Pinpoint security flaws in maintenance-mode and legacy systems
* Deeper understanding amongst project stakeholders on how the software provides assurance protections

====Add’l Success Metrics====
* >80% of stakeholders briefed on status of review requests in past 6 months
* >75% of projects undergoing design review in past 12 months

====Add’l Costs====
* Buildout, training, and maintenance of design review team
* Ongoing project overhead from review activities

====Add’l Personnel====
* Architects (1-2 days/yr)
* Developers (1 day/yr)
* Managers (1 day/yr)
* Security Auditors (2-3 days/yr)

====Related Levels====
* Education & Guidance - 2
* Strategy & Metrics - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Inspect for complete provision of security mechanisms===
For each interface on a module in the high-level architecture diagram, formally iterate through the list of security mechanisms and analyze the system for their provision. This type of analysis should be performed on both internal interfaces, e.g. between tiers, as well as external ones, e.g. those comprising the attack surface.

The six main security mechanisms to consider are authentication, authorization, input validation, output encoding, error handling and logging. Where relevant, also consider the mechanisms of cryptography and session management. For each interface, determine where in the system design each mechanism is provided and note any missing or unclear features as findings.

This analysis should be conducted by security-savvy staff with assistance from the project team for application-specific knowledge. This analysis should be performed once per release, usually toward the end of the design phase. After initial analysis, subsequent releases are required to update the findings based on changes being made during the development cycle.

===B. Deploy design review service for project teams===
Institute a process whereby project stakeholders can request a design review. This service may be provided centrally within the organization or distributed across existing staff, but all reviewers must be trained on performing the reviews completely and consistently.

The review service should be centrally managed in that the review request queue should be triaged by senior managers, architects, and stakeholders that are familiar with the overall business risk profile for the organization. This allows prioritization of project reviews in alignment with overall business risk.

During a design review, the review team should work with project teams to collect information sufficient to formulate an understanding of the attack surface, match project-specific security requirements to design elements, and verify security mechanisms at module interfaces.

</div>
</div>

<div style="float:left; width:100%;"> 
----
----
===Additional Resources===

</div>

__NOTOC__ __NOEDITSECTION__

Podcast 40

2009-09-23T18:39:20Z

Rksethi:

'''[[OWASP_Podcast|OWASP Podcast Series]] #40'''

OWASP Interview with Rohit Sethi 
Recorded July 27, 2009 
Published Sept 23, 2009 

[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/itunes.jpg] [http://www.owasp.org/download/jmanico/podcast.xml https://www.owasp.org/images/d/d3/Feed-icon-32x32.png] [http://www.owasp.org/download/jmanico/owasp_podcast_40.mp3 mp3]

==Participants==
<ul>
<li>Rohit Sethi, Director of Professional Services, Security Compass, is a specialist in threat modeling, application security reviews, and building security controls into the software development life cycle (SDLC). Mr. Sethi is a frequent guest speaker and instructor at several conferences, including RSA, Shmoocon, and CSI. He has written articles for Security Focus and the Web Application Security Consortium (WASC), and has been quoted as an expert in application security for ITWorldCanada and Computer World.
At Security Compass, Rohit teaches students various topics on web application security in cities across North America. He has also managed and performed extensive threat analysis, source code reviews, and penetration testing for clients in financial services, utilities, telecommunications and healthcare. He is often consulted for his dual expertise in information security and software engineering.</li>
</ul>

==Questions==
* How did your team come up with the idea of writing this paper?
* How does the security analysis of Core J2EE patterns differ from the Core Security patterns book? Do we need both?
* Why did you choose the J2EE Core Design patterns and not the Gang of Four Design Patterns?
* What value does this analysis have? Who is actually going to use this stuff?
* How does this design pattern analysis differ from the most popular design-time security activity: threat modeling?
* The analysis doesn’t have a notion of “risk” – it doesn’t articulate the difference between say an application on Intranet versus one on the Internet.
* What are the next steps for this OWASP project?
* How can people contribute to the project?

Category:OWASP Security Analysis of Core J2EE Design Patterns Project

2009-08-03T03:40:53Z

Rksethi:

==== Main ====

=== Introduction ===

Most application security experts focus on a single activity for integrating design into the SDLC: threat modeling . Threat modeling is excellent at approximating an application’s attack surface but, in our experience, developers sometimes do not have the time, budget or security know-how to build an adequate threat model. Perhaps more importantly, developers cannot create a comprehensive threat model until they complete the application design.

This reference guide aims at dispensing security best practices to developers to make security decisions during design. We focus on one of the most important concepts in modern software engineering: design patterns. Ever since the publication of the seminal Design Patterns Book , developers have reused common patterns such as Singleton and Factory Method in large-scale software projects. Design patterns offer a common vocabulary to discuss application design independent of implementation details.
One of the most critically acclaimed pattern collections in the Java Enterprise Edition (JEE) community is the Core J2EE Patterns book by Deepak Alur, Dan Malks and John Crupi . Developers regularly implement patterns such as “Application Controller”, “Data Access Object” or “Session Façade” in large, distributed JEE applications and in frameworks such as Spring and Apache Struts . We aim to dispense security best practices so that developers can introduce security features and avoid vulnerabilities independent of their underlying technology choices such as which Model View Controller (MVC) framework to use.

Java developers currently have access to patterns for security code (e.g. how to develop authentication, how to implement cryptography) such as the Core Security Patterns book. We hope our guide will help address the critical shortage of advice on securely coding using existing design patterns. Your feedback is critical to improving the quality and applicability of the best practices listed in the Security Analysis of Core J2EE Design Patterns. Please contact the mailing list at owasp_security_analysis_j2ee@lists.owasp.org with comments or questions and help improve the guide for future developers.

The project is broken up into three categories:
*[[:Category:OWASP Security Analysis of Core J2EE Design Patterns Project/PresentationTier|Presentation Tier Patterns]]
*[[:Category:OWASP Security Analysis of Core J2EE Design Patterns Project/BusinessTier|Business Tier Patterns]]
*[[:Category:OWASP Security Analysis of Core J2EE Design Patterns Project/EISTier|EIS Tier Patterns]]

==Downloadable Versions==
You can download the OWASP Security Analysis of Core J2EE Design Patterns here:

* [https://www.owasp.org/index.php/File:Security_Analysis_of_Core_JEE_Design_Patterns_v0.1.doc Editable DOC Version]

* [http://www.owasp.org/index.php/File:Security_Analysis_of_Core_JEE_Design_Patterns_v0.01.pdf PDF Version]

The source for the images used in the patterns can be downloaded [http://www.owasp.org/index.php/File:Secure_pattern_images.ppt here]

==== Project Identification ====
{{Template:OWASP Security Analysis of Core J2EE Design Patterns Project - GPC Tab}}

[[Category:OWASP Project|Security Analysis of Core J2EE Design Patterns Project]]
[[Category:OWASP Document]]
[[Category:OWASP Alpha Quality Document]]

__NOTOC__
<headertabs/>

''''' Project's License:''''' [http://www.gnu.org/licenses/gpl-3.0.html '''GPL v3''']

File:Security Analysis of Core JEE Design Patterns v0.01.pdf

2009-08-03T03:21:04Z

Rksethi: PDF version of the Security Analysis fo Core java EE Design patterns project

PDF version of the Security Analysis fo Core java EE Design patterns project

File:Security Analysis of Core JEE Design Patterns v0.1.doc

2009-08-03T03:19:29Z

Rksethi: Editable version of the Core Java EE Patterns project

Editable version of the Core Java EE Patterns project

File:Secure pattern images.ppt

2009-08-03T03:18:03Z

Rksethi: Images for the Security Analysis of the J2EE Core Patterns project

Images for the Security Analysis of the J2EE Core Patterns project

Category:OWASP Security Analysis of Core J2EE Design Patterns Project/EISTier

2009-07-09T21:26:11Z

Rksethi:

==== Data Access Object ====
Most if not all JEE applications require access to enterprise or business data from a persistent data store. Data, however, can reside in many different kinds of repositories, from relational databases to mainframe or legacy systems. Mixing application logic with persistence logic introduces tight coupling and creates a maintenance nightmare for an application. The ''Data Access Object'' (DAO) pattern allows for the encapsulation of all access to the persistent data store and manages connections to the data tier, while hiding the implementation details of the persistence API from the client. A <tt>DataAccessObject</tt> implements create, find, update, and delete operations.
[[File:J2EEPatterns-Data Access Object.JPG]]
== Analysis ==
=== Avoid ===

'''Interpreter Injection'''

''DataAccessObjects'' (''DAOs'') interact with interpreters such as SQL-enabled databases or Lightweight Directory Access Protocol (LDAP) enabled repositories. ''DAOs'' are therefore susceptible to injection-style attacks such as SQL injection. Avoid SQL attacks by using properly constructed prepared statements or stored procedures. For other interpreters, such as LDAP or XML data stores, use appropriate encoding to escape potentially malicious characters such as LDAP encoding or XML encoding. Remember to use a whitelist approach for encoding rather than a blacklist approach.

You may not find encoding methods for some interpreters, leaving your code highly susceptible to interpreter injection. In these cases use strict whitelist input validation.

'''Improper Resource Closing'''

Developers often forget to properly close resources such as database connections. Always close resources in a finally block, check for null pointers before closing on an object, and catch and handle any possible exception that may occur during resource closing ''within ''the finally block.

'''Unencrypted Connection String Storage'''

In order to communicate with a database or other backend server, most applications use a connection string that includes a user name and password. Developers often store this connection string un-encrypted in server configuration files such as server.xml. Malicious insiders and external attackers who exploit path traversal vulnerabilities may be able to use a plaintext connection string to gain unauthorized access to the database.

Encrypt database and other server credentials during storage. Unfortunately, any method you use to encrypt the connection string has weaknesses. For instance, WebLogic provides an encrypt utility to encrypt any clear text property within a configuration file, but the utility relies on an encryption key stored on the application server. Other methods, such as Jasypt’s password based encryption mechanisms require either manual intervention or remote server communication during startup to implement securely. Nevertheless, storing a password plaintext is the least secure option so always use some form of encryption.

'''Exposing Implementation-specific Exceptions'''

A <tt>DataAccessObject</tt> makes a direct connection to the persistence layer and executes queries against it, returning data to the client. Such access requires correct handling and translation of exceptions that stem from the data tier. Ensure that exceptions that are thrown from implementation-specific packages, such as <tt>java.sql.*</tt> or <tt>javax.sql.*</tt> are handled and logged appropriately in the <tt>DataAccessObject</tt> and are not simply propagated to the client. One popular strategy is to log the exception and throw a custom-made exception to the client, such as a <tt>DAOException</tt>.

==== Service Activator ====
In JEE applications, certain business services can involve complex processes that may consume considerable time and resources. In such cases, developers often prefer to invoke these services asynchronously. The ''Service Activator ''pattern allows for the reception of asynchronous requests from a client and invokes multiple business services. A <tt>ServiceActivator</tt> class is typically implemented as a JMS listener that receives and parses messages from the client, identifies and invokes the correct business service to process the request, and informs the client of the outcome.
[[File:J2EEPatterns-Service Activator.JPG]]
== Analysis ==
=== Avoid ===

'''Denial of Service in Message Queues'''

Attackers may fill up message queues to launch a Denial of Service (DOS) attacks. Perform a sanity check on the size of a message prior to accepting it into the message queue.

'''Unauthenticated Messages'''

Allowing unauthenticated access to <tt>BusinessServices</tt> or other middle tier components leaves applications susceptible to insider attacks. Build system-to-system authentication into the <tt>ServiceActivator</tt> itself or use container-managed mechanisms such as mutual certificate authentication.

Another approach is to add authentication credentials into each message, similar to WS-Security authentication in web services. Remember, however, that processor-intensive authentication functions may themselves leave applications vulnerable to DOS attacks.

'''Unauthorized Messages'''

<tt>BusinessServices</tt> often expose critical middle tier or backend functions. Include functional authorization checks to protect <tt>BusinessServices</tt> from authenticated user privilege escalation.

Developers sometimes skip middle tier authorization, relying instead on functional authorization checks in the presentation tier (e.g. application controller checks). A presentation-tier-only authorization approach might work with strong infrastructure-level access controls. Remember, however, that you must duplicate authorization checks on all channels that access the business service. Wherever possible use the <tt>ServiceActivator</tt> to enforce consistent access control for all messages.

'''Dynamic SQL in Database Response Strategy'''

The Database Response strategy stores the message response in a database that a client subsequently polls. As with other database interaction patterns, remember to use properly configure Prepared Statements or stored procedures to avoid SQL injection.

'''Unvalidated Email Addresses in Email Response Strategy'''

The Email Response strategy sends a message response though email. Malicious users who can influence the response may provide multiple email addresses and use the server as a gateway to send unauthorized spam messages. Use whitelist validation to ensure that users supply only one email address.

==== Domain Store ====
Patterns such as ''Data Access Object'' emphasize the value of separating persistence details <tt>from BusinessObjects</tt>. Some applications must also separate persistence details from the application object model. The ''Domain Store ''pattern allows for this separation, unlike container-managed persistence and bean-managed persistence strategies, which tie persistence code with the object model. The ''Domain Store'' pattern can be implemented using either a custom persistence framework or a persistence product, such as Java Data Objects.
[[File:J2EEPatterns-Domain Store.JPG]]
== Analysis ==
=== Avoid ===

'''Interpreter Injection'''

''Domain Stores'' interact with interpreters such as SQL-enabled databases or Lightweight Directory Access Protocol (LDAP) enabled repositories. DAOs are therefore susceptible to injection-style attacks such as SQL injection. Avoid SQL attacks by using properly constructed prepared statements or stored procedures. For other interpreters, such as LDAP or XML data stores, use appropriate encoding to escape potentially malicious characters such as LDAP encoding or XML encoding. Remember to use a whitelist approach for encoding rather than a blacklist approach.

You may not find encoding methods for some interpreters, leaving your code highly susceptible to interpreter injection. In these cases use strict whitelist input validation.

'''Properly Close Resources'''

Developers often forget to properly close resources such as database connections. Always close resources in a finally block, check for null pointers before closing on an object, and catch and handle any possible exception that may occur during resource closing ''within ''the finally block.

'''Connection String Storage'''

In order to communicate with a database or other backend server, most applications use a connection string that includes a user name and password. Most developers store this connection string un-encrypted in server configuration files such as server.xml. Malicious insiders and external attackers who exploit path traversal vulnerabilities may be able to use a plaintext connection string to gain unauthorized access to the database.

Encrypt database and other server credentials during storage. Unfortunately, any method you use to encrypt the connection string has weaknesses. For instance, WebLogic provides an encrypt utility to encrypt any clear text property within a configuration file, but the utility relies on an encryption key stored on the application server. Other methods, such as Jasypt’s password based encryption mechanisms require either manual intervention or remote server communication during startup to implement securely. Nevertheless, storing a password plaintext is the least secure option so always use some form of encryption.

==== Web Service Broker ====
A web service is a popular way of exposing business services to other applications. The integration of different systems, however, can typically involve incompatibilities and complexities. Furthermore, it is desirable to limit the set of services that are exposed by an application as web services. The ''Web Service Broker'' pattern uses XML and web protocols to selectively expose and broker the services of an application. A <tt>WebServiceBroker</tt> coordinates the interaction among services, collects responses and performs transactions. It is typically exposed using a WSDL. The <tt>EndpointProcessor</tt> class is the entry point into the web service, and processes the client request. The <tt>EndpointProcessor</tt> then invokes the web service through the <tt>WebServiceBroker</tt>, which brokers to one or more services.
[[File:J2EEPatterns-Web Services Broker.JPG]]
== Analysis ==
=== Avoid ===

'''XML Denial of Service'''

Attackers may try Denial of Service (DOS) attacks on XML parsers and validators. Ensure either the web server, application server or an ''Intercepting Filter'' performs a sanity check on the ''size'' of the XML message '''prior'' '''''to''''' '''''XML parsing or validation to prevent DOS conditions.

'''Disclosure of Information in SOAP Faults'''

One of the most common information disclosure vulnerabilities in web services is when error messages disclose full stack trace information and/or other internal details. Stack traces are often embedded in SOAP faults by default. Turn this feature off and return generic error messages to clients.

'''Publishing WSDL Files'''

Web Services Description Language (WSDL) files provide details on how to access web services and are very useful to attackers. Many SOAP frameworks publish the WSDL by default (e.g. http://url/path?WSDL). Turn this feature off.

'''Using DTDs'''

Document Type Definition (DTD) validators may be susceptible to a variety of attacks such as entity reference attacks. If possible, use XML Schema Definition (XSD) validators instead. If a DTD validator is required, ensure that the prologue of the DTD is not supplied by the message sender. Also ensure that external entity references are disabled unless absolutely necessary.

'''Unvalidated Input on Web Services'''

Web services often expose critical Enterprise Information Systems (EIS) that are vulnerable to interpreter injection attacks. Protect EIS systems at the web service level with strict input validation on all client-supplied parameters. XML encode untrusted data prior to its inclusion in a web service / XML response.

'''Unauthenticated and Unauthorized Web Service Requests'''

Like the other middle and EIS tier components, developers often employ weaker or altogether ignore authentication and authorization controls on web service requests – making web services an ideal target for attackers. Authenticate and authorize every web service request.

__NOTOC__

<headertabs/>

Category:OWASP Security Analysis of Core J2EE Design Patterns Project/BusinessTier

2009-07-09T21:24:57Z

Rksethi:

'''Middle and Integration Tier Security'''

The majority of Open Web Application Security Project (OWASP) Top 10 vulnerabilities occur in the presentation tier. While attacks do exploit vulnerabilities in the business and enterprise integration tiers, the attacks typically ''originate'' from presentation tier web pages. For example, a SQL injection payload is usually delivered as part of an HTTP request to a web page, but the exploit itself usually occurs in the integration tier.

We examine the business and integration tier patterns for security from two perspectives:

# Attacks originating from the presentation tier, such as a Cross-Site Scripting (XSS) attack sent by a malicious web client
# Attacks originating from the business and integration tiers, such as an unauthorized web service request to an integration tier device

The second perspective is important enough to warrant special attention. Many organizations ignore attacks originating from within the internal network. Unfortunately, the notion that organizations can completely trust insiders is flawed.In application security, developers sometimes argue that the process of launching an attack in the business or integration tiers is complicated and therefore less likely. As organizations increasingly adopt Service Oriented Architectures (SOA) in business and integration tiers with standards like Simple Object Access Protocol (SOAP) and Representation State Transfer (REST), security tools targeting these protocols are becoming readily available .

Even if you have not yet experienced an insider security incident, remember that insider attacks are on the rise and the systems you architect today may remain in production for years or even decades to come. Create secure applications by building-in protection from insider threats.

==== Business Delegate ====
The ''Business Delegate'' serves as an abstraction of the business service classes of the business tier from the client tier. Implementing a business delegate effectively reduces the coupling between the client tier and business tier, and allows for greater flexibility and maintainability of the application code. The most significant benefit of this pattern is the capability to hide potentially sensitive implementation details of the business services from the calling client tier. Furthermore, a business delegate can effectively handle business tier exceptions (such as <tt>java.rmi.Remote</tt> exceptions) and translate them into more meaningful, application-level exceptions to be forwarded to the client.
[[File:J2EEPatterns-Business Delegate.JPG]]
== Analysis ==
=== Use to Implement ===

'''Whitelist input validation'''

The DelegateProxyStrategy uses <tt>BusinessDelegate </tt>objects as simple proxies to underlying services. Each <tt>BusinessDelegate</tt> is business context specific and is therefore a good place to implement whitelist security input validation. Remember, however, that <tt>BusinessDelegate</tt> validation only applies to input originating from the presentation tier. You need to duplicate input validation functionality for all other channels that access the same business tier, such as web services.

'''Exception Handling'''

A property of sound exception management is the practice of throwing an exception that is meaningful to the target tier. For example, a <tt>JMSException</tt> caught by a business tier object should not be propagated to the client tier. Instead, a custom, application-level, exception should be sent to the client tier. <tt>BusinessDelegate</tt> can effectively perform this translation, intercepting service-level exceptions from the business tier and throwing application-level exceptions to the client tier. This practice helps protect implementation-level details of the business services from calling clients. Note that exceptions can occur within and across many tiers, and restricting exception handling logic to the <tt>BusinessDelegate</tt> alone is insufficient.

==== Service Locator ====
JEE application modules from the client tier often need to access business or integration tier services, such as JMS components, EJB components, or data sources. These components are typically housed in a central registry. In order to communicate with this registry, the client uses the Java Naming and Directory Interface (JNDI) API to obtain an <tt>InitialContext</tt> object containing the desired object name. Unfortunately, this process can be repeated across several clients, increasing complexity and decreasing performance. The ''Service Locator ''pattern implements a <tt>ServiceLocator</tt> singleton class that encapsulates API lookups and lookup complexities, and provides an easy-to-use interface for the client tier. This pattern helps promote reuse of resource-intensive lookups, and decouples the client tier from the underlying lookup implementation details.
[[File:J2EEPatterns-Service Locator.JPG]]
== Analysis ==
=== Avoid ===

'''Memory Leaks in Caching'''

Developers typically use caching to improve performance. If you are not careful about implementing caching, however, you can actually degrade performance over time.

Many developers use collections like HashMaps to maintain references to cached objects. Suppose you maintain a cache using a HashMap where the keys are Strings describing services in the <tt>ServiceLocator</tt> and the values are <tt>Target</tt> objects. After a period of inactivity you want to remove the Target reference to free memory. Simply running a method like <tt>close()</tt> on the Target object will not actually make the object eligible for garbage collection because the cache HashMap still maintains a pointer to the Target object. You must remember to remove references from the HashMap otherwise you will experience memory degradation overtime and possibly suffer from Denial of Service (DoS) conditions.

Use a WeakHashMap or another collection of WeakReferences or SoftReferences rather than traditional collections to maintain caches. A WeakHashMap maintains WeakReferences to key and value objects, meaning the cache will allow key and value objects to be eligible for garbage collection. Using WeakReferences allows the garbage collector to automatically remove objects from the cache when necessary, as long as the application does not maintain any strong references (i.e. regular pointers) to the object.

If you cannot use WeakReferences or SoftReferences then ensure you regularly remove objects from the cache.

'''Open Access to UDDI'''

Many developers opt to use web services instead of more traditional middle tier technologies like Enterprise Java Beans (EJBs). In Service Oriented Architecture (SOAs), Universal Description, Discovery and Integration (UDDI), registries often play the role of Service Locator. UDDIs are extremely valuable to attackers since they house Web Service Definition Language (WSDL) files that provide blueprints of how and where to access web services. If you use UDDI, ensure that only authorized users can access registries. Consider using mutual certificate authentication with each UDDI request. Also ensure that an authenticated user is actually authorized to access specific parts of the registry.

==== Session Façade ====
Business components in JEE applications often interact with many different services, each of which may involve complex processes. Exposing these components directly to the client tier is undesirable, as this leads to a tight coupling between the client and business tiers, and can lead to code duplication. The ''Session Façade'' pattern is used to encapsulate the services of the business tier and acts as an interface to the client. Developers typically implement a <tt>SessionFacade</tt> class as a session bean and expose only the interfaces that clients require, hiding the complex interdependencies between <tt>BusinessObjects</tt>. Very little or no business logic should be placed within a <tt>SessionFacade</tt>.
[[File:J2EEPatterns-Session Facade.JPG]]
== Analysis ==
=== Avoid ===

'''Unauthenticated Client Calls'''

Allowing unauthenticated access to Enterprise Java Beans (EJBs), web services, or other middle tier components leaves applications susceptible to insider attacks. In some cases, developers configure application servers to allow open access to the underlying DataSources such as databases. Build system-to-system authentication into the Session Façade itself or use container-managed mechanisms such as mutual certificate authentication. Maybe also mention that DataSources can be made available by app servers for anyone on the network to retrieve.

'''Deserializing Objects from Untrusted Sources'''

Developers often use Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP) to communicate between the presentation and business tiers. RMI uses Java serialization and deserialization to transfer objects over the network. Treat deserialization as a dangerous function because some Java Virtual Machines are vulnerable to Denial Of Service (DOS) conditions when attackers transmit specially crafted serialized objects. Remember to treat client or third party-supplied serialized objects as untrusted input; malicious users can modify the serialized version of an object to inject malicious data or even supply objects running malicious code

Decrease the risk of a DOS attack by authenticating requests ''prior ''to deserializing data. Also upgrade and patch Java Virtual Machines just like other critical software components such as operating systems.

=== Use to Implement ===

'''Middle Tier Authorization at Session Facade'''

''Session Façades'' are entry points to the middle tier, meaning they are ideal for handling middle-tier authorization. Ensure clients have sufficient privileges to access any function exposed through ''Session Façades''.

==== Application Service ====
While the ''Session Façade'' pattern allows for the decoupling of the client tier from the business tier and encapsulates the services of the business tier, <tt>SessionFacade </tt>objects should not encapsulate business logic. An application may contain multiple <tt>BusinessObjects</tt> (see the next pattern) that perform distinct services, but placing the business logic here introduces coupling between <tt>BusinessObjects</tt>. The ''Application Service'' pattern provides a uniform service layer for the client. An <tt>ApplicationService</tt> class acts as a central location to implement business logic that encapsulates a specific business service of the application and reduces coupling between <tt>BusinessObjects</tt>. The <tt>ApplicationService</tt> object can implement common logic acting on different <tt>BusinessObjects</tt>, implement use case-specific business logic, invoke business methods in a <tt>BusinessObject</tt>, or methods in other <tt>ApplicationServices</tt>. An <tt>ApplicationService</tt> is commonly implemented as a plain-old Java object (POJO).
[[File:J2EEPatterns-Application Service.JPG]]
== Analysis ==
'''Unauthenticated Client Calls'''

Allowing unauthenticated access to Enterprise Java Beans (EJBs), web services, or other middle tier components leaves applications susceptible to insider attacks. Build system-to-system authentication into the ''Application Service ''itself or use container-managed mechanisms such as mutual certificate authentication.

==== Business Object ====
Ideally, a multi-tiered application is decoupled into presentation, business and data tiers. Of the three, the business tier often results in duplicated code and tight coupling with data logic. The ''Business Object ''pattern allows for the separation of the business state and behavior from the rest of the application, and the centralization of both. <tt>BusinessObjects </tt>encapsulate the core business data, and implement the desired business behavior, all while separating persistence logic from the business logic. Using this pattern, the client interacts directly with a <tt>BusinessObject</tt> that will delegate behavior to one or more business entities, and manage its own persistence logic using a desired persistence strategy, such as POJOs or EJB entity beans.
[[File:J2EEPatterns-Business Object.JPG]]
== Analysis ==
=== General Notes ===

In most cases, ''Business Objects'' do not implement common security features such as authentication and authorization, data validation and encoding, or session management. Ideally, a ''Business Object'' should simply provide accessor methods and offer basic business logic functions. You still need to develop with standard secure coding practices such as error handling and logging.

==== Composite Entity ====
''Business Objects ''separate business logic and business data. While Enterprise Java Beans (EJB) entity beans are one way to implement ''Business Objects'', they come with complexity and network overhead. The ''Composite Entity'' pattern uses both local entity beans and Plain Old Java Objects (POJOs) to implement persistent ''Business Objects''. The ''Composite Entity'' can aggregate a single <tt>BusinessObject </tt>and its related dependant <tt>BusinessObjects</tt> into coarse-grained entity beans. Using this pattern allows developers to leverage the EJB architecture, such as container-managed transactions, security, and persistence.
[[File:J2EEPatterns-Composite Entity.JPG]]
== Analysis ==
=== General Notes ===

'''Entity Bean Alternatives'''

With the rise of third party persistence frameworks such as Hibernate and IBATIS, fewer developers use entity beans. In general, application developers can take security advice for ''Composite Entity'' and apply it to persistence frameworks other than Entity Beans.

=== Avoid ===

'''Interpreter Injection'''

If you use bean managed persistence (BMP) with entity beans, then protect against injection attacks by using secure prepared statements, stored procedures, or appropriate encoding for non-database persistence mechanisms such as XML encoding for creating XML documents.

In most cases persistence frameworks like Hibernate automatically protect against SQL injection. Remember, however, that many persistence frameworks allow you to create custom queries through special functions like Hibernate Query Language (HQL). If you dynamically concatenate strings to create custom queries, then your application may be vulnerable to injection despite the fact that you use a persistence framework.

'''Plaintext Transmission of Confidential Data'''

The Composite Transfer Object strategy creates a <tt>TransferObject</tt> to send to a remote client. Many organizations do not use encrypted communication channels within the internal network, so a malicious insider attacker might sniff confidential data within a <tt>TransferObject</tt> during transmission. Either do not serialize confidential variables or use an encrypted communication channel like Secure Socket Layer (SSL) during transmission.

==== Transfer Object ====
Integration patterns such as ''Session Façade'' and ''Business Object'' often need to return data to the client. A client, however, may potentially call several getter methods on these objects, and when these patterns are implemented as remote enterprise beans, a significant network overhead is incurred with each call. The ''Transfer Object'' pattern is designed to optimize the transfer of data to the client tier. A <tt>TransferObject</tt> encapsulates all data elements within a single structure and returns this structure to the calling client. The ''Transfer Object'' pattern serves to reduce network traffic, transfer bulk data with far fewer remote calls, and promote code reuse.
[[File:J2EEPatterns-Transfer Object.JPG]]
== Analysis ==
=== Avoid ===

'''Plaintext Transmission of Confidential Data'''

Many organizations do not use encrypted communication channels within the internal network, so a malicious insider attacker might sniff confidential data within a <tt>TransferObject</tt> during transmission. Either do not serialize confidential variables or use an encrypted communication channel like Secure Socket Layer (SSL) during transmission.

==== Transfer Object Assembler ====
Clients often need to access business data from potentially many different <tt>BusinessObjects</tt>, <tt>TransferObjects</tt>, <tt>or ApplicationServices</tt> to perform processing. Direct access to these different components by the client can lead to tight coupling between tiers and code duplication. The ''Transfer Object Assembler ''pattern provides an efficient way to collect multiple <tt>Transfer Objects</tt> across different business components and return the information to the client. Think of ''Transfer Object Assembler ''as a factory to create <tt>Transfer Objects</tt>. The client invokes the <tt>TransferObjectAssembler</tt>, which retrieves and processes different <tt>TransferObjects</tt> from the business tier, constructs a composite <tt>TransferObject</tt> known as the <tt>ApplicationModel</tt>, and returns the <tt>ApplicationModel</tt> to the client. Note that the client uses the <tt>ApplicationModel</tt> for read-only purposes, and does not modify any data contained within it.
[[File:J2EEPatterns-Transfer Object Assembler.JPG]]
== Analysis ==
'''Unauthenticated Client Calls'''

Allowing unauthenticated access to <tt>TransferObjectAssemblers</tt> or other middle tier components leaves applications susceptible to insider attacks. If you expose your <tt>TransferObjectAssemblers</tt> directly to clients, then build in system-to-system authentication or use container-managed mechanisms such as mutual certificate authentication.

==== Value List Handler ====
Searching is a common operation in JEE applications. A search typically is initiated by the client tier and execution by the business tier. More concretely, this can involve several invocations of entity bean finder methods or <tt>DataAccessObjects</tt> by the client, particularly if the result set of the search is large. This introduces network overhead. The ''Value List Handler ''pattern affords efficient searching and result set caching, which can allow the client to traverse and select desired objects from the result set. A <tt>ValueListHandler</tt> object executes the search and obtains the results in a <tt>ValueList</tt>. The <tt>ValueList</tt> is normally created and manipulated by the <tt>ValueListHandler</tt> through a <tt>DataAccessObject</tt>. The <tt>ValueList</tt> is returned to the client, and the client can iterate through the list contents using a <tt>ValueListIterator</tt>.
[[File:J2EEPatterns-Value List Handler.JPG]]
== Analysis ==
=== General Notes ===

In most cases, ''Value List Handlers ''do not implement common security features such as authentication and authorization, data validation and encoding, or session management. You still need to develop with standard secure coding practices such as error handling and logging.

__NOTOC__

<headertabs/>

Category:OWASP Security Analysis of Core J2EE Design Patterns Project/PresentationTier

2009-07-09T21:21:40Z

Rksethi:

==== Intercepting Filter ====
The ''Intercepting Filter'' pattern may be used in instances where there is the need to execute logic before and after the main processing of a request (pre and postprocessing). The logic resides in <tt>Filter</tt> objects and typically consist of code that is common across multiple requests. The Servlet 2.3 Specification provides a mechanism for building filters and chaining of <tt>Filters</tt> through configuration. A <tt>FilterManager</tt> controls the execution of a number of loosely-coupled <tt>Filters</tt> (referred to as a <tt>FilterChain</tt>), each of which performs a specific action. This Standard Filter Strategy can also be replaced by a Custom Filter Strategy which replaces the Servlet Specification’s object wrapping with a custom implementation.

[[File:J2EEPatterns-Intercepting Filter.JPG]]

== Analysis ==
=== Avoid ===

'''Relying Only on a Blacklist Validation Filter'''

Developers often use blacklists in <tt>Filters</tt> as their only line of defense against input attacks such as Cross Site Scripting (XSS). Attackers constantly circumvent blacklists because of errors in canonicalization and character encoding. In order to sufficiently protect applications, do not rely on a blacklist validation filter as the sole means of protection; also validate input with strict whitelists on all input and/or encode data at every sink.

'''Output Encoding in Filter'''

Encoding data before forwarding requests to the <tt>Target</tt> is too early because the data is too far from the sink point and may actually end up in several sink points, each requiring a different form of encoding. For instance, suppose an application uses a client-supplied e-mail address in a Structured Query Language (SQL) query, a Lightweight Directory Access Protocol (LDAP) lookup, and within a Hyper Text Markup Language (HTML) page. SQL, LDAP, and HTML are all different sinks and each requires a unique form of encoding. It may be impossible to encode input at the <tt>Filter</tt> for all three sink types without breaking functionality. On the other hand, performing encoding after the <tt>Target</tt> returns data is too late since data will have already reached the sink by the time it reaches the <tt>Filter</tt>.

'''Overly Generous Whitelist Validation'''

While attempting to implement whitelist validation, developers often allow a large range of characters that may include potentially malicious characters. For example, some developers will allow all printable ASCII characters which contain malicious XSS and SQL injection characters such as less than signs and semi-colons. If your whitelists are not sufficiently restrictive, perform additional encoding at each data sink.

'''XML Denial of Service'''

If you use ''Intercepting Filter'' to preprocess XML messages, then remember that attackers may try many different Denial of Service (DOS) attacks on XML parsers and validators. Ensure either the web server, application server, or the first <tt>Filter</tt> on the chain performs a sanity check on the ''size'' of the XML message '''prior'' '''''to''''' '''''XML parsing or validation to prevent DOS conditions.

'''Logging Arbitrary HTTP Parameters'''

A common cross-cutting application security concern is logging and monitoring of user actions. Although an ''Intercepting Filter'' is ideally situated to log incoming requests, avoid logging entire HTTP requests. HTTP requests contain user-supplied parameters which often include confidential data such as passwords, credit card numbers and personally identifiable information (PII) such as an address. Logging confidential data or PII may be in violation of privacy and/or security regulations.

=== Use to Implement ===

'''Input Validation'''

Use an ''Intercepting Filter'' to implement security input validation consistently across all presentation tier pages including both Servlets and JSPs. The <tt>Filter’s</tt> position between the client and the front/application controllers make it an ideal location for a blacklist against all input. Ideally, developers should always employ whitelist validation rather than blacklist validation; however, in practice developers often select blacklist validation due to the difficulty in creating whitelists. In cases where blacklist validation is used, ensure that additional encoding is performed at each data sink (e.g. HTML and JavaScript encoding).

'''Page-Level Authorization'''

Use an ''Intercepting Filter'' to examine requests from the client to ensure that a user is authorized to access a particular page. Centralizing authorization checks removes the burden of including explicit page-level authorization deeper in the application. The Spring Security framework employs an ''Intercepting Filter'' for authorization.

Remember that page-level authorization is only one component of a complete authorization scheme. Perform authorization at the command level if you use <tt>Command</tt> objects, the parameter level such as HTTP request parameters, and at the business logic level such as ''Business Delegate'' or ''Session Façade''. Remember to propagate user access control information such as users’ roles to other design layers like the ''Application Controller''. The OWASP Enterprise Security Application Programming Interface (ESAPI) uses <tt>ThreadLocal</tt> objects to maintain user authorization data throughout the life of a thread.

'''Session Management'''

Session management is usually one of the first security controls that an application applies to a request. Aside from container-managed session management controls such as idle timeout and invalidation, some applications implement controls such as fixed session timeout, session rotation and session-IP correlation through proprietary code. Use an ''Intercepting Filter ''to apply the additional session management controls before each request is processed.

Invalidating the current session token and assigning a new session token after authentication is a common defense against session fixation attacks. This control can also be handled in an ''Intercepting Filter ''specifically configured to intercept authentication requests. You may alternatively use a generic session management <tt>Filter</tt> that intercepts all requests, and then use conditional logic to check, specifically, for authentication requests in order to apply a defense against session fixation attacks. Be aware, however, that using a generic <tt>Filter</tt> introduces maintenance overhead when you implement new authentication paths.

'''Audit Logging'''

Since ''Intercepting Filters'' are often designed to intercept all requests, they are ideally situated to perform logging of user actions for auditing purposes. Consider implementing a <tt>Filter</tt> that intercepts all requests and logs information such as:

* Username for authenticated requests
* Timestamp of request
* Resource requested
* Response type such as success, error, etc.

The logging filter should be configured as the first <tt>Filter</tt> in the chain in order to log all requests irrespective of any errors that may occur in <tt>Filters</tt> further down the chain. Never log confidential or PII data.

==== Front Controller ====
Processing a request typically consists of a number of request handling activities such as protocol handling, navigation and routing, core processing, and dispatch as well as view processingvii. A controller provides a place for centralizing this common logic performed for each request. Typically implemented as a Servlet, the ''Front Controller ''can perform this common logic and further delegate the action management (servicing the request) and view management (dispatching a view for user output) activities to an ''Application Controller''. This pattern provides centralization of request control logic and partitioning of an application between control and processing.
[[File:J2EEPatterns-Front Controller.JPG]]
== Analysis ==
=== Avoid ===

'''Physical Resource Mapping'''

The Physical Resource Mapping strategy maps user-supplied parameters directly to physical resources such as files residing on the server. Attackers often take advantage of this strategy to gain illicit access to resources. In a directory traversal exploit, for example, clients supply the server with the physical location of a file such as “file=statement_060609.pdf”. Attackers attempt to access other files on the server by supplying malicious parameters such as “file=../../../../../etc/password”. If the application blindly accepts and opens any user-supplied filename then the attacker may have access to a whole array of sensitive files, including properties and configuration files that often contain hard-coded passwords.

Developers sometimes mitigate directory traversal attacks by checking for the presence of a specific prefix or suffix, such as verifying that the file parameter begins with “statement” and ends with “.pdf”. A crafty attacker can take advantage of null character injection and enter “file=statement_060609.pdf/../../../../etc/password%00.pdf”. Java will see that the resource beings with “statement” and ends with “.pdf” whereas the operating system may actually drop all remaining characters after the %00 null terminator and open the password file.

As a rule, avoid using the Physical Resource Mapping strategy altogether. If you must use this strategy, ensure that the application operates in a sandboxed environment with the Java Security Manager and/or employs sufficient operating system controls to protect resources from unauthorized access.

'''Invoking Commands Without Sufficient Authorization'''

In the Command and Controller strategy, users supply a <tt>Command</tt> object which the <tt>Application Controller </tt>subsequently handles by invoking an action. Developers who rely on client-side controls and page-level access control often forget to check if the user is actually ''allowed ''to invoke a given <tt>Command</tt>.

Attackers take advantage of this vulnerability by simply modifying a parameter. A common example is a Create Read Update Delete (CRUD) transaction, such as http://siteurl/controller?command=viewUser&userName=jsmith. An attacker can simply modify “viewUser” to “deleteUser”. Often developers assume that if clients cannot see a link to “deleteUser” on a web page then they will not be able to invoke the “deleteUser” command. We like to call this ''GUI-based Authorization ''and it is a surprisingly common vulnerability in web applications.

Ensure that clients are actually allowed to invoke the supplied command by performing an authorization check on the application server. Provide the <tt>Application Controller</tt> sufficient data about the current user to perform the authorization check, such as roles and username. Consider using a <tt>Context </tt>object to store user data.

'''Unhandled Mappings in the Multiplexed Resource Mapping Strategy'''

The Multiplexed Resource Mapping strategy maps sets of logical requests to physical resources. For example, all requests that end with a “.ctrl” suffix are handled by a <tt>Controller</tt> object. Often developers forget to account for non-existent mappings, such as suffixes not associated with specific handlers.

Create a default <tt>Controller</tt> for non-existent mappings. Ensure the <tt>Controller</tt> simply provides a generic error message; relying on application server defaults often leads to propagation of detailed error messages and sometimes even reflected XSS in the error message (e.g. “The resource <script>alert(‘xss’)</script>.pdf could not be found”).

'''Logging of Arbitrary HTTP Parameters'''

A common cross-cutting application security concern is logging and monitoring of user actions. Although a ''Front Controller'' is ideally situated to log incoming requests, avoid logging entire HTTP requests. HTTP requests contain user-supplied parameters which often include confidential data such as passwords and credit card numbers and personally identifiable information (PII) such as an address. Logging confidential data or PII may be in violation of privacy and/or security regulations.

'''Duplicating Common Logic Across Multiple Front Controllers'''

If you use multiple ''Front Controllers'' for different types of requests, be sure to use the Base Front strategy to centralize security controls common to all requests. Duplicating cross-cutting security concerns such as authentication or session management checks in multiple ''Front Controllers'' may decrease maintainability. In addition, the inconsistent implementation of security checks may result in difficult-to-find security holes for specific use cases. If you use the BaseFront strategy to encapsulate cross-cutting security controls, then declare all security check methods as ''final'' in order to prevent method overriding and potentially skipping security checks in subclasses. The risk of overriding security checks increases with the size of the development team.

=== Use to Implement ===

'''Logical Resource Mapping'''

The Logical Resource Mapping strategy forces developers to explicitly define resources available for download and prevents directory traversal attacks.

'''Session Management'''

Session management is usually one of the first security controls that an application applies to a request. Aside from container-managed session management controls such as idle timeout and invalidation, some applications implement controls such as fixed session timeout, session rotation, and session-IP correlation through proprietary code. Use a ''Front Controller'' to apply the additional session management controls before each request is processed.

Invalidating the current session token and assigning a new session token after authentication is a common defense against session fixation attacks. This control can also be handled by ''Front Controller'' .

'''Audit Logging'''

Since ''Front Controllers ''are often designed to intercept all requests, they are ideally situated to perform logging of user actions for auditing purposes. Consider logging request information such as:

* Username for authenticated requests
* Timestamp of request
* Resource requested
* Response type such as success, error, etc.

Never log confidential or PII data.

==== Context Object ====
In a multi-tiered applications, one tier may retrieve data from an interface using a specific protocol and then pass this data to another tier to be used for processing or as input into decision logic. In order to reduce the dependency of the inner tiers on any specific protocol, the protocol-specific details of the data can be removed and the data populated into a <tt>ContextObject</tt> which can be shared between tiers. Examples of such data include HTTP parameters, application configuration values, or security data such as the user login information, defined by the Request Context, Configuration Context, and Security Context strategies, respectively. By removing the protocol-specific details from the input, the ''Context Object'' pattern significantly reduces the effort required to adapt code to a change in the application’s interfaces.
[[File:J2EEPatterns-Context Object.JPG]]
== Analysis ==
=== Avoid ===

'''Context Object Auto-Population Strategy'''

The Context Object Auto-Population strategy uses client-supplied parameters to populate the variables in a <tt>Context</tt> object. Rather than using a logical mapping to match parameters with <tt>Context</tt> variables, the Context Object Auto-Population strategy automatically matches <tt>Context</tt> variable names with parameter names. In some cases, developers maintain two types of variables within a <tt>Context</tt> object: client-supplied and server supplied. An e-commerce application, for example, might have a ShoppingCartContext object with client-supplied product ID and quantity variables and a price variable derived from a server-side database query. If a client supplies a request such as “http://siteurl/controller?command=purchase&prodID=43quantity=2” then the Context Object Auto-Population strategy will automatically set the ShoppingCartContext.prodId=43 and ShoppingCartContext.quantity=2. What if the user appends “&price=0.01” to the original query? The strategy automatically sets the ShoppingCarContext.price=0.01 even though the price value should not be client controlled. Ryan Berg and Dinis Cruz and of Ounce labs documented this as a vulnerability in the Spring Model View Controller (MVC) framework.

Avoid using the Context Object Auto-Population strategy wherever possible. If you must use this strategy, ensure that the user is actually allowed to supply the variables to the context object by performing explicit authorization checks.

'''Assuming Security Context Reflects All Security Concerns'''

The Security Context strategy should more precisely be called an Access Control Context strategy. Developers often assume that security is comprised entirely of authentication, authorization and encryption. This line of thinking often leads developers to believe that using the Secure Socket Layer (SSL) with user authentication and authorization is sufficient for creating a secure web application.

Also remember that fine-grained authorization decisions may be made further downstream in the application architecture, such as at the ''Business Delegate''. Consider propagating roles, permissions, and other relevant authorization information via the <tt>Context</tt> object.

=== Use to Implement ===

'''Whitelist Input Validation'''

The Request Context Validation strategy uses the <tt>RequestContext</tt> object to perform validation on client-supplied values. The Core J2EE Patterns book provides examples for form and business logic level validation, such as verifying the correct number of digits in a credit card. Use the same mechanism to perform security input validation with regular expressions. Unlike ''Intercepting Filter''s, <tt>RequestContexts</tt> encapsulate enough context data to perform whitelist validation. Many developers employ this strategy in Apache Struts applications by opting to use the Apache Commons Validator plugin for security input validation.

In several real-world implementations of Request Context Validation, the<tt> RequestContext</tt> only encapsulates HTTP parameters. Remember that malicious user-supplied input can come from a variety of other sources: cookies, URI paths, and other HTTP headers. If you do use the Request Context Validation strategy for security input validation then provide mechanisms for security input validation on other forms of input. For example, use an ''Intercepting Filter'' to validate cookie data.

'''Flagging Tainted Variables'''

Conceptually, <tt>Context</tt> objects form the last layer where applications can differentiate between untrusted user-supplied data and trusted system-supplied data. For instance, a shopping cart <tt>Context </tt>object might contain a user-supplied shipping address and a database-supplied product name. Generally speaking, objects logically downstream from the <tt>Context</tt> object cannot distinguish user-supplied data from system-supplied data. If you encode data at sink points and you want to minimize performance impact by encoding only user-supplied data (as opposed to system generated data), then consider adding an “isTainted” flag for each variable in the <tt>Context</tt> class. Set “isTainted” to true if the variable is user supplied or derived from another user supplied value. Set “isTainted” to false if the variable is computer generated and can be trusted. Store the instance variable and “isTainted” booleans as key/value pairs in a collection with efficient lookups (such as a <tt>WeakHashMap)</tt>. Downstream in the application, simply check if a variable is tainted (originates from user-supplied input) prior to deciding to encode it at sink points. For instance, you might HTML, JavaScript, or Cascading Stylesheet (CSS) encode all tainted data that you print to stream in a Servlet while leaving untainted data as is.

==== Application Controller ====
While the ''Front Controller'' pattern stresses centralization of logic common to all incoming requests, the conditional logic related to mapping each request to a command and view set can be further separated. The <tt>FrontController</tt> performs all generic request processing and delegates the conditional logic to an <tt>ApplicationController</tt>. The <tt>ApplicationController</tt> can then decide, based on the request, which command should service the request and which view to dispatch. The <tt>ApplicationController</tt> can be extended to include new use cases through a map holding references to the Command and View for each transaction. ''The Application Controller'' pattern is central to the Apache Struts model view controller framework.
[[File:J2EEPatterns-Application Controller.JPG]]
== Analysis ==
=== Avoid ===

'''Unauthorized Commands'''

In the Command Handler strategy, users supply a <tt>Command</tt> object which the <tt>ApplicationController </tt>subsequently handles by invoking an action. Developers who rely on client-side controls and page-level access control often forget to check if the user should actually be ''allowed ''to invoke a given <tt>Command</tt>.

Attackers take advantage of this vulnerability by simply modifying a parameter. A common example is a Create Read Update Delete (CRUD) transaction, such as http://siteurl/controller?command=viewUser&userName=jsmith. An attacker can simply modify “viewUser” to “deleteUser”. Often developers assume that if clients cannot see a link to “deleteUser” on a web page then they will not be able to invoke the “deleteUser” command. We call this vulnerability ''GUI-based Authorization ''and it is a surprisingly common in web applications.

Ensure that clients are actually allowed to invoke the supplied command by performing an authorization check on the application server. Provide the <tt>ApplicationController</tt> sufficient data about the current user to perform the authorization check, such as roles and username. Consider using a <tt>Context </tt>object to store user data.

'''Unhandled Commands'''

Create a default response page for non-existent commands. Relying on application server defaults often leads to propagation of detailed error messages and sometimes even reflected XSS in the error message (e.g. “The resource <script>alert(‘xss’)</script>.pdf could not be found”).

'''XSLT and XPath Vulnerabilities'''

The Transform Handler strategy uses XML Stylesheet Language Transforms (XSLTs) to generate views. Avoid XSLT and related XPath vulnerabilities by performing strict whitelist input validation or XML encoding on any user-supplied data used in view generation.

'''XML Denial of Service'''

If you use ''Application Controller'' with XML messages then remember that attackers may try Denial of Service (DOS) attacks on XML parsers and validators. Ensure either the web server, application server, or an ''Intercepting Filter'' performs a sanity check on the ''size'' of the XML message '''prior'' '''''to''''' '''''XML parsing or validation to prevent DOS conditions.

'''Disclosure of Information in SOAP Faults'''

One of the most common information disclosure vulnerabilities in web services is when error messages disclose full stack trace information and/or other internal details. Stack traces are often embedded in SOAP faults by default. Turn this feature off and return generic error messages to clients.

'''Publishing WSDL Files'''

Web Services Description Language (WSDL) files provide details on how to access web services and are very useful to attackers. Many SOAP frameworks publish the WSDL by default (e.g. http://url/path?WSDL). Turn this feature off.

=== Use to Implement ===

'''Synchronization Token as Anti-CSRF Mechanism'''

Synchronizer tokens are random numbers designed to detect duplicate web page requests. Use cryptographically strong random synchronized tokens to help prevent anti-Cross Site Request Forgery (CSRF). Remember, however, that CSRF tokens can be defeated if an attacker can successfully launch a Cross Site Scripting (XSS) attack on the application to programmatically parse and read the synchronization token.

'''Page-Level Authorization'''

If not already done using an ''Intercepting Filter'', use the ''Application Controller'' to examine client requests to ensure that only authorized users access a particular page. Centralizing authorization checks removes the burden of including explicit page-level authorization deeper in the application.

Remember that page-level authorization is only one component to a complete authorization scheme. Perform authorization at the command level if you use <tt>Command</tt> objects, the parameter level such as HTTP request parameters, and at the business logic level such as ''Business Delegate'' or ''Session Façade''. Remember to propagate user access control information such as users’ roles to other design layers. The OWASP Enterprise Security Application Programming Interface (ESAPI) uses <tt>ThreadLocal</tt> objects to maintain user authorization data throughout the life of a thread.

==== View Helper ====
View processing occurs with each request and typically consists of two major activities: processing and preparation of the data required by the view, and creating a view based on a template using data prepared during the first activity. These two components, often termed as <tt>Model</tt> and <tt>View</tt>, can be separated by using the ''View Helper ''pattern. Using this pattern, a view only contains the formatting logic either using the Template-Based View strategy such as a JSP or Controller-Based View Strategy using Servlets and XSLT transformations. The <tt>View</tt> then makes use of <tt>Helper</tt> objects that both retrieve data from the <tt>PresentationModel</tt> and encapsulate processing logic to format data for the View. JavaBean Helper and Custom Tag Helper are two popular strategies which use different data types (JavaBeans and custom view tags respectively) for encapsulating the model components.
[[File:J2EEPatterns-View Helper.JPG]]
== Analysis ==
=== Avoid ===

'''XSLT and XPath Vulnerabilities'''

Some developers elect to use Xml Stylesheet Language Transforms (XSLTs) within their <tt>Helper</tt> objects. Avoid XSLT and related XPath vulnerabilities by performing strict whitelist input validation or XML encoding on any user-supplied data used in view generation.

'''Unencoded User Supplied Data'''

Many JEE developers use standard and third party tag libraries extensively. Libraries such as Java Server pages Tag Libraries (JSTL) and Java Server Faces (JSF) simplify development by encapsulating view building logic and hiding difficult-to-maintain scriptlet code. Some tags automatically perform HTML encoding on common special characters. The “c:out” and “$(fn:escapeXml(variable))” Expression Language (EL) tags in JSTL automatically HTML encode potentially dangerous less-than, greater-than, ampersand, and apostrophe characters. Encoding a small subset of potentially malicious characters significantly reduces the risk of common Cross Site Scripting (XSS) attacks in web applications but may still leave other less-common malicious characters such as percentage signs unencoded. Many other tags do not perform any HTML encoding. Most do not perform any encoding for other sink types, such as JavaScript or Cascading Style Sheets (CSS).

Assume tag libraries do not perform output encoding unless you have specific evidence to the contrary. Wherever possible, wrap existing tag libraries with custom tags that perform output encoding. If you cannot use custom tags then manually encode user supplied data prior to embedding it in a tag.

=== Use to Implement ===

'''Output Encoding in Custom Tag Helper'''

The Custom Tag Helper strategy uses custom tags to create views. Wherever possible embed output encoding in custom tags to automatically protect against Cross Site Scripting (XSS) attacks.

==== Composite View ====
Applications often contain common <tt>View</tt> components, both from layout and content perspectives, across multiple <tt>Views</tt> in an application. These common components can be modularized by using the ''Composite View'' pattern which allows for a <tt>View</tt> to be built from modular, atomic components. Examples of modular components which can be reused are page headers, footers, and common tables. A <tt>CompositeView</tt> makes use of a <tt>ViewManager</tt> to assemble multiple views. A <tt>CompositeView</tt><nowiki> can be assembled by JavaBeans, standard JSP tags such as <jsp:include>, or custom tags, </nowiki>using the JavaBean View Management, Standard Tag View Management, or Custom Tag View Management strategies respectively.
[[File:J2EEPatterns-Composite View.JPG]]
== Analysis ==
=== Avoid ===

'''XSLT and XPath Vulnerabilities'''

The Transformer View Management strategy uses XML Stylesheet Language Transforms (XSLTs). Avoid XSLT and related XPath vulnerabilities by performing strict whitelist input validation or XML encoding on any user-supplied data used in view generation.

'''Skipping Authorization Check Within SubViews'''

One of the most common web applications vulnerabilities is weak functional authorization. Developers sometimes use user role data to dynamically generate views. In the Core J2EE Pattern books the authors refer to these dynamic views as “Role-based content”. Role-based content prevents unauthorized users from ''viewing'' content but does not prevent unauthorized users from ''invoking'' Servlets and Java Server Pages (JSPs). For example, imagine a JEE accounting application with two JSPs – accounting_functions.jsp which is the main accounting page and gl.jsp representing the general ledger. In order to restrict access to the general ledger, developers include the following content in accounts.jsp:

<nowiki><region: render template=’portal.jsp’></nowiki>
<nowiki><region:put section=’general_ledger’ content=’gl.jsp’ </nowiki>
role=’accountant’ />
<nowiki></region:render></nowiki>

The code snippet above restricts the content in gl.jsp to users in the accountant role. Remember, however, that a user can simply access gl.jsp directly – a flaw that can be even more devastating if invoking gl.jsp with parameters causes a transaction to run such as posting a debit or credit.

=== Use to Implement ===

'''Output Encoding in Custom Tags'''

The Custom Tag View Management strategy uses custom tags to create views. Wherever possible embed output encoding in custom tags to automatically protect against Cross Site Scripting (XSS) attacks.

==== Service to Worker ====
Applications commonly dispatch a <tt>View</tt> based exclusively on the results of request processing. In this the ''Service to Worker ''pattern, the <tt>Controller</tt> (either <tt>FrontController</tt> or <tt>ApplicationController</tt>) performs business logic and, based on the result of that logic, creates a <tt>View </tt>and invokes its logic. ''Service to Worker'' is different from ''Dispatcher View'' because in the latter the <tt>View</tt> logic is invoked '''before '''the''' '''business logic is invoked.
[[File:J2EEPatterns-Service to Worker.JPG]]
== Analysis ==
=== Avoid ===

'''Dispatching Error Pages Without a Default Error Handler'''

In ''Service to Worker'', an <tt>ApplicationController</tt> manages the flow of web pages. When an application encounters an error, the <tt>ApplicationController</tt> typically determines which error page to dispatch. The Core J2EE Patterns book uses the following line of code to determine which error page to forward the user to:

next= ApplicationResources.getInstance().getErrorPage(e);

Many developers use the approach of mapping exceptions to particular error pages, but do not account for a default error page. As applications evolve, the job of creating a friendly error page for every exception type becomes increasingly difficult. In many applications the <tt>ApplicationController </tt>will simply dump a stack trace or even redisplay the client’s request back to them. Avoid both scenarios by providing a default generic error page. In Java EE you can implement default error handling through web.xml configuration.

==== Dispatcher View ====
In instances where there is a limited amount or no business processing required prior to generating a response, control can be passed to the <tt>View</tt> directly from the <tt>ApplicationController</tt>. The <tt>ApplicationController</tt> performs general control logic and is only responsible for mapping the request to a corresponding <tt>View</tt>. Dispatcher View pattern is typically used in situations where the response is entirely static or the response is generated from data which has been generated from a previous request. Using this pattern, view management is often so trivial (i.e. mapping of an alias to a resource) that no application-level logic is required and it is handled by the container.
[[File:J2EEPatterns-Dispatcher View.JPG]]
== Analysis ==
=== Avoid ===

'''Using User Supplied Forward Values'''

The <tt>ApplicationController</tt> determines which view to dispatch to a user. In the Core J2EE Patterns book, the authors provide the following sample of code to determine the next page to dispatch to a user:

next = request.getParameter(“nextview”);

Depending on how you forward users to the next page, an attacker may be able to:

* Gain unauthorized access to pages if the forwarding mechanism bypasses authorization checks
* Forward unsuspecting users to a malicious site. Attackers can take advantage of the forwarding feature to craft more convincing phishing emails with links such as http://siteurl/page?nextview=http://malicioussite/attack.html. Since the URL originates from a trusted domain – “http://siteurl” in the example – it is less likely to be caught by phishing filters or careful users
* Perform Cross Site Scripting (XSS) in browsers that accept JavaScript URLs. For example, an attacker might send a phishing email with the following URL: [http://siteurl/page?nextview=javascript:do_something_malicious http://siteurl/page?nextview=javascript:do_something_malicious]
* Perform HTTP Response Splitting if the application uses an HTTP redirect to forward the user to the next page. The user supplies the literal value of the destination URL. Because the application server uses that URL in the header of the HTTP redirect response, a malicious user can inject carriage return and line feeds into the response using hex encoded %0A and %0D

Do not rely on literal user-supplied values to determine the next page. Instead, use a logical mapping of numbers to actual pages. For example, in http://siteurl/page?nextview=1 the “1” maps to “edituser.jsp” on the server.

'''Assuming User’s Navigation History '''

The Core J2EE Patterns book discusses an example where the ''Dispatcher View'' pattern may be used. In the example, the application places an intermediate model in a temporary store and a later request uses that model to generate a response. When writing code for the second view, some developers assume that the user has already navigated to the first view thereby instantiating and populating the intermediate model. An attacker may take advantage of this assumption by directly navigating to the second view before the first. Similarly, if the first view automatically dispatches the second view (through an HTTP or JavaScript redirect), an attacker may drop the second request, resulting in an unexpected state. Always user server-side checks such as session variables to verify that the user has followed the intended navigation path.

__NOTOC__

<headertabs/>

Category:OWASP Security Analysis of Core J2EE Design Patterns Project/PresentationTier

2009-07-09T21:19:10Z

Rksethi:

==== Intercepting Filter ====
The ''Intercepting Filter'' pattern may be used in instances where there is the need to execute logic before and after the main processing of a request (pre and postprocessing). The logic resides in <tt>Filter</tt> objects and typically consist of code that is common across multiple requests. The Servlet 2.3 Specification provides a mechanism for building filters and chaining of <tt>Filters</tt> through configuration. A <tt>FilterManager</tt> controls the execution of a number of loosely-coupled <tt>Filters</tt> (referred to as a <tt>FilterChain</tt>), each of which performs a specific action. This Standard Filter Strategy can also be replaced by a Custom Filter Strategy which replaces the Servlet Specification’s object wrapping with a custom implementation.

[[File:J2EEPatterns-Intercepting Filter.JPG]]

== Analysis ==
=== Avoid ===

'''Relying Only on a Blacklist Validation Filter'''

Developers often use blacklists in <tt>Filters</tt> as their only line of defense against input attacks such as Cross Site Scripting (XSS). Attackers constantly circumvent blacklists because of errors in canonicalization and character encoding. In order to sufficiently protect applications, do not rely on a blacklist validation filter as the sole means of protection; also validate input with strict whitelists on all input and/or encode data at every sink.

'''Output Encoding in Filter'''

Encoding data before forwarding requests to the <tt>Target</tt> is too early because the data is too far from the sink point and may actually end up in several sink points, each requiring a different form of encoding. For instance, suppose an application uses a client-supplied e-mail address in a Structured Query Language (SQL) query, a Lightweight Directory Access Protocol (LDAP) lookup, and within a Hyper Text Markup Language (HTML) page. SQL, LDAP, and HTML are all different sinks and each requires a unique form of encoding. It may be impossible to encode input at the <tt>Filter</tt> for all three sink types without breaking functionality. On the other hand, performing encoding after the <tt>Target</tt> returns data is too late since data will have already reached the sink by the time it reaches the <tt>Filter</tt>.

'''Overly Generous Whitelist Validation'''

While attempting to implement whitelist validation, developers often allow a large range of characters that may include potentially malicious characters. For example, some developers will allow all printable ASCII characters which contain malicious XSS and SQL injection characters such as less than signs and semi-colons. If your whitelists are not sufficiently restrictive, perform additional encoding at each data sink.

'''XML Denial of Service'''

If you use ''Intercepting Filter'' to preprocess XML messages, then remember that attackers may try many different Denial of Service (DOS) attacks on XML parsers and validators. Ensure either the web server, application server, or the first <tt>Filter</tt> on the chain performs a sanity check on the ''size'' of the XML message '''prior'' '''''to''''' '''''XML parsing or validation to prevent DOS conditions.

'''Logging Arbitrary HTTP Parameters'''

A common cross-cutting application security concern is logging and monitoring of user actions. Although an ''Intercepting Filter'' is ideally situated to log incoming requests, avoid logging entire HTTP requests. HTTP requests contain user-supplied parameters which often include confidential data such as passwords, credit card numbers and personally identifiable information (PII) such as an address. Logging confidential data or PII may be in violation of privacy and/or security regulations.

=== Use to Implement ===

'''Input Validation'''

Use an ''Intercepting Filter'' to implement security input validation consistently across all presentation tier pages including both Servlets and JSPs. The <tt>Filter’s</tt> position between the client and the front/application controllers make it an ideal location for a blacklist against all input. Ideally, developers should always employ whitelist validation rather than blacklist validation; however, in practice developers often select blacklist validation due to the difficulty in creating whitelists. In cases where blacklist validation is used, ensure that additional encoding is performed at each data sink (e.g. HTML and JavaScript encoding).

'''Page-Level Authorization'''

Use an ''Intercepting Filter'' to examine requests from the client to ensure that a user is authorized to access a particular page. Centralizing authorization checks removes the burden of including explicit page-level authorization deeper in the application. The Spring Security framework employs an ''Intercepting Filter'' for authorization.

Remember that page-level authorization is only one component of a complete authorization scheme. Perform authorization at the command level if you use <tt>Command</tt> objects, the parameter level such as HTTP request parameters, and at the business logic level such as ''Business Delegate'' or ''Session Façade''. Remember to propagate user access control information such as users’ roles to other design layers like the ''Application Controller''. The OWASP Enterprise Security Application Programming Interface (ESAPI) uses <tt>ThreadLocal</tt> objects to maintain user authorization data throughout the life of a thread.

'''Session Management'''

Session management is usually one of the first security controls that an application applies to a request. Aside from container-managed session management controls such as idle timeout and invalidation, some applications implement controls such as fixed session timeout, session rotation and session-IP correlation through proprietary code. Use an ''Intercepting Filter ''to apply the additional session management controls before each request is processed.

Invalidating the current session token and assigning a new session token after authentication is a common defense against session fixation attacks. This control can also be handled in an ''Intercepting Filter ''specifically configured to intercept authentication requests. You may alternatively use a generic session management <tt>Filter</tt> that intercepts all requests, and then use conditional logic to check, specifically, for authentication requests in order to apply a defense against session fixation attacks. Be aware, however, that using a generic <tt>Filter</tt> introduces maintenance overhead when you implement new authentication paths.

'''Audit Logging'''

Since ''Intercepting Filters'' are often designed to intercept all requests, they are ideally situated to perform logging of user actions for auditing purposes. Consider implementing a <tt>Filter</tt> that intercepts all requests and logs information such as:

* Username for authenticated requests
* Timestamp of request
* Resource requested
* Response type such as success, error, etc.

The logging filter should be configured as the first <tt>Filter</tt> in the chain in order to log all requests irrespective of any errors that may occur in <tt>Filters</tt> further down the chain. Never log confidential or PII data.

==== Front Controller ====
Processing a request typically consists of a number of request handling activities such as protocol handling, navigation and routing, core processing, and dispatch as well as view processingvii. A controller provides a place for centralizing this common logic performed for each request. Typically implemented as a Servlet, the ''Front Controller ''can perform this common logic and further delegate the action management (servicing the request) and view management (dispatching a view for user output) activities to an ''Application Controller''. This pattern provides centralization of request control logic and partitioning of an application between control and processing.

== Analysis ==
=== Avoid ===

'''Physical Resource Mapping'''

The Physical Resource Mapping strategy maps user-supplied parameters directly to physical resources such as files residing on the server. Attackers often take advantage of this strategy to gain illicit access to resources. In a directory traversal exploit, for example, clients supply the server with the physical location of a file such as “file=statement_060609.pdf”. Attackers attempt to access other files on the server by supplying malicious parameters such as “file=../../../../../etc/password”. If the application blindly accepts and opens any user-supplied filename then the attacker may have access to a whole array of sensitive files, including properties and configuration files that often contain hard-coded passwords.

Developers sometimes mitigate directory traversal attacks by checking for the presence of a specific prefix or suffix, such as verifying that the file parameter begins with “statement” and ends with “.pdf”. A crafty attacker can take advantage of null character injection and enter “file=statement_060609.pdf/../../../../etc/password%00.pdf”. Java will see that the resource beings with “statement” and ends with “.pdf” whereas the operating system may actually drop all remaining characters after the %00 null terminator and open the password file.

As a rule, avoid using the Physical Resource Mapping strategy altogether. If you must use this strategy, ensure that the application operates in a sandboxed environment with the Java Security Manager and/or employs sufficient operating system controls to protect resources from unauthorized access.

'''Invoking Commands Without Sufficient Authorization'''

In the Command and Controller strategy, users supply a <tt>Command</tt> object which the <tt>Application Controller </tt>subsequently handles by invoking an action. Developers who rely on client-side controls and page-level access control often forget to check if the user is actually ''allowed ''to invoke a given <tt>Command</tt>.

Attackers take advantage of this vulnerability by simply modifying a parameter. A common example is a Create Read Update Delete (CRUD) transaction, such as http://siteurl/controller?command=viewUser&userName=jsmith. An attacker can simply modify “viewUser” to “deleteUser”. Often developers assume that if clients cannot see a link to “deleteUser” on a web page then they will not be able to invoke the “deleteUser” command. We like to call this ''GUI-based Authorization ''and it is a surprisingly common vulnerability in web applications.

Ensure that clients are actually allowed to invoke the supplied command by performing an authorization check on the application server. Provide the <tt>Application Controller</tt> sufficient data about the current user to perform the authorization check, such as roles and username. Consider using a <tt>Context </tt>object to store user data.

'''Unhandled Mappings in the Multiplexed Resource Mapping Strategy'''

The Multiplexed Resource Mapping strategy maps sets of logical requests to physical resources. For example, all requests that end with a “.ctrl” suffix are handled by a <tt>Controller</tt> object. Often developers forget to account for non-existent mappings, such as suffixes not associated with specific handlers.

Create a default <tt>Controller</tt> for non-existent mappings. Ensure the <tt>Controller</tt> simply provides a generic error message; relying on application server defaults often leads to propagation of detailed error messages and sometimes even reflected XSS in the error message (e.g. “The resource <script>alert(‘xss’)</script>.pdf could not be found”).

'''Logging of Arbitrary HTTP Parameters'''

A common cross-cutting application security concern is logging and monitoring of user actions. Although a ''Front Controller'' is ideally situated to log incoming requests, avoid logging entire HTTP requests. HTTP requests contain user-supplied parameters which often include confidential data such as passwords and credit card numbers and personally identifiable information (PII) such as an address. Logging confidential data or PII may be in violation of privacy and/or security regulations.

'''Duplicating Common Logic Across Multiple Front Controllers'''

If you use multiple ''Front Controllers'' for different types of requests, be sure to use the Base Front strategy to centralize security controls common to all requests. Duplicating cross-cutting security concerns such as authentication or session management checks in multiple ''Front Controllers'' may decrease maintainability. In addition, the inconsistent implementation of security checks may result in difficult-to-find security holes for specific use cases. If you use the BaseFront strategy to encapsulate cross-cutting security controls, then declare all security check methods as ''final'' in order to prevent method overriding and potentially skipping security checks in subclasses. The risk of overriding security checks increases with the size of the development team.

=== Use to Implement ===

'''Logical Resource Mapping'''

The Logical Resource Mapping strategy forces developers to explicitly define resources available for download and prevents directory traversal attacks.

'''Session Management'''

Session management is usually one of the first security controls that an application applies to a request. Aside from container-managed session management controls such as idle timeout and invalidation, some applications implement controls such as fixed session timeout, session rotation, and session-IP correlation through proprietary code. Use a ''Front Controller'' to apply the additional session management controls before each request is processed.

Invalidating the current session token and assigning a new session token after authentication is a common defense against session fixation attacks. This control can also be handled by ''Front Controller'' .

'''Audit Logging'''

Since ''Front Controllers ''are often designed to intercept all requests, they are ideally situated to perform logging of user actions for auditing purposes. Consider logging request information such as:

* Username for authenticated requests
* Timestamp of request
* Resource requested
* Response type such as success, error, etc.

Never log confidential or PII data.

==== Context Object ====
In a multi-tiered applications, one tier may retrieve data from an interface using a specific protocol and then pass this data to another tier to be used for processing or as input into decision logic. In order to reduce the dependency of the inner tiers on any specific protocol, the protocol-specific details of the data can be removed and the data populated into a <tt>ContextObject</tt> which can be shared between tiers. Examples of such data include HTTP parameters, application configuration values, or security data such as the user login information, defined by the Request Context, Configuration Context, and Security Context strategies, respectively. By removing the protocol-specific details from the input, the ''Context Object'' pattern significantly reduces the effort required to adapt code to a change in the application’s interfaces.

== Analysis ==
=== Avoid ===

'''Context Object Auto-Population Strategy'''

The Context Object Auto-Population strategy uses client-supplied parameters to populate the variables in a <tt>Context</tt> object. Rather than using a logical mapping to match parameters with <tt>Context</tt> variables, the Context Object Auto-Population strategy automatically matches <tt>Context</tt> variable names with parameter names. In some cases, developers maintain two types of variables within a <tt>Context</tt> object: client-supplied and server supplied. An e-commerce application, for example, might have a ShoppingCartContext object with client-supplied product ID and quantity variables and a price variable derived from a server-side database query. If a client supplies a request such as “http://siteurl/controller?command=purchase&prodID=43quantity=2” then the Context Object Auto-Population strategy will automatically set the ShoppingCartContext.prodId=43 and ShoppingCartContext.quantity=2. What if the user appends “&price=0.01” to the original query? The strategy automatically sets the ShoppingCarContext.price=0.01 even though the price value should not be client controlled. Ryan Berg and Dinis Cruz and of Ounce labs documented this as a vulnerability in the Spring Model View Controller (MVC) framework.

Avoid using the Context Object Auto-Population strategy wherever possible. If you must use this strategy, ensure that the user is actually allowed to supply the variables to the context object by performing explicit authorization checks.

'''Assuming Security Context Reflects All Security Concerns'''

The Security Context strategy should more precisely be called an Access Control Context strategy. Developers often assume that security is comprised entirely of authentication, authorization and encryption. This line of thinking often leads developers to believe that using the Secure Socket Layer (SSL) with user authentication and authorization is sufficient for creating a secure web application.

Also remember that fine-grained authorization decisions may be made further downstream in the application architecture, such as at the ''Business Delegate''. Consider propagating roles, permissions, and other relevant authorization information via the <tt>Context</tt> object.

=== Use to Implement ===

'''Whitelist Input Validation'''

The Request Context Validation strategy uses the <tt>RequestContext</tt> object to perform validation on client-supplied values. The Core J2EE Patterns book provides examples for form and business logic level validation, such as verifying the correct number of digits in a credit card. Use the same mechanism to perform security input validation with regular expressions. Unlike ''Intercepting Filter''s, <tt>RequestContexts</tt> encapsulate enough context data to perform whitelist validation. Many developers employ this strategy in Apache Struts applications by opting to use the Apache Commons Validator plugin for security input validation.

In several real-world implementations of Request Context Validation, the<tt> RequestContext</tt> only encapsulates HTTP parameters. Remember that malicious user-supplied input can come from a variety of other sources: cookies, URI paths, and other HTTP headers. If you do use the Request Context Validation strategy for security input validation then provide mechanisms for security input validation on other forms of input. For example, use an ''Intercepting Filter'' to validate cookie data.

'''Flagging Tainted Variables'''

Conceptually, <tt>Context</tt> objects form the last layer where applications can differentiate between untrusted user-supplied data and trusted system-supplied data. For instance, a shopping cart <tt>Context </tt>object might contain a user-supplied shipping address and a database-supplied product name. Generally speaking, objects logically downstream from the <tt>Context</tt> object cannot distinguish user-supplied data from system-supplied data. If you encode data at sink points and you want to minimize performance impact by encoding only user-supplied data (as opposed to system generated data), then consider adding an “isTainted” flag for each variable in the <tt>Context</tt> class. Set “isTainted” to true if the variable is user supplied or derived from another user supplied value. Set “isTainted” to false if the variable is computer generated and can be trusted. Store the instance variable and “isTainted” booleans as key/value pairs in a collection with efficient lookups (such as a <tt>WeakHashMap)</tt>. Downstream in the application, simply check if a variable is tainted (originates from user-supplied input) prior to deciding to encode it at sink points. For instance, you might HTML, JavaScript, or Cascading Stylesheet (CSS) encode all tainted data that you print to stream in a Servlet while leaving untainted data as is.

==== Application Controller ====
While the ''Front Controller'' pattern stresses centralization of logic common to all incoming requests, the conditional logic related to mapping each request to a command and view set can be further separated. The <tt>FrontController</tt> performs all generic request processing and delegates the conditional logic to an <tt>ApplicationController</tt>. The <tt>ApplicationController</tt> can then decide, based on the request, which command should service the request and which view to dispatch. The <tt>ApplicationController</tt> can be extended to include new use cases through a map holding references to the Command and View for each transaction. ''The Application Controller'' pattern is central to the Apache Struts model view controller framework.

== Analysis ==
=== Avoid ===

'''Unauthorized Commands'''

In the Command Handler strategy, users supply a <tt>Command</tt> object which the <tt>ApplicationController </tt>subsequently handles by invoking an action. Developers who rely on client-side controls and page-level access control often forget to check if the user should actually be ''allowed ''to invoke a given <tt>Command</tt>.

Attackers take advantage of this vulnerability by simply modifying a parameter. A common example is a Create Read Update Delete (CRUD) transaction, such as http://siteurl/controller?command=viewUser&userName=jsmith. An attacker can simply modify “viewUser” to “deleteUser”. Often developers assume that if clients cannot see a link to “deleteUser” on a web page then they will not be able to invoke the “deleteUser” command. We call this vulnerability ''GUI-based Authorization ''and it is a surprisingly common in web applications.

Ensure that clients are actually allowed to invoke the supplied command by performing an authorization check on the application server. Provide the <tt>ApplicationController</tt> sufficient data about the current user to perform the authorization check, such as roles and username. Consider using a <tt>Context </tt>object to store user data.

'''Unhandled Commands'''

Create a default response page for non-existent commands. Relying on application server defaults often leads to propagation of detailed error messages and sometimes even reflected XSS in the error message (e.g. “The resource <script>alert(‘xss’)</script>.pdf could not be found”).

'''XSLT and XPath Vulnerabilities'''

The Transform Handler strategy uses XML Stylesheet Language Transforms (XSLTs) to generate views. Avoid XSLT and related XPath vulnerabilities by performing strict whitelist input validation or XML encoding on any user-supplied data used in view generation.

'''XML Denial of Service'''

If you use ''Application Controller'' with XML messages then remember that attackers may try Denial of Service (DOS) attacks on XML parsers and validators. Ensure either the web server, application server, or an ''Intercepting Filter'' performs a sanity check on the ''size'' of the XML message '''prior'' '''''to''''' '''''XML parsing or validation to prevent DOS conditions.

'''Disclosure of Information in SOAP Faults'''

One of the most common information disclosure vulnerabilities in web services is when error messages disclose full stack trace information and/or other internal details. Stack traces are often embedded in SOAP faults by default. Turn this feature off and return generic error messages to clients.

'''Publishing WSDL Files'''

Web Services Description Language (WSDL) files provide details on how to access web services and are very useful to attackers. Many SOAP frameworks publish the WSDL by default (e.g. http://url/path?WSDL). Turn this feature off.

=== Use to Implement ===

'''Synchronization Token as Anti-CSRF Mechanism'''

Synchronizer tokens are random numbers designed to detect duplicate web page requests. Use cryptographically strong random synchronized tokens to help prevent anti-Cross Site Request Forgery (CSRF). Remember, however, that CSRF tokens can be defeated if an attacker can successfully launch a Cross Site Scripting (XSS) attack on the application to programmatically parse and read the synchronization token.

'''Page-Level Authorization'''

If not already done using an ''Intercepting Filter'', use the ''Application Controller'' to examine client requests to ensure that only authorized users access a particular page. Centralizing authorization checks removes the burden of including explicit page-level authorization deeper in the application.

Remember that page-level authorization is only one component to a complete authorization scheme. Perform authorization at the command level if you use <tt>Command</tt> objects, the parameter level such as HTTP request parameters, and at the business logic level such as ''Business Delegate'' or ''Session Façade''. Remember to propagate user access control information such as users’ roles to other design layers. The OWASP Enterprise Security Application Programming Interface (ESAPI) uses <tt>ThreadLocal</tt> objects to maintain user authorization data throughout the life of a thread.

==== View Helper ====
View processing occurs with each request and typically consists of two major activities: processing and preparation of the data required by the view, and creating a view based on a template using data prepared during the first activity. These two components, often termed as <tt>Model</tt> and <tt>View</tt>, can be separated by using the ''View Helper ''pattern. Using this pattern, a view only contains the formatting logic either using the Template-Based View strategy such as a JSP or Controller-Based View Strategy using Servlets and XSLT transformations. The <tt>View</tt> then makes use of <tt>Helper</tt> objects that both retrieve data from the <tt>PresentationModel</tt> and encapsulate processing logic to format data for the View. JavaBean Helper and Custom Tag Helper are two popular strategies which use different data types (JavaBeans and custom view tags respectively) for encapsulating the model components.

== Analysis ==
=== Avoid ===

'''XSLT and XPath Vulnerabilities'''

Some developers elect to use Xml Stylesheet Language Transforms (XSLTs) within their <tt>Helper</tt> objects. Avoid XSLT and related XPath vulnerabilities by performing strict whitelist input validation or XML encoding on any user-supplied data used in view generation.

'''Unencoded User Supplied Data'''

Many JEE developers use standard and third party tag libraries extensively. Libraries such as Java Server pages Tag Libraries (JSTL) and Java Server Faces (JSF) simplify development by encapsulating view building logic and hiding difficult-to-maintain scriptlet code. Some tags automatically perform HTML encoding on common special characters. The “c:out” and “$(fn:escapeXml(variable))” Expression Language (EL) tags in JSTL automatically HTML encode potentially dangerous less-than, greater-than, ampersand, and apostrophe characters. Encoding a small subset of potentially malicious characters significantly reduces the risk of common Cross Site Scripting (XSS) attacks in web applications but may still leave other less-common malicious characters such as percentage signs unencoded. Many other tags do not perform any HTML encoding. Most do not perform any encoding for other sink types, such as JavaScript or Cascading Style Sheets (CSS).

Assume tag libraries do not perform output encoding unless you have specific evidence to the contrary. Wherever possible, wrap existing tag libraries with custom tags that perform output encoding. If you cannot use custom tags then manually encode user supplied data prior to embedding it in a tag.

=== Use to Implement ===

'''Output Encoding in Custom Tag Helper'''

The Custom Tag Helper strategy uses custom tags to create views. Wherever possible embed output encoding in custom tags to automatically protect against Cross Site Scripting (XSS) attacks.

==== Composite View ====
Applications often contain common <tt>View</tt> components, both from layout and content perspectives, across multiple <tt>Views</tt> in an application. These common components can be modularized by using the ''Composite View'' pattern which allows for a <tt>View</tt> to be built from modular, atomic components. Examples of modular components which can be reused are page headers, footers, and common tables. A <tt>CompositeView</tt> makes use of a <tt>ViewManager</tt> to assemble multiple views. A <tt>CompositeView</tt><nowiki> can be assembled by JavaBeans, standard JSP tags such as <jsp:include>, or custom tags, </nowiki>using the JavaBean View Management, Standard Tag View Management, or Custom Tag View Management strategies respectively.

== Analysis ==
=== Avoid ===

'''XSLT and XPath Vulnerabilities'''

The Transformer View Management strategy uses XML Stylesheet Language Transforms (XSLTs). Avoid XSLT and related XPath vulnerabilities by performing strict whitelist input validation or XML encoding on any user-supplied data used in view generation.

'''Skipping Authorization Check Within SubViews'''

One of the most common web applications vulnerabilities is weak functional authorization. Developers sometimes use user role data to dynamically generate views. In the Core J2EE Pattern books the authors refer to these dynamic views as “Role-based content”. Role-based content prevents unauthorized users from ''viewing'' content but does not prevent unauthorized users from ''invoking'' Servlets and Java Server Pages (JSPs). For example, imagine a JEE accounting application with two JSPs – accounting_functions.jsp which is the main accounting page and gl.jsp representing the general ledger. In order to restrict access to the general ledger, developers include the following content in accounts.jsp:

<nowiki><region: render template=’portal.jsp’></nowiki>
<nowiki><region:put section=’general_ledger’ content=’gl.jsp’ </nowiki>
role=’accountant’ />
<nowiki></region:render></nowiki>

The code snippet above restricts the content in gl.jsp to users in the accountant role. Remember, however, that a user can simply access gl.jsp directly – a flaw that can be even more devastating if invoking gl.jsp with parameters causes a transaction to run such as posting a debit or credit.

=== Use to Implement ===

'''Output Encoding in Custom Tags'''

The Custom Tag View Management strategy uses custom tags to create views. Wherever possible embed output encoding in custom tags to automatically protect against Cross Site Scripting (XSS) attacks.

==== Service to Worker ====
Applications commonly dispatch a <tt>View</tt> based exclusively on the results of request processing. In this the ''Service to Worker ''pattern, the <tt>Controller</tt> (either <tt>FrontController</tt> or <tt>ApplicationController</tt>) performs business logic and, based on the result of that logic, creates a <tt>View </tt>and invokes its logic. ''Service to Worker'' is different from ''Dispatcher View'' because in the latter the <tt>View</tt> logic is invoked '''before '''the''' '''business logic is invoked.

== Analysis ==
=== Avoid ===

'''Dispatching Error Pages Without a Default Error Handler'''

In ''Service to Worker'', an <tt>ApplicationController</tt> manages the flow of web pages. When an application encounters an error, the <tt>ApplicationController</tt> typically determines which error page to dispatch. The Core J2EE Patterns book uses the following line of code to determine which error page to forward the user to:

next= ApplicationResources.getInstance().getErrorPage(e);

Many developers use the approach of mapping exceptions to particular error pages, but do not account for a default error page. As applications evolve, the job of creating a friendly error page for every exception type becomes increasingly difficult. In many applications the <tt>ApplicationController </tt>will simply dump a stack trace or even redisplay the client’s request back to them. Avoid both scenarios by providing a default generic error page. In Java EE you can implement default error handling through web.xml configuration.

==== Dispatcher View ====
In instances where there is a limited amount or no business processing required prior to generating a response, control can be passed to the <tt>View</tt> directly from the <tt>ApplicationController</tt>. The <tt>ApplicationController</tt> performs general control logic and is only responsible for mapping the request to a corresponding <tt>View</tt>. Dispatcher View pattern is typically used in situations where the response is entirely static or the response is generated from data which has been generated from a previous request. Using this pattern, view management is often so trivial (i.e. mapping of an alias to a resource) that no application-level logic is required and it is handled by the container.

== Analysis ==
=== Avoid ===

'''Using User Supplied Forward Values'''

The <tt>ApplicationController</tt> determines which view to dispatch to a user. In the Core J2EE Patterns book, the authors provide the following sample of code to determine the next page to dispatch to a user:

next = request.getParameter(“nextview”);

Depending on how you forward users to the next page, an attacker may be able to:

* Gain unauthorized access to pages if the forwarding mechanism bypasses authorization checks
* Forward unsuspecting users to a malicious site. Attackers can take advantage of the forwarding feature to craft more convincing phishing emails with links such as http://siteurl/page?nextview=http://malicioussite/attack.html. Since the URL originates from a trusted domain – “http://siteurl” in the example – it is less likely to be caught by phishing filters or careful users
* Perform Cross Site Scripting (XSS) in browsers that accept JavaScript URLs. For example, an attacker might send a phishing email with the following URL: [http://siteurl/page?nextview=javascript:do_something_malicious http://siteurl/page?nextview=javascript:do_something_malicious]
* Perform HTTP Response Splitting if the application uses an HTTP redirect to forward the user to the next page. The user supplies the literal value of the destination URL. Because the application server uses that URL in the header of the HTTP redirect response, a malicious user can inject carriage return and line feeds into the response using hex encoded %0A and %0D

Do not rely on literal user-supplied values to determine the next page. Instead, use a logical mapping of numbers to actual pages. For example, in http://siteurl/page?nextview=1 the “1” maps to “edituser.jsp” on the server.

'''Assuming User’s Navigation History '''

The Core J2EE Patterns book discusses an example where the ''Dispatcher View'' pattern may be used. In the example, the application places an intermediate model in a temporary store and a later request uses that model to generate a response. When writing code for the second view, some developers assume that the user has already navigated to the first view thereby instantiating and populating the intermediate model. An attacker may take advantage of this assumption by directly navigating to the second view before the first. Similarly, if the first view automatically dispatches the second view (through an HTTP or JavaScript redirect), an attacker may drop the second request, resulting in an unexpected state. Always user server-side checks such as session variables to verify that the user has followed the intended navigation path.

__NOTOC__

<headertabs/>

File:J2EEPatterns-Web Services Broker.JPG

2009-07-09T21:15:26Z

Rksethi:

File:J2EEPatterns-View Helper.JPG

2009-07-09T21:15:09Z

Rksethi:

File:J2EEPatterns-Value List Handler.JPG

2009-07-09T21:14:43Z

Rksethi:

File:J2EEPatterns-Transfer Object Assembler.JPG

2009-07-09T21:14:24Z

Rksethi:

File:J2EEPatterns-Transfer Object.JPG

2009-07-09T21:13:49Z

Rksethi:

File:J2EEPatterns-Session Facade.JPG

2009-07-09T21:13:31Z

Rksethi:

File:J2EEPatterns-Service to Worker.JPG

2009-07-09T21:13:12Z

Rksethi:

File:J2EEPatterns-Service Locator.JPG

2009-07-09T21:12:31Z

Rksethi:

File:J2EEPatterns-Service Activator.JPG

2009-07-09T21:12:13Z

Rksethi:

File:J2EEPatterns-Intercepting Filter.JPG

2009-07-09T21:12:00Z

Rksethi:

File:J2EEPatterns-Dispatcher View.JPG

2009-07-09T21:11:20Z

Rksethi:

File:J2EEPatterns-Front Controller.JPG

2009-07-09T21:11:08Z

Rksethi:

File:J2EEPatterns-Domain Store.JPG

2009-07-09T21:10:53Z

Rksethi:

File:J2EEPatterns-Data Access Object.JPG

2009-07-09T21:09:53Z

Rksethi:

File:J2EEPatterns-Context Object.JPG

2009-07-09T21:09:20Z

Rksethi:

File:J2EEPatterns-Composite View.JPG

2009-07-09T21:08:09Z

Rksethi:

File:J2EEPatterns-Composite Entity.JPG

2009-07-09T21:07:30Z

Rksethi:

File:J2EEPatterns-Business Object.JPG

2009-07-09T21:06:59Z

Rksethi:

File:J2EEPatterns-Business Delegate.JPG

2009-07-09T21:06:06Z

Rksethi: