Renamed to vulnerablecomponents

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content0.adoc

@@ -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
+

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content1.adoc

@@ -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"]

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content1a.adoc

@@ -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"]
+

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content2.adoc

@@ -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.
+

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content2a.adoc

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

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content3.adoc

@@ -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?

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content4.adoc

@@ -0,0 +1,60 @@
+== 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. You can add OWASP Dependency check as a plugin to the pom.xml of a Maven project for instance. The plugin will download information from public vulnerability databases and it will check if vulnerable libraries are used and will indicate which vulnerability was reported.
+
+As part of a development pipeline, you can instruct the plugin to fail the build if there are violations that the development team was not aware of. Additionally you can use an xml file to waiver some of the violations. You should do so if the mentioned vulnerability cannot be exploited in your application.
+
+In the parent pom.xml from WebGoat you can see an example:
+
+[source,xml]
+----
+<plugin>
+	<groupId>org.owasp</groupId>
+	<artifactId>dependency-check-maven</artifactId>
+	<version>5.3.2</version>
+	<configuration>
+		<failBuildOnCVSS>7</failBuildOnCVSS>
+		<skipProvidedScope>true</skipProvidedScope>
+		<skipRuntimeScope>true</skipRuntimeScope>
+		<suppressionFiles>
+			<suppressionFile>project-suppression.xml</suppressionFile>
+		</suppressionFiles>
+	</configuration>
+	<executions>
+		<execution>
+			<goals>
+				<goal>check</goal>
+			</goals>
+		</execution>
+	</executions>
+</plugin>
+---- 
+
+And also an example of the suppressed violations. 
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
+    <suppress base="true">
+        <cpe>cpe:/a:pivotal_software:spring_security</cpe>
+        <cve>CVE-2018-1258</cve>
+    </suppress>
+    <suppress base="true"><!-- webgoat-server -->
+        <cpe>cpe:/a:postgresql:postgresql</cpe>
+        <cve>CVE-2018-10936</cve>
+    </suppress>
+</suppressions>
+----
+
+In the case of WebGoat, the plugin is activated when the following is run (owasp profile):
+
+	mvn clean install -Powasp
+	
+Below is a snippet of a report, which can be found in e.g. webgoat-container/target/dependency-check-report.html:
+
+image::images/OWASP-Dep-Check.png[caption="Figure: ", title="WebGoat Bill of Materials", alt="BoM", width="988", height="515", style="lesson-image"]
+
+ 

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content4a.adoc

@@ -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.
+

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content4b.adoc

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

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content4c.adoc

@@ -0,0 +1,23 @@
+== 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"]
+|===

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content5.adoc

@@ -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: https://diniscruz.blogspot.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.
+

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content5a.adoc

@@ -0,0 +1,18 @@
+== Exploiting http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7285[CVE-2013-7285] (XStream)
+
+NOTE: This lesson only works when you are using the Docker image of WebGoat.
+
+WebGoat uses 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>  
+----
+
+The java interface that you need for the exercise is: org.owasp.webgoat.vulnerablecomponents.Contact.
+Start by sending the above contact to see what the normal response would be and then read the CVE vulnerability  documentation (search the Internet) and try to trigger the vulnerability.
+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)`.

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_content6.adoc

@@ -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.
+
+

src/main/resources/lessons/vulnerablecomponents/documentation/VulnerableComponents_plan.adoc

@@ -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
+

src/main/resources/lessons/vulnerablecomponents/html/VulnerableComponents.html

@@ -0,0 +1,126 @@
+<!DOCTYPE html>
+
+<html xmlns:th="http://www.thymeleaf.org">
+
+    <link rel="stylesheet" type="text/css" href="http://code.jquery.com/ui/1.9.1/themes/base/jquery-ui.css" />
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_plan.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content0.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content1.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content1a.adoc"></div>
+	</div>
+
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content2.adoc"></div>
+		<div class="attack-container">
+			<!-- using attack-form class on your form, will allow your request to be ajaxified and stay within the display framework for webgoat -->
+			<div id="lessonContent">
+        			<table>
+						<tr>
+							<td>Clicking go will execute a jquery-ui close dialog:</td>
+							<td><input id="closetext" value="OK<script>alert('XSS')</script>" type="TEXT" /><input
+								name="SUBMIT" value="Go!" type="SUBMIT" onclick="webgoat.customjs.vuln_jquery_ui()" /></td>
+							<td></td>
+						</tr>
+					</table>
+					<script th:inline="javascript">
+					/*<![CDATA[*/
+					webgoat.customjs.vuln_jquery_ui = function()
+					{
+						webgoat.customjs.jqueryVuln('#dialog').dialog({ closeText: webgoat.customjs.jquery('#closetext').val() });
+		        	};
+					/*]]>*/
+						</script>
+				<div id="dialog" title="jquery-ui-1.10.4">This dialog should have exploited a known flaw in jquery-ui:1.10.4 and allowed a XSS attack to occur</div>
+				<!-- do not remove the two following div's, this is where your feedback/output will land -->
+				<div class="attack-feedback"></div>
+				<div class="attack-output"></div>
+				<!-- ... of course, you can move them if you want to, but that will not look consistent to other lessons -->
+			</div>
+
+		</div>
+		<div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content2a.adoc"></div>
+		<div class="attack-container">
+			<!-- using attack-form class on your form, will allow your request to be ajaxified and stay within the display framework for webgoat -->
+			<div id="lessonContent">
+        			<table>
+						<tr>
+							<td>Clicking go will execute a jquery-ui close dialog:</td>
+							<td><input id="closetext2" value="OK<script>alert('XSS')</script>" type="TEXT" /><input
+								name="SUBMIT" value="Go!" type="SUBMIT" onclick="webgoat.customjs.jquery_ui()" /></td>
+							<td></td>
+						</tr>
+					</table>
+					<script th:inline="javascript">
+					/*<![CDATA[*/
+					webgoat.customjs.jquery_ui = function()
+					{
+						webgoat.customjs.jquery('#dialog2').dialog({ closeText: webgoat.customjs.jquery('#closetext2').val() });
+		        	};
+					/*]]>*/
+						</script>
+				<div id="dialog2" title="jquery-ui-1.12.0">This dialog should have prevented the above exploit using the EXACT same code in WebGoat but using a later version of jquery-ui.</div>
+				<!-- do not remove the two following div's, this is where your feedback/output will land -->
+				<div class="attack-feedback"></div>
+				<div class="attack-output"></div>
+				<!-- ... of course, you can move them if you want to, but that will not look consistent to other lessons -->
+			</div>
+
+		</div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content3.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content4.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content4a.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content4b.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content4c.adoc"></div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content5.adoc"></div>
+	</div>
+	
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content5a.adoc"></div>
+		<div class="attack-container">
+			<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+			<form class="attack-form" accept-charset="UNKNOWN"
+				method="POST" name="form"
+				action="/WebGoat/VulnerableComponents/attack1">
+				<div id="lessonContent">
+					<form accept-charset="UNKNOWN" method="POST" name="form"
+						action="#attack/307/100">
+						<table>
+							<tr>
+								<td>Enter the contact's xml representation:</td>
+								<td><textarea name="payload" value="" type="TEXT" rows="15" cols="60"/></td>
+								<td><input name="SUBMIT" value="Go!" type="SUBMIT"/></td>
+							</tr>
+						</table>
+					</form>
+				</div>
+			</form>
+			<!-- do not remove the two following div's, this is where your feedback/output will land -->
+			<div class="attack-feedback"></div>
+			<div class="attack-output"></div>
+			<!-- ... of course, you can move them if you want to, but that will not look consistent to other lessons -->
+		</div>
+	</div>
+	<div class="lesson-page-wrapper">
+        <div class="adoc-content" th:replace="doc:lessons/vulnerablecomponents/documentation/VulnerableComponents_content6.adoc"></div>
+	</div>
+	
+</html>

src/main/resources/lessons/vulnerablecomponents/i18n/WebGoatLabels.properties

@@ -0,0 +1,6 @@
+vulnerable-components.title=Vulnerable Components
+EnterYourName=Enter your Name
+vulnerable.hint=Did you search for CVE-2013-728 and read https://x-stream.github.io/CVE-2013-7285.html
+vulnerable-components.close=The payload send could not be deserialized to a Contact class. Please try again.
+vulnerable-components.success=You successfully tried to exploit the CVE-2013-7285 vulnerability
+vulnerable-components.fromXML=You created contact {0}.  This means you did not exploit the remote code execution.