fixed minor spelling mistakes, unified wording
This commit is contained in:
Timur Linden
committed by
Nanne Baars
Nanne Baars
parent
875f0487bd
commit
53c16c8b82
@ -2,38 +2,38 @@
|
||||
xss.title=Cross Site Scripting
|
||||
xss-stored.title=Cross Site Scripting (stored)
|
||||
xss-mitigation.title=Cross Site Scripting (mitigation)
|
||||
xss-reflected-5a-success-alert=Well done, but alerts aren't very impressive are they? Please continue.
|
||||
xss-reflected-5a-success-console=Well done, but console logs aren't very impressive are they? Please continue.
|
||||
xss-reflected-5a-success-alert=Well done, but alerts are not very impressive are they? Please continue.
|
||||
xss-reflected-5a-success-console=Well done, but console logs are not very impressive are they? Please continue.
|
||||
xss-reflected-5a-failed-wrong-field=Seems like you tried to compromise our shop with an reflected XSS attack.<br/> We do our... "best"... to prevent such attacks. Try again!
|
||||
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-5a-failure=Try again. We do want to see this specific JavaScript (in case you are trying to do something more fancy).
|
||||
xss-reflected-5a-hint-1=Think about how the inputs are presumably processed by the application.
|
||||
xss-reflected-5a-hint-2=Quantity inputs are probably processed as integer values. Not the best option for inputting text right?
|
||||
xss-reflected-5a-hint-3=What information send to the application gets reflected back after being submitted?
|
||||
xss-reflected-5a-hint-4=Just try purchasing something. You want your script to be included in the purchase-confirmation.
|
||||
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-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 will not execute (because of response type). Try it if you like.</li></ul>
|
||||
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=Sorry that's not correct. Look at the example again to understand what a valid route looks like. If you're stuck... hints might help.
|
||||
xss-reflected-6a-failure=Sorry that is not correct. Look at the example again to understand what a valid route looks like. If you're stuck... hints might help.
|
||||
xss-reflected-6a-hint-1=To search through the client side code, use the developer tools of your browser. (If you don't know how to use them, check the <i>Developer Tools</i> Lesson in the general category.)
|
||||
xss-reflected-6a-hint-2=Since you are looking for application code, check the WebGoat/js/goatApp folder for a file that could handle the routes.
|
||||
xss-reflected-6a-hint-3=Make sure you add the base route at the start, when submitting your solution.
|
||||
xss-reflected-6a-hint-4=Still didn't find it? Check the <a href="/WebGoat/js/goatApp/view/GoatRouter.js" target="_blank">GoatRouter.js</a> file. It should be pretty easy to determine.
|
||||
xss-reflected-6a-hint-4=Still did not find it? Check the <a href="/WebGoat/js/goatApp/view/GoatRouter.js" target="_blank">GoatRouter.js</a> file. It should be pretty easy to determine.
|
||||
xss.lesson1.failure=Are you sure? Try using a tab from a different site.
|
||||
xss-dom-message-success=Correct, I hope you didn't cheat, using the console!
|
||||
xss-dom-message-success=Correct, I hope you did not cheat, using the console!
|
||||
xss-dom-message-failure=Incorrect, keep trying. It should be obvious in the log when you are successful.
|
||||
xss-dom-message-hint-1=Open a new tab and navigate to the test-route you just figured out in the previous lesson.
|
||||
xss-dom-message-hint-2=Your url should look something like that http://localhost:8080/WebGoat/start.mvc#REPLACE-WITH-THE-TEST-ROUTE/some_parameters
|
||||
xss-dom-message-hint-3=Note how the parameters you send to the test-route get reflected back to the page. Now add your javascript to it.
|
||||
xss-dom-message-hint-4=You have to use script tags, so your javascript code gets executed when being rendered into the DOM.
|
||||
xss-dom-message-hint-5=Since you're working with an URL, you might have to URL-encode your parameters.
|
||||
xss-dom-message-hint-3=Note how the parameters you send to the test-route get reflected back to the page. Now add your JavaScript to it.
|
||||
xss-dom-message-hint-4=You have to use script tags, so your JavaScript code gets executed when being rendered into the DOM.
|
||||
xss-dom-message-hint-5=Since you are working with an URL, you might have to URL-encode your parameters.
|
||||
xss-dom-message-hint-6=Replace '/' with '%2F' in your URL parameters.
|
||||
xss-stored-comment-success=It appears your payload should invoke the function. To tell for sure, you need to capture the value and put it in the form below. Then we will really know.
|
||||
xss-stored-comment-failure=We can't see the payload in your submission, but XSS can be tricky. Look for the call back fired after the comments reload. If you see that and can put the correct value there and put it in, maybe you did succeed.
|
||||
xss-stored-comment-failure=We cannot see the payload in your submission, but XSS can be tricky. Look for the call back fired after the comments reload. If you see that and can put the correct value there and put it in, maybe you did succeed.
|
||||
xss-stored-callback-success=Yes, that is the correct value (note, it will be a different value each time the phoneHome endpoint is called).
|
||||
xss-stored-callback-failure=No, that is not the correct value (note, it will be a different value each time the phoneHome endpoint is called).
|
||||
xss-mitigation-3-hint1=You don't store the user input in this example. Try to encode the user's input right before you place it into the HTML document.
|
||||
xss-mitigation-3-hint1=You do not store the user input in this example. Try to encode the user's input right before you place it into the HTML document.
|
||||
xss-mitigation-3-hint2=Make use of JavaServer Pages Standard Tag Library (JSTL) and JSP Expression Language.
|
||||
xss-mitigation-3-hint3=Take a look at OWASP Java Encoder Project.
|
||||
xss-mitigation-3-hint4=Don't forget to reference the taglibs and choose "e" as prefix.
|
||||
xss-mitigation-3-hint4=Do not forget to reference the tag libs and choose "e" as prefix.
|
||||
xss-mitigation-3-success=You have completed this lesson. Congratulations!
|
||||
xss-mitigation-3-failure=This in not the correct answer. Try again!
|
||||
xss-mitigation-3-no-code=You didn't change anything.
|
||||
xss-mitigation-3-no-code=You did not change anything.
|
||||
@ -2,10 +2,10 @@
|
||||
"questions": [{
|
||||
"text": "Are trusted websites immune to XSS attacks?",
|
||||
"solutions": {
|
||||
"1": "Yes, they're safe because the browser checks the code before executing.",
|
||||
"2": "Yes, because Google has got an algorithm that blocks malicious code.",
|
||||
"3": "No, because the script that's executed will break through the browser's defense algorithm.",
|
||||
"4": "No, because the browser trusts the website if it's acknowledged trusted, then the browser doesn't know that the script is malicious."
|
||||
"1": "Yes they are safe because the browser checks the code before executing.",
|
||||
"2": "Yes because Google has got an algorithm that blocks malicious code.",
|
||||
"3": "No because the script that is executed will break through the defense algorithm of the browser.",
|
||||
"4": "No because the browser trusts the website if it is acknowledged trusted, then the browser does not know that the script is malicious."
|
||||
}
|
||||
}, {
|
||||
"text": "When do XSS attacks occur?",
|
||||
@ -13,14 +13,14 @@
|
||||
"1": "Data enters a web application through a trusted source.",
|
||||
"2": "Data enters a browser application through the website.",
|
||||
"3": "The data is included in dynamic content that is sent to a web user without being validated for malicious content.",
|
||||
"4": "The data is excluded in static content, that way it is sent without being validated."
|
||||
"4": "The data is excluded in static content that way it is sent without being validated."
|
||||
}
|
||||
}, {
|
||||
"text": "What are Stored XSS attacks?",
|
||||
"solutions": {
|
||||
"1": "The script is permanently stored on the server and the victim gets the malicious script when requesting information from the server.",
|
||||
"2": "The script stores itself on the victim's computer and executes locally the malicious code.",
|
||||
"3": "The script stores a virus on the victim's computer. The attacker can perform various actions now.",
|
||||
"2": "The script stores itself on the computer of the victim and executes locally the malicious code.",
|
||||
"3": "The script stores a virus on the computer of the victim. The attacker can perform various actions now.",
|
||||
"4": "The script is stored in the browser and sends information to the attacker."
|
||||
}
|
||||
}, {
|
||||
@ -28,16 +28,16 @@
|
||||
"solutions": {
|
||||
"1": "Reflected attacks reflect malicious code from the database to the web server and then reflect it back to the user.",
|
||||
"2": "They reflect the injected script off the web server. That occurs when input sent to the web server is part of the request.",
|
||||
"3": "Reflected attacks reflect from the server's firewall off to the database where the user requests information from.",
|
||||
"3": "Reflected attacks reflect from the firewall off to the database where the user requests information from.",
|
||||
"4": "Reflected XSS is an attack where the injected script is reflected off the database and web server to the user."
|
||||
}
|
||||
}, {
|
||||
"text": "Is Javascript the only way to perform XSS attacks?",
|
||||
"text": "Is JavaScript the only way to perform XSS attacks?",
|
||||
"solutions": {
|
||||
"1": "Yes, you can only make use of tags through Javascript.",
|
||||
"2": "Yes, otherwise you can't steal cookies.",
|
||||
"3": "No, there's ECMAScript too.",
|
||||
"4": "No, there're many other ways. Like HTML, Flash or any other type of code that the browser executes."
|
||||
"1": "Yes you can only make use of tags through JavaScript.",
|
||||
"2": "Yes otherwise you cannot steal cookies.",
|
||||
"3": "No there is ECMAScript too.",
|
||||
"4": "No there are many other ways. Like HTML, Flash or any other type of code that the browser executes."
|
||||
}
|
||||
}]
|
||||
}
|
||||
@ -7,7 +7,7 @@ you will know learn how you can defend against it.
|
||||
|
||||
* The user will understand the best practices for defending against XSS injection attacks
|
||||
* The user will demonstrate knowledge on:
|
||||
** XSS Mitigation
|
||||
** XSS mitigation
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
== Concept
|
||||
|
||||
After taking a look at Reflected XSS in the previous lesson. We're now gonna take a closer look at another form of Cross Site Scripting Attack: Stored CSS.
|
||||
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.
|
||||
|
||||
== Goals
|
||||
* The user will learn what Stored XSS is
|
||||
* The user will demonstrate knowledge on:
|
||||
** Stored XSS Injection
|
||||
** Stored XSS injection
|
||||
@ -1,17 +1,17 @@
|
||||
== What is XSS
|
||||
== What is XSS?
|
||||
|
||||
Cross-site script (also commonly known as XSS) is a vulnerability/flaw that combines ...
|
||||
Cross-Site Scripting (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
|
||||
# rendered 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
|
||||
|
||||
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.
|
||||
coverage of fixes also tends to be a problem. We will talk more about the defense in a little bit.
|
||||
|
||||
=== XSS has a significant impact
|
||||
=== XSS has significant impact
|
||||
|
||||
Especially as 'Rich Internet Applications' are more and more common place, privileged function calls linked to via javascript may be compromised.
|
||||
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.
|
||||
|
||||
|
||||
@ -31,4 +31,4 @@ javascript:alert(document.cookie);
|
||||
== 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, in the address bar on each tab, type `javascript:alert(document.cookie);` *NOTE:* If you /cut/paste you'll need to add the `javascript:` back in.
|
||||
* Then, in the address bar on each tab, type `javascript:alert(document.cookie);` *NOTE:* If you /cut/paste you will need to add the `javascript:` back in.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
== Most Common Locations
|
||||
== Most common locations
|
||||
|
||||
* Search fields that echo a search string back to the user
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
== Why Should We Care
|
||||
== Why should we care?
|
||||
|
||||
=== XSS attacks may result in
|
||||
* Stealing session cookies
|
||||
@ -15,5 +15,5 @@
|
||||
“>GoodYear recommends buying BridgeStone tires…
|
||||
----
|
||||
|
||||
=== XSS attacks add validity to Phishing attacks
|
||||
=== XSS attacks add validity to phishing attacks
|
||||
* A valid domain is used in the URL
|
||||
|
||||
@ -11,7 +11,7 @@
|
||||
* Similar to reflected XSS
|
||||
* Runs with browser privileges inherited from user in browser
|
||||
|
||||
=== Stored or Persistent
|
||||
=== 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
|
||||
* Social engineering is not required
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
== Reflected XSS Scenario
|
||||
== Reflected XSS scenario
|
||||
|
||||
* Attacker sends a malicious URL to victim
|
||||
* Victim clicks on the link that loads malicious web page
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
== Self XSS or Reflected XSS?
|
||||
== 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.
|
||||
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
== Identify Potential for DOM-Based XSS
|
||||
== 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 being "reflected" to the page.
|
||||
|
||||
For this example, you'll want to look for some 'test' code in the route handlers (WebGoat uses backbone as its primary javascript library).
|
||||
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!).
|
||||
|
||||
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.
|
||||
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.
|
||||
@ -1,6 +1,6 @@
|
||||
== 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.
|
||||
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 ...
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
== 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) as opposed to passed/injected via a link.
|
||||
|
||||
== Stored XSS Scenario
|
||||
* Attacker posts malicious script to a message board
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
See the comments below.
|
||||
|
||||
Add a comment with a javascript payload. Again ... you want to call the _webgoat.customjs.phoneHome_ function.
|
||||
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 exfiltrating data.
|
||||
Also, you may have to find a way to load your own JavaScript dynamically to fully achieve goals of extracting data.
|
||||
@ -1,12 +1,12 @@
|
||||
== XSS Defense
|
||||
== XSS defense
|
||||
|
||||
|
||||
=== Why?
|
||||
Hopefully we've covered that by now. Bottom line, you don't 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.
|
||||
That may be changing with more sophisticated attacks, but is still the best defense we currently have. *AND* ... *context matters*
|
||||
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.
|
||||
@ -19,9 +19,9 @@ in the client*. Consult your framework/library for me details, but some resource
|
||||
|
||||
* 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're outputting user input into javascript on your page!!)
|
||||
* 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
|
||||
@ -1,13 +1,13 @@
|
||||
== What is encoding
|
||||
== 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.
|
||||
say from a web form to an application script, and then encoding it prior to 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.
|
||||
|
||||
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.
|
||||
processing before being used by a web application in any way.
|
||||
|
||||
== Escaping
|
||||
|
||||
@ -20,10 +20,10 @@ which will not be interpreted as HTML tags by a browser.
|
||||
|
||||
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 webpages always define their character set so the browser won't interpret
|
||||
In conjunction to encoding, it is important that your web pages 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
|
||||
|
||||
@ -60,7 +60,7 @@ But what happens if someone uses this link:
|
||||
http://hostname.com/mywebapp/main.jsp?first_name=<script>alert("XSS Test")</script>
|
||||
----
|
||||
|
||||
=== It's your turn!
|
||||
=== It is your turn!
|
||||
|
||||
Try to prevent this kind of XSS by escaping the url parameters in the JSP file:
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
== XSS Defense Resources
|
||||
== XSS defense resources
|
||||
|
||||
=== Java OWASP Encoder
|
||||
Do not be bothered by the incubator status on this project, use it if you are doing Java Web Apps and want to defend against XSS, use this
|
||||
Do not be bothered by the incubator status on this project, use it if you are doing Java web apps and want to defend against XSS, use this
|
||||
link: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
|
||||
|
||||
=== General XSS prevention Cheat Sheet
|
||||
@ -16,15 +16,15 @@ link https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
|
||||
|
||||
=== Javascript Framework Specifics
|
||||
|
||||
Encoding in the client can be tricky. Here are somre resources to help with that. If you don't see your framework below (e.g. Ember, React, ???) and would like to contribute or suggest something ...
|
||||
stop by https://github.com/WebGoat/WebGoat and file an issue (preferably with some recommendations/links) or fork and submit a PR.
|
||||
Encoding in the client can be tricky. Here are some resources to help with that. If you do not see your framework below (e.g. Ember, React, ???) and would like to contribute or suggest something ...
|
||||
stop by https://github.com/WebGoat/WebGoat and file an issue (preferably with some recommendations/links) or fork and submit a pull request.
|
||||
|
||||
==== jQuery
|
||||
be aware if you are using something like ...
|
||||
|
||||
_$selector.html(userInputHere)_,
|
||||
|
||||
...you are in danger. If you want to use that, ensure you are doing someting more like:
|
||||
...you are in danger. If you want to use that, ensure you are doing something more like:
|
||||
|
||||
_$selector.html(someEncodeHtmlMethod(userInputHere))_
|
||||
|
||||
|
||||
@ -7,8 +7,8 @@ This lesson describes what Cross-Site Scripting (XSS) is and how it can be used
|
||||
* The user should have a basic understanding of what XSS is and how it works
|
||||
* The user will learn what Reflected XSS is
|
||||
* The user will demonstrate knowledge on:
|
||||
** Reflected XSS Injection
|
||||
** DOM-based XSS Injection
|
||||
** Reflected XSS injection
|
||||
** DOM-based XSS injection
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1 +1 @@
|
||||
Now it's time for a quiz! It's recommended to check the OWASP Cross Site Scripting explanations https://www.owasp.org/index.php/Cross-site_Scripting_(XSS). Answer all questions correctly to complete the assignment.
|
||||
Now it is time for a quiz! It is recommended to check the OWASP Cross-Site Scripting explanations https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) . Answer all questions correctly to complete the assignment.
|
||||
Reference in New Issue
Block a user