Update documentation

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScriptingMitigation_plan.adoc

@@ -1,7 +1,7 @@
 == Concept 
 
 After learning what Cross-Site Scripting (XSS) is and how it works,
-you will know learn how you can defend against it.
+you will know to learn how you can defend against it.
 
 == Goals
 

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScriptingStored_plan.adoc

@@ -1,8 +1,8 @@
 == Concept 
 
-After taking a look at Reflected XSS in the previous lesson. We are now gonna take a closer look at another form of Cross-Site Scripting Attack: Stored XSS.
+After looking at Reflected XSS in the previous lesson, we are now going to take a closer look at another form of Cross-Site Scripting Attack: Stored XSS.
 
 == Goals
 * The user will learn what Stored XSS is
 * The user will demonstrate knowledge on:
-** Stored XSS injection
+** Stored XSS injection

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content1.adoc

@@ -1,16 +1,15 @@
 == What is XSS?
 
-Cross-Site Scripting (also commonly known as XSS) is a vulnerability/flaw that combines the allowance of html/script tags as input that are rendered into a browser without encoding or sanitization
+Cross-Site Scripting (also known as XSS) is a vulnerability/flaw that combines the allowance of HTML/script tags as input that renders into a browser without encoding or sanitization.
 
 === Cross-Site Scripting (XSS) is the most prevalent and pernicious web application security issue
 
-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 will talk more about the defense in a little bit.
+While there is a simple well-known defense for this attack, there are still many instances on the web.  Coverage of fixes also tends to be a problem in terms of fixing it. We will talk more about the defense in a little bit.
 
 === XSS has significant impact
 
 Especially as 'Rich Internet Applications' are more and more commonplace, 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.
+And if not adequately protected, sensitive data (such as your authentication cookies) can be stolen and used for someone else's purpose.
 
 
 ==== Quick examples:
@@ -20,14 +19,14 @@ And if not properly protected, sensitive data (such as your authentication cooki
 alert("XSS Test");
 alert(document.cookie);
 ----
-* Any data field that is returned to the client is potentially injectable
+* Any data field returned to the client is potentially injectable
 +
 ----
 <script>alert("XSS Test")</script>
 ----
 
 == Try It!  Using Chrome or Firefox
 
-* Open a second tab and use the same url as this page you are currently on (or any URL within this instance of WebGoat).
-* Then, on that second tab open the browser developer tools and open the javascript console. And type:  `alert(document.cookie);`.
+* Open a second tab and use the same URL as this page you are currently on (or any URL within this instance of WebGoat).
+* On the second tab, open the JavaScript console in the developer tools  and type:  `alert(document.cookie);`.
 * The cookies should be the same on each tab.

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content2.adoc

@@ -4,11 +4,11 @@
 
 * Input fields that echo user data
 
-* Error messages that return user supplied text
+* Error messages that return user-supplied text
 
-* Hidden fields that contain user supplied data
+* Hidden fields that contain user-supplied data
 
-* Any page that displays user supplied data
+* Any page that displays user-supplied data
 ** Message boards
 ** Free form comments
 

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content4.adoc

@@ -4,14 +4,13 @@
 * Malicious content from a user request is displayed to the user in a web browser
 * Malicious content is written into the page after from server response
 * Social engineering is required
-* Runs with browser privileges inherited from user in browser
+* Runs with browser privileges inherited from the user in a browser
 
 === 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 inherited from user in browser
+* Client-side scripts use malicious content from a user request to write HTML to its page
+* Similar to reflected XSS
+* Runs with browser privileges inherited from the user in a 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
+* Malicious content is stored on the server ( in a database, file system, or other objects) and later displayed to users in a web browser
 * Social engineering is not required
-

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content5.adoc

@@ -1,7 +1,7 @@
 == Reflected XSS scenario
 
-* Attacker sends a malicious URL to victim 
-* Victim clicks on the link that loads malicious web page
+* Attacker sends a malicious URL to the victim
+* Victim clicks on the link that loads a malicious web page
 * The malicious script embedded in the URL executes in the victim’s browser
 ** The script steals sensitive information, like the session id, and releases it to the attacker
 

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content5a.adoc

@@ -1,8 +1,8 @@
 == Try It! Reflected XSS
 
-The goal of the assignment is to identify which field is susceptible to XSS.
+The assignment's goal is to 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 gets used in an HTTP response.
+It is always a good practice to validate all input on the server side. XSS can occur when unvalidated user input gets 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.
 
-An easy way to find out if a field is vulnerable to an XSS attack is to use the `alert()` or `console.log()` methods. Use one of them to find out which field is vulnerable.
+An easy way to find out if a field is vulnerable to an XSS attack is to use the `alert()` or `console.log()` methods. Use one of them to find out which field is vulnerable.

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content5b.adoc

@@ -1,10 +1,10 @@
 == Self XSS or reflected XSS?
 
-You should have been able to execute script with the last example. At this point, it would be considered 'self XSS' though.
+You should have been able to execute the script with the last example. At this point, it is considered 'self XSS,' though.
 
 Why is that?
 
-That is because there is no link that would trigger that XSS.
+That is because no link triggers that XSS.
 You can try it yourself to see what happens ... go to:
 
 link:/WebGoat/CrossSiteScripting/attack5a?QTY1=1&QTY2=1&QTY3=1&QTY4=1&field1=<script>alert('my%20javascript%20here')</script>4128+3214+0002+1999&field2=111["/WebGoat/CrossSiteScripting/attack5a?QTY1=1&QTY2=1&QTY3=1&QTY4=1&field1=<script>alert('my%20javascript%20here')</script>4128+3214+0002+1999&field2=111",window=_blank]

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content6.adoc

@@ -1,14 +1,14 @@
 == Reflected and DOM-Based XSS
 
-DOM-based XSS is another form of reflected XSS. Both are triggered by sending a link with inputs that are reflected to the browser.
-The difference between DOM and 'traditional' reflected XSS is that, with DOM, the payload will never go to the server.  It will only ever be processed by the client.
+DOM-based XSS is another form of reflected XSS. Both are triggered by sending a link with inputs reflected in the browser.
+The difference between DOM and 'traditional' reflected XSS is that, with DOM, the payload will never go to the server.  The client will only ever process it.
 
 
-* Attacker sends a malicious URL to victim
+* Attacker sends a malicious URL to the victim
 * 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
+* If it's a  malicious web page, it may use its own JavaScript to attack another page/URL with a vulnerable route/handler
+* The vulnerable page renders the payload and executes an 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* ... Malicious attackers don't use <script>alert('xss')</ script>
+*Victim does not realize attack occurred* ... Malicious attackers don't use <script>alert('xss')</ script>

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content6a.adoc

@@ -1,15 +1,15 @@
 == Identify potential for DOM-Based XSS
 
 DOM-Based XSS can usually be found by looking for the route configurations in the client-side code.
-Look for a route that takes inputs that are being "reflected" to the page.
+Look for a route that takes inputs that are "reflected" to the page.
 
 For this example, you will want to look for some 'test' code in the route handlers (WebGoat uses backbone as its primary JavaScript library).
-Sometimes, test code gets left in production (and often times test code is very simple and lacks security or any quality controls!).
+Sometimes, test code gets left in production (and often test code is simple and lacks security or 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 ...
+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/9. The 'base route' in this case is:
 *start.mvc#lesson/*
 The *CrossSiteScripting.lesson/9* after that are parameters that are processed by the JavaScript route handler.
 
 So, what is the route for the test code that stayed in the app during production?
-To answer this question, you have to check the JavaScript source.
+To answer this question, you have to check the JavaScript source.

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content6b.adoc

@@ -1,11 +1,11 @@
 == Try It!   DOM-Based XSS
 
-Some attacks are "blind". Fortunately, you have the server running here so you will be able to tell if you are successful.
-Use the route you just found and see if you can use the fact that it reflects a parameter from the route without encoding to execute an internal function in WebGoat.
-The function you want to execute is ...
+Some attacks are "blind." Fortunately, you have the server running here, so you can tell if you are successful.
+Use the route you just found and see if you can use it to reflect a parameter from the route without encoding to execute an internal function in WebGoat.
+The function you want to execute is:
 
 *webgoat.customjs.phoneHome()*
 
-Sure, you could just use console/debug to trigger it, but you need to trigger it via a URL in a new tab.
+Sure, you could use console/debug to trigger it, but you need to trigger it via a URL in a new tab.
 
-Once you do trigger it, a subsequent response will come to your browser's console with a random number. Put that random number in below.
+Once you trigger it, a subsequent response will come to your browser's console with a random number. Put that random number below.

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content7.adoc

@@ -1,8 +1,8 @@
 == Stored XSS
-Stored Cross-Site Scripting is different in that the payload is persisted (stored) as opposed to passed/injected via a link.
+Stored Cross-Site Scripting is different in that the payload is persisted (stored) instead of passed/injected via a link.
 
 == Stored XSS Scenario
-* Attacker posts malicious script to a message board 
+* Attacker posts malicious script to a message board
 * Message is stored in a server database
 * Victim reads the message
 * The malicious script embedded in the message board post executes in the victim’s browser

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content7b.adoc

@@ -2,5 +2,5 @@ See the comments below.
 
 Add a comment with a JavaScript payload. Again ... you want to call the _webgoat.customjs.phoneHome_ function.
 
-As an attacker (offensive security), keep in mind that most apps are not going to have such a straight-forwardly named compromise.
-Also, you may have to find a way to load your own JavaScript dynamically to fully achieve goals of extracting data.
+As an attacker (offensive security), keep in mind that most apps will not have such a straightforwardly named compromise.
+Also, you may have to find a way to load your JavaScript dynamically to achieve the goal of extracting data fully.

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content7c.adoc

@@ -1,3 +1,3 @@
 Watching in your browser's developer tools or your proxy, the output should include a value starting with 'phoneHome Response is ...."
-Put that value in below to complete this exercise.  Note that, each subsequent call to the _phoneHome_ method will change that value.
-You may need to ensure you have the most recent one.
+Put that value below to complete this exercise.  Note that each subsequent call to the _phoneHome_ method will change that value.
+You may need to ensure you have the most recent one.

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content8.adoc

@@ -2,26 +2,26 @@
 
 
 === Why?
-Hopefully we have covered that by now. Bottom line, you do not want someone else's code running in the context of your users and their logged-in session
+Hopefully, we have covered that by now. Bottom line, you do not want someone else's code running in the context of your users and their logged-in session
 
 === What to encode?
-The basic premise of defending against XSS is *output encoding* any untrusted input that goes to the screen.
+The basic premise of defending against XSS is *output encoding* any untrusted input to the screen.
 That may be changing with more sophisticated attacks, but it is still the best defense we currently have. *AND* ... *context matters*
 
-Another word on 'untrusted input'. If in doubt, treat everything (even data you populated in your DB as untrusted).
-Sometimes data is shared across multiple systems and what you think is your data, may not have been created by you/your team.
+Another word on 'untrusted input.' If in doubt, treat everything (even data you populated in your DB as untrusted).
+Sometimes data is shared across multiple systems, and what you think is your data may not have been created by you/your team.
 
 === When/Where?
 Encode *as the data is sent to the browser* (not in your persisted data).  In the case of *Single Page Apps (SPA's), you will need to encode
-in the client*. Consult your framework/library for me details, but some resources will be  provided on the next page.
+in the client*. Consult your framework/library for details, but some resources will be provided on the next page.
 
 === How?
 
- * Encode as HTML Entities in HTML Body
- * Encode as HTML Entities in HTML Attribute
- * Encode for JavaScript if outputting user input to JavaScript (but think about that ... you are outputting user input into JavaScript on your page!!)
+* Encode as HTML Entities in HTML Body
+* Encode as HTML Entities in HTML Attribute
+* Encode for JavaScript if outputting user input to JavaScript (but think about that ... you are outputting user input into JavaScript on your page!!)
 
 *DO NOT* try to blacklist/negative filter on strings like '<script>' and so forth.
 
 
-...See the next page for some recommended resources and reading on defending against XSS
+...See the next page for some recommended resources and reading on defending against XSS

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content8a.adoc

@@ -1,40 +1,40 @@
 == What is encoding?
 
-Not trusting user input means validating data for type, length, format and range whenever it passes through a trust boundary,
-say from a web form to an application script, and then encoding it prior to redisplay in a dynamic page.
+Not trusting user input means validating data for type, length, format, and range whenever it passes through a trust boundary,
+say from a web form to an application script, then encode it before redisplay in a dynamic page.
 
 In practice, this means that you need to review every point on your site where user-supplied data is handled and processed and
-ensure that, before being passed back to the user, any values accepted from the client side are checked, filtered and encoded.
+ensure that, before being passed back to the user, any values accepted from the client side are checked, filtered, and encoded.
 
 Client-side validation cannot be relied upon, but user input can be forced down to a minimal alphanumeric set with server-side
 processing before being used by a web application in any way.
 
 == Escaping
 
 Escaping means that you convert (or mark) key characters of the data to prevent it from being interpreted in a dangerous context.
-In the case of HTML output, you need to convert the < and > characters (among others), to prevent any malicious code from rendering.
+In the case of HTML output, you need to convert the < and > characters (among others) to prevent any malicious code from rendering.
 Escaping these characters involves turning them into their entity equivalents \&lt; and \&gt;,
 which will not be interpreted as HTML tags by a browser.
 
 == Special characters
 
 You need to encode special characters like "<" and ">" before they are redisplayed if they are received from user input.
 For example, encoding "<" and ">" ensures a browser will display <script> but not execute it.
-In conjunction to encoding, it is important that your web pages always define their character set so the browser will not interpret
+In conjunction with encoding, your web pages must always define their character set so the browser will not interpret
 special character encodings from other character sets.
 
-Cross site scripting attacks usually occur when you manage to sneak a script (usually javascript) onto someone else's website, where
+Cross-site scripting attacks usually occur when you manage to sneak a script (usually javascript) onto someone else's website, where
 it can run maliciously.
 
 === Relevant XML/HTML special characters
 
 |===
 |Char |Escape string |
-|<	|\&lt;|
-|>	|\&gt;|
-|"	|\&quot;|
-|'	|\&#x27;|
-|&	|\&amp;|
+|< |\&lt;|
+|> |\&gt;|
+|" |\&quot;|
+|' |\&#x27;|
+|& |\&amp;|
 |/  |\&#x2F;|
 
 |===

webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content8b.adoc

@@ -1,6 +1,6 @@
 == Reflective XSS
 
-See the HTML file below which passes data to a JSP file.
+See the HTML file below, which passes data to a JSP file.
 
 [source,html]
 -------------------------------------------------------
@@ -49,7 +49,7 @@ Here is the JSP file:
 
 
 As you can see the JSP file prints unfiltered user input which is never a good idea.
-You want people to accesses the page like this:
+You want people to access the page like this:
 
 ----
 http://hostname.com/mywebapp/main.jsp?first_name=John&last_name=Smith
@@ -62,7 +62,7 @@ http://hostname.com/mywebapp/main.jsp?first_name=<script>alert("XSS Test")</scri
 
 === It is your turn!
 
-Try to prevent this kind of XSS by escaping the url parameters in the JSP file:
+Try to prevent this kind of XSS by escaping the URL parameters in the JSP file: