#304 update to IDOR. Still experiencing 400 on EditOwnProfile endpoint
This commit is contained in:
@ -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,
|
||||
|
@ -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).
|
@ -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.
|
@ -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?
|
Reference in New Issue
Block a user