IBM AppScan and IBM SiteProtector Integration Demo PDF

Security Center of Excellence
IBM Security Course: AppScan and SiteProtector

Integration
Cookbook version 2.0
March 2013
Vladimir Jeremic
jeremic@us.ibm.com
Enablement Specialist
IBM Security Center of Excellence
IBM Software, Security Division
Copyright Notice
Copyright © 2012 IBM Corporation, including this documentation and all software. All rights reserved. May only be
used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum
for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced,
transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any
means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of
IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any
machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM
Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM
Corporation. The document is not intended for production and is furnished “as is” without warranty of any kind. All
warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a
particular purpose.
Note to U.S. Government Users—Documentation related to restricted rights—Use, duplication or disclosure is subject
to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.
Trademarks
The following are trademarks of IBM Corporation or Tivoli Systems Inc.: IBM, Tivoli, AIX, Cross-Site, NetView, OS/2,
Planet Tivoli, RS/6000, Tivoli Certified, Tivoli Enterprise, Tivoli Ready, TME. In Denmark, Tivoli is a trademark
licensed from Kjøbenhavns Sommer - Tivoli A/S.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United
States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries,
or both.
Lotus is a registered trademark of Lotus Development Corporation.
PC Direct is a trademark of Ziff Communications Company in the United States, other countries, or both and is used
by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium, and ProShare are trademarks of Intel Corporation in the United States, other
countries, or both.
SET and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. For further information,
see http://www.setco.org/aboutmark.html.
Other company, product, and service names may be trademarks or service marks of others.
Notices
References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be
available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or
services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used.
Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, any functionally
equivalent product, program, or service can be used instead of the referenced product, program, or service. The
evaluation and verification of operation in conjunction with other products, except those expressly designated by
Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent
applications covering subject matter in this document. The furnishing of this document does not give you any license
to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North
Castle Drive, Armonk, New York 10504-1785, U.S.A.
Table of contents
Introduction .............................................................................................................................. 2
Lab Environment ...................................................................................................................... 3
Users and passwords .............................................................................................................. 4
Demo Scenarios ....................................................................................................................... 5
Assumptions ..............................................................................................................................................5
Configuring the Firewall Policy for Network IPS .................................................................... 6
Scanning AltoroJ application with AppScan ........................................................................ 11
Testing AltoroJ availability for the scan .................................................................................................11
Configuring AppScan to be registered as an agent in SiteProtector .......................................................11
Configuring AppScan to scan the application.........................................................................................13
Running the scan and review the results .................................................................................................22
Reviewing the results in SiteProtector and generating the report. ..................................... 26
Turning on the Web Application Protection (WAP) policy for NIPS.................................... 31
Configuring SiteProtector SecurityFusion policy ................................................................ 33
Testing an attack and SecurityFusion Module ..................................................................... 38
SQL injection attack................................................................................................................................38
Performing SQL Injection to bypass authentication ...........................................................................38
Performing SQL Injection to retrieve data .........................................................................................41
Tuning XPATH_Injection and SQL_Injection decode ......................................................................44
Triggering SQL_Injection decode for authentication bypass attack...................................................47
Cross-site scripting attack .......................................................................................................................51
Performing Cross-site script attack using HTTP GET method ..........................................................51
Performing Cross-site script attack using the HTTP POST method...................................................54
Testing SQL Injection with enabled blocking in the WAP policy ........................................ 57
Modify the WAP policy ..........................................................................................................................57
SQL Injection attack ...............................................................................................................................58
Testing Cross-site scripting with blocking enabled in the WAP policy.............................. 59
Modify WAP policy ................................................................................................................................59
Cross-site scripting attack using the HTTP GET method .......................................................................60
Cross-site scripting attack using the HTTP POST method .....................................................................60
Tuning Cross-site scripting for the HTTP GET method by creating a Response Filter policy...............62
Repeating the Cross-site scripting attack ................................................................................................64
© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration I
Materials may not be reproduced in whole or in part without the prior written permission of IBM.
Tuning the Cross_Site_Scripting decode ................................................................................................65
Triggering Cross-site scripting attack using the HTTP POST method ...................................................67
Tuning Cross-site scripting using the Response Filter policy .................................................................68
Repeating the Cross-site scripting attack using the HTTP POST method ..............................................70
Scaning Mutillidae application with AppScan ...................................................................... 72
Prepare mutillidae for the scan................................................................................................................72
Configuring AppScan to scan Mutillidae application .......................................................... 74
Running the scan and review the results .................................................................................................85
Testing SQL injection attack for Mutillidae .......................................................................... 90
SQL Injection attack – authentication bypass .........................................................................................90
Cross-site scripting Attack for Mutillidae web application.................................................. 92
How to reset AltoroJ DB ........................................................................................................ 94
Resources ............................................................................................................................... 95
II AppScan and SiteProtector Integration © Copyright IBM Corp. 2013
Contacts
If you need a help or would you like to provide feedback, this is the primary contact list.
Question about Contact Role
VMware setup Vladimir Jeremic IBM Security CoE
Rational AppScan Alexei Pivkine AppScan CTP (Sales Engineer)
Vladimir Jeremic
SiteProtector/Network IPS IBM Security CoE
Karl Sigler
© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 1
Introduction
The purpose of this book is to show the integration between IBM Security AppScan and IBM Security
SiteProtector System and how application security can benefit from this integration.
This document refers to VMWare machine images and other lab materials that are not available
for download on developerWorks and requires some prerequisite basic knowledge about products.
This cookbook is offered on developerWorks as a general guide to help IT security practitioners
understand and deploy this integration scenario in their IT environment.
2 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013
Lab Environment
The following virtual machines (VM) are part of this lab setup:
1. Web Server running on Linux (Lubuntu distribution) with a few vulnerable web applications:
– Altoro Mutual
http://192.168.5.111:8080/altoromutual
– Mutillidae1
http://192.168.5.111/mutillidae
– DVWA
http://192.168.5.111/dvwa
2. SiteProtector server running SiteProtector 2.9, with the latest SecurityFusion XPU
3. AppScan server running AppScan Enterprise 8.5 Fix pack 1, or later.
4. Network IPS with firmware 4.5 with security content from November (Version 32.110 or later).
This book primarily focuses on protecting the AltoroMutual web application.
1
http://en.wikipedia.org/wiki/Mutillidae
Users and passwords
The following users’ credentials apply to the various lab components.
Application/Server User Password
VulnerableWWW (Lubuntu) toor password
admin Admin
AltoroJ
jsmith demo1234
SiteProtector (w2k8 + app) Administrator password
AppScan (w2k8) Administrator watchfire
AppScan (application) ADMIN watchfire
admin
NIPS password
root
Demo Scenarios
We demonstrate following use cases
1. Perform policy tuning by creating a Firewall policy in SiteProtector that allows AppScan to run
scans through NIPS without generating security events.
2. Scan the application with AppScan to discover vulnerabilities in the application
3. Review and export results from AppScan to SiteProtector.
4. Review results in SiteProtector and generate report.
5. Configure the Web Application Protection (WAP) policy in SiteProtector to provide visibility and
possibly mitigate vulnerabilities (virtual patch) while they are being addressed by application web
development.
6. Enable the SiteProtector SecurityFusion policy to increase awareness of the web related attacks
reported by App Scan.
7. Initiate attacks (SQL injection and Cross-site scripting) from a browser on the SiteProtector
server, and show SecurityFusion correlation in SiteProtector.
8. Optionally: Add blocking to the WAP policy and demonstrate how the attacker cannot take
advantage of the vulnerability.
Assumptions
1. Network IPS is already registered with SiteProtector.
2. SiteProtector has valid SecurityFusion Module license.
3. AppScan has valid license to scan network 192.168.5.0/24
4. All fix packs are applied.
– AppScan requires 8.5. Fix pack. 1
– SiteProtector requires the fix released after 2.9.07 XPU 1.394 so that the SecurityFusion
module works properly.
Please contact the owner of the document to ensure that you have right fix.
Configuring the Firewall Policy for
Network IPS
We create the Firewall policy for NIPS in SiteProtector that prevents false positive events in the
SiteProtector Analysis view generated by NIPS trying to block scans from AppScan. By applying this
policy, NIPS does not perform deep packet inspection for the traffic between AppScan IP address and
vulnerable web server IP address. This approach is a classic policy tuning step.
5. Login to SiteProtector server and start SiteProtector Console from the desktop
6. At the console login window, use the credentials: Administrator/password.
Note: If you receive a Java error, wait a few minutes and try logging in again. It
takes time to start all services in a virtual machine environment once the image is
(re)started.
7. From the Agent view, select the Network IPS group.
8. Right click the GV1000 and select Manage Policy.
This opens a new Policy tab for NIPS version 4.5.
9. From the right frame, expand Policy not deployed.
10. Right click the Firewall policy and select New policy.
11. In the Create New Policy window, type the name of the policy (for example AvoidScanners).
12. Click OK.
13. In the Firewall policy, create a new rule by clicking the green plus icon in upper right corner.
14. Configure the Firewall rule with following parameters
Field name Value
Enabled Selected
Rule Comment Allow AppScan to scan the network
Action ignore
Protocol Any
2
Source Address (es) 192.168.5.144
3
Target Address (es) 192.168.5.111
2
AppScan IP address
3
Vulnerable Web Server IP address
15. Click OK to save the rule.
16. Click the Save toolbar button to save the policy.
17. In the Save Policy Version window, type Avoid triggering events for AppScan vulnerability
assessment.
18. Select Deploy This New Version.
19. Click OK.
20. In the Deploy Policy window, select Targets.
21. Select Network IPS group as the target for IPS policy.
22. Click OK.
23. Close the Firewall policy.
This concludes the section.
Scanning AltoroJ application with
AppScan
Testing AltoroJ availability for the scan

To verify that the AppScan can reach the application, use a browser from the AppScan server to access to
application:
Configuring AppScan to be registered as an

agent in SiteProtector
The following steps are performed by an administrator to configure the initial integration:
1. Log into the AppScan server virtual machine and clikc the shortcut on the desktop to start
AppScan Enterprise Console.
2. On the login screen type the admin credentials of user name ADMIN and password watchfire.
Note:
a) The name and password are case sensitive.
b) The browser notifies you with a Certificate Exception due to self-signed certificate.
3. In the upper right side, select the Administration tab, then Network Security Systems and under
the SiteProtector Integration section, click the Edit button.
4. On the SiteProtector Server Configuration screen, type the following parameters
Parameter Value Description
Enabled Selected
Valid address of the SiteProtector server on which

Host Name 192.168.5.128
the AgentManager component is running.
Port 3995 Default AgentManager listening TCP port.
5. Click Test Connection to verify communication with SiteProtector.
Note: At this point, AppScan can to communicate with SiteProtector.
6. Click Done to exit General settings.
Configuring AppScan to scan the application

A developer or security specialist performs the following steps to configure a scan against an application.
1. In the upper right corner of the AppScan Console, select Jobs & Reports; click the ASE folder
(top of tree) on the left side of the console and click the + icon (create) on the left side of the
console.
2. Type SiteProtector as a name of the new folder and click Create.
Note: In the figure above, the steps two and three are optional, and we can use
some of the predefined folders such as Online Banking.
3. Click SiteProtector > Users and Groups screen and review default settings.
4. Click Save.
5. Click the SiteProtector folder in the left frame, and then click the + icon in the right frame to
create a new scan job.
On the Create Folder Item screen, type AltoroJ in the Name field.
6. Leave all other settings at the defaults, and click Create to save the settings.
7. On the What to Scan window, in the New starting URL(s) field type:
8. Click the Add button.
The typed web address is displayed in the Start the scan from the following URLs: section.
9. Scroll down to ensure that the In starting domains, only scan links in and below the directory
of each starting URL check box is selected.
10. To test the application, AppScan needs to know how to log into the application.
This is achieved by recording a login.
In the left frame, select Login Management.
11. In the Login Management area, select Recorded (Recommended) and then click the Record
login… button.
12. On the pop up window, click OK.
13. On the Record Login Sequence screen, review the steps and click the Record Login button to
start the process.
The new browser opens with http://192.168.5.111:8080/altoromutual as a starting page.
14. At the top of the application window, click the Sign In link.
15. On the login page, type credentials for username jsmith with password demo1234 and click
Login.
16. The landing page for the user will open.

Click the square sign in the orange circle at the menu bar of the browser to stop recording
Note: The login banner contains information specific for the user:
“Hello John Smith”
17. Close the browser.

You return to the Record login Sequence page.
18. Click Done to finish recording.
You return to the Login Sequence Details page.

19. Review the Login sequence web addresses.
20. Click Save to save login details.
You return to the Login Management page.
21. Review the Login sequence web addresses.
Note: The last web addresses in the Login sequence URL list has the key sign next to it (in
session).
22. If you cannot see it on the screen, scroll down and expand the Login Session IDs (advanced)
section and ensure that JSESSIONID in the cookies is tracked.
23. Validate that In-session detection is enabled with the default pattern looking for Sign Off link.
24. At the left frame, select Explore Options.
25. In the Explore Options > Scan Limits section in the right frame, change Redundant Path limit
to 50.
This feature, which controls the number of requests to test on each page, ensures that AppScan
properly covers of the operations of each page.
26. On the same page, scroll down and insure that JavaScript Execution is enabled.
27. On the left frame, select Test > Security.
28. In the Security Test Policy section, select Application Only test policy, and leave all other
settings at their defaults
The Application Only test policy executes tests that are specific to the application and not to the
infrastructure.
29. Click the Save button at bottom of the screen to save all scan settings.
Running the scan and review the results
1. Navigate to the saved scan setting by selecting Jobs & Reports > SiteProtector.
2. Enable the row with the name AltoroJ and 1 Starting URL in the Contents column, and click
the Run button.
3. To watch the results, click the web address named AltoroJ in the same column where you run the
job
4. When the scan is complete, select Jobs & Reports > SiteProtector to review the results.
5. Select the second URL AltoroJ (16 reports).
You are moved to the new screen
6. At the top of the list, select the Application Security Issues reports.
7. Select the Group tab to reorganize the report (for example by Issue Type). Click Apply after
selecting the grouping option.
8. To export the results to SiteProtector, click the Publish > Publish to SiteProtector button in the
upper right part of the screen.
Note: When you select “To Site Protector”, AppScan shows in Agent view of
SiteProtector top level domain.
9. Verify that AppScan is created in the AppScan Enterprise folder (if not drag and drop the
AppScan agent into this folder).

Reviewing the results in
SiteProtector and generating the
report.
After the results are published from AppScan to SiteProtector, you can use SiteProtector console to
review the scan results and to generate reports.
1. Log in to the SiteProtector console as Administrator with password of password.
2. Select the Analysis view.
3. Select Load View to change the type of data you to display.
4. From Load View window, select AppScan – Security Issue Detail, and click OK.
AppScan data loads into the Analysis view of the SiteProtector Console.
Optionally, review the scan results by loading AppScan – Security Issue Summary.
Important: If you are not able to see the events in the Analysis View and export
process did not report any error you should try following work around:
Add Everyone windows group full permissions on exportchache directory located at
“c:\Program Files\IBM\AppScan Enterprise\WebApp\exportcache” and repeat the export
process.
5. Expand the sections, select an interesting event, and double-click it to examine the event details.
The following figure is an example of authentication bypass.
Note: Note that if you open VariantX.txt you can see details about HTTP traffic.
6. Open the Reporting view and expand the Analysis category.
7. Select AppScan_security Issue Detail and click New Report.
8. From the New Report window, type the report name AltoroJ Scan Details
9. Select Parameters
10. On the Groups tab, select AppScan Enterprise group.
11. On the Content Settings tab, select the Filters tab and in the Column Filters list, verify that
Time is selected. In the Time Filter list, select the appropriate filter to see Scan results.
12. Click OK to generate the report.
Turning on the Web Application
Protection (WAP) policy for NIPS
To detect attacks related to Web application, such as SQL injection and Cross-site scripting, you can
configure the Web Application Protection (WAP) policy.
Perform the following steps in the SiteProtector console:
1. In the Policy view, verify that the Agent Type is Network IPS and Agent Version is 4.5.
2. In the Default Repository, right-click Web Application Protection (Default).
3. Select: Derive New.

The Derive New Policy dialog opens.
4. In the Policy Name field, type AltoroJ.
5. Click OK.
The Web Application Protection policy tab opens.
6. In the Web Protection Categories table, enable all categories of attacks.
Note: Do not enable BLOCK mode, just enable the category.
7. Click the Save Policy toolbar button.
The Save Policy Version dialog opens.
8. In the Enter comments field, type Enabled WAP policy.
9. Select the Deploy This New Version option.
10. Click OK.

The Deploy Policy dialog opens.
11. Click the Targets icon.
12. Select the Network IPS group.
13. Click OK.
14. Close the Web Application Protection policy tab.
15. Verify that the policy is deployed and appears in the Default Repository and under the NIPS
group.
Configuring SiteProtector
SecurityFusion policy
SecurityFusion can provide quicker incident response by focusing on successfully attacked web
vulnerabilities. It also helps in remediation prioritization by providing information on which
vulnerabilities are most attacked so that they can be patched first. To configure the SecurityFusion policy,
perform following tasks:
Note: At this point, you have already configured the Firewall policy in the section
Configuring the Firewall Policy for Network IPS at page 6.
1. If you are not already logged in, log in to SiteProtector Console window, using the credentials:
Administrator and password
2. Select the Agent view and navigate below localhost in the My Sites tree.
You see SiteProtector components as agents with active status; as well as the registered Network
IPS.
3. Right click SecurityFusion Module and select Manage Policy.
4. Confirm that you are now in Policy View (upper right corner), right click FusionPolicy, and
select Derive New.
5. In Derive New window, type the name of the new policy (for example FusionPolicy-AppScan).
6. When the Policy Editor opens, select Host Configuration from the left frame.
7. Add the IP address of the vulnerable web server in the FusionPolicy 192.168.5.111.
8. Click the Validate Hosts… button.
The result IP addresses range displays in the lower edit box on the same screen.
9. Expand Impact Analysis Component Settings.
10. Select Responses for Successful Attack.
11. From the right frame, change the Set severity to value High.
12. Click the Save icon, at upper left corner, to save the policy as fusion-AppScan.xml and close the
Policy view.
13. Switch back to the Agent view.
14. Right click the SecurityFusion Module and select Apply > Policy.
15. In the Apply Policy window, click Policy, select FusionPolicy-AppScan, and click OK.
16. Restart the issdaemon by typing following commands in the command prompt (or using Services
Microsoft Management Console):
net stop issdaemon.

net start issdaemon.
Note: Even though restarting issdaemon should be good enough, the suggested
approach is to restart all services or reboot the server. Not having license can cause the
issue too.
17. Verify that the Fusion has attached policy from Agent view.
18. Verify that the Fusion has status column as Active.
If not, start fusion agent by right-clicking to open the context menu.
Testing an attack and SecurityFusion
Module
This section provides web attack examples and how the attacks are logged/correlated in SiteProtector.
Some basic yet common web application attack types include these two examples:
• SQL Injection
• Cross-site scripting.
SQL injection attack

SQL injection attack leverages application input entry fields to manipulate SQL statements used by
application logic. By manipulating SQL statements, an attacker can bypass authentication mechanisms,
access and retrieve confidential data, manipulate database content including removal of records and/or
complete tables, change records (for example adding dollar amounts to a user’s bank account), and other
actions.
Performing SQL Injection to bypass authentication

In this exercise, you run a SQL injection attack to log in to the web application without knowing the
password. You also verify that the appliance is detecting the attack. Perform the following steps:
1. From the SiteProtector Server desktop, open the browser and type:
The AltoroMutual portal page opens.
2. At the top of the screen, click the Sign in link.
The Login page opens.
3. In the Name field, type

jsmith' or 1=1 --.
4. In the Password field, type anything for example p.
5. Click the Login button.
As the result of attack you are logged in as Admin (not John Smith) without knowing or using the
administrator password. This type of SQL injection attack is also known as authentication bypass.
Important: DO NOT close the browser.
6. Navigate back to the SiteProtector Console.
7. In the SiteProtector Console, Analysis view, verify that an XPATH_Injection event appears
with a High severity.
Note: Verify that you are positioned in the correct SiteProtector group and that you
have the proper Load view.
Note that the Status field is marked as Attack likely successful (vulnerable). Since
SecurityFusion is active, this attack correlates with the imported AppScan results and Fusion
triggers that this event is most likely an attack.
8. Double-click the XPATH_Injection event.
9. In the Event Attribute Value Pairs area, examine the event-info field and the other fields. Note
the field values, the page that was called in HTTP request, source IP, target/destination IP, and
so on.
By examining the event detail fields (especially event-info), we conclude that XPATH_Injection
decode has triggered to indicate a SQL Injection attack on the Web Server. Also note that in the
event detail description at the right frame Default risk level is MEDIUM. However Analysis
view display event with Severity HIGH due to Fusion Policy settings that changes severity of
events that are identified as most likely successful attacks.
10. Close the Event Details window.
Performing SQL Injection to retrieve data

While still logged as admin in the AltoroMutual web site, run an attack that steals account information, by
performing following steps:
1. Navigate back to the browser.
2. Verify that you are still logged into AltoroMutual web site.
3. Click View Recent Transactions on the left side of the page.
A list of recent transactions page opens.
4. In the After field, type following SQL injection attack:

2001-01-01 00:00:00') and 0=1 UNION SELECT 2999 as TRANSACTION_ID,7 as
ACCOUNTID, TIMESTAMP('2001-01-01 00:00:00') as DATE,'User ID: ' ||
USER_ID || '<BR>password: ' || PASSWORD AS TYPE ,7 as AMOUNT FROM
PEOPLE –-
5. Click Submit, and note the returned data.
The Action column contains users’ login credentials.
7. In the SiteProtector Console Analysis view, verify that a SQL_Injection, as well as more
specific HTTP_POST_SQL_UnionSelect events appear with a High severity.
Note at the Status field displays Attack likely successful (vulnerable). Since SecurityFusion is
active, this attack correlates with the imported AppScan results and Fusion indicates that this
event is quite possibly an attack.
Also, the HTTP_HTML_Tag_Injection event is detected because the attack format consists of
the HTML tag for a new line <BR>.
8. Double-click the HTTP_POST_SQL_UnionSelect event.
the field values, the page that was called in HTTP request, source IP, target/destination IP, and so
on.
Note that Default risk level is medium, because of the SecurityFusion policy, the event risk level
is high in the SiteProtector Analysis view.
11. Review other Event Details for SQL injection attacks.
Tuning XPATH_Injection and SQL_Injection decode

XPath (XML Path Language) injection is an attack technique similar to SQL injection that can be used to
exploit Web applications using an XML database that construct run-time XPath queries from user-
supplied input.
If you ran the SQL injection attack, by changing the behavior of the SQL statement behind the scene, you
might wonder why the IBM Security Network IPS triggers on XPATH Injection attack types. In the
PAM.chm help file, the XPATH_Injection decode details state: This signature triggers when well-known
Boolean injection patterns are detected. In the absence of an SQL keyword, then it is most likely than an
XPATH injection attempt has been made.
Because your attack did not use SQL keywords (such as SELECT, UNION, etc.), PAM generates false
positive events because it triggers XPATH injection instead of SQL Injection. By investigating the details
of an attack, you realize that the attack is SQL Injection (not XPATH) and we should tune SQL_Injection
decode.
To tune the SQL_Injection decode, perform following steps:
1. From the SiteProtector Console Agent view, select the Network IPS group.
2. Right click the GV1000 and select Manage Policy.
This opens a new Policy tab for NIPS version 4.5.
3. From the right frame, expand Policy not deployed.
4. Right click the Tuning Parameters policy and select New policy.
5. In the Create New Policy window, type the name of the policy (for example Tune NIPS).
6. Click OK.
7. In the Tuning Parameters policy, click the green plus icon in upper right corner.
8. Create a tuning parameter with the following values:
Name Value Comment
pam.injection.sql.boolean.triggers 2 Always trigger SQLi
A value 2 (two) provides that a Boolean pattern always triggers the SQL_Injection event, even if
SQL keywords are not present in conjunction with the Boolean pattern.
9. Click OK to save the parameter.

11. In the Save Policy Version window, type Tune SQLi value =2.
13. Click OK.
15. Select the Network IPS group as the target for IPS policy.
16. Click OK.
17. Close the Tuning Parameters policy.
Triggering SQL_Injection decode for authentication bypass

attack
To demonstrate the change in signature behavior, repeat the authentication bypass attack.
1. From the SiteProtector Server desktop, open your browser and type:
2. At the top of the screen, click the Sign in link
3. In the Name field, type

jsmith' or 1=1 –-
4. In the Password field, type anything (for example p).
5. Click the Login button.
As a result of the attack, you are logged in as Admin (not John Smith) without knowing or using
the administrator password. This type of SQL injection attack is also known as authentication
bypass.
7. Navigate to SiteProtector Console.
8. In the SiteProtector Console, Analysis view, verify that a SQL_Injection event appears with a
High severity.
Note that the Status field is marked as Attack likely successful (vulnerable). Since
SecurityFusion is active, this attack correlates with the imported AppScan results and Fusion
triggers that this event is quite possibly an attack.
Note: The Analysis view also displays another event, HTTP_URL_repeated_char, that you can
explore to better understand other possible attacks to the vulnerable web application. This event is not
correlated with AppScan results and has a default status of Detected event.
9. Double-click the SQL_Injection event.
the field values, the page that was called in HTTP request, source IP, target/destination IP, and so
on.
Cross-site scripting attack
The Cross-site scripting (XSS) attack uses application input entry fields to inject malicious JavaScript. By
injecting the script, the attacker can infect the browser and computer with malware, redirect the browser
to a malicious site and so on.
Depending on the design of the input entry fields, two HTTP request behaviors cause differences in the
cross-site scripting attacks:
• HTTP GET method
• HTTP POST method
Performing Cross-site script attack using HTTP GET method

To run a cross-site scripting attack and verify that the appliance is detecting the attack, perform the
following steps:
2. At the top of the screen, locate the Search box and type the following script:
<script>alert(’Hello World’) </script>
3. Click the GO button.

The coss-site scripting attack executes and the Hello world pop up window opens.
5. In the SiteProtector Console, Analysis view, verify that a Cross_Site_Scripting event appears
as a High severity event.
have the proper Load view
6. Verify that the HTTP_GETargscript event also appears as High severity event.
Note that the Status field for the both decodes are marked as Attack likely successful
(vulnerable). Since SecurityFusion is active, this attack correlates with the imported AppScan
results and Fusion triggers that this event is a likely attack.
7. Double-click the Cross_Site_Scripting event.
8. In the Event Attribute Value Pairs area, examine the event-info field, the page that was called
in the HTTP request, source IP, target/destination IP, and so on.
Note in the right frame that the Default risk level is Medium. Due to Fusion correlation, the attack
is displayed with a High severity (see step 12 in Configuring SiteProtector SecurityFusion policy
section).
9. Close the Event details window.
10. Double-click the HTTP_GETargscript event.
11. In the Event Attribute Value Pairs area, examine the event-info field, the page that was called
in :URL Attribute name filed, request, source IP, target/destination IP, and so on.
Note in the lower left frame (Event Attribute Value Pairs) that fusion-intruder-ip-addr and
fusion-victim-ip-addr are reverted to what PAM originally reports in Target IP Address and
Source IP Address (upper left table with Event Details).
Performing Cross-site script attack using the HTTP POST

method
To run a Cross-site scripting attack and verify that the appliance is detecting the attack, perform the
following steps:
2. Click the Feedback link at the top of the screen
3. On the Feedback form, in the Your Name field type the attack script:
4. Click the Submit button.

The Cross Site Scrip attack runs and the Hello world window opens.
6. In the SiteProtector Console, Analysis view, verify that a Cross_Site_Scripting event appears
with a High severity event.
7. Verify that HTTP_POST_Script event also appears as a High severity event.
Note that the Status field for the both decodes are marked as Attack likely successful
(vulnerable). Since SecurityFusion is active, this attack correlates with the imported AppScan
results and Fusion triggers that this event is a likely attack.
8. Double-click the HTTP_POST_Script event.
9. In the Event Details window, examine the details regarding Default risk level (Medium),
fusion-intruder-ip-addr, fusion-victim-ip-addr and other relevant fields..

Testing SQL Injection with enabled
blocking in the WAP policy
To prevent attacks detected by the Network IPS, escalate and report the attacks to development so that a
patch for the web application can be created. In addition, the Network Intrusion Prevention System
provides a virtual patch by blocking attacks on the network segment controlled by a Network Intrusion
Prevention System device. While the application is not patched, it is protected by the Network Intrusion
Prevention System appliance.
Modify the WAP policy

To enable blocking in SiteProtector to protect the Altoro applications, perform following steps:
Note: These are high level policy configuration steps (for the details, refer to the
section Turning on the Web Application Protection (WAP) policy for NIPS)
1. Open the WAP policy that is deployed on the Network IPS.
2. In the policy, enable Blocking for Injection Attacks Category (the type of SQL Injection attack
demonstrated in the previous exercise).
3. Save and deploy the policy.
SQL Injection attack
1. Open the browser and access AltoroMutual at
http://192.168.5.111:8080/altoromutual.
2. Perform the SQL Injection attack using the jsmith account.

Notice how the browser responds differently because it cannot perform the HTTP request.
4. In the SiteProtector Console, Analysis view, verify that a SQL Injection attack is blocked.
have the proper Load view

Testing Cross-site scripting with
blocking enabled in the WAP policy
In this section we will discuss the blocking of Cross-site scripting type of attacks, that falls under
Client-Side Attacks category in WAP policy.
Modify WAP policy

To enable blocking in SiteProtector Console to protect the AltoroMutual application, perform following
steps:
Note: These are high level policy configuration steps (for the details, reefer to
WAP Policy configuration section).
1. Open the WAP policy that is deployed on the Network IPS.
2. In the policy enable Blocking for Client-Side Attacks Category (Cross-site scripting attacks
demonstrated in the previous exercise).
3. Save and deploy the policy.
Cross-site scripting attack using the HTTP GET
method
1. Open the browser and access AltoroMutual at http://192.168.5.111:8080/altoromutual.
2. Perform the Cross-site scripting attack by inserting the following script in the search field and
clicking the GO button.
<script> alert('Hello World') </script>
Important: The attack is successful even though blocking is enabled. Also, note that
this attack was performed using the HTTP GET method.
4. In the SiteProtector Console, Analysis view, verify that a Cross_Site_Scripting and

HTTP_GETargscript attacks are reported but not blocked.
Cross-site scripting attack using the HTTP POST

method
1. To perform the attack using the HTTP POST method, open the browser and access:
http://192.168.5.111:8080/altoromutual/feedback.jsp.
2. Type the same script into Your Name edit field:
<script>alert('Hello World')</script>
3. Click the Submit button and note the Browser error page “The Connection was reset.”
Blocking of this Cross-site scripting attack using the HTTP POST method was successful.
5. In the SiteProtector Console, Analysis view, verify that Fusion detected Cross_Site_Scripting
event for successful attack, but the second event HTTP_POST_Script reported blocking.
Note that since the SecurityFusion Module is not correlating blocked attacks, the reported event
HTTP_POST_Srcipt has a Medium severity, which is the default value. Also, notice that
Cross_Site_Scripting decode was reported with no blocking and SecurityFusion module
performs correlation marking event as attack likely successful.
Important: The reason why certain cross-site scripting attacks performed using the
HTTP GET method are not blocked is based on guidance from the IBM X-Force. It is
common for real world web applications to post script using HTTP GET method for
various legitimate reasons. The decision to have the blocking response disabled by
default is to prevent inadvertent outages of customer web applications. If your web
application is not designed to use this feature you can override the default behavior to
implement a block response using the Response Filter policy described in the next
section.
Tuning Cross-site scripting for the HTTP GET
method by creating a Response Filter policy
To create a Response Filter policy, perform the following steps in the SiteProtector console:
1. In the Policy view, verify that the Agent Type is Network IPS and Agent Version is 4.5.
2. In the Default Repository, right-click Response Filters.
3. Select Derive New.

The Derive New Policy dialog opens.
4. In the Policy Name field, type Cross_Site_Scripting Tuning.
5. Click OK.
The Response Filters policy tab opens.
6. In the Response Filters policy, create a new rule by clicking the green plus icon in the upper
right corner.
7. Specify the Response Filter rule with following parameters:
Field name Value
Enabled Selected
Protection Domain Global
Event Name HTTP_GETargscript
Severity High
Block Enabled
Field name Value
4
5
Destination Address (es) 192.168.5.128
Source Port(es) any
Destination Port(es) any
Note: Becuase the Network IPS sees this as a client side attack, the source and
destination address are changed. We use SiteProtector to run the attack.
4
5
SiteProtector IP address
8. Click OK to save the rule.
10. In the Save Policy Version window, type Enabled Blocking for HTTP_GETargscript decode.
12. Click OK.
14. Select the Network IPS group as the target for the policy.
15. Click OK.
16. Close the Response Filter policy.
Repeating the Cross-site scripting attack

Now that you have a proper response filter policy in place, you can block cross-site scripting attack using
HTTP GET method.
1. Open the browser and point to AltoroMutual at

2. To perform the cross-site scripting attack, insert the following script in the Search field and click
GO.
Note that the attack is blocked this time and the web page is not reachable.
4. In the SiteProtector Console, Analysis view, verify that the cross-site scripting attack using the
HTTP GET method is blocked.
Tuning the Cross_Site_Scripting decode

By default, IBM Network IPS always reports the Cross_Site_Scripting decode in conjunction with a more
specific decode that describes the attack. You can tune this behavior so that the IBM Network IPS only
shows the single ‘generic’ decode Cross_Site_Scripting. To demonstrate this behavior, change the PAM
tuning parameter which forces Cross_Site_Scripting to trigger in place of the other events.
To tune the Cross_Site_Scripting decode, perform following steps:
1. From the Policy view, select the Network IPS group.
2. In the upper right frame, double click the Tuning Parameters: Tune NIPS policy.
3. In the Tuning Parameters policy, create a new rule by clicking on the green plus icon in the
upper right corner.
4. Specify the tuning parameters with following values:
Name Value Comment
pam.injection.xss.supression 1 Only trigger Cross_Site_Scripting
A value 1 (one) provides that HTTP_GETargscript and HTTP_POST_Script do not trigger, but
Cross_Site_Scripting triggers in their place.
5. Click OK to save the parameter.
7. In the Save Policy Version window, type Tune Cross_Site_Scripting behavior and SQLi=2.
9. Click OK.
11. Select the Network IPS group as the target for IPS policy.
12. Click OK.
13. Close the Tuning Parameters policy.
Triggering Cross-site scripting attack using the

HTTP POST method
To demonstrate the change in PAM decode behavior, repeat the HTTP POST attack.
Note: By default, this type of attack blocks when the WAP policy blocking is
enabled (there is no need to configure Response Filters).
1. From the SiteProtector Server desktop, open your browser and navigate to the Feedback page of
the AltoroMutual web site:
http://192.168.5.111:8080/altoromutual/feedback.jsp
2. On the Feedback form, in the Your Name field type the following the attack script:

The Cross Site Scrip attack runs and the Hello world window opens.
5. In the SiteProtector Console, Analysis view, verify that ONLY the Cross_Site_Scripting event
appears with a High severity, and that Fusion correlates the event (the attack is not blocked).
The reason for this change in behavior is in tuning parameters, because the events which are
suppressed by the configuration of pam.injection.xss.supression tuning parameter WILL NOT
invoke blocking responses, even if they otherwise would block certain traffic patterns. A
Response Filter has to be created for Cross_Site_Scripting decode to enforce blocking of
cross-site scripting attacks when the default pam.injection.xss.supression behavior is changed.
Tuning Cross-site scripting using the Response

Filter policy
To modify a Response Filter policy, perform the following steps in the SiteProtector console:
1. From the Policy view, select the Network IPS group.
2. In the upper right frame, double click the Tuning Parameters: Tune NIPS policy.
3. In the Response Filters policy, create a new rule by clicking the green plus icon in the upper
right corner.
4. Specify the Response Filter rule with following parameters:
Field name Value
Enabled Selected
Protection Domain Global
Event Name Cross_Site_Scripting
Severity High
Block Enabled
6
7
Destination Address (es) 192.168.5.128
Source Port(es) Any
Destination Port(es) any
Note: Since the Network IPS sees this as a client side attack, the source and
destination address are changed. We use the SiteProtector server to execute the attack.
6
7
SiteProtector IP address
5. Click OK to save the rule
7. In the Save Policy Version window, type Override default behavior for Cross_Site_Scripting
decode.
9. Click OK.
11. Select the Network IPS group as the target for the policy.
12. Click OK.
13. Close the Response Filter policy.
Repeating the Cross-site scripting attack using

the HTTP POST method
1. From the SiteProtector Server desktop, open your browser and navigate to the Feedback page of
the AltoroMutual web site:
http://192.168.5.111:8080/altoromutual/feedback.jsp
2. On the Feedback form, in the Your Name field, type the following attack script:
Note that the browser opens “The Connection was reset” page.
The blocking of this Cross-site scripting attack using HTTP POST method was successful.
5. In the SiteProtector Analysis view, verify that only a Cross_Site_Scripting event was detected
and reported blocking.
Note even though the SecurityFusion Module is not correlating blocked attacks, the reported
event Cross_Site_Scripting has HIGH severity (Medium is the default value) because of the
Response Filter policy.
Note: You might see that SiteProtector Analysis View reports multiple events for
the same attacks (especially if you have multiple protection domains). This bug is
recognized by development and the fix will come soon.
Scaning Mutillidae application with
AppScan
You should prepare the mutillidae site to a clean starting point before initiating the scan. Then, AppScan
should be configured with the proper parameters to execute scans with the ability to maximize the number
of discovered vulnerabilities.
Prepare mutillidae for the scan

1. From SiteProtector virtual machine, use Firefox to access the application at
http://192.168.5.111/mutillidae
2. From the left side of the screen, click Setup/Reset the DB.
3. Return to the starting page and click the Register link to create a user account that is used in the
scans.
Note: The mutillidae application has a few users with an unknown password. For
demonstration purposes, create a new user (for example jdoe) with the password tse123.
4. On the registration page, fill out the user name and password as well the Signature field that
shows up in the login banner.
Parameter Value
User name jdoe
Password tse123
Password confirm tse123
Signature Bad hacker
5. Click the Submit button
6. You receive information that the Account is created.
7. Click the Login link to test the login in with the jdoe credentials.
Configuring AppScan to scan
Mutillidae application
1. In the upper right corner of AppScan Console, select Jobs & Reports; click the ASE folder (top
of tree) in left side of console and click on + sicon (create) in the left side of the console.
2. Type SiteProtector as a name of the new folder and click Create.
3. Select the new SitepPotector folder and click the + icon in the right frame to create a new scan
job.
4. On the Create Folder Item screen, type mutillidae in the name field and leave as default the
other parameters.
5. Click Create to save the settings.
6. On the new What to Scan window, type in the New starting URL(s) type
http://192.168.5.111/mutillidae/index.php
7. Click the Add button.
The URL displays in the Start the scan from the following URLs section.
8. Scroll down to verify that the check box is selected next to In starting domains, only scan links
in and below the directory of each starting URL
9. In the left frame select Login Management, in Login Method select Recorded
(Recommended), and then click the Record login… button.
10. On the pop up window, click OK.
11. On the Record Login Sequence screen, review the steps and click the Record Login button to
start the process.
12. The new browser opens with http://192.168.5.111/mutillidae/index.php as the starting page.
13. At the web application left frame, click the Login link.
14. On the login page, type the credentials for user jdoe (jdoe/tse123) and click Submit.
15. The landing page for the user opens. Click the square sign in orange circle on the menu bar of
the browser to stop recording, and close the browser.
Note: The login banner contains information specific to jdoe:
“You are logged in as jdoe

Bad Hacker!”
16. You return to the Record login Sequence page. Click Done to finish recording.
17. You return to the Login Sequence Details page. Review the Login sequence URLs and click
Save to save login details.
18. You return to Login Sequence Details page. Review the Login sequence URLs and click Save to
save the login details.
Note: The last URL in the Login sequence URL list has the key sign next to it (in
session).
19. You return to the Login Management page. Scroll down and expand the Login Session IDs
(advanced) section and verify that only the UID stored in the cookie is tracked.
20. Expand the In Session Detection Details section. Select the check box next to Activate in-
session detection, and type the following pattern (session string):
You are logged in as jdoe.
21. Click the Update button.
22. In the left frame, select Exclude Paths and Files, and click New URL Exclusions (Prefix or
Pattern).
23. In the edit field, type the following: http://192.168.5.111/mutillidae/setupreset.php, then click
Done.
24. In the left frame, select Explore Options, and in the Explore Options section in the right frame
change Redundant Path limit to 100 Max.
25. On the same page, scroll down and insure that JavaScript Execution is enabled.
26. In the left frame, select Test- > Security, and in the Security Test Policy section select
Application Only test policy.
27. Click the Save button at bottom of the screen to save the scan settings.
Running the scan and review the results

1. Navigate to the saved scan setting by selecting Jobs & Reports > SiteProtector.
2. Add a check mark next to the mutillidae and click the Run button.
3. To watch the results, click the URL named mutillidae
4. When the scan is complete, select Jobs & Reports > SiteProtector and review the results.
5. Then, select the econd URL mutillidae (16 reports).
You are routed to the new screen
6. Select the Application Security reports.
7. Select the Group tab to reorganize the report (for example by Issue) and click Apply after selecting
the grouping option.
8. To export all results to a pdf, an Excel file, or to SiteProtector, click the Export button in the upper
right part of the screen.
Note: At this point, AppScan shows in theAgent view of SiteProtector in the top
level domain.
9. Ensure that AppScan is created at AppScan Enterprise
10. If not drag and drop AppScan agent into AppScan Folder from the root folder (top level tree node)
Testing SQL injection attack for
Mutillidae
SQL Injection attack – authentication bypass

To run an injection attack and verify that the appliance is detecting the attack, perform the following
steps:
http://192.168.5.111/mutillidae/
The Mutillidae: Hack, Learn, Secure, Have Fun!!! page opens.
2. In the left column, under Core Controls, click the Login link.
3. In the Name field, type admin.
4. In the Password field, type

' or '1'='1

You are logged in as admin.
6. In the SiteProtector Console, Analysis view, verify that a SQL_Injection event with a High
severity appears.
Note: This demonstration shows the deficiency of Fusion because it does not
distinguish between two applications running on the same web server. Even though
AppScan did not import vulnerability assessment results into SiteProtector, Fusion marks
this event as highly possible because it runs on the same IP as AltoroJ.
7. Double-click the SQL_Injection event.
8. In the Event Attribute Value Pairs area, examine the value field and note the value ‘or ’1’=’1.
9. Close the Event Details dialog.
Cross-site scripting Attack for
Mutillidae web application
1. To perform the attack using the HTTP POST method ,open the browser and access:
http://192.168.5.111/mutillidae/?page=add-to-your-blog.php
2. Type the same script into blog edit field:

<script>alert('Hello World') </script>
3. Click the Submit button
Note: This time we are executing the HTTP POST method.
4. In the SiteProtector Console, Analysis view, verify that a Cross_Site_Scripting event was
detected by Fusion for successful attack on the altoromutual application, and that the attack to
the mutillidae application was blocked.
Note: Insure that you are positioned at right SiteProtector Group and that, and that
you have Load proper view.
Note that since the SecurityFusion Module is not correlating blocked attacks, the reported event
Severity is Medium, which is the default value.
How to reset AltoroJ DB
AltoroJ comes with preinstalled Derby Database. Due to hacking and exploring the AltoroMutual website
you end up with changing default content of database. If so, you can use following steps to reset the
database:
1. Stop TomCat
/etc/init.d/tomcat6 stop
2. Remove database files:

rm -r /var/lib/tomcat6/altoro
rm -r /usr/share/tomcat6/altoro
3. Start Tomcat
/etc/init.d/tomcat6 start
4. Use the browser to login to AltoroMutual with credentials jsmith/demo1234

Resources
• AppScan Forum
Please report all questions or issues, whether they are technical or with the script, to the Security
(Watchfire/Ounce) community of practice forum
http://ibmforums.ibm.com/forums/forum.jspa?forumID=2968&start=0
• AppScan Community of Practice –

http://w3.ibm.com/connections/communities/service/html/communityview?communityUuid=6bb
1ce65-9c19-4d6c-ab67-9ca4504219ff
Key Resources for the Community
http://w3.ibm.com/connections/blogs/NASecurityPractice/entry/some_recent_helpful_files_you_s
hould_take_a_look_at2?lang=en_us
• ISS Technical Product Marketing Community

https://w3-
connections.ibm.com/communities/service/html/communityview?communityUuid=d62fe109-
8c2f-4196-91c7-5e1c0ead813b
• NIPS Firmware 4.4 forum

https://w3-
connec-
tions.ibm.com/wikis/home?lang=en_US#/wiki/W861fe756b541_4ebb_a2dc_63b22df6f4aa/page/
FAQ%20-%20Firmware%204.4%20%28SNORT%29
==EOF

IBM AppScan and IBM SiteProtector Integration Demo PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IBM AppScan and IBM SiteProtector Integration Demo PDF

Uploaded by

Copyright:

Available Formats

Security Center of Excellence

IBM Security Course: AppScan and SiteProtector

II AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

Question about Contact Role

VMware setup Vladimir Jeremic IBM Security CoE

Rational AppScan Alexei Pivkine AppScan CTP (Sales Engineer)

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 1

2 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

3. AppScan server running AppScan Enterprise 8.5 Fix pack 1, or later.

This book primarily focuses on protecting the AltoroMutual web application.

Application/Server User Password

VulnerableWWW (Lubuntu) toor password

SiteProtector (w2k8 + app) Administrator password

AppScan (w2k8) Administrator watchfire

AppScan (application) ADMIN watchfire

4 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 5

6. At the console login window, use the credentials: Administrator/password.

7. From the Agent view, select the Network IPS group.

8. Right click the GV1000 and select Manage Policy.

6 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

9. From the right frame, expand Policy not deployed.

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 7

12. Click OK.

14. Configure the Firewall rule with following parameters

Field name Value

Rule Comment Allow AppScan to scan the network

16. Click the Save toolbar button to save the policy.

18. Select Deploy This New Version.

19. Click OK.

20. In the Deploy Policy window, select Targets.

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 9

22. Click OK.

23. Close the Firewall policy.

This concludes the section.

10 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

Testing AltoroJ availability for the scan

Configuring AppScan to be registered as an

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 11

4. On the SiteProtector Server Configuration screen, type the following parameters

Parameter Value Description

Valid address of the SiteProtector server on which

Port 3995 Default AgentManager listening TCP port.

12 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

Note: At this point, AppScan can to communicate with SiteProtector.

6. Click Done to exit General settings.

This concludes the section.

Configuring AppScan to scan the application

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 13

14 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 15

16 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

12. On the pop up window, click OK.

The new browser opens with http://192.168.5.111:8080/altoromutual as a starting page.

© Copyright IBM Corp. 2013 AppScan and SiteProtector Integration 17

16. The landing page for the user will open.

18 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

17. Close the browser.

18. Click Done to finish recording.

You return to the Login Sequence Details page.

21. Review the Login sequence web addresses.

20 AppScan and SiteProtector Integration © Copyright IBM Corp. 2013

24. At the left frame, select Explore Options.