Manual Scan & WorkFlow Driven Scan Clarification
I have to an authenticated scan of an application. There is a account lockout feature, due to which the account gets locked after 3 failed attempted.
Earlier I used to record a login macro for the authentication. Then I found that the application gets locked.
So I preferred to do a manual scan of the application. First I login to the application in Mozilla. I start the scan and then change the proxy of Mozilla in order to do the crawling.
Here are my doubts
1. If I close the Mozilla broswer after the manual crawling gets over, will it affect the scan ? I am mean will it act as an authenticated scan ?
2. In a manual scan, am I supposed to click on all the links in the page for effective scan ? Do I have to input data to all forms so that the tool gets to know it has to input parameters into that field ?
3. Suppose there is a CAPTCHA in a page. And I have to scan that page by excluding that CAPTCHA. How will I do it in manual mode ? Also, can it be done in WorkFlow ? I guess WorkFlow macro will be effective when CAPTCHA is in a different page. Can it be effective in same page ?
**** You need to coordinate a testing account that will not get locked out.
WebInspect will test forms with valid and invalid values. This includes the Login Page forms, even if a Login Macro is used for maintaining session state. You could put in Session Exclusions to avoid the Login Page, and yet your Login Macro will still be permitted to go there. However, there can still be numerous places in any app where session state is re-requested or where input fuzzing activity will get noticed and the site will drop your session state on purpose. Work smarter by getting a test account that does not lock. Your goal is to test the app's inputs, not break into the site's login system.
The Manual Scan is ok, but my preference is to use automation for repeatability and so I would choose to use a Login Macro instead. Manual Scan requires you to kick it off, and depending on your depth of browsing, this can be an aggravating time-spend and will probably not be identical scan-to-scan.
With Manual Scan, when finished manually browsing, you click the Finish button found in the Site Tree of WebInspect. At that point you can close your connected browser, or reopen it with the available Step-Mode button found beneath the Site Tree pane.
Once Finished with the manual browsing, do you want to then proceed to an automated Crawl, or an Audit of the sessions, or both?
- Crawl - Right-click one of the Sessions and choose Crawl From Here, and let it run to completion. I would select the top or root Session.
- Audit - Click the red Audit button found in the Toolbar area, select the desired scan Policy, and let it go to completion.
- both - Do the Crawl From Here step above, wait for it to complete, then click the Audit button when that completes.
How and when this Auditing occurs can be changed, but I do not recommend it. Auditing while browsing may destroy your session state more. Open the Edit menu > Application Settings > Step-Mode panel. the default mode is Manual Audit, which uses the patterns I described above in the three bullet points. You can change that to Audit As You Browse, but it may not give you what you are seeking.
Here is what the Help Guide (F1) describes for these modes.
Audit as you browse: While you are navigating a target Web site, WebInspect concurrently audits the pages you visit.
Manual Audit: This option allows you to pause the Step Mode scan and return to WebInspect, where you can select a specific session and audit it.
Session state does not truly depend on the connected browser, especially once the user clicks Finish in WebInspect. However, as you proceed to the Crawl or Audit phases, session state will most likely get lost at some point, and not regained. This is why I would recommend recording a Login Macro and then adding that Macro to the Authentication scan settings for the scan, even though it will be a "Manual scan". A Login Macro will auto-run as needed during those automated portions of the post-Manual Scan.
How many sessions you manually browse is up to you. If you will be using the Audit feature only, then only the sessions you click through will be tested. Again, my preference is automation, so I would prefer to prerecord the desired sessions with either the Workflow Macro Recorder tool or the Web Proxy tool, or even BURP. The output saved from those can be Imported in the Guided Scan Wizard as Workflows. Notice that when enabling the option for a Workflow-driven scan, the scan mode changes from Crawl-and-Audit to Audit-Only, but you can select that back if you merely want the Workflows to force-feed the Crawler.
If specific or preferred values are needed for the site's forms, I would prefer you record those in advance with the Web Form Editor tool. When recorded, they are segregated by the precise URL where each form was encountered/submitted, but you can right-click them and choose "Make a Global Input". This option then permits that recorded value to be used for that form regardless of the URL where it may be encountered in the future. You can then specify your customized/augmented Web form input file in the scan settings. Look for the MEthod panel > "Auto fill web forms..." Notice in the tool that the Default entry for any encountered field whose name has not matching entry will be "12345", but you can change that value in the right-click menu. If a scan comes back with many, many, many entries of "12345" or even errors stating that an improper format was submitted for something, it is a sign that maybe you could have exposed more of the attack surface with a few customized values.
I may not understand this question. If you put in a Session Exclusion scan setting, WebInspect will avoid going to the CAPTCHA/page, but then WebInspect will probably not discover and scan the areas protected behind the CAPTCHA, right?
If you must scan through a CAPTCHA or other two-factor mechanism, you will want to enable the Interactive Scan. This requires two preparations. first, record the CAPTCHA page in the Web Form Editor tool, then right-click that form and choose "Mark as Interactive". Add your customized web form input file to the scan settings. Next, open the scan settings > and enable both boxes for "Prompt for web form values..." and "Only prompt for tagged inputs". You will then be prepared to run a "Mostly Automated" scan, where it runs per normal until it encounters that tagged field and pops a browser window asking for your human input. this pop-up will only Pause the current Thread, not the rest of the scanner threads you have defined in the Requestors scan settings panel.
A cleaner option is to install the free WebInspect Agent on the target server. WI Agent will give WebInspect a "free pass", essentially informing the CAPTCHA framework that the required input was submitted "true". WI Agent is a derivative of the Fortify Runtime product, and can be applied to Java web servers or IIS .NET apps.
-- Habeas Data
Micro Focus Fortify Customers-Only Forums – https://community.softwaregrp.com/t5/Fortify/ct-p/fortify
What is the definition of 'Session' in the scan stats ? I selected manual scan. Did one login, and navigated to multiple pages. I clicked Finish and started the Audit. At the end of the scan/audit I see multiple sessions (e.g. 70+) sessions in the Scan Stats on the right. Does each session indicate a new login ? How does Web Inspect logout - as I didn't include that in the manual walk through, or does it just start with a new set of headers/cookies to start a new session.
Thanks in advance.
A session in WebInspect is a request and response pair - it's unrelated to logins or logouts.
WebInspect won't intentionally log out of your application - but many applications will push it out due to the attacks that are being performed at scan time. That's the purpose of the logout condition in the login macro - it allows WebInspect to recognize the logged out condition so that it can replay the macro to get back in before proceeding.
I am using WebInspect 17.10 and I use a login macro. It is locking out the account after 3 failed attempts. The same application instance is used to run our test suites and the related tests are failing due to the account lockout. I tried following the steps suggested here , but I still see the account being locked out.
Is there something I missed in the steps or are these not applicable with WI 17.10? Please suggest.