WhiteHat Security Sentinel Service

Transcription

1 WhiteHat Security Sentinel Service User Guide Version 3.0 September 2010

2 Contents Preface... 4 Intended audience...4 How to use this guide...4 Administrators...4 Security Operators...4 Developers...4 Viewers...5 Need help?...5 Resources...5 WhiteHat Security Customer Support...5 Getting Started... 6 Task overview...6 Logging in to Sentinel...7 Navigating in Sentinel...8 Creating and managing site groups...10 Setting up and managing user accounts...11 User roles Managing users Creating a new user Modifying a user s settings Deleting a user Editing your Sentinel account settings preferences Public Key API Web Key Managing Your Sites Interpreting site findings...19 Site Summary info boxes Hostnames and links Setting up your site credentials...20 F5 Web Application Firewall (WAF) Credentials Adjusting a site's priority level, scan speed, and industry...22 Managing Sentinel Scans WhiteHat Security IP Addresses...24 How long do scans take to complete?...24 Scheduling scans...25 Editing a scan Stopping a Scan Exporting scan schedules...27 Viewing recent scan activity...28 Scan status indicators If a site has not been scanned Managing Your Site Vulnerabilities What vulnerabilities does Sentinel scan for?...35

3 Viewing site vulnerabilities...37 Retesting site vulnerabilities...39 Generating Reports Creating a new vulnerability report...41 Using the Sentinel Open XML API Glossary Sentinel interface terms...45 Business logic vulnerabilities...48 Technical vulnerabilities...52 F5 Web Application Firewall (WAF) terms...57 General web application security terms...57

4 Preface Intended audience This guide shows assigned Administrators, Security Operators, Developers, and Viewers how to use WhiteHat Sentinel to find and fix vulnerabilities on their website. How to use this guide Depending on your assigned role, this guide helps you: Get in and around WhiteHat Sentinel Set up Sentinel user accounts Manage your sites and user site access Schedule scans and manage scan credentials Interpret scan reports Perform optional operations, such as managing your F5 WAF credentials and using the WhiteHat Sentinel open XML API Administrators If you are an assigned Administrator, you have full control of all of your Sentinel operations and this entire guide applies to your activities. Security Operators If you are a Security Operator, you may want to read: Getting Started: Logging in to Sentinel, Navigating Sentinel Editing your Sentinel account settings Developers Managing Your Sites Managing Sentinel Scans Managing Your Site Vulnerabilities Generating Reports Using the Sentinel Open XML API If you re a Developer, you may want to read: Getting Started: Logging in to Sentinel, Navigating Sentinel, Editing your Sentinel account settings Managing Your Site Vulnerabilities: Retesting site vulnerabilities Generating Reports page 4 of 58

5 Viewers If you re a Viewer, you may want to read: Getting Started: Logging in to Sentinel, Navigating Sentinel, Editing your Sentinel account settings Generating Reports Need help? Resources For more help, you can: Look up terms in the Glossary at the end of this user guide. Log in to your Sentinel account and click the Resources tab for a complete glossary, FAQs, white papers, API integration instructions, and other information about web security. Click the info buttons on each web page for help on certain topics. WhiteHat Security Customer Support To contact WhiteHat Security Customer Support: Go to the WhiteHat Support Portal: Send us at: [email protected] Call from 6:00 AM 7:00 PM Pacific Time, Monday through Friday (excluding holidays). WhiteHat Support Plus is available in three service levels the Standard Support level is free, and you can upgrade to Silver Support or Gold Support according to your needs. To see what level is best for you, go to: page 5 of 58

6 Getting Started Ensure scanning success in 3 steps! Who can do this? Administrator and Security Operator You have received your confirmation and created a password you re in! Right? Well, yes. But scanning doesn t start until you tell it to and let us in. There are three important steps you absolutely must take to get scans running on your sites. Be sure to: Log in to the Sentinel Interface. Configure your sites, including setting up credentials to allow us to scan. (Administrator only) Set up a scan schedule for each site to start and continue scanning. Task overview The basic steps for setting up and using WhiteHat Sentinel are: 1. Log in as a new user. This is initially done by the first assigned Administrator and by additional users as defined by their roles. 2. Manage your sites, including setting up credentials and site groups. (Administrator) 3. Set up user accounts. (Administrator) 4. Schedule and start scans. (Administrator and Security Operator) 5. Review vulnerabilities. (All users) 6. Generate reports. (All users) 7. Integrate our open XML API into your ticketing system. (Optional Administrators and Security Operators) 8. Manage F5 WAF credentials. (Optional Administrators and Security Operators) Getting Started takes you through steps one through four. page 6 of 58

7 Logging in to Sentinel Who can do this? All users, after the initial Administrator logs in and sets up user accounts (For browser requirements, from Resources, click the FAQ link.) Here is how to log in to Sentinel when your organization subscribes and assigns you as the initial Administrator or the Administrator has assigned you a user role. 1. You receive an from WhiteHat Security Support to establish access to your account. 2. Follow the link and instructions in the . Your username is the address the Administrator used in setting up your access. Note: This link is valid for 48 hours from the time the was sent. 3. To ensure username security, you receive a second with a URL to establish your password. 4. Follow the link and. enter your password information. Note: Your username and password are case sensitive. After set-up, here is how to log in: 1. Go to: 2. Enter your username and password. If you have problems logging in, check: Username and password. Both are case-sensitive in the Sentinel login screen. Spam filter settings. If you changed your password recently, make sure your spam filter settings in your account do not filter out the [email protected] address that sends the password confirmation . page 7 of 58

8 Navigating in Sentinel Who can do this? All users When you log in to Sentinel, you land on your Summary page. The options and menus on your page depend on your role. (For example, only Administrators see an Admin tab, and only Administrators and Security Operators see the scan schedule as a menu.) Summary Page page 8 of 58

9 Click a tab to take you to: Summary: An overview of your sites security. Findings: A list of all security problems Sentinel found in your sites. Schedule: A list of all scheduled events (such as scans). Reports: A place to input criteria for vulnerability reports. Account: Your Sentinel account information, including options. Admin: Editable user details such as roles and site accessibility. (Only Administrators can see this tab.) Resources: An API Reference, white papers, a glossary, and other help and industry references. The Pending Messages link, located next to the subject tabs and also under the Admin tab, takes you to the Account Messages page. Here you ll find info about the latest on releases and other general messages from WhiteHat Security, along with any alerts you may have about the status of your scans. page 9 of 58

10 Creating and managing site groups Who can do this? Administrators You can create site groups and manage user roles according to your organization s needs. Note: The Rename Group and Delete Group buttons appear when you select a group name. 1. Click the Admin tab. 2. Click Site Management. Grouping Sites 3. Below Site Groups, click Add New Group. A new entry is added to the Site Group list. 4. Name the site group. 5. Drag and drop sites from the All Sites list to the new group. The added sites appear below the group name. page 10 of 58

11 After you create a group name, you can: Add or remove sites to or from a site group: Drag the site name to or from the site group. Rename a site group: Select the group name and click Rename Group. Delete a site group: Select the group name and click Delete. Note: If an administrator deletes a site group, users no longer have access to that site group. Setting up and managing user accounts User roles Who can do this? Administrators The Administrator defines user roles with corresponding site access and privileges, as described below: Administrator (Admin) Security Operator Developer Viewer User Privileges Task Admin Security Operator Developer Viewer Manage users X Manage roles X Create site groups X Schedule/start scan X X Configure scan X X Retest vulnerabilities X X X Generate reports X X X X Schedule reports X X X X View vulnerabilities X X X X Set up F5 WAF credentials X X Set up open API XML X X Each service subscription can include multiple administrators. The highest privilege level within Sentinel is an administrator with All Sites access. Administrators who do not have access to all sites are limited to creating site groups and granting site access to sites that they administer. When your organization subscribes to Sentinel, WhiteHat Security creates an administrator with access to all sites, and that administrator can give all-site permissions to other administrators. Depending on your Sentinel set-up and organizational needs, access to all sites may not be required. page 11 of 58

12 Each user can have only one role and corresponding privileges to one or more sites. For example, if you are an Administrator, you have admin privileges for all sites you access; if you are a Viewer, you have Viewer privileges for all sites you access, and so on. Managing users You can add, edit, and remove the following user information from Admin > User Management. User (used as the username and is case sensitive) Title Phone number Cell phone number Time zone Country Vulnerability summary options Role (defines privilege level) Sites (that this user can access) page 12 of 58

13 Creating a new user To create a new user: 1. Click the Admin tab. Creating a New User 2. In the User List, click New. 3. In Add New User, enter the new user s information, including the role and site(s) the user can access under that role. page 13 of 58

14 The user s address must be unique. Once set up, an account address cannot be edited or reused. However, if the account is deleted, it can be reactivated by having the account main point of contact call WhiteHat Security Support. Select All, None, or one or more site name. To select more than one site: On a PC, press the Control key and select the site names. On a Mac, press the Command key and select the site names. 4. Click Create User. Modifying a user s settings You can modify any settings other than the user s address: 1. Click the Admin tab. 2. In the User List, click the username. 3. In User Details, enter the new information. 4. Click Save. Since the user s address is used as their username, to change the address, you need to delete the account and create a new one with the correct address: 1. Click the Admin tab. 2. In the User List, click the username. 3. Click Delete. 4. Follow the instructions for creating a new user, including re-establishing their roles and sites. Deleting a user Once deleted, a user cannot access Sentinel. If the user tries to log in and clicks the Forgot Username or Password? link on the log in screen, they are granted access to a WhiteHat Security demo account with no displayed websites. The administrator must create an account with a new address or contact White Hat Security Support to reestablish the previous account. To delete a user: 1. Log in to your Sentinel account. 2. Click the Admin tab. 3. In the User List, click the username. 4. Click Delete. page 14 of 58

15 Editing your Sentinel account settings Who can do this? All users From the Account tab, you can modify your account information, including: Contact information Time zone preferences Password Public key (Administrators and Security Operators only) Open XML API web key (Administrators and Security Operators only) To edit your account settings: 1. Log in to your Sentinel account. 2. Click the Account tab. 3. Modify your account information and click Save. If you re generating a Web API key, click Save and Generate Web API Key. You can use session cookies as an alternative to using a Web API key. For details, go to Resources > API Reference > API Cookie Authentication or go here: preferences In the Preferences field, choose how often you want to receive status summaries. Select Daily to receive summaries every day, including weekends. Select Weekly to receive summaries once a week. Public Key Select Monthly to receive summaries once a month. Select whether to include your host names in your summaries. (Deselect this option for added security.) In the Public Key field, you can create or edit a key that allows you to send a scheduled report via encrypted . If your mail server uses PGP (Pretty Good Privacy) keys to send secure data across unsecured networks, click Edit Key to paste or edit your PGP key. API Web Key Who can do this? Administrators and Security Operators If you are integrating the open XML API into your system, you need a Web API key to authenticate your API requests. Your key is generated automatically when you go to Account and click Save and Generate Web API Key. Never share your Web API key with anyone. This key could allow others to access your vulnerability information. Our support team will never ask for your Web API key. page 15 of 58

16 You can also validate API requests by presenting a valid authentication cookie in your API requests. Upon a successful login, the browser returns a cookie named APID. The APID cookie expires at the end of a session (upon logout). For more about using our open XML API, go to Resources > API Reference. page 16 of 58

17 Managing Your Sites Who can do this? Administrators Before scheduling your first vulnerability scan, review your account site information. Additional information may be required before Sentinel can scan your sites, such as a set of credentials to gain access to secure sites. You can set the scan schedule and time zone for all sites from Summary > Executive Summary > Site Overview. For individual site information and activity, from the Summary page, click the site name. This brings you to the Site Summary page, where you can view and adjust the site s summary, including site credentials, vulnerability findings, and site-specific activities. page 17 of 58

18 Site Summary Page page 18 of 58

19 Interpreting site findings Site Summary info boxes The boxes at the top of each site s summary page give you a quick overview of your site s completed scan number, priority, global rank, and industry rank. Scans completed in last 30 days: The number of scans that have finished in the preceding 30 days. Priority: The site s importance to your business, on a scale of 1 to 10. A change in priority affects the score of all vulnerabilities found on this site. Global rank: Indicates your site s approximate percentile rank against all sites that have been scanned at least twice. The percentage represents the percentage of sites that contain more vulnerabilities than your site. For example, if your site s global ranking is 20%, then 80% of all WhiteHat-scanned sites are more secure. Sites that have not yet been globally ranked are labeled Unranked. Industry rank: Indicates your site s approximate rank against all sites within your vertical market that have been scanned at least twice. Note: This box appears only if WhiteHat Security has scanned at least 10 sites in your industry more than once. To change the priority, scan speed, or industry rank: 1. From the Site Summary page, click the Settings link. 2. Adjust the settings. 3. Click Update. Hostnames and links The hostname is the base URL that we have under contract for a site. The scanner finds and tests only links that have the same base URL. This keeps scanning for your account to approved sites. For example, if a site has a hostname of only links that follow the structure are tested. (For example: and so on.) A site may also have one or more associated hostnames. An associated hostname is a URL that is different from the base URL, but is part of or the same as the application found on the main hostname. For example, a site may have sign-on and user account management pages on a URL such as secure.site.com, when the main hostname we have for the account is simply In this case, secure.site.com must be added as an associated hostname since it is considered to be part of the same account. To create an associated host name, contact WhiteHat Security Support. As your website continues to add features and functions, when you create links from the original site, the scanner finds them and marks them for testing during the next scheduled scan. All findings from this testing are reported in the next scan. For this and other reasons, we strongly recommend that you set scan schedules to run frequently and until completion. This ensures ongoing site coverage as you add new web code. page 19 of 58

20 Setting up your site credentials WhiteHat Security uses credential sets to log in to your sites and reach pages and forms that are not accessible to unauthenticated end users. Credential sets include: Username Password Login Entrance URL Destination URL (after a successful login) Other Login Notes (information about this site or users that WhiteHat Threat Research Center (TRC) engineers will need when setting up scanning or doing business logic testing) There are two uses for the credential sets: Scanning Credentials (all users). WhiteHat's automated scanning technology covers pages and forms throughout the site. Scans are limited to only one credential, so we encourage you to provide a super user login that allows us to visit the entire site. Business Logic Credentials (Sentinel PE users only). WhiteHat s Threat Research Center (TRC) engineers use these credentials to manually verify vulnerabilities, examine interactions among user roles, and see if website information leaks from one user to another. For instance, your site may behave differently for admin users, returning customers, prospects, or high-value shoppers. Labeling each credential pair ( admin, gold-card-customer, and such) helps our TRC engineers match credentials to business situations. The number of credentials you enter and how they are used depends on whether you have a Sentinel BE, SE, or PE account. Credentials should allow maximum access (such as admin or super user) to the site functions. Credentials are optional, but provide better scan coverage than having no credential. We strongly recommend assigning credentials. Sentinel Basic Edition (BE) account users enter one credential. This is used for automated scanning. Sentinel Standard Edition (SE) account users can enter one or two credentials, both used for automated scanning. The second credential is recommended as back up in case the first credential isn t accepted during scanning. Sentinel Premium Edition (PE) account users can enter one or more credentials. The first is used for automated scanning; the second is recommended as back up in case the first credential isn t accepted. Subsequent credential sets are used by WhiteHat s TRC engineers to perform Business Logic analysis. To create site credentials, follow these steps after logging in: 1. Click the Summary tab. 2. From Site Overview, select the site. 3. In the Site Summary page, click the Credentials link. page 20 of 58

21 Entering Credentials 4. Enter a Username and Password. 5. In the Login Entrance URL field, enter the URL where the scanner will enter these credentials. 6. In the Destination URL field, enter the URL that displays after a successful login, if applicable. (Not all websites change the URL as part of their authentication methodology.) 7. (Optional) In the Other Login Notes field, enter information to distinguish this account from others that have varying levels of access to the web application. (Examples: You need to have cookies turned on or Site asks for your pet s name. Answer: Lassie. ) 8. Click Done, or click Add a Credential if you have more than one credential for the scanner to use. You can now enter the second half of the pair, with a different username and password but similar permissions. PE users can also assign roles and credential pairs for Business Logic testing. page 21 of 58

22 Site Credentials (Example) After you have set up credentials, the Credential page includes the following state information: Valid means we have confirmed that these credentials work. Under Review means we have not yet tested these credentials or put them to work in automated scans. Invalid means we have had trouble logging into your site, or otherwise cannot get the login to work. The last user to change/edit information, and when changes were made. F5 Web Application Firewall (WAF) Credentials Who can do this? Administrator, Security Operator WhiteHat Sentinel integrates with the F5 Application Security Manager (ASM), a web application firewall that applies a security policy to protect against website attacks. Sentinel users can update their F5 ASM security policy on a per-vulnerability basis from within the Sentinel interface, which mitigates the risk of website exploitation while the vulnerability is addressed with an application code or system update. To add or modify F5 WAF credentials, go to Account > Manage F5 Credentials link. To add a new F5 ASM device and proper credentials, click the New credential link. To modify credentials, from the Actions column, click Edit. Adjusting a site's priority level, scan speed, and industry You can specify your site s priority level, scanning frequency, and the industry to which your site belongs. To edit your site settings: 1. Log in to your Sentinel account. 2. From Summary > Executive Summary > Site Overview, click the site name. page 22 of 58

23 3. Click the Settings link. 4. In the Priority field, select a level from 1 (Low) to 10 (Urgent). Level 5 is the default for all sites added to Sentinel. Note: Changing this number also affects the Score of all individual vulnerabilities discovered on this site. 5. In the Scan Speed field, select whether you want the scanner to send: Slow: Up to two HTTP requests per second Medium: Up to four requests per second (default) Fast: Unlimited requests per second 6. In the Industry field, select the closest match to your site's vertical market. 7. Click Update. page 23 of 58

24 Managing Sentinel Scans Who can do this? Administrators and Security Operators WhiteHat Security IP Addresses To enable us to scan your website, your security team may need our IP addresses: /27: This is a range of 30 addresses for Sentinel Service PE testing, disaster recovery ranges, and so on /30: This is a range of two addresses. These IP ranges are used for backup/disaster recovery: /28: This is a range of 14 addresses /28: This is a range of 14 addresses. How long do scans take to complete? WhiteHat Sentinel scans run "low and slow," meaning they should have no discernible effect on your website's performance. WhiteHat Security scans some of the most complex and mission critical websites in the world without causing performance issues. Scan time depends on various factors, such as: Size and complexity of the website Input number The number of pages to assess Web server speed (page load time) Amount of business logic within the website Length of scan windows provided by the customer Initial scans for the average WhiteHat-monitored site may take a day or less, but very large sites may take as long as a few weeks to complete. Note: Sentinel SE and PE users, keep in mind that findings appear in your interface after they have been verified by a TRC engineer. page 24 of 58

25 Scheduling scans For your first few scans, we recommend scheduling your scans to run during non-peak hours and continuously during the weekend. Once you have confirmed that there is no impact by scans during those time periods, we recommend running scans continuously, which means 24 hours a day, with a fresh scan starting as soon as the current one completes. Schedules take effect right away. If your schedule allows scanning in the current hour, it will start (or continue). It can take up to 10 minutes for scans to stop or start. You will see the current scan status (after you refresh your browser window) as it changes. If you turn off scanning in the current hour, it will start again the next time an allowable hour arrives. There are no options for fractional hour scheduling or setting scans to start on a future calendar date. For simplicity, we have included primary global time zones, but not every unique combination of time zone/savings time. Contact [email protected] to log an enhancement request for additional time zones. To schedule a scan: 1. Go to one of the following areas: Summary > Executive Summary Summary > Executive Summary > Site Overview <site name> Schedule 2. For the selected site, in the Scan Schedule column, select a schedule. Continuous: Enables scanning at all times. This is the recommended option. Nights and Weekends, 8P-6A: Enables scanning between 8:00 PM and 6:00 AM during weekdays and continuously during weekends. Be sure you select a corresponding time zone to determine exactly when 8:00 PM is in that geography. The time zone option defaults to the time zone you picked for yourself on the Account tab, but can also be set for each site from the Time Zone column to the right of the Scan Schedule column. Not Scheduled/Stopped: When you first set up your sites, they are set to Not scheduled/stopped. Be sure to schedule regular scans for each site, so WhiteHat Sentinel can continue to monitor for any threats. Customize: You can create your own custom scan schedule, as follows. When you select Customize, you can either create a schedule (recommended) or run the scan once. Schedule scanning time A grid shows all of the hours in a week. The rows represent days (starting with Sunday) and the columns represent hours (starting with 0:00-0:59, or Midnight to 1:00 AM). page 25 of 58

26 Customizing Scan Times By default, all hours show a green check mark, specifying that scanning is permitted during that hour. If you leave all cells with green check marks, this is the same as a continuous scan. You can click individual cells, changing them to red X's. Red X's signify that scanning is not permitted during that hour. To change multiple cells, you can: Click and drag your mouse around the interface. Click a row or column header to change an entire row/column. Click a second time to toggle between green check marks and red X s. The time zone selected should match where your system is or the clock to which your hours refer. The default is the time you chose in your user profile on the Account page. For example: You work in New York and the time zone under the Account tab is set for Americas/New York. Your web server is in Americas/Los Angles. If you leave the setting defaulted to New York, the scan will run/not run in Eastern Standard Time. If you change it to Los Angeles, the scan will run/not run in Pacific Standard Time, regardless of your default setting. Name the scan schedule something meaningful, such as NYSE non-trading hours. page 26 of 58

27 Once you create a schedule, it appears on the list as long as one or more sites are using it. Custom schedules created for one site can be re-used for additional sites. Editing a scan To edit an established scan: 1. From the Scan Schedule list, select Customize. 2. Edit the schedule as necessary. 3. Save the schedule under the previous name or give it a new name. Scanning only once Note: We recommend against scanning once without an ongoing schedule, since this leaves your site unprotected after that single scan completes. When you select this option, all hourly/daily scheduling windows are disabled. The scan starts immediately and runs continuously until it completes, for one time only. To run one scan, from Scan Schedule > Customize, click Run scan once continuously until completion. Stopping a Scan To disable all scanning for a site, or stop a running scan, select Not scheduled/ Stopped. You cannot pause and restart a scan while it is running. A status of Not scheduled/stopped leaves your site unprotected, so we do not recommend leaving sites in this state. You may get frequent reminders that this site needs a new scan schedule. Exporting scan schedules For a comma-separated values (CSV) file with schedule information for all of your sites: 1. Click the Schedule or Summary tab. 2. Below the Site Overview, click the Download CSV link. Download CSV Link By default, the file is named scheduled_scans.csv. This file may show more than one row for each site, since it lists each contiguous block of hours that the scan will run. For instance, each nightly scan window may have its own entry. page 27 of 58

28 Viewing recent scan activity As described below, you can view the following scan activity details for all of your sites or each site individually: Vulnerability scan started indicates a newly scheduled scan cycle has begun. Vulnerability scan completed indicates the total scan cycle has finished. Vulnerability scan paused, end of scan period reached appears only for scans that run during limited hours, and indicates the scheduled time duration has reached its limit for the day. For instance, a scan scheduled to run from midnight to 6 a.m. pauses at 6 a.m. It automatically resumes during the next window of time in your scan schedule (such as midnight in the above example). Vulnerability scan paused by WhiteHat Security means that the WhiteHat Security TRC team paused the scheduled scan. Vulnerability scan resuming is also used for limited-hour scans, and indicates the scheduled time in which the paused scan picked up where it left off. All sites WhiteHat Sentinel tracks all activities and events related to your account. To view a list of activities for all sites on your account in the last 90 days: 1. Click the Summary tab. 2. Click the Recent Activities link. 3. View your list of activities, listed by date. For a full archive, click the see complete history link. Individual sites To view activities for individual sites: 1. From the Summary page, click the name of the site. 2. From the Site Summary page, either: Click the Activities link. You see the site's scan activity over the past 90 days. To view all activity, click see complete history. Scroll to the bottom of the page to view the site's 10 most recent activities. To view the 90-day history, click the show all... see complete history link. From there, to view the complete archive, click see complete history. Tested URLs and additional hostnames Sentinel discovered 1. Go to Summary > [site name]. 2. On the site summary page, in the box next to the last chart (the site name is at the top of the list), scroll down to the Link Info section. 3. To see if a particular part of your site has been tested, click View all links found in your current scan or View all pages tested in your current scan. If the section of the site you are concerned with appears in any of these URL lists, it has been tested. page 28 of 58

29 Scan status indicators Sometimes issues come up that can prevent WhiteHat Security from effectively accessing and scanning a site, and may require action by you to resolve. For each of your site(s), the Summary and Site Summary pages indicate scan status to let you know if scans are running and if you need to take action. Problems are reported by priority, with more urgent/important items showing above less urgent/important items. The Urgent icon indicates a condition that prevents successful scans, potentially preventing the site from being fully assessed. You need to address urgent items immediately. The Warning icon provides a warning or advance notice about an issue. If it requires action, address warning items at your earliest convenience. The OK icon indicates that scanning is working and you do not need to take action. In Summary > Site Overview, scan status is displayed in the last column. Scan Status on the Summary Page If there is more than one alert for a site, only the highest priority item is shown. If the site has more than one issue, clearing the highest priority item may reveal another issue. (To see all of them at once, click the site name to go to the Site Summary page.) To address the issue, click the status description next to the icon. This takes you to a page that describes the issue and how to address it. page 29 of 58

30 Some corrective actions can only be performed by specific Sentinel user roles. If you do not have the corresponding role, only the required action is displayed. Contact a Sentinel Administrator to provide you with the appropriate role or for completion of the requested action. The Site Summary page shows a list of all scan status alerts for that site. If, for instance, there are three scan status issues, all three are shown, with links to relevant details. Scan Status on the Site Summary Page page 30 of 58

31 The following table lists all current possible status indicators. Scan status indicators may change over time. Contact if you need information about a scan status indicator. Scan Status Indicators Icon Status Description Site Disabled Need Credentials Invalid Credentials Need Scan Schedule Contract Expired BE Link Limit Exceeded Contract Expiring in X Days Configuration in Progress Reviewing Credentials Scan Running Paused Per Schedule Situation/Problem WhiteHat has stopped all scanning as specified by your account Administrator. You need to provide one set of credentials for a BE account and at least one and preferably two for SE and PE accounts.* The site has an SE or PE service level, and none of the provided credentials are working.** This site has no scans scheduled. The service contract for this site has expired, and is not set for auto-renewal. Service may be terminated at any time. The BE service has an upper limit on the number of pages and links it covers. This site needs more coverage than BE provides. The service contract for this site is expiring soon, and is not set for auto-renewal. Our TRC engineers are setting up login handlers, configuring scans, or otherwise changing scan details. TRC is verifying that credentials work. This site is currently being scanned. This site's schedule identifies the current hour/day as outside the selected scanning period. Scanning will resume based Action Required Urgent: If you have not requested that this site be disabled, contact [email protected] and request that scans be resumed. Urgent: Click the Need Credentials label and enter the credential information. Urgent: Click the Need Credentials label and ensure that the credential input is correct. Urgent: In the Scan Schedule column, pull down the menu and select a schedule. Urgent: Contact Customer Support to renew your contract and/or arrange for autorenewal. Warning: Talk with Customer Support about upgrading to SE or PE so that the entire site can be protected. Warning: Contact Customer Support to extend the contract. Warning: Wait for TRC to complete its tasks. Contact Customer Support for additional information. OK: No action required. OK: No action required. OK: No action required. page 31 of 58

32 Icon Status Description Scan Scheduled Scanning (no credentials) Situation/Problem on the schedule. This site has a scan scheduled for a future time. The Administrator has set this site to be scanned without any credentials, or unauthenticated. Only external pages/forms will be tested.* Action Required OK: No action required. OK: No action required unless you want to re-enable authenticated scans. If so, click Scanning (no credentials), deselect Do not need credentials, and enter valid credentials. *Selecting Do not need credentials disables all scan status warnings about missing credentials, while scans run unauthenticated (without credentials). We strongly discourage enabling unauthenticated scans, since that may leave sites unprotected from attacks on internal forms and pages. **A site with many credentials may have some marked as Invalid or Not working. You may receive alerts or action items elsewhere in Sentinel and in support s to request that you fix these credentials. You only see an Urgent status if every credential for that site is invalid. page 32 of 58

33 Here is an example of time/event activities as reported by scan status alerts. Sample Time/Event Sequence Reported by Scan Status Alerts Time/Event Icon Status Description Current Action 1 Scan Running This site is currently being scanned. 2 Configuration in Progress While the scan was running, it notified TRC of needed configurations. TRC is making these changes, 3 Scan Running Configuration completed. This site is currently being scanned. 4 Paused Per Schedule This site's schedule identifies the current hour/day is outside the selected scanning period. Scanning will resume based on the schedule. 5 Scan Running This site came out of the blackout period 6 Need Scan Schedule and resumed being scanned. The scan from Time/Event 5 above was a one-time scan and has finished. There is no scan scheduled after that. 7 Scan Scheduled A reoccurring scan schedule was provided and it is waiting for the next scan time slot to occur. 8 Invalid Credentials The scheduled scan started and the scanner found the provided site credentials have changes and are no longer allowing login. 9 Reviewing Credentials The customer has updated the site credentials and TRC is verifying that credentials work. 10 Scan Running Credentials were validated and the site is currently being scanned. 11 Scan Scheduled Due to the action in Time/Event 7 the scanner has finished the scan and is waiting for the next scan time slot to occur to start a new scan. Scan status alerts and action items If you need to take action on a scan issue, you may see this along with other tasks in Pending Messages > Action Items. Some Urgent scan status issues do not generate action items. For instance, sites with no credentials will show an Urgent alert labeled Need Credentials, even though no action items have been generated. Also, some action items are not reflected in scan status. For instance, if a site has many credentials, some Valid and others Invalid, this does not force an Urgent alert, since scans are still running based on valid credentials. page 33 of 58

34 Action items are still created, requesting that you update/replace those credentials that are not working. If a site has not been scanned If you see that a site has not been scanned in a while: The site may have been scheduled for a one-time, immediate scan, which does not repeat. Click the Pending Messages link (next to the navigation tabs on each page) and scroll down to Action Items for actions that must be taken for a scan to run, such as credentials that need updating or a scan with no schedule. page 34 of 58

35 Managing Your Site Vulnerabilities As Sentinel identifies vulnerabilities, it classifies them according to the 24 Web Application Security Consortium (WASC) vulnerability classes such as Cross-Site Scripting, Directory Traversal, and SQL Injection. Each class is assigned a Threat and Severity level, represented by info boxes at various data sections of the Sentinel interface. For Sentinel SE and Sentinel PE accounts, Threat Research Center (TRC) engineers verify all vulnerabilities before they reach your Sentinel interface, which ensures that you do not see false positives. Note: Vulnerability verification is performed during normal business hours in Pacific Standard Time (PST). So it is possible to run a scan at night and not see vulnerabilities reported until the next business day during PST. What vulnerabilities does Sentinel scan for? Sentinel scans for vulnerabilities based on your subscription level. (See the Glossary for vulnerability definitions.) All subscriptions levels scan for the following vulnerabilities. Command Execution Buffer Overflow Format String Attack LDAP Injection OS Commanding SQL Injection SSI Injection XPath Injection Information Disclosure Directory Indexing Information Leakage Path Traversal Predictable Resource Location Client-Side Content Spoofing Cross-site Scripting (XSS) HTTP Response Splitting page 35 of 58

36 Sentinel PE also scans for the following business logic flaws: Authentication Brute Force Insufficient Authentication Weak Password Recovery Validation Cross-Site Request Forgery Authorization Credential/Session Prediction Insufficient Authorization Insufficient Session Expiration Session Fixation Logical Attacks Abuse of Functionality Denial of Service Insufficient Anti-automation Insufficient Process Validation page 36 of 58

37 Viewing site vulnerabilities Who can do this? All users To view all of your site vulnerabilities at once, click the Findings tab. The Findings page contains a list of vulnerabilities and their details. Alternatively: To see the most recently identified vulnerabilities for all your sites, go to Summary > Executive Summary > Vulnerability Overview > Recently Identified Vulnerabilities. To see the most recently identified vulnerabilities for a specific site, go to Summary > Executive Summary > Site Overview > [site name] > Scan Statistics > Recently Identified Vulnerabilities. Click the icon in the Details column to see the Vulnerability Viewer page. Findings Page page 37 of 58

38 Vulnerability Viewer The Vulnerability Viewer includes the following information: The vulnerability as defined by the WASC class (example: Cross-Site Scripting). The vulnerability s Severity, Threat, Priority, and Score. A retest button enabling you to run a retest or request a manual retest (based on the nature of the vulnerability). A link to ask a question about this vulnerability. (Questions are generally answered within 24 hours.) The VulnID (the unique number assigned to the vulnerability). The vulnerability URI (in the Located in field). The Site name. The date and time it was opened (identified), and the duration it has been open. The current status (open or closed). A list of open and closed attack vectors according to the parameter sent in the HTTP request. (Click the Details icon for the complete record of the request and response that indicated the presence of this vulnerability). A description of this class of vulnerability, along with a solution or remediation recommendations and references. Any applicable Web Application Firewall (WAF) policy settings. page 38 of 58

39 Retesting site vulnerabilities Who can do this? Administrators, Security Operators, and Developers To retest a vulnerability, follow these steps from the Vulnerability Viewer page. Below the info boxes, click the retest button. Depending on the vulnerability, it will be labeled in one of two ways: Request Manual Retest means that only manual retesting can be performed on this specific vulnerability. Click this button to send a request to the TRC team. The status of the vulnerability changes to Manual Retest Pending until the retest is finished. Retest Now means that the vulnerability is eligible for automatic retest. The retest begins immediately. To retest more than one vulnerability, follow these steps from the Findings tab: 1. In the Retest column, select the vulnerabilities to retest. 2. At the bottom of the table, click Retest Vulnerabilities. page 39 of 58

40 Generating Reports Who can do this? All users You can create customized vulnerability reports for one or more of your sites in HTML or PDF (and schedule the PDF to be ed periodically). Sentinel reports include levels of information based on report type. (The HTML web report is available only as a Vulnerabilities Details Report.) The Executive Summary Report provides executive management with an illustrated overview of the security risk profile of their organization's sites. It contains a summary of vulnerability totals across multiple sites broken up by risk levels and vulnerability categories. The Site Summary Report provides management with a comprehensive, illustrated view of the specific security risk exposure of individual sites under their responsibility. It has an overview of each site's vulnerabilities by category, the trends of vulnerabilities discovered by month over the past year, and each site's vulnerability findings prioritized by their risk and severity level, and the priority level of the site. You can filter this report by site. The Vulnerability Detail Report provides security team members and development managers with a detailed listing of the vulnerabilities found on their organization's websites. It groups the findings by category for each website selected for the report. Each chapter contains a description of the vulnerability class with remediation instructions, followed by a list of specific instances of the vulnerability on each site. You can filter this report by site, class, date range, and current state. You can add an Attack Vector list to each vulnerability detail. The Attack Vector Detail Report provides security team members and developers with a detailed list of all instances of vulnerabilities found on their organization's sites. It details every vulnerability instance found on selected sites. You can filter this report by site, class, date range, and current state. You can add a response body to each vulnerability detail so that your developers can easily replicate the problem. The PCI Report measures a website's compliance with the Payment Card Industry's Data Security Standard (PCI-DSS). The PCI standard ensures that sites are built to the secure coding guidelines of the OWASP Top Ten Vulnerability Classes and are routinely checked for vulnerabilities. You can filter this report by site. You can add the Attack Vector list. page 40 of 58

41 Creating a new vulnerability report To create a vulnerability report: 1. Click the Reports tab. 2. Click either PDF Reports or Web Reports. The Web Report form creates a Vulnerability Detail report. The PDF Reports page offers all report formats. page 41 of 58

42 PDF Report Form page 42 of 58

43 3. For PDF, from the Options field, select the report type. 4. Select the site(s) you want to see, or select All Sites. To select site names in the list: On a PC, press Shift and click the site names; on a Mac, press Command and the click the site names. The rest of your options depend on the report type and your account level. Some of the options include: Vulnerability Class. You can select one or more Vulnerability Class, or select All Classes. (See Types of site vulnerability scans to see which scans are covered for your account level and the Glossary for report type definitions.) Start and End dates. The start date should be early enough to include the actual discovery date of the vulnerability (vulnerabilities discovered prior to that date range are not included in the report). By default, reports are set to include only vulnerabilities opened in the last seven days. To report a full list of vulnerabilities, open a new browser tab, log in to Sentinel, and click Findings > Opened Date. In the report form, click Filter by Date and enter a date that is equal to or one day before the oldest date. To find your oldest closed vulnerabilities, in the separate browser tab, go to Findings > Closed Date. In the report form, click Filter by Date and enter a date that is equal to or one day before the oldest date. Open/closed/both. Choose whether to report vulnerabilities that are still open, closed, or both. We recommend choosing both to indicate progress in remediating vulnerabilities over a period of time. Delivery options. Choose how this report should be delivered. If you are in the Web Reports view, you will automatically receive an HTML view of the report when you click Generate Report. If you are in the PDF Reports view, select Show report immediately or Schedule a delivery time. You will need a public key (PGP) to enable Sentinel to periodically a PDF report. If you have not done so, go to the Account tab and generate a public key. page 43 of 58

44 Using the Sentinel Open XML API Who can do this? Administrators and Security Operators The Sentinel open XML API is a set of functions that support HTTP requests, allowing your developers to work directly with your own Sentinel vulnerability data. Vulnerability, site, and schedule information, retrieved in XML format, can be integrated into your developer defect tracking systems or security information management systems (SIMS). For instructions on using the open XML API: 1. Click the Resources tab. 2. Click the API Reference link. Or, from outside Sentinel, go to: and log in. 3. Follow the instructions on the page. page 44 of 58

45 Glossary Sentinel interface terms Attack Vector A test consisting of HTTP requests and responses that indicate the presence of a vulnerability. Because injection-based attacks usually target specific parameter injection points, attack vectors for vulnerabilities such as Cross-Site Scripting (XSS) and SQL Injection are grouped by each vulnerable parameter. All open attack vectors must be resolved in order to close a vulnerability. The same attack vectors will be re-sent during a retest. If the vulnerability can no longer be found, the attack vectors (and thus the vulnerability) will be closed. Should future scans reveal new or re-opened attack vectors, the closed vulnerability may be re-opened. Global Rank A percentile rank indicating your site's approximate rank against all sites that have been scanned at least twice. The percent shown in the box represents the percentage of sites that contain more vulnerabilities than your site. For example, if your Global Rank is 20%, then 80% of all scanned sites are more secure. Sites that have not yet been globally ranked are labeled Unranked. Hostname An identifying domain name assigned to a host computer, usually a combination of the host's local name with its parent domain's name. Industry Rank A percentile rank indicating your site's approximate rank against all sites within your vertical market that have been scanned at least twice. Priority On a scale of 1 to 10, a customer-determined level of value or importance of a site. Priority is initially set to the default level of 5, but can be modified from Site Summary > Settings. A change in Priority additively affects the Score of all vulnerabilities found in this site. page 45 of 58

46 Severity The potential business impact if a specific vulnerability is exploited. The levels of severity are based on the same conditions factored into the PCI Security Scan report ratings, but the definitions below are clarified for Web application security concerns. Level 5 - Urgent Attacker can assume remote root or remote administrator roles Exposes entire host to attacker; backend database, personally identifiable records, credit card data Full read and Write access, remote execution of commands Example Business Vulnerability: Insufficient Authorization Example Technical Vulnerability: Format String Attack, SQL Injection, Directory/Path Traversal Level 4 - Critical Attacker can assume remote user only, not root or admin Exposes internal IP addresses, source code Partial file-system access (full read access without full write access) Example Business Vulnerability: Insufficient Authentication, Session Fixation, Abuse of Functionality, Credential/Session Prediction, Insufficient Authentication, Cross-Site Request Forgery (CSRF) Example Technical Vulnerability: Cross-Site Scripting (XSS), Server Side Include (SSI) Injection, OS Command Injection Level 3 - High Exposes security settings, software distributions and versions, database names Example Business Vulnerability: Weak Password Recovery Validation, Denial of Service, Insufficient Process Validation, Brute Force Example Technical Vulnerability: Information Leakage, Content Spoofing, Predictable Resource Location, LDAP Injection, Directory Indexing, HTTP Response Splitting Level 2 - Medium Exposes precise versions of applications Sensitive configuration information may be used to research potential attacks against host Example Business Vulnerability: Insufficient Session Expiration, Insufficient Anti-automation Example Technical Vulnerability: XPath Injection Level 1 - Low General information may be exposed to attackers, such as developer comments Example Technical Vulnerability: Buffer Overflow page 46 of 58

47 Threat A measure of feasibility in which a specific Vulnerability can be exploited. Criteria can include the skill level required of the attacker, the context of the attack surface, the transience of the vulnerable code, and the dependencies for access to the vulnerability. Threat level is one of the factors used to calculate the Score of a vulnerability. The higher the threat level, the greater the ease of exploitation for the vulnerability. Threat levels of some vulnerability classes are subject to change on a case-by-case basis. Level 5 - Urgent Very low time, resources, and skill levels are needed for execution Easily exploitable Can be accidentally triggered by unsuspecting, non-technical user Authentication may not be required Details of past exploits and demonstrations are widely available Extensive educational materials have been published about this vulnerability class Large, almost universal attack surface with many entry points Level 4 - Critical Little time and few resources are needed for execution Some background knowledge may be required for execution Remotely exploitable Authentication, if required by the Web application, is easily defeated Details of past exploits somewhat available Level 3 - High Tools to automate the attack are available, but require some background knowledge A moderate amount of time and resources are required Proofs-of-concept and a few real-world exploits have occurred, but details may not be known Level 2 - Medium At least one proof-of-concept has been demonstrated, but there are no records of real world attacks Considerable technical skill is required Attack vector is moderately transient and conditional Attack vector is moderately deep in the code Level 1 - Low Attack method is obscure, brand-new, or strictly a theory Distributed systems knowledge (or insider status) required for execution Origin of attack is typically local A month or more of time is required to design and launch attack page 47 of 58

48 Authentication is required Attack vector is highly transient, conditional, and located deep in the code Extremely narrow attack surface Score The sum total of the Threat and Severity levels of an identified vulnerability, plus the Priority of the site. Scores range from 3 to 20. For example, a Cross-Site Scripting vulnerability with a Severity level of 5 and a Threat level of 5 on a Priority 10 site results in a Score of 20. Priority is initially set to the default level of 5. If you increase the Priority for a site that has been scanned, the Score for any vulnerability found on that site automatically updates. Threat and Severity levels have default levels that can be overridden by WhiteHat Security on a case-by-case basis. Each vulnerability's Score is indicated in the Vulnerability Summary and Findings pages. Site Credentials A username and password a customer provides in order for scanners to perform tests as a logged-in user. This feature is required if your site requires user accounts. We recommend creating two accounts for each access level (two users, two administrators, and so on), pre-populated with example test data, to ensure a thorough scan. In the Site Credentials page, you can enter the credentials of multiple accounts to represent different roles, such as users and administrators, to test various permission and access levels. The Site Credentials page indicates whether existing credentials, if any, have been used for testing. In some cases, separate "sites" are created for each credential set. You can add, change, or delete the credentials for a given site by selecting the site in the Executive Summary page, and then clicking the Site Credentials link. Vulnerability An instance of weakness in a Web application that can result in harm to the Web application, its operations, or its end users, especially when exploited by a malicious individual or script. VulnID (Vulnerability Identification) A unique identifier of a specific vulnerability in your account. Business logic vulnerabilities Abuse of Functionality An attack that uses a website's own features and functionality to consume, defraud, or circumvent access control mechanisms. Some functions including security features may be abused to cause unexpected behavior, annoy other users, or perhaps defraud the system entirely. Abuse of Functionality techniques are often intertwined with other categories of Web application attacks, such as performing an encoding attack to introduce a query string page 48 of 58

49 that turns a web search function into a remote web proxy. Abuse of Functionality attacks are also commonly used as a force multiplier. For example, an attacker can inject a Cross-Site Scripting snippet into a web-chat session, then use the built-in broadcast function to propagate the malicious code site-wide. Brute Force An automated process of trial and error used to guess a person's username, password, credit-card number or cryptographic key. Many systems will allow the use of weak passwords or small cryptographic keys. An attacker can cycle though the dictionary word by word, generating thousands or potentially millions of incorrect guesses searching for the valid password. There are two types of brute force attacks: normal brute force and reverse brute force. A normal brute force attack uses a single username against many passwords. A reverse brute force attack uses many usernames against one password. In systems with millions of user accounts, the odds of multiple users having the same password dramatically increases. Insufficient Anti-automation Insufficient Anti-automation can happen when a website permits an attacker to automate a process that should only be performed manually. Certain website functionalities should be protected against automated attacks. Left unchecked, automated robots or attackers could repeatedly exercise website functionality attempting to exploit or defraud the system. An automated robot could potentially execute thousands of requests a minute, causing potential loss of performance or service. Insufficient Authentication Insufficient Authentication can happen if a website permits an attacker to access sensitive content or functionality without having to properly authenticate. Web-based administration tools are a good example of websites providing access to sensitive functionality. Depending on the specific online resource, these Web applications should not be directly accessible without the user required to properly verify their identity. To get around setting up authentication, some resources are protected by "hiding" the specific location and not linking the location into the main website or other public places. However, this approach is nothing more than Security Through Obscurity. It is important to understand that simply because a resource is unknown to an attacker, it still remains accessible directly through a specific URL. The specific URL could be discovered through a Brute Force probing for common file and directory locations (/admin for example), error messages, referrer logs, or perhaps documented in Help files. These resources, whether they are content or functionality driven, should be adequately protected. Insufficient Authorization A vulnerability that permits access to sensitive content or functionality that should have increased access restrictions. Authorization procedures are performed after authentication, enforcing what a user, service or application is permitted to do. Thoughtful restrictions should govern particular page 49 of 58

50 website activity according to policy. Sensitive portions of a website may need to be restricted to everyone except to an administrator. Insufficient Process Validation A vulnerability that permits an attacker to bypass or circumvent the intended flow control of a Web application. If the user state through a process is not verified and enforced, the website could be vulnerable to exploitation or fraud. When a user performs a certain website function, the Web application may expect the user to navigate through a specific order sequence. If the user performs certain steps incorrectly or out of order, a data integrity error occurs. Examples of multi-step processes include wire transfer, password recovery, purchase checkout, account signup, and so on. These processes will likely require certain steps to be performed as expected. For multi-step processes to function properly, websites are required to maintain user state as the user traverses the process flow. Websites will normally track a user s state through the use of cookies or hidden HTML form fields. However, when tracking is stored on the client side within the Web browser, the integrity of the data must be verified, otherwise an attacker may circumvent the expected traffic flow by altering the current state. Insufficient Session Expiration A vulnerability that enables an attacker to reuse old session credentials or session IDs for authorization. Insufficient Session Expiration increases a website's exposure to attacks that steal or impersonate other users. Since HTTP is a stateless protocol, websites commonly use session IDs to uniquely identify a user from request to request. Consequently, each session ID's confidentiality must be maintained in order to prevent multiple users from accessing the same account. A stolen session ID can be used to view another user's account or perform a fraudulent transaction. Weak Password Recovery Validation A vulnerability that permits an attacker to illegally obtain, change or recover another user's password. Conventional website authentication methods require users to select and remember a password or passphrase. The user should be the only person that knows the password and it must be remembered precisely. As time passes, a user's ability to remember a password fades. The matter is further complicated when the average user visits 20 sites requiring them to supply a password. Thus, Password Recovery is an important part in servicing online users. Examples of automated password recovery processes include requiring the user to answer a "secret question" defined as part of the user registration process. This question can either be selected from a list of canned questions or supplied by the user. Another mechanism in use is having the user provide a "hint" during registration that will help the user remember his password. Other mechanisms require the user to provide several pieces of personal data such as their social security number, home address, zip code etc. to validate their identity. After the user has proven who they are, the recovery system will display or them a new password. page 50 of 58

51 Credential/Session Prediction A method of hijacking or impersonating a website user. Deducing or guessing the unique value that identifies a particular session or user accomplishes the attack. Also known as Session Hijacking, the consequences could allow attackers the ability to issue website requests with the compromised user's privileges. Many websites are designed to authenticate and track a user when communication is first established. To do this, users must prove their identity to the website, typically by supplying a username/password (credentials) combination. Rather than passing these confidential credentials back and forth with each transaction, websites will generate a unique "session ID" to identify the user session as authenticated. Subsequent communication between the user and the website is tagged with the session ID as "proof" of the authenticated session. If an attacker is able predict or guess the session ID of another user, fraudulent activity is possible. Cross-Site Request Forgery (CSRF) An attack that tricks the victim into loading a page that contains a malicious request. The request inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server, but can also be used to access sensitive data. For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, or Windows domain credentials. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish a CSRF attack from a legitimate user request. The attacker can then make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website. Denial of Service (DoS) An attack with the intent of preventing a website from serving normal user activity. DoS attacks, normally applied to the network layer, are also possible at the Web application layer. These malicious attacks succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality. DoS attacks attempt to consume all of a website's available system resources such as CPU, memory, or disk space, to render the website inaccessible. As modern Web application environments include a Web server, database server and an authentication server, DoS at the Web application layer may target each of these independent components. Unlike DoS at the network layer, where a large number of connection attempts are required, DoS at the Web application layer is a much simpler task to perform. Session Fixation An attack that forces a user's session ID to an explicit value. Techniques to "fix" the session ID value range from Cross-Site Scripting (XSS) exploits to peppering the website with previously made HTTP requests. After a user's session ID has been fixed, the attacker will wait for the user to login, upon which the attacker uses the predefined session ID value to assume their online identity. page 51 of 58

52 There are two types of session management systems: "permissive" systems that allow Web browsers to specify any ID, and "strict" systems that only accept server-side generated values. With permissive systems, arbitrary session IDs are maintained without contact with the website. Strict systems require the attacker to maintain the "trapsession", with periodic website contact, preventing inactivity timeouts. Technical vulnerabilities Directory/Path Traversal An attack that forces access to files, directories, and commands that potentially reside outside the Web document root directory. An attacker may manipulate a URL in such a way that the website will execute or reveal the contents of arbitrary files anywhere on the Web server. Any device that exposes an HTTP-based interface is potentially vulnerable to Path Traversal. Most websites restrict user access to a specific portion of the file-system, typically called the "web document root" or "CGI root" directory. These directories contain the files intended for user access and the executables necessary to drive Web application functionality. To access files or execute commands anywhere on the file-system, Path Traversal attacks will utilize the ability of special-characters sequences. Format String Attack Format String Attacks alter the flow of a Web application by using string-formatting library features to access other memory space. Vulnerabilities occur when user-supplied data are used directly as formatting string input for certain C/C++ functions (e.g. fprintf, printf, sprintf, setproctitle, syslog,... ). If an attacker passes a format string consisting of printf conversion characters (for example: "%f", "%p", "%n", and so on.) as parameter value to the web application, they may: Execute arbitrary code on the server Read values off the stack Cause segmentation faults / software crashes HTTP Response Splitting A technique allowing the attacker to send a single HTTP request that forces the Web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response, in the normal case. The first response may be partially controlled by the attacker, but this is less important. What is material is that the attacker completely controls the form of the second response from the HTTP status line to the last byte of the HTTP response body. Once this is possible, the attacker realizes the attack by sending two requests through the target. The first one invokes two responses from the Web server, and the second request would typically be to some "innocent" resource on the Web server. However, the second request would be matched by the target to the second HTTP response, which is fully controlled by the attacker. The attacker tricks the target into believing that a particular resource on the Web server (designated by the second request) is the server's HTTP page 52 of 58

53 response (server content), while it is in fact data forged by the attacker through the Web server in the second response. LDAP Injection An attack used to exploit websites that construct LDAP statements from user-supplied input. Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both querying and manipulating X.500 directory services. The LDAP protocol runs over Internet transport protocols such as TCP. Web applications may use user-supplied input to create custom LDAP statements for dynamic Web page requests. When a Web application fails to properly sanitize user-supplied input, an attacker can alter the construction of an LDAP statement so that the process will run with the same permissions as the component that executed the command. This can cause serious security problems where the permissions grant the rights to query, modify or remove anything inside the LDAP tree. OS Command Injection When a Web application does not properly sanitize user-supplied input before using it within application code, an attacker can trick the Web application into executing Operating System commands. The executed commands will run with the same permissions of the component that executed the command such as the database server, Web application server, or Web server. Predictable Resource Location An attack used to uncover hidden website content and functionality. By making educated guesses, the attack is a brute force search for content not intended for public viewing such as temporary files, backup files, configuration files, and sample files. Hidden files will often have common naming conventions and reside in standard locations which may disclose sensitive information about Web application internals, database information, passwords, machine names, file paths to other sensitive areas, or possibly contain vulnerabilities. Disclosure of this information is valuable to an attacker. Cross-Site Scripting (XSS) An attack that forces a website to echo attacker-supplied executable code, which loads in a user's browser. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology. When an attacker gets a user's browser to execute his code, the code will run within the security context (or zone) of the hosting website. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-Site Scripted user may have his account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the website they are visiting. There are two types of Cross-Site Scripting attacks: non-persistent and persistent. Non-persistent attacks require a user to visit a specially crafted link laced with malicious code. Upon visiting the link, the code embedded in the URL will be echoed and executed within the user's Web browser. page 53 of 58

54 Persistent attacks occur when the malicious code is submitted to a website where it is stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to click on any link, just simply view the web page containing the code. Buffer Overflow An attack that alters the flow of a Web application by overwriting parts of memory, resulting in an error condition. This error condition occurs when data written to memory exceed the allocated size of the buffer. As the buffer is overflowed, adjacent memory addresses are overwritten causing the software to fail. When unrestricted, properly crafted input can be used to overflow the buffer resulting in a number of security issues. A Buffer Overflow can be used as a Denial of Service attack when memory is corrupted. Even more critical is the ability of a Buffer Overflow attack to alter application flow and force unintended actions, such as overwriting stack pointers and redirecting the program to execute malicious instructions, or to change program variables. Since the attacker must exploit custom code on a remote system, they would have to perform the attack blind, making success very difficult. Directory Indexing A vulnerability present when a Web server function that lists all of the files within a requested directory if the normal base file (index.html/home.html/default.htm) is not present. When a user requests the main page of a website, they normally type in a URL such as - using the domain name and excluding a specific file (/index.html). The Web server processes this request and searches the document root directory for the default file name and sends this page to the client. If this page is not present, the Web server will issue a directory listing and send the output to the client. From an attack and countermeasure perspective, unintended directory listings may be possible due to software vulnerabilities combined with a specific web request. When a Web server reveals a directory's contents, the listing could contain information not intended for public viewing. Often web administrators rely on "Security Through Obscurity" assuming that if there are no hyperlinks to these documents, they will not be found, or no one will look for them. The assumption is incorrect. Today's vulnerability scanners can dynamically add additional directories/files to include in their scan based upon data obtained in initial probes. By reviewing the /robots.txt file and/or viewing directory indexing contents, the vulnerability scanner can now interrogate the Web server further with these new data. Although potentially harmless, Directory Indexing could allow an information leak that enables further attacks against the system. Content Spoofing An attack used to trick a user into believing that certain content appearing on a website is legitimate and not from an external source. This attack exploits the trust relationship established between the user and the website. The technique has been used to create fake web pages including login forms, defacements, false press releases, and so on. page 54 of 58

55 Specially crafted links can be sent to a user via , instant messages, left on bulletin board postings, or forced upon users by a Cross-Site Scripting attack. If an attacker gets a user to visit a web page designated by their malicious URL, the user will believe he is viewing authentic content from one location since the browser location bar displays a legitimate-appearing URL, when in fact the underlying HTML frame is referencing attack data. Information Leakage A vulnerability present when a website reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system. Sensitive information may be present within HTML comments, error messages, source code, or simply left in plain sight. While leakage does not necessarily represent a breach in security, it does give an attacker useful guidance for future exploitation. In the first case of information leakage (comments left in the code, verbose error messages, etc.), the leak may give intelligence to the attacker with contextual information of directory structure, SQL query structure, and the names of key processes used by the website. Often a developer will leave comments in the HTML and script code to help facilitate in debugging or integration. This information can range from simple comments detailing how the script works, to, in the worst cases, usernames and passwords used during the testing phase of development. Information Leakage also applies to data deemed confidential, which aren't properly protected by the website. This data may include account numbers, user identifiers (Drivers license number, Passport number, Social Security Numbers, and so on) and user-specific data (account balances, address, and transaction history). Insufficient Authentication, Insufficient Authorization, and secure transport encryption also deal with protecting and enforcing proper controls over access to data. SQL Injection A very severe attack used to exploit websites that construct SQL statements from usersupplied input to steal information from a database and/or to gain access to an organization's host computers through the computer that is hosting the database. Structured Query Language (SQL) is a specialized programming language for sending queries to databases. However, many database products supporting SQL do so with proprietary extensions to the standard language. Web applications may use usersupplied input to create custom SQL statements for dynamic web page requests. SQL injection attacks are used to steal information from a database from which the data would normally not be available and/or to gain access to an organization's host computers through the computer that is hosting the database. SQL Injection attacks may be prevented by enforcing the use of parameterized statements. Server Side Include (SSI) Injection A server-side technique that allows an attacker to send code into a Web application, to be executed locally by the Web server. SSI Injection exploits a Web application's failure to sanitize user-supplied data before they are inserted into a server-side interpreted HTML file. page 55 of 58

56 Before serving an HTML web page, a Web server may parse and execute Server-side Include statements. In message boards, guest books, or content management systems, a Web application will insert user-supplied data into the source of a web page. An SSI is a variable value such as a Last modified date that a server can place in an HTML file. Before sending the file to the requestor, the server searches the file for CGI environment variables and inserts the appropriate values in the places where "include" statements appear. In SSI injection, the variable values are modified to allow the attacker to add, alter or delete HTML files on the server, or to gain access to server resources. page 56 of 58

57 XPath Injection An attack used to exploit websites that construct XPath queries from user-supplied input. XPath 1.0 is a language used to query an XML document, or as part of a larger operation such as applying an XSLT transformation to an XML document, or applying an XQuery to an XML document. If an application embeds unprotected data into an XPath query, the query can be altered so that it is no longer parsed in the manner originally intended. This can be done by bypassing the website authentication system and extracting the structure of one or more XML documents in the site. This attack may be prevented by parameterizing XPath queries. F5 Web Application Firewall (WAF) terms Application Security Manager (ASM) A web application firewall from F5 Networks that integrates with WhiteHat Security Sentinel's vulnerability management service. Sentinel users can update the security policy on a per-vulnerability basis to mitigate the risk of its exploitation while the vulnerability is being addressed in the Web application code. IP Address A unique address assigned to a networked device, including computers, and servers. Password A secret sequence of characters that is paired with a username to gain access to an online system. Username and password combinations are also known as credentials. Policy A set of rules employed by a Web application firewall that detect and block attempts to exploit a vulnerability in a Web application. All HTTP requests are assessed for strings that contain vulnerable parameters. Policy rules need to be maintained periodically. Username A name that uniquely identifies a user or role; required (along with a password) to authorize access your F5 Application Security Manager (ASM). Username and password combinations are also known as credentials. Web Application Firewall A device or software module that applies a set of policy rules to incoming traffic to block potential attacks on a Web application. Also known as a WAF. General web application security terms Authentication The process of verifying identity, ownership, and/or authorization. Backdoor Malicious code inserted into a program for the purposes of providing the author covert access to machines running the program. page 57 of 58

58 Base 64 A method for encoding binary data into printable ASCII strings. Every byte of output maps to six bits of input (minus possible padding bytes). Blacklist When performing Input validation, the set of items that if matched result in the input being considered invalid. If no invalid items are found, the result is valid. Input Validation The act of determining that data input to a program is sound. Padding Data added to a message that is not part of the message. For example, some block cipher modes require messages to be padded to a length that is evenly divisible by the block length of the cipher i.e., the number of bytes that the cipher processes at once. Root User A user with unlimited access to all operations on a computer. Read Access The ability to view the names of files in a directory, but not any other information such as file type, size, and so on.) Whitelist When performing input validation, the set of items that, if matched, results in the input being accepted as valid. If there is no match to the whitelist, then the input is considered invalid. That is, a whitelist uses a default deny policy. Write access The ability to create, delete, change permissions, or rename files. page 58 of 58

59 WhiteHat Security Customer Support If you have any questions regarding the use of these features, please contact WhiteHat Customer Support via the support portal or send an to or call from 6:00 AM 7:00 PM PT Monday thru Friday. About WhiteHat Security, Inc. Headquartered in Santa Clara, California, WhiteHat Security is a leading provider of website vulnerability management services. WhiteHat delivers turnkey solutions that enable companies to secure valuable customer data, comply with industry standards and maintain brand integrity. WhiteHat Sentinel, the company s flagship service, is the only solution that incorporates expert analysis and industry-leading technology to provide unparalleled coverage to protect critical data from attacks. For more information about WhiteHat Security, please visit WhiteHat Security, Inc Bunker Hill Lane, Suite 220 Santa Clara, CA Copyright 2010 WhiteHat Security, Inc. Product names or brands used in this publication are for identification purposes only and may be trademarks or brands of their respective companies.