OWASP - User contributions [en]

OWASP Dependency Check

2017-07-03T12:24:19Z

Will Stranathan: /* Quick Download */ Updated version numbers to 2.0.0

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java and .NET are supported; additional experimental support has been added for Ruby, Node.js, Python, and limited support for C/C++ build systems (autoconf and cmake). The tool can be part of a solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[http://www1.contrastsecurity.com/the-unfortunate-reality-of-insecure-libraries?&__hssc=92971330.1.1412763139545&__hstc=92971330.5d71a97ce2c038f53e4109bfd029b71e.1412763139545.1412763139545.1412763139545.1&hsCtaTracking=7bbb964b-eac1-454d-9d5b-cc1089659590%7C816e01cf-4d75-449a-8691-bd0c6f9946a5 The Unfortunate Reality of Insecure Libraries]" (registration required). The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

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

== Quick Download ==

Version 2.0.0
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-2.0.0-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-2.0.0-release.zip Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C2.0.0%7Cmaven-plugin Maven Plugin]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-gradle%7C2.0.0%7Cgradle-plugin Gradle Plugin]
* [https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin Jenkins Plugin]
* [http://brew.sh/ Mac Homebrew]:<br><code>brew update && brew install dependency-check</code>

Other Plugins
* [http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22net.vonbuchholtz%22%20a%3A%22sbt-dependency-check%22 sbt Plugin]

== Integrations ==
* [https://github.com/stevespringett/dependency-check-sonar-plugin SonarQube Plugin]

== Links ==

* [https://github.com/jeremylong/DependencyCheck github]
* [https://github.com/jeremylong/dependency-check-gradle gradle source]
* [https://github.com/albuch/sbt-dependency-check sbt source]
* [https://github.com/jenkinsci/dependency-check-plugin jenkins source]
* [https://www.ohloh.net/p/dependencycheck Ohloh]
* [https://bintray.com/jeremy-long/owasp Bintray]

== Documentation ==

* [http://jeremylong.github.io/DependencyCheck/ Documentation (on GitHub)]

== Mailing List ==

* [mailto:dependency-check+subscribe@googlegroups.com Subscribe]
* [mailto:dependency-check@googlegroups.com Post]
* [https://groups.google.com/forum/#!forum/dependency-check Archived Posts]

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/general/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/general/dependency-check.pptx dependency-check (PPTX)]

==Classifications==

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

|}

= Acknowledgements =
==Volunteers==
Dependency-Check is developed by a team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of March 2015, the top priorities are:
* Resolving all open [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues/feature requests]
* Improving analysis for .NET Dlls

Involvement in the development and promotion of dependency-check is actively encouraged!
You do not have to be a security expert in order to contribute. How you can help:
* Use the tool
* Provide feedback via the [https://groups.google.com/forum/?fromgroups#!forum/dependency-check mailing list] or by creating [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues] (both bugs and feature requests are encouraged)
* The project source code is hosted on [https://github.com/jeremylong/DependencyCheck/ github] - if you are so inclined fork it and provide push requests!

__NOTOC__ <headertabs></headertabs>

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

OWASP Dependency Check

2015-08-06T00:09:46Z

Will Stranathan: Bumped version on Quick Download

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java, .NET, and Python dependencies are supported. This tool can be part of a solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[http://www1.contrastsecurity.com/the-unfortunate-reality-of-insecure-libraries?&__hssc=92971330.1.1412763139545&__hstc=92971330.5d71a97ce2c038f53e4109bfd029b71e.1412763139545.1412763139545.1412763139545.1&hsCtaTracking=7bbb964b-eac1-454d-9d5b-cc1089659590%7C816e01cf-4d75-449a-8691-bd0c6f9946a5 The Unfortunate Reality of Insecure Libraries]" (registration required). The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

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

== Quick Download ==

Version 1.3.0
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-1.3.0-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-1.3.0.jar Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C1.3.0%7Cmaven-plugin Maven Plugin]
* [https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin Jenkins Plugin]
* [http://brew.sh/ Mac Homebrew]:<br><code>brew update && brew install dependency-check</code>

== Links ==

* [https://github.com/jeremylong/DependencyCheck Github]
* [https://www.ohloh.net/p/dependencycheck Ohloh]
* [https://bintray.com/jeremy-long/owasp Bintray]

== Documentation ==

* [http://jeremylong.github.io/DependencyCheck/ User Documentation]
* [https://github.com/jeremylong/DependencyCheck/wiki Developer Documentation]

== Mailing List ==

* [mailto:dependency-check+subscribe@googlegroups.com Subscribe]
* [mailto:dependency-check@googlegroups.com Post]
* [https://groups.google.com/forum/#!forum/dependency-check Archived Posts]

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/dependency-check.pptx dependency-check (PPTX)]

==Classifications==

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

|}

= Acknowledgements =
==Volunteers==
Dependency-Check is developed by a team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of March 2015, the top priorities are:
* Resolving all open [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues/feature requests]
* Improving analysis for .NET Dlls

Involvement in the development and promotion of dependency-check is actively encouraged!
You do not have to be a security expert in order to contribute. How you can help:
* Use the tool
* Provide feedback via the [https://groups.google.com/forum/?fromgroups#!forum/dependency-check mailing list] or by creating [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues] (both bugs and feature requests are encouraged)
* The project source code is hosted on [https://github.com/jeremylong/DependencyCheck/ github] - if you are so inclined fork it and provide push requests!

__NOTOC__ <headertabs />

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

OWASP Dependency Check

2015-07-09T02:06:09Z

Will Stranathan: Added a line break to clarify brew commands

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java, .NET, and Python dependencies are supported. This tool can be part of a solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[http://www1.contrastsecurity.com/the-unfortunate-reality-of-insecure-libraries?&__hssc=92971330.1.1412763139545&__hstc=92971330.5d71a97ce2c038f53e4109bfd029b71e.1412763139545.1412763139545.1412763139545.1&hsCtaTracking=7bbb964b-eac1-454d-9d5b-cc1089659590%7C816e01cf-4d75-449a-8691-bd0c6f9946a5 The Unfortunate Reality of Insecure Libraries]" (registration required). The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

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

== Quick Download ==

Version 1.2.11
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-1.2.11-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-1.2.11.jar Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C1.2.11%7Cmaven-plugin Maven Plugin]
* [https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin Jenkins Plugin]
* [http://brew.sh/ Mac Homebrew]:<br><code>brew update && brew install dependency-check</code>

== Links ==

* [https://github.com/jeremylong/DependencyCheck Github]
* [https://www.ohloh.net/p/dependencycheck Ohloh]
* [https://bintray.com/jeremy-long/owasp Bintray]

== Documentation ==

* [http://jeremylong.github.io/DependencyCheck/ User Documentation]
* [https://github.com/jeremylong/DependencyCheck/wiki Developer Documentation]

== Mailing List ==

* [mailto:dependency-check+subscribe@googlegroups.com Subscribe]
* [mailto:dependency-check@googlegroups.com Post]
* [https://groups.google.com/forum/#!forum/dependency-check Archived Posts]

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/dependency-check.pptx dependency-check (PPTX)]

==Classifications==

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

|}

= Acknowledgements =
==Volunteers==
Dependency-Check is developed by a team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of March 2015, the top priorities are:
* Resolving all open [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues/feature requests]
* Improving analysis for .NET Dlls

Involvement in the development and promotion of dependency-check is actively encouraged!
You do not have to be a security expert in order to contribute. How you can help:
* Use the tool
* Provide feedback via the [https://groups.google.com/forum/?fromgroups#!forum/dependency-check mailing list] or by creating [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues] (both bugs and feature requests are encouraged)
* The project source code is hosted on [https://github.com/jeremylong/DependencyCheck/ github] - if you are so inclined fork it and provide push requests!

__NOTOC__ <headertabs />

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

OWASP Dependency Check

2015-07-09T02:04:16Z

Will Stranathan: Added installation instructions on Homebrew

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java, .NET, and Python dependencies are supported. This tool can be part of a solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[http://www1.contrastsecurity.com/the-unfortunate-reality-of-insecure-libraries?&__hssc=92971330.1.1412763139545&__hstc=92971330.5d71a97ce2c038f53e4109bfd029b71e.1412763139545.1412763139545.1412763139545.1&hsCtaTracking=7bbb964b-eac1-454d-9d5b-cc1089659590%7C816e01cf-4d75-449a-8691-bd0c6f9946a5 The Unfortunate Reality of Insecure Libraries]" (registration required). The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

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

== Quick Download ==

Version 1.2.11
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-1.2.11-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-1.2.11.jar Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C1.2.11%7Cmaven-plugin Maven Plugin]
* [https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin Jenkins Plugin]
* [http://brew.sh/ Mac Homebrew]: <code>brew update && brew install dependency-check</code>

== Links ==

* [https://github.com/jeremylong/DependencyCheck Github]
* [https://www.ohloh.net/p/dependencycheck Ohloh]
* [https://bintray.com/jeremy-long/owasp Bintray]

== Documentation ==

* [http://jeremylong.github.io/DependencyCheck/ User Documentation]
* [https://github.com/jeremylong/DependencyCheck/wiki Developer Documentation]

== Mailing List ==

* [mailto:dependency-check+subscribe@googlegroups.com Subscribe]
* [mailto:dependency-check@googlegroups.com Post]
* [https://groups.google.com/forum/#!forum/dependency-check Archived Posts]

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/dependency-check.pptx dependency-check (PPTX)]

==Classifications==

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

|}

= Acknowledgements =
==Volunteers==
Dependency-Check is developed by a team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of March 2015, the top priorities are:
* Resolving all open [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues/feature requests]
* Improving analysis for .NET Dlls

Involvement in the development and promotion of dependency-check is actively encouraged!
You do not have to be a security expert in order to contribute. How you can help:
* Use the tool
* Provide feedback via the [https://groups.google.com/forum/?fromgroups#!forum/dependency-check mailing list] or by creating [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues] (both bugs and feature requests are encouraged)
* The project source code is hosted on [https://github.com/jeremylong/DependencyCheck/ github] - if you are so inclined fork it and provide push requests!

__NOTOC__ <headertabs />

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

REST Security Cheat Sheet

2014-12-16T21:52:27Z

Will Stranathan: Added section on framework-provided validation.

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

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] (or REpresentational State Transfer) is a means of expressing specific entities in a system by URL path elements. REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URLs rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and session management =

RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS; API Key in URL)

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider using only the session token or API key to maintain client state in a server-side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time, and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt; change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in <tt>https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false</tt> as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.

== Whitelist allowable methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>PUT</tt> would update an existing entity, <tt>POST</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs would work, while all others would return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST, and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token-based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Insecure direct object references ==

It may seem obvious, but if you had a bank account REST web service, you'd have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly absurd. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

This is essentially a data-contextual access control enforcement need. A URL or even a POSTed form should NEVER contain an access control "key" or similar that provides automatic verification. <b>A data contextual check needs to be done, server side, with each request.</b>

= Input validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and computer" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client-side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Secure parsing ==

Use a secure parser for parsing the incoming messages. If you are using XML, make sure to use a parser that is not vulnerable to [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing XXE] and similar attacks.

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate incoming content-types ==

When POSTing or PUTting new data, the client will specify the Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The client should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a <tt>406 Not Acceptable</tt> response.

== Validate response types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML input validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

== Framework-Provided Validation ==

Many frameworks, such as [https://jersey.java.net/ Jersey], allow for validation constraints to be enforced automatically by the framework at request or response time. (See [https://jersey.java.net/documentation/latest/bean-validation.html Bean Validation Support] for more information). While this does not validate the structure of JSON or XML data before being unmarshaled, it does provide automatic validation after unmarshaling, but before the data is presented to the application.

= Output encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is preventing arbitrary JavaScript remote code execution within the browser... or, if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user-supplied data properly to prevent the execution of user-supplied input on the browser.

When inserting values into the browser DOM, strongly consider using <tt>.value</tt>/<tt>.innerText</tt>/<tt>.textContent</tt> rather than <tt>.innerHTML</tt> updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless the public information is completely read-only, the use of TLS should be mandated, particularly where credentials, updates, deletions, and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client-side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Related articles =

{{Cheatsheet_Navigation}}

= Authors and primary editors =

Erlend Oftedal - erlend.oftedal@owasp.org<br/>
Andrew van der Stock - vanderaj@owasp.org<br/>
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

User:Will Stranathan

2014-07-17T14:15:57Z

Will Stranathan: Updated email address

== Biography ==

I've written bad code since I was 8 years old. I've written bad code in Turtle Logo, BASIC (Atari 2600, C-64, Apple II, TRS-80, QBasic, and Visual Basic), Pascal, C, C++, Ada, Cobol, Perl, .NET (C#, J#, Visual Basic), Java, Groovy, Python, Ruby, Scala, Smalltalk, P-SQL, T-SQL, REXX, DOS-Batch, bash, DBase III, Oracle Forms, FORTH, HTML, Javascript, and probably some other languages I've forgotten. Writing bad code for that long has qualified me to observe how others write rotten code. I look at other peoples' rotten code for a living and help them write better code.

== <tt>.project</tt> ==

I'm the active chair of the [[Charlotte|Chalotte OWASP Chapter]].

== Contact ==

You can email me at [mailto:will.stranathan+at+owasp.org will.stranathan at owasp.org]

CISSP, GSSP-J

OWASP Dependency Check

2014-06-24T13:01:15Z

Will Stranathan: Updated downloads to 1.2.2

=Main=

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

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

==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java and .NET dependencies are supported; however, support for Node.JS, client side JavaScript libraries, etc. is planned. This tool can be part of the solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

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

== Quick Download ==

Version 1.2.2
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-1.2.2-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-1.2.2.jar Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C1.2.2%7Cmaven-plugin Maven Plugin]
* [https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin Jenkins Plugin]

== Links ==

* [https://github.com/jeremylong/DependencyCheck Github]
* [https://www.ohloh.net/p/dependencycheck Ohloh]
* [https://bintray.com/jeremy-long/owasp Bintray]

== Documentation ==

* [http://jeremylong.github.io/DependencyCheck/ User Documentation]
* [https://github.com/jeremylong/DependencyCheck/wiki Developer Documentation]

== Mailing List ==

* [mailto:dependency-check+subscribe@googlegroups.com Subscribe]
* [mailto:dependency-check@googlegroups.com Post]
* [https://groups.google.com/forum/#!forum/dependency-check Archived Posts]

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/dependency-check.pptx dependency-check (PPTX)]

==Classifications==

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

|}

= Acknowledgements =
==Volunteers==
Dependency-Check is developed by a team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of May 2014, the top priorities are:
* Resolving all open [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues/feature requests]
* Improving analysis for .NET Dlls
* Implementing a JavaScript analyzer to support both Node.js and JavaScript libraries such as jquery

Involvement in the development and promotion of dependency-check is actively encouraged!
You do not have to be a security expert in order to contribute. How you can help:
* Use the tool
* Provide feedback via the [https://groups.google.com/forum/?fromgroups#!forum/dependency-check mailing list] or by creating [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues] (both bugs and feature requests are encouraged)
* The project source code is hosted on [https://github.com/jeremylong/DependencyCheck/ github] - if you are so inclined fork it and provide push requests!

__NOTOC__ <headertabs />

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

OWASP Dependency Check

2014-03-05T16:23:55Z

Will Stranathan: Updated to show that .NET is supported.

=Main=

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

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

==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java and .NET dependencies are supported; however, support for Node.JS, client side JavaScript libraries, etc. is planned. This tool can be part of the solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

More information about dependency-check can be found on the [http://jeremylong.github.io/DependencyCheck/ dependency-check github pages]. Additionally, the source could can be found on [https://github.com/jeremylong/DependencyCheck github].

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

== What is Dependency-Check? ==

OWASP Dependency-Check provides:

* Monitoring of project dependencies
* Library Identification
* Notification of CVE

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/dependency-check.pptx dependency-check (PPTX)]

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

== Quick Download ==

{{:Projects/OWASP Dependency Check/Releases/Current}}

==Classifications==

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

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

Involvement in the development and promotion of Dependency Check is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP_Dependency_Check}}

__NOTOC__ <headertabs />

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

OWASP Dependency Check

2014-03-04T01:55:30Z

Will Stranathan: Updated contributors

=Main=

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

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

==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently only Java projects are supported; however, support for .NET, Node.JS, client side JavaScript libraries, etc. is planned. This tool can be part of the solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

More information about dependency-check can be found on the [http://jeremylong.github.io/DependencyCheck/ dependency-check github pages]. Additionally, the source could can be found on [https://github.com/jeremylong/DependencyCheck github].

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

== What is Dependency-Check? ==

OWASP Dependency-Check provides:

* Monitoring of project dependencies
* Library Identification
* Notification of CVE

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/dependency-check.pptx dependency-check (PPTX)]

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

== Quick Download ==

{{:Projects/OWASP Dependency Check/Releases/Current}}

==Classifications==

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

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

Involvement in the development and promotion of Dependency Check is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP_Dependency_Check}}

__NOTOC__ <headertabs />

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

Projects/OWASP Dependency Check/Releases/Current

2014-03-04T01:47:11Z

Will Stranathan: Updated version

Version 1.1.2
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-1.1.2-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-1.1.2.jar Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C1.1.2%7Cmaven-plugin Maven Plugin]
* [https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin Jenkins Plugin]

Source distribution can be found [https://github.com/jeremylong/DependencyCheck here].

OWASP Dependency Check

2014-03-04T01:45:58Z

Will Stranathan: Updated to 1.1.2

=Main=

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

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

==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently only Java projects are supported; however, support for .NET, Node.JS, client side JavaScript libraries, etc. is planned. This tool can be part of the solution to the OWASP Top 10 2013 [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [http://nvd.nist.gov/cpe.cfm Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [http://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [http://nvd.nist.gov/download.cfm NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more, if you run the tool at least once every seven days only a small XML file needs to be downloaded to keep the local copy of the data current.

More information about dependency-check can be found on the [http://jeremylong.github.io/DependencyCheck/ dependency-check github pages]. Additionally, the source could can be found on [https://github.com/jeremylong/DependencyCheck github].

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

== What is Dependency-Check? ==

OWASP Dependency-Check provides:

* Monitoring of project dependencies
* Library Identification
* Notification of CVE

== Presentation ==

* [http://jeremylong.github.io/DependencyCheck/dependency-check.pdf dependency-check (PDF)]
* [http://jeremylong.github.io/DependencyCheck/dependency-check.pptx dependency-check (PPTX)]

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

== Quick Download ==

Version 1.1.2
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-1.1.2-release.zip Command Line]
* [http://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-1.1.2.jar Ant Task]
* [http://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C1.1.2%7Cmaven-plugin Maven Plugin]
* [https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin Jenkins Plugin]

Source distribution can be found [https://github.com/jeremylong/DependencyCheck here].

==Classifications==

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

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

Involvement in the development and promotion of XXX is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP_Dependency_Check}}

__NOTOC__ <headertabs />

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

Charlotte

2012-04-04T21:32:08Z

Will Stranathan: Changed leader to Jon

[[File:OWASP CLT.png|x182px]]

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [mailto:rjmolesa@owasp.org Jon Molesa].|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next chapter meeting will be Wednesday, March 21, 6:30pm at [http://knowclassic.com Classic Graphics] at [http://g.co/maps/5zgwt 8335 Classic Drive in Charlotte].

Our chapter meetings now are the third Wednesday of every month at 6:30pm.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2012-02-22|22 February 2012]]
* [[Charlotte Chapter Meeting 2011-10-10|10 October 2011]]
* [[Charlotte Chapter Meeting 2011-08-15|15 August 2011]]
* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

* We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.
* We have a channel on Freenode - #owasp-clt
* We have a named Hangout on Google+ - http://plus.google.com/hangouts/extras/owasp-clt

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

Charlotte Chapter Meeting 2012-02-22

2012-02-25T14:10:57Z

Will Stranathan: Spelling correction

22 February 2012 was our first meeting at [http://knowclassic.com Classic Graphics]. Many thanks to Classic for hosting '''and''' providing pizza and drinks before the meeting.

== Meet and Greet ==

Our first order of business was to meet and greet. Professional and student chapters were represented. Brian of Classic also gave us a tour of the facility, which was really cool.

== Leadership ==

[[User:Will Stranathan|Will Stranathan]] announced he would like to step down as Chair of the Charlotte Chapter in order to focus on projects within the chapter. The floor was open for nominations, and [[User:Jon Molesa|Jon Molesa]] was chosen as the new chapter chair.

The chapter also decided to have a Chapter Board. Initially seven people self-nominated for the Board, but a decision was later made to reduce that number to three plus the Chair.

== Code Jams ==

In an effort to start producing and having some contributions back to the OWASP Community, we're hoping to organize some Code Jams - very quick wins that still are good contributions to code, exploit examples, documentation, etc.

Also, we still have our long-term goal to work on a hardened Drupal packaging with hooks to [[Appsensor]]

== Wrap-up ==

Classic has offered to allow us to use their facility for future meetings. They will also sponsor our membership to Meetup. Regular meetings will be the third Wednesday of every month at Classic.

Charlotte Chapter Meeting 2012-02-22

2012-02-25T14:07:55Z

Will Stranathan: Created page with "22 February 2012 was our first meeting at [http://knowclassic.com Classic Graphics]. Many thanks to Classic for hosting '''and''' providing pizza and drinks before the meeting..."

Charlotte

2012-02-25T13:32:09Z

Will Stranathan: Added chapter logo and link to meeting summary page

[[File:OWASP CLT.png|x182px]]

{{Chapter Template|chaptername=Charlotte|extra=The chapter leaders are [[User:Will Stranathan|Will Stranathan]] and [mailto:rjmolesa@owasp.org Jon Molesa].|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next chapter meeting will be Wednesday, March 21, 6:30pm at [http://knowclassic.com Classic Graphics] at [http://g.co/maps/5zgwt 8335 Classic Drive in Charlotte].

Our chapter meetings now are the third Wednesday of every month at 6:30pm.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2012-02-22|22 February 2012]]
* [[Charlotte Chapter Meeting 2011-10-10|10 October 2011]]
* [[Charlotte Chapter Meeting 2011-08-15|15 August 2011]]
* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

* We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.
* We have a channel on Freenode - #owasp-clt
* We have a named Hangout on Google+ - http://plus.google.com/hangouts/extras/owasp-clt

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

File:OWASP CLT.png

2012-02-25T13:24:49Z

Will Stranathan: OWASP Charlotte logo

OWASP Charlotte logo

Charlotte

2012-02-14T17:17:25Z

Will Stranathan: Added info for next meeting

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next chapter meeting will be Wednesday, February 22, 6:30pm at [http://knowclassic.com Classic Graphics] at [http://g.co/maps/5zgwt 8335 Classic Drive in Charlotte].

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-10-10|10 October 2011]]
* [[Charlotte Chapter Meeting 2011-08-15|15 August 2011]]
* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

Talk:REST Security Cheat Sheet

2011-12-20T01:22:50Z

Will Stranathan: Added section on Type Validation

== Avoiding DOR ==
[[User:Will Stranathan|Will]]<br />
My point with the [[{{PAGENAME}}#Check Authorization for User-Specific Entities|Check Authorization for User-Specific Entities]] section is to avoid Direct Object Reference. There are really two underlying potential pitfalls here:
* Giving access to objects simply by the key value in the URL rather than checking proper authorization for that entity. (i.e., this user doesn't have access to object 1235, but we allow the method simply because 1235 was in the URL rather than checking to see if '''this''' user is allowed to modify/view it)
* Giving away sensitive information simply by including the object ID in the URL. Users tend to copy/paste URL's and they get cached in many different places and included in the history (even if the response gives the right <tt>Expires</tt>, <tt>Cache-control</tt>, and <tt>Pragma</tt> headers), so the URL shouldn't directly include anything sensitive like account number. http://some.service/account/128420482 should be a no-no.

== Type Validation ==
[[User:Will Stranathan|Will]]<br />
I would love to add a section on validating incoming entity definitions via XML or JSON. In XML, you have to deal first with entity expansion (death by a million laughs) because entities are expanded '''before''' the XML itself is validated, then need to validate against a DTD, XML-Schema, etc.

I'm just now finding out that there is a loose definition of a JSON validation scheme [http://en.wikipedia.org/wiki/JSON#Schema], but I'm not sure if any of the popular server-side JSON frameworks support this built-in, or what the maturity is of any of the implementations at [http://json-schema.org/implementations.html]. Anybody have any knowledge on this?

Talk:REST Security Cheat Sheet

2011-12-20T00:53:41Z

Will Stranathan: Added discussion about Direct Object Reference details

== Avoiding DOR ==
My point with the [[{{PAGENAME}}#Check Authorization for User-Specific Entities|Check Authorization for User-Specific Entities]] section is to avoid Direct Object Reference. There are really two underlying potential pitfalls here:
* Giving access to objects simply by the key value in the URL rather than checking proper authorization for that entity. (i.e., this user doesn't have access to object 1235, but we allow the method simply because 1235 was in the URL rather than checking to see if '''this''' user is allowed to modify/view it)
* Giving away sensitive information simply by including the object ID in the URL. Users tend to copy/paste URL's and they get cached in many different places and included in the history (even if the response gives the right <tt>Expires</tt>, <tt>Cache-control</tt>, and <tt>Pragma</tt> headers), so the URL shouldn't directly include anything sensitive like account number. http://some.service/account/128420482 should be a no-no.

REST Security Cheat Sheet

2011-12-20T00:35:27Z

Will Stranathan: Fixed my confluence markup to mediawiki

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] or REpresentational State Transfer is a means of expressing specific entities in a system by URL path elements. REST allows interaction with a web-based system via simplified URL's rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

== Check Authorization for User-Specific Entities ==
While REST is useful for targeting specific entities in the system, the URL itself should not be the only authorizing token for sensitive entities (such as account transactions, personally-identifying information, etc.). Proper authentication should take place, and the token for authorization should be sent as a cookie. Furthermore, no Personally-Identifiable Information (such as bank-account number, credit card number, etc.) should be used as a parameter to request an entity. See the [DOR (Direct Object Reference) Prevention Cheat Sheet] for strategies for preventing Direct Object Reference weaknesses.

== Whitelist-Only Response Types ==
It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== Whitelist Allowable Methods ==
It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>POST</tt> would update an existing entity, <tt>PUT</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs will work, all others return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Non-REST Authentication ==
Authentication for a REST-based service should not take place by passing the user ID and password in path elements of the URL. URL's are commonly cached by browsers, proxies, etc. so sensitive information should not be included directly in the URL.

[[Category:How_To]] [[Category:Cheatsheets]]

REST Security Cheat Sheet

2011-12-20T00:32:21Z

Will Stranathan: Very beginnings of the REST security cheat sheet.

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] or REpresentational State Transfer is a means of expressing specific entities in a system by URL path elements. REST allows interaction with a web-based system via simplified URL's rather than complex request body or {{POST}} parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

== Check Authorization for User-Specific Entities ==
While REST is useful for targeting specific entities in the system, the URL itself should not be the only authorizing token for sensitive entities (such as account transactions, personally-identifying information, etc.). Proper authentication should take place, and the token for authorization should be sent as a cookie. Furthermore, no Personally-Identifiable Information (such as bank-account number, credit card number, etc.) should be used as a parameter to request an entity. See the [DOR (Direct Object Reference) Prevention Cheat Sheet] for strategies for preventing Direct Object Reference weaknesses.

== Whitelist-Only Response Types ==
It is common for REST services to allow multiple response types (e.g. {{application/xml}} or {{application/json}}, and the client specifies the preferred order of response types by the {{Accept}} header in the request. '''Do NOT''' simply copy the {{Accept}} header to the {{Content-type}} header of the response. Reject the request (ideally with a {{406 Not Acceptable}} response) if the {{Accept}} header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== Whitelist Allowable Methods ==
It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a {{GET}} request might read the entity while {{POST}} would update an existing entity, {{PUT}} would create a new entity, and {{DELETE}} would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs will work, all others return a proper response code (for example, a {{403 Forbidden}}).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Non-REST Authentication ==
Authentication for a REST-based service should not take place by passing the user ID and password in path elements of the URL. URL's are commonly cached by browsers, proxies, etc. so sensitive information should not be included directly in the URL.

[[Category:How_To]] [[Category:Cheatsheets]]

AppSensor

2011-11-01T16:50:27Z

Will Stranathan: Added a redirect to OWASP AppSensor Project since AppSensor is easier to type

#REDIRECT [[OWASP AppSensor Project]]

Charlotte Chapter Meeting 2011-04-27

2011-10-14T01:48:41Z

Will Stranathan: Added to Charlotte Chapter Meetings category

The 27 April 2011 Chapter Meeting was held at UNCC after the Software as a Service/Cloud Computing Symposium. Scott Matsumoto of Cigital presented on Threat Modeling in Amazon Web Services (and really, a lot of Threat Modeling in general).

[[Category:Charlotte Chapter Meetings]]

Charlotte Chapter Meeting 2011-08-15

2011-10-14T01:48:05Z

Will Stranathan: Added to the Charlotte Chapter Meetings category.

The August 15 meeting was held at Woodward Hall room 130. Our speaker was [[User:John Melton|John Melton]], developer for the [[OWASP AppSensor Project]]. Pizza was provided.

The chapter decided that as a chapter project we should begin getting involved in the [[OWASP AppSensor Project]] in various degrees. [[User:John Melton|John]] will begin working out a list of open bugs and enhancement requests. Also, members of the chapter are encouraged to begin looking at implementing AppSensor in other languages (PHP had the highest interest level during the meeting), being sure to make it compatible as much as possible with [[:Category:OWASP Enterprise Security API|ESAPI]] and the current Java implementation of AppSensor.

[[Category:Charlotte Chapter Meetings]]

Charlotte

2011-10-14T01:46:59Z

Will Stranathan: Added January meeting info.

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Stay tuned for our next chapter meeting. We intend to have a few smaller "Jam Sessions" before the next chapter meeting to get some of those "quick wins" that help us feel more productive. The next chapter meeting will probably be in January 2012.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-10-10|10 October 2011]]
* [[Charlotte Chapter Meeting 2011-08-15|15 August 2011]]
* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

Charlotte Chapter Meeting 2011-10-10

2011-10-14T01:29:57Z

Will Stranathan:

Our 2011-10-10 meeting featured [[User:Jeff Williams|Jeff Williams]], CEO of Aspect Security and former Volunteer Chair for OWASP. Jeff did a rapid-fire discussion of [[Media:OWASP Jeff Williams Talk.ppt|lots of different topics]]. We also discussed things we can do to make the chapter a success. Please be sure to send [[User:Jeff Williams|Jeff]] your thanks.

[[Category:Charlotte Chapter Meetings]]

Charlotte Chapter Meeting 2011-10-10

2011-10-14T01:24:02Z

Will Stranathan: Initial notes on the 2011-10-10 meeting

Our 2011-10-10 meeting featured [[User:Jeff Williams|Jeff Williams]], CEO of Aspect Security and former Volunteer Chair for OWASP. Jeff did a rapid-fire discussion of [[File:OWASP Jeff Williams Talk.ppt|lots of different topics]]. We also discussed things we can do to make the chapter a success. Please be sure to send [[User:Jeff Williams|Jeff]] your thanks.

[[Category:Charlotte Chapter Meetings]]

File:OWASP Jeff Williams Talk.ppt

2011-10-14T01:22:38Z

Will Stranathan: List of topics Jeff Williams talked about during the 2011-10-10 OWASP Charlotte Chapter Meeting.

List of topics Jeff Williams talked about during the 2011-10-10 OWASP Charlotte Chapter Meeting.

HTML5 Security Cheat Sheet

2011-10-09T11:55:01Z

Will Stranathan: Fixed some formatting, grammar. Removed incomplete/question sections.

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they relate to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but the <tt>sandbox</tt> attribute of <tt>iframe</tt>'s will be ignored in browsers except those HTML 5 compliant browsers which support it. If there are differences in implementations, there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

* Validate URLs passed to <tt>XMLHttpRequest.open</tt>, current browsers allow these URLs to be cross domain.
* Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
* Take special care when using <tt>Access-Control-Allow-Credentials: true</tt> response header. Whitelist the allowed Origins and never echo back the <tt>Origin</tt> request header in <tt>Access-Control-Allow-Origin</tt>.
* Allow only selected, trusted domains in <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (either through <tt>*</tt> wildcard or echoing the <tt>Origin</tt> header content).
* Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
* While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.

== Local Storage (a.k.a. Offline Storage, Web Storage) ==
* Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebDatabase ==
* Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebSockets ==

* Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
* While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
* The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
* Endpoints exposed through <tt>ws://</tt> protocol are easily reversible to plaintext. Only <tt>wss://</tt> (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
* Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
* When implementing servers, check the <tt>Origin:</tt> header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
* As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.

== Geolocation ==
* The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the <tt>sandbox</tt> attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
* When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
* The receiving page should '''always''':
** Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
** Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format

== Content Deliverability ==

CDN or src links to foreign domains -- know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well known - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

Will Stranathan - will [at] cltnc.us

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-09-18T18:43:27Z

Will Stranathan: Added some formatting - mostly tt around specific header or API names

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to <tt>XMLHttpRequest.open</tt>, current browsers allow these URLs to be cross domain.
*Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using <tt>Access-Control-Allow-Credentials: true</tt> response header. Whitelist the allowed Origins and never echo back the <tt>Origin</tt> request header in <tt>Access-Control-Allow-Origin</tt>.
*Allow only selected, trusted domains in <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the <tt>Origin</tt> header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
*While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==
*Keep in mind that the underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebDatabase ==
*Keep in mind that the underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only <tt>wss://</tt> (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the <tt>Origin:</tt> header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.

== Geolocation ==
*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

Will Stranathan - will [at] cltnc.us

[[Category:How_To]] [[Category:Cheatsheets]]

Talk:HTML5 Security Cheat Sheet

2011-09-18T18:37:33Z

Will Stranathan: Created page with "I contributed to the following sections: *Local Storage *Web Database *Cross-Origin Resource Sharing *Geolocation *Web Messaging Please take a moment to ..."

[[User:Will Stranathan|I]] contributed to the following sections:
*Local Storage
*Web Database
*Cross-Origin Resource Sharing
*Geolocation
*Web Messaging
Please take a moment to review the changes to ensure they're consistent with the "cheatsheet" mentality.

HTML5 Security Cheat Sheet

2011-09-18T18:35:01Z

Will Stranathan: Added myself as a contributor

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
*Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br>
*Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==
*Keep in mind that the underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebDatabase ==
*Keep in mind that the underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br>

== Geolocation ==
*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

Will Stranathan - will [at] cltnc.us

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-09-18T18:34:27Z

Will Stranathan: Added warnings about local storage not requiring any authentication.

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
*Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br>
*Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==
*Keep in mind that the underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebDatabase ==
*Keep in mind that the underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br>

== Geolocation ==
*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-09-18T18:31:28Z

Will Stranathan: Added a privacy blurb on Geolocation

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
*Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br>
*Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==

== WebDatabase ==

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br>

== Geolocation ==
*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-09-18T18:28:24Z

Will Stranathan: Fixed tt tags (thinking Confluence syntax)

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
*Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br>
*Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==

== WebDatabase ==

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br>

== Geolocation ==

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-09-18T18:27:28Z

Will Stranathan: Added brief section on Web Messaging

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
*Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br>
*Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==

== WebDatabase ==

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br>

== Geolocation ==

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the {{origin}} attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the {{data}} attribute of the event to ensure it's in the desired format

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-09-18T18:22:01Z

Will Stranathan: Added CSRF recommendation on CORS

Charlotte

2011-08-31T13:00:02Z

Will Stranathan: Updated date for the next meeting.

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next Chapter meeting will be October 10, 2011 at 6:30 pm at the University of North Carolina Charlotte campus - Woodward Hall room 130. This is the day '''before''' the [http://cci.uncc.edu/security Cyber Security Symposium] (which you should also attend). Our guest speaker will be [[user:Jeff Williams|Jeff Williams]], volunteer Chair of the OWASP Foundation and CEO of [http://aspectsecurity.com Aspect Security]. Please mark your calendar and invite a friend!

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-08-15|15 August 2011]]
* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

Charlotte Chapter Meeting 2011-08-15

2011-08-17T21:05:53Z

Will Stranathan: Created page with "The August 15 meeting was held at Woodward Hall room 130. Our speaker was John Melton, developer for the OWASP AppSensor Project. Pizza was provided. ..."

Charlotte

2011-08-17T20:57:49Z

Will Stranathan: Moved August to archive, prepared for October.

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next Chapter meeting will be October 11, 2011 at the University of North Carolina Charlotte campus. It will be somewhere in the building where the [http://cci.uncc.edu/security Cyber Security Symposium] (which you should also attend) is to be held. We're working on a speaker right now, but guarantee it should be a really good one considering the line-up coming to speak at the Symposium. The meeting will begin at 6:30pm.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-08-15|15 August 2011]]
* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

Charlotte

2011-08-13T20:25:57Z

Will Stranathan: Fixed a link to JM's name and to the AppSensor Project.

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next chapter meeting will be Monday, August 15 at 6:30 pm in room 130 of Woodward Hall. [[User:John_Melton|JM]] will be presenting the [[OWASP AppSensor Project]]. Parking that week at UNCC is '''free''', plus there will be '''free''' pizza. Please email the mailing list to RSVP so we know (approximately) how much pizza to get.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

Charlotte Chapter Meeting 2011-04-27

2011-07-18T01:24:23Z

Will Stranathan: Created page with "The 27 April 2011 Chapter Meeting was held at UNCC after the Software as a Service/Cloud Computing Symposium. Scott Matsumoto of Cigital presented on Threat Modeling in Amazon W..."

Charlotte

2011-07-18T01:22:58Z

Will Stranathan:

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next chapter meeting will be Monday, August 15 at 6:30 pm in room 130 of Woodward Hall. JM will be presenting the OWASP App Sensor project. Parking that week at UNCC is '''free''', plus there will be '''free''' pizza. Please email the mailing list to RSVP so we know (approximately) how much pizza to get.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-04-27|27 April 2011]]
* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]
[[Category:North Carolina]]

Charlotte

2011-04-16T21:07:05Z

Will Stranathan: Added April meeting information

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

The Charlotte OWASP Chapter will be meeting Wednesday, April 27 after the [http://www.cvent.com/events/2011-saas-cloud-computing-symposium/event-summary-7700e2b6a6b24be1a8ba3ec83400cf22.aspx UNCC SaaS - Cloud Computing Symposium]. A couple of different things are lined up:

* Sign up for the Symposium - lots of great speakers will be presenting at the Symposium
* There's a dinner/reception after the Symposium from 5:30-6:30 in the Lucas room of the Cone building. OWASP members are welcome
* After the reception, Nabil Hannan from [http://www.cigital.com Cigital] will be presenting to the chapter

Be sure to bring $6 for parking - or ride share.

Hope to see all of you there.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]

Charlotte Chapter Meeting 2011-01-26

2011-01-28T17:39:18Z

Will Stranathan: Changed the URL for 49th S3curity Divisi0n

Our meeting on January 26, 2011 was held at Woodward Hall room 120 at UNC Charlotte. There were about 30 people in attendance between local professionals and members of the UNCC chapter and [http://49sd.tk/ 49th S3curity Divisi0n].

== Chapter Presentation ==
[[user:Mark Cimijotti|Mark Cimijotti]] gave a "meta-presentation" on presenting the [[Media:Charlotte_OWASP_Presentation_Template.ppt|Charlotte Chapter Presentation]] to other local professional chapters and/or co-workers in order to develop more interest in the local chapter.

== Meet and Greet ==
We had a short period of meet and greet where folks shared their professional or academic connection to OWASP.

== ASIDE ==
Dr. Bill Chu, Department Chair of the College of Computing and Informatics and [[User:Jing Xie|Jing Xie]] a graduate student at UNCC presented on [[OWASP ASIDE Project|ASIDE]], an Eclipse-based IDE plugin which helps developers to write defensive code from the beginning by giving them real-time feedback on points of interest in their development.

[[Category:Charlotte Chapter Meetings]]

Charlotte

2011-01-28T15:58:56Z

Will Stranathan: Added ink to chapter meetings and updated the next meeting.

{{Chapter Template|chaptername=Charlotte|extra=The chapter leader is [[User:Will Stranathan|Will Stranathan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Charlotte|emailarchives=http://lists.owasp.org/pipermail/owasp-Charlotte}}

== Next Chapter Meeting ==

Our next chapter meeting will be Wednesday, 27 April 2011 at UNC-Charlotte. The annual Software as a Service/Cloud Computing symposium will be that day, and we hope to have one of the speakers from the symposium present at the chapter meeting.

== Local News ==

* We now have a [[Media:Charlotte OWASP Presentation Template.ppt|Power Point Presentation]] for pitching the chapter to other local professional organizations.
* Many thanks to Brent for designing a logo, color scheme, and Power Point template for us. You can see a taste of it on [http://twitter.com/OWASPCharlotte|our Twitter page]. The Power Point template we'll use for local presentations (such as Infragard, PHP Users group, etc.)

== Chapter Meetings ==

We'll try to keep a record of [[:Category:Charlotte Chapter Meetings|our chapter meetings]] online as we go. The most recent ones are:

* [[Charlotte Chapter Meeting 2011-01-26|26 January 2011]]

== More Information ==

We have a [http://twitter.com/OWASPCharlotte Twitter Account] where we'll be posting news about OWASP Charlotte.

[[Category:OWASP Chapter]]

Charlotte Chapter Meeting 2011-01-26

2011-01-28T15:55:32Z

Will Stranathan: Fixed the sort category back - need to find a way to pretty-up the category page

Our meeting on January 26, 2011 was held at Woodward Hall room 120 at UNC Charlotte. There were about 30 people in attendance between local professionals and members of the UNCC chapter and [http://studentorgs.uncc.edu/node/692 49th S3curity Divisi0n].

== Chapter Presentation ==
[[user:Mark Cimijotti|Mark Cimijotti]] gave a "meta-presentation" on presenting the [[Media:Charlotte_OWASP_Presentation_Template.ppt|Charlotte Chapter Presentation]] to other local professional chapters and/or co-workers in order to develop more interest in the local chapter.

== Meet and Greet ==
We had a short period of meet and greet where folks shared their professional or academic connection to OWASP.

== ASIDE ==
Dr. Bill Chu, Department Chair of the College of Computing and Informatics and [[User:Jing Xie|Jing Xie]] a graduate student at UNCC presented on [[OWASP ASIDE Project|ASIDE]], an Eclipse-based IDE plugin which helps developers to write defensive code from the beginning by giving them real-time feedback on points of interest in their development.

[[Category:Charlotte Chapter Meetings]]

Charlotte Chapter Meeting 2011-01-26

2011-01-28T15:52:03Z

Will Stranathan:

Our meeting on January 26, 2011 was held at Woodward Hall room 120 at UNC Charlotte. There were about 30 people in attendance between local professionals and members of the UNCC chapter and [http://studentorgs.uncc.edu/node/692 49th S3curity Divisi0n].

== Chapter Presentation ==
[[user:Mark Cimijotti|Mark Cimijotti]] gave a "meta-presentation" on presenting the [[Media:Charlotte_OWASP_Presentation_Template.ppt|Charlotte Chapter Presentation]] to other local professional chapters and/or co-workers in order to develop more interest in the local chapter.

== Meet and Greet ==
We had a short period of meet and greet where folks shared their professional or academic connection to OWASP.

== ASIDE ==
Dr. Bill Chu, Department Chair of the College of Computing and Informatics and [[User:Jing Xie|Jing Xie]] a graduate student at UNCC presented on [[OWASP ASIDE Project|ASIDE]], an Eclipse-based IDE plugin which helps developers to write defensive code from the beginning by giving them real-time feedback on points of interest in their development.

[[Category:Charlotte Chapter Meetings|2011]]

Category:Charlotte Chapter Meetings

2011-01-28T15:50:37Z

Will Stranathan: Initial Write

The [[Charlotte|OWASP Charlotte Chapter]] keeps records of their chapter meetings online so that folks who miss the meetings can see what they missed.

Charlotte Chapter Meeting 2011-01-26

2011-01-28T15:47:53Z

Will Stranathan: Initial write-up

Our meeting on January 26, 2011 was held at Woodward Hall room 120 at UNC Charlotte. There were about 30 people in attendance between local professionals and members of the UNCC chapter and [http://studentorgs.uncc.edu/node/692 49th S3curity Divisi0n].

== Chapter Presentation ==
[[user:Mark Cimijotti|Mark Cimijotti]] gave a "meta-presentation" on presenting the [[Media:Charlotte_OWASP_Presentation_Template.ppt|Charlotte Chapter Presentation]] to other local professional chapters and/or co-workers in order to develop more interest in the local chapter.

== Meet and Greet ==
We had a short period of meet and greet where folks shared their professional or academic connection to OWASP.

== ASIDE ==
Dr. Bill Chu, Department Chair of the College of Computing and Informatics and [[User:Jing Xie|Jing Xie]] a graduate student at UNCC presented on [[OWASP ASIDE Project|ASIDE]], an Eclipse-based IDE plugin which helps developers to write defensive code from the beginning by giving them real-time feedback on points of interest in their development.

[[Category:Charlotte Chapter Meetings]]