#304 update to IDOR. Still experiencing 400 on EditOwnProfile endpoint

This commit is contained in:
Jason White
2017-01-06 13:04:03 -05:00
parent c2988eb771
commit fe4f568fc0
11 changed files with 94 additions and 30 deletions

View File

@ -127,6 +127,36 @@
</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_eidtOwn.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>
<!-- 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,

View File

@ -0,0 +1,4 @@
==== Edit Your Own Profile
If an application only exposes a way to view your profile or some object (i.e. 'GET' in RESTful), that does not mean you cannot edit it.
Use your intercept proxy to modify the request such that it would modify your profile. Change the color from 'yellow' to 'black' (sans single quotes).

View File

@ -0,0 +1,7 @@
=== Authenticate First, Abuse Authorization Later
Many access control issues are succeptible to attack from an authenticated-but-unauthorized user. So, let's start by legitimately authenticating. Then, we will look for ways to bypass or abuse Authorization.
The id and password for the account in this case are 'tom' and 'cat' (It is an insecure app, right?).
After authenticating, proceed to the next screen.

View File

@ -1,6 +1,7 @@
=== Guessing & Predicting Patterns
==== View Your Own Profile Another Way
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 using a direct object reference?
So, what do you think is a likely pattern to view your own profile explicitly using a direct object reference?