At Havoc Shield, our Web Vulnerability Scan capability is especially popular amongst the portion of our client base that self-identifies as B2B SaaS. We're still at a scale where we know every customer by first name and are able to ask for candid feedback about what cybersecurity concerns led them to our doorstep, so this article is a roundup of what we're hearing from our B2B SaaS clients about what they find so essential about completing a web vulnerability scan with us.
B2B SaaS companies are notorious for having subdomains set up for various experiments, staging environments, 3rd party tools, etc. There is nothing wrong with the practice of setting up a variety of subdomains for special purposes, and in fact it's a great way to help your team (and maybe even your customers) compartmentalize certain feature sets or use cases that are isolated in nature.
However, a web vulnerability scan that only operates on the domain apex (e.g. example.com) misses the point, if you've also got a pile of subdomains such as app.example.com, help.example.com, staging.example.com, etc. For that reason, many of our clients ask for us to include subdomain discovery in our scan, to help with enumerating experiments, sub-projects, and environments that may otherwise be forgotten.
At the risk of stepping into a hornet's nest of a debate amongst DevOps professionals, suffice it to say that there is a school of thought that fervently believes that port 23 is open, it's a bug. There are similar debates about many other commonly-used ports, but playing out the port 23 example a little further, it's crucial that software development teams have a stance on which ports should and shouldn't be open on their production systems. It is not a "given" that something as simple as an SSH port should be open.
Perhaps you have sufficient log aggregation for investigation of production failures, and perhaps you treat production system's local storage as ephemeral. If that's the case, you may have concluded that there is no justifiable reason that one of your team members should need to be able to SSH into a production host. If that's the case, you'd want to make sure that you've got that port (and other ones that you have strong feelings about) closed. And a web vulnerability scan is your 2nd line of defense behind making intentional configuration changes in your infrastructure to close the ports that you believe should be closed.
You don't want to do this type of test manually. It's too labor intensive and repetitive. Suppose your website is at example.com, and that there is an authentication-required page called https://example.com/v3/accounts. Want to take bets on whether there is an old/forgotten variant of that same page, at https://example.com/v2/accounts -- and care to double-down on that bet, with a perspective on whether that v2 version has some age-old security vulnerabilities, long forgotten after removing it from mainstream use?
Hold off on that bet. Just use our URL fuzzer instead. Especially if you are a B2B SaaS company where your platform revisions move so quickly that it's easy to forget about legacy code/pages that accidentally remain exposed. We include this in almost every web vulnerability scan -- it's proven it's mettle through the findings that it has brought forth for many of our clients.
Your sign-in page that transitions users from your public-facing website to your secure web portal is (obviously!) one of the most essential pages in your cyber perimeter. Remember what it was like when you first set up that page, and registered your first few test accounts? What are the odds that there might be early accounts that were just quick/rushed tests that use a "dictionary word" as their password? Most B2B SaaS companies are at a pretty hectic era when they are first setting up their website, and it's not hard at all to imagine that there might be some readily obvious username/password pairs that could be guessed by an outsider. Maybe better to let a web vulnerability scan find these, before an attacker does?
This is an "oldie but a goodie" -- and there are an increasing number of B2B SaaS websites with dependencies so intricate that I'd say there are many people who think their site doesn't have any SQL datastore, when in reality there may very well be some subtle dependency. For example on a website that uses DynamoDB as it's datastore, but uses various intermediate libraries to access it: whose to say that one of those intermediate libraries didn't switch to using the SQL query style that eventually became available on DynamoDB? Some SQL injection testing should add comfort in any web vulnerability scan. It's especially crucial if you know that you have SQL dependencies, but is an easy "win" even if you aren't sure.
It's cipher suite quiz time! Which combinations of Key Exchange, Bulk Encryption, and Message Authentication does your site allow? If you need a cheat sheet to remember some of the possibilities, here you go:
Key Exchange RSA, Diffie-Hellman, ECDH, SRP, PSK Authentication RSA, DSA, ECDSA Bulk Encryption CiphersRC4, 3DES, AES Message AuthenticationHMAC-SHA256, HMAC-SHA1, HMAC-MD5
So, what combinations of these cipher suite elements does your site allow, and are the allowed combinations still considered secure in light of the latest exploits? Not sure? You aren't alone. Few if any of our clients could recite the cipher suite configurations they've chosen and the security implications that caused them to disallow other combinations. This is where a web vulnerability scan shines: it's a way to gain confidence that you've chosen reasonable cipher suites that do not have known vulnerabilities.
Ready to be frightened? In the past few months we've helped numerous companies realize (and fix) open directory listings. Yes, you heard that right. Cases where any person with a web browser could potentially browse to a particular URL and see the list of internal source code files that exist in a particular folder on a particular website. Dependencies, libraries, configuration files, etc. That's not something you normally want to be sharing "with the world" and a web vulnerability scan is a quick way to double-check that you haven't accidentally made a configuration change that exposes some commonly-known path or folder. It's especially common for B2B SaaS companies to host a marketing site on Wordpress with clickthroughs to sign into a secure web portal hosted on some other stack -- and for companies in that situation there is some comfort to take in the fact that your deepest secrets might not be in a Wordpress directory. But maybe a key/secret that you use for sending authenticated emails (e.g. newsletter signup confirmations) is. Maybe your payment/subscription API key is. Maybe your licensing configuration file for a dependency is.
For this section we're going to use Wordpress as an example. Not because Server / Dependency Version Scanning is specific to Wordpress (it's not), but because Wordpress sites almost always use a variety of plugins that make this scan especially eventful. This part of a web vulnerability scan interrogates web servers and pages in a way that tries to get them to reveal versioning information. For example, what Apache version you are using. What Wordpress version you are using. What version of each and every Wordpress extension you are using. Bad news: with that information, combined with publicly-disclosed release notes from many of those vendors, a hacker has a straightforward path to exploiting vulnerabilities that (although they may be fixed in the latest version) are wide open in the version of the dependency that you have installed. No good. Better to know precisely what versions of "everything" you've got in use.
In the dependency scanning section, we talked about the risks of using a known-vulnerable version of a web server (or other dependency). No we'll make this more "real" for you. For this example, we'll assume that you are using the Apache web server. Here are the 1,753 Apache vulnerabilities that you could potentially be up against, according to the CVE database (What is a CVE?).
Why do we tie together web server / dependency version information with entries from the CVE database? Because it's one of the very best ways to demonstrate exactly what vulnerability exists and to allow you to evaluate (with our advice if you like) what risks the vulnerability brings to your particular site.
HTTP security headers are tough to keep up with. There are ever-evolving practices involving headers such as X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and many more. For these and other headers, our web vulnerability scan critiques the headers you have (and the headers you don't have) and supplies you with an explanation of precisely what header changes you should consider and why you should consider them. This is relevant both on public-facing websites and on secure web portals (e.g. the signed-in portion of a B2B SaaS site). A combination of missteps could, for example, allow an attacker to obtain the "session cookie" of a signed-in user -- and then do who-knows-what with the direct/unfettered access to the secure portal when signed in as that user. Many security header vulnerabilities are used in combination with other vulnerabilities, to achieve exploits such as that one.
Security headers are a perfect use for a web vulnerability scan that would be excruciatingly difficult to complete manually. Take the shortcut: get a scan, review the results, and take action.
These days, there is little justification for operating on the faith that your webserver doesn't have any readily discoverable vulnerabilities. You know that hackers have access to the same types of web vulnerability scans that the "good guys" have. You know that hackers scan websites in bulk and then use the output to decide which vulnerable sites are the most interesting to choose to attack. Lastly, you know that you have readily available means to pre-emptively scan your site, and fix the defects, dramatically reducing your risk. Why wouldn't you? We'd love to help.