Understanding scan coverage in AppScan Standard

Size: px

Start display at page:

Download "Understanding scan coverage in AppScan Standard"

Erik Shields
6 years ago
Views:

IBM Security AppScan Standard Open Mic Webcast January 27, 2015 Understanding scan coverage in AppScan Standard Panelists Shahar Sperling Software Architect at Application Security AppScan Tal

1 IBM Security AppScan Standard Open Mic Webcast January 27, 2015 Understanding scan coverage in AppScan Standard Panelists Shahar Sperling Software Architect at Application Security AppScan Tal Rabinovitch - AppScan Standard Development Manager Daniel Dubnikov - Security Software Developer Warren Moynihan - ethical hacking and AppScan Standard expert Joe Bucanelli - Escalation Lead for AppScan Standard Scott Hurd Client Technical Resolution Specialist Marek Stepien Knowledge & Content Specialist for AppScan Support Kathleen Smith, Moderator Social business manager Reminder: You must dial-in to the phone conference to listen to the panelists. The web cast does not include audio. USA Toll-Free: USA Toll: Participant passcode: Slides & additional phone numbers: NOTICE: By participating in this call, you give your irrevocable consent to IBM to record any statements that you may make during the call, as well as to IBM's use of such recording in any and all media, including for video postings on YouTube. If you object, please do not connect to this call IBM Corporation

2 Goal: Understanding Application Data for configuration The most important aspect of the scan is the Explore phase This is where we identify what we need to test Coverage of the application defines how much of it we scan We want to cover all the business logic We want to avoid over-testing a specific part of the application Automatic Explore needs help! How can you assist AppScan to better cover the application? What information can you draw from AppScan to improve configuration? In this session I will attempt to explain some of the advanced topics in the Application Data and how they can help in optimizing the scan. 2

3 Agenda Review Application Data Layout Review General Information Tabs Review Critical Information Tabs Summary 3

4 Status Bar Information Visited Pages Count of main URL, not including automatic or AJAX links Tested Elements The combination of entity and the list of rules that need to run in each part of the test phase HTTP Request Sent Requests that were sent to the site Does not include in-session requests or server down check requests Total security Issues Security Issues by Severity Demo license indication GlassBox agent status 4 4

Application Tree Application Tree provides a physical view of the URL paths Identify filtered or broken links HTTP/S identify a different application Each port is a new application

5 Application Tree Application Tree provides a physical view of the URL paths Identify filtered or broken links HTTP/S identify a different application Each port is a new application Available operations include: Apply configuration changes: Exclude from scan Record Multi Step Operation Can generate partial reports Manual explore adds directly to application data 5 5

6 Data Tabs Requests All successful HTTP request sent to the server Parameters All query, body (POST), and custom parameters Cookies All cookies identified (including client-cookies) Pages Root requests which should match the Visited Page Failed Request all requests resulting in HTTP 4xx and 5xx errors Filtered all requests not sent due to some filter status User Interaction Needed requests which generated additional authentication processes Comments all the comment that was identified in the JavaScript all the code that was detected in the application 6 6

7 Agenda Review Application Data Layout Review General Information Tabs Review Critical Information Tabs Summary 7

Many look repeated, but represent different sources

8 Requests Review traffic to identify differences URI related data URL Method Parameters query, post, custom Many look repeated, but represent different sources Automatic/Manual explore, pre/post login Recorded login Recorded sequences 8

9 Cookies Cookie properties Response containing set-cookie Values Configuration Tracked Test Exclude 9

10 Pages Examine Navigation Logical root requests 10

11 Failed Requests Requests with 4xx/5xx response codes 11

12 User Interaction Needed Extra user intervention Additional Authorization needed Failed from submission 12

13 Comment and JavaScript Information provided for convenience Tests search for suspicious content Phone numbers, SSN, s, etc. Detail section contains the full content of the JavaScript code or Comment Modern applications contain a critical mass of JavaScript code Content of JavaScript tab can be overwhelming Could be used to find something specific 13

14 Agenda Review Application Data Layout Review General Information Tabs Review Critical Information Tabs Summary 14

15 Filtered Examine Navigation Logical root requests 15

16 Filtered - Details Scan scope Untested Server host name not included in Starting URL and additional domains File Extension Exclude file extensions General Regular Expression Excluded Path/Parameters Scanner Limits technological limitations Unsupported Flash Version Request HTTP Method (supported GET POST PUT DELET) Configuration Redundant Path Limit Depth Limit Page Limit Review these values to identify if too much unique content is missing, increase values if necessary 16

17 Parameters Details include Configuration Session ID tracking Test Included Details Location Type 17

18 Parameters Parameters in the wide sense of the term Query, Post-Data, Multi-Part Form, JSON, XML Path parameters (custom parameters for URL rewriting) Non-standard Query and Body parameters (custom parameters) Parameters are the primary attack mechanisms Constitute the greatest dependency in server side code The most abundant elements in web-applications The single-most dramatic affect on coverage Greatest impact on the content being covered Greatest impact on the size of the scan and length of the test phase Compound, structured, and complex data types JSON and XML based data exchange is very popular AppScan parses structures to attack each value Can create an explosion of test entities could be hundreds in a single request! 18

19 Parameters Standard Locations Query Post Data Multi-part form data Type location where the parameter was identify Simple parameter in a link Text, Select, Hidden, Password, etc. parameter in form submission will be identified by the field type Name the name of the parameter as it appears as part HTTP protocol 19

20 Parameters - Custom Locations Query Path Body Headers advanced configuration Type Custom Name The name is constructed from the name of the custom parameter and an index, if more than one instance of the parameter is identified If the custom parameter has a name, it will also be added to the name as it appears in AppScan 20

21 Parameters Custom examples Nameless parameter the name of the custom parameter in brackets, followed by an index if more than one index appears Example 1: Numeric defined as 8 value digits in path in Parameter identified will be [Numeric] with value of Example 2: Numeric defined as 8 digits in path in Parameter identified will be [Numeric] with value of Parameter identified will be [Numeric]_1 with value of Named parameter the name of the custom parameter in brackets, followed the name and an index Example 1: Numeric defined as 4 name characters followed by 8 value digits in path in Parameter 1: [Numeric] abcd Parameter 2: [Numeric] efgh_1 21

22 Parameters JSON/XML Structured types Locations Body Query Value of query/post-data parameters (complex parameters) Values are encapsulated, meaning each value may contain another structure which is parsed for parameters Type XML JSON Name The name of the parameters is created from the path through the structured type to reach a specific value If the JSON or XML is in the value of query or body parameters, the name of the parameter is also added as a lead in 22

23 Parameters JSON examples JSON body Example { top : { first : 1, second : 2 } } Name Value Type -> top { first : 1, second : 2 } JSON -> top -> first 1 JSON -> top -> second 2 JSON JSON Value Example /index.php?content={ top :{ first :1, second :2}}&target=new Name Value Type content -> top { first : 1, second : 2 } JSON content -> top -> first 1 JSON content -> top -> second 2 JSON content { top :{ first :1, second :2}} Simple Link target New Simple Link 23

24 Parameters XML examples XML body Example <top> <first attr= 2 > 1 </first> </top> Name Value Type -> top XML -> top -> first 1 XML -> top -> first{attr} 2 XML 24

25 Redundancy Tuning Describing affect on application Redundancy tuning is available for parameters (all types) and cookies The affect of a parameter or cookie has on the application Helps avoid exploring redundant content or performing redundant tests Content is only interesting if it exposes new business logic in the server Retesting the same parameter/cookie over and over in the same context will not yield new vulnerabilities 25

26 Redundancy Tuning - Explore Question: Does a parameter introduce new business logic? Question: Does a parameter value affects business logic flow? Explore Redundancy tuning asks the following questions: Should AppScan revisit the page when the value of the parameter changes? Should AppScan revisit the page when the parameter is added or removed? The answers can optimize the coverage of the business logic in the server 26

27 Redundancy Tuning Explore Example layout: Defines the stylesheet to be used Case 1: If layout is missing redirect to SelectLayout.php (a different logic flow) We prefer revisit the URL when parameter is added or removed. We will cover two different flows in the application. We save following the flow that has the parameter, but with a new value. Case 2: If layout is missing, default to flat (not affect on the logic flow) We prefer full redundancy tuning, because all requests follow the same flow, and there is no need to scan it three different times. 27

28 Redundancy Tuning - Test Concept: Each parameter is tested in a request context. The context is the environment of the parameter/cookie. The default is to test the parameter/cookie in each of it s contexts. Question: Does a parameter introduce new business logic? Question: Does a parameter value affects business logic flow? When a parameter is introduced or is given a new value, it creates a new context for it s neighbors. Test Redundancy tuning asks the following questions: Does the parameter value affect the context? Should AppScan retest the neighbors when the parameter value changes? Does the parameter addition or removal affect the context? Should AppScan retest the neighbors when the parameter is added or removed? The answers can optimize the test phase of the scan, making it considerably shorter 28

29 Redundancy Tuning Test Example layout: Defines the stylesheet to be used Case 1: If layout is missing redirect to SelectLayout.php (a different logic flow) We prefer retest neighbors when parameter is added or removed. We don t know how index is used in the redirect, so we must test it there as well. Case 2: If layout is missing, default to flat (not affect on the logic flow) We prefer full redundancy tuning, because index is used in the same way in all three requests. We can save a lot of testing by only testing index in the context of the first request. 29

30 Parameters Structured Redundancy Tuning When repeated records are identified, only the first will be tested (configurable) Sample { report : [ { index :1, value : abcd }, { index :2, value : efgh }, } { index :3, value : ijkl } ] Name Value -> report [{"index":1,"value":"abcd"},{"index":2,"value":"efgh"},{"index":3,"value":"ijkl"}] -> report[0] {"index":1,"value":"abcd"} -> report[0] -> index 1 -> report[0] -> value abcd -> report[1] {"index":2,"value": efgh"} -> report[1] -> index 2 -> report[1] -> value efgh -> report[2] {"index":3,"value": ijkl"} -> report[2] -> index 3 -> report[2] -> value ijkl 30

31 Parameters Management and Configuration Add this parameter Create configuration definition for the parameter directly from the Application Data view Automatically fills in details about the parameter to simplify creating the configuration Include/Exclude Exclude/Include configuration can be dependent on a parameter s value Complements the Application Tree action to exclude a URL by allowing to exclude a URL given a specific value Do not test Creates a parameter configuration from the Application Data view Available in multi-select to avoid test large number of parameters in a single action 31

32 Agenda Review Application Data Layout Review General Information Tabs Review Critical Information Tabs Summary 32

33 Summary Reviewing the explore results is important There are many hints to for the quality of coverage, even without detailed application knowledge Use tools within Application Data to perform some of the work in a simpler manner Parameters The most direct influence on the coverage Compound data types can create an explosion of test entities Careful configuration can reduce over-testing Filtered URLs Best indication for coverage Examine relationship between explored and filtered URLs Indicate complexity of filtering It is worth your time to review the Application Data. It will result in a more affective scan in both time spent scanning and the quality of results reported 33

34 Questions for the panel? Now is your opportunity to ask questions of our panelists. To ask a question now: Press *1 to ask a question over the phone or Type your question into the SmartCloud Meetings chat To ask a question after this presentation: You are encouraged to participate in Forum topics: IBM developerworks forum for IBM Security AppScan Standard 34

35 Where do you get more information? Questions on this or other topics can be directed to the product forum: IBM developerworks forum for IBM Security AppScan Standard Other references: AppScan Standard on IBM Support Portal AppScan Standard demonstration videos How to subscribe to notifications for AppScan products AppScan Standard in IBM KnowledgeCenter Security Support Open Mic Opportunities Follow us: IBM Support Portal Open a Service Request Update your PMR Escalate your PMR 35

Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your

No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access.

36 Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a lawful, comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANY SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

37 Backup 37

38 Tested Elements Explained Entity a part of the application that should be tested (cookie, parameter, request, etc.) Rule a script that tests for a single issue type on a specific entity, with multiple variants Rules can identify global-detection issues as well Test steps there are two steps in the test phase concurrent (running rules in parallel) and serialized (running rules one at a time) Rule Range a list of rules applying to a specific entity which should run in a specific step Test Element defined by an entity and a rule-range Entity that can run concurrent and has no serialized rules, will have one Test Element created for it Entity that should run entirely serialized will have one Test Element created for it Entity that can run concurrent and has serialized rules, will have two Test Elements created of it 38

Disk Space Management of ISAM Appliance

IBM Security Access Manager Tuesday, 5/3/16 Disk Space Management of ISAM Appliance Panelists David Shen Level 2 Support Engineer Steve Hughes Level 2 Support Engineer Nicholas Hasten Level 2 Support Engineer