TEC Workbook - IBM

TEC Workbook - IBM TEC Workbook - IBM

23.02.2013 Views

IBM Software The processing policy should now look like the following image. __5. Click the Apply Policy button to make your changes active. __6. In the soapUI request window, load the request from c:\labs\requests\missingDp.xml. Notice that the brand is missing the word “DataPower”. __7. Click the green submit button to POST the request to MyServiceProxy. You should receive a SOAP fault with an error message as shown in the following image. 2.5.1 SQL Injection Threat Filtering SQL Injection is an attack technique used to exploit Web sites and services that construct SQL statements from user-supplied input. For example, assume that a web service expects a SOAP request containing a element used for looking up a customer. KAPLAN The Web service uses an SQL statement with substitution parameters similar to the following SQL snippet: SELECT * FROM EMPLOYEE WHERE LASTNAME = ? After the substitution takes place, the resultant SQL statement will be: SELECT * FROM EMPLOYEE WHERE LASTNAME = 'KAPLAN' However, if the value submitted in the element contained a malicious SQL injection threat, it may look like this: KAPLAN’ OR ‘1’=’1 Page 44 WebSphere Lab Jam

The SQL statement would become: SELECT * FROM EMPLOYEE WHERE LASTNAME = 'KAPLAN' OR '1' = '1' IBM Software The service will return the details about ALL employees, since the WHERE clause will evaluate to true for every record in the EMPLOYEE table (because of the ‘1’ = ‘1’ clause). WebSphere DataPower SOA Appliances can protect against such SQL injection threats using a special SQL injection threat filter. It works the same way as the filter you tried in the previous steps, except that the logic is a bit more complex. The SQL Injection Threat filter has two parts: the base stylesheet filter (that uses and ), and an XML file that contains the various patterns to search for. Keeping the patterns in a separate XML file allows you to create more customized patterns. __1. In the policy editor window, drag another Filter action onto the processing rule to the right of the previously added filter action. __2. Double click the yellow outlined filter action to complete its configuration. __3. In the Transform field: __a. Change the upper dropdown to show: store:/// __b. In the lower dropdown box, select: SQL-Injection-Filter.xsl __4. Click the Done button. __5. Click the Apply Policy button to activate these changes. Lab 2 - Working with XML Page 45

The SQL statement would become:<br />

SELECT * FROM EMPLOYEE WHERE LASTNAME = 'KAPLAN' OR '1' = '1'<br />

<strong>IBM</strong> Software<br />

The service will return the details about ALL employees, since the WHERE clause will evaluate to true<br />

for every record in the EMPLOYEE table (because of the ‘1’ = ‘1’ clause).<br />

WebSphere DataPower SOA Appliances can protect against such SQL injection threats using a special<br />

SQL injection threat filter. It works the same way as the filter you tried in the previous steps, except that<br />

the logic is a bit more complex.<br />

The SQL Injection Threat filter has two parts: the base stylesheet filter (that uses and<br />

), and an XML file that contains the various patterns to search for. Keeping the patterns in a<br />

separate XML file allows you to create more customized patterns.<br />

__1. In the policy editor window, drag another Filter action onto the processing rule to the right of the<br />

previously added filter action.<br />

__2. Double click the yellow outlined filter action to complete its configuration.<br />

__3. In the Transform field:<br />

__a. Change the upper dropdown to show: store:///<br />

__b. In the lower dropdown box, select: SQL-Injection-Filter.xsl<br />

__4. Click the Done button.<br />

__5. Click the Apply Policy button to activate these changes.<br />

Lab 2 - Working with XML Page 45

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!