OWASP - User contributions [en]

Project Information:template Yasca Project

2014-07-15T03:23:10Z

Scovetta: Updated website.

{|
|-
! width="700" align="center" | 
! width="500" align="center" | 
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}

{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''PROJECT IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|'''OWASP Yasca Project'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|
* Yasca is an open source program which looks for security vulnerabilities, code-quality, performance, and conformance to best practices in program source code. It leverages external open source programs, such as [http://findbugs.sourceforge.net/ FindBugs], [http://pmd.sourceforge.net PMD], [http://artho.com/jlint JLint], [http://javascriptlint.com/ JavaScript Lint], [http://www.icosaedro.it/phplint/ PHPLint], [http://en.wikipedia.org/wiki/Cppcheck Cppcheck], [http://en.wikipedia.org/wiki/ClamAV ClamAV], [http://en.wikipedia.org/wiki/RATS RATS], and [http://pixybox.seclab.tuwien.ac.at/ Pixy] to scan specific file types, and also contains many custom scanners developed just for Yasca. It is a command-line tool that generates reports in HTML, CSV, XML, SQLite, and other formats. Yasca is easily extensible via a plugin-based architecture, so scanning any particular file is as simple as coming up with the rules or integrating external tools. 
* Yasca also features a simple regular-expression plugin that allows new rules to be written in less than a minute.

|-
| style="width:15%; background:#7B8ABD" align="center"|'''Key Project Information'''
| style="width:12%; background:#cccccc" align="center"|Licensed under [http://en.wikipedia.org/wiki/BSD_license BSD License] [http://en.wikipedia/org/wiki/GPL_license GPL License]
| style="width:12%; background:#cccccc" align="center"|Project Leader [mailto:michael.scovetta(at)gmail.com '''Michael V. Scovetta''']
| style="width:12%; background:#cccccc" align="center"|Project Contributors [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Mailing List [https://lists.owasp.org/mailman/listinfo/owasp-yasca-project '''To Subscribe'''] [mailto:owasp-yasca-project(at)lists.owasp.org '''To Use''']
| style="width:12%; background:#cccccc" align="center"|First Reviewer [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Second Reviewer [mailto:name(at)name '''Name'''] 
| style="width:12%; background:#cccccc" align="center"|OWASP Board Member (if applicable) [mailto:name(at)name '''Name&Email''']
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''PROJECT MAIN LINKS'''
|-
| style="width:100%; background:#cccccc" align="center"|
Yasca is hosted on [https://github.com/scovetta/yasca Github] and has a main project website at [http://scovetta.github.io/yasca/ scovetta.github.io/yasca].

|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''RELATED PROJECTS'''
|-
| style="width:100%; background:#cccccc" align="center"|
* [[:Category:OWASP Orizon Project|OWASP Orizon Project]] 
* [[:Category:OWASP Code Review_Project|OWASP Code Review_Project]]
* [[:Category:OWASP Open Review Project|OWASP Open Review Project]]
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''SPONSORS & GUIDELINES'''
|-
| style="width:50%; background:#cccccc" align="center"|Sponsor name, if applicable
| style="width:50%; background:#cccccc" align="center"|[[:Category:OWASP Yasca Project Roadmap|'''Guidelines/Roadmap''']]
|}
{| style="width:100%" border="0" align="center"
! colspan="5" align="center" style="background:#4058A0; color:white"|ASSESSMENT AND REVIEW PROCESS
|-
| style="width:15%; background:#6C82B5" align="center"|'''Review/Reviewer'''
| style="width:21%; background:#b3b3b3" align="center"|'''Author's Self Evaluation''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''First Reviewer''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''Second Reviewer''' (applicable for Beta Quality & further)
| style="width:22%; background:#b3b3b3" align="center"|'''OWASP Board Member''' (applicable just for Release Quality)
|-
| style="width:15%; background:#7B8ABD" align="center"|'''First Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- Which status has been reached? '''Beta Status''' --------- [[Project Information:template Yasca Project - First Review - Self Evaluation - A|See&Edit: First Review/SelfEvaluation (A)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Not yet''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - First Reviewer - B|See&Edit: First Review/1st Reviewer (B)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - Second Reviewer - C|See&Edit: First Review/2nd Reviewer (C)]]
| style="width:22%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - OWASP Board Member - D|See/Edit: First Review/Board Member (D)]]
|-
|}

OWASP Data Exchange Format Project

2011-07-22T16:12:05Z

Scovetta:

==== Main ====

At the moment exchanging data between pentest tools it is far too difficult.

So ... the purpose of this project is to define a simple, open format for exchanging data between pentest tools!

Involvement is encouraged, so if you would like to contribute to this project then please join the [https://lists.owasp.org/mailman/listinfo/owasp-data-exchange-format mailing list] and / or contact one of the project leaders.

=== Requirements ===

The format must be open, and licensed so that it can be adopted by all products, whether open, closed, free or commercial.

It must be as simple to adopt as possible, and ideally based on existing open formats.

==== Roadmap ====

The high level roadmap is:

# Psiinon to document a strawman proposal
# All - rip the strawman to pieces and agree an improved format
# Finalize DEF v1.0
# Supporting project leaders to adopt the format in their tools
# Publicize and drive adoption in other tools
# Learn from our experiences and start on the next version, repeat ;)

==== Strawman ====

This tab will document a strawman proposal for all concerned to rip to pieces :)

==== Supporting projects ====

The following project leaders have agreed to support this format and (once it has been agreed) adopt it within their projects.

If you would like your project added to this list then feel free to update it, or contact one of the project leaders to update it for you.

{| border="1" align="left" cellspacing="1" cellpadding="1"
|-
! scope="col" | Project
! scope="col" | Leader
|-
| [http://portswigger.net/burp/ Burp Suite]
| Dafydd Stuttard (PortSwigger)
|-
| [https://www.owasp.org/index.php/OWASP_O2_Platform O2 Platform]
| [[User:Dinis_Cruz|Dinis Cruz]]
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project WebScarab]
| [[User:Daniel_Brzozowski|Daniel Brzozowski]]
|-
| [http://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy]
| [[User:Psiinon|Simon Bennetts (Psiinon)]]
|-
| [http://www.owasp.org/index.php/OWASP_Yasca_Project Yasca]
| [[User:Scovetta|Michael Scovetta (Scovetta)]]
|}

==== Project About ====

{{:Projects/OWASP Data Exchange Format Project | Project About}}

 __NOTOC__ <headertabs />

[[Category:OWASP_Project|Data Exchange Format Project]] [[Category:OWASP_Tool]] [[Category:OWASP_Alpha_Quality_Tool]]

User:Scovetta

2011-04-13T11:58:37Z

Scovetta:

== Current OWASP Involvement ==

I am current involved in a number of OWASP projects, including:

* creator of the [http://www.owasp.org/index.php/Category:OWASP_Yasca_Project OWASP Yasca Project]
* contributor to the [[:OWASP Guide Project]]

To see my wiki contributions, [[:Special:Contributions/scovetta|click here]].

== Résumé ==
* [http://www.scovetta.com/download/resume-latest.pdf Michael Scovetta's Résumé]

== Security vulnerability research==
* [http://www.scovetta.com/view.php?f=SCL-2010-001.txt Multiple Vulnerabilities in WebCalendar]
* [http://www.scovetta.com/view.php?f=SCL-2005-001.txt WebCalendar: Multiple SQL Injection Vulnerabilities from Encoded Cookie]
* [http://www.scovetta.com/view.php?f=SCL-2005-002.txt IDN Feature Workaround via Proxy.pac]

== Presentations/Video ==
* [http://www.youtube.com/watch?v=OjtjZSHWkyo Static Analyzer v1.0 Demo (Yasca)], 17/Sep/10
* [http://www.nyphp.org/PHP-Presentations/134_Static-Code-Analysis-PHP-Zend-Framework-Circa-2009 Static Code Analysis Using Yasca], New York PHP, 24/Feb/09

== External Sites ==
* [http://www.scovetta.com Personal Home Page]
* [http://www.linkedin.com/in/scovetta LinkedIn Profile]
* [http://www.tasecuritygroup.com Trusted Advisor Security]

How to Join a Committee

2011-03-16T16:51:48Z

Scovetta: Removed myself

[[:Global Committee Pages|Click here to return to the Global Committee Pages]].

The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the ongoing availability and support for our work. 

 Many individuals start with OWASP as a user of a tool/guide or attending a local chapter. From that they may become a individual project leader on a new tool/guide or may serve on the board of a local OWASP chapter. Becoming a member of one of the Global Committees is not only a great achievement in the technical community, but is an opportunity to directly impact the future of OWASP Foundation. 

 Global Committees are designed to develop a committee plan and then work on a global effort with your peers from around the world. Ideally you nominate a peer as a regional spokesperson and he/she is the conduit for global issues that has approx., 10 hrs per month to volunteer time to OWASP Foundation. 

 To encourage focus and participation, we suggest that volunteers contribute to '''ONE COMMITTEE''' only. Individuals are welcome to participate in whatever committee they prefer, but may only be officially elected to serve on one committee.

 This NEW ROLE was announced at the OWASP Portugal Summit and several individuals were nominated from the floor of the event and a motion was approved at the public board meeting in November 2008. There is still time.... If you were not at the event and would like to get involved with a global role and are either a project leader or chapter leader and it must be supported by 5 endorsements of you regional peers*. We are calling this the "2009 2nd wave applicants" 

*Note that to prevent conflict of interest, Board members cannot endorse candidates for any committee nor can a committee member endorse a candidate for their own committee. Committee members may endorse candidates for other committees to which they do not belong.
* Committee members who wish to transfer between committees, should discuss this with their current committee first. They must begin a new application for the committee they want to move to.

Still have questions - [https://spreadsheets.google.com/a/owasp.org/viewform?hl=en&formkey=dFN1R2NIMTNROXN3dml4ZEcxXzJQYXc6MQ#gid=0 Contact Us]

 Fill in one of the below application forms. 

 

=== Current Committee MEMBERS UNDER ELECTION - APPLICATION FORMS ===

{| style="width: 90%" class="FCK__ShowTableBorders" border="0" align="center"
|-
| style="background: rgb(64,88,160); color: white; -moz-background-inline-policy: continuous" colspan="8" align="center" | '''OWASP GLOBAL COMMITTEES - UNDER ELECTION'''
|-
| style="width: 15%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | OWASP GLOBAL COMMITTEES
| style="width: 15%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Projects'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Membership'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Education'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Conferences'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Industry'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Chapters'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''[[OWASP_Connections_Committee | Connections]]'''
|-
| style="width: 15%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | '''Applications ->'''
| style="width: 15%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | '''[[Global Projects and Tools Committee - Application 1|Aryavalli Gandhi]]''' '''[[Global Projects and Tools Committee - Application 2|Brad Causey]]''' [[Global Projects and Tools Committee - Application 3|Chris Schmidt]] [[Global Projects and Tools Committee - Application 4|Justin Searle]] [[Global Projects and Tools Committee - Application 5|Larry Casey]] [[Global Projects and Tools Committee - Application 6|Keith Turpin]] add [[Global Projects and Tools Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Membership Committee - Application 1|Tony UcedaVelez]] [[Global Membership Committee - Application 2|Mateo Martínez]] [[Global Membership Committee - Application 3|Ofer Maor]] [[Global Membership Committee - Application 4|Aryavalli Gandhi]] [[Global Membership Committee - Application 5|Helen Gao]] add [[Global Membership - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Education Committee - Application 2|'''Carlos Serrão''']] [[Global Education Committee - Application 3|'''Sébastien Gioria''']] [[Global Education Committee - Application 5|Marc Chisinevski]] [[Global Education Committee - Application 6|Zaki Akhmad]] add [[Global Education Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" |
 [[Global Conferences Committee - Application 7|'''Mohd Fazli Azran''']] [[Global Conferences Committee - Application 8|'''Zhendong Yu ''']] [[Global Conferences Committee - Application 9|'''Benjamin (Ben) Tomhave''']] [[Global Conferences Committee - Application 10|'''Applicant 10''']] add [[Global Conferences Committee - Template|more]], if needed

| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Industry Committee - Application 1|'''Colin Watson''']] [[Global Industry Committee - Application 2|'''Alexander Fry''']] [[Global Industry Committee - Application 3|'''Yiannis Pavlosoglou''']] [[Global Industry Committee - Application 4|'''Joe Bernik''']] [[Global Industry Committee - Application 5|'''Lorna Alamri''']] [[Global Industry Committee - Application 6|Nishi Kumar]] [[Global Industry Committee - Application 7|Applicant 7]] [[Global Industry Committee - Application 8|Applicant 8]] [[Global Industry Committee - Application 9|Applicant 9]] [[Global Industry Committee - Application 10|Applicant 10]] [[Global Industry Committee - Application 11|Applicant 11]] [[Global Industry Committee - Application 12|Applicant 12]] add [[Global Industry Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Chapter Committee - Application 2|Matthew Chalmers]] [[Global Chapter Committee - Application 3|Mandeep Khera]] [[Global Chapter Committee - Application 4|Tin Zaw.]] [[Global Chapter Committee - Application 5|L. Gustavo C. Barbato]] [[Global Chapter Committee - Application 6|Ofer Maor]] [[Global Chapter Committee - Application 7|Gandhi Aryavalli]] add [[Global Chpaters Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | '''[[OWASP Connections Committee - Application 1|Lorna Alamri]]''' [[OWASP Connections Committee - Application 2|'''Robert Hansen''']] [[OWASP Connections Committee - Application 3|'''Justin Clarke''']] [[OWASP Connections Committee - Application 4|'''Jim Manico''']] [[OWASP Connections Committee - Application 5|Greg Genung]] [[OWASP Connections Committee - Application 6|Doug Wilson]] add [[OWASP Connections Committee - Template|more]], if needed
|}

=== MEMBERS WITH OWASP SUMMIT'S APPROVAL ===

{| border="0" align="center" style="width: 90%;"
|-
| align="center" colspan="7" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); -moz-background-inline-policy: continuous; color: white;" | '''OWASP GLOBAL COMMITTEES - ELECTED AT THE OWASP SUMMIT 08'''
|-
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 15%; -moz-background-inline-policy: continuous;" | OWASP GLOBAL COMMITTEES
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 15%; -moz-background-inline-policy: continuous;" | [[Global Projects Committee|'''Projects''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Membership Committee|'''Membership''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Education Committee|'''Education''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Conferences Committee|'''Conferences''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Industry Committee|'''Industry''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Chapter Committee|'''Chapters''']]
|-
| align="center" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 15%; -moz-background-inline-policy: continuous;" | Current committee members
| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 15%; -moz-background-inline-policy: continuous;" |
*[[:User:Dinis.cruz|Dinis Cruz]]
*[[:Image:Image021-Jason Li.jpg|Jason Li]]
*[[:Image:Image019-Matt Tesauro.jpg|Matt Tesauro]]
*[[:Image:Image022-Leo Cavallari.jpg|Leo Cavallari]]
*[[:Image:Image020-Pravir Chandra.jpg|Pravir Chandra]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[:User:Brennan|Tom Brennan]]
*[[:Image:Image018-Dan Cornell.jpg|Dan Cornell]]
*[[:Image:Image017-Michael Coates.jpg|Michael Coates]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[User:Sdeleersnyder|Seba Deleersnyder]]
*[[:Image:Image007-Martin Knobloch.jpg|Martin Knobloch]]
*[[:Image:Image012-Mano Paul.jpg|Mano Paul]]
*[[:Image:Image008-Eduardo Neves.jpg|Eduardo Neves]]
*[[:Image:Image010-Kuai Hinjosa.jpg|Kuai Hinjosa]]
*[[:Image:Image011-Cecil Su.jpg|Cecil Su]]
*[[:Image:Image009-Fabio Cerullo.jpg|Fabio Cerullo]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[:User:Wichers|Dave Wichers]]
*[[:Image:Image005-Wayne Huang.jpg|Wayne Huang]]
*[[:Image:Image003-Steve Antoniewicz.jpg|Steve Antoniewicz]]
*[[:Image:Image004-Dhruv Soi.jpg|Dhruv Soi]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[:User:Brennan|Tom Brennan]]
*[[:Image:Image014 Rex Booth.jpg|Rex Booth]]
*[[:Image:Image016-Georg Hess.jpg|Georg Hess]]
*[[:Image:Image013-Eoin Keary.jpg|Eoin Keary]]
*[[:Image:Image015-David Campbell.jpg|David Campbell]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[User:Sdeleersnyder|Seba Deleersnyder]]
*[[:Image:Image002-Puneet Mehta.jpg|Puneet Mehta]]
*[[:Image:Image001-Wayne Huang.jpg|Wayne Huang]]

|}

How to Join a Committee

2011-02-16T01:20:22Z

Scovetta: Added myself to the list of applicants for the Global Industry Committee

[[:Global Committee Pages|Click here to return to the Global Committee Pages]].

The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the ongoing availability and support for our work. 

 Many individuals start with OWASP as a user of a tool/guide or attending a local chapter. From that they may become a individual project leader on a new tool/guide or may serve on the board of a local OWASP chapter. Becoming a member of one of the Global Committees is not only a great achievement in the technical community, but is an opportunity to directly impact the future of OWASP Foundation. 

 Global Committees are designed to develop a committee plan and then work on a global effort with your peers from around the world. Ideally you nominate a peer as a regional spokesperson and he/she is the conduit for global issues that has approx., 10 hrs per month to volunteer time to OWASP Foundation. 

 This NEW ROLE was announced at the OWASP Portugal Summit and several individuals were nominated from the floor of the event and a motion was approved at the public board meeting in November 2008. There is still time.... If you were not at the event and would like to get involved with a global role and are either a project leader or chapter leader and it must be supported by 5 endorsements of you regional peers*. We are calling this the "2009 2nd wave applicants" 

*Note that to prevent conflict of interest, Board members cannot endorse candidates for any committee nor can a committee member endorse a candidate for their own committee. Committee members may endorse candidates for other committees to which they do not belong.

Still have questions - [https://spreadsheets.google.com/a/owasp.org/viewform?hl=en&formkey=dFN1R2NIMTNROXN3dml4ZEcxXzJQYXc6MQ#gid=0 Contact Us]

 Fill in one of the below application forms. 

 

=== Current Committee MEMBERS UNDER ELECTION - APPLICATION FORMS ===

{| style="width: 90%" class="FCK__ShowTableBorders" border="0" align="center"
|-
| style="background: rgb(64,88,160); color: white; -moz-background-inline-policy: continuous" colspan="8" align="center" | '''OWASP GLOBAL COMMITTEES - UNDER ELECTION'''
|-
| style="width: 15%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | OWASP GLOBAL COMMITTEES
| style="width: 15%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Projects'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Membership'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Education'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Conferences'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Industry'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''Chapters'''
| style="width: 14%; background: rgb(242,152,76); -moz-background-inline-policy: continuous" align="center" | '''[[OWASP_Connections_Committee | Connections]]'''
|-
| style="width: 15%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | '''Applications ->'''
| style="width: 15%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | '''[[Global Projects and Tools Committee - Application 1|Aryavalli Gandhi]]''' '''[[Global Projects and Tools Committee - Application 2|Brad Causey]]''' [[Global Projects and Tools Committee - Application 3|Applicant 3]] [[Global Projects and Tools Committee - Application 4|Applicant 4]] [[Global Projects and Tools Committee - Application 5|Applicant 5]] add [[Global Projects and Tools Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Membership Committee - Application 1|Tony UcedaVelez]] [[Global Membership Committee - Application 2|Mateo Martínez]] [[Global Membership Committee - Application 3|Ofer Maor]] [[Global Membership Committee - Application 4|Aryavalli Gandhi]] [[Global Membership Committee - Application 5|Applicant 5]] add [[Global Membership - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Education Committee - Application 2|'''Carlos Serrão''']] [[Global Education Committee - Application 3|'''Sébastien Gioria''']] [[Global Education Committee - Application 5|Marc Chisinevski]] add [[Global Education Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" |
 [[Global Conferences Committee - Application 7|'''Mohd Fazli Azran''']] [[Global Conferences Committee - Application 8|'''Applicant 8''']] [[Global Conferences Committee - Application 9|'''Applicant 9''']] [[Global Conferences Committee - Application 10|'''Applicant 10''']] add [[Global Conferences Committee - Template|more]], if needed

| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Industry Committee - Application 1|'''Colin Watson''']] [[Global Industry Committee - Application 2|'''Alexander Fry''']] [[Global Industry Committee - Application 3|'''Yiannis Pavlosoglou''']] [[Global Industry Committee - Application 4|'''Joe Bernik''']] [[Global Industry Committee - Application 5|'''Lorna Alamri''']] [[Global Industry Committee - Application 6|Nishi Kumar]] [[Global Industry Committee - Application 7|Applicant 7]] [[Global Industry Committee - Application 8|Applicant 8]] [[Global Industry Committee - Application 9|Applicant 9]] [[Global Industry Committee - Application 10|Applicant 10]] [[Global Industry Committee - Application 11|Applicant 11]] [[Global Industry Committee - Application 12|Applicant 12]] [[Global Industry Committee - Application 13|Michael Scovetta]] add [[Global Industry Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | [[Global Chapter Committee - Application 2|Matthew Chalmers]] [[Global Chapter Committee - Application 3|Mandeep Khera]] [[Global Chapter Committee - Application 4|Tin Zaw.]] [[Global Chapter Committee - Application 5|L. Gustavo C. Barbato]] [[Global Chapter Committee - Application 6|Ofer Maor]] [[Global Chapter Committee - Application 7|Gandhi Aryavalli]] add [[Global Chpaters Committee - Template|more]], if needed
| style="width: 14%; background: rgb(204,204,204); -moz-background-inline-policy: continuous" align="center" | '''[[OWASP Connections Committee - Application 1|Lorna Alamri]]''' [[OWASP Connections Committee - Application 2|'''Robert Hansen''']] [[OWASP Connections Committee - Application 3|'''Justin Clarke''']] [[OWASP Connections Committee - Application 4|'''Jim Manico''']] [[OWASP Connections Committee - Application 5|Greg Genung]] add [[OWASP Connections Committee - Template|more]], if needed
|}

=== MEMBERS WITH OWASP SUMMIT'S APPROVAL ===

{| border="0" align="center" style="width: 90%;"
|-
| align="center" colspan="7" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); -moz-background-inline-policy: continuous; color: white;" | '''OWASP GLOBAL COMMITTEES - ELECTED AT THE OWASP SUMMIT 08'''
|-
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 15%; -moz-background-inline-policy: continuous;" | OWASP GLOBAL COMMITTEES
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 15%; -moz-background-inline-policy: continuous;" | [[Global Projects Committee|'''Projects''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Membership Committee|'''Membership''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Education Committee|'''Education''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Conferences Committee|'''Conferences''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Industry Committee|'''Industry''']]
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 152, 76); width: 14%; -moz-background-inline-policy: continuous;" | [[Global Chapter Committee|'''Chapters''']]
|-
| align="center" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 15%; -moz-background-inline-policy: continuous;" | Current committee members
| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 15%; -moz-background-inline-policy: continuous;" |
*[[:User:Dinis.cruz|Dinis Cruz]]
*[[:Image:Image021-Jason Li.jpg|Jason Li]]
*[[:Image:Image019-Matt Tesauro.jpg|Matt Tesauro]]
*[[:Image:Image022-Leo Cavallari.jpg|Leo Cavallari]]
*[[:Image:Image020-Pravir Chandra.jpg|Pravir Chandra]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[:User:Brennan|Tom Brennan]]
*[[:Image:Image018-Dan Cornell.jpg|Dan Cornell]]
*[[:Image:Image017-Michael Coates.jpg|Michael Coates]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[User:Sdeleersnyder|Seba Deleersnyder]]
*[[:Image:Image007-Martin Knobloch.jpg|Martin Knobloch]]
*[[:Image:Image012-Mano Paul.jpg|Mano Paul]]
*[[:Image:Image008-Eduardo Neves.jpg|Eduardo Neves]]
*[[:Image:Image010-Kuai Hinjosa.jpg|Kuai Hinjosa]]
*[[:Image:Image011-Cecil Su.jpg|Cecil Su]]
*[[:Image:Image009-Fabio Cerullo.jpg|Fabio Cerullo]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[:User:Wichers|Dave Wichers]]
*[[:Image:Image005-Wayne Huang.jpg|Wayne Huang]]
*[[:Image:Image003-Steve Antoniewicz.jpg|Steve Antoniewicz]]
*[[:Image:Image004-Dhruv Soi.jpg|Dhruv Soi]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[:User:Brennan|Tom Brennan]]
*[[:Image:Image014 Rex Booth.jpg|Rex Booth]]
*[[:Image:Image016-Georg Hess.jpg|Georg Hess]]
*[[:Image:Image013-Eoin Keary.jpg|Eoin Keary]]
*[[:Image:Image015-David Campbell.jpg|David Campbell]]

| align="left" style="background: none repeat scroll 0% 0% rgb(204, 204, 204); width: 14%; -moz-background-inline-policy: continuous;" |
*[[User:Sdeleersnyder|Seba Deleersnyder]]
*[[:Image:Image002-Puneet Mehta.jpg|Puneet Mehta]]
*[[:Image:Image001-Wayne Huang.jpg|Wayne Huang]]

|}

Global Industry Committee - Application 13

2011-02-16T01:18:16Z

Scovetta:

[[How to Join a Committee|Click here to return to 'How to Join a Committee' page]]

----
{| style="width:100%" border="0" align="center"
! colspan="2" align="center" style="background:#4058A0; color:white"|'''COMMITTEE APPLICATION FORM'''
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Applicant's Name'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|Michael Scovetta
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Current and past OWASP Roles'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|OWASP Yasca Project (Lead), OWASP Development Guide (Contributor)
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Committee Applying for'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|Global Industry Committee
|}
----

----
Please be aware that for an application to be considered by the board, '''you MUST have 5 recommendations'''.
An incomplete application will not be considered for vote.
----

----
{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''COMMITTEE RECOMMENDATIONS'''
|-
! align="center" style="background:white; color:white"|
! align="center" style="background:#7B8ABD; color:white"|'''Who Recommends/Name'''
! align="center" style="background:#7B8ABD; color:white"|'''Role in OWASP'''
! align="center" style="background:#7B8ABD; color:white"|'''Recommendation Content'''
|-
| style="width:3%; background:#cccccc" align="center"|'''1'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|-
| style="width:3%; background:#cccccc" align="center"|'''2'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|-
| style="width:3%; background:#cccccc" align="center"|'''3'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|-
| style="width:3%; background:#cccccc" align="center"|'''4'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|-
| style="width:3%; background:#cccccc" align="center"|'''5'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|}
----

User:Scovetta

2010-12-13T14:20:37Z

Scovetta: Initial Version

== Current OWASP Involvement ==

I am current involved in a number of OWASP projects, including:

* creator of the [http://www.owasp.org/index.php/Category:OWASP_Yasca_Project OWASP Yasca Project]
* contributor to the [[:OWASP Guide Project]]

To see my wiki contributions, [[:Special:Contributions/scovetta|click here]].

== Résumé ==
* [http://www.scovetta.com/download/resume-20101213.pdf Michael Scovetta's Résumé]

== Security vulnerability research==
* [http://www.scovetta.com/view.php?f=SCL-2010-001.txt Multiple Vulnerabilities in WebCalendar]
* [http://www.scovetta.com/view.php?f=SCL-2005-001.txt WebCalendar: Multiple SQL Injection Vulnerabilities from Encoded Cookie]
* [http://www.scovetta.com/view.php?f=SCL-2005-002.txt IDN Feature Workaround via Proxy.pac]

== Presentations/Video ==
* [http://www.youtube.com/watch?v=OjtjZSHWkyo Static Analyzer v1.0 Demo (Yasca)], 17/Sep/10
* [http://www.nyphp.org/PHP-Presentations/134_Static-Code-Analysis-PHP-Zend-Framework-Circa-2009 Static Code Analysis Using Yasca], New York PHP, 24/Feb/09

== External Sites ==
* [http://www.scovetta.com Personal Home Page]
* [http://www.linkedin.com/in/scovetta LinkedIn Profile]
* [http://www.tasecuritygroup.com Trusted Advisor Security]

OWASP Trainers/Volunteer 3

2010-12-13T13:55:51Z

Scovetta:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Trainers Volunteers Tab</noinclude>
|-
| trainer_name1 = Michael Scovetta
| trainer_email1 = michael.scovetta@gmail.com
| trainer_wiki_username1 = scovetta
|-
| project_interested_in_presenting = OWASP Yasca, OWASP Top 10, OWASP Development Guide
|-
| project_already_presented_name1 = OWASP Yasca
| project_already_presented_url_1 = http://www.scovetta.com/yasca/nyphp-yasca.pdf
| project_already_presented_name2 =
| project_already_presented_url_2 =
| project_already_presented_name3 =
| project_already_presented_url_3 =
| project_already_presented_name4 =
| project_already_presented_url_4 =
| project_already_presented_name5 =
| project_already_presented_url_5 =
|-
| current_location = Long Island, NY
|-
| trainer_name_mask =  Volunteer_3
| trainer_home_page =  OWASP_Trainers/Volunteer_3
}}

OWASP Trainers/Volunteer 3

2010-11-24T17:14:22Z

Scovetta: Added myself

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Trainers Volunteers Tab</noinclude>
|-
| trainer_name1 = Michael Scovetta
| trainer_email1 = michael.scovetta@gmail.com
| trainer_wiki_username1 = scovetta
|-
| project_interested_in_presenting = OWASP Yasca
|-
| project_already_presented_name1 = OWASP Yasca
| project_already_presented_url_1 = http://www.scovetta.com/yasca/nyphp-yasca.pdf
| project_already_presented_name2 =
| project_already_presented_url_2 =
| project_already_presented_name3 =
| project_already_presented_url_3 =
| project_already_presented_name4 =
| project_already_presented_url_4 =
| project_already_presented_name5 =
| project_already_presented_url_5 =
|-
| current_location = Long Island, NY
|-
| trainer_name_mask =  Volunteer_3
| trainer_home_page =  OWASP_Trainers/Volunteer_3
}}

GPC Project Reviewers/Volunteer 5

2010-09-02T17:13:22Z

Scovetta: Added myself in.

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Reviewers Volunteers Tab</noinclude>
|-
| project_reviewer_name1 = Michael Scovetta
| project_reviewer_email1 = michael.scovetta@gmail.com
| project_reviewer_wiki_username1 = scovetta
|-
| type_of_project_interested_in_reviewing = Best practices, code review, templates
|-
| project_currently_reviewing_name1 = OWASP Secure Coding Practices - Quick Reference Guide
| project_currently_reviewing_url_1 = http://www.owasp.org/index.php/Projects/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide
| project_currently_reviewing_name2 =
| project_currently_reviewing_url_2 =
| project_currently_reviewing_name3 =
| project_currently_reviewing_url_3 =
| project_currently_reviewing_name4 =
| project_currently_reviewing_url_4 =
| project_currently_reviewing_name5 =
| project_currently_reviewing_url_5 =
|-
|project_reviewed_name1 = 
|project_reviewed_url_1 = 
|project_reviewed_name2 =
|project_reviewed_url_2 =
|project_reviewed_name3 =
|project_reviewed_url_3 =
|project_reviewed_name4 =
|project_reviewed_url_4 =
|project_reviewed_name5 =
|project_reviewed_url_5 =
|-
| reviewer_name_mask = 
| reviewer_home_page =  GPC_Project_Reviewers/Volunteer_5
}}

Category:OWASP Vulnerability Data Model Project Download

2009-11-13T01:06:44Z

Scovetta: Created page with '=== Download === You can download the latest version of the OVDMP here. The data model itself currently requires [http://wb.mysql.com/ MySQL Workbench] in order to view. *[[Med…'

=== Download ===

You can download the latest version of the OVDMP here. The data model itself currently requires [http://wb.mysql.com/ MySQL Workbench] in order to view.

*[[Media:Ovdmp-0.10.zip|OVDMP v0.10]]

[[Category:OWASP Vulnerability Data Model Project]]

File:Ovdmp-0.10.zip

2009-11-13T01:04:53Z

Scovetta: OVDMP v0.10 - Requires MySQL Workbench in order to view.

OVDMP v0.10 - Requires MySQL Workbench in order to view.

Project Information:template Vulnerability Data Model Project

2009-10-17T16:40:45Z

Scovetta: Initial Page

{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''PROJECT IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|'''OWASP Vulnerability Data Model Project'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|
* The goal of this project is to define a common data model that other OWASP, open source, and commercial tools can use to store vulnerability information discovered during manual or automated testing, including both penetration testing and static analysis.
* The data model will be available in both abstract and physical forms.
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Key Project Information'''
| style="width:12%; background:#cccccc" align="center"|Licensed under [http://en.wikipedia/org/wiki/GPL_license GPL License]
| style="width:12%; background:#cccccc" align="center"|Project Leader [mailto:michael.scovetta(at)gmail.com '''Michael V. Scovetta''']
| style="width:12%; background:#cccccc" align="center"|Project Contributors [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Mailing List [https://lists.owasp.org/mailman/listinfo/owasp-yasca-project '''To Subscribe'''] [mailto:owasp-vdm-project(at)lists.owasp.org '''To Use''']
| style="width:12%; background:#cccccc" align="center"|First Reviewer [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Second Reviewer [mailto:name(at)name '''Name'''] 
| style="width:12%; background:#cccccc" align="center"|OWASP Board Member (if applicable) [mailto:name(at)name '''Name&Email''']
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''PROJECT MAIN LINKS'''
|-
| style="width:100%; background:#cccccc" align="center"|
TBD.

|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''RELATED PROJECTS'''
|-
| style="width:100%; background:#cccccc" align="center"|
* [[:Category:OWASP Orizon Project|OWASP Orizon Project]] 
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''SPONSORS & GUIDELINES'''
|-
| style="width:50%; background:#cccccc" align="center"|Sponsor name, if applicable
| style="width:50%; background:#cccccc" align="center"|[[:Category:OWASP Vulnerability Data Model Project Roadmap|'''Guidelines/Roadmap''']]
|}
{| style="width:100%" border="0" align="center"
! colspan="5" align="center" style="background:#4058A0; color:white"|ASSESSMENT AND REVIEW PROCESS
|-
| style="width:15%; background:#6C82B5" align="center"|'''Review/Reviewer'''
| style="width:21%; background:#b3b3b3" align="center"|'''Author's Self Evaluation''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''First Reviewer''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''Second Reviewer''' (applicable for Beta Quality & further)
| style="width:22%; background:#b3b3b3" align="center"|'''OWASP Board Member''' (applicable just for Release Quality)
|-
| style="width:15%; background:#7B8ABD" align="center"|'''First Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- Which status has been reached? '''Beta Status''' --------- [[Project Information:template Yasca Project - First Review - Self Evaluation - A|See&Edit: First Review/SelfEvaluation (A)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Not yet''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - First Reviewer - B|See&Edit: First Review/1st Reviewer (B)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - Second Reviewer - C|See&Edit: First Review/2nd Reviewer (C)]]
| style="width:22%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - OWASP Board Member - D|See/Edit: First Review/Board Member (D)]]
|-
|}

Category:OWASP Vulnerability Data Model Project

2009-10-17T16:37:55Z

Scovetta: Initial Page

[[:Category:OWASP Project|Click here to return to OWASP Projects page.]] 
[[:Project Information:template Vulnerability Data Model Project|Click here to see (& edit, if wanted) the template.]]
{{:Project Information:template Vulnerability Data Model Project}}

[[Category:OWASP Project]]
[[Category:OWASP Download]]

Phoenix/Tools

2009-05-29T00:45:20Z

Scovetta: Fixed capitalization

__NOTOC__
Please send comments or questions to the [https://lists.owasp.org/mailman/listinfo/owasp-phoenix Phoenix-OWASP mailing-list].

==LiveCDs==
Monday, January 29, 2007 4:02 PM 828569600 AOC_Labrat-ALPHA-0010.iso - http://www.packetfocus.com/hackos/ 
DVL (Damn Vulnerable Linux) - http://www.damnvulnerablelinux.org/ 

==Test sites / testing grounds==
SPI Dynamics (live) - http://zero.webappsecurity.com/ 
Cenzic (live) - http://crackme.cenzic.com/ 
Watchfire (live) - http://demo.testfire.net/ 
Acunetix (live) - http://testphp.acunetix.com/ http://testasp.acunetix.com http://testaspnet.acunetix.com 
WebMaven / Buggy Bank - http://www.mavensecurity.com/webmaven 
Foundstone SASS tools - http://www.foundstone.com/us/resources-free-tools.asp 
Updated HackmeBank - http://www.o2-ounceopen.com/technical-info/2008/12/8/updated-version-of-hacmebank.html 
OWASP WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project 
OWASP SiteGenerator - http://www.owasp.org/index.php/Owasp_SiteGenerator 
Stanford SecuriBench - http://suif.stanford.edu/~livshits/securibench/ 
SecuriBench Micro - http://suif.stanford.edu/~livshits/work/securibench-micro/ 

==HTTP proxying / editing==
WebScarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project 
Burp - http://www.portswigger.net/ 
Paros - http://www.parosproxy.org/ 
Fiddler - http://www.fiddlertool.com/ 
Web Proxy Editor - http://www.microsoft.com/mspress/companion/0-7356-2187-X/ 
Pantera - http://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project 
Suru - http://www.sensepost.com/research/suru/ 
httpedit (curses-based) - http://www.neutralbit.com/en/rd/httpedit/ 
Charles - http://www.xk72.com/charles/ 
Odysseus - http://www.bindshell.net/tools/odysseus 
Burp, Paros, and WebScarab for Mac OS X - http://www.corsaire.com/downloads/ 
Web-application scanning tool from `Network Security Tools'/O'Reilly - http://examples.oreilly.com/networkst/ 
JS Commander - http://jscmd.rubyforge.org/ 
Ratproxy - http://code.google.com/p/ratproxy/ 

==RSnake's XSS cheat sheet based-tools, webapp fuzzing, and encoding tools==
Wfuzz - http://www.edge-security.com/wfuzz.php 
ProxMon - http://www.isecpartners.com/proxmon.html 
Wapiti - http://wapiti.sourceforge.net/ 
Grabber - http://rgaucher.info/beta/grabber/ 
XSSScan - http://darkcode.ath.cx/scanners/XSSscan.py 
CAL9000 - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project 
HTMangLe - http://www.fishnetsecurity.com/Tools/HTMangLe/publish.htm 
JBroFuzz - http://sourceforge.net/projects/jbrofuzz 
XSSFuzz - http://ha.ckers.org/blog/20060921/xssfuzz-released/ 
WhiteAcid's XSS Assistant - http://www.whiteacid.org/greasemonkey/ 
Overlong UTF - http://www.microsoft.com/mspress/companion/0-7356-2187-X/ 
[TGZ] MielieTool (SensePost Research) - http://packetstormsecurity.org/UNIX/utilities/mielietools-v1.0.tgz 
RegFuzzer: test your regular expression filter - http://rgaucher.info/b/index.php/post/2007/05/26/RegFuzzer%3A-Test-your-regular-expression-filter 
screamingCobra - http://www.dachb0den.com/projects/screamingcobra.html 
SPIKE and SPIKE Proxy - http://immunitysec.com/resources-freesoftware.shtml 
RFuzz - http://rfuzz.rubyforge.org/ 
WebFuzz - http://www.codebreakers-journal.com/index.php?option=com_content&task=view&id=112&Itemid=99999999 
TestMaker - http://www.pushtotest.com/Docs/downloads/features.html 
ASP Auditor - http://michaeldaw.org/projects/asp-auditor-v2/ 
WSTool - http://wstool.sourceforge.net/ 
Web Hack Control Center (WHCC) - http://ussysadmin.com/whcc/ 
Web Text Converter - http://www.microsoft.com/mspress/companion/0-7356-2187-X/ 
HackBar (Firefox Add-on) - https://addons.mozilla.org/firefox/3899/ 
Net-Force Tools (NF-Tools, Firefox Add-on) - http://www.net-force.nl/library/downloads/ 
PostIntercepter (Greasemonkey script) - http://userscripts.org/scripts/show/743 

==HTTP general testing / fingerprinting==
Wbox: HTTP testing tool - http://hping.org/wbox/ 
ht://Check - http://htcheck.sourceforge.net/ 
Mumsie - http://www.lurhq.com/tools/mumsie.html 
WebInject - http://www.webinject.org/ 
Torture.pl Home Page - http://stein.cshl.org/~lstein/torture/ 
JoeDog's Seige - http://www.joedog.org/JoeDog/Siege/ 
OPEN-LABS: metoscan (http method testing) - http://www.open-labs.org/ 
Load-balancing detector - http://ge.mine.nu/lbd.html 
HMAP - http://ujeni.murkyroc.com/hmap/ 
Net-Square: httprint - http://net-square.com/httprint/ 
Wpoison: http stress testing - http://wpoison.sourceforge.net/ 
Net-square: MSNPawn - http://net-square.com/msnpawn/index.shtml 
hcraft: HTTP Vuln Request Crafter - http://druid.caughq.org/projects/hcraft/ 
rfp.labs: LibWhisker - http://www.wiretrip.net/rfp/lw.asp 
Nikto - http://www.cirt.net/code/nikto.shtml 
twill - http://twill.idyll.org/ 
DirBuster - http://www.owasp.org/index.php/Category:OWASP_DirBuster_Project 
[ZIP] DFF Scanner - http://security-net.biz/files/dff/DFF.zip 
[ZIP] The Elza project - http://packetstormsecurity.org/web/elza-1.4.7-beta.zip http://www.stoev.org/elza.html 
HackerFox and Hacking Addons Bundled: Portable Firefox with web hacking addons bundled
- http://sf.net/projects/hackfox

==Browser-based HTTP tampering / editing / replaying==
TamperIE - http://www.bayden.com/Other/ 
isr-form - http://www.infobyte.com.ar/developments.html 
Modify Headers (Firefox Add-on) - http://modifyheaders.mozdev.org/ 
Tamper Data (Firefox Add-on) - http://tamperdata.mozdev.org/ 
UrlParams (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1290/ 
TestGen4Web (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1385/ 
DOM Inspector / Inspect This (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1806/ https://addons.mozilla.org/en-US/firefox/addon/1913/ 
LiveHTTPHeaders / Header Monitor (Firefox Add-on) - http://livehttpheaders.mozdev.org/ https://addons.mozilla.org/en-US/firefox/addon/575/ 

==Cookie editing / poisoning==
[TGZ] stompy: session id tool - http://lcamtuf.coredump.cx/stompy.tgz 
Add'N Edit Cookies (AnEC, Firefox Add-on) - http://addneditcookies.mozdev.org/ 
CookieCuller (Firefox Add-on) - http://cookieculler.mozdev.org/ 
CookiePie (Firefox Add-on) - http://www.nektra.com/oss/firefox/extensions/cookiepie/ 
CookieSpy - http://www.codeproject.com/shell/cookiespy.asp 
Cookies Explorer - http://www.dutchduck.com/Features/Cookies.aspx 

==Ajax and XHR scanning==
Sahi - http://sahi.co.in/ 
scRUBYt - http://scrubyt.org/ 
jQuery - http://jquery.com/ 
jquery-include - http://www.gnucitizen.org/projects/jquery-include 
Sprajax - http://www.denimgroup.com/sprajax.html 
Watir - http://wtr.rubyforge.org/ 
Watij - http://watij.com/ 
Watin - http://watin.sourceforge.net/ 
RBNarcissus - http://idontsmoke.co.uk/2005/rbnarcissus/ 
SpiderTest (Spider Fuzz plugin) - http://blog.caboo.se/articles/2007/2/21/the-fabulous-spider-fuzz-plugin 
Javascript Inline Debugger (jasildbg) - http://jasildbg.googlepages.com/ 
Firebug Lite - http://www.getfirebug.com/lite.html 
firewaitr - http://code.google.com/p/firewatir/ 

==RSS extensions and caching==
LiveLines (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/324/ 
rss-cache - http://www.dubfire.net/chris/projects/rss-cache/ 

==SQL injection scanning==
0x90.org: home of Absinthe, Mezcal, etc - http://0x90.org/releases.php 
SQLiX - http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project 
sqlninja: a SQL Server injection and takover tool - http://sqlninja.sourceforge.net/ 
JustinClarke's SQL Brute - http://www.justinclarke.com/archives/2006/03/sqlbrute.html 
BobCat - http://www.northern-monkee.co.uk/projects/bobcat/bobcat.html 
sqlmap - http://sqlmap.sourceforge.net/ 
Scully: SQL Server DB Front-End and Brute-Forcer - http://www.sensepost.com/research/scully/ 
FG-Injector - http://www.flowgate.net/?lang=en&seccion=herramientas 
PRIAMOS - http://www.priamos-project.com/ 

==Web application security malware, backdoors, and evil code==
W3AF: Web Application Attack and Audit Framework - http://w3af.sourceforge.net/ 
Jikto - http://busin3ss.name/jikto-in-the-wild/ 
XSS Shell - http://ferruh.mavituna.com/article/?1338 
XSS-Proxy - http://xss-proxy.sourceforge.net 
AttackAPI - http://www.gnucitizen.org/projects/attackapi/ 
FFsniFF - http://azurit.elbiahosting.sk/ffsniff/ 
HoneyBlog's web-based junkyard - http://honeyblog.org/junkyard/web-based/ 
BeEF - http://www.bindshell.net/tools/beef/ 
Firefox Extension Scanner (FEX) - http://www.gnucitizen.org/projects/fex/ 
What is my IP address? - http://reglos.de/myaddress/ 
xRumer: blogspam automation tool - http://www.botmaster.net/movies/XFull.htm 
SpyJax - http://www.merchantos.com/makebeta/tools/spyjax/ 
Greasecarnaval - http://www.gnucitizen.org/projects/greasecarnaval 
Technika - http://www.gnucitizen.org/projects/technika/ 
Load-AttackAPI bookmarklet - http://www.gnucitizen.org/projects/load-attackapi-bookmarklet 
MD's Projects: JS port scanner, pinger, backdoors, etc - http://michaeldaw.org/my-projects/ 

==Web application services that aid in web application security assessment==
Netcraft - http://www.netcraft.net 
AboutURL - http://www.abouturl.com/ 
The Scrutinizer - http://www.scrutinizethis.com/ 
net.toolkit - http://clez.net/ 
ServerSniff - http://www.serversniff.net/ 
Online Microsoft script decoder - http://www.greymagic.com/security/tools/decoder/ 
Webmaster-Toolkit - http://www.webmaster-toolkit.com/ 
myIPNeighbbors, et al - http://digg.com/security/MyIPNeighbors_Find_Out_Who_Else_is_Hosted_on_Your_Site_s_IP_Address 
PHP charset encoding - http://h4k.in/encoding 
data: URL testcases - http://h4k.in/dataurl 

==Browser-based security fuzzing / checking==
Zalewski's MangleMe - http://lcamtuf.coredump.cx/mangleme/mangle.cgi 
hdm's tools: Hamachi, CSSDIE, DOM-Hanoi, AxMan - http://metasploit.com/users/hdm/tools/ 
Peach Fuzzer Framework - http://peachfuzz.sourceforge.net/ 
TagBruteForcer - http://research.eeye.com/html/tools/RT20060801-3.html 
PROTOS Test-Suite: c05-http-reply - http://www.ee.oulu.fi/research/ouspg/protos/testing/c05/http-reply/index.html 
COMRaider - http://labs.idefense.com 
bcheck - http://bcheck.scanit.be/bcheck/ 
Stop-Phishing: Projects page - http://www.indiana.edu/~phishing/?projects 
LinkScanner - http://linkscanner.explabs.com/linkscanner/default.asp 
BrowserCheck - http://www.heise-security.co.uk/services/browsercheck/ 
Cross-browser Exploit Tests - http://www.jungsonnstudios.com/cool.php 
Stealing information using DNS pinning demo - http://www.jumperz.net/index.php?i=2&a=1&b=7 
Javascript Website Login Checker - http://ha.ckers.org/weird/javascript-website-login-checker.html 
Mozilla Activex - http://www.iol.ie/~locka/mozilla/mozilla.htm 
Jungsonn's Black Dragon Project - http://blackdragon.jungsonnstudios.com/ 
Mr. T (Master Recon Tool, includes Read Firefox Settings PoC) - http://ha.ckers.org/mr-t/ 
Vulnerable Adobe Plugin Detection For UXSS PoC - http://www.0x000000.com/?i=324 
About Flash: is your flash up-to-date? - http://www.macromedia.com/software/flash/about/ 
Test your installation of Java software - http://java.com/en/download/installed.jsp?detect=jre&try=1 
WebPageFingerprint - Light-weight Greasemonkey Fuzzer - http://userscripts.org/scripts/show/30285

==PHP static analysis and file inclusion scanning==
PHP-SAT.org: Static analysis for PHP - http://www.program-transformation.org/PHP/ 
Unl0ck Research Team: tool for searching in google for include bugs - http://unl0ck.net/tools.php 
FIS: File Inclusion Scanner - http://www.segfault.gr/index.php?cat_id=3&cont_id=25 
PHPSecAudit - http://developer.spikesource.com/projects/phpsecaudit 

==PHP Defensive Tools==

PHPInfoSec - Check phpinfo configuration for security - http://phpsec.org/projects/phpsecinfo/

A Greasemonkey Replacement can be found at http://yehg.net/lab/#tools.greasemonkey

Php-Brute-Force-Attack Detector - Detect your web servers being scanned by brute force tools such as WFuzz, OWASP DirBuster and vulnerability scanners such as Nessus, Nikto, Acunetix ..etc.
http://yehg.net/lab/pr0js/files.php/php_brute_force_detect.zip

PHP-Login-Info-Checker - Strictly enforce admins/users to select stronger passwords. It tests cracking passwords against 4 rules. It has also built-in smoke test page via url loginfo_checker.php?testlic

http://yehg.net/lab/pr0js/files.php/loginfo_checkerv0.1.zip

http://yehg.net/lab/pr0js/files.php/phploginfo_checker_demo.zip

php-DDOS-Shield - A tricky script to prevent idiot distributed bots which discontinue their flooding attacks by identifying HTTP 503 header code. http://code.google.com/p/ddos-shield/

PHPMySpamFIGHTER - http://yehg.net/lab/pr0js/files.php/phpmyspamfighter.zip
http://yehg.net/lab/pr0js/files.php/phpMySpamFighter_demo.rar

==Web Application Firewall (WAF) and Intrusion Detection (APIDS) rules and resources==
APIDS on Wikipedia - http://en.wikipedia.org/wiki/APIDS 
PHP Intrusion Detection System (PHP-IDS) - http://php-ids.org/ http://code.google.com/p/phpids/ 
dotnetids - http://code.google.com/p/dotnetids/ 
Secure Science InterScout - http://www.securescience.com/home/newsandevents/news/interscout1.0.html 
Remo: whitelist rule editor for mod_security - http://remo.netnea.com/ 
GotRoot: ModSecuirty rules - http://www.gotroot.com/tiki-index.php?page=mod_security+rules 
The Web Security Gateway (WSGW) - http://wsgw.sourceforge.net/ 
mod_security rules generator - http://noeljackson.com/tools/modsecurity/ 
Mod_Anti_Tamper - http://www.wisec.it/projects.php?id=3 
[TGZ] Automatic Rules Generation for Mod_Security - http://www.wisec.it/rdr.php?fn=/Projects/Rule-o-matic.tgz 
AQTRONIX WebKnight - http://www.aqtronix.com/?PageID=99 
Akismet: blog spam defense - http://akismet.com/ 
Samoa: Formal tools for securing web services - http://research.microsoft.com/projects/samoa/ 

==Web services enumeration / scanning / fuzzing==
WebServiceStudio2.0 - http://www.codeplex.com/WebserviceStudio 
Net-square: wsChess - http://net-square.com/wschess/index.shtml 
WSFuzzer - http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project 
SIFT: web method search tool - http://www.sift.com.au/73/171/sift-web-method-search-tool.htm 
iSecPartners: WSMap, WSBang, etc - http://www.isecpartners.com/tools.html 

==Web application non-specific static source-code analysis==
Pixy: a static analysis tool for detecting XSS vulnerabilities - http://www.seclab.tuwien.ac.at/projects/pixy/ 
Brixoft.Net: Source Edit - http://www.brixoft.net/prodinfo.asp?id=1 
Security compass web application auditing tools (SWAAT) - http://www.owasp.org/index.php/Category:OWASP_SWAAT_Project 
An even more complete list here - http://www.cs.cmu.edu/~aldrich/courses/654/tools/ 
A nice list that claims some demos available - http://www.cs.cmu.edu/~aldrich/courses/413/tools.html 
A smaller, but also good list - http://spinroot.com/static/ 
Yasca: A highly extensible source code analysis framework; incorporates several analysis tools into one package. http://www.yasca.org/ 

==Static analysis for C/C++ (CGI, ISAPI, etc) in web applications==
RATS - http://www.securesoftware.com/resources/download_rats.html 
ITS4 - http://www.cigital.com/its4/ 
FlawFinder - http://www.dwheeler.com/flawfinder/ 
Splint - http://www.splint.org/ 
Uno - http://spinroot.com/uno/ 
BOON (Buffer Overrun detectiON) - http://www.cs.berkeley.edu/~daw/boon/ http://boon.sourceforge.net 
Valgrind - http://www.valgrind.org/ 

==Java static analysis, security frameworks, and web application security tools==
LAPSE - http://suif.stanford.edu/~livshits/work/lapse/ 
HDIV Struts - http://hdiv.org/ 
Orizon - http://sourceforge.net/projects/orizon/ 
FindBugs: Find bugs in Java programs - http://findbugs.sourceforge.net/ 
PMD - http://pmd.sourceforge.net/ 
CUTE: A Concolic Unit Testing Engine for C and Java - http://osl.cs.uiuc.edu/~ksen/cute/ 
EMMA - http://emma.sourceforge.net/ 
JLint - http://jlint.sourceforge.net/ 
Java PathFinder - http://javapathfinder.sourceforge.net/ 
Fujaba: Move between UML and Java source code - http://wwwcs.uni-paderborn.de/cs/fujaba/ 
Checkstyle - http://checkstyle.sourceforge.net/ 
Cookie Revolver Security Framework - http://sourceforge.net/projects/cookie-revolver 
tinapoc - http://sourceforge.net/projects/tinapoc 
jarsigner - http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jarsigner.html 
Solex - http://solex.sourceforge.net/ 
Java Explorer - http://metal.hurlant.com/jexplore/ 
HTTPClient - http://www.innovation.ch/java/HTTPClient/ 
another HttpClient - http://jakarta.apache.org/commons/httpclient/ 
a list of code coverage and analysis tools for Java - http://mythinkpond.blogspot.com/2007/06/java-foss-freeopen-source-software.html 

==Microsoft .NET static analysis and security framework tools, mostly for ASP.NET and ASP.NET AJAX, but also C# and VB.NET==
* Visual Studio 2008 Code Analysis, available in:
** VSTS 2008 Development Edition (http://msdn.microsoft.com/vsts2008/products/bb933752.aspx) and
** VSTS 2008 Team Suite (http://msdn.microsoft.com/vsts2008/products/bb933735.aspx)
* Visual Studio 2005 Code Analyzer, available in:
** Visual Studio 2005 Team Edition for Software Developers (http://msdn.microsoft.com/en-us/vstudio/aa718806.aspx)
** Visual Studio 2005 Team Suite (http://msdn.microsoft.com/en-us/vstudio/aa718806.aspx)
* Web Development Helper - http://www.nikhilk.net/Project.WebDevHelper.aspx
* FxCop:
** (blog) http://blogs.msdn.com/fxcop/
** (download) http://code.msdn.microsoft.com/codeanalysis
* Microsoft internal tools you can't have yet:
** http://www.microsoft.com/windows/cse/pa_projects.mspx
** http://research.microsoft.com/Pex/
** http://www.owasp.org/images/5/5b/OWASP_IL_7_FuzzGuru.pdf 

==Threat modeling==
Microsoft Threat Analysis and Modeling Tool v2.1 (TAM) - http://www.microsoft.com/downloads/details.aspx?FamilyID=59888078-9daf-4e96-b7d1-944703479451&displaylang=en 
Amenaza: Attack Tree Modeling (SecurITree) - http://www.amenaza.com/software.php 
Octotrike - http://www.octotrike.org/ 

==Add-ons for Firefox that help with general web application security==
Web Developer Toolbar - https://addons.mozilla.org/firefox/60/ 
Plain Old Webserver (POW) - https://addons.mozilla.org/firefox/3002/ 
XML Developer Toolbar - https://addons.mozilla.org/firefox/2897/ 
Public Fox - https://addons.mozilla.org/firefox/3911/ 
XForms Buddy - http://beaufour.dk/index.php?sec=misc&pagename=xforms 
MR Tech Local Install - http://www.mrtech.com/extensions/local_install/ 
Nightly Tester Tools - http://users.blueprintit.co.uk/~dave/web/firefox/buildid/index.html 
IE Tab - https://addons.mozilla.org/firefox/1419/ 
User-Agent Switcher - https://addons.mozilla.org/firefox/59/ 
ServerSwitcher - https://addons.mozilla.org/firefox/2409/ 
HeaderMonitor - https://addons.mozilla.org/firefox/575/ 
RefControl - https://addons.mozilla.org/firefox/953/ 
refspoof - https://addons.mozilla.org/firefox/667/ 
No-Referrer - https://addons.mozilla.org/firefox/1999/ 
LocationBar^2 - https://addons.mozilla.org/firefox/4014/ 
SpiderZilla - http://spiderzilla.mozdev.org/ 
Slogger - https://addons.mozilla.org/en-US/firefox/addon/143 
Fire Encrypter - https://addons.mozilla.org/firefox/3208/ 

==Add-ons for Firefox that help with Javascript and Ajax web application security==
Selenium IDE - http://www.openqa.org/selenium-ide/ 
Firebug - http://www.joehewitt.com/software/firebug/ 
Venkman - http://www.mozilla.org/projects/venkman/ 
Chickenfoot - http://groups.csail.mit.edu/uid/chickenfoot/ 
Greasemonkey - http://www.greasespot.net/ 
Greasemonkey compiler - http://www.letitblog.com/greasemonkey-compiler/ 
User script compiler - http://arantius.com/misc/greasemonkey/script-compiler 
Extension Developer's Extension (Firefox Add-on) - http://ted.mielczarek.org/code/mozilla/extensiondev/ 
Smart Middle Click (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/3885/ 

==Bookmarklets that aid in web application security==
RSnake's security bookmarklets - http://ha.ckers.org/bookmarklets.html 
BMlets - http://optools.awardspace.com/bmlet.html 
Huge list of bookmarklets - http://www.squarefree.com/bookmarklets/ 
Blummy: consists of small widgets, called blummlets, which make use of Javascript to provide
rich functionality - http://www.blummy.com/ 
Bookmarklets every blogger should have - http://www.micropersuasion.com/2005/10/bookmarklets_ev.html 
Flat Bookmark Editing (Firefox Add-on) - http://n01se.net/chouser/proj/mozhack/ 
OpenBook and Update Bookmark (Firefox Add-ons) - http://www.chuonthis.com/extensions/ 

==SSL certificate checking / scanning==
[ZIP] THCSSLCheck - http://thc.org/root/tools/THCSSLCheck.zip 
[ZIP] Foundstone SSLDigger - http://www.foundstone.com/us/resources/termsofuse.asp?file=ssldigger.zip 
Cert Viewer Plus (Firefox Add-on) - https://addons.mozilla.org/firefox/1964/ 

==Honeyclients, Web Application, and Web Proxy honeypots==
Honeyclient Project: an open-source honeyclient - http://www.honeyclient.org/trac/ 
HoneyC: the low-interaction honeyclient - http://honeyc.sourceforge.net/ 
Capture: a high-interaction honeyclient - http://capture-hpc.sourceforge.net/ 
Google Hack Honeypot - http://ghh.sourceforge.net/ 
PHP.Hop - PHP Honeynet Project - http://www.rstack.org/phphop/ 
SpyBye - http://www.monkey.org/~provos/spybye/ 
Honeytokens - http://www.securityfocus.com/infocus/1713 

==Blackhat SEO and maybe some whitehat SEO==
SearchStatus (Firefox Add-on) - http://www.quirk.biz/searchstatus/ 
SEO for Firefox (Firefox Add-on) - http://tools.seobook.com/firefox/seo-for-firefox.html 
SEOQuake (Firefox Add-on) - http://www.seoquake.com/ 

==Footprinting for web application security==
Evolution - http://www.paterva.com/evolution-e.html 
GooSweep - http://www.mcgrewsecurity.com/projects/goosweep/ 
Aura: Google API Utility Tools - http://www.sensepost.com/research/aura/ 
Edge-Security tools - http://www.edge-security.com/soft.php 
Fierce Domain Scanner - http://ha.ckers.org/fierce/ 
Googlegath - http://www.nothink.org/perl/googlegath/ 
Advanced Dork (Firefox Add-on) - https://addons.mozilla.org/firefox/2144/ 
Passive Cache (Firefox Add-on) - https://addons.mozilla.org/firefox/977/ 
CacheOut! (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1453/ 
BugMeNot Extension (Firefox Add-on) - http://roachfiend.com/archives/2005/02/07/bugmenot/ 
TrashMail.net Extension (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1813/ 
DiggiDig (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/2819/ 
Digger (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1467/ 

==Database security assessment==
Scuba by Imperva Database Vulnerability Scanner - http://www.imperva.com/scuba/ 

==Browser Defenses==
DieHard - http://www.diehard-software.org/ 
LocalRodeo (Firefox Add-on) - http://databasement.net/labs/localrodeo/ 
NoMoXSS - http://www.seclab.tuwien.ac.at/projects/jstaint/ 
Request Rodeo - http://savannah.nongnu.org/projects/requestrodeo 
FlashBlock (Firefox Add-on) - http://flashblock.mozdev.org/ 
CookieSafe (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/2497 
NoScript (Firefox Add-on) - http://www.noscript.net/ 
FormFox (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1579/ 
Adblock (Firefox Add-on) - http://adblock.mozdev.org/ 
httpOnly in Firefox (Firefox Add-on) - http://blog.php-security.org/archives/40-httpOnly-Cookies-in-Firefox-2.0.html 
SafeCache (Firefox Add-on) - http://www.safecache.com/ 
SafeHistory (Firefox Add-on) - http://www.safehistory.com/ 
PrefBar (Firefox Add-on) - http://prefbar.mozdev.org/ 
All-in-One Sidebar (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1027/ 
QArchive.org web file checker (Firefox Add-on) - https://addons.mozilla.org/firefox/4115/ 
Update Notified (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/2098/ 
FireKeeper - http://firekeeper.mozdev.org/ 
Greasemonkey: XSS Malware Script Detector - http://yehg.net/lab/#tools.greasemonkey

==Browser Privacy==
TrackMeNot (Firefox Add-on) - https://addons.mozilla.org/firefox/3173/ 
Privacy Bird - http://www.privacybird.com/ 

==Application and protocol fuzzing (random instead of targeted)==
Sulley - http://fuzzing.org/ 
taof: The Art of Fuzzing - http://sourceforge.net/projects/taof/ 
zzuf: multipurpose fuzzer - http://sam.zoy.org/zzuf/ 
autodafé: an act of software torture - http://autodafe.sourceforge.net/ 
EFS and GPF: Evolutionary Fuzzing System - http://www.appliedsec.com/resources.html

Category:OWASP Yasca Project Roadmap

2009-05-19T02:14:05Z

Scovetta:

=== The Goal of Yasca ===
The primary goal of Yasca is to assist '''developers''' in performing a '''security-oriented code review'''. This is accomplished through the following main features:
* an extensible architecture that other products can be integrated into,
* a single view of all results, with details down to the line of code (where possible), and
* a growing set of "open source" rules that anyone can add to.

A secondary goal is to support both the open source and enterprise development communities by delivering a high-quality product that can be relied upon and extended to meet evolving needs.

=== The Roadmap ===

==== Version 1.0 ====

The initial public release of Yasca was made available in October 2008. It offered integration with PMD, FindBugs, J-Lint, and antiC, as well as a limited set of custom rules and report generators.

==== Version 1.1 ====

This version was released on December 19, 2008, with the following changes:
* Update of all integrated components
** PMD to version 4.2.4
** FindBugs to version 1.3.6 (with FB-Contrib as well)
** PHP to version 5.2.8
* Addition of new custom rules
* Minor bug fixes

==== Version 1.2 ====

Version 1.2 was released on January 16, 2009, with the following enhancements:
* Ability to flag findings to be ignored in subsequent scans
* New plugins for PHP and C/C++
* Inclusion of Pixy, a scanner for PHP 4 source code
* Minor bug fixes

==== Version 2.0 ====

Version 2.0 released on 2009-05-07
Redesign separating Yasca-Core from plugin packages.
Added ClamAV plugin
Added RATS plugin
Added new minor plugins and many new rulesets.

Version 2.01 released on 2009-05-18
Fixed a few bugs related to calling external plugins.
Added a few minor plugins, including one that finds banned functions (via Microsoft SDL)

==== Version 3.0 ====
While no decisions have been finalized, some ideas for consideration include:
* Better error handling
** Automatic disabling of certain plugins based on the type of project (i.e. don't use PMD to scan C only projects)
* Integration of OunceOpen tools
* Integration of other OWASP projects ([[:Category:OWASP_Open_Review_Project|Open Review]], [[:Category:OWASP_Code_Review_Project|Code Review]], and [[:Category:OWASP_Orizon_Project|Orizon]])

[[Category:OWASP Yasca Project]]

Project Information:template Yasca Project

2009-05-19T02:12:16Z

Scovetta: Fixed up some links.

{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''PROJECT IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|'''OWASP Yasca Project'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|
* Yasca is an open source program which looks for security vulnerabilities, code-quality, performance, and conformance to best practices in program source code. It leverages external open source programs, such as [http://findbugs.sourceforge.net/ FindBugs], [http://pmd.sourceforge.net PMD], [http://artho.com/jlint JLint], [http://javascriptlint.com/ JavaScript Lint], [http://www.icosaedro.it/phplint/ PHPLint], [http://en.wikipedia.org/wiki/Cppcheck Cppcheck], [http://en.wikipedia.org/wiki/ClamAV ClamAV], [http://en.wikipedia.org/wiki/RATS RATS], and [http://pixybox.seclab.tuwien.ac.at/ Pixy] to scan specific file types, and also contains many custom scanners developed just for Yasca. It is a command-line tool that generates reports in HTML, CSV, XML, SQLite, and other formats. Yasca is easily extensible via a plugin-based architecture, so scanning any particular file is as simple as coming up with the rules or integrating external tools. 
* Yasca also features a simple regular-expression plugin that allows new rules to be written in less than a minute.

|-
| style="width:15%; background:#7B8ABD" align="center"|'''Key Project Information'''
| style="width:12%; background:#cccccc" align="center"|Licensed under [http://en.wikipedia.org/wiki/BSD_license BSD License] [http://en.wikipedia/org/wiki/GPL_license GPL License]
| style="width:12%; background:#cccccc" align="center"|Project Leader [mailto:michael.scovetta(at)gmail.com '''Michael V. Scovetta''']
| style="width:12%; background:#cccccc" align="center"|Project Contributors [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Mailing List [https://lists.owasp.org/mailman/listinfo/owasp-yasca-project '''To Subscribe'''] [mailto:owasp-yasca-project(at)lists.owasp.org '''To Use''']
| style="width:12%; background:#cccccc" align="center"|First Reviewer [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Second Reviewer [mailto:name(at)name '''Name'''] 
| style="width:12%; background:#cccccc" align="center"|OWASP Board Member (if applicable) [mailto:name(at)name '''Name&Email''']
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''PROJECT MAIN LINKS'''
|-
| style="width:100%; background:#cccccc" align="center"|
Yasca is hosted on [http://sourceforge.net/projects/yasca SourceForge] and has a main project website at [http://www.yasca.org/ yasca.org].

|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''RELATED PROJECTS'''
|-
| style="width:100%; background:#cccccc" align="center"|
* [[:Category:OWASP Orizon Project|OWASP Orizon Project]] 
* [[:Category:OWASP Code Review_Project|OWASP Code Review_Project]]
* [[:Category:OWASP Open Review Project|OWASP Open Review Project]]
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''SPONSORS & GUIDELINES'''
|-
| style="width:50%; background:#cccccc" align="center"|Sponsor name, if applicable
| style="width:50%; background:#cccccc" align="center"|[[:Category:OWASP Yasca Project Roadmap|'''Guidelines/Roadmap''']]
|}
{| style="width:100%" border="0" align="center"
! colspan="5" align="center" style="background:#4058A0; color:white"|ASSESSMENT AND REVIEW PROCESS
|-
| style="width:15%; background:#6C82B5" align="center"|'''Review/Reviewer'''
| style="width:21%; background:#b3b3b3" align="center"|'''Author's Self Evaluation''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''First Reviewer''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''Second Reviewer''' (applicable for Beta Quality & further)
| style="width:22%; background:#b3b3b3" align="center"|'''OWASP Board Member''' (applicable just for Release Quality)
|-
| style="width:15%; background:#7B8ABD" align="center"|'''First Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- Which status has been reached? '''Beta Status''' --------- [[Project Information:template Yasca Project - First Review - Self Evaluation - A|See&Edit: First Review/SelfEvaluation (A)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Not yet''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - First Reviewer - B|See&Edit: First Review/1st Reviewer (B)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - Second Reviewer - C|See&Edit: First Review/2nd Reviewer (C)]]
| style="width:22%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - OWASP Board Member - D|See/Edit: First Review/Board Member (D)]]
|-
|}

Category:OWASP Yasca Documentation

2009-02-25T14:39:11Z

Scovetta:

__FORCETOC__
=== User Documentation ===

All user documentation for Yasca is provided in the 'doc' directory of the Yasca distribution. It is also available at the Yasca [http://www.yasca.org/h/documentation/ Documentation] page.

=== Presentations ===

*[[Media:NYPHP-Yasca.pdf|Introducing Yasca]] (given at [http://www.nyphp.org/ NYPHP])

[[Category:OWASP Yasca Project]]

Category:OWASP Yasca Documentation

2009-02-25T14:38:32Z

Scovetta: Added new presentation.

__FORCETOC__
=== User Documentation ===

All user documentation for Yasca is provided in the 'doc' directory of the Yasca distribution. It is also available at the Yasca [http://www.yasca.org/h/documentation/ Documentation] page.

=== Presentations ===

*[[Media:NYPHP-Yasca.pdf‎|Introducing Yasca]] (given at [http://www.nyphp.org/|NYPHP])

[[Category:OWASP Yasca Project]]

File:NYPHP-Yasca.pdf

2009-02-25T14:37:11Z

Scovetta: Presentation given at NYPHP on 24 Feb 2009 titled "Introducing Yasca"

Presentation given at NYPHP on 24 Feb 2009 titled "Introducing Yasca"

Category:OWASP Yasca Project Roadmap

2009-01-17T13:17:08Z

Scovetta: Updated release v1.2 change log

=== The Goal of Yasca ===
The primary goal of Yasca is to assist '''developers''' in performing a '''security-oriented code review'''. This is accomplished through the following main features:
* an extensible architecture that other products can be integrated into,
* a single view of all results, with details down to the line of code (where possible), and
* a growing set of "open source" rules that anyone can add to.

A secondary goal is to support both the open source and enterprise development communities by delivering a high-quality product that can be relied upon and extended to meet evolving needs.

=== The Roadmap ===

==== Version 1.0 ====

The initial public release of Yasca was made available in October 2008. It offered integration with PMD, FindBugs, J-Lint, and antiC, as well as a limited set of custom rules and report generators.

==== Version 1.1 ====

This version was released on December 19, 2008, with the following changes:
* Update of all integrated components
** PMD to version 4.2.4
** FindBugs to version 1.3.6 (with FB-Contrib as well)
** PHP to version 5.2.8
* Addition of new custom rules
* Minor bug fixes

==== Version 1.2 ====

Version 1.2 was released on January 16, 2009, with the following enhancements:
* Ability to flag findings to be ignored in subsequent scans
* New plugins for PHP and C/C++
* Inclusion of Pixy, a scanner for PHP 4 source code
* Minor bug fixes

==== Version 2.0 ====

While no decisions have been finalized, some ideas for consideration include:
* Better error handling
** Automatic disabling of certain plugins based on the type of project (i.e. don't use PMD to scan C only projects)
* Integration of OunceOpen tools
* Integration of other OWASP projects ([[:Category:OWASP_Open_Review_Project|Open Review]], [[:Category:OWASP_Code_Review_Project|Code Review]], and [[:Category:OWASP_Orizon_Project|Orizon]])

[[Category:OWASP Yasca Project]]

Category:OWASP Yasca Documentation

2009-01-04T04:59:17Z

Scovetta:

__FORCETOC__
=== User Documentation ===

All user documentation for Yasca is provided in the 'doc' directory of Yasca. It is also available at the Yasca [http://www.yasca.org/h/documentation/ Documentation] page.

=== Presentations ===

*[[Media:OWASP-_Yasca.ppt|Introducing Yasca]]

[[Category:OWASP Yasca Project]]

Category:OWASP Yasca Documentation

2009-01-04T04:35:49Z

Scovetta: Initial Edit

File:OWASP- Yasca.ppt

2009-01-04T04:30:07Z

Scovetta: Draft presentation of Yasca for the NY/NJ OWASP January 2009 Chapter Meeting.

Draft presentation of Yasca for the NY/NJ OWASP January 2009 Chapter Meeting.

Category:OWASP Yasca Project Roadmap

2009-01-04T04:27:58Z

Scovetta: Added v1.2 information

=== The Goal of Yasca ===
The primary goal of Yasca is to assist '''developers''' in performing a '''security-oriented code review'''. This is accomplished through the following main features:
* an extensible architecture that other products can be integrated into,
* a single view of all results, with details down to the line of code (where possible), and
* a growing set of "open source" rules that anyone can add to.

A secondary goal is to support both the open source and enterprise development communities by delivering a high-quality product that can be relied upon and extended to meet evolving needs.

=== The Roadmap ===

==== Version 1.0 ====

The initial public release of Yasca was made available in October 2008. It offered integration with PMD, FindBugs, J-Lint, and antiC, as well as a limited set of custom rules and report generators.

==== Version 1.1 ====

This version was released on December 19, 2008, with the following changes:
* Update of all integrated components
** PMD to version 4.2.4
** FindBugs to version 1.3.6 (with FB-Contrib as well)
** PHP to version 5.2.8
* Addition of new custom rules
* Minor bug fixes

==== Version 1.2 ====

Version 1.2 is expected to be released on January 27, 2009, with the following enhancements:
* Ability to flag findings to be ignored in subsequent scans
* New plugins for PHP and C/C++
* Minor bug fixes

==== Version 2.0 ====

While no decisions have been finalized, some ideas for consideration include:
* Better error handling
** Automatic disabling of certain plugins based on the type of project (i.e. don't use PMD to scan C only projects)
* Integration of OunceOpen tools
* Integration of other OWASP projects ([[:Category:OWASP_Open_Review_Project|Open Review]], [[:Category:OWASP_Code_Review_Project|Code Review]], and [[:Category:OWASP_Orizon_Project|Orizon]])

[[Category:OWASP Yasca Project]]

Category:OWASP Yasca Project Roadmap

2008-12-19T20:40:13Z

Scovetta: Updated for version 1.1

=== The Goal of Yasca ===
The primary goal of Yasca is to assist '''developers''' in performing a '''security-oriented code review'''. This is accomplished through the following main features:
* an extensible architecture that other products can be integrated into,
* a single view of all results, with details down to the line of code (where possible), and
* a growing set of "open source" rules that anyone can add to.

A secondary goal is to support both the open source and enterprise development communities by delivering a high-quality product that can be relied upon and extended to meet evolving needs.

=== The Roadmap ===

==== Version 1.0 ====

The initial public release of Yasca was made available in October 2008. It offered integration with PMD, FindBugs, J-Lint, and antiC, as well as a limited set of custom rules and report generators.

==== Version 1.1 ====

This version was released on December 19, 2008, with the following changes:
* Update of all integrated components
** PMD to version 4.2.4
** FindBugs to version 1.3.6 (with FB-Contrib as well)
** PHP to version 5.2.8
* Addition of new custom rules
* Minor bug fixes

==== Version 2.0 ====

While no decisions have been finalized, some ideas for consideration include:
* Better error handling
** Automatic disabling of certain plugins based on the type of project (i.e. don't use PMD to scan C only projects)
* Integration of OunceOpen tools
* Integration of other OWASP projects ([[:Category:OWASP_Open_Review_Project|Open Review]], [[:Category:OWASP_Code_Review_Project|Code Review]], and [[:Category:OWASP_Orizon_Project|Orizon]])

[[Category:OWASP Yasca Project]]

Project Information:template Yasca Project

2008-12-19T20:32:21Z

Scovetta: Added BSD License

{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''PROJECT IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|'''OWASP Yasca Project'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|
* Yasca is a new static analysis tool designed to scan Java, C/C++, JavaScript, .NET, and other source code for security and code-quality issues. Yasca is easily extensible via a plugin-based architecture, so scanning PHP, Ruby, or other languages is as simple as coming up with rules or integrating external tools. 
* Yasca includes plugins for the following open-source projects:
** FindBugs (http://findbugs.sourceforge.net/)
** PMD (http://pmd.sourceforge.net/)
** Jlint / antiC (http://artho.com/jlint/)
* Yasca also features a simple regular-expression plugin that allows new rules to be written in less than a minute. It includes many custom rules created specifically for Yasca, and additional rule-packs will be released soon.
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Key Project Information'''
| style="width:12%; background:#cccccc" align="center"|Licensed under [http://en.wikipedia.org/wiki/BSD_license BSD License]
| style="width:12%; background:#cccccc" align="center"|Project Leader [mailto:michael.scovetta(at)gmail.com '''Michael V. Scovetta''']
| style="width:12%; background:#cccccc" align="center"|Project Contributors [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Mailing List [https://lists.owasp.org/mailman/listinfo/owasp-yasca-project '''To Subscribe'''] [mailto:owasp-yasca-project(at)lists.owasp.org '''To Use''']
| style="width:12%; background:#cccccc" align="center"|First Reviewer [mailto:name(at)name '''Name''']
| style="width:12%; background:#cccccc" align="center"|Second Reviewer [mailto:name(at)name '''Name'''] 
| style="width:12%; background:#cccccc" align="center"|OWASP Board Member (if applicable) [mailto:name(at)name '''Name&Email''']
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''PROJECT MAIN LINKS'''
|-
| style="width:100%; background:#cccccc" align="center"|
Yasca is hosted on SourceForge (http://sourceforge.net/projects/yasca) with additional information at http://yasca.org.

|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''RELATED PROJECTS'''
|-
| style="width:100%; background:#cccccc" align="center"|
* [[:Category:OWASP Orizon Project|OWASP Orizon Project]] 
* [[:Category:OWASP Code Review_Project|OWASP Code Review_Project]]
* [[:Category:OWASP Open Review Project|OWASP Open Review Project]]
|}
{| style="width:100%" border="0" align="center"
! colspan="6" align="center" style="background:#4058A0; color:white"|'''SPONSORS & GUIDELINES'''
|-
| style="width:50%; background:#cccccc" align="center"|Sponsor name, if applicable
| style="width:50%; background:#cccccc" align="center"|[[:Category:OWASP Yasca Project Roadmap|'''Guidelines/Roadmap''']]
|}
{| style="width:100%" border="0" align="center"
! colspan="5" align="center" style="background:#4058A0; color:white"|ASSESSMENT AND REVIEW PROCESS
|-
| style="width:15%; background:#6C82B5" align="center"|'''Review/Reviewer'''
| style="width:21%; background:#b3b3b3" align="center"|'''Author's Self Evaluation''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''First Reviewer''' (applicable for Alpha Quality & further)
| style="width:21%; background:#b3b3b3" align="center"|'''Second Reviewer''' (applicable for Beta Quality & further)
| style="width:22%; background:#b3b3b3" align="center"|'''OWASP Board Member''' (applicable just for Release Quality)
|-
| style="width:15%; background:#7B8ABD" align="center"|'''First Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Not yet''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - Self Evaluation - A|See&Edit: First Review/SelfEvaluation (A)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Not yet''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - First Reviewer - B|See&Edit: First Review/1st Reviewer (B)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - Second Reviewer - C|See&Edit: First Review/2nd Reviewer (C)]]
| style="width:22%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Alpha Status''' - (To update) --------- [[Project Information:template Yasca Project - First Review - OWASP Board Member - D|See/Edit: First Review/Board Member (D)]]
|-
|}

[[Category:OWASP Project]]

Category:OWASP Yasca Project Roadmap

2008-12-13T15:28:56Z

Scovetta: Added category

=== The Goal of Yasca ===
The primary goal of Yasca is to assist '''developers''' in performing a '''security-oriented code review'''. This is accomplished through the following main features:
* an extensible architecture that other products can be integrated into,
* a single view of all results, with details down to the line of code (where possible), and
* a growing set of "open source" rules that anyone can add to.

A secondary goal is to support both the open source and enterprise development communities by delivering a high-quality product that can be relied upon and extended to meet evolving needs.

=== The Roadmap ===

==== Version 1.0 ====

The initial public release of Yasca was made available in October 2008. It offered integration with PMD, FindBugs, J-Lint, and antiC, as well as a limited set of custom rules and report generators.

==== Version 1.1 ====

This version is expected to be released in January 2009, and to offer the following changes:
* Update of all integrated components
** PMD to version 4.2.4
** FindBugs to version 1.3.6
** PHP to version 5.2.8
* Addition of new custom rules
* Better error handling
** Automatic disabling of certain plugins based on the type of project (i.e. don't use PMD to scan C only projects)

==== Version 2.0 ====

While no decisions have been finalized, some ideas for consideration include:
* Integration of OunceOpen tools
* Integration of other OWASP projects ([[:Category:OWASP_Open_Review_Project|Open Review]], [[:Category:OWASP_Code_Review_Project|Code Review]], and [[:Category:OWASP_Orizon_Project|Orizon]])

[[Category:OWASP Yasca Project]]

Category:OWASP Yasca Project Roadmap

2008-12-13T15:22:27Z

Scovetta: Initial Submission

Funds available for OWASP Projects

2007-07-16T13:49:14Z

Scovetta: corrected spelling of SPI Dynamics

This page contains details about funds available to OWASP projects.

The sponsorship model is different from the one used in [[OWASP Autumn Of Code 2006|AoC 06]] and [[OWASP Spring Of Code 2007|SpoC 007]] since these are cases where specific money (throughout out the year) has been allocated to OWASP projects (for example by new OWASP members or by companies/organizations with specific requirements/projects)

== July 2007 Batch - Overview ==

Now with the SpoC 007 (Spring of Code 2007) under way, OWASP is requesting proposals for OWASP projects with sponsorship funds available (28,000 USD in total).

The projects with funding available are (with details included below):

* '''OSG - OWASP Site Generator''' - Join Boris in his development of the new version of .NET's OSG (funds from SPI Dynamics and Cenzic membership fees)
* '''OWASP Corporate Application Security Rating Guide''' - Create and release the first version of this very important document ( funds from Cenzic membership fees)
* '''Questions for SANS''' - Write 200 questions for SANS with a % of those questions made open to the OWASP community (funds directly allocated by SANS for this project)
* '''Source Code Review OWASP Projects''' - Implement a workflow where all OWASP projects that use JAVA technology are automatically audited for security flaws (funds directly allocated by Fortify Software for this project)
* '''BlackTop project''' - Develop a runtime code analysis tool to be used by Penetration Testers during client engagements (funds directly allocated by Ounce Labs for this project).

If you are interested, email your proposal to Dinis.cruz at owasp.net including responses to the following items:

* Your educational and professional background
* Application security experience and accomplishments
* Participation and leadership in open communities
* The opportunity, challenges, issues or need your proposal addresses
* Milestones and objectives
* Specific activities and who will carry out these activities
* Specific deliverables and a rough project schedule so we can track progress
* Long-term vision for the project
* Any other reasons why you and your project should be selected

The proposed project delivery time is 3 months and the payment will be made in two 50% parts (one at the 50% mark and one at 100% mark (i.e. project completed))

OWASP will also put the applicants in touch with the contacts at the sponsoring companies so that the brief and project deliverables can be finalized.

== July 2007 Batch - Project details ==

====OSG - OWASP Site Generator (5k)====

* '''Project description''': Continue development of Site Generator, write new vulnerabilities, work on new dynamic engine, document findings
* '''Funds available''': 5,000 USD
* '''Sponsor:''' SPI Dynamics, Cenzic

====OWASP Corporate Application Security Rating Guide (3k)====

* '''Project description''': As per https://www.owasp.org/index.php/OWASP_Corporate_Application_Security_Rating_Guide, finalize criteria, research selected companies and publish a report with the results
* '''Funds available''': 3,000 USD
* '''Sponsor''': Cenzic

====Questions for SANS (5k)====

* '''Project description''': Write JAVA/JSP questions for SANS's Software Security Institute certification exams( http://www.sans-ssi.org/). The candidate will need to write 200 questions and answers and must be a knowledgeable and respected member of the Java community. For obvious reasons only 10% to 20% of the questions created will be disclosed to the OWASP community, with the remainder to be used in the certification's exams..
** Note that although this first request is for questions in JAVA/JSP there are plans to run a similar project for C, C++, PHP, .NET, so if you are interested in these other languages feel free to contact us..
* '''Funds available''': 5,000 USD
* '''Sponsor''': SANS

====Source Code Review OWASP Projects (5k)====

* '''Project description''': Use Fortify Software's source code scanning engine ( http://opensource.fortifysoftware.com) to scan open source projects coded in JAVA. The objectives of this project will be:
** Develop and document a workflow for open source projects to incorporate static analysis into the Software Development Life Cycle (SDLC).
** Apply the above workflow as a required step for OWASP projects.
** Aid in auditing select open source projects to create a baseline for comparing security amongst open source projects.
* '''Funds available''': 5,000 USD
* '''Sponsor''': Fortify Software

====BlackTop - Runtime coverage analysis tool (10k)====

* '''Project description''': Develop and document a "blackbox" pen testing code analysis solution capable of providing runtime coverage analysis for applications written in Java and .NET. In order to ensure the solution does not require access to the applications' source code, the solution should use (for example) the AspectJ and PostSharp bytecode weaving frameworks.
** The project must produce an open source, release quality application, including a GUI and documentation. The project should utilize a license; either the Eclipse Public License or the Mozilla Public license is allowable.
** The tool should provide code level details and call trace information of all ingress and egress points of the application and be able to identify gaps in the "blackbox" testing to facilitate more accurate and complete pen testing. All output and configuration should be done using an open format (such as XML) and enable command line execution of the application.
* '''Funds available''': 10,000 USD
* '''Sponsor''': Ounce Labs

Data Validation

2007-05-22T15:12:30Z

Scovetta: Reformatted code

[[Guide Table of Contents]]__TOC__

==Objective ==

To ensure that the application is robust against all forms of input data, whether obtained from the user, infrastructure, external entities or database systems

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS11 – Manage Data. All sections should be reviewed

==Description ==

The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as interpreter injection, locale/Unicode attacks, file system attacks and buffer overflows. Data from the client should never be trusted for the client has every possibility to tamper with the data.

In many cases, [[Encoding]] has the potential to defuse attacks that rely on lack of input validation. For example, if you use HTML entity encoding on user input before it is sent to a browser, it will prevent most [[XSS]] attacks. However, simply preventing attacks is not enough - you must perform [[Intrusion Detection]] in your applications. Otherwise, you are allowing attackers to repeatedly attack your application until they find a vulnerability that you haven't protected against. Detecting attempts to find these weaknesses is a critical protection mechanism.

==Definitions ==

These definitions are used within this document:

* '''Integrity checks'''

Ensure that the data has not been tampered with and is the same as before

* '''Validation'''

Ensure that the data is strongly typed, correct syntax, within length boundaries, contains only permitted characters, or that numbers are correctly signed and within range boundaries

* '''Business rules'''

Ensure that data is not only validated, but business rule correct. For example, interest rates fall within permitted boundaries.

Some documentation and references interchangeably use the various meanings, which is very confusing to all concerned. This confusion directly causes continuing financial loss to the organization.

==Where to include integrity checks ==

Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return.

The type of integrity control (checksum, HMAC, encryption, digital signature) should be directly related to the risk of the data transiting the trust boundary.

==Where to include validation ==

Validation must be performed on every tier. However, validation should be performed as per the function of the server executing the code. For example, the web / presentation tier should validate for web related issues, persistence layers should validate for persistence issues such as SQL / HQL injection, directory lookups should check for LDAP injection, and so on.

==Where to include business rule validation ==

Business rules are known during design, and they influence implementation. However, there are bad, good and "best" approaches. Often the best approach is the simplest in terms of code.

===Example - Scenario ===

* You are to populate a list with accounts provided by the back-end system
* The user will choose an account, choose a biller, and press next

===Wrong way===

The account select option is read directly and provided in a message back to the backend system without validating the account number is one of the accounts provided by the backend system.

===Why this is bad===

An attacker can change the HTML in any way they choose:

* The lack of validation requires a round-trip to the backend to provide an error message that the front end code could easily have eliminated

* The back end may not be able to cope with the data payload the front-end code could have easily eliminated. For example, buffer overflows, XML injection, or similar.

===Acceptable Method ===

The account select option parameter ("payee_id") is read by the code, and compared to an already-known list.

<code>
<pre>
if (account.hasPayee( session.getParameter("payee_id") )) {
backend.performTransfer( session.getParameter("payee_id") );
}
</pre>
</code>

This prevents parameter tampering, but requires the list of possible payee_id's to be to be calculated beforehand.

===Best Method ===

The original code emitted indexes <option value="1" ... > rather than account names.

''int payeeLstId = session.getParameter('payeelstid');''
''accountFrom = account.getAcctNumberByIndex(payeeLstId);''

Not only is this easier to render in HTML, it makes validation and business rule validation trivial. The field cannot be tampered with.

===Conclusion ===

To provide defense in depth and to prevent attack payloads from trust boundaries, such as backend hosts, which are probably incapable of handling arbitrary input data, business rule validation is to be performed (preferably in workflow or command patterns), even if it is known that the back end code performs business rule validation.

This is not to say that the entire set of business rules need be applied - it means that the fundamentals are performed to prevent unnecessary round trips to the backend and to prevent the backend from receiving most tampered data.

==Data Validation Strategies ==

There are four strategies for validating data, and they should be used in this order:

===Accept known good===

This strategy is also known as "whitelist" or "positive" validation. The idea is that you should check that the data is one of a set of tightly constrained known good values. Any data that doesn't match should be rejected. Data should be:

* Strongly typed at all times
* Length checked and fields length minimized
* Range checked if a numeric
* Unsigned unless required to be signed
* Syntax or grammar should be checked prior to first use or inspection

If you expect a postcode, validate for a postcode (type, length and syntax):

<code>
<pre>
public String isPostcode(String postcode) {
return (postcode != null && Pattern.matches("^(((2|8|9)\d{2})|((02|08|09)\d{2})|([1-9]\d{3}))$", postcode)) ? postcode : "";
}
</pre>
</code>

Coding guidelines should use some form of visible tainting on input from the client or untrusted sources, such as third party connectors to make it obvious that the input is unsafe:

<code>
<pre>
String taintPostcode = request.getParameter("postcode");
ValidationEngine validator = new ValidationEngine();
boolean isValidPostcode = validator.isPostcode(taintPostcode);
</pre>
</code>

===Reject known bad===

This strategy, also known as "negative" or "blacklist" validation is a weak alternative to positive validation. Essentially, if you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them. This is a dangerous strategy, because the set of possible bad data is potentially infinite. Adopting this strategy means that you will have to maintain the list of "known bad" characters and patterns forever, and you will by definition have incomplete protection.

''public String removeJavascript(String input) {''

'' Pattern p = Pattern.compile("javascript", CASE_INSENSITIVE);''

'' p.matcher(input);''

'' return (!p.matches()) ? input : '';''

''}''

It can take upwards of 90 regular expressions (see the CSS Cheat Sheet in the Guide 2.0) to eliminate known malicious software, and each regex needs to be run over every field. Obviously, this is slow and not secure. Just rejecting "current known bad" (which is at the time of writing hundreds of strings and literally millions of combinations) is insufficient if the input is a string. This strategy is directly akin to anti-virus pattern updates. Unless the business will allow updating "bad" regexes on a daily basis and support someone to research new attacks regularly, this approach will be obviated before long.

===Sanitize===

Eliminate or translate characters (such as to HTML entities or to remove quotes) in an effort to make the input "safe".
Like blacklists, this approach requires maintenance and is usually incomplete. As most fields have a particular grammar, it is simpler, faster, and more secure to simply validate a single correct positive test than to try to include complex and slow sanitization routines for all current and future attacks.

<code>
<pre>
public String quoteApostrophe(String input) {
if (input != null)
return input.replaceAll("[\']", "&rsquo;");
else
return null;
}
</pre>
</code>

===No validation===

This is inherently unsafe and strongly discouraged. The business must sign off each and every example of no validation as the lack of validation usually leads to direct obviation of application, host and network security controls.

''account.setAcctId(getParameter('formAcctNo'));''
''...''

''public setAcctId(String acctId) {''
'' cAcctId = acctId;''
''}''

==Prevent parameter tampering ==

There are many input sources:

* HTTP headers, such as REMOTE_ADDR, PROXY_VIA or similar

* Environment variables, such as getenv() or via server properties

* All GET, POST and Cookie data

This includes supposedly tamper resistant fields such as radio buttons, drop downs, etc - any client side HTML can be re-written to suit the attacker

Configuration data (mistakes happen :))

External systems (via any form of input mechanism, such as XML input, RMI, web services, etc)

All of these data sources supply untrusted input. Data received from untrusted data sources must be properly checked before first use.

==Hidden fields ==

Hidden fields are a simple way to avoid storing state on the server. Their use is particularly prevalent in "wizard-style" multi-page forms. However, their use exposes the inner workings of your application, and exposes data to trivial tampering, replay, and validation attacks. In general, only use hidden fields for page sequence.

If you have to use hidden fields, there are some rules:

* Secrets, such as passwords, should never be sent in the clear

* Hidden fields need to have integrity checks and preferably encrypted using non-constant initialization vectors (i.e. different users at different times have different yet cryptographically strong random IVs)

* Encrypted hidden fields must be robust against replay attacks, which means some form of temporal keying

* Data sent to the user must be validated on the server once the last page has been received, even if it has been previously validated on the server - this helps reduce the risk from replay attacks.

The preferred integrity control should be at least a HMAC using SHA-256 or preferably digitally signed or encrypted using PGP. IBMJCE supports SHA-256, but PGP JCE support require the inclusion of the Legion of the Bouncy Castle (http://www.bouncycastle.org/) JCE classes.

It is simpler to store this data temporarily in the session object. Using the session object is the safest option as data is never visible to the user, requires (far) less code, nearly no CPU, disk or I/O utilization, less memory (particularly on large multi-page forms), and less network consumption.

In the case of the session object being backed by a database, large session objects may become too large for the inbuilt handler. In this case, the recommended strategy is to store the validated data in the database, but mark the transaction as "incomplete". Each page will update the incomplete transaction until it is ready for submission. This minimizes the database load, session size, and activity between the users whilst remaining tamperproof.

Code containing hidden fields should be rejected during code reviews.

==ASP.NET Viewstate ==

ASP.NET sends form data back to the client in a hidden “Viewstate” field. Despite looking forbidding, this “encryption” is simply plain-text equivalent (base64 encoding) and has no data integrity without further action on your behalf in ASP.NET 1.0. In ASP.NET 1.1 and 2.0, tamper proofing, called "enableViewStateMAC" is on by default using a SHA/1 hash.

Any application framework with a similar mechanism might be at fault – you should investigate your application framework’s support for sending data back to the user. Preferably it should not round trip.

===How to determine if you are vulnerable ===

These configurations are set hierarchically in the .NET framework. The machine.config file contains the global configuration; each web directory may contain a web.config file further specifying or overriding configuration; each page may contain @page directives specifying same configuration or overrides; you must check all three locations:

* If the enableViewStateMac is not set to “true”, you are at risk if your viewstate contains authorization state

* If the viewStateEncryptionMode is not set to “always”, you are at risk if your viewstate contains secrets such as credentials

* If you share a host with many other customers, you all share the same machine key by default in ASP.NET 1.1. In ASP.NET 2.0, it is possible to configure unique viewstate keys per application

===How to protect yourself ===

* If your application relies on data returning from the viewstate without being tampered with, you should turn on viewstate integrity checks at the least, and strongly consider:

* Encrypt viewstate if any of the data is application sensitive

* Upgrade to ASP.NET 2.0 as soon as practical if you are on a shared hosting arrangement

* Move truly sensitive viewstate data to the session variable instead

===Selects, radio buttons, and checkboxes ===

It is commonly held belief that the value settings for these items cannot be easily tampered. This is wrong. In the following example, actual account numbers are used, which can lead to compromise:

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(1).toString( )%>" />''

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(2).toString( )%>" />''

This produces (for example):

''<input type="radio" name="acctNo" value="455712341234">Gold Card''

''<input type="radio" name="acctNo" value="455712341235">Platinum Card''

If the value is retrieved and then used directly in a SQL query, an interesting form of SQL injection may occur: authorization tampering leading to information disclosure. As the connection pool connects to the database using a single user, it may be possible to see other user's accounts if the SQL looks something like this:

''String acctNo = getParameter('acctNo');''

''String sql = "SELECT acctBal FROM accounts WHERE acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acctNo);''

''ResultSet rs = st.executeQuery();''

This should be re-written to retrieve the account number via index, and include the client's unique ID to ensure that other valid account numbers are exposed:

''String acctNo = acct.getCardNumber(getParameter('acctIndex'));''

''String sql = "SELECT acctBal FROM accounts WHERE acct_id = '?' AND acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acct.getID());''

''st.setString(2, acctNo);''

''ResultSet rs = st.executeQuery();''

This approach requires rendering input values from 1 to ... x, and assuming accounts are stored in a Collection which can be iterated using logic:iterate:

''<logic:iterate id="loopVar" name="MyForm" property="values">''

'' <html:radio property="acctIndex" idName="loopVar" value="value"/> ''

'' <bean:write name="loopVar" property="name"/> ''

''</logic:iterate>''

The code will emit HTML with the values "1" .. "x" as per the collection's content.

''<input type="radio" name="acctIndex" value="1" />Gold Credit Card''

''<input type="radio" name="acctIndex" value="2" />Platinum Credit Card''

This approach should be used for any input type that allows a value to be set: radio buttons, checkboxes, and particularly select / option lists.

===Per-User Data ===

In fully normalized databases, the aim is to minimize the amount of repeated data. However, some data is inferred. For example, users can see messages that are stored in a messages table. Some messages are private to the user. However, in a fully normalized database, the list of message IDs are kept within another table:

If a user marks a message for deletion, the usual way is to recover the message ID from the user, and delete that:

''DELETE FROM message WHERE msgid='frmMsgId'''

However, how do you know if the user is eligible to delete that message ID? Such tables need to be denormalized slightly to include a user ID or make it easy to perform a single query to delete the message safely. For example, by adding back an (optional) uid column, the delete is now made reasonably safe:

''DELETE FROM message WHERE uid='session.myUserID' and msgid='frmMsgId';''

Where the data is potentially both a private resource and a public resource (for example, in the secure message service, broadcast messages are just a special type of private message), additional precautions need to be taken to prevent users from deleting public resources without authorization. This can be done using role based checks, as well as using SQL statements to discriminate by message type:

''DELETE FROM message ''

''WHERE''

''uid='session.myUserID' AND''

''msgid='frmMsgId' AND''

''broadcastFlag = false;''

==URL encoding ==

Data sent via the URL, which is strongly discouraged, should be URL encoded and decoded. This reduces the likelihood of cross-site scripting attacks from working.

In general, do not send data via GET request unless for navigational purposes.

==HTML encoding ==

Data sent to the user needs to be safe for the user to view. This can be done using <bean:write ...> and friends. Do not use <%=var%> unless it is used to supply an argument for <bean:write...> or similar.

HTML encoding translates a range of characters into their HTML entities. For example, > becomes &gt; This will still display as > on the user's browser, but it is a safe alternative.

==Encoded strings ==

Some strings may be received in encoded form. It is essential to send the correct locale to the user so that the web server and application server can provide a single level of canoncalization prior to the first use.

Do not use getReader() or getInputStream() as these input methods do not decode encoded strings. If you need to use these constructs, you must decanoncalize data by hand.

==Data Validation and Interpreter Injection ==

This section focuses on preventing injection in ColdFusion. Interpreter Injection involves manipulating application parameters to execute malicious code on the system. The most prevalent of these is SQL injection but it also includes other injection techniques, including LDAP, ORM, User Agent, XML, etc. – see the Interpreter Injection chapter of this document for greater details. As a developer you should assume that all input is malicious. Before processing any input coming from a user, data source, component, or data service it should be validated for type, length, and/or range. ColdFusion includes support for Regular Expressions and CFML tags that can be used to validate input.

'''SQL Injection'''

SQL Injection involves sending extraneous SQL queries as variables. ColdFusion provides the <cfqueryparam> and <cfprocparam> tags for validating database parameters. These tags nests inside <cfquery> and <cfstoredproc>, respectively. For dynamic SQL submitted in <cfquery>, use the CFSQLTYPE attribute of the <cfqueryparam> to validate variables against the expected database datatype. Similarly, use the CFSQLTYPE attribute of <cfprocparam> to validate the datatypes of stored procedure parameters passed through <cfstoredproc>.

You can also strengthen your systems against SQL Injection by disabling the Allowed SQL operations for individual data sources. See the '''Configuration''' section below for more information.

'''LDAP Injection'''

ColdFusion uses the <cfldap> tag to communicate with LDAP servers. This tag has an ACTION attribute which dictates the query performed against the LDAP. The valid values for this attribute are: add, delete, query (default), modify, and modifyDN. <cfldap> calls are turned into JNDI (Java Naming And Directory Interface) lookups. However, because <cfldap> wraps the calls, it will throw syntax errors if native JNDI code is passed to its attributes making LDAP injection more difficult.

'''XML Injection'''

Two parsers exist for XML data – SAX and DOM. ColdFusion uses DOM which reads the entire XML document into the server’s memory. This requires the administrator to restrict the size of the JVM containing ColdFusion. ColdFusion is built on Java therefore by default, entity references are expanded during parsing. To prevent unbounded entity expansion, before a string is converted to an XML DOM, filter out DOCTYPES elements.

After the DOM has been read, to reduce the risk of XML, Injection use the ColdFusion XML decision functions: isXML(), isXmlAttribute(), isXmlElement(), isXmlNode(), and isXmlRoot(). The isXML() function determines if a string is well-formed XML. The other functions determine whether or not the passed parameter is a valid part of an XML document. Use the xmlValidate() function to validate external XML documents against a Document Type Definition (DTD) or XML Schema.

'''Event Gateway, IM, and SMS Injection'''

ColdFusion MX 7 enables Event Gateways, instant messaging (IM), and SMS (short message service) for interacting with external systems. Event Gateways are ColdFusion components that respond asynchronously to non-HTTP requests – e.g. instant messages, SMS text from wireless devices, etc. ColdFusion provides Lotus Sametime and XMPP (Extensible Messaging and Presence Protocol) gateways for instant messaging. It also provides an event gateway for interacting with SMS text messages.

Injection along these gateways can happen when end users (and/or systems) send malicious code to execute on the server. These gateways all utilize ColdFusion Components (CFCs) for processing. Use standard ColdFusion functions, tags, and validation techniques to protect against malicious code injection. Sanitize all input strings and do not allow un-validated code to access backend systems.

'''Best Practices'''

Use the XML functions to validate XML input.

Before performing XPath searches and transformations in ColdFusion, validate the source before executing.

Use ColdFusion validation techniques to sanitize strings passed to xmlSearch for performing XPath queries.

When performing XML transformations only use a trusted source for the XSL stylesheet.

Ensure that the memory size of the Java Sandbox containing ColdFusion can handle large XML documents without adversely affecting server resources.

Set the memory value to less than the amount of RAM on the server (-Xmx)

Remove DOCTYPE elements from the XML string before converting it to an XML object.

Using scriptProtect can be used to thwart most attempts of cross-site scripting. Set scriptProtect to All in the Application.cfc

Use <cfparam> or <cfargument> to instantiate variables in ColdFusion. Use this tag with the name and type attributes. If the value is not of the specified type, ColdFusion returns an error.

To handle untyped variables use IsValid() to validate its value against any legal object type that ColdFusion supports.

Use <cfqueryparam> and <cfprocparam> to valid dynamic SQL variables against database datatypes

Use CFLDAP for accessing LDAP servers. Avoid allowing native JNDI calls to connect to LDAP

'''Best Practice in Action'''

The sample code below shows a database authentication function using some of the input validation techniques discussed in this section.

{| border=1

||
* <cffunction name="dblogin" access="private" output="false" returntype="struct">

* <cfargument name="strUserName" required="true" type="string">

* <cfargument name="strPassword" required="true" type="string">

* <cfset var retargs = StructNew()>

* <cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

* <cfquery name="loginQuery" dataSource="#Application.DB#" >

* SELECT hashed_password, salt

* FROM UserTable

* WHERE UserName =

* <cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

* </cfquery>

* <cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

* <cfset retargs.authenticated="YES">

* <cfset Session.UserName = strUserName>

* 

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfreturn retargs>

* </cffunction>

|-

|}

==Delimiter and special characters ==

There are many characters that mean something special to various programs. If you followed the advice only to accept characters that are considered good, it is very likely that only a few delimiters will catch you out.

Here are the usual suspects:

* NULL (zero) %00

* LF - ANSI chr(10) "\r"

* CR - ANSI chr(13) "\n"

* CRLF - "\n\r"

* CR - EBCDIC 0x0f

* Quotes " '

* Commas, slashes spaces and tabs and other white space - used in CSV, tab delimited output, and other specialist formats

* <> - XML and HTML tag markers, redirection characters

* ; & - Unix and NT file system continuance

* @ - used for e-mail addresses

* 0xff

* ... more

Whenever you code to a particular technology, you should determine which characters are "special" and prevent them appearing in input, or properly escaping them.

==Further Reading ==

* ASP.NET 2.0 Viewstate

http://channel9.msdn.com/wiki/default.aspx/Channel9.HowToConfigureTheMachineKeyInASPNET2

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Validation]]
[[Category:Encoding]]

Data Validation

2007-05-22T15:09:24Z

Scovetta: Reformatted code

[[Guide Table of Contents]]__TOC__

==Objective ==

To ensure that the application is robust against all forms of input data, whether obtained from the user, infrastructure, external entities or database systems

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS11 – Manage Data. All sections should be reviewed

==Description ==

The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as interpreter injection, locale/Unicode attacks, file system attacks and buffer overflows. Data from the client should never be trusted for the client has every possibility to tamper with the data.

In many cases, [[Encoding]] has the potential to defuse attacks that rely on lack of input validation. For example, if you use HTML entity encoding on user input before it is sent to a browser, it will prevent most [[XSS]] attacks. However, simply preventing attacks is not enough - you must perform [[Intrusion Detection]] in your applications. Otherwise, you are allowing attackers to repeatedly attack your application until they find a vulnerability that you haven't protected against. Detecting attempts to find these weaknesses is a critical protection mechanism.

==Definitions ==

These definitions are used within this document:

* '''Integrity checks'''

Ensure that the data has not been tampered with and is the same as before

* '''Validation'''

Ensure that the data is strongly typed, correct syntax, within length boundaries, contains only permitted characters, or that numbers are correctly signed and within range boundaries

* '''Business rules'''

Ensure that data is not only validated, but business rule correct. For example, interest rates fall within permitted boundaries.

Some documentation and references interchangeably use the various meanings, which is very confusing to all concerned. This confusion directly causes continuing financial loss to the organization.

==Where to include integrity checks ==

Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return.

The type of integrity control (checksum, HMAC, encryption, digital signature) should be directly related to the risk of the data transiting the trust boundary.

==Where to include validation ==

Validation must be performed on every tier. However, validation should be performed as per the function of the server executing the code. For example, the web / presentation tier should validate for web related issues, persistence layers should validate for persistence issues such as SQL / HQL injection, directory lookups should check for LDAP injection, and so on.

==Where to include business rule validation ==

Business rules are known during design, and they influence implementation. However, there are bad, good and "best" approaches. Often the best approach is the simplest in terms of code.

===Example - Scenario ===

* You are to populate a list with accounts provided by the back-end system
* The user will choose an account, choose a biller, and press next

===Wrong way===

The account select option is read directly and provided in a message back to the backend system without validating the account number is one of the accounts provided by the backend system.

===Why this is bad===

An attacker can change the HTML in any way they choose:

* The lack of validation requires a round-trip to the backend to provide an error message that the front end code could easily have eliminated

* The back end may not be able to cope with the data payload the front-end code could have easily eliminated. For example, buffer overflows, XML injection, or similar.

===Acceptable Method ===

The account select option parameter is read by the code, and compared to the previously rendered list.

''if ( account.inList(session.getParameter('payeelstid') ) {''
''backend.performTransfer(session.getParameter('payeelstid'));''
''}''

This prevents parameter tampering, but still makes the browser do a lot of work.

===Best Method ===

The original code emitted indexes <option value="1" ... > rather than account names.

''int payeeLstId = session.getParameter('payeelstid');''
''accountFrom = account.getAcctNumberByIndex(payeeLstId);''

Not only is this easier to render in HTML, it makes validation and business rule validation trivial. The field cannot be tampered with.

===Conclusion ===

To provide defense in depth and to prevent attack payloads from trust boundaries, such as backend hosts, which are probably incapable of handling arbitrary input data, business rule validation is to be performed (preferably in workflow or command patterns), even if it is known that the back end code performs business rule validation.

This is not to say that the entire set of business rules need be applied - it means that the fundamentals are performed to prevent unnecessary round trips to the backend and to prevent the backend from receiving most tampered data.

==Data Validation Strategies ==

There are four strategies for validating data, and they should be used in this order:

===Accept known good===

This strategy is also known as "whitelist" or "positive" validation. The idea is that you should check that the data is one of a set of tightly constrained known good values. Any data that doesn't match should be rejected. Data should be:

* Strongly typed at all times
* Length checked and fields length minimized
* Range checked if a numeric
* Unsigned unless required to be signed
* Syntax or grammar should be checked prior to first use or inspection

If you expect a postcode, validate for a postcode (type, length and syntax):

<code>
<pre>
public String isPostcode(String postcode) {
return (postcode != null && Pattern.matches("^(((2|8|9)\d{2})|((02|08|09)\d{2})|([1-9]\d{3}))$", postcode)) ? postcode : "";
}
</pre>
</code>

Coding guidelines should use some form of visible tainting on input from the client or untrusted sources, such as third party connectors to make it obvious that the input is unsafe:

<code>
<pre>
String taintPostcode = request.getParameter("postcode");
ValidationEngine validator = new ValidationEngine();
boolean isValidPostcode = validator.isPostcode(taintPostcode);
</pre>
</code>

===Reject known bad===

This strategy, also known as "negative" or "blacklist" validation is a weak alternative to positive validation. Essentially, if you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them. This is a dangerous strategy, because the set of possible bad data is potentially infinite. Adopting this strategy means that you will have to maintain the list of "known bad" characters and patterns forever, and you will by definition have incomplete protection.

''public String removeJavascript(String input) {''

'' Pattern p = Pattern.compile("javascript", CASE_INSENSITIVE);''

'' p.matcher(input);''

'' return (!p.matches()) ? input : '';''

''}''

It can take upwards of 90 regular expressions (see the CSS Cheat Sheet in the Guide 2.0) to eliminate known malicious software, and each regex needs to be run over every field. Obviously, this is slow and not secure. Just rejecting "current known bad" (which is at the time of writing hundreds of strings and literally millions of combinations) is insufficient if the input is a string. This strategy is directly akin to anti-virus pattern updates. Unless the business will allow updating "bad" regexes on a daily basis and support someone to research new attacks regularly, this approach will be obviated before long.

===Sanitize===

Eliminate or translate characters (such as to HTML entities or to remove quotes) in an effort to make the input "safe".
Like blacklists, this approach requires maintenance and is usually incomplete. As most fields have a particular grammar, it is simpler, faster, and more secure to simply validate a single correct positive test than to try to include complex and slow sanitization routines for all current and future attacks.

<code>
<pre>
public String quoteApostrophe(String input) {
if (input != null)
return input.replaceAll("[\']", "&rsquo;");
else
return null;
}
</pre>
</code>

===No validation===

This is inherently unsafe and strongly discouraged. The business must sign off each and every example of no validation as the lack of validation usually leads to direct obviation of application, host and network security controls.

''account.setAcctId(getParameter('formAcctNo'));''
''...''

''public setAcctId(String acctId) {''
'' cAcctId = acctId;''
''}''

==Prevent parameter tampering ==

There are many input sources:

* HTTP headers, such as REMOTE_ADDR, PROXY_VIA or similar

* Environment variables, such as getenv() or via server properties

* All GET, POST and Cookie data

This includes supposedly tamper resistant fields such as radio buttons, drop downs, etc - any client side HTML can be re-written to suit the attacker

Configuration data (mistakes happen :))

External systems (via any form of input mechanism, such as XML input, RMI, web services, etc)

All of these data sources supply untrusted input. Data received from untrusted data sources must be properly checked before first use.

==Hidden fields ==

Hidden fields are a simple way to avoid storing state on the server. Their use is particularly prevalent in "wizard-style" multi-page forms. However, their use exposes the inner workings of your application, and exposes data to trivial tampering, replay, and validation attacks. In general, only use hidden fields for page sequence.

If you have to use hidden fields, there are some rules:

* Secrets, such as passwords, should never be sent in the clear

* Hidden fields need to have integrity checks and preferably encrypted using non-constant initialization vectors (i.e. different users at different times have different yet cryptographically strong random IVs)

* Encrypted hidden fields must be robust against replay attacks, which means some form of temporal keying

* Data sent to the user must be validated on the server once the last page has been received, even if it has been previously validated on the server - this helps reduce the risk from replay attacks.

The preferred integrity control should be at least a HMAC using SHA-256 or preferably digitally signed or encrypted using PGP. IBMJCE supports SHA-256, but PGP JCE support require the inclusion of the Legion of the Bouncy Castle (http://www.bouncycastle.org/) JCE classes.

It is simpler to store this data temporarily in the session object. Using the session object is the safest option as data is never visible to the user, requires (far) less code, nearly no CPU, disk or I/O utilization, less memory (particularly on large multi-page forms), and less network consumption.

In the case of the session object being backed by a database, large session objects may become too large for the inbuilt handler. In this case, the recommended strategy is to store the validated data in the database, but mark the transaction as "incomplete". Each page will update the incomplete transaction until it is ready for submission. This minimizes the database load, session size, and activity between the users whilst remaining tamperproof.

Code containing hidden fields should be rejected during code reviews.

==ASP.NET Viewstate ==

ASP.NET sends form data back to the client in a hidden “Viewstate” field. Despite looking forbidding, this “encryption” is simply plain-text equivalent (base64 encoding) and has no data integrity without further action on your behalf in ASP.NET 1.0. In ASP.NET 1.1 and 2.0, tamper proofing, called "enableViewStateMAC" is on by default using a SHA/1 hash.

Any application framework with a similar mechanism might be at fault – you should investigate your application framework’s support for sending data back to the user. Preferably it should not round trip.

===How to determine if you are vulnerable ===

These configurations are set hierarchically in the .NET framework. The machine.config file contains the global configuration; each web directory may contain a web.config file further specifying or overriding configuration; each page may contain @page directives specifying same configuration or overrides; you must check all three locations:

* If the enableViewStateMac is not set to “true”, you are at risk if your viewstate contains authorization state

* If the viewStateEncryptionMode is not set to “always”, you are at risk if your viewstate contains secrets such as credentials

* If you share a host with many other customers, you all share the same machine key by default in ASP.NET 1.1. In ASP.NET 2.0, it is possible to configure unique viewstate keys per application

===How to protect yourself ===

* If your application relies on data returning from the viewstate without being tampered with, you should turn on viewstate integrity checks at the least, and strongly consider:

* Encrypt viewstate if any of the data is application sensitive

* Upgrade to ASP.NET 2.0 as soon as practical if you are on a shared hosting arrangement

* Move truly sensitive viewstate data to the session variable instead

===Selects, radio buttons, and checkboxes ===

It is commonly held belief that the value settings for these items cannot be easily tampered. This is wrong. In the following example, actual account numbers are used, which can lead to compromise:

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(1).toString( )%>" />''

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(2).toString( )%>" />''

This produces (for example):

''<input type="radio" name="acctNo" value="455712341234">Gold Card''

''<input type="radio" name="acctNo" value="455712341235">Platinum Card''

If the value is retrieved and then used directly in a SQL query, an interesting form of SQL injection may occur: authorization tampering leading to information disclosure. As the connection pool connects to the database using a single user, it may be possible to see other user's accounts if the SQL looks something like this:

''String acctNo = getParameter('acctNo');''

''String sql = "SELECT acctBal FROM accounts WHERE acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acctNo);''

''ResultSet rs = st.executeQuery();''

This should be re-written to retrieve the account number via index, and include the client's unique ID to ensure that other valid account numbers are exposed:

''String acctNo = acct.getCardNumber(getParameter('acctIndex'));''

''String sql = "SELECT acctBal FROM accounts WHERE acct_id = '?' AND acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acct.getID());''

''st.setString(2, acctNo);''

''ResultSet rs = st.executeQuery();''

This approach requires rendering input values from 1 to ... x, and assuming accounts are stored in a Collection which can be iterated using logic:iterate:

''<logic:iterate id="loopVar" name="MyForm" property="values">''

'' <html:radio property="acctIndex" idName="loopVar" value="value"/> ''

'' <bean:write name="loopVar" property="name"/> ''

''</logic:iterate>''

The code will emit HTML with the values "1" .. "x" as per the collection's content.

''<input type="radio" name="acctIndex" value="1" />Gold Credit Card''

''<input type="radio" name="acctIndex" value="2" />Platinum Credit Card''

This approach should be used for any input type that allows a value to be set: radio buttons, checkboxes, and particularly select / option lists.

===Per-User Data ===

In fully normalized databases, the aim is to minimize the amount of repeated data. However, some data is inferred. For example, users can see messages that are stored in a messages table. Some messages are private to the user. However, in a fully normalized database, the list of message IDs are kept within another table:

If a user marks a message for deletion, the usual way is to recover the message ID from the user, and delete that:

''DELETE FROM message WHERE msgid='frmMsgId'''

However, how do you know if the user is eligible to delete that message ID? Such tables need to be denormalized slightly to include a user ID or make it easy to perform a single query to delete the message safely. For example, by adding back an (optional) uid column, the delete is now made reasonably safe:

''DELETE FROM message WHERE uid='session.myUserID' and msgid='frmMsgId';''

Where the data is potentially both a private resource and a public resource (for example, in the secure message service, broadcast messages are just a special type of private message), additional precautions need to be taken to prevent users from deleting public resources without authorization. This can be done using role based checks, as well as using SQL statements to discriminate by message type:

''DELETE FROM message ''

''WHERE''

''uid='session.myUserID' AND''

''msgid='frmMsgId' AND''

''broadcastFlag = false;''

==URL encoding ==

Data sent via the URL, which is strongly discouraged, should be URL encoded and decoded. This reduces the likelihood of cross-site scripting attacks from working.

In general, do not send data via GET request unless for navigational purposes.

==HTML encoding ==

Data sent to the user needs to be safe for the user to view. This can be done using <bean:write ...> and friends. Do not use <%=var%> unless it is used to supply an argument for <bean:write...> or similar.

HTML encoding translates a range of characters into their HTML entities. For example, > becomes &gt; This will still display as > on the user's browser, but it is a safe alternative.

==Encoded strings ==

Some strings may be received in encoded form. It is essential to send the correct locale to the user so that the web server and application server can provide a single level of canoncalization prior to the first use.

Do not use getReader() or getInputStream() as these input methods do not decode encoded strings. If you need to use these constructs, you must decanoncalize data by hand.

==Data Validation and Interpreter Injection ==

This section focuses on preventing injection in ColdFusion. Interpreter Injection involves manipulating application parameters to execute malicious code on the system. The most prevalent of these is SQL injection but it also includes other injection techniques, including LDAP, ORM, User Agent, XML, etc. – see the Interpreter Injection chapter of this document for greater details. As a developer you should assume that all input is malicious. Before processing any input coming from a user, data source, component, or data service it should be validated for type, length, and/or range. ColdFusion includes support for Regular Expressions and CFML tags that can be used to validate input.

'''SQL Injection'''

SQL Injection involves sending extraneous SQL queries as variables. ColdFusion provides the <cfqueryparam> and <cfprocparam> tags for validating database parameters. These tags nests inside <cfquery> and <cfstoredproc>, respectively. For dynamic SQL submitted in <cfquery>, use the CFSQLTYPE attribute of the <cfqueryparam> to validate variables against the expected database datatype. Similarly, use the CFSQLTYPE attribute of <cfprocparam> to validate the datatypes of stored procedure parameters passed through <cfstoredproc>.

You can also strengthen your systems against SQL Injection by disabling the Allowed SQL operations for individual data sources. See the '''Configuration''' section below for more information.

'''LDAP Injection'''

ColdFusion uses the <cfldap> tag to communicate with LDAP servers. This tag has an ACTION attribute which dictates the query performed against the LDAP. The valid values for this attribute are: add, delete, query (default), modify, and modifyDN. <cfldap> calls are turned into JNDI (Java Naming And Directory Interface) lookups. However, because <cfldap> wraps the calls, it will throw syntax errors if native JNDI code is passed to its attributes making LDAP injection more difficult.

'''XML Injection'''

Two parsers exist for XML data – SAX and DOM. ColdFusion uses DOM which reads the entire XML document into the server’s memory. This requires the administrator to restrict the size of the JVM containing ColdFusion. ColdFusion is built on Java therefore by default, entity references are expanded during parsing. To prevent unbounded entity expansion, before a string is converted to an XML DOM, filter out DOCTYPES elements.

After the DOM has been read, to reduce the risk of XML, Injection use the ColdFusion XML decision functions: isXML(), isXmlAttribute(), isXmlElement(), isXmlNode(), and isXmlRoot(). The isXML() function determines if a string is well-formed XML. The other functions determine whether or not the passed parameter is a valid part of an XML document. Use the xmlValidate() function to validate external XML documents against a Document Type Definition (DTD) or XML Schema.

'''Event Gateway, IM, and SMS Injection'''

ColdFusion MX 7 enables Event Gateways, instant messaging (IM), and SMS (short message service) for interacting with external systems. Event Gateways are ColdFusion components that respond asynchronously to non-HTTP requests – e.g. instant messages, SMS text from wireless devices, etc. ColdFusion provides Lotus Sametime and XMPP (Extensible Messaging and Presence Protocol) gateways for instant messaging. It also provides an event gateway for interacting with SMS text messages.

Injection along these gateways can happen when end users (and/or systems) send malicious code to execute on the server. These gateways all utilize ColdFusion Components (CFCs) for processing. Use standard ColdFusion functions, tags, and validation techniques to protect against malicious code injection. Sanitize all input strings and do not allow un-validated code to access backend systems.

'''Best Practices'''

Use the XML functions to validate XML input.

Before performing XPath searches and transformations in ColdFusion, validate the source before executing.

Use ColdFusion validation techniques to sanitize strings passed to xmlSearch for performing XPath queries.

When performing XML transformations only use a trusted source for the XSL stylesheet.

Ensure that the memory size of the Java Sandbox containing ColdFusion can handle large XML documents without adversely affecting server resources.

Set the memory value to less than the amount of RAM on the server (-Xmx)

Remove DOCTYPE elements from the XML string before converting it to an XML object.

Using scriptProtect can be used to thwart most attempts of cross-site scripting. Set scriptProtect to All in the Application.cfc

Use <cfparam> or <cfargument> to instantiate variables in ColdFusion. Use this tag with the name and type attributes. If the value is not of the specified type, ColdFusion returns an error.

To handle untyped variables use IsValid() to validate its value against any legal object type that ColdFusion supports.

Use <cfqueryparam> and <cfprocparam> to valid dynamic SQL variables against database datatypes

Use CFLDAP for accessing LDAP servers. Avoid allowing native JNDI calls to connect to LDAP

'''Best Practice in Action'''

The sample code below shows a database authentication function using some of the input validation techniques discussed in this section.

{| border=1

||
* <cffunction name="dblogin" access="private" output="false" returntype="struct">

* <cfargument name="strUserName" required="true" type="string">

* <cfargument name="strPassword" required="true" type="string">

* <cfset var retargs = StructNew()>

* <cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

* <cfquery name="loginQuery" dataSource="#Application.DB#" >

* SELECT hashed_password, salt

* FROM UserTable

* WHERE UserName =

* <cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

* </cfquery>

* <cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

* <cfset retargs.authenticated="YES">

* <cfset Session.UserName = strUserName>

* 

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfreturn retargs>

* </cffunction>

|-

|}

==Delimiter and special characters ==

There are many characters that mean something special to various programs. If you followed the advice only to accept characters that are considered good, it is very likely that only a few delimiters will catch you out.

Here are the usual suspects:

* NULL (zero) %00

* LF - ANSI chr(10) "\r"

* CR - ANSI chr(13) "\n"

* CRLF - "\n\r"

* CR - EBCDIC 0x0f

* Quotes " '

* Commas, slashes spaces and tabs and other white space - used in CSV, tab delimited output, and other specialist formats

* <> - XML and HTML tag markers, redirection characters

* ; & - Unix and NT file system continuance

* @ - used for e-mail addresses

* 0xff

* ... more

Whenever you code to a particular technology, you should determine which characters are "special" and prevent them appearing in input, or properly escaping them.

==Further Reading ==

* ASP.NET 2.0 Viewstate

http://channel9.msdn.com/wiki/default.aspx/Channel9.HowToConfigureTheMachineKeyInASPNET2

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Validation]]
[[Category:Encoding]]

Data Validation

2007-05-22T13:56:08Z

Scovetta: Reformatted code, added null check

[[Guide Table of Contents]]__TOC__

==Objective ==

To ensure that the application is robust against all forms of input data, whether obtained from the user, infrastructure, external entities or database systems

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS11 – Manage Data. All sections should be reviewed

==Description ==

The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as interpreter injection, locale/Unicode attacks, file system attacks and buffer overflows. Data from the client should never be trusted for the client has every possibility to tamper with the data.

In many cases, [[Encoding]] has the potential to defuse attacks that rely on lack of input validation. For example, if you use HTML entity encoding on user input before it is sent to a browser, it will prevent most [[XSS]] attacks. However, simply preventing attacks is not enough - you must perform [[Intrusion Detection]] in your applications. Otherwise, you are allowing attackers to repeatedly attack your application until they find a vulnerability that you haven't protected against. Detecting attempts to find these weaknesses is a critical protection mechanism.

==Definitions ==

These definitions are used within this document:

* '''Integrity checks'''

Ensure that the data has not been tampered with and is the same as before

* '''Validation'''

Ensure that the data is strongly typed, correct syntax, within length boundaries, contains only permitted characters, or that numbers are correctly signed and within range boundaries

* '''Business rules'''

Ensure that data is not only validated, but business rule correct. For example, interest rates fall within permitted boundaries.

Some documentation and references interchangeably use the various meanings, which is very confusing to all concerned. This confusion directly causes continuing financial loss to the organization.

==Where to include integrity checks ==

Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return.

The type of integrity control (checksum, HMAC, encryption, digital signature) should be directly related to the risk of the data transiting the trust boundary.

==Where to include validation ==

Validation must be performed on every tier. However, validation should be performed as per the function of the server executing the code. For example, the web / presentation tier should validate for web related issues, persistence layers should validate for persistence issues such as SQL / HQL injection, directory lookups should check for LDAP injection, and so on.

==Where to include business rule validation ==

Business rules are known during design, and they influence implementation. However, there are bad, good and "best" approaches. Often the best approach is the simplest in terms of code.

===Example - Scenario ===

* You are to populate a list with accounts provided by the back-end system
* The user will choose an account, choose a biller, and press next

===Wrong way===

The account select option is read directly and provided in a message back to the backend system without validating the account number is one of the accounts provided by the backend system.

===Why this is bad===

An attacker can change the HTML in any way they choose:

* The lack of validation requires a round-trip to the backend to provide an error message that the front end code could easily have eliminated

* The back end may not be able to cope with the data payload the front-end code could have easily eliminated. For example, buffer overflows, XML injection, or similar.

===Acceptable Method ===

The account select option parameter is read by the code, and compared to the previously rendered list.

''if ( account.inList(session.getParameter('payeelstid') ) {''
''backend.performTransfer(session.getParameter('payeelstid'));''
''}''

This prevents parameter tampering, but still makes the browser do a lot of work.

===Best Method ===

The original code emitted indexes <option value="1" ... > rather than account names.

''int payeeLstId = session.getParameter('payeelstid');''
''accountFrom = account.getAcctNumberByIndex(payeeLstId);''

Not only is this easier to render in HTML, it makes validation and business rule validation trivial. The field cannot be tampered with.

===Conclusion ===

To provide defense in depth and to prevent attack payloads from trust boundaries, such as backend hosts, which are probably incapable of handling arbitrary input data, business rule validation is to be performed (preferably in workflow or command patterns), even if it is known that the back end code performs business rule validation.

This is not to say that the entire set of business rules need be applied - it means that the fundamentals are performed to prevent unnecessary round trips to the backend and to prevent the backend from receiving most tampered data.

==Data Validation Strategies ==

There are four strategies for validating data, and they should be used in this order:

===Accept known good===

This strategy is also known as "whitelist" or "positive" validation. The idea is that you should check that the data is one of a set of tightly constrained known good values. Any data that doesn't match should be rejected. Data should be:

* Strongly typed at all times
* Length checked and fields length minimized
* Range checked if a numeric
* Unsigned unless required to be signed
* Syntax or grammar should be checked prior to first use or inspection

If you expect a postcode, validate for a postcode (type, length and syntax):

''public String validateAUpostCode(String postcode) {''
'' return (Pattern.matches("^(((2|8|9)\d{2})|((02|08|09)\d{2})|([1-9]\d{3}))$", postcode)) ? postcode : '';''
''}''

Coding guidelines should use some form of visible tainting on input from the client or untrusted sources, such as third party connectors to make it obvious that the input is unsafe:

''taintPostcode = getParameter('postcode');''
''validation = new validation();''
''postcode = validation.isPostcode(taintPostcode);''

===Reject known bad===

This strategy, also known as "negative" or "blacklist" validation is a weak alternative to positive validation. Essentially, if you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them. This is a dangerous strategy, because the set of possible bad data is potentially infinite. Adopting this strategy means that you will have to maintain the list of "known bad" characters and patterns forever, and you will by definition have incomplete protection.

''public String removeJavascript(String input) {''

'' Pattern p = Pattern.compile("javascript", CASE_INSENSITIVE);''

'' p.matcher(input);''

'' return (!p.matches()) ? input : '';''

''}''

It can take upwards of 90 regular expressions (see the CSS Cheat Sheet in the Guide 2.0) to eliminate known malicious software, and each regex needs to be run over every field. Obviously, this is slow and not secure. Just rejecting "current known bad" (which is at the time of writing hundreds of strings and literally millions of combinations) is insufficient if the input is a string. This strategy is directly akin to anti-virus pattern updates. Unless the business will allow updating "bad" regexes on a daily basis and support someone to research new attacks regularly, this approach will be obviated before long.

===Sanitize===

Eliminate or translate characters (such as to HTML entities or to remove quotes) in an effort to make the input "safe".
Like blacklists, this approach requires maintenance and is usually incomplete. As most fields have a particular grammar, it is simpler, faster, and more secure to simply validate a single correct positive test than to try to include complex and slow sanitization routines for all current and future attacks.

<code>
<pre>
public String quoteApostrophe(String input) {
if (input != null)
return input.replaceAll("[\']", "&rsquo;");
else
return null;
}
</pre>
</code>

===No validation===

This is inherently unsafe and strongly discouraged. The business must sign off each and every example of no validation as the lack of validation usually leads to direct obviation of application, host and network security controls.

''account.setAcctId(getParameter('formAcctNo'));''
''...''

''public setAcctId(String acctId) {''
'' cAcctId = acctId;''
''}''

==Prevent parameter tampering ==

There are many input sources:

* HTTP headers, such as REMOTE_ADDR, PROXY_VIA or similar

* Environment variables, such as getenv() or via server properties

* All GET, POST and Cookie data

This includes supposedly tamper resistant fields such as radio buttons, drop downs, etc - any client side HTML can be re-written to suit the attacker

Configuration data (mistakes happen :))

External systems (via any form of input mechanism, such as XML input, RMI, web services, etc)

All of these data sources supply untrusted input. Data received from untrusted data sources must be properly checked before first use.

==Hidden fields ==

Hidden fields are a simple way to avoid storing state on the server. Their use is particularly prevalent in "wizard-style" multi-page forms. However, their use exposes the inner workings of your application, and exposes data to trivial tampering, replay, and validation attacks. In general, only use hidden fields for page sequence.

If you have to use hidden fields, there are some rules:

* Secrets, such as passwords, should never be sent in the clear

* Hidden fields need to have integrity checks and preferably encrypted using non-constant initialization vectors (i.e. different users at different times have different yet cryptographically strong random IVs)

* Encrypted hidden fields must be robust against replay attacks, which means some form of temporal keying

* Data sent to the user must be validated on the server once the last page has been received, even if it has been previously validated on the server - this helps reduce the risk from replay attacks.

The preferred integrity control should be at least a HMAC using SHA-256 or preferably digitally signed or encrypted using PGP. IBMJCE supports SHA-256, but PGP JCE support require the inclusion of the Legion of the Bouncy Castle (http://www.bouncycastle.org/) JCE classes.

It is simpler to store this data temporarily in the session object. Using the session object is the safest option as data is never visible to the user, requires (far) less code, nearly no CPU, disk or I/O utilization, less memory (particularly on large multi-page forms), and less network consumption.

In the case of the session object being backed by a database, large session objects may become too large for the inbuilt handler. In this case, the recommended strategy is to store the validated data in the database, but mark the transaction as "incomplete". Each page will update the incomplete transaction until it is ready for submission. This minimizes the database load, session size, and activity between the users whilst remaining tamperproof.

Code containing hidden fields should be rejected during code reviews.

==ASP.NET Viewstate ==

ASP.NET sends form data back to the client in a hidden “Viewstate” field. Despite looking forbidding, this “encryption” is simply plain-text equivalent (base64 encoding) and has no data integrity without further action on your behalf in ASP.NET 1.0. In ASP.NET 1.1 and 2.0, tamper proofing, called "enableViewStateMAC" is on by default using a SHA/1 hash.

Any application framework with a similar mechanism might be at fault – you should investigate your application framework’s support for sending data back to the user. Preferably it should not round trip.

===How to determine if you are vulnerable ===

These configurations are set hierarchically in the .NET framework. The machine.config file contains the global configuration; each web directory may contain a web.config file further specifying or overriding configuration; each page may contain @page directives specifying same configuration or overrides; you must check all three locations:

* If the enableViewStateMac is not set to “true”, you are at risk if your viewstate contains authorization state

* If the viewStateEncryptionMode is not set to “always”, you are at risk if your viewstate contains secrets such as credentials

* If you share a host with many other customers, you all share the same machine key by default in ASP.NET 1.1. In ASP.NET 2.0, it is possible to configure unique viewstate keys per application

===How to protect yourself ===

* If your application relies on data returning from the viewstate without being tampered with, you should turn on viewstate integrity checks at the least, and strongly consider:

* Encrypt viewstate if any of the data is application sensitive

* Upgrade to ASP.NET 2.0 as soon as practical if you are on a shared hosting arrangement

* Move truly sensitive viewstate data to the session variable instead

===Selects, radio buttons, and checkboxes ===

It is commonly held belief that the value settings for these items cannot be easily tampered. This is wrong. In the following example, actual account numbers are used, which can lead to compromise:

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(1).toString( )%>" />''

''<html:radio value="<%=acct.getCardNumber(1).toString( )%>" property="acctNo">''

''<bean:message key="msg.card.name" arg0="<%=acct.getCardName(2).toString( )%>" />''

This produces (for example):

''<input type="radio" name="acctNo" value="455712341234">Gold Card''

''<input type="radio" name="acctNo" value="455712341235">Platinum Card''

If the value is retrieved and then used directly in a SQL query, an interesting form of SQL injection may occur: authorization tampering leading to information disclosure. As the connection pool connects to the database using a single user, it may be possible to see other user's accounts if the SQL looks something like this:

''String acctNo = getParameter('acctNo');''

''String sql = "SELECT acctBal FROM accounts WHERE acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acctNo);''

''ResultSet rs = st.executeQuery();''

This should be re-written to retrieve the account number via index, and include the client's unique ID to ensure that other valid account numbers are exposed:

''String acctNo = acct.getCardNumber(getParameter('acctIndex'));''

''String sql = "SELECT acctBal FROM accounts WHERE acct_id = '?' AND acctNo = '?'";''

''PreparedStatement st = conn.prepareStatement(sql);''

''st.setString(1, acct.getID());''

''st.setString(2, acctNo);''

''ResultSet rs = st.executeQuery();''

This approach requires rendering input values from 1 to ... x, and assuming accounts are stored in a Collection which can be iterated using logic:iterate:

''<logic:iterate id="loopVar" name="MyForm" property="values">''

'' <html:radio property="acctIndex" idName="loopVar" value="value"/> ''

'' <bean:write name="loopVar" property="name"/> ''

''</logic:iterate>''

The code will emit HTML with the values "1" .. "x" as per the collection's content.

''<input type="radio" name="acctIndex" value="1" />Gold Credit Card''

''<input type="radio" name="acctIndex" value="2" />Platinum Credit Card''

This approach should be used for any input type that allows a value to be set: radio buttons, checkboxes, and particularly select / option lists.

===Per-User Data ===

In fully normalized databases, the aim is to minimize the amount of repeated data. However, some data is inferred. For example, users can see messages that are stored in a messages table. Some messages are private to the user. However, in a fully normalized database, the list of message IDs are kept within another table:

If a user marks a message for deletion, the usual way is to recover the message ID from the user, and delete that:

''DELETE FROM message WHERE msgid='frmMsgId'''

However, how do you know if the user is eligible to delete that message ID? Such tables need to be denormalized slightly to include a user ID or make it easy to perform a single query to delete the message safely. For example, by adding back an (optional) uid column, the delete is now made reasonably safe:

''DELETE FROM message WHERE uid='session.myUserID' and msgid='frmMsgId';''

Where the data is potentially both a private resource and a public resource (for example, in the secure message service, broadcast messages are just a special type of private message), additional precautions need to be taken to prevent users from deleting public resources without authorization. This can be done using role based checks, as well as using SQL statements to discriminate by message type:

''DELETE FROM message ''

''WHERE''

''uid='session.myUserID' AND''

''msgid='frmMsgId' AND''

''broadcastFlag = false;''

==URL encoding ==

Data sent via the URL, which is strongly discouraged, should be URL encoded and decoded. This reduces the likelihood of cross-site scripting attacks from working.

In general, do not send data via GET request unless for navigational purposes.

==HTML encoding ==

Data sent to the user needs to be safe for the user to view. This can be done using <bean:write ...> and friends. Do not use <%=var%> unless it is used to supply an argument for <bean:write...> or similar.

HTML encoding translates a range of characters into their HTML entities. For example, > becomes &gt; This will still display as > on the user's browser, but it is a safe alternative.

==Encoded strings ==

Some strings may be received in encoded form. It is essential to send the correct locale to the user so that the web server and application server can provide a single level of canoncalization prior to the first use.

Do not use getReader() or getInputStream() as these input methods do not decode encoded strings. If you need to use these constructs, you must decanoncalize data by hand.

==Data Validation and Interpreter Injection ==

This section focuses on preventing injection in ColdFusion. Interpreter Injection involves manipulating application parameters to execute malicious code on the system. The most prevalent of these is SQL injection but it also includes other injection techniques, including LDAP, ORM, User Agent, XML, etc. – see the Interpreter Injection chapter of this document for greater details. As a developer you should assume that all input is malicious. Before processing any input coming from a user, data source, component, or data service it should be validated for type, length, and/or range. ColdFusion includes support for Regular Expressions and CFML tags that can be used to validate input.

'''SQL Injection'''

SQL Injection involves sending extraneous SQL queries as variables. ColdFusion provides the <cfqueryparam> and <cfprocparam> tags for validating database parameters. These tags nests inside <cfquery> and <cfstoredproc>, respectively. For dynamic SQL submitted in <cfquery>, use the CFSQLTYPE attribute of the <cfqueryparam> to validate variables against the expected database datatype. Similarly, use the CFSQLTYPE attribute of <cfprocparam> to validate the datatypes of stored procedure parameters passed through <cfstoredproc>.

You can also strengthen your systems against SQL Injection by disabling the Allowed SQL operations for individual data sources. See the '''Configuration''' section below for more information.

'''LDAP Injection'''

ColdFusion uses the <cfldap> tag to communicate with LDAP servers. This tag has an ACTION attribute which dictates the query performed against the LDAP. The valid values for this attribute are: add, delete, query (default), modify, and modifyDN. <cfldap> calls are turned into JNDI (Java Naming And Directory Interface) lookups. However, because <cfldap> wraps the calls, it will throw syntax errors if native JNDI code is passed to its attributes making LDAP injection more difficult.

'''XML Injection'''

Two parsers exist for XML data – SAX and DOM. ColdFusion uses DOM which reads the entire XML document into the server’s memory. This requires the administrator to restrict the size of the JVM containing ColdFusion. ColdFusion is built on Java therefore by default, entity references are expanded during parsing. To prevent unbounded entity expansion, before a string is converted to an XML DOM, filter out DOCTYPES elements.

After the DOM has been read, to reduce the risk of XML, Injection use the ColdFusion XML decision functions: isXML(), isXmlAttribute(), isXmlElement(), isXmlNode(), and isXmlRoot(). The isXML() function determines if a string is well-formed XML. The other functions determine whether or not the passed parameter is a valid part of an XML document. Use the xmlValidate() function to validate external XML documents against a Document Type Definition (DTD) or XML Schema.

'''Event Gateway, IM, and SMS Injection'''

ColdFusion MX 7 enables Event Gateways, instant messaging (IM), and SMS (short message service) for interacting with external systems. Event Gateways are ColdFusion components that respond asynchronously to non-HTTP requests – e.g. instant messages, SMS text from wireless devices, etc. ColdFusion provides Lotus Sametime and XMPP (Extensible Messaging and Presence Protocol) gateways for instant messaging. It also provides an event gateway for interacting with SMS text messages.

Injection along these gateways can happen when end users (and/or systems) send malicious code to execute on the server. These gateways all utilize ColdFusion Components (CFCs) for processing. Use standard ColdFusion functions, tags, and validation techniques to protect against malicious code injection. Sanitize all input strings and do not allow un-validated code to access backend systems.

'''Best Practices'''

Use the XML functions to validate XML input.

Before performing XPath searches and transformations in ColdFusion, validate the source before executing.

Use ColdFusion validation techniques to sanitize strings passed to xmlSearch for performing XPath queries.

When performing XML transformations only use a trusted source for the XSL stylesheet.

Ensure that the memory size of the Java Sandbox containing ColdFusion can handle large XML documents without adversely affecting server resources.

Set the memory value to less than the amount of RAM on the server (-Xmx)

Remove DOCTYPE elements from the XML string before converting it to an XML object.

Using scriptProtect can be used to thwart most attempts of cross-site scripting. Set scriptProtect to All in the Application.cfc

Use <cfparam> or <cfargument> to instantiate variables in ColdFusion. Use this tag with the name and type attributes. If the value is not of the specified type, ColdFusion returns an error.

To handle untyped variables use IsValid() to validate its value against any legal object type that ColdFusion supports.

Use <cfqueryparam> and <cfprocparam> to valid dynamic SQL variables against database datatypes

Use CFLDAP for accessing LDAP servers. Avoid allowing native JNDI calls to connect to LDAP

'''Best Practice in Action'''

The sample code below shows a database authentication function using some of the input validation techniques discussed in this section.

{| border=1

||
* <cffunction name="dblogin" access="private" output="false" returntype="struct">

* <cfargument name="strUserName" required="true" type="string">

* <cfargument name="strPassword" required="true" type="string">

* <cfset var retargs = StructNew()>

* <cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

* <cfquery name="loginQuery" dataSource="#Application.DB#" >

* SELECT hashed_password, salt

* FROM UserTable

* WHERE UserName =

* <cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

* </cfquery>

* <cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

* <cfset retargs.authenticated="YES">

* <cfset Session.UserName = strUserName>

* 

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfelse>

* <cfset retargs.authenticated="NO">

* </cfif>

* <cfreturn retargs>

* </cffunction>

|-

|}

==Delimiter and special characters ==

There are many characters that mean something special to various programs. If you followed the advice only to accept characters that are considered good, it is very likely that only a few delimiters will catch you out.

Here are the usual suspects:

* NULL (zero) %00

* LF - ANSI chr(10) "\r"

* CR - ANSI chr(13) "\n"

* CRLF - "\n\r"

* CR - EBCDIC 0x0f

* Quotes " '

* Commas, slashes spaces and tabs and other white space - used in CSV, tab delimited output, and other specialist formats

* <> - XML and HTML tag markers, redirection characters

* ; & - Unix and NT file system continuance

* @ - used for e-mail addresses

* 0xff

* ... more

Whenever you code to a particular technology, you should determine which characters are "special" and prevent them appearing in input, or properly escaping them.

==Further Reading ==

* ASP.NET 2.0 Viewstate

http://channel9.msdn.com/wiki/default.aspx/Channel9.HowToConfigureTheMachineKeyInASPNET2

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Validation]]
[[Category:Encoding]]

Buffer Overflows

2006-08-08T17:49:16Z

Scovetta: Added link to Phrack article

[[Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components

* Applications create as few buffer overflows as possible

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1
|-
! Language/Environment !! Compiled or Interpreted !! Strongly Typed !! Direct Memory Access !! Safe or Unsafe

|-

|| Java, Java Virtual Machine (JVM) || Both || Yes || No || Safe

|-

|| .NET || Both || Yes || No || Safe

|-

|| Perl || Both || Yes || No || Safe

|-

|| Python - interpreted || Intepreted || Yes || No || Safe

|-

|| Ruby || Interpreted || Yes || No || Safe

|-

|| C/C++ || Compiled || No || Yes || Unsafe

|-

|| Assembly || Compiled || No || Yes || Unsafe

|-

|| COBOL || Compiled || Yes || No || Safe

|-

|}
Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

<pre>
#include <string.h>

void f(char* s) {
char buffer[10];
strcpy(buffer, s);
}

void main(void) {
f("01234567890123456789");
}

[root /tmp]# ./stacktest

Segmentation fault
</pre>

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-execuable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

void main(void) {
char str[100] = scanf("%s");
printf("%s", str);
}
</pre>

This simple program takes input from the user and displays it back on the screen. The string <code>%s</code> means that the other parameter, str, should be displayed as a string. This example is ''not'' vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from [http://www.phrack.org/phrack/60/p60-0x0a.txt Blexim's Phrack article]:

<pre>
#include <stdio.h>
#include <string.h>

void main(int argc, char *argv[]) {
int i = atoi(argv[1]); // input from user
unsigned short s = i; // truncate to a short
char buf[50]; // large buffer

if (s > 10) { // check we're not greater than 10
return;
}

memcpy(buf, argv[2], i); // copy i bytes to the buffer
buf[i] = '\0'; // add a null byte to the buffer
printf("%s\n", buf); // output the buffer contents

return;
}

[root /tmp]# ./inttest 65580 foobar
Segmentation fault
</pre>

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html

* Newsham, Tim, ''Format String Attacks

''http://www.lava.net/~newsham/format-string-attacks.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/phrack/49/P49-14

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://rr.sans.org/code/inside_buffer.php

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/phrack/60/p60-0x0a.txt

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

http://www.immunix.org

* Libsafe

http://www.research.avayalabs.com/project/libsafe

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Buffer Overflows

2006-08-08T17:47:07Z

Scovetta: Fixed table formatting

[[Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components

* Applications create as few buffer overflows as possible

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1
|-
! Language/Environment !! Compiled or Interpreted !! Strongly Typed !! Direct Memory Access !! Safe or Unsafe

|-

|| Java, Java Virtual Machine (JVM) || Both || Yes || No || Safe

|-

|| .NET || Both || Yes || No || Safe

|-

|| Perl || Both || Yes || No || Safe

|-

|| Python - interpreted || Intepreted || Yes || No || Safe

|-

|| Ruby || Interpreted || Yes || No || Safe

|-

|| C/C++ || Compiled || No || Yes || Unsafe

|-

|| Assembly || Compiled || No || Yes || Unsafe

|-

|| COBOL || Compiled || Yes || No || Safe

|-

|}
Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

<pre>
#include <string.h>

void f(char* s) {
char buffer[10];
strcpy(buffer, s);
}

void main(void) {
f("01234567890123456789");
}

[root /tmp]# ./stacktest

Segmentation fault
</pre>

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-execuable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

void main(void) {
char str[100] = scanf("%s");
printf("%s", str);
}
</pre>

This simple program takes input from the user and displays it back on the screen. The string <code>%s</code> means that the other parameter, str, should be displayed as a string. This example is ''not'' vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from Blexim's ''Phrack ''article:

<pre>
#include <stdio.h>
#include <string.h>

void main(int argc, char *argv[]) {
int i = atoi(argv[1]); // input from user
unsigned short s = i; // truncate to a short
char buf[50]; // large buffer

if (s > 10) { // check we're not greater than 10
return;
}

memcpy(buf, argv[2], i); // copy i bytes to the buffer
buf[i] = '\0'; // add a null byte to the buffer
printf("%s\n", buf); // output the buffer contents

return;
}

[root /tmp]# ./inttest 65580 foobar
Segmentation fault
</pre>

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html

* Newsham, Tim, ''Format String Attacks

''http://www.lava.net/~newsham/format-string-attacks.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/phrack/49/P49-14

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://rr.sans.org/code/inside_buffer.php

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/phrack/60/p60-0x0a.txt

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

http://www.immunix.org

* Libsafe

http://www.research.avayalabs.com/project/libsafe

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Threat Risk Modeling

2006-07-25T15:23:08Z

Scovetta: Added threat analysis program from Microsoft.

[[Guide Table of Contents]]
__TOC__
When you start a web application design, it is essential to apply threat risk modeling; otherwise you will squander resources, time and money on useless controls that fail to focus on the real risks.

The method used to assess risk is not nearly as important as actually performing a structured threat risk modeling. Microsoft notes that the single most important factor in their security improvement program was the corporate adoption of threat risk modeling .

OWASP recommends Microsoft’s threat modeling process because it works well for addressing the unique challenges facing web application security and is simple to learn and adopt by designers, developers, code reviewers, and the quality assurance team.

The following sections provide some overview information (or see Section 6.9, Further Reading, for additional resources).

==Threat Risk Modeling ==

Threat risk modeling is an essential process for secure web application development. It allows organizations to determine the correct controls and to produce effective countermeasures within budget. For example, there is little point in spending $100,000 for fraud control for a system that has negligible fraud risk.

==Performing threat risk modeling using the Microsoft Threat Modeling Process ==

The threat risk modeling process has five steps , enumerated below and shown graphically in Figure 1. They are:

# Identify Security Objectives
# Survey the Application
# Decompose it
# Identify Threats
# Identify Vulnerabilities

[[Image:Threat_Model_Flow.gif|Figure 1: Threat Model Flow]]

Let’s consider the steps in more detail.

===Identify Security Objectives ===

The business (or project management) leadership, in concert with the software development and quality assurance teams, all need to understand the security objectives. To facilitate this, start by breaking down the application’s security objectives into the following categories:

* '''Identity:''' Does the application protect user identity from abuse? Are there adequate controls in place to ensure evidence of identity (as required for many banking applications?)

* '''Financial:''' Assess the level of risk the organization is prepared to absorb in remediation, as a potential financial loss. For example, forum software may have a lower estimated financial risk than an Internet banking application.

* '''Reputation:''' Quantify or estimate of the loss of reputation derived from the application being misused or successfully attacked.

* '''Privacy and Regulatory:''' To what extent will the application have to protect user data? Forum software by its nature is public, but a tax preparation application is subject to tax regulations and privacy legislation requirements in most countries.

* '''Availability Guarantees:''' Is the application required to be available per a '''''Service Level Agreement (SLA)''''' or similar guarantee? Is it a nationally protected infrastructure? To what level will the application have to be available? High availability techniques are significantly more expensive, so applying the correct controls up front will save a great deal of time, resources, and money.

This is by no means an exhaustive list, but it gives an idea of some of the business risk decisions leading into selecting and building security controls.

Other sources of risk guidance come from:

* Laws (such as privacy or finance laws)

* Regulations (such as banking or e-commerce regulations)

* Standards (such as ISO 17799)

* Legal Agreements (such as payment card industry standards or merchant agreements)

* Corporate Information Security Policy

===Application Overview ===

Once the security objectives have been defined, analyze the application design to identify the '''''components''''', '''''data flows''''', and '''''trust boundaries'''''.

Do this by surveying the application’s architecture and design documentation. In particular, look for UML component diagrams. Such high level component diagrams are generally sufficient to understand how and why data flows to various places. For example, data movement across a trust boundary (such as from the Internet to the web tier, or from the business logic to the database server), needs to be carefully analyzed, whereas data that flows within the same trust level does not need as much scrutiny.

===Decompose Application ===

Once the application architecture is understood then decompose it further, to identify the features and modules with a security impact that need to be evaluated. For example, when investigating the authentication module, it is necessary to understand how data enters the module, how the module validates and processes the data, where the data flows, how the data is stored, and what fundamental decisions and assumptions are made by the module.

===Identify Threats ===

It is impossible to write down unknown threats, but it is likewise unlikely that new malware will be created to exploit new vulnerabilities within custom systems. Therefore, concentrate on known risks, which can be easily demonstrated using tools or techniques from Bugtraq .

Microsoft suggests two different approaches for writing up threats. One is a threat graph, as shown in Figure 2, and the other is a structured list, as shown in Figure 3.

[[Image:Threat_Graph.gif|Figure 2: Threat Graph]]

Typically, a threat graph imparts more information quickly but it takes longer to construct, while a structured list is easier to create but it will take longer for the threat impacts to become obvious.

# Attacker may be able to read other user’s messages
# User may not have logged off on a shared PC
# Data validation may allow SQL injection
# Implement data validation
# Authorization may fail, allowing unauthorized access
# Implement authorization checks
# Browser cache may contain contents of message
# Implement anti-caching directive in HTTP headers
# If eavesdropping risk is high, use SSL

Note that it takes a motivated attacker to exploit a threat; they generally want something from your application or to obviate controls. To understand the relevant threats, use the following categories to understand who might attack the application:

* '''Accidental Discovery:''' An ordinary user stumbles across a functional mistake in your application, just using a web browser, and gains access to privileged information or functionality.

* '''Automated Malware:''' Programs or scripts, which are searching for known vulnerabilities, and then report them back to a central collection site.

* '''The Curious Attacker:''' a security researcher or ordinary user, who notices something wrong with the application, and decides to pursue further.

* '''Script Kiddies:''' Common renegades, seeking to compromise or deface applications for collateral gain, notoriety, or a political agenda, perhaps using the attack categories described in the ''OWASP Web Application Penetration Checklist.''

* '''The Motivated Attacker:''' Potentially, a disgruntled staff member with inside knowledge or a paid professional attacker.

* '''Organized Crime:''' Criminals seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.

It is vital to understand the level of attacker you are defending against. For example, a motivated attacker, who understands your internal processes is often more dangerous than script kiddies.

===STRIDE ===

STRIDE is a methodology for identifying known threats. The STRIDE acronym is formed from the first letter of each of the following categories.

'''''Spoofing Identity'''''

“Identity spoofing” is a key risk for applications that have many users but provide a single execution context at the application and database level. In particular, users should not be able to become any other user or assume the attributes of another user.

'''''Tampering with Data'''''

Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, which are obtainable only from within the application itself. The application should also carefully check data received from the user and validate that it is sane and applicable before storing or using it.

'''''Repudiation'''''

Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, “But I didn’t transfer any money to this external account!”, and you cannot track his/her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.

Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the application should run with the user’s privileges, not more, but this may not be possible with many off-the-shelf application frameworks.

'''''Information Disclosure'''''

Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Also, consider if the user’s web browser may leak information. Some web browsers may ignore the no caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser, just in case it leaks or leaves information behind, which can be used by an attacker to learn details about the application, the user, or to potentially become that user.

Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should not be relied on to secure sensitive information or to provide adequate personal privacy safeguards.

'''''Denial of Service'''''

Application designers should be aware that their applications may be subject to a denial of service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users, and not available to anonymous users.

For applications that do not have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, to avoid exposing large files or unique links per user, in order to prevent simple denial of service attacks.

'''''Elevation of Privilege'''''

If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one. In particular, simply not displaying privileged role links is insufficient. Instead, all actions should be gated through an authorization matrix, to ensure that only the permitted roles can access privileged functionality.

===DREAD ===

The DREAD acronym is formed from the first letter of each category below.

DREAD modeling influences the thinking behind setting the risk rating, and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.

'''Risk_DREAD''' = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk.

Here are some examples of how to quantify the DREAD categories.

'''''Damage Potential'''''

* If a threat exploit occurs, how much damage will be caused?
**0 = Nothing
**5 = Individual user data is compromised or affected.
**10 = Complete system or data destruction

'''''Reproducibility'''''

* How easy is it to reproduce the threat exploit?
**0 = Very hard or impossible, even for administrators of the application.
**5 = One or two steps required, may need to be an authorized user.
**10 = Just a web browser and the address bar is sufficient, without authentication.

'''''Exploitability'''''

* What is needed to exploit this threat?
**0 = Advanced programming and networking knowledge, with custom or advanced attack tools.
**5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools.
**10 = Just a web browser

'''''Affected Users'''''

* How many users will be affected?
**0 = None
**5 = Some users, but not all
**10 = All users

'''''Discoverability'''''

* How easy is it to discover this threat?
**0 = Very hard to impossible; requires source code or administrative access.
**5 = Can figure it out by guessing or by monitoring network traces.
**9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
**10 = The information is visible in the web browser address bar or in a form.

'''Note:''' When performing a security review of an existing application, “Discoverability” will often be set to 10 by convention, as it is assumed the threat issues will be discovered.

==Alternative Threat Modeling Systems==
OWASP recognizes that the adoption of the Microsoft modeling process may not fit all organizations. If STRIDE and DREAD are unacceptable for some reason, we recommend that your organization “dry run” the other threat risk models discussed against an existing application or design. This will allow you to determine which approach works best for you, and to adopt the most appropriate threat modeling tools for your organization.

'''In summary, performing threat modeling provides a far greater return than most any other control in this Guide. Therefore, make threat risk modeling an early priority in your application design process.'''

==Trike==
Trike is a threat modeling framework with similarities to the Microsoft threat modeling processes. However, Trike differs because it uses a risk based approach with distinct implementation, threat, and risk models, instead of using the STRIDE/DREAD aggregated threat model (attacks, threats, and weaknesses).
From the Trike paper, Trike’s goals are:
* With assistance from the system stakeholders, to ensure that the risk this system entails to each asset is acceptable to all stakeholders.
* Be able to tell whether we have done this.
* Communicate what we’ve done and its effects to the stakeholders.
* Empower stakeholders to understand and reduce the risks to them and other stakeholders implied by their actions within their domains.
For more information on Trike, please see Section 6.9, reference 8.
==AS/NZS 4360:2004 Risk Management==
The Australian/New Zealand Standard AS/NZS 4360, first issued in 1999, and revised in 2004, is the world’s first formal standard for documenting and managing risk and is still one of the few formal standards for managing it.
The standard’s approach is simple (it’s only 28 pages long), flexible, and iterative. Furthermore, it does not lock organizations into a particular risk management methodology, provided the methodology fulfils the AS/NZS 4360 five steps. It also provides several sets of risk tables as examples, and allows organizations to freely develop and adopt their own.

'''The five steps of the AS/NZS 4360 process are:'''
* '''Establish Context:''' Establish the risk domain, i.e., which assets/systems are important?
* '''Identify the Risks:''' Within the risk domain, what specific risks are apparent?
* '''Analyze the Risks:''' Look at the risks and determine if there are any supporting controls in place.
* '''Evaluate the Risks:''' Determine the residual risk.
* '''Treat the Risks:''' Describe the method to treat the risks so that risks selected by the business will be mitigated.
AS/NZS 4360 assumes that risk will be managed by an '''''operational risk group''''', and that the organization has adequate skills and risk management resources in house to identify, analyze, and treat the risks.

'''The advantages of AS/NZS 4360:'''
* AS/NZS 4360 works well as a risk management methodology for organizations requiring Sarbanes-Oxley compliance.
* AS/NZS 4360 works well for organizations that prefer to manage risks in a traditional way, such as just using likelihood and consequence to determine an overall risk.
* AS/NZS 4360 is familiar to most risk managers worldwide, and your organization may already have implemented an AS/NZS 4360 compatible approach.
* You are an Australian organization, and may be required to use it if you are audited on a regular basis, or to justify why you aren’t using it. Luckily, the STRIDE/DREAD model discussed earlier is AS/NZS 4360 compatible.

'''The limitations of AS/NZS 4360:'''
* The AS/NZS 4360 approach works best for business or systemic risks than for technical risks.
* AS/NZS 4360 does not define the methodology to perform a structured threat risk modeling exercise.
* As AS/NZS 4360 is a generic framework for managing risk, it does not provide any structured method to enumerate web application security risks.
Although AS/NZS 4360 may be used to rank risks for security reviews, the lack of structured methods of enumerating threats for web applications makes it less desirable than other methodologies described earlier.

==CVSS==
The US Department of Homeland Security (DHS) established the NIAC Vulnerability Disclosure Working Group, which incorporates input from Cisco Systems, Symantec, ISS, Qualys, Microsoft, CERT/CC, and eBay. One of the group’s outputs is the Common '''''Vulnerability Scoring System (CVSS).'''''

'''The advantages of CVSS:'''
* You have just received notification from a security researcher or other source that your product has vulnerability, and you wish to ensure that it has an accurate and normalized severity rating, so as to alert your customers to the appropriate level of action required when you release the patch.
* You are a security researcher, and have found several threat exploits within an application. You would like to use the CVSS ranking system to produce reliable risk rankings, to ensure that the ISV will take the exploits seriously as indicated by their rating.
* CVSS has been recommended by the working group for use by US Government departments. However, it is unclear if it will become policy or be widely adopted at the time of this writing.

'''The limitations of CVSS:'''
* CVSS does not find or reduce the attack surface area (i.e. design flaws), or help enumerate risks within any arbitrary piece of code, as it is just a scoring system, not a modeling methodology.
* CVSS is more complex than STRIDE/DREAD, as it aims to calculate the risk of announced vulnerabilities as applied to deployed software and environmental factors.
* The CVSS risk ranking is complex – a spreadsheet is required to calculate the risk components as the assumption behind CVSS is that a specific vulnerability has been identified and announced, or a worm or Trojan has been released targeting a small number of attack vectors.
* The overhead of calculating the CVSS risk ranking is quite high if applied to a thorough code review, which may have 250 or more threats to rank.

==OCTAVE==
OCTAVE is a heavyweight risk methodology approach originating from Carnegie Mellon University’s Software Engineering Institute (SEI) in collaboration with CERT. OCTAVE focuses on organizational risk, not technical risk.
OCTAVE comes in two versions: Full OCTAVE, for large organizations, and OCTAVE-S for small organizations, both of which have specific catalogs of practices, profiles, and worksheets to document the modeling outcomes.

'''OCTAVE is popular with many sites and is useful when:'''
* Implementing an organizational culture of risk management and controls becomes necessary.
* Documenting and measuring business risk becomes timely.
* Documenting and measuring the overall IT security risk, particularly as it relates to the corporate IT risk management, becomes necessary.
* When documenting risks surrounding complete systems becomes necessary.
* To accommodate a fundamental reorganization, such as when an organization does not have a working risk methodology in place, and requires a robust risk management framework to be put in place.

'''The limitations of OCTAVE are:'''
* OCTAVE is incompatible with AS/NZS 4360, as it mandates Likelihood = 1 (i.e., It assumes a threat will always occur) and this is inappropriate for many organizations. OCTAVE-S makes the inclusion of this probability optional, but this is not part of the more comprehensive OCTAVE standard.
* Consisting of 18 volumes, OCTAVE is large and complex, with many worksheets and practices to implement.
* It does not provide a list of “out of the box” practices for assessing and mitigating web application security risks.
Because of these issues, OWASP does not anticipate that OCTAVE will be used at large by application designers or developers, because it fails to take threat risk modeling into consideration, which is useful during all stages of development, by all participants, to reduce the overall risk of an application becoming vulnerable to attack.

==Conclusion==
In this chapter, we have touched on the basic principles of threat risk modeling, risk management, and web application security. Applications that leverage the underlying intent of these principles will be more secure than their counterparts, which will only be minimally compliant just by including specific controls.
==Further Reading==
* Threat Analysis & Modeling v2.0, © Microsoft Corporation, 2006,
http://www.microsoft.com/downloads/details.aspx?familyid=334AD466-8B53-4440-8FF0-6AC8142D9198&displaylang=en

* Threat Modeling Web Applications, J.D. Meier, Alex Mackman, Blaine Wastell, © Microsoft Corporation, May 2005,

http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx?pull=/library/en-us/dnpag2/html/tmwa.asp.

* Improving Web Application Security: Threats and Countermeasures, J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, © Microsoft Corporation, June 2003,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/ThreatCounter.asp.

* Threat Modeling, Frank Swiderski and Window Snyder, Microsoft Press, June 2004, ISBM 0-7356-1991-3 or

http://www.microsoft.com/downloads/details.aspx?FamilyID=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en.

* Writing Secure Code, 2nd Edition, Howard and LeBlanc, pp 69 – 124, Microsoft Press, 2003, ISBN 0-7356-1722-8.

* Improving Web Application Security: Threats and Countermeasures, Meier et al, Microsoft Press, 2003.

* The STRIDE Threat Model, © Microsoft Corporation, 2005,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csvr2002/htm/cs_se_securecode_zlsj.asp

* The DREAD Threat Model, © Microsoft Corporation, 2005.

* A Conceptual Model for Threat Modeling Applications, Saitta, Larcom, and Michael Eddington, July 2005, http://dymaxion.org/trike/ or

http://dymaxion.org/trike/Trike_v1_Methodology_Document-draft.pdf.

* AS/NZS 4360:2004 Risk Management, Standards Australia and Standards New Zealand,

http://www.standards.co.nz/web-shop/?action=viewSearchProduct&mod=catalog&pid=4360:2004(AS|NZS).

* CVSS, U.S. Department of Homeland Security library, February 2005,

http://www.dhs.gov/interweb/assetlibrary/NIAC_CyberVulnerabilitiesPaper_Feb05.pdf.

* OCTAVE, CERT library, http://www.cert.org/octave/.

==Reference==
[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Threat]]

Guide Frontispiece

2006-07-25T15:20:25Z

Scovetta: Sorted by last name

'''A Guide to Building Secure Web Applications and Web Services'''

2.1 (DRAFT 3)
February 2006
OWASP Foundation

[[Guide Table of Contents]]
__TOC__
==Dedication ==
To my fellow procrastinators and TiVo addicts, this book proves that given enough “tomorrows,” anything is possible. --Andrew van der Stock

==Copyright and license ==
© 2001 – 2006 OWASP Foundation.
The Guide is licensed under the Free Documentation License, a copy of which is found in the Appendix. PERMISSION IS GRANTED TO COPY, DISTRIBUTE, AND/OR MODIFY THIS DOCUMENT PROVIDED THIS COPYRIGHT NOTICE AND ATTRIBUTION TO OWASP IS RETAINED.
==Editors ==
The Guide has had several editors over various editions, all of whom have contributed immensely as authors, project managers, and editors over the lengthy period of the Guide’s gestation.
Guide 2.x series editors:

Andrew van der Stock
Adrian Wiesmann

==Authors and Reviewers ==
The Guide would not be where it is today without the generous gift of volunteer time and effort from many individuals. The following people helped develop Guide 2.x:

{| border="0"
| valign="top" |
*Ernesto Arroyo
*José Pedro Arroyo
*Derek Browne
*Izhar By-Gad
*Daniel Cornell
*Martin Eizner
*David Endler
*Raoul Endres
*Brian Greidanus
*Dennis Groves
*Darrel Grundy
| valign="top" |
*Robert Hansen
*William Hau
*Michael Howard
*Sverre Huseby
*Abraham Kang
*Eoin Keary
*Amit Klein
*Neal Krawetz
*Erik Lee
*Frank Lemmon
*Hal Lockhart
| valign="top" |
*Gene McKenna
*Kevin McLaughlin
*Roy McNamara
*K.K. Mookhey
*Richard Parke
*Denis Pilipchuk
*Jeremy Poteet
*Michael Scovetta
*Mikael Simonsson
*Tim Smith
*Ray Stirbei
| valign="top" |
*Steve Taylor
*Christopher Todd
*Nigel Tranter
*Andrew van der Stock
*Adrian Wiesmann
|}

==Revision History ==

{| border=1
|| '''Date''' || '''Version''' || '''Pages''' || '''Notes'''
|-
|| July 26, 2005 || 2.0 Blackhat Edition || 280 pages || Andrew van der Stock, Guide Lead
|-
|| July 27, 2005 || 2.0.1 Blackhat Edition++ || 293 pages || Cryptography chapter review
from Michael Howard incorporated
|-
|| September 12, 2005 || 2.1 DRAFT 1 || X pages || Changes from many sources
New SQA chapter from Frank Lemmon
|-
|| January 2006 || 2.1 DRAFT 2 || X pages || Changes from Bill Pollock
New chapters from Erick Lee
New revisions from Dan Cornell
|-
|| February 2006 || 2.1 DRAFT 3 || X pages || Ajax chapter
Many chapters back from reviewers
|-
|}

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Guide:Frontispiece

2006-06-14T17:02:57Z

Scovetta: /* Dedication */

A Guide to Building Secure Web Applications and
Web Services

2.1 (DRAFT 3)
February 2006

OWASP Foundation

=Frontispiece =
==Dedication ==
''To my fellow procrastinators and TiVo addicts, this book proves that given enough "tomorrows", anything is possible.'' -- Andrew van der Stock

==Copyright and license ==
© 2001 – 2006 OWASP Foundation.
The Guide is licensed under the Free Documentation License, a copy of which is found in the Appendix. PERMISSION IS GRANTED TO COPY, DISTRIBUTE, AND/OR MODIFY THIS DOCUMENT PROVIDED THIS COPYRIGHT NOTICE AND ATTRIBUTION TO OWASP IS RETAINED.
==Editors ==
The Guide has had several editors over various editions, all of whom have contributed immensely as authors, project managers, and editors over the lengthy period of the Guide’s gestation.
Guide 2.x series editors:

Andrew van der Stock
Adrian Wiesmann

==Authors and Reviewers ==
The Guide would not be where it is today without the generous gift of volunteer time and effort from many individuals. The following people helped develop Guide 2.x:

{| cellspacing="5" valign="top"
|
* Abraham Kang
* Adrian Wiesmann
* Amit Klein
* Andrew van der Stock
* Brian Greidanus
* Christopher Todd
* Darrel Grundy
* Daniel Cornell
* David Endler
* Denis Pilipchuk
|
* Dennis Groves
* Derek Browne
* Eoin Keary
* Erik Lee
* Ernesto Arroyo
* Frank Lemmon
* Gene McKenna
* Hal Lockhart
* Izhar By-Gad
* Jeremy Poteet
|
* José Pedro Arroyo
* K.K. Mookhey
* Kevin McLaughlin
* Martin Eizner
* Michael Howard
* Michael Scovetta
* Mikael Simonsson
* Neal Krawetz
* Nigel Tranter
* Raoul Endres
| valign="top" |
* Ray Stirbei
* Richard Parke
* Robert Hansen
* Roy McNamara
* Steve Taylor
* Sverre Huseby
* Tim Smith
* William Hau
|}

==Revision History ==

'''Date''' '''Version''' '''Pages''' '''Notes'''
July 26, 2005 2.0 Blackhat Edition 280 pages Andrew van der Stock, Guide Lead
July 27, 2005 2.0.1 Blackhat Edition++ 293 pages Cryptography chapter review
from Michael Howard incorporated
September 12, 2005 2.1 DRAFT 1 X pages Changes from many sources
New SQA chapter from Frank Lemmon
January 2006 2.1 DRAFT 2 X pages Changes from Bill Pollock
New chapters from Erick Lee
New revisions from Dan Cornell
February 2006 2.1 DRAFT 3 X pages Ajax chapter
Many chapters back from reviewers
{| border=1
|| '''Date''' || '''Version''' || '''Pages''' || '''Notes'''
|-
|| July 26, 2005 || 2.0 Blackhat Edition || 280 pages || Andrew van der Stock, Guide Lead
|-
|| July 27, 2005 || 2.0.1 Blackhat Edition++ || 293 pages || Cryptography chapter review
from Michael Howard incorporated
|-
|| September 12, 2005 || 2.1 DRAFT 1 || X pages || Changes from many sources
New SQA chapter from Frank Lemmon
|-
|| January 2006 || 2.1 DRAFT 2 || X pages || Changes from Bill Pollock
New chapters from Erick Lee
New revisions from Dan Cornell
|-
|| February 2006 || 2.1 DRAFT 3 || X pages || Ajax chapter
Many chapters back from reviewers
|-
|}

=Table of Contents =

[[Guide:Table of Contents]]

Guide:Frontispiece

2006-06-14T16:55:57Z

Scovetta: Reformatted authors and reviewers section

A Guide to Building Secure Web Applications and
Web Services

2.1 (DRAFT 3)
February 2006

OWASP Foundation

=Frontispiece =
==Dedication ==
To my fellow procrastinators and TiVo addicts, this book proves that given enough “tomorrows,” anything is possible.
Andrew van der Stock
==Copyright and license ==
© 2001 – 2006 OWASP Foundation.
The Guide is licensed under the Free Documentation License, a copy of which is found in the Appendix. PERMISSION IS GRANTED TO COPY, DISTRIBUTE, AND/OR MODIFY THIS DOCUMENT PROVIDED THIS COPYRIGHT NOTICE AND ATTRIBUTION TO OWASP IS RETAINED.
==Editors ==
The Guide has had several editors over various editions, all of whom have contributed immensely as authors, project managers, and editors over the lengthy period of the Guide’s gestation.
Guide 2.x series editors:

Andrew van der Stock
Adrian Wiesmann

==Authors and Reviewers ==
The Guide would not be where it is today without the generous gift of volunteer time and effort from many individuals. The following people helped develop Guide 2.x:

{| cellspacing="5" valign="top"
|
* Abraham Kang
* Adrian Wiesmann
* Amit Klein
* Andrew van der Stock
* Brian Greidanus
* Christopher Todd
* Darrel Grundy
* Daniel Cornell
* David Endler
* Denis Pilipchuk
|
* Dennis Groves
* Derek Browne
* Eoin Keary
* Erik Lee
* Ernesto Arroyo
* Frank Lemmon
* Gene McKenna
* Hal Lockhart
* Izhar By-Gad
* Jeremy Poteet
|
* José Pedro Arroyo
* K.K. Mookhey
* Kevin McLaughlin
* Martin Eizner
* Michael Howard
* Michael Scovetta
* Mikael Simonsson
* Neal Krawetz
* Nigel Tranter
* Raoul Endres
| valign="top" |
* Ray Stirbei
* Richard Parke
* Robert Hansen
* Roy McNamara
* Steve Taylor
* Sverre Huseby
* Tim Smith
* William Hau
|}

==Revision History ==

'''Date''' '''Version''' '''Pages''' '''Notes'''
July 26, 2005 2.0 Blackhat Edition 280 pages Andrew van der Stock, Guide Lead
July 27, 2005 2.0.1 Blackhat Edition++ 293 pages Cryptography chapter review
from Michael Howard incorporated
September 12, 2005 2.1 DRAFT 1 X pages Changes from many sources
New SQA chapter from Frank Lemmon
January 2006 2.1 DRAFT 2 X pages Changes from Bill Pollock
New chapters from Erick Lee
New revisions from Dan Cornell
February 2006 2.1 DRAFT 3 X pages Ajax chapter
Many chapters back from reviewers
{| border=1
|| '''Date''' || '''Version''' || '''Pages''' || '''Notes'''
|-
|| July 26, 2005 || 2.0 Blackhat Edition || 280 pages || Andrew van der Stock, Guide Lead
|-
|| July 27, 2005 || 2.0.1 Blackhat Edition++ || 293 pages || Cryptography chapter review
from Michael Howard incorporated
|-
|| September 12, 2005 || 2.1 DRAFT 1 || X pages || Changes from many sources
New SQA chapter from Frank Lemmon
|-
|| January 2006 || 2.1 DRAFT 2 || X pages || Changes from Bill Pollock
New chapters from Erick Lee
New revisions from Dan Cornell
|-
|| February 2006 || 2.1 DRAFT 3 || X pages || Ajax chapter
Many chapters back from reviewers
|-
|}

=Table of Contents =

[[Guide:Table of Contents]]

What are web applications?

2006-06-08T11:05:01Z

Scovetta: Added reason why they are written in c/c++

[[Guide Table of Contents]]

__TOC__

In the early days of the web, web sites consisted of static pages, which severely limited interaction with the user. In the early 1990’s, this limitation was removed when web servers were modified to allow communication with server-side custom scripts. No longer were applications just static brochure-ware, edited only by those who knew the arcane mysteries of HTML; with this single change, normal users could interact with the application for the first time.

[[Image:What are web applications.JPG]]

This is a huge and fundamental step towards the web as we know it today. Without interactivity, there would be no e-commerce (such as Amazon), no web e-mail (Hotmail or GMail), no Internet Banking, no blogs, no online share trading, and no web forums or communities like Orkut or Friendster. The static Internet would have been vastly different to today.

The trend towards increased interactivity has continued apace, with the advent of “Web 2.0”, a term that encompasses many existing technologies, but heavily features highly interactive, user centric, web-aware applications.

==Technologies ==

Initially, it was quite difficult to write sophisticated applications. The first generation web applications were primitive, usually little more than form submissions and search applications. Even these basic applications took quite a great deal of skill to craft.

Over time, the arcane knowledge required to write applications has been reduced. Today, it is relatively easy to write sophisticated applications with modern platforms and simpler languages, like PHP or VB.NET.

However, this push to make applications as easy to write as possible has a downside – many entry-level programmers are completely unaware of the security implications of their code. This is discussed further in the “Security Principles” chapter.

Let’s look at the various generations of web application technology.

==First generation – CGI ==

Common Gateway Interface (CGI) reigned supreme from approximately 1993 through to the late 1990’s when scripting languages took over in a big way.

CGI works by encapsulating user supplied data in environment variables. These are inherited by the custom written scripts or programs, usually developed in Perl or C. The custom programs process the supplied user data, and send fully formed HTML to the “standard out” (stdout), which is captured by the web server and passed back to the user.

Examples of complex CGI include Hotmail, which was essentially Perl scripts running on top of FreeBSD boxes and Slashdot, again a large Perl script running under Linux

As few sites today write new CGI applications, the techniques to secure CGI applications are not discussed within the Guide. However, many of the techniques discussed can be used with few or no changes.

==Filters ==

Filters can be used to control access to a web site, implement a different web application framework (such as Perl, PHP, or ASP), or to provide a security check. Filters are generally written in C/C++ because they usually integrate with the web/app server at a low-level.

Because filters live within the execution context of the web server itself, they can be high performance. Typical examples of a filter interface include Apache web server modules, SunONE’s NSAPI, and Microsoft’s ISAPI. Because filters are rarely used specialist interfaces that can directly affect the availability of the web server, they are not considered further.

==Scripting ==

CGI’s lack of session management and authorization controls hampered the development of commercially useful web applications.

Web developers turned to scripting languages, such as JavaScript and PHP to solve these problems. Scripting languages run script code within the web server, and, because the scripts are not compiled, they are more quickly developed and implemented.

I’m not sure if that’s what you mean above but please clarify.

Unlike low-level languages, scripting languages rarely suffer from buffer overflows or resource leaks. Thus, programmers who use them can avoid two of the most common security issues. However, they do have their disadvantages:

* Most scripting languages aren’t strongly typed and do not promote good programming practices

* Scripting languages are generally slower than their compiled counterparts (sometimes as much as 100 times slower)

* Scripts often lead to unmanageable code bases that perform poorly as their size grows

* It’s difficult (but not impossible) to write multi-tier large scale applications in scripting languages, because often the presentation, application and data tiers reside on the same machine, thus limiting scalability and security

* Most scripting languages do not natively support remote method or web service calls, which makes it difficult to communicate with application servers and external web services.

Despite their disadvantages, many large and useful applications have been written with scripting languages, such as eGroupWare (egroupware.org), which is written in PHP. Too, many older Internet banking sites are written in ASP.

Scripting frameworks include ASP, Perl, Cold Fusion, and PHP. However, many of these would be considered interpreted hybrids now, particularly later versions of PHP and Cold Fusion, which pre-tokenize and optimize scripts.

==Web application frameworks – J2EE and ASP.NET ==

As scripting languages reached the boundaries of performance and scalability, many larger vendors jumped on Sun’s J2EE web development platform. There are many J2EE implementations, including Tomcat from the Apache Foundation and _______.

J2EE:

* Uses the Java language to produce applications which run nearly as quickly as C++ based ones, and that do not easily suffer from buffer overflows and memory leaks

* Allowed large distributed applications to run acceptably for the first time

* Possesses good session and authorization controls

* Enabled relatively transparent multi-tier applications via various remote component invocation mechanisms, and

* Is strongly typed to prevent many common security and programming issues before the program even runs

J2EE’s downside is that it has a steep learning curve which makes it difficult for web designers and entry-level programmers to use it to write applications. While certain graphical development tools make it somewhat easier to program with J2EE, a scripting language like PHP is still much easier to use.

When Microsoft updated their ASP technology to ASP.NET. which mimics the J2EE framework in many ways, they offered several improvements on the development process. For example, .NET:

* Makes it easy for entry level programmers and web designers to whip up smaller applications

* Allows large distributed applications

* Offers good session and authorization controls

* Allows programmers to use their favorite language, which is compiled to native code for excellent performance (near C++ speeds), along with buffer overflow and resource garbage collection

* Permits transparent communication with remote and external components

* Is strongly typed to prevent many common security and programming issues before the program even runs

The choice of J2EE or ASP.NET frameworks is largely dependent upon platform. There is little reason to choose one over the other from a security perspective.

Applications targeting J2EE theoretically can run with few (if any) changes between any of the major vendors and on many platforms from Linux, to AIX, MacOS X, or Windows. (While in practice, some tweaking is required, complete re-writes are not required. )

# ''ASP.Net is primarily available for Microsoft Windows. The Mono project (http://www.go-mono.com/) can run ASP.NET applications on many platforms including Solaris, Netware, and Linux. ''

==Small to medium scale applications ==

Most applications are either small or medium scale. The usual architecture is a simple linear procedural script. This is the most common form of coding for ASP, Cold Fusion and PHP scripts, but rarer (but not impossible) for ASP.NET and J2EE applications.

The reason for this architecture is that it is easy to write, and few skills are required to maintain the code. For smaller applications, any perceived performance benefit from moving to a more scalable architecture will never be recovered in the runtime for those applications. For example, if it takes an additional three weeks of developer time to re-factor the scripts into an MVC approach, the three weeks will never be recovered (or noticed by end users) from the improvements in scalability.

It is typical to find many security issues in such applications, including dynamic database queries constructed from insufficiently validated data input, poor error handling and weak authorization controls.

This Guide provides advice throughout to help improve the security of these applications.

==Large scale applications ==

Larger applications need a different architecture to that of a simple survey or feedback form. As applications get larger, it becomes ever more difficult to implement and maintain features and to keep scalability high. Using scalable application architectures becomes a necessity rather than a luxury when an application needs more than about three database tables or presents more than approximately 20 - 50 functions to a user.

Scalable application architecture is often divided into tiers, and if design patterns are used, often broken down into re-usable chunks using specific guidelines to enforce modularity, interface requirements and object re-use. Breaking the application into tiers allows the application to be distributed to various servers, thus improving the scalability of the application at the expense of complexity.

One of the most common web application architectures is model-view-controller (MVC), which implements the Smalltalk 80 application architecture. MVC is typical of most Apache Foundation Jakarta Struts J2EE applications, and the code-behinds of ASP.NET can be considered a partial implementation of this approach. For PHP, the WACT project (http://wact.sourceforge.net) aims to implement the MVC paradigm in a PHP friendly fashion.

==View ==

The front-end rendering code, often called the presentation tier, should aim to produce the HTML output for the user with little to no application logic.

As many applications will be internationalized (i.e. contain no localized strings or culture information in the presentation layer), they must use calls into the model (application logic) to obtain the data required to render useful information to the user in their preferred language and culture, script direction, and units.

All user input is directed back to controllers in the application logic.

==Controller ==

The controller (or application logic) takes input from the users and gates it through various workflows that call on the application’s model objects to retrieve, process, or store the data.

Well written controllers centrally server-side validate input data against common security issues before passing the data to the model for processing, and ensure that output is safe or in a ready form for safe output by the view code.

As the application is likely to be internationalized and accessible, the data needs to be in the local language and culture. For example, dates cannot only be in different orders, but an entirely different calendar could be in use. Applications need to be flexible about presenting and storing data. Simply displaying “7/4/2005” is ambiguous to anyone outside a few countries.

==Model ==

Models encapsulate functionality, such as “Account” or “User”. A good model should be transparent to the caller, and provide a method to deal with high-level business processes rather than a thin shim to the data store. For example, a good model will allow pseudo code such as this to exist in the controller:

<pre>
oAccount->TransferFunds(fromAcct, ToAcct, Amount)
</pre>

rather than writing it such as this:

<pre>
if ( oAccount->isMyAcct(fromAcct) &&
amount < oAccount->getMaxTransferLimit() &&
oAccount->getBalance(fromAcct) > amount &&
oAccount->ToAccountExists(ToAcct) )
then
if oAccount->withdraw(fromAcct, Amount) == OK
then oAccount->deposit(ToAcct, Amount)
end if
end if
</pre>

The idea is to encapsulate the actual dirty work into the model code, rather than exposing primitives. If the controller and model are on different machines, the performance difference will be staggering, so it is important for the model to be useful at a high level.

The model is responsible for checking data against business rules, and any residual risks unique to the data store in use. For example, if a model stores data in a flat file, the code needs to check for OS injection commands if the flat files are named by the user. If the model stores data in an interpreted language, such as SQL, then the model is responsible for preventing SQL injection. If it uses a message queue interface to a mainframe, the message queue data format (typically XML) needs to be well formed and compliant with a DTD.

The contract between the controller and the model needs to be carefully considered to ensure that data is strongly typed, with reasonable structure (syntax), and appropriate length, whilst allowing flexibility to allow for internationalization and future needs.

Calls by the model to the data store should be through the most secure method possible. Often the weakest possibility is dynamic queries, where a string is built up from unverified user input. This leads directly to SQL injection and is frowned upon. For more information, see the Interpreter Injections chapter.

The best performance and highest security is often obtained through parameterized stored procedures, followed by parameterized queries (also known as prepared statements) with strong typing of the parameters and schema. The major reason for using stored procedures is to minimize network traffic for a multi-stage transaction or to remove security sensitive information from traversing the network.

Stored procedures are not always a good idea – they tie you to a particular database vendor and many implementations are not fast for numeric computation. If you use the 80/20 rule for optimization and move the slow and high-risk transactions to stored procedures, the wins can be worthwhile from a security and performance perspective.

==Conclusion ==

Web applications can be written in many different ways, and in many different languages. Although the Guide concentrates upon three common choices for its examples (PHP, J2EE and ASP.NET), the Guide can be used with any web application technology.

[[Guide Table of Contents]]

[[Category:OWASP_Guide_Project]]

What are web applications?

2006-06-08T11:01:43Z

Scovetta: Reformatted code

[[Guide Table of Contents]]

__TOC__

In the early days of the web, web sites consisted of static pages, which severely limited interaction with the user. In the early 1990’s, this limitation was removed when web servers were modified to allow communication with server-side custom scripts. No longer were applications just static brochure-ware, edited only by those who knew the arcane mysteries of HTML; with this single change, normal users could interact with the application for the first time.

[[Image:What are web applications.JPG]]

This is a huge and fundamental step towards the web as we know it today. Without interactivity, there would be no e-commerce (such as Amazon), no web e-mail (Hotmail or GMail), no Internet Banking, no blogs, no online share trading, and no web forums or communities like Orkut or Friendster. The static Internet would have been vastly different to today.

The trend towards increased interactivity has continued apace, with the advent of “Web 2.0”, a term that encompasses many existing technologies, but heavily features highly interactive, user centric, web-aware applications.

==Technologies ==

Initially, it was quite difficult to write sophisticated applications. The first generation web applications were primitive, usually little more than form submissions and search applications. Even these basic applications took quite a great deal of skill to craft.

Over time, the arcane knowledge required to write applications has been reduced. Today, it is relatively easy to write sophisticated applications with modern platforms and simpler languages, like PHP or VB.NET.

However, this push to make applications as easy to write as possible has a downside – many entry-level programmers are completely unaware of the security implications of their code. This is discussed further in the “Security Principles” chapter.

Let’s look at the various generations of web application technology.

==First generation – CGI ==

Common Gateway Interface (CGI) reigned supreme from approximately 1993 through to the late 1990’s when scripting languages took over in a big way.

CGI works by encapsulating user supplied data in environment variables. These are inherited by the custom written scripts or programs, usually developed in Perl or C. The custom programs process the supplied user data, and send fully formed HTML to the “standard out” (stdout), which is captured by the web server and passed back to the user.

Examples of complex CGI include Hotmail, which was essentially Perl scripts running on top of FreeBSD boxes and Slashdot, again a large Perl script running under Linux

As few sites today write new CGI applications, the techniques to secure CGI applications are not discussed within the Guide. However, many of the techniques discussed can be used with few or no changes.

==Filters ==

Filters can be used to control access to a web site, implement a different web application framework (such as Perl, PHP, or ASP), or to provide a security check. Filters must be written in C or C++ because __________.

Because filters live within the execution context of the web server itself, they can be high performance. Typical examples of a filter interface include Apache web server modules, SunONE’s NSAPI, and Microsoft’s ISAPI. Because filters are rarely used specialist interfaces that can directly affect the availability of the web server, they are not considered further.

==Scripting ==

CGI’s lack of session management and authorization controls hampered the development of commercially useful web applications.

Web developers turned to scripting languages, such as JavaScript and PHP to solve these problems. Scripting languages run script code within the web server, and, because the scripts are not compiled, they are more quickly developed and implemented.

I’m not sure if that’s what you mean above but please clarify.

Unlike low-level languages, scripting languages rarely suffer from buffer overflows or resource leaks. Thus, programmers who use them can avoid two of the most common security issues. However, they do have their disadvantages:

* Most scripting languages aren’t strongly typed and do not promote good programming practices

* Scripting languages are generally slower than their compiled counterparts (sometimes as much as 100 times slower)

* Scripts often lead to unmanageable code bases that perform poorly as their size grows

* It’s difficult (but not impossible) to write multi-tier large scale applications in scripting languages, because often the presentation, application and data tiers reside on the same machine, thus limiting scalability and security

* Most scripting languages do not natively support remote method or web service calls, which makes it difficult to communicate with application servers and external web services.

Despite their disadvantages, many large and useful applications have been written with scripting languages, such as eGroupWare (egroupware.org), which is written in PHP. Too, many older Internet banking sites are written in ASP.

Scripting frameworks include ASP, Perl, Cold Fusion, and PHP. However, many of these would be considered interpreted hybrids now, particularly later versions of PHP and Cold Fusion, which pre-tokenize and optimize scripts.

==Web application frameworks – J2EE and ASP.NET ==

As scripting languages reached the boundaries of performance and scalability, many larger vendors jumped on Sun’s J2EE web development platform. There are many J2EE implementations, including Tomcat from the Apache Foundation and _______.

J2EE:

* Uses the Java language to produce applications which run nearly as quickly as C++ based ones, and that do not easily suffer from buffer overflows and memory leaks

* Allowed large distributed applications to run acceptably for the first time

* Possesses good session and authorization controls

* Enabled relatively transparent multi-tier applications via various remote component invocation mechanisms, and

* Is strongly typed to prevent many common security and programming issues before the program even runs

J2EE’s downside is that it has a steep learning curve which makes it difficult for web designers and entry-level programmers to use it to write applications. While certain graphical development tools make it somewhat easier to program with J2EE, a scripting language like PHP is still much easier to use.

When Microsoft updated their ASP technology to ASP.NET. which mimics the J2EE framework in many ways, they offered several improvements on the development process. For example, .NET:

* Makes it easy for entry level programmers and web designers to whip up smaller applications

* Allows large distributed applications

* Offers good session and authorization controls

* Allows programmers to use their favorite language, which is compiled to native code for excellent performance (near C++ speeds), along with buffer overflow and resource garbage collection

* Permits transparent communication with remote and external components

* Is strongly typed to prevent many common security and programming issues before the program even runs

The choice of J2EE or ASP.NET frameworks is largely dependent upon platform. There is little reason to choose one over the other from a security perspective.

Applications targeting J2EE theoretically can run with few (if any) changes between any of the major vendors and on many platforms from Linux, to AIX, MacOS X, or Windows. (While in practice, some tweaking is required, complete re-writes are not required. )

# ''ASP.Net is primarily available for Microsoft Windows. The Mono project (http://www.go-mono.com/) can run ASP.NET applications on many platforms including Solaris, Netware, and Linux. ''

==Small to medium scale applications ==

Most applications are either small or medium scale. The usual architecture is a simple linear procedural script. This is the most common form of coding for ASP, Cold Fusion and PHP scripts, but rarer (but not impossible) for ASP.NET and J2EE applications.

The reason for this architecture is that it is easy to write, and few skills are required to maintain the code. For smaller applications, any perceived performance benefit from moving to a more scalable architecture will never be recovered in the runtime for those applications. For example, if it takes an additional three weeks of developer time to re-factor the scripts into an MVC approach, the three weeks will never be recovered (or noticed by end users) from the improvements in scalability.

It is typical to find many security issues in such applications, including dynamic database queries constructed from insufficiently validated data input, poor error handling and weak authorization controls.

This Guide provides advice throughout to help improve the security of these applications.

==Large scale applications ==

Larger applications need a different architecture to that of a simple survey or feedback form. As applications get larger, it becomes ever more difficult to implement and maintain features and to keep scalability high. Using scalable application architectures becomes a necessity rather than a luxury when an application needs more than about three database tables or presents more than approximately 20 - 50 functions to a user.

Scalable application architecture is often divided into tiers, and if design patterns are used, often broken down into re-usable chunks using specific guidelines to enforce modularity, interface requirements and object re-use. Breaking the application into tiers allows the application to be distributed to various servers, thus improving the scalability of the application at the expense of complexity.

One of the most common web application architectures is model-view-controller (MVC), which implements the Smalltalk 80 application architecture. MVC is typical of most Apache Foundation Jakarta Struts J2EE applications, and the code-behinds of ASP.NET can be considered a partial implementation of this approach. For PHP, the WACT project (http://wact.sourceforge.net) aims to implement the MVC paradigm in a PHP friendly fashion.

==View ==

The front-end rendering code, often called the presentation tier, should aim to produce the HTML output for the user with little to no application logic.

As many applications will be internationalized (i.e. contain no localized strings or culture information in the presentation layer), they must use calls into the model (application logic) to obtain the data required to render useful information to the user in their preferred language and culture, script direction, and units.

All user input is directed back to controllers in the application logic.

==Controller ==

The controller (or application logic) takes input from the users and gates it through various workflows that call on the application’s model objects to retrieve, process, or store the data.

Well written controllers centrally server-side validate input data against common security issues before passing the data to the model for processing, and ensure that output is safe or in a ready form for safe output by the view code.

As the application is likely to be internationalized and accessible, the data needs to be in the local language and culture. For example, dates cannot only be in different orders, but an entirely different calendar could be in use. Applications need to be flexible about presenting and storing data. Simply displaying “7/4/2005” is ambiguous to anyone outside a few countries.

==Model ==

Models encapsulate functionality, such as “Account” or “User”. A good model should be transparent to the caller, and provide a method to deal with high-level business processes rather than a thin shim to the data store. For example, a good model will allow pseudo code such as this to exist in the controller:

<pre>
oAccount->TransferFunds(fromAcct, ToAcct, Amount)
</pre>

rather than writing it such as this:

<pre>
if ( oAccount->isMyAcct(fromAcct) &&
amount < oAccount->getMaxTransferLimit() &&
oAccount->getBalance(fromAcct) > amount &&
oAccount->ToAccountExists(ToAcct) )
then
if oAccount->withdraw(fromAcct, Amount) == OK
then oAccount->deposit(ToAcct, Amount)
end if
end if
</pre>

The idea is to encapsulate the actual dirty work into the model code, rather than exposing primitives. If the controller and model are on different machines, the performance difference will be staggering, so it is important for the model to be useful at a high level.

The model is responsible for checking data against business rules, and any residual risks unique to the data store in use. For example, if a model stores data in a flat file, the code needs to check for OS injection commands if the flat files are named by the user. If the model stores data in an interpreted language, such as SQL, then the model is responsible for preventing SQL injection. If it uses a message queue interface to a mainframe, the message queue data format (typically XML) needs to be well formed and compliant with a DTD.

The contract between the controller and the model needs to be carefully considered to ensure that data is strongly typed, with reasonable structure (syntax), and appropriate length, whilst allowing flexibility to allow for internationalization and future needs.

Calls by the model to the data store should be through the most secure method possible. Often the weakest possibility is dynamic queries, where a string is built up from unverified user input. This leads directly to SQL injection and is frowned upon. For more information, see the Interpreter Injections chapter.

The best performance and highest security is often obtained through parameterized stored procedures, followed by parameterized queries (also known as prepared statements) with strong typing of the parameters and schema. The major reason for using stored procedures is to minimize network traffic for a multi-stage transaction or to remove security sensitive information from traversing the network.

Stored procedures are not always a good idea – they tie you to a particular database vendor and many implementations are not fast for numeric computation. If you use the 80/20 rule for optimization and move the slow and high-risk transactions to stored procedures, the wins can be worthwhile from a security and performance perspective.

==Conclusion ==

Web applications can be written in many different ways, and in many different languages. Although the Guide concentrates upon three common choices for its examples (PHP, J2EE and ASP.NET), the Guide can be used with any web application technology.

[[Guide Table of Contents]]

[[Category:OWASP_Guide_Project]]

Category talk:OWASP Guide Project

2006-06-07T15:57:03Z

Scovetta: question about official version

Currently in the process of uploading the current draft. Each page discussion has the edit notes as I know them. [[User:Vanderaj|Vanderaj]]

Is the official Guide version the word docs or the wiki now? (I don't want to make updates and have them get replaced) [[User:Scovetta|Scovetta]]

Buffer Overflows

2006-06-07T15:55:03Z

Scovetta: Fixed formatting for code

[[Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components

* Applications create as few buffer overflows as possible

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1

|| * Language/Environment || * Compiled or Interpreted || * Strongly Typed || * Direct Memory Access || * Safe or Unsafe

|-

|| * Java, Java Virtual Machine (JVM) || * Both || * Yes || * No || * Safe

|-

|| * .NET || * Both || * Yes || * No || * Safe

|-

|| * Perl || * Both || * Yes || * No || * Safe

|-

|| * Python - interpreted || * Intepreted || * Yes || * No || * Safe

|-

|| * Ruby || * Interpreted || * Yes || * No || * Safe

|-

|| * C/C++ || * Compiled || * No || * Yes || * Unsafe

|-

|| * Assembly || * Compiled || * No || * Yes || * Unsafe

|-

|| * COBOL || * Compiled || * Yes || * No || * Safe

|-

|}

Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

<pre>
#include <string.h>

void f(char* s) {
char buffer[10];
strcpy(buffer, s);
}

void main(void) {
f("01234567890123456789");
}

[root /tmp]# ./stacktest

Segmentation fault
</pre>

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-execuable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

void main(void) {
char str[100] = scanf("%s");
printf("%s", str);
}
</pre>

This simple program takes input from the user and displays it back on the screen. The string <code>%s</code> means that the other parameter, str, should be displayed as a string. This example is ''not'' vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from Blexim's ''Phrack ''article:

<pre>
#include <stdio.h>
#include <string.h>

void main(int argc, char *argv[]) {
int i = atoi(argv[1]); // input from user
unsigned short s = i; // truncate to a short
char buf[50]; // large buffer

if (s > 10) { // check we're not greater than 10
return;
}

memcpy(buf, argv[2], i); // copy i bytes to the buffer
buf[i] = '\0'; // add a null byte to the buffer
printf("%s\n", buf); // output the buffer contents

return;
}

[root /tmp]# ./inttest 65580 foobar
Segmentation fault
</pre>

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html

* Newsham, Tim, ''Format String Attacks

''http://www.lava.net/~newsham/format-string-attacks.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/phrack/49/P49-14

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://rr.sans.org/code/inside_buffer.php

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/phrack/60/p60-0x0a.txt

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

http://www.immunix.org

* Libsafe

http://www.research.avayalabs.com/project/libsafe

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Buffer Overflows

2006-06-07T15:52:27Z

Scovetta: Fixed formatting for code

[[Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components

* Applications create as few buffer overflows as possible

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1

|| * Language/Environment || * Compiled or Interpreted || * Strongly Typed || * Direct Memory Access || * Safe or Unsafe

|-

|| * Java, Java Virtual Machine (JVM) || * Both || * Yes || * No || * Safe

|-

|| * .NET || * Both || * Yes || * No || * Safe

|-

|| * Perl || * Both || * Yes || * No || * Safe

|-

|| * Python - interpreted || * Intepreted || * Yes || * No || * Safe

|-

|| * Ruby || * Interpreted || * Yes || * No || * Safe

|-

|| * C/C++ || * Compiled || * No || * Yes || * Unsafe

|-

|| * Assembly || * Compiled || * No || * Yes || * Unsafe

|-

|| * COBOL || * Compiled || * Yes || * No || * Safe

|-

|}

Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

<pre>
#include <string.h>

void f(char* s) {
char buffer[10];
strcpy(buffer, s);
}

void main(void) {
f("01234567890123456789");
}

[root /tmp]# ./stacktest

Segmentation fault
</pre>

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-execuable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

void main(void) {
char str[100] = scanf("%s");
printf("%s", str);
}
</pre>

This simple program takes input from the user and displays it back on the screen. The string <code>%s</code> means that the other parameter, str, should be displayed as a string. This example is ''not'' vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from Blexim's ''Phrack ''article:

'' #include <stdio.h>''

'' #include <string.h>''

'' void main(int argc, char *argv[]){''

'' int i = atoi(argv[1]); // input from user''

'' unsigned short s = i; // truncate to a short''

'' char buf[50]; // large buffer''

'' if (s > 10) { // check we're not greater than 10''

'' return;''

'' }''

'' memcpy(buf, argv[2], i); // copy i bytes to the buffer''

'' buf[i] = '\0'; // add a null byte to the buffer''

'' printf("%s\n", buf); // output the buffer contents''

'' return;''

'' } ''

''[root /tmp]# ./inttest 65580 foobar''

''Segmentation fault''

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html

* Newsham, Tim, ''Format String Attacks

''http://www.lava.net/~newsham/format-string-attacks.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/phrack/49/P49-14

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://rr.sans.org/code/inside_buffer.php

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/phrack/60/p60-0x0a.txt

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

http://www.immunix.org

* Libsafe

http://www.research.avayalabs.com/project/libsafe

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Buffer Overflows

2006-06-07T15:51:30Z

Scovetta: Fixed formatting for code

[[Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components

* Applications create as few buffer overflows as possible

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1

|| * Language/Environment || * Compiled or Interpreted || * Strongly Typed || * Direct Memory Access || * Safe or Unsafe

|-

|| * Java, Java Virtual Machine (JVM) || * Both || * Yes || * No || * Safe

|-

|| * .NET || * Both || * Yes || * No || * Safe

|-

|| * Perl || * Both || * Yes || * No || * Safe

|-

|| * Python - interpreted || * Intepreted || * Yes || * No || * Safe

|-

|| * Ruby || * Interpreted || * Yes || * No || * Safe

|-

|| * C/C++ || * Compiled || * No || * Yes || * Unsafe

|-

|| * Assembly || * Compiled || * No || * Yes || * Unsafe

|-

|| * COBOL || * Compiled || * Yes || * No || * Safe

|-

|}

Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

<pre>
#include <string.h>

void f(char* s) {
char buffer[10];
strcpy(buffer, s);
}

void main(void) {
f("01234567890123456789");
}

[root /tmp]# ./stacktest

Segmentation fault
</pre>

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-execuable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

void main(void) {

char str[100] = scanf("%s");

printf("%s", str);

}

This simple program takes input from the user and displays it back on the screen. The string %s means that the other parameter, str, should be displayed as a string. This example is ''not ''vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from Blexim's ''Phrack ''article:

'' #include <stdio.h>''

'' #include <string.h>''

'' void main(int argc, char *argv[]){''

'' int i = atoi(argv[1]); // input from user''

'' unsigned short s = i; // truncate to a short''

'' char buf[50]; // large buffer''

'' if (s > 10) { // check we're not greater than 10''

'' return;''

'' }''

'' memcpy(buf, argv[2], i); // copy i bytes to the buffer''

'' buf[i] = '\0'; // add a null byte to the buffer''

'' printf("%s\n", buf); // output the buffer contents''

'' return;''

'' } ''

''[root /tmp]# ./inttest 65580 foobar''

''Segmentation fault''

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html

* Newsham, Tim, ''Format String Attacks

''http://www.lava.net/~newsham/format-string-attacks.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/phrack/49/P49-14

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://rr.sans.org/code/inside_buffer.php

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/phrack/60/p60-0x0a.txt

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

http://www.immunix.org

* Libsafe

http://www.research.avayalabs.com/project/libsafe

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Buffer Overflows

2006-06-07T15:50:24Z

Scovetta: /* Heap Overflow */

[[Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components

* Applications create as few buffer overflows as possible

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1

|| * Language/Environment || * Compiled or Interpreted || * Strongly Typed || * Direct Memory Access || * Safe or Unsafe

|-

|| * Java, Java Virtual Machine (JVM) || * Both || * Yes || * No || * Safe

|-

|| * .NET || * Both || * Yes || * No || * Safe

|-

|| * Perl || * Both || * Yes || * No || * Safe

|-

|| * Python - interpreted || * Intepreted || * Yes || * No || * Safe

|-

|| * Ruby || * Interpreted || * Yes || * No || * Safe

|-

|| * C/C++ || * Compiled || * No || * Yes || * Unsafe

|-

|| * Assembly || * Compiled || * No || * Yes || * Unsafe

|-

|| * COBOL || * Compiled || * Yes || * No || * Safe

|-

|}

Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

#include <string.h>

void f(char* s) {

char buffer[10];

strcpy(buffer, s);

}

void main(void) {

f("01234567890123456789");

}

[root /tmp]# ./stacktest

Segmentation fault

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-execuable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

void main(void) {

char str[100] = scanf("%s");

printf("%s", str);

}

This simple program takes input from the user and displays it back on the screen. The string %s means that the other parameter, str, should be displayed as a string. This example is ''not ''vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from Blexim's ''Phrack ''article:

'' #include <stdio.h>''

'' #include <string.h>''

'' void main(int argc, char *argv[]){''

'' int i = atoi(argv[1]); // input from user''

'' unsigned short s = i; // truncate to a short''

'' char buf[50]; // large buffer''

'' if (s > 10) { // check we're not greater than 10''

'' return;''

'' }''

'' memcpy(buf, argv[2], i); // copy i bytes to the buffer''

'' buf[i] = '\0'; // add a null byte to the buffer''

'' printf("%s\n", buf); // output the buffer contents''

'' return;''

'' } ''

''[root /tmp]# ./inttest 65580 foobar''

''Segmentation fault''

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html

* Newsham, Tim, ''Format String Attacks

''http://www.lava.net/~newsham/format-string-attacks.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/phrack/49/P49-14

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://rr.sans.org/code/inside_buffer.php

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/phrack/60/p60-0x0a.txt

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

http://www.immunix.org

* Libsafe

http://www.research.avayalabs.com/project/libsafe

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]