How to use Rational AppScan to scan large web sites more effectively, part 2nd: Case Studies

Using AppScan for scanning

For large web site scanning, we follow the Deming Cycle PDCA methodology for planning and discussion, suggesting AppScan use steps: Plan, execute (DO), check, analyze (analysis and Action).

1. In the planning phase: a clear purpose for strategic selection and task decomposition.
   1. Clear Purpose: Select the appropriate scanning strategy
   2. Understanding objects: First explore to understand the structure and size of the site
   3. Determine the policy: make the corresponding configuration
   4. Decomposition of scan tasks by directory
   5. Decomposition of scan tasks according to scan policy
2. Execution phase: one scan to observe
   1. To scan
   2. Crawl and sweep first (continue testing only)
3. Inspection phase (check)
   1. Check and adjust configuration
4. Results analysis
   1. Compare results
   2. Summary results (consolidation and filtering)

Below we have specific elaboration for each stage.

Preparation phase AppScan installation environment requirements and inspections

To ensure a better scanning effect, the hardware recommendations for installing AppScan are as follows:

Table 1. Rational AppScan Installation Configuration requirements

Hardware	Minimum Requirements
Processor	Pentium p4,2.4 GHz
Memory	2 GB RAM
Disk space	GB
Internet	1 NIC Mbps (network traffic with configured TCP/IP)

wherein, the processor and memory recommendations, the larger the better, and disk space, it is recommended that the system disk (usually C disk) space at least 10G, if the system disk space is relatively small, you can consider to save the user files such as the other disk; The default user file is: C:\Documents and Settings\ Administrator\my Documents\appscan; can be modified to a different path. The path can be modified in the menu bar by selecting Tools-Options-general-File location section.

Figure 1. Set File Save path

Disk requirements: Modifying temporary file paths

Sometimes we will find that the above address has been modified to other disks, but during the scanning process, you will find that the space of the C disk is consumed quickly, the analysis reason, because many temporary files are saved in the C drive , AppScan has a hidden parameter appscan_temp To set the temporary file location. During the scanning process, if the system disk space is compared, you can modify the system variables to change to other hard disk space.

Temporary file Location Description: Describes the location where AppScan's temporary files are saved during normal operation. By default, AppScan stores its temporary files in the following location:

C:\Documents and Settings\All Users\Application Data\ibm\rational Appscan\temp

If you need to modify this default location, edit the path of the environment variable appscan_temp as required. (To access environment variables, right-click My Computer, then select Properties > Advanced > Environment Variables .) ）

Note: There must be no Unicode characters in the path to the new location.

To modify a temporary file in AppScan:

1. right mouse button on the desktop select "My Computer" and select "Properties"
2. Select "Advanced", "Environment variable"
3. Add a new "user environment variable" with the name "Appscan_temp", set the path, and point to the directory where you want to save the temporary file.

Planning Phase

In the planning phase, several questions are identified first:

1. What types of security issues are concerned, and set up scan rules based on these security issues.
2. To scan the website address, the business features of the website.

Selection of scanning strategies

Imagine that we are now scanning a mobile company's website system, the site system provides multiple content channels, but also can connect to a number of other mobile company websites and business sites, our security test is focused on the portal itself and its above the online business. This is a relatively clear test target object.

Then, to determine the scanning strategy, we are mainly concerned about whether the site has cross-site scripting and SQL injection issues, then in the scan rule, we can select both types of rules, and other rules are excluded.

Specific scan rule customization can be selected in the scan configuration-test-test strategy :

In the test strategy, there are a number of different grouping modes, most often using the "severity", "type", "intrusive", "WASC Threat Classification" and other criteria, according to the different groupings of the selected scanning strategy, and finally form a common set of policies.

Based on our goal of this scan, we are concerned with cross-site scripting and SQL injection issues, regardless of the "infrastructure" level of security issues. You can first select a default scan policy, then empty all, then select

Cross-site scripting and SQL injection, and finally remove the security issues related to the underlying results in both of these scanning strategies.

Here's how:

1. Select the default scan policy, or switch the current scan policy to the category " type " and remove the " infrastructure " and " application " types.

   Note: The scanning policy is empty, no scanning strategy is selected, refers to all distribution types select "type" classification, because the type classification contains the type, only two types, can be quickly all canceled off.

2. Group type, switch toWASC threat classification , selectSQL injection and cross-site scripting .
3. Grouping type, switch to " type ", found that this time the "infrastructure" and "application" two types of scanning strategy is the selection of the mode, and is a dashed line, that both types are under a partial scan policy is selected.
4. We don't care about security issues at the infrastructure level, so we're canceling the infrastructurehere.

Figure 2. Test strategy by type category

1. Type of grouping, switch to "intrusive" type, below the "non-intrusive" and "intrusive" two categories. Cancels the test at the infrastructure level.

Intrusive test cases , often because there are relatively strong side effects, may cause damage to the system, so generally scanning production systems, rarely selected. We can look at an intrusive security issue with a SQL injection type, enter "SQL" in the "Enter to find" input box, and then enter the query. You can see the description of the test variant, "set the parameter value to declare/case SQL injection attack (attempt to shut down the DB server)", the test case is used during the scan to execute the command that attempts to close the database, and if the test case is passed, the database is shut down, and the entire system is paralyzed! Therefore, it is very prudent to choose "intrusive test Cases".

Figure 3. Query test Strategy

Figure 3 Big Picture

Other in "type", the "application" type indicates that the problem exists because the application is not rigorous, the code is a security problem caused by the modification method is to modify the original code, and "Infrastructure" type, that the problem is a configuration problem, It is recommended that you modify the system configuration or install the latest patches (often middleware or database patches).

Learn about the site being tested

Before testing the site, we often need to know about the site, such as what technology the site uses, what type of Business (features), website size, etc. These are all related to our scanning settings. For example, we often use a questionnaire to understand the basic characteristics of the system being tested.

Table 2. Record the characteristics of the site being tested

Application System name	Access Address	Application System Architecture (jee/.net/php ... )	URL number	Login method	Remark

Among them, users often confuse the number of URLs, sometimes it is difficult for users to evaluate the approximate number of pages of a system, and according to AppScan, scanning is for each parameter of the page, if more pages, more parameters, the scan to run the longer the time, The larger the scanned file is saved, the more it needs to be decomposed. If a scan task itself has more than 5000 visited URLs, and more than 50,000 security test cases are evaluated, it is recommended that the analysis of the scan configuration be performed and that further task decomposition and division of work is required based on the results of the analysis.

So, if you can find out what pages are specific to the site? Here we can take advantage of AppScan's Exploration (page crawling) capabilities.

After you set the main URL in the scan configuration, in the Work menu, select Scan-Explore only . Explore the site. The discovery tool will typically run for 10-30 minutes to see which pages, which parameters, and so on, the site specifically exists. This lets you switch to the application Data view to view.

We generally care about these views:

• visited URLs (): AppScan pages that have been explored and analyzed
• filtered URLs (): AppScan has been found, and depending on the scan configuration, pages that do not require a security scan.
• Break Link URL (): AppScan found, but could not access or access the wrong page, such as 404 page does not exist, or 500 server error.

Pseudo-Static pages

You can select each node under the URL tree in the " My Application Data " on the left to see the URLs that the node has visited, the URLs that have been filtered out, and so on.

As in the visited URL (), we find a number of HTML pages that resemble the following structure:

http://www. Test.com//focus/satisfy/file5.htmlhttp://www. Test.com//focus/satisfy/file6.htmlhttp://www. Test.com/m-zone/news/dgdd/quanbu/bylb/file5.html

Its common characteristics are the HTML suffix, the final file name format is file+ number format; This type of page often has news, forums and so on. If you visit these pages, found that the page structure is the same, the difference is the text content, such as providing different news content, these pages are so-called "pseudo-static page", in fact, the site publishing system generated dynamically, due to similar results, in the security scan, there is no need for these pages every time to scan. We can set regular expressions to filter, for example, in scan configuration-exclude paths and files, for file+ number format pages that exist under each directory.

Exclude all pages of this type;. *file\d+.html

Add "exceptions" to scan only file1.html and file20.html for this type of page

Other similar pages often exist, as well as news1.html, content200.html and other types, using similar methods.

"Redundant path" of the business type

and "pseudo-static page" corresponding to the other dynamic page, these pages according to the default scanning rules, will be automatically filtered, but according to the real business scenario, these pages do not filter, such as Access demo.testfire.net when the "Filtered URL" will display the following URL Address, the reason for filtering is "path limit":

http://www. Test.com/default.aspx?content=inside_community.htmhttp://www. Test.com/default.aspx?content=inside_press.htmhttp://www. Test.com/default.aspx?content=inside_executives.htm

Select the URL address, the right mouse button " display in the browser ", you will find here the page content is completely different, and the above "pseudo-static page" Just the opposite, these parameters are the same, the parameter value of the dynamic page, is the real business page, is not filtered out; A lot of subsequent business pages will not be found. So why are these pages filtered? According to what kind of rules are filtered out?

In AppScan, by default there is a " redundant path limit " (in the "Scan configuration-Explore selection-redundant path limit"), the default for redundant pages, up to 5 scans, the key question is, what page is AppScan considered redundant page?

Figure 4. Redundant path settings

Simply put:

http://www. Test.com/default.aspx?content=inside_community.htmhttp://www. Test.com/default.aspx?content=inside_press.htm

Appscan is based on "?" Number to separate, if? is considered a redundant page, so the page above is a redundant page.

A page that encounters such a situation is accessed up to 5 times. And these 5 times, specifically what parameters are used, is random, the specific access to the page is also in the application Data view of the "visited URL" view:

http://www. Test.com/default.aspx?content=business.htmhttp://www. Test.com/default.aspx?content=business_lending.htmhttp://www. Test.com/default.aspx?content=inside_contact.htm

However, in this case, the content parameter value is different, in fact, according to business logic, should not be counted as "redundant page", and according to the configuration, will also be automatically filtered, in this case, you need to consider adding "redundant path limit", such as set to 20 or 50. To be able to access these pages more than once.

These conditions often exist in jump parameters and so on.

By the way, "redundant path limit", the purpose of the function setting is to deal with pages such as BBS, only the text content is different, page schema exactly the same page:

Http://www.Test.com/showthread.php?id=1http://www.Test.com/showthread.php?id=2http://www.Test.com/showthread.php?id=3

And when we test demo.testfire.net, we find that every safety test result can be different, one big reason is that each page is accessed differently, which is the effect of this setting.

Parsing duplicate "script arguments"

In the above steps, the "pseudo-static page" is analyzed, the exclusion rules should be set by "Exclude path or file name" method, and for "redundant path of business type", it needs to be expanded by increasing the number of "redundant path display" to scan to these URLs. In this step we analyze another parameter, the script parameter .

In the my application Data tree structure, after the mouse selects the table of contents, select Script Parameters in the right view and see if there are different pages (URLs) with the same or similar parameters: for example, in different URLs, there are kbkey parameters , the default parameter value is "Please enter the question you want to search for":

Figure 5. Script parameters

Figure 5 Big picture

By accessing these URLs, it is found that each page contains a search function, which is why the parameter is found on different pages. From a business perspective, these search pages are tested in one URL and no need to be tested on another page. And the change of the parameter value, can be considered as redundant pages, there is no need for the next step of re-exploration and testing. This can be accomplished by selecting the right mouse button, selecting the "Add to the list in the parameters and cookies" tab after the parameter is selected. Select to eject the following page:

Figure 6 Adding parameter definitions (set redundant paths based on parameters)

Figure 6 Big picture

In this page, click "Other Options-redundancy adjustment", deselect any one of the selection box, that is, whether or not to include this parameter, regardless of whether the value of the parameter is changed, is not considered a new page, there is no need to re-test, and should not be affected by the change of the parameters of other parameters of the test.

We know that the tests in AppScan are done for each parameter of the page, and that a change in the value of a parameter would require a re-test of the other parameters, so this setting can greatly reduce the number of test cases.

For more setup instructions, you can refer to the following explanations:

Table 3. Setup instructions

check box	When selected ...
As soon as you add or remove this parameter/cookie, the URL is explored again.	In the exploratory phase, if the only difference between the two URLs is one that includes this parameter, and the other does not include this parameter, then treat it as a different URL and explore both. For example, if you have the following two URLs, both will be explored: ... page.jsp ... page.jsp?thisparam=value If you uncheck this check box, in this case, only one request will be sent, and the other requests will be discarded.
As long as the value of this parameter/cookie changes, the URL is explored again.	In the exploratory phase, if the only difference between the two URLs is the value of this parameter/cookie, treat it as a different URL and explore both. For example, if you have the following two URLs, both will be explored: ... page.jsp?thisparam=value1 ... page.jsp?thisparam=value2 If you uncheck this check box, in this case, only one request will be sent, and the other requests will be discarded.
As soon as you add or remove this parameter/cookie, all adjacent parameter/cookie tests are repeated.	In the test phase, if the unique difference between the two URLs has been added or dropped, the parameter is treated as a different URL and the adjacent parameters are tested again. For example, if you have the following two URLs, two complete sets of tests, one for each URL, will be generated for the neighboring parameters. ...page.jsp?adjacentparam=<test_this> ... page.jsp?adjacentparam=<test_this>&thisparam=value If you deselect this check box, only one set of tests will be generated for the adjacent parameters.
As long as the value of this parameter/cookie changes, all adjacent parameter/cookie tests are repeated.	In the test phase, if the only difference between the two URLs is the value of this parameter/cookie, it is treated as a different URL and the adjacent parameters are tested again. For example, if you have the following two URLs, two complete sets of tests, one for each URL, will be generated for the neighboring parameters. ... page.jsp?adjacentparam=<test_this>&thisparam=value1 ... page.jsp?adjacentparam=<test_this>&thisparam=value2 if you deselect this check box, only one set of tests will be generated for the adjacent parameter.

View the number of pages per catalog

If a scan task itself has more than 5000 visited URLs, and more than 20,000 security test cases are evaluated, it is recommended that the analysis of the scan configuration be performed and that further task decomposition and division of work is required based on the results of the analysis.

In the " My Application Data " tree structure, after the mouse selects the directory, in the right view, select "Visited URL ()", record the number of URLs, if the directory URL number is larger (more than 500) you can consider a separate scan task for the directory, Only the links below the directory are scanned.

Implementation phase

Based on the scanning strategy identified in the "Planning phase", and the scan settings that were made, re-explore (Scan menu select: Rescan-re-explore), after continuing to analyze the number of pages and number of test cases, if the number of control pages within 5,000, the number of test cases within 20,000, you can directly scan If not, it is recommended to continue the analysis to optimize the scan configuration.

Phased testing

The scanning process of AppScan is divided into two stages of "exploration" and "testing", by default, the full scan mode is used, that is, the edge exploration side is tested. If the site is larger, it is recommended to consider exploring the post-test mode first.

If the URL reaches 5000 and the test needs to reach 50000, you can pause the scan, manually stop the exploration, and select " continue only testing ." Test and test the pages that have been found and analyzed, and then choose " continue to explore only ", i.e.:

Continue to explore only---continue to test only-continue to explore only-a looping process that tests only.

In this process, after a phase is over, it is recommended to review below. Scan file size, if the size exceeds 500M, it is recommended to consider task decomposition, according to the directory can be a scan task decomposition into multiple, or according to the scanning strategy to decompose.

The method is used in the AppScan scanning process to explore the characteristics of the test that can be separated and to support continued scanning during the scanning process.

Scan tasks by Business decomposition

In practice, we scan a large web site that often contains multiple channels, and each channel may require different scan configurations, and these configurations even conflict with each other. As a Web site provides the BBS forum function:

http://www. Test.com/www. Test.com/showthread?channel=1&thread=1001http://www. Test.com/www. test.com/showthread?channel=30&thread=2001

For such a page, after access to find the same structure of the page, only the text content is different, you should use the "redundant path limit" parameter, control the number of scans, there is no need to scan multiple times.

At the same time, a service channel on the site has the following pages:

Http://www.Test.com/default.aspx?content=inside_executives.htmhttp://www.Test.com/default.aspx?content=privacy.htm

The "redundant path" of the business type mentioned above should be scanned multiple times, and the "Redundant path limit" parameter should be increased on the configuration.

In this case, it is necessary to set up scan tasks separately based on the business, each with a different scan configuration.

Inspection phase

During the scan execution, you need to check to see if the following conditions exist:

1. The network connection is not available, or you are prompted that some pages cannot be opened. Check to see if the scan is too fast, the server cannot afford it, modify the scan configuration-connection-communication and proxy as appropriate, increase the number of "timeouts", and consider reducing the number of concurrent threads to allow longer time to wait for the page to affect and reduce the number of access connections to the server.
2. Discover the security issues that are scanned, including security concerns that we don't care about, and then cancel these rules. If a security risk is found, the type is "SQL injection file write (requires user authentication)", the problem is required to be checked by the user, and for the SQL database, if we use a database is not a SQL database, or user confirmation after not found clues, you can in the scan configuration-test- Deselect the policy in the test policy.
3. Perform a "Planning phase" check to see if there are still "pseudo-static pages", "redundant paths for business types," and so on, if present, adjust the scan configuration.

Analysis phase

In the analysis phase, combined with the business characteristics, check whether the scan range, analysis of the scan results, and for the scan out of the problem, analysis, produce a variety of types of reports.

Scan results Check

After the scan is over, it is recommended to switch to the Application Data View, analyze the page, and check that the core pages are tested. Focus on examining the following sections:

1. Interactive URL: Some pages, you must enter the correct information, before you can jump to the next page, such as query phone arrears of the page, you must enter the correct 11-digit mobile phone number, query identity information page, you must enter a 18-digit ID number in order to enter the subsequent page. If not configured, how does AppScan know to enter this information? So if there is an "interactive" url, you can select the URL after the right mouse button, select manual exploration, access these pages in the AppScan browser, enter the corresponding data, then AppScan will automatically record these inputs, and populate the scan configuration-automatic form fill.
2. Broken Links: see which pages during the scanning process, access errors or inaccessible, such as for time out of the page, it may be because of network reasons, the scanning process did not respond in a timely manner, you can choose "Retry all broken Links" to re-access.

Report Analysis

We need to make a comparative analysis of the report or report a summary merge, as follows:

1. Incremental analysis: In the actual work, often to a site regularly scanned, then we can use the report comparison function, compare two times produced results, check which issues have been modified, which are newly discovered security risks. method is to select report-incremental analysis.
2. Report summary and consolidation: And if we break down in the execution phase, according to the business or directory, we may need to merge and summarize multiple scan results, and repeat the problems in the merge process only once, such as scan task A and task B found the apply.jsp ID parameter has XSS security hidden and recorded only once. The consolidation of the report requires the use of the AppScan Enterprise Edition, which features a AppScan standard version of the scan feature and powerful report aggregation capabilities that can produce dashboards, report comparative analysis, trend analysis, and more. You can publish the AppScan Standard Edition report to AppScan Enterprise Edition by selecting File-Export in the menu bar-publishing the results to AppScan Enterprise.

Figure 7. AppScan Standard Edition of scan results published to Enterprise Edition

Back to top of page

Case analysis

Work encountered a case, using AppScan Scan scanned 3*24 hours, scanned scan file has reached 9G; the scan is still ongoing, the overall progress is 30%, you can imagine the scanning speed is very slow, how long will it take to complete the scan? Is the result file so large after the scan completed that it can be opened successfully and saved?

In my experience, if the scan result file is larger than 1G, it is necessary to stop the scan immediately for configuration analysis. Our analysis process is as follows:

2. Discuss with the user, identify the security concerns, develop a test strategy based on these security issues, and then decide on two types of security vulnerabilities: SQL injection and cross-site scripting.
4. To determine the scope of the site, the scanned application is a typical carrier portal, focusing on scanning the portal itself and the "online business" service provided above.
6. Analyze the site under test, configure the site's home page with AppScan, and then select Explore only to run for 20 minutes and discover more than 30,000 pages. Stop exploring and start analyzing the page.
8. The analysis found that the site is the same link, there are different conditions of HTTP, HTTPS access, and the two access methods access to the same page content, then filter out the HTTPS request, centrally test the HTTP request.
10. The analysis found a large number of "pseudo-static pages", such as:

    Http://www.Test.com//focus/satisfy/file5.htmlhttp://www.Test.com//focus/satisfy/file6.html

    In scan configuration-exclude paths and files:

    Exclude all pages of this type;. *file\d+.html

    Add "exceptions" to scan only file1.html and file20.html for this type of page

12. At the same time, the SWF file is discovered and should not be scanned for Flash, so in exclude file types, the setting excludes the SWF file according to the suffix name.
14. Found

    Http://www.Test.com/service

    
    There are a large number of pages of the following types in the directory, all of which are different from the values of the menu parameter, which are found to have different hyperlinks in the page:

    http://www. Test.com/service/business.do?menu=queryhttp://www. Test.com/service/business.do?menu=openhttp://www. Test.com/service/business.do?menu=service

    Confirm that the page is the business type of "redundant path", should be fully scanned, you need to adjust the "Redundant path settings" to a larger parameter, while the channel is an online office channel, but also require users to log in first. Therefore, a separate scan task is established for this directory, and only the directory and its subdirectories are scanned.

16. The analysis found that index.jsp appears in multiple directories, and each occurrence has two formats, that is, there are no parameters and a fixed three parameters, each time the parameter values are the same. Such as:

    http://www. test.com//rdwd/jfmz/jifen/index.htmlhttp://www. test.com//rdwd/jfmz/jifen/index.html?querytype=common&applyarea=010    &kbkey= Please enter the question you want to search http ://www. test.com//rdwd/txl/rdwdznyd/index.htmlhttp://www. test.com//rdwd/txl/rdwdznyd/index.html?querytype=common&applyarea=010    &kbkey= Please enter the question you want to search

    Visit the above page, found that the content is the same, whether with these three parameters does not affect the discovery of more pages, you can set the three parameters each time it appears, whether there are different values can be considered the same page.

    Setup method: In the scan configuration, select "Parameters and cookies" to implement. Then increase the Querytype,applyarea,kbkey three parameters, all set to "whether there are parameters", "parameter changes" does not affect the test mode.

18. Switch to "Application View", analysis "broken link", found some pages exist "scope content exceeds the maximum capacity" situation, in Internet Explorer direct access, found that these pages have a dead loop, the content of the page is infinitely incremented. These pages are excluded from the scan configuration-exclude paths and files.
20. Based on the above settings, two scan tasks have been established, both "SQL injection" and "cross-site scripting" are scanned. After re-exploring, the total number of pages decreased to more than 4,000, the number of test cases was reduced to nearly 50,000, and two scan tasks were completed within 8 hours.

Summarize

AppScan as an automated scanning setup tool, we understand how it works, and we need to optimize the configuration according to the business characteristics of the system under test and the structure of the website, so that we can quickly target scanning.

Common settings are the ability to take advantage of its "explore" function, quickly get the structure, and then analyze the existence of "pseudo-static pages", the "Redundant path" page on the business, "duplicate parameter" page, etc., in the scan configuration corresponding settings.

At the same time, if the site size is still relatively large, it can be divided into multiple scanning tasks according to the business, so as to attack, quickly scan, and combined with Enterprise Edition tools, comprehensive summary analysis.

How to use Rational AppScan to scan large web sites more effectively, part 2nd: Case Studies