Lesson Plan Title: Using an Access Control Matrix
-Concept / Topic To Teach:
- -In a role-based access control scheme, a role represents a set of access permissions and privileges. A user can be assigned one or more roles. A role-based access control scheme normally consists of two parts: role permission management and role assignment. A broken role-based access control scheme might allow a user to perform accesses that are not allowed by his/her assigned roles, or somehow allow privilege escalation to an unauthorized role. -General Goal(s):
-Each user is a member of a role that is allowed to access only certain resources. Your goal is to explore the access control rules that govern this site. Only the [Admin] group should have access to the 'Account Manager' resource. - diff --git a/src/main/webapp/lesson_plans/English/BackDoors.html b/src/main/webapp/lesson_plans/English/BackDoors.html deleted file mode 100644 index c4ac8a08a..000000000 --- a/src/main/webapp/lesson_plans/English/BackDoors.html +++ /dev/null @@ -1,23 +0,0 @@ -Lesson Plan Title: How to Create Database Back Door Attacks.
-Concept / Topic To Teach:
-How to Create Database Back Door Attacks. --How the attacks works: -
-Databases are used usually as a backend for web applications. Also it is used as a media of storage. It can also -be used as a place to store a malicious activity such as a trigger. A trigger is called by the database management -system upon the execution of another database operation like insert, select, update or delete. An attacker for example -can create a trigger that would set his email address instead of every new user's email address. -General Goal(s):
- -* Your goal should be to learn how you can exploit a vulnerable query to create a trigger.Lesson Plan Title: Basic Authentication
-Concept / Topic To Teach:
- -Basic Authentication is used to protect server side resources. The web server will send a 401 authentication request with the response for the requested resource. The client side browser will then prompt the user for a user name and password using a browser supplied dialog box. The browser will base64 encode the user name and password and send those credentials back to the web server. The web server will then validate the credentials and return the requested resource if the credentials are correct. These credentials are automatically resent for each page protected with this mechanism without requiring the user to enter their credentials again.General Goal(s):
-For this lesson, your goal is to understand Basic Authentication and answer the questions below. - diff --git a/src/main/webapp/lesson_plans/English/BlindSqlInjection.html b/src/main/webapp/lesson_plans/English/BlindSqlInjection.html deleted file mode 100644 index 0ff76e32e..000000000 --- a/src/main/webapp/lesson_plans/English/BlindSqlInjection.html +++ /dev/null @@ -1,15 +0,0 @@ -Lesson Plan Title: How to Perform Blind SQL Injection
-Concept / Topic To Teach:
- -SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks an incredible number of systems on the internet are susceptible to this form of attack. -General Goal(s):
-The form below allows a user to enter an account number and determine if it is valid or not. Use this form to develop a true / false test check other entries in the database.Lesson Plan Title: How to Perform Cross Site Request Forgery.
-Concept / Topic To Teach:
- This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks. --How the attacks works: -
-Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page that contains img links like the one below: - -<img src="http://www.mybank.com/sendFunds.do?acctId=123456"/>- -When the victim's browser attempts to render this page, it will issue a request to www.mybank.com to the transferFunds.do page with the specified parameters. The browser will think the link is to get an image, even though it actually is a funds transfer function. - -The request will include any cookies associated with the site. Therefore, if the user has authenticated to the site, and has either a permanent cookie or even a current session cookie, the site will have no way to distinguish this from a legitimate user request. - -In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, or any other function provided by the vulnerable website -
General Goal(s):
- -Your goal is to send an email to a newsgroup that contains an image whose URL is pointing to a malicious request. Try to include a 1x1 pixel image that includes a URL. The URL should point to the CSRF lesson with an extra parameter "transferFunds=4000". You can copy the shortcut from the left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu.Lesson Plan Title: Putting it all together
-Concept / Topic To Teach:
-This lesson creates a challenge that will help the student apply all that they have learned.Lesson Plan Title: Client Side Filtering
-Concept / Topic To Teach:
- -It is always a good practice to send to the client only information which they are supposed -to have access to. In this lesson, too much information is being sent to the client, creating -a serious access control problem. - -General Goal(s):
-For this exercise, your mission is exploit the extraneous information being returned by the -server to discover information to which you should not have access. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/ClientSideValidation.html b/src/main/webapp/lesson_plans/English/ClientSideValidation.html deleted file mode 100644 index e712b6fb7..000000000 --- a/src/main/webapp/lesson_plans/English/ClientSideValidation.html +++ /dev/null @@ -1,15 +0,0 @@ -Lesson Plan Title: Insecure Client Storage
-Concept / Topic To Teach:
- -It is always a good practice to validate all input on the server side. Leaving the -mechanism for validation on the client side leaves it vulnerable to reverse -engineering. Remember, anything on the client side should not be -considered a secret. - -General Goal(s):
-For this exercise, your mission is to discover a coupon code to receive an unintended -discount. Then, exploit the use of client side validation to submit an order with a -cost of zero. - diff --git a/src/main/webapp/lesson_plans/English/CommandInjection.html b/src/main/webapp/lesson_plans/English/CommandInjection.html deleted file mode 100644 index 1db97ab80..000000000 --- a/src/main/webapp/lesson_plans/English/CommandInjection.html +++ /dev/null @@ -1,12 +0,0 @@ -Lesson Plan Title: How to Perform Command Injection
-Concept / Topic To Teach:
- -Command injection attacks represent a serious threat to any parameter-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks an incredible number of systems on the internet are susceptible to this form of attack.General Goal(s):
-The user should be able to execute any command on the hosting OS. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/ConcurrencyCart.html b/src/main/webapp/lesson_plans/English/ConcurrencyCart.html deleted file mode 100644 index 4a2f44b75..000000000 --- a/src/main/webapp/lesson_plans/English/ConcurrencyCart.html +++ /dev/null @@ -1,22 +0,0 @@ - - - - - -Lesson Plan Title: Shopping Cart Concurrency Flaw
-Concept / Topic To Teach:
- - Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. Thread safety means that the fields of an object or class always maintain a valid state when used concurrently by multiple threads. It is often possible to exploit a concurrency bug by loading the same page as another user at the exact same time. Because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently.General Goal(s):
-For this exercise, your mission is to exploit the concurrency issue which will allow you to purchase merchandise for a lower price. -Lesson Plan Title: How to Perform Cross Site Scripting (XSS)
-Concept / Topic To Teach:
- -It is always a good practice to scrub all inputs, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere. Users should not be able to create message content that could cause another user to load an undesirable page or undesirable content when the user's message is retrieved.General Goal(s):
-For this exercise, you will perform stored and reflected XSS attacks. You will also implement code changes in the web application to defeat these attacks. -Lesson Plan Title:CSRF User Prompt By-Pass
Concept / Topic To Teach:
-This lesson teaches how to perform CSRF attacks that by-pass user confirmation prompts. --How the attacks works: -
-Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page -that contains a 'forged request' to execute commands with the victim's credentials. Prompting -a user to confirm or cancel the command might sound like a solution, but can be by-passed if -the prompt is scriptable. This lesson shows how to by-pass such a prompt by issuing another -forged request. This can also apply to a series of prompts such as a wizard or issuing multiple -unrelated forged requests.
- - -General Goal(s):
- -Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains multiple -malicious requests: the first to transfer funds, and the second a request to confirm the prompt -that the first request triggered. The URL should point to the CSRF lesson with an extra -parameter "transferFunds=4000", and "transferFunds=CONFIRM". You can copy the shortcut from the -left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever -receives this email and happens to be authenticated at that time will have his funds transferred. -When you think the attack is successful, refresh the page and you will find the green check on -the left hand side menu.Lesson Plan Title:CSRF Token Prompt By-Pass
Concept / Topic To Teach:
-This lesson teaches how to perform CSRF attacks on sites that use tokens to mitigate CSRF attacks, but are vulnerable to CSS attacks. --How the attacks works: -
--Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into -loading a page that contains a 'forged request' to execute commands with the -victim's credentials.
- -Token-based request authentication mitigates these attacks. This technique -inserts tokens into pages that issue requests. These tokens are required to -complete a request, and help verify that requests are not scripted. CSRFGuard from OWASP uses -this technique to help prevent CSRF attacks.
- -However, this technique can be by-passed if CSS vulnerabilities exist on the same site. -Because of the same-origin browser policy, pages from the same domain can read content from -other pages from the same domain.
- -General Goal(s):
- -Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains a malicious -request to transfer funds. To successfully complete you need to obtain a valid request token. -The page that presents the transfer funds form contains a valid request token. The URL for the -transfer funds page is the same as this lesson with an extra parameter "transferFunds=main". Load -this page, read the token and append the token in a forged request to transferFunds. When you think -the attack is successful, refresh the page and you will find the green check on the left hand side menu.Lesson Plan Title: How to Perform Cross Site Scripting -(XSS)
-Concept / Topic To Teach:
- -It is always a good practice to scrub all inputs, especially those -inputs that will later be used as parameters to OS commands, scripts, -and database queries. It is particularly important for content that will -be permanently stored somewhere. Users should not be able to create -message content that could cause another user to load an undesirable -page or undesirable content when the user's message is retrieved. -General Goal(s):
-For this exercise, you will perform a stored XSS attack. -You will also implement code changes in the database to defeat -these attacks. -Lesson Plan Title: How to Perform SQL Injection
-Concept / Topic To Teach:
- -It is always a good practice to scrub all inputs, especially those -inputs that will later be used as parameters to OS commands, scripts, -and database queries. Users should not be able to alter the intent of -commands that are executed on the server, in many cases as a privileged user. - -General Goal(s):
-For this exercise, you will perform a SQL Injection attack. -You will also implement code changes in the database to defeat -these attacks. -Lesson Plan Title: How to Perform DOM Injection Attack.
-Concept / Topic To Teach:
-How to perform DOM injection attacks. --How the attacks works: -
-Some applications specially the ones that uses AJAX manipulates and updates the DOM -directly using javascript, DHTML and eval() method.General Goal(s):
- -* Your victim is a system that takes an activation key to allow you to use it.Lesson Plan Title: DOM Based Cross Site Scripting (XSS)
-Concept / Topic To Teach:
- -The Document Object Model (DOM) presents an interesting problem from -a security standpoint. It allows the content of a web page to be dynamically -modified, but that can be abused by attackers during a malicious code injection. XSS, -a type of malicious code injection, can occur when unvalidated user input is used directly -to modify the content of a page on the client side. - -General Goal(s):
-For this exercise, your mission is to use this vulnerability to inject -malicious code into the DOM. Then in the last stage, you will correct -the flaws in the code to address the vulnerability. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/DOS_Login.html b/src/main/webapp/lesson_plans/English/DOS_Login.html deleted file mode 100644 index 941a89b49..000000000 --- a/src/main/webapp/lesson_plans/English/DOS_Login.html +++ /dev/null @@ -1,9 +0,0 @@ -Lesson Plan Title: Denial of Service from Multiple Logins
-Concept / Topic To Teach:
- -Denial of service attacks are a major issue in web applications. If the end user cannot conduct business or perform the service offered by the web application, then both time and money is wasted. -General Goal(s):
-This site allows a user to login multiple times. This site has a database connection pool that allows 2 connections. You must obtain a list of valid users and create a total of 3 logins. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/DangerousEval.html b/src/main/webapp/lesson_plans/English/DangerousEval.html deleted file mode 100644 index f6190530c..000000000 --- a/src/main/webapp/lesson_plans/English/DangerousEval.html +++ /dev/null @@ -1,14 +0,0 @@ -Lesson Plan Title: Dangerous Use of Eval
-Concept / Topic To Teach:
- -It is always a good practice to validate all input on the server side. XSS can occur -when unvalidated user input is reflected directly into an HTTP response. In this lesson, unvalidated -user-supplied data is used in conjunction with a Javascript eval() call. In a reflected -XSS attack, an attacker can craft a URL with the attack script and store it on another -website, email it, or otherwise trick a victim into clicking on it. - -General Goal(s):
-For this exercise, your mission is to come up with some input which, when run through eval, -will execute a malicious script. In order to pass this lesson, you must 'alert()' document.cookie. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/Encoding.html b/src/main/webapp/lesson_plans/English/Encoding.html deleted file mode 100644 index fcba2ddac..000000000 --- a/src/main/webapp/lesson_plans/English/Encoding.html +++ /dev/null @@ -1,9 +0,0 @@ -Lesson Plan Title: How to Peform Basic Encoding
-Concept / Topic To Teach:
- -Different encoding schemes can be used in web applications for different reasons. - -General Goal(s):
-This lesson will familiarize the user with different encoding schemes. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/FailOpenAuthentication.html b/src/main/webapp/lesson_plans/English/FailOpenAuthentication.html deleted file mode 100644 index 27a82e2cf..000000000 --- a/src/main/webapp/lesson_plans/English/FailOpenAuthentication.html +++ /dev/null @@ -1,10 +0,0 @@ -Lesson Plan Title: How to Bypass Fail Open Authentication
-Concept / Topic To Teach:
- - This lesson presents the basics for understanding the "fail open" condition regarding authentication. The security term, “fail open” describes a behavior of a verification mechanism. This is when an error (i.e. unexpected exception) occurs during a verification method causing that method to evaluate to true. This is especially dangerous during login.General Goal(s):
- The user should be able to bypass the authentication check. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/ForcedBrowsing.html b/src/main/webapp/lesson_plans/English/ForcedBrowsing.html deleted file mode 100644 index 2bf4fa6a4..000000000 --- a/src/main/webapp/lesson_plans/English/ForcedBrowsing.html +++ /dev/null @@ -1,21 +0,0 @@ -Lesson Plan Title: How to Perform Forced Browsing Attacks.
-Concept / Topic To Teach:
-How to Exploit Forced Browsing. --How the attacks works: -
-Forced browsing is a technique used by attackers to gain access to resources that are not referenced, but are nevertheless accessible. - -One technique is to manipulate the URL in the browser by deleting sections from the end until an unprotected directory is found -General Goal(s):
- -* Your goal should be to try to guess the URL for the "config" interface.Lesson Plan Title: How to Exploit the Forgot Password Page
-Concept / Topic To Teach:
- -Web applications frequently provide their users the ability to retrieve a forgotten password. Unfortunately, many web applications fail to implement the mechanism properly. The information required to verify the identity of the user is often overly simplistic. -General Goal(s):
-Users can retrieve their password if they can answer the secret question properly. There is no lock-out mechanism on this 'Forgot Password' page. Your username is 'webgoat' and your favorite color is 'red'. The goal is to retrieve the password of another user. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/HiddenFieldTampering.html b/src/main/webapp/lesson_plans/English/HiddenFieldTampering.html deleted file mode 100644 index dff0d945e..000000000 --- a/src/main/webapp/lesson_plans/English/HiddenFieldTampering.html +++ /dev/null @@ -1,12 +0,0 @@ -Lesson Plan Title: How to Exploit Hidden Fields
-Concept / Topic To Teach:
- -Developers will use hidden fields for tracking, login, pricing, etc.. information on a loaded page. While this is a convenient and easy mechanism for the developer, they often don't validate the information that is received from the hidden field. This lesson will teach the attacker to find and modify hidden fields to obtain a product for a price other than the price specifiedGeneral Goal(s):
-The user should be able to exploit a hidden field to obtain a product at an incorrect price. - -Try to purchase the HDTV for less than the purchase price, if you have not done so already. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/HowToWork.html b/src/main/webapp/lesson_plans/English/HowToWork.html deleted file mode 100644 index d99f61dc2..000000000 --- a/src/main/webapp/lesson_plans/English/HowToWork.html +++ /dev/null @@ -1,68 +0,0 @@ - -
-Welcome to a brief overview of WebGoat.
-
-WebGoat uses the Apache Tomcat server but can run in any application server. It is configured to run on -localhost although this can be easily changed, see the "Tomcat Configuration" section in the Introduction.
- -
-
-1. Lesson Categories in WebGoat. Click on a Category to see specific Lessons.
-2. This will show the underlying Java source code.
-3. This will show the complete solution of the selected lesson.
-4. This will show goals and objectives of the lesson.
-5. This will show technical hints to solve the lesson.
-6. This shows the HTTP request data
-7. If you want to restart a lesson you can use this link.
-Always start with the lesson plan. Then try to solve the lesson and if necessary, -use the hints. The last hint is the solution text if applicable. If you cannot solve the lesson using the hints, you may view the -solution for complete details.
- --To read and edit parameters and cookies you need a local proxy like OWASP ZAP to intercept the HTTP request. - More information on ZAP can be found in the "Useful Tools" section in the Introduction. -
- -
-WebGoat uses spring-security.xml to configure users.
-
-
-<!-- Authentication Manager --> -<authentication-manager alias="authenticationManager"> - <authentication-provider> - <user-service> - <user name="guest" password="guest" authorities="ROLE_WEBGOAT_USER" /> - <user name="webgoat" password="webgoat" authorities="ROLE_WEBGOAT_ADMIN" /> - <user name="server" password="server" authorities="ROLE_SERVER_ADMIN" /> - </user-service> - </authentication-provider> -</authentication-manager> -- -
-Usually WebGoat only requires logging in with the user:guest and password:guest. - But maybe in laboratory you have made a setup with one server and a lot of -clients. In this case you might want to have a user for every client, - you will have to alter /WEB-INF/spring-security.xml to add additional users. We recommend not to use real passwords -as the passwords are stored in plain text in this file! -
--Adding a user is straight forward. You can use the guest entry as an example. The added -users should have the same role as the guest user. The new user/password will not show on the login page. -Add lines like this to the /WEB-INF/spring-security.xml file: -
--<user name="guest2" password="guest2" authorities="ROLE_WEBGOAT_USER" /> -... -- diff --git a/src/main/webapp/lesson_plans/English/HtmlClues.html b/src/main/webapp/lesson_plans/English/HtmlClues.html deleted file mode 100644 index c0d81446c..000000000 --- a/src/main/webapp/lesson_plans/English/HtmlClues.html +++ /dev/null @@ -1,12 +0,0 @@ -
Lesson Plan Title: How to Discover Clues in the HTML
-Concept / Topic To Teach:
- - Developers are notorious for leaving statements like FIXME's, TODO's, Code Broken, Hack, etc... inside the source code. Review the source code for any comments denoting passwords, backdoors, or something doesn't work right. - Below is an example of a forms based authentication form. Look for clues to help you log in. - -General Goal(s):
-The user should be able to bypass the authentication check. diff --git a/src/main/webapp/lesson_plans/English/HttpBasics.html b/src/main/webapp/lesson_plans/English/HttpBasics.html deleted file mode 100644 index f3321f295..000000000 --- a/src/main/webapp/lesson_plans/English/HttpBasics.html +++ /dev/null @@ -1,27 +0,0 @@ -Lesson Plan Title: Http Basics
-Concept / Topic To Teach:
- This lesson presents the basics for understanding the transfer of data between the browser and the web application.-How HTTP works: -
-All HTTP transactions follow the same general format. Each client request and server response has three parts: the request or response line, a header section and the entity body. The client initiates a transaction as follows:General Goal(s):
- -Enter your name in the input field below and press "Go!" to submit. The server will accept the request, reverse the input and display it back to the user, illustrating the basics of handling an HTTP request. -Lesson Plan Title: HttpOnly Test
-Concept / Topic To Teach:
- -To help mitigate the cross site scripting threat, Microsoft has -introduced a new cookie attribute entitled 'HttpOnly.' If this flag is -set, then the browser should not allow client-side script to access the -cookie. Since the attribute is relatively new, several browsers neglect -to handle the new attribute properly. -For a list of supported browsers see: OWASP HTTPOnly Support -
General Goal(s):
-The purpose of this lesson is to test whether your browser supports the -HTTPOnly cookie flag. Note the value of the -unique2u -cookie. If your browser supports HTTPOnly, and you enable it for a -cookie, client side code should NOT be able to read OR write to that -cookie, but the browser can still send its value to the server. Some -browsers only prevent client side read access, but don't prevent write -access. -Lesson Plan Title: How to Perform HTTP Splitting
-Concept / Topic To Teach:
- This lesson teaches how to perform HTTP Splitting attacks. --How the attack works: -
-The attacker passes malicious code to the web server together with normal input. -A victim application will not be checking for CR (carriage return, also given by %0d or \r) -and LF (line feed, also given by %0a or \n) characters. These characters not only give attackers control -of the remaining headers and body of the response the application intends to send, -but they also allows them to create additional responses entirely under their control.
-The effect of an HTTP Splitting attack is maximized when accompanied with a Cache Poisoning. The goal of -Cache Poisoning attack is to poison the cache of the victim by fooling the cache into believing that the page -hijacked using the HTTP splitting is an authentic version of the server's copy.
-The attack works by using the HTTP Splitting attack plus adding the Last-Modified: header and setting it -to a future date. This forces the browser to send an incorrect If-Modified-Since request header on future requests. -Because of this, the server will always report that the (poisoned) page has not changed, and the victim's browser -will continue to display the attacked version of the page.
-A sample of a 304 response is: -
HTTP/1.1 304 Not Modified- -
-Date: Fri, 30 Dec 2005 17:32:47 GMT
General Goal(s):
- -This lesson has two stages. Stage 1 teaches you how to do HTTP Splitting attacks while stage 2 builds on that to teach you how to elevate HTTP Splitting to Cache Poisoning.
-Enter a language for the system to search by. You will notice that the application is redirecting your request to another resource on the server. You should be able to use the CR (%0d) and LF (%0a) characters to exploit the attack. Your goal should be to force the server to send a 200 OK. If the screen changed as an effect to your attack, just go back to the homepage. After stage 2 is exploited successfully, you will find the green check in the left menu.
-You may find the PHP Charset Encoder useful. The Encode and DecodeURIComponent buttons translate CR and LF.
- - diff --git a/src/main/webapp/lesson_plans/English/InsecureLogin.html b/src/main/webapp/lesson_plans/English/InsecureLogin.html deleted file mode 100644 index a33256309..000000000 --- a/src/main/webapp/lesson_plans/English/InsecureLogin.html +++ /dev/null @@ -1,14 +0,0 @@ -Lesson Plan Title: Insecure Login
-Concept / Topic To Teach:
- -Sensitive data should never sent in plaintext! Often applications -switch to a secure connection after the authorization. An attacker -could just sniff the login and use the gathered information to -break into an account. A good webapplication always takes care of -encrypting sensitive data. -General Goal(s):
-See how easy it is to sniff a password in plaintext.Lesson Plan Title: How to Perform JSON Injection
-Concept / Topic To Teach:
-This lesson teaches how to perform JSON Injection Attacks. --How the attacks works: -
-JavaScript Object Notation (JSON) is a simple and effective lightweight data exchange format. JSON can be in a lot of forms such as arrays, lists, hashtables and other data structures. -JSON is widely used in AJAX and Web2.0 application and is favored by programmers over XML because of its ease of use and speed. -However, JSON, like XML is prone to Injection attacks. A malicious attacker can inject the reply from the server and inject some arbitrary values in there. - -General Goal(s):
- -* You are traveling from Boston, MA- Airport code BOS to Seattle, WA - Airport code SEA.Lesson Plan Title: How to Bypass Client Side JavaScript Validation
-Concept / Topic To Teach:
- -Client-side validation should not be considered a secure means of validating parameters. These validations only help reduce the amount of server processing time for normal users who do not know the format of required input. Attackers can bypass these mechanisms easily in various ways. Any client-side validation should be duplicated on the server side. This will greatly reduce the likelihood of insecure parameter values being used in the application. - -General Goal(s):
-For this exercise, the web site requires that you follow certain rules when you fill out a form. The user should be able to break those rules, and send the website input that it wasn't expecting.Lesson Plan Title:
-Concept / Topic To Teach:
-Standards Addressed:
-General Goal(s):
-Specific Objectives:
-Required Materials:
-Anticipatory Set (Lead-In):
-Step-By-Step Procedures:
-Plan For Independent Practice:
-Closure (Reflect Anticipatory Set):
-Assessment Based On Objectives:
-Extensions (For Gifted Students):
-Possible Connections To Other Subjects:
- \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/LogSpoofing.html b/src/main/webapp/lesson_plans/English/LogSpoofing.html deleted file mode 100644 index 105e38f54..000000000 --- a/src/main/webapp/lesson_plans/English/LogSpoofing.html +++ /dev/null @@ -1,20 +0,0 @@ -Lesson Plan Title: How to Perform Log Spoofing.
-Concept / Topic To Teach:
- This lesson teaches attempts to fool the human eye. --How the attacks works: -The attack is based on fooling the humane eye in log files. An attacker can erase his traces from the logs -using this attack. -
-General Goal(s):
- -* The grey area below represents what is going to be logged in the web server's log file.Lesson Plan Title: Multi Level Login 1
-Concept / Topic To Teach:
- -A Multi Level Login should provide a strong authentication. -This is archived by adding a second layer. After having -logged in with your user name and password you are asked -for a 'Transaction Authentication Number' (TAN). This is -often used by online banking. You get a list with a lots -of TANs generated only for you by the bank. Each TAN is used only once. -Another method is to provide the TAN by SMS. This has -the advantage that an attacker can not get TANs provided -by the user. -General Goal(s):
-In this Lesson you try to get around the strong authentication. -You have to break into another account. The user name, password and a -already used TAN is provided. You have to make sure -the server accept the TAN even it is already used. - diff --git a/src/main/webapp/lesson_plans/English/MultiLevelLogin2.html b/src/main/webapp/lesson_plans/English/MultiLevelLogin2.html deleted file mode 100644 index 3514b7148..000000000 --- a/src/main/webapp/lesson_plans/English/MultiLevelLogin2.html +++ /dev/null @@ -1,20 +0,0 @@ -Lesson Plan Title: Multi Level Login 2
-Concept / Topic To Teach:
- -A Multi Level Login should provide a strong authentication. -This is archived by adding a second layer. After having -logged in with your user name and password you are asked -for a 'Transaction Authentication Number' (TAN). This is -often used by online banking. You get a list with a lots -of TANs generated only for you by the bank. Each TAN is used only once. -Another method is to provide the TAN by SMS. This has -the advantage that an attacker can not get TANs provided -by the user. -General Goal(s):
-In this lesson you have to try to break into another account. -You have an own account for WebGoat Financial but you want to -log into another account only knowing the user name of the victim -to attack. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/NewLesson.html b/src/main/webapp/lesson_plans/English/NewLesson.html deleted file mode 100644 index 234b170d8..000000000 --- a/src/main/webapp/lesson_plans/English/NewLesson.html +++ /dev/null @@ -1,13 +0,0 @@ - - -
-Adding lessons to WebGoat is very easy. If you have an idea that would be suitable
-for a new lesson, follow these few simple instructions to implement it:
-* Download the source code from here.
-* Setup framework: follow the simple instructions in "HOW TO create the WebGoat workspace.txt" that comes with the project.
-* You need to add two files for each new lesson:
- - YourLesson.java to org.owasp.webgoat.lessons
- - YourLesson.html to WebContent/lesson_plans
Lesson Plan Title: How to Exploit "Off-by-One" Buffer Overflow Vulnerabilities
-Concept / Topic To Teach:
-How to Exploit a Web Based "Off-by-One" Buffer Overflow. -How the attack works: -
-Despite being more rare, buffer overflow vulnerabilities on the web occur when a tier of the application has insufficient memory allocated to deal with the data submitted by the user. Typically, such a tier would be written in C or a similar language. - -For the particular subset, namely, off-by-one overflows, this lesson focuses on the consequences of being able to overwrite the position for the trailing null byte. - -As a result, further information is returned back to the user, due to the fact that no null byte was found. -Lesson Goal(s):
- -Welcome to the OWASP Hotel! Can you find out which room a VIP guest is staying in?
- -* Understand how a buffer overflow vulnerability can be triggered on a web application.Lesson Plan Title: Password Strength
-Concept / Topic To Teach:
- -Accounts are only as secure as their passwords. Most users have the same weak password everywhere. If you want to protect them against brute-force-attacks your application should have good requirements for passwords. The password should contain lower case letters, capitals, numbers and special characters. The longer the password, the better, consider using a passphrase instead. For -more information see: OWASP proper password strength. - -General Goal(s):
- For this exercise, your job is to test several passwords on https://howsecureismypassword.net/ \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/PathBasedAccessControl.html b/src/main/webapp/lesson_plans/English/PathBasedAccessControl.html deleted file mode 100644 index 235bd2528..000000000 --- a/src/main/webapp/lesson_plans/English/PathBasedAccessControl.html +++ /dev/null @@ -1,9 +0,0 @@ -Lesson Plan Title: How to Bypass a Path Based Access Control Scheme
-Concept / Topic To Teach:
- -In a path based access control scheme, an attacker can traverse a path by providing relative path information. Therefore an attacker can use relative paths to access files that normally are not directly accessible by anyone, or would otherwise be denied if requested directly. - -General Goal(s):
-The user should be able to access a file that is not in the listed directory. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/Phishing.html b/src/main/webapp/lesson_plans/English/Phishing.html deleted file mode 100644 index 9b0127d14..000000000 --- a/src/main/webapp/lesson_plans/English/Phishing.html +++ /dev/null @@ -1,16 +0,0 @@ -Lesson Plan Title: Phishing with XSS
-Concept / Topic To Teach:
- -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. - With the help of XSS you can do a Phishing Attack and add content to a page - which looks official. It is very hard for a victim to determinate - that the content is malicious. - -General Goal(s):
-The user should be able to add a form asking for username -and password. On submit the input should be sent -to http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName - diff --git a/src/main/webapp/lesson_plans/English/ReflectedXSS.html b/src/main/webapp/lesson_plans/English/ReflectedXSS.html deleted file mode 100644 index 9db959e07..000000000 --- a/src/main/webapp/lesson_plans/English/ReflectedXSS.html +++ /dev/null @@ -1,13 +0,0 @@ -Lesson Plan Title: How to Perform Reflected Cross Site Scripting (XSS)
-Concept / Topic To Teach:
- -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. - -General Goal(s):
-For this exercise, your mission is to come up with some input containing a script. You have to try to get this page to reflect that input back to your browser, which will execute the script and do something bad. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/RemoteAdminFlaw.html b/src/main/webapp/lesson_plans/English/RemoteAdminFlaw.html deleted file mode 100644 index e852cbcba..000000000 --- a/src/main/webapp/lesson_plans/English/RemoteAdminFlaw.html +++ /dev/null @@ -1,11 +0,0 @@ -Lesson Plan Title: How to Force Browser Web Resources
-Concept / Topic To Teach:
-Applications will often have an administrative interface that allows privileged users access to functionality that normal users shouldn't see. The application server will often have an admin interface as well. -Standards Addressed :
-General Goal(s): - -Try to access the administrative interface for WebGoat. You may also try to access the administrative interface for Tomcat. The Tomcat admin interface can be accessed via a URL (/admin) and will not count towards the completion of this lesson. - -
diff --git a/src/main/webapp/lesson_plans/English/RoleBasedAccessControl.html b/src/main/webapp/lesson_plans/English/RoleBasedAccessControl.html deleted file mode 100644 index 132dc235f..000000000 --- a/src/main/webapp/lesson_plans/English/RoleBasedAccessControl.html +++ /dev/null @@ -1,15 +0,0 @@ -Lesson Plan Title: Role Based Access Control
-Concept / Topic To Teach:
- -In role-based access control scheme, a role represents a set of access permissions and privileges. A user can be assigned one or more roles. A role-based access control normally consists of two parts: role permission management and role assignment. A broken role-based access control scheme might allow a user to perform accesses that are not allowed by his/her assigned roles, or somehow obtain unauthorized roles. - -General Goal(s):
-Your goal is to explore the access control rules that govern this site. Each role has permission to certain resources (A-F). Each user is assigned one or more roles. Only the user with the [Admin] role should have access to the 'F' resources. In a successful attack, a user doesn't have the [Admin] role can access resource F. -Lesson Resources:
-Org Chart -Lesson Plan Title: How to Perform a SQL Injection
-Concept / Topic To Teach:
- -SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack. -General Goal(s):
-For this exercise, you will perform SQLInjection attacks. You will also implement code changes in the web application to defeat these attacks. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/SameOriginPolicyProtection.html b/src/main/webapp/lesson_plans/English/SameOriginPolicyProtection.html deleted file mode 100644 index b7db5d10e..000000000 --- a/src/main/webapp/lesson_plans/English/SameOriginPolicyProtection.html +++ /dev/null @@ -1,13 +0,0 @@ -Lesson Plan Title: Same Origin Policy Protection
-Concept / Topic To Teach:
- -A key element of AJAX is the XMLHttpRequest (XHR), which allows javascript to make asynchronous -calls from the client side to a server. However, as a security measure these requests may -only be made to the server from which the client page originated. - -General Goal(s):
-This exercise demonstrates the Same Origin Policy Protection. XHR requests -can only be passed back to the originating server. Attempts to pass data to -a non-originating server will fail."; diff --git a/src/main/webapp/lesson_plans/English/SessionFixation.html b/src/main/webapp/lesson_plans/English/SessionFixation.html deleted file mode 100644 index c7e70f3aa..000000000 --- a/src/main/webapp/lesson_plans/English/SessionFixation.html +++ /dev/null @@ -1,33 +0,0 @@ -Lesson Plan Title: Session Fixation
-Concept / Topic To Teach:
-How to steal a session with a 'Session Fixation' --How the attacks works: -
-A user is recognized by the server by an unique Session ID. If a -user has logged in and is authorized he does not have to -reauthorize when he revisits the application as the user is recognized -by the Session ID. In some applications it is possible to deliver -the Session ID in the Get-Request. Here is where the attack starts. -General Goal(s):
- -This lesson has several stages. You play the attacker but also the victim. -After having done this lesson it should be understood how -a Session Fixation in general works. It should be also understood that -it is a bad idea to use the Get-Request for Session IDs. - - diff --git a/src/main/webapp/lesson_plans/English/SilentTransactions.html b/src/main/webapp/lesson_plans/English/SilentTransactions.html deleted file mode 100644 index d3377dce8..000000000 --- a/src/main/webapp/lesson_plans/English/SilentTransactions.html +++ /dev/null @@ -1,24 +0,0 @@ -Lesson Plan Title: How to Perform Silent Transactions Attacks.
-Concept / Topic To Teach:
-This lesson teaches how to perform silent transactions attacks. --How the attacks works: -
-Any system that silently processes transactions using a single submission is dangerous to the client. -For example, if a normal web application allows a simple URL submission, a preset session attack will -allow the attacker to complete a transaction without the user’s authorization. -In Ajax, it gets worse: the transaction is silent; it happens with no user feedback on the page, -so an injected attack script may be able to steal money from the client without authorization.General Goal(s):
- -* This is a sample internet banking application - money transfer page.Lesson Plan Title: How to Create a SOAP Request
-Concept / Topic To Teach:
- -Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL). Let's learn something about WSDL files. Check out WebGoat's web service description language (WSDL) file. -General Goal(s):
-Try connecting to the WSDL with a browser or Web Service tool. The URL for the web service is: http://localhost/WebGoat/services/SoapRequest The WSDL can usually be viewed by adding a ?WSDL on the end of the web service request. You must access 2 of the operations to pass this lesson. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/SqlNumericInjection.html b/src/main/webapp/lesson_plans/English/SqlNumericInjection.html deleted file mode 100644 index a081c1a29..000000000 --- a/src/main/webapp/lesson_plans/English/SqlNumericInjection.html +++ /dev/null @@ -1,14 +0,0 @@ -Lesson Plan Title: How to Perform Numeric SQL Injection
-Concept / Topic To Teach:
- -SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack. -General Goal(s):
-The form below allows a user to view weather data. Try to inject an SQL string that results in all the weather data being displayed. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/SqlStringInjection.html b/src/main/webapp/lesson_plans/English/SqlStringInjection.html deleted file mode 100644 index 2dc84b697..000000000 --- a/src/main/webapp/lesson_plans/English/SqlStringInjection.html +++ /dev/null @@ -1,14 +0,0 @@ -Lesson Plan Title: How to Perform String SQL Injection
-Concept / Topic To Teach:
- -SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack. -General Goal(s):
-The form below allows a user to view their credit card numbers. Try to inject an SQL string that results in all the credit card numbers being displayed. Try the user name of 'Smith'. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/StoredXss.html b/src/main/webapp/lesson_plans/English/StoredXss.html deleted file mode 100644 index e2662164f..000000000 --- a/src/main/webapp/lesson_plans/English/StoredXss.html +++ /dev/null @@ -1,9 +0,0 @@ -Lesson Plan Title: How to Perform Stored Cross Site Scripting (XSS)
-Concept / Topic To Teach:
- -It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved. - -General Goal(s):
-The user should be able to add message content that cause another user to load an undesireable page or content. \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/ThreadSafetyProblem.html b/src/main/webapp/lesson_plans/English/ThreadSafetyProblem.html deleted file mode 100644 index 1b01a915d..000000000 --- a/src/main/webapp/lesson_plans/English/ThreadSafetyProblem.html +++ /dev/null @@ -1,22 +0,0 @@ - - - - - -Lesson Plan Title: How to Exploit Thread Safety Problems
-Concept / Topic To Teach:
- - Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. Thread safety means that the fields of an object or class always maintain a valid state when used concurrently by multiple threads. It is often possible to exploit a concurrency bug by loading the same page as another user at the exact same time. Because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently.General Goal(s):
-The user should be able to exploit the concurrency error in the web application and view login information for another user that is attempting the same function at the same time. This will require the use of two browsers. -WebGoat comes with default configurations for Tomcat. This page will explain these configurations -and other possible configurations for Tomcat. This is just -a short description which should be enough in most cases. For more advanced tasks please -refer to the Tomcat documentation. Please note that all solutions -are written for the standard configurations on port 80 or 8080. If you use another port you have -to adjust the solution to your configuration.
- -WebGoat has multiple ways of being run. The -WebGoat Wiki is the best place to find the latest configuration instructions. -By default WebGoat will run on port 8080. In the basic configurations you use the server on your localhost. -In Linux you have to start WebGoat as root or with sudo if you want to run it on port 80 and - 443. Running software as root is dangerous we strongly advice to use -the port 8080 and 8443. -
- --If you are a single user of WebGoat the standard configurations should be -enough but if you want to use WebGoat in laboratory or in class there -might be the need to change the configurations. Before changing -the configurations we recommend doing a backup of the files you change. -
- --To change the ports open Tomcat's server.xml which you find in tomcat/conf and change the -non-SSL port. If you want to change your -Tomcat server to use it on port 8079 for example: -
- --<!-- Define a non-SSL HTTP/1.1 Connector on port 8079 --> -<Connector address="127.0.0.1" port="8079"... --
-You can also change the SSL connector to another port of course. -In this example to port 8442: -
--<!-- Define a SSL HTTP/1.1 Connector on port 8442 --> -<Connector address="127.0.0.1" port="8442"... -- -You can also modify WebGoat's pom.xml file to change the port. You will need to modify -the tomcat7-maven-plugin plugin configuration. - -
THIS MAKES IT POSSIBLE TO REALLY ATTACK YOUR SERVER! DO NOT DO THIS - UNTIL YOU KNOW WHAT YOU ARE DOING. THIS CONFIGURATION SHOULD BE ONLY USED IN -SAFE NETWORKS!
-By its default configuration, WebGoat is only -reachable within the localhost. In a laboratory or a class -there is maybe the need of having a server and a few clients. -In this case it is possible to make WebGoat reachable. -
- --If you have made WebGoat reachable it is reachable for -all clients. If you want to make it reachable only for certain clients specified -by their IP you can archive this by using a 'Remote Address Filter'. -The filter can be set in a whitebox or blackbox approach. Here is -only discussed the whitebox approach. You have to add following lines to the -Host section of server.xml in your Tomcat server configuration: -
-- <Valve className="org.apache.catalina.valves.RemoteAddrValve" - allow="127.0.0.1,ip1,ip2"/> --
In this case only localhost, ip1 and ip2 are permitted to connect.
- - - - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/TraceXSS.html b/src/main/webapp/lesson_plans/English/TraceXSS.html deleted file mode 100644 index 2358d4fc4..000000000 --- a/src/main/webapp/lesson_plans/English/TraceXSS.html +++ /dev/null @@ -1,9 +0,0 @@ -Lesson Plan Title: How to Perform Cross Site Tracing (XST) Attacks
-Concept / Topic To Teach:
- -It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved. -General Goal(s):
-Tomcat is configured to support the HTTP TRACE command. Your goal is to perform a Cross Site Tracing (XST) attack. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/UncheckedEmail.html b/src/main/webapp/lesson_plans/English/UncheckedEmail.html deleted file mode 100644 index db3c630e9..000000000 --- a/src/main/webapp/lesson_plans/English/UncheckedEmail.html +++ /dev/null @@ -1,9 +0,0 @@ -Lesson Plan Title: How to Exploit Unchecked Email
-Concept / Topic To Teach:
- -It is always a good practice to validate all inputs. Most sites allow non-authenticated users to send email to a 'friend'. This is a great mechanism for spammers to send out email using your corporate mail server. - -General Goal(s):
-The user should be able to send and obnoxious email message. diff --git a/src/main/webapp/lesson_plans/English/UsefulTools.html b/src/main/webapp/lesson_plans/English/UsefulTools.html deleted file mode 100644 index 99bee445d..000000000 --- a/src/main/webapp/lesson_plans/English/UsefulTools.html +++ /dev/null @@ -1,41 +0,0 @@ - - --Below is a list of tools we've found useful in solving the WebGoat lessons. You will need a proxy like OWASP ZAP or Paros to solve most of the lessons.
-
-Like WebGoat, Zed Attack Proxy (ZAP) is a part of OWASP and is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.
-It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.
-ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually..
-
-Webpage: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
-
The .jar install file can be found at the OWASP ZAP Google Code Project
After installing ZAP and configuring your browser to use it as a proxy on localhost we can start. To intercept a request,
-click the green arrow icon turning it red. If we browse a WebGoat page, ZAP will intercept the HTTP request.
-Here we can read and edit the intercepted parameters and headers. After editing is complete press the play icon to submit the request to the server.
-
-
-Most modern browser have developer tools that will allow you to inspect and modify request data.
-
-
-
-Wireshark is a network protocol analyzer. You can sniff network traffic and gather useful
-informations this way.
-
-Webpage:http://www.wireshark.org
-
-
-There are many vulnerability scanners for your own web applications. They can find XSS, Injection Flaws and other vulnerabilities. Below are links to three open source scanners.
-Nessus:http://www.nessus.org
-Paros:http://www.parosproxy.org
-OWASP ZAP:https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
-
Lesson Plan Title: How to Perform WSDL Scanning
-Concept / Topic To Teach:
- -Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file. -General Goal(s):
-This screen is the API for a web service. Check the WSDL file for this web service and try to get some customer credit numbers. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/WeakAuthenticationCookie.html b/src/main/webapp/lesson_plans/English/WeakAuthenticationCookie.html deleted file mode 100644 index 9c9b86c8a..000000000 --- a/src/main/webapp/lesson_plans/English/WeakAuthenticationCookie.html +++ /dev/null @@ -1,12 +0,0 @@ -Lesson Plan Title: How to Spoof an Authentication Cookie
-Concept / Topic To Teach:
- -Many applications will automatically log a user into their site if the right authentication cookie is specified. Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. Some times the cookies maybe intercepted using Cross site scripting. This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.General Goal(s):
- - The user should be able to bypass the authentication check. -Login using the webgoat/webgoat account to see what happens. You may also try aspect/aspect. When you understand the authentication cookie, try changing your identity to alice. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/WeakSessionID.html b/src/main/webapp/lesson_plans/English/WeakSessionID.html deleted file mode 100644 index 45157e0b5..000000000 --- a/src/main/webapp/lesson_plans/English/WeakSessionID.html +++ /dev/null @@ -1,9 +0,0 @@ -Lesson Plan Title: How to Hijack a Session
-Concept / Topic To Teach:
- -Application developers who develop their own session IDs frequently forget to incorporate the complexity and randomness necessary for security. If the user specific session ID is not complex and random, then the application is highly susceptible to session-based brute force attacks. -General Goal(s):
-Try to access an authenticated session belonging to someone else. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/WelcomeScreeen.html b/src/main/webapp/lesson_plans/English/WelcomeScreeen.html deleted file mode 100644 index be93e40e2..000000000 --- a/src/main/webapp/lesson_plans/English/WelcomeScreeen.html +++ /dev/null @@ -1,16 +0,0 @@ -Lesson Plan Title:Welcome
-Concept / Topic To Teach:
-This lesson presents the basics for understanding the transfer of data between the browser and the web application. -Standards Addressed:
-General Goal(s):
-Specific Objectives:
-Required Materials:
-Anticipatory Set (Lead-In):
-Step-By-Step Procedures:
-Plan For Independent Practice:
-Closure (Reflect Anticipatory Set):
-Assessment Based On Objectives:
-Extensions (For Gifted Students):
-Possible Connections To Other Subjects:
\ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/WsSAXInjection.html b/src/main/webapp/lesson_plans/English/WsSAXInjection.html deleted file mode 100644 index 23a2e8607..000000000 --- a/src/main/webapp/lesson_plans/English/WsSAXInjection.html +++ /dev/null @@ -1,12 +0,0 @@ -Lesson Plan Title: How to Perform Web Service SAX Injection
-Concept / Topic To Teach:
- -Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file. -General Goal(s):
-Some web interfaces make use of Web Services in the background. If the frontend relies on the web service for all input validation, it may be possible to corrupt the XML that the web interface sends. -Lesson Plan Title: How to Perform Web Service SQL Injection
-Concept / Topic To Teach:
- -Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file. -General Goal(s):
-Check the web service description language (WSDL) file and try to obtain multiple customer credit card numbers. You will not see the results returned to this screen. When you believe you have suceeded, refresh the page and look for the 'green star'. - \ No newline at end of file diff --git a/src/main/webapp/lesson_plans/English/XMLInjection.html b/src/main/webapp/lesson_plans/English/XMLInjection.html deleted file mode 100644 index fc9c73697..000000000 --- a/src/main/webapp/lesson_plans/English/XMLInjection.html +++ /dev/null @@ -1,19 +0,0 @@ -Lesson Plan Title: How to Perform XML Injection Attacks.
-Concept / Topic To Teach:
- This lesson teaches how to perform XML Injection attacks. --How the attacks works: -
-AJAX applications use XML to exchange information with the server. This XML can be easily intercepted and altered by a malicious attacker. - -General Goal(s):
- -WebGoat-Miles Reward Miles shows all the rewards available. Once you've entered your account ID, the lesson will show you your balance and the products you can afford. Your goal is to try to add more rewards to your allowed set of rewards. Your account ID is 836239. - - diff --git a/src/main/webapp/lesson_plans/English/XPATHInjection.html b/src/main/webapp/lesson_plans/English/XPATHInjection.html deleted file mode 100644 index 926d8f151..000000000 --- a/src/main/webapp/lesson_plans/English/XPATHInjection.html +++ /dev/null @@ -1,22 +0,0 @@ -Lesson Plan Title: How to Perform XPATH Injection Attacks.
-Concept / Topic To Teach:
- This lesson teaches how to perform XPath Injection attacks. --How the attacks works: -
-Similar to SQL Injection, XPATH Injection attacks occur when a web site uses user supplied information to query XML data. By sending intentionally malformed information into the web site, an attacker can find out how the XML data is structured or access data that they may not normally have access to. -They may even be able to elevate their privileges on the web site if the xml data is being used for authentication (such as an xml based user file). - -Querying XML is done with XPath, a type of simple descriptive statement that allows the xml query to locate a piece of information. Like SQL you can specify certain attributes to find and patterns to match. When using XML for a web site it is common to accept some form of input on the query string to identify the content to locate and display on the page. This input must be sanitized to verify that it doesn't mess up the XPath query and return the wrong data. - - -General Goal(s):
- -The form below allows employees to see all their personal data including their salaries. Your account is Mike/test123. Your goal is to try to see other employees data as well. -