What is a website? :: Updated 09.03.09

  1. A Website is any number of hostnames:
    1. that can be reached by logging in with a single username/password. Or,
    2. that don’t require a login
  If you log in at... and can see... but are required to log in again at...
  sentinel.whitehatsec.com

 www.whitehatsec.com

 console.whitehatsec.com
  Site 1
(login with demo/demo)		 Site 1 (requires
no login)		 Site 2 (requires separate login)

When we say “hostname,” we really mean “fully qualified domain name,” or FQDN. For example, given a device with a local hostname myhost and a parent domain name ex

ample.com, the fully qualified domain name is myhost.example.com. The FQDN uniquely identifies the device: While there may be many hosts in the world called myhost, there can only be one myhost.example.com.

Here’s how to identify unique hostnames in urls:

https://www.example.com – unique
http://www.example.com – same hostname as above
http://www.example.edu – unique
http://login.example.edu – unique
http://images.login.example.edu – unique

How to Sell a Website

Let the customer come to you and propose how many websites they have.  With the above rule, we’re flexible.  If the customer would identify the three FQDNs (in the example above) as three different sites - all the better. 

Your default answer to whatever the customer proposes should be “Yes, we can do that;” and, if needed, “but...”

The above rule will work 90% of the time.  Individually scoping websites actually costs WhiteHat Security more time and money, and leads to the customer thinking we are arbitrarily nit-picking what a website is.  If the site definition doesn’t feel right, look at the five exception templates below to see if any of those fit better.

How are Multiple Users / Roles Handled?

Under WhiteHat Sentinel PE, multiple users/roles are tested manually.  The scanning is done entirely with one username/password.  If the customer wants multiple user levels tested in a repeatable, automated fashion, they’ll have to purchase that as a separate “site” or “slot.”

The goal here is code coverage.  The customer wants to give WhiteHat Security one account with the most code coverage possible.  If there are multiple accounts (or roles) with completely different code coverage, it’s best if they pay for that as a separate site.  The noted exception is the “user/admin” template that is detailed below.

Exception Templates - and How to Sell Them

User and Admin

Historically we’ve sold www.example.com, testing both the user and admin roles, as just one website.  If you can access all the available functionality from the admin account, then we can assess it as one site.  If you need to log in as user and log in separately as admin to access all available functionality, then we can still sell it as one site. But, Sentinel will actually have two site entries:
            www.example.com ADMIN
            www.example.com USER

If there are more than two roles with access to unique functionality (e.g., client, broker, administrator), then any access levels beyond the first two chosen by the customer require purchasing an additional “slot.”

Production and QA

Many customers hesitate to pay for two websites when they see production and QA as the “same application.”  This is because to the customer, it’s the “same code.” 

Often, we find out the two environments aren’t the same, because:
            * Server configurations can result in significant differences, such as left over files/directories in production, developer notes, or source code remnants

    1. Code that was supposed to make it to production was never pushed
    2. Production has “real” data, so it might behave differently

Because we assess websites from a blackbox approach, we need to test these applications independently without making assumptions about how they behave compared to other environments. 

Still, you have two selling options for price sensitive customers:

    1. Offer PE in production and SE in QA (PE is preferred solution in prod because production has real data - essential for business logic testing)
    2. Give the customer PE in both production and QA, but a meaningful discount on one of the sites

Clones of the same site
Sometimes the customer uses the same code for multiple websites, e.g.:

    1. www.sports.com/boston-celtics
    2. www.sports.com/seattle-mariners
    3. www.sports.com/denver-broncos

Or even:
            * www.boston-celtics.sports.com

    1. www.seattle-mariners.sports.com
    2. www.denver-broncos.sports.com

If they meet the definition for separate websites (they each require a unique login), then we can accommodate the customer by offering PE on one of the sites (e.g., www.boston-celtics.sports.com), and SE on all the others.  If the sites are truly the same, then whatever vulnerabilities we find on one should be found on the others.  This is especially true for business logic issues.  SE assessments on the other sites will find any differences in configuration or files left on one server but not the others.

If the “cloned” sites don’t require a login, you can also sell them as per the “Grouping Sites Together” section below.

Portals or extremely large sites
Portals are large, extremely complex applications that perform several different functions.  We can treat them as one website – with these caveats:

    1. Assessment scans will take a very long time to complete
    2. Vulnerabilities will be reported for the entire site as a whole. This makes sorting through the vulnerabilities and fine-tuning access for the developers difficult.
    3. Only one set of credentials can be used to scan the entire website

Many times portals (or extremely large websites) will have separate teams working on different pieces of an application.  To accommodate partitioning results and running faster scans, we can break the site up into pieces and scan/charge the customer for separate websites.

For example, www.ebay.com might be broken up into:

    1. my.ebay.com
    2. shopping.ebay.com
    3. forum.ebay.com

These three “sites” (even though they can be accessed with one login) can be scanned separately so that scans finish faster.  And developers working on shopping.ebay.com can have Sentinel accounts only granting access to that data - and not forum.ebay.com or my.ebay.com results.

Grouping Websites Together

With our permissive website definition (unlimited hostnames), customers might consider combining unrelated sites as a “single application.”  If you have a customer who wants to do this, be sure they realize:

  1. scans will take longer, the more hostnames that are included
  2. all the results will be grouped together, making it hard to sort through or
    partition results for developers
  3. only one set of credentials can be used to scan the entire site

The advantages in breaking up the sites into multiple slots include:

  • scanning with multiple creds
  • completing scans faster; and,
  • partitioning results in a way that makes sense for their separate development groups to consume. 

Pitch the purchase of multiple slots as “value added”, and worth their while for ease of use / faster results.




Contact your WhiteHat Representataive | Contact the Webmaster