- Introduced user registration
- Now using Spring Boot for classloading, this way local development does not need to restart the complete server - Fixed all kinds of dependencies on the names of the lessons necessary to keep in mind during the creation of a lesson. - Simplied loading of resources, by adding resource mappings in MvcConfig. - Refactored plugin loading, now only one class is left for loading the lessons.
This commit is contained in:
Nanne Baars
@ -0,0 +1,13 @@
|
||||
== The Open Source Ecosystems
|
||||
|
||||
* 10+ Million GitHub code repositories
|
||||
* 1 Million Sourceforge code repositories
|
||||
* 2500 public binary repositories
|
||||
** Some repositories have strict publisher standards
|
||||
*** Some repositories enforce source code distribution
|
||||
*** No guarantee the published source code is the source code of the published binary
|
||||
** Some repositories allow the republishing of a different set of bits for the same version
|
||||
** Some repositories allow you to remove published artifacts
|
||||
* Many different packaging systems; even for the same language
|
||||
* Different coordinates systems and level of granularity
|
||||
|
||||
@ -0,0 +1,7 @@
|
||||
|
||||
== 2013 OWASP Top 10 - A9
|
||||
|
||||
As early as 2013, thought leaders like OWASP recognized that "WE" need to pay attention to this problem.
|
||||
|
||||
|
||||
image::images/OWASP-2013-A9.png[caption="Figure: ", title="2013 OWASP - Top 10 - A9", alt="A9", width="800", height="500", style="lesson-image" link="https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities"]
|
||||
@ -0,0 +1,11 @@
|
||||
|
||||
== Components are everywhere
|
||||
|
||||
WebGoat uses almost *200 Java and JavaScript* libraries. Like most Java applications, we use maven to manage our java dependencies and we employ the wild, wild west strategy for managing JavaScript.
|
||||
|
||||
=== Vulnerable components in WebGoat?
|
||||
|
||||
When this lesson was created WebGoat contained more than a dozen high security risks within it's components. Most of these were not deliberate choices. How are developers supposed to track this information across the hundreds of components?
|
||||
|
||||
image::images/WebGoat-Vulns.png[caption="Figure: ", title="WebGoat Security Issues", alt="Security Issues", width="800", height="400", style="lesson-image"]
|
||||
|
||||
@ -0,0 +1,6 @@
|
||||
== The exploit is not always in "your" code
|
||||
Below is an example of using the same WebGoat source code, but different versions of the jquery-ui component. One is exploitable; one is not.
|
||||
|
||||
=== jquery-ui:1.10.4
|
||||
This example allows the user to specify the content of the "closeText" for the jquery-ui dialog. This is an unlikely development scenario, however the jquery-ui dialog (TBD - show exploit link) does not defend against XSS in the button text of the close dialog.
|
||||
|
||||
@ -0,0 +1,4 @@
|
||||
|
||||
=== jquery-ui:1.12.0 Not Vulnerable
|
||||
|
||||
Using the same WebGoat source code but upgrading the jquery-ui library to a non-vulnerable version eliminates the exploit.
|
||||
@ -0,0 +1,14 @@
|
||||
== Knowing the OSS "Bill of Materials" is the starting point
|
||||
|
||||
Modern applications are comprised of custom code and many pieces of open source. The developer is normally very knowledgeable about their custom code but less familiar with the potential risk of the libraries/components they use. Think of the bill of materials as the list of ingredients in a recipe.
|
||||
|
||||
=== Questions we should know the answer to:
|
||||
|
||||
* How do we know what open source components are in our applications?
|
||||
** How do we know what versions of open source components we are using?
|
||||
* How do we define the risk of open source components?
|
||||
* How do we discover the risk of open source components?
|
||||
** How do we associate a specific risk to a specific version of an open source component?
|
||||
* How do we know when a component releases a new version?
|
||||
* How do we know if a new vulnerability is found on what was previously a "good" component?
|
||||
* How do we know if we are using the authentic version of an open source component?
|
||||
@ -0,0 +1,9 @@
|
||||
== How do I generate a Bill of Materials
|
||||
|
||||
There are several open source and paid-for solutions that will identify risk in components. However, there are not many tools that will deliver a complete list of "ingredients" used within an application. OWASP Dependency Check provides the ability to generate a bill of materials and identify potential security risk.
|
||||
|
||||
Dependency check uses several pieces of evidence to determine the library names. Below is a snippet of a report:
|
||||
|
||||
image::images/OWASP-Dep-Check.png[caption="Figure: ", title="WebGoat Bill of Materials", alt="BoM", width="988", height="515", style="lesson-image"]
|
||||
|
||||
|
||||
@ -0,0 +1,23 @@
|
||||
== Security Information Overload
|
||||
|
||||
=== What's important?
|
||||
|
||||
* Is my component exploitable?
|
||||
* Is my component an authentic copy?
|
||||
** Do I understand why my component is modified?
|
||||
|
||||
=== Security information is scattered everywhere
|
||||
|
||||
* Multiple sources of security advisories
|
||||
** 80,000+ CVEs in the National Vulnerbility Database
|
||||
** Node Security Project, Metasploit, VulnDB, Snyk, ...
|
||||
** Thousands of website security advisories, blogs, tweets, ...
|
||||
* 600,000 GitHub events generated daily
|
||||
** 700 GitHub security related events
|
||||
** Release notes, change logs, code comments, ...
|
||||
|
||||
=== Summary
|
||||
|
||||
* It is not reasonable to expect a developer to continually research each component.
|
||||
* Developers are not security experts; they already have a day job.
|
||||
|
||||
@ -0,0 +1,23 @@
|
||||
== License Information Overload
|
||||
|
||||
=== What's important?
|
||||
|
||||
* Can I use this component within the context of distribution of my software?
|
||||
* Are there license incompatibilities?
|
||||
* If using a modified component, did I addressed additional license obligations?
|
||||
|
||||
=== License information is scattered everywhere
|
||||
|
||||
* Projects declare a license:
|
||||
** In a project metadata file.
|
||||
** On the project website or source code repository page.
|
||||
** Using a link to a license file in their own source code repository.
|
||||
** In a license file within the project source tree.
|
||||
** In the binary META-INF folder.
|
||||
* Projects include licenses as headers in the source code.
|
||||
|
||||
=== Summary
|
||||
|
||||
* It is difficult to determine the scope of a license.
|
||||
* A project often has license discrepancies.
|
||||
* Developers are not lawyers .
|
||||
@ -0,0 +1,25 @@
|
||||
== Architecture Information
|
||||
|
||||
=== What's important?
|
||||
|
||||
* Is my component old or is it stable
|
||||
* Is my component unpopular
|
||||
* Was my lack of upgrade a deliberate choice or a lack of knowledge
|
||||
|
||||
=== Summary
|
||||
|
||||
* It's really difficult to keep components up to date
|
||||
|
||||
====
|
||||
|
||||
For the components analyzed in 25,000 applications it was found that:
|
||||
|
||||
* 8% of 2 year old components did not have a newer version
|
||||
* 23% of 11 year old components did not have a newer version
|
||||
* Older components make up the majority of the risk
|
||||
|
||||
[cols="2a,2a"]
|
||||
|===
|
||||
| image::images/Old-Components.png[caption="Figure: ", title="Old Components", alt="Old Components", width="355", height="304", style="lesson-image"]
|
||||
| image::images/Risk-of-Old-Components.png[caption="Figure: ", title="Risk of Old Components", alt="Risk of Old Components", width="355", height="304", style="lesson-image"]
|
||||
|===
|
||||
@ -0,0 +1,15 @@
|
||||
== Some Examples of OSS Risk
|
||||
|
||||
=== Commons Collections
|
||||
In November of 2015, the Apache Commons Collections component latest release was 8 years old. Commons Collections was considered a reliable and stable component. A researcher found a way to exploit a deserialization issue in Commons Collections resulting in a remote code execution. The next day... *everyone using Commons Collections was in a panic*.
|
||||
|
||||
Ref: http://www.pcworld.com/article/3004633/business-security/thousands-of-java-applications-vulnerable-to-nine-month-old-remote-code-execution-exploit.html[Thousands of Java applications vulnerable to nine-month-old remote code execution exploit]
|
||||
|
||||
|
||||
=== Dinis Cruz and Alvaro Munoz exploit of XStream
|
||||
XStream, a relatively common XML and JSON parsing library, has a nasty little remote code execution. +
|
||||
Ref: http://blog.diniscruz.com/2013/12/xstream-remote-code-execution-exploit.html[Dinis Cruz Blog] +
|
||||
https://github.com/pwntester/XStreamPOC[pwntester/XStreamPOC]
|
||||
|
||||
You may want to read the article(s) before trying this lesson. Let's see if you can figure out how to exploit this in WebGoat.
|
||||
|
||||
@ -0,0 +1,14 @@
|
||||
== Exploiting http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7285[CVE-2013-7285] (XStream)
|
||||
|
||||
WebGoat Sends an XML document to add contacts to a contacts database.
|
||||
[source,xml]
|
||||
----
|
||||
<contact>
|
||||
<id>1</id>
|
||||
<firstName>Bruce</firstName>
|
||||
<lastName>Mayhew</lastName>
|
||||
<email>webgoat@owasp.org</email>
|
||||
</contact>
|
||||
----
|
||||
|
||||
For this example, we will let you enter the xml directly versus intercepting the request and modifying the data. You provide the XML representation of a contact and WebGoat will convert it a Contact object using `XStream.fromXML(xml)`.
|
||||
@ -0,0 +1,16 @@
|
||||
== Summary
|
||||
|
||||
* Open source consumption in modern day applications has increased.
|
||||
* Open source is obtained from many different repositories with different quality standards.
|
||||
* Security information on vulnerabilities is scattered everywhere.
|
||||
* License information is often difficult to validate.
|
||||
* Most teams don't have a component upgrade strategy.
|
||||
* *Open source components are the new attack vector.*
|
||||
|
||||
== What to do
|
||||
* Generate an OSS Bill of Materials.
|
||||
** Use http://lmgtfy.com/?q=OSS+bill+of+materials[automated tooling]
|
||||
* Baseline open source consumption in your organization.
|
||||
* Develop an open source component risk management strategy to mitigate current risk and reduce future risk.
|
||||
|
||||
|
||||
@ -0,0 +1,17 @@
|
||||
= Vulnerable Components
|
||||
|
||||
== Concept
|
||||
|
||||
The way we build software has changed. The open source community is maturing and the availability of open source software has become prolific without regard to determining the provenance of the libraries used in our applications. Ref: https://www.sonatype.com/hubfs/SSC/Software_Supply_Chain_Inforgraphic.pdf?t=1485298506170[Software Supply Chain]
|
||||
|
||||
This lesson will walk through the difficulties with managing dependent libraries, the risk of not managing those dependencies, and the difficulty in determining if you are at risk.
|
||||
|
||||
image::images/OpenSourceGrowing.png[caption="Figure: ", title="Software Supply Chain", alt="SSC", width="500", height="300", style="lesson-image" link="https://www.sonatype.com/hubfs/SSC/Software_Supply_Chain_Inforgraphic.pdf?t=1485298506170[Software Supply Chain"]
|
||||
|
||||
|
||||
== Goals
|
||||
|
||||
* Gain awareness that the open source consumed is as important as your own custom code.
|
||||
* Gain awareness of the management, or lack of management, in our open source component consumption.
|
||||
* Understand the importance of a Bill of Materials in determining open source component risk
|
||||
|
||||
Reference in New Issue
Block a user