dubey/WebGoat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial/partial commit of IDOR lesson

Browse Source
This commit is contained in:
Jason White
2017-01-05 17:30:53 -05:00
parent 00eeae911d
commit 65eaa934ea
18 changed files with 763 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

137
webgoat-lessons/idor/src/main/resources/plugin/IDOR/html/IDOR.html Normal file
View File

@ -0,0 +1,137 @@
<html xmlns:th="http://www.thymeleaf.org">
<div class="lesson-page-wrapper">
<!-- reuse this lesson-page-wrapper block for each 'page' of content in your lesson -->
<!-- include content here, or can be placed in another location. Content will be presented via asciidocs files,
which you put in src/main/resources/plugin/lessonplans/{lang}/{fileName}.adoc -->
<div class="adoc-content" th:replace="doc:IDOR_intro.adoc"></div>
</div>
<div class="lesson-page-wrapper">
<!-- reuse this lesson-page-wrapper block for each 'page' of content in your lesson -->
<!-- include content here, or can be placed in another location. Content will be presented via asciidocs files,
which you put in src/main/resources/plugin/lessonplans/{lang}/{fileName}.adoc -->
<div class="adoc-content" th:replace="doc:IDOR_login.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 class="lessonContent">
<!-- using attack-form class on your form will allow your request to be ajaxified and stay within the display framework for webgoat -->
<!-- you can write your own custom forms, but standard form submission will take you to your endpoint and outside of the WebGoat framework -->
<!-- of course, you can write your own ajax submission /handling in your own javascript if you like -->
<!-- modify the action to point to the intended endpoint -->
<form class="attack-form" accept-charset="UNKNOWN"
method="POST" name="form"
action="/WebGoat/IDOR/login"
enctype="application/json;charset=UTF-8">
<table>
<tr>
<td>user/pass</td>
<td>user:<input name="username" value="" type="TEXT" /></td>
<td>pass:<input name="password" value="" type="password" /></td>
<td>
<input
name="submit" value="Submit" type="SUBMIT"/>
</td>
</tr>
</table>
</form>
</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="lesson-page-wrapper">
<!-- reuse this lesson-page-wrapper block for each 'page' of content in your lesson -->
<!-- include content here, or can be placed in another location. Content will be presented via asciidocs files,
which you put in src/main/resources/plugin/lessonplans/{lang}/{fileName}.adoc -->
<div class="adoc-content" th:replace="doc:IDOR_viewDiffs.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>
<!-- using attack-form class on your form will allow your request to be ajaxified and stay within the display framework for webgoat -->
<!-- you can write your own custom forms, but standard form submission will take you to your endpoint and outside of the WebGoat framework -->
<!-- of course, you can write your own ajax submission /handling in your own javascript if you like -->
<!-- modify the action to point to the intended endpoint -->
<form class="attack-form" accept-charset="UNKNOWN"
method="GET" name="form"
action="/WebGoat/IDOR/profile"
enctype="application/json;charset=UTF-8">
<script th:src="@{/plugin_lessons/plugin/IDOR/js/idor.js}" />
<input name="View Profile" value="View Profile" type="button" onclick="onViewProfile();" />
</form>
</div>
<div id="idor-profile"></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 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 class="lessonContent">
<!-- using attack-form class on your form will allow your request to be ajaxified and stay within the display framework for webgoat -->
<!-- you can write your own custom forms, but standard form submission will take you to your endpoint and outside of the WebGoat framework -->
<!-- of course, you can write your own ajax submission /handling in your own javascript if you like -->
<div class="adoc-content" th:replace="doc:IDOR_whatDiffs.adoc"></div>
<!-- modify the action to point to the intended endpoint -->
<form class="attack-form"
method="POST" name="diff-form"
action="IDOR/diff-attributes"
enctype="application/json;charset=UTF-8">
<input name="attributes" type="text" />
<input name="Submit Diffs" value="Submit Diffs" type="submit" />
</form>
</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="lesson-page-wrapper">
<!-- reuse this lesson-page-wrapper block for each 'page' of content in your lesson -->
<!-- include content here, or can be placed in another location. Content will be presented via asciidocs files,
which you put in src/main/resources/plugin/lessonplans/{lang}/{fileName}.adoc -->
<div class="adoc-content" th:replace="doc:IDOR_viewOwnAltPath.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 class="lessonContent">
<!-- using attack-form class on your form will allow your request to be ajaxified and stay within the display framework for webgoat -->
<!-- you can write your own custom forms, but standard form submission will take you to your endpoint and outside of the WebGoat framework -->
<!-- of course, you can write your own ajax submission /handling in your own javascript if you like -->
<!-- modify the action to point to the intended endpoint -->
<form class="attack-form" accept-charset="UNKNOWN"
method="POST" name="form"
action="/WebGoat/IDOR/profile/alt-path"
enctype="application/json;charset=UTF-8">
<div class="adoc-content" th:replace="doc:IDOR_inputAltPath.adoc"></div>
<input name="url" value="WebGoat/" type="text"/>
<input name="submit" value="Submit" type="SUBMIT"/>
</form>
</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="lesson-page-wrapper">
<!-- reuse this lesson-page-wrapper block for each 'page' of content in your lesson -->
<!-- include content here, or can be placed in another location. Content will be presented via asciidocs files,
which you put in src/main/resources/plugin/lessonplans/{lang}/{fileName}.adoc -->
<div class="adoc-content" th:replace="doc:IDOR_mitigation.adoc"></div>
</div>
</html>

18
webgoat-lessons/idor/src/main/resources/plugin/IDOR/js/idor.js Normal file
View File

@ -0,0 +1,18 @@
// need custom js for this?
webgoat.customjs.idorViewProfile = function(data) {
webgoat.customjs.jquery('#idor-profile').html(
'name:' + data.name + '<br/>'+
'color:' + data.color + '<br/>'+
'size:' + data.size + '<br/>'
);
}
var onViewProfile = function () {
console.warn("on view profile activated")
webgoat.customjs.jquery.ajax({
method: "GET",
url: "/WebGoat/IDOR/profile",
contentType: 'application/json; charset=UTF-8'
}).then(webgoat.customjs.idorViewProfile);
}

1
webgoat-lessons/idor/src/main/resources/plugin/IDOR/lessonPlans/en/IDOR_inputAltPath.adoc Normal file
View File

@ -0,0 +1 @@
Please input the alternate path to the Url to view your own profile. Please start witih 'WebGoat' (i.e. disregard 'http://localhost:8080/')

37
webgoat-lessons/idor/src/main/resources/plugin/IDOR/lessonPlans/en/IDOR_intro.adoc Normal file
View File

@ -0,0 +1,37 @@
== Direct Object References
Direct Object References are when an application uses client-provided input to access data & objects.
=== Examples
Examples of Direct Object References using the GET method may look something like
`https://some.company.tld/dor?id=12345`
`https://some.company.tld/images?img=12345`
`https://some.company.tld/dor/12345`
=== Other Methods
POST, PUT, DELETE or other methods are also potentially succeptible and mainly only differ in the method and the potential payload.
== *Insecure* Direct Object References
These are considered insecure when the reference is not properly handled and allows for authorization bypasses.
Let's say that as a user, you go to view your profile and the URL looks something like:
`https://some.company.tld/app/user/23398`
\... and you can view your profile there. What happens if you navigate to:
`https://some.company.tld/app/user/23399` ... or use another number at the end. If you can manipulate the number (user id) and view another's profile, then the object reference is insecure.
This of course can be checked or expanded beyond GET methods to view data, but to also manipulate data.
=== More good reading
Before we go on to practice, here's some good reading on Insecure Direct Object References:
* https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)
* https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
* http://cwe.mitre.org/data/definitions/639.html

10
webgoat-lessons/idor/src/main/resources/plugin/IDOR/lessonPlans/en/IDOR_mitigation.adoc Normal file
View File

@ -0,0 +1,10 @@
== Secure Object References
=== Using Indrect References
In some cases, using an indirect reference may help. This of course may make the application harder to trouble shoot and may also affect performance.
=== Access Controls
Since the root of 'Insecure' of IDOR's s really in controlling access to the objects referenced, the key to making them secure is implementing vertical and horizontal access control.
==== Knowing How Things Should be Secured

6
webgoat-lessons/idor/src/main/resources/plugin/IDOR/lessonPlans/en/IDOR_viewDiffs.adoc Normal file
View File

@ -0,0 +1,6 @@
=== Observing Differences & Behaviors
A consistent principle from the offensive side of AppSec is to view differences from the raw response to what is visible.
In other words (as you may have already noted in the client-side filtering lesson), there is often data in the raw response that doesn't show up on the screen/page.
View the profile below and take note of the differences.

6
webgoat-lessons/idor/src/main/resources/plugin/IDOR/lessonPlans/en/IDOR_viewOwnAltPath.adoc Normal file
View File

@ -0,0 +1,6 @@
=== Guessing & Predicting Patterns
The application we are working with seems to follow a RESTful pattern so far as the profile goes. Many apps have roles in which an elevated user may access content of another.
In that case, just /profile won't work since the own user's session/authentication data won't tell us whose profile they want view.
So, what do you think is a likely pattern to view your own profile explicitly?

1
webgoat-lessons/idor/src/main/resources/plugin/IDOR/lessonPlans/en/IDOR_whatDiffs.adoc Normal file
View File

@ -0,0 +1 @@
In the text input below, list the two attributes that are in the server's response, but don't show above in the profile.

15
webgoat-lessons/idor/src/main/resources/plugin/IDOR/lessonPlans/en/temp.txt Normal file
View File

@ -0,0 +1,15 @@
- Describe how the attack works / should be some outpu
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform XML External Entity Attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
An XML External Entity attack is a type of attack against an application that parses XML input.
This attack occurs when XML input containing a reference to an external entity is processed by a weakly
configured XML parser. This attack may lead to the disclosure of confidential data, denial of service,
server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.