XSS lesson updates
This commit is contained in:
Jason White
@ -78,7 +78,7 @@
|
||||
<!-- 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 -->
|
||||
<form class="attack-form" accept-charset="UNKNOWN"
|
||||
method="POST" name="form"
|
||||
method="GET" name="xss-5a"
|
||||
action="/WebGoat/CrossSiteScripting/attack5a"
|
||||
enctype="application/json;charset=UTF-8">
|
||||
<hr width="90%" />
|
||||
@ -161,11 +161,27 @@
|
||||
<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:CrossSiteScripting_content5b.adoc"></div>
|
||||
<div class="attack-container">
|
||||
<form class="attack-form" accept-charset="UNKNOWN"
|
||||
method="POST" name="xss-5b"
|
||||
action="/WebGoat/CrossSiteScripting/attack5b"
|
||||
enctype="application/json;charset=UTF-8">
|
||||
<input size="4" value="" name="isReflectedXSS" type="text" />
|
||||
<input type="submit" name="reflectedXssSubmit" value="Submit"/>
|
||||
</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">
|
||||
<!-- 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:CrossSiteScripting_content6.adoc"></div>
|
||||
</div>
|
||||
<div class="lesson-page-wrapper">
|
||||
@ -180,18 +196,11 @@
|
||||
<!-- 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 -->
|
||||
<form class="attack-form" accept-charset="UNKNOWN"
|
||||
method="POST" name="form"
|
||||
method="POST" name="DOMTestRoute"
|
||||
action="/WebGoat/CrossSiteScripting/attack6a"
|
||||
enctype="application/json;charset=UTF-8">
|
||||
<table>
|
||||
<tr>
|
||||
<td>Name:</td>
|
||||
<td><input name="userid_6a" value="" type="TEXT" /></td>
|
||||
<td><input
|
||||
name="Get Account Info" value="Get Account Info" type="SUBMIT"/></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</table>
|
||||
<input name="DOMTestRoute" value="" type="TEXT" />
|
||||
<input name="SubmitTestRoute" value="Submit" type="SUBMIT"/>
|
||||
</form>
|
||||
<!-- do not remove the two following div's, this is where your feedback/output will land -->
|
||||
<div class="attack-feedback"></div>
|
||||
|
||||
@ -1,14 +1,21 @@
|
||||
== What is XSS
|
||||
|
||||
NEED DEFINITION.
|
||||
Cross-site script (also commonly known as XSS) is a vulnerability/flaw that combines ...
|
||||
# the allowance of html/script tags as input that are ...
|
||||
# rendred into a browser without encoding or sanitization
|
||||
|
||||
==== Cross site scripting (XSS) is the most prevalent and pernicious web application security issue
|
||||
=== Cross site scripting (XSS) is the most prevalent and pernicious web application security issue
|
||||
|
||||
==== XSS flaws occur whenever an application takes user originated data and sends it to a web browser without validation or encoding
|
||||
While there is a simple well-known defense for this attack, there are still many instances of it on the web. In terms of fixing it,
|
||||
coverage of fixes also tends to be a problem. We'll talk more about the defense in a little bit.
|
||||
|
||||
=== XSS allows attackers to execute script in the victim’s browser and take over the user’s browser using scripting malware
|
||||
=== XSS has a significant impact
|
||||
|
||||
==== Examples:
|
||||
Especially as 'Rich Internet Applications' are more and more common place, privileged function calls linked to via javascript may be compromised.
|
||||
And if not properly protected, sensitive data (such as your authentication cookies) can be stolen and used for someone else's purpose.
|
||||
|
||||
|
||||
==== Quick examples:
|
||||
* From the browser address bar (chrome, Firefox)
|
||||
+
|
||||
----
|
||||
@ -22,4 +29,5 @@ javascript:alert(document.cookie);
|
||||
----
|
||||
|
||||
== Try It! Using Chrome or Firefox
|
||||
Type in `javascript:alert(document.cookie);` in the URL bar. If you /cut/paste you'll need to add the `javascript:` back in. Try it on a different tab.
|
||||
Type in `javascript:alert(document.cookie);` in the URL bar. *NOTE:* If you /cut/paste you'll need to add the `javascript:` back in.
|
||||
Try it on a different tab (with WebGoat open in that tab).
|
||||
|
||||
@ -11,7 +11,7 @@
|
||||
* Insertion of hostile and inappropriate content
|
||||
+
|
||||
----
|
||||
<img src=“http://pornsite.com/image.jpg/>
|
||||
<img src=“http://malicious.site.com/image.jpg/>
|
||||
“>GoodYear recommends buying BridgeStone tires…
|
||||
----
|
||||
|
||||
|
||||
@ -2,13 +2,14 @@
|
||||
|
||||
=== Reflected
|
||||
* Malicious content from a user request is displayed to the user in a web browser
|
||||
* Malicious content is written into the page via server code
|
||||
* Malicious content is written into the page after from server response
|
||||
* Social engineering is required
|
||||
* Runs with browser privileges inherited from user in browser
|
||||
|
||||
=== Local: DOM-based
|
||||
=== DOM-based (also technically reflected)
|
||||
* Malicious content from a user request is used by client-side scripts to write HTML to it own page
|
||||
* Similar to reflected XSS
|
||||
* Runs with browser privileges
|
||||
* Runs with browser privileges inherited from user in browser
|
||||
|
||||
=== Stored or Persistent
|
||||
* Malicious content is stored on the server ( in a database, file system, or other object ) and later displayed to users in a web browser
|
||||
|
||||
@ -2,5 +2,7 @@
|
||||
|
||||
Identify which field is susceptible to XSS
|
||||
|
||||
It is always a good practice to validate all input on the server side. XSS can occur when unvalidated user input is used in an HTTP response. In a reflected XSS attack, an attacker can craft a URL with the attack script and post it to another website, email it, or otherwise get a victim to click on it.
|
||||
It is always a good practice to validate all input on the server side. XSS can occur when unvalidated user input is used in an HTTP response.
|
||||
In a reflected XSS attack, an attacker can craft a URL with the attack script and post it to another website, email it, or otherwise get a victim to click on it.
|
||||
|
||||
Make sure to include in your attack payload "<script>alert('my javascript here')</script>".
|
||||
@ -1,4 +1,5 @@
|
||||
== Was it Really Reflected XSS?
|
||||
|
||||
Now, was the last attack truly reflected XSS?
|
||||
You should have been able to execute script with the last example. Was it truly reflected XSS?
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,9 @@
|
||||
== Was it Really Reflected XSS?
|
||||
|
||||
The last example was not truly reflected XSS ... Why you say?
|
||||
# Can you execute it by changing the URL? (No)
|
||||
# If you do follow the actual payload in a new tab, does it execute the script? (No ... go ahead and give it a try)
|
||||
|
||||
The reason for #2 is that the response type
|
||||
|
||||
|
||||
@ -1,10 +1,12 @@
|
||||
== DOM-Based XSS Scenario
|
||||
|
||||
DOM-based XSS is similar to reflected. The difference is that the payload will never go to the server, but will only ever be processed by the client.
|
||||
|
||||
* Attacker sends a malicious URL to victim
|
||||
* Victim clicks on the link that loads malicious web page
|
||||
* The malicious web page's JavaScript opens a local web page on the victims machine that contains an attack
|
||||
* The local page executes attack in the computer’s local zone
|
||||
* Victim clicks on the link
|
||||
* That link may load a malicious web page or a web page they use (are logged into?) that has a vulnerable route/handler
|
||||
* If it's a malicious web page, it may use it's own JavaScript to attack another page/url with a vulnerable route/handler
|
||||
* The vulnerable page renders the payload and executes attack in the user's context on that page/site
|
||||
* Attacker’s malicious script may run commands with the privileges of local account
|
||||
|
||||
*Victim does not realize attack occurred*
|
||||
|
||||
*Victim does not realize attack occurred* ... Malicious attackers don't use <script>alert('xss')</ script>
|
||||
@ -1,3 +1,12 @@
|
||||
== Try It! DOM-Based XSS
|
||||
|
||||
Need A Lesson
|
||||
For this, you'll want to look for some 'test' code in the route handlers (javascript/backbone). Sometimes, test code gets left in.
|
||||
(Often times test code is very simple and lacks security or any quality controls!).
|
||||
|
||||
Your objective is to find the route and exploit it. First though ... what is the base route? As an example, look at the URL for this lesson ...
|
||||
it should look something like /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/5 (although maybe slightly different). The 'base route' in this case is:
|
||||
*start.mvc#lesson/*
|
||||
|
||||
The *CrossSiteScripting.lesson/5* after that are parameters that are processed by javascript route handler.
|
||||
|
||||
So, what is test route for this test code?
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
#StringSqlInjection.java
|
||||
StringSqlInjectionSecondStage=Now that you have successfully performed an SQL injection, try the same type of attack on a parameterized query. Restart the lesson if you wish to return to the injectable query.
|
||||
EnterLastName=Enter your last name:
|
||||
NoResultsMatched=No results matched. Try Again.
|
||||
SqlStringInjectionHint1=The application is taking your input and inserting it at the end of a pre-formed SQL command.
|
||||
SqlStringInjectionHint2=This is the code for the query being built and issued by WebGoat:<br><br> "SELECT * FROM user_data WHERE last_name = "accountName"
|
||||
SqlStringInjectionHint3=Compound SQL statements can be made by joining multiple tests with keywords like AND and OR. Try appending a SQL statement that always resolves to true
|
||||
SqlStringInjectionHint4=Try entering [ smith' OR '1' = '1 ].
|
||||
# XSS success, failure messages and hints
|
||||
xss-reflected-5a-success=well done, but alerts aren't very impressive are they? Please continue.
|
||||
xss-reflected-5a-failure=Try again. We do want to see this specific javascript (in case you are trying to do something more fancy)
|
||||
xss-reflected-5b-success=Correct ... because <ul><li>The script was not triggered by the URL/QueryString</li><li>Even if you use the attack URL in a new tab, it won't execute (becuase of response type). Try it if you like.</li></ul>
|
||||
xss-reflected-5b-failure=Nope, pretty easy to guess now though.
|
||||
xss-reflected-6a-success=Correct! Now, see if you can send in an exploit to that route in the next assignment.
|
||||
xss-reflected-6a-failure=No, look at the example. Check the GoatRouter.js file. It should be pretty easy to determine.
|
||||
xss.lesson1.failure=Are you sure? Try using a tab from a different site.
|
||||
|
||||
xss.lesson1.failure=Are you sure? Try using a tab from a different site.
|
||||
#xss-reflected-5b-do5a-first=Do the reflected xss attack prior to this, then come back and answer this.
|
||||
Reference in New Issue
Block a user