Your Website Got an F in Security

ACM.296 Let’s look at that F and what it actually means — when it matters and when it does not

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Security | Secure Code | Application Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I’m finally done with some other work and getting back to my series on deploying a static website. In the last post I wrote about how to add a policy to your ECR registry so it can be used with a Lambda function.

Before I continue with that I need to jump to another topic which came up recently. Are you getting a “penetration test” which is not really a penetration test but actually a “vulnerability scan”?

I’m going to demonstrate using my own website, which has a few issues I know about and plan to fix in this series — but I would consider them low risk and I’ll explain why.

That said — as I just mentioned — I will fix them. Why would you leave any risk on your website if you don’t have to? In my case, I hadn’t updated my website since 2020 because I was so busy.

But now I’m making the time because I’m writing this series and I’m upgrading some of my penetration testing tools I use on AWS in the process. So let’s get this done. Follow along in the series if you want to see how I do it, what matters, and why or why not.

I set up my website in like 5 minutes so I could start my business since my lawyer said a website was required. Since then I have barely looked at it. I finally updated it recently after a few years when AWS made me an AWS Security Hero but I purposely did not fix some “known issues” so I could write about them — and to consider the relevance of some scan findings and the risk associated with those issues to my particular site.

I’m going to try to “hack my own website” in a future post or possibly new series and show you the implications of some of the things.

But let me start with the fact that if you have malware on your machine performing a man-in-the-middle (MITM) attack (which is essentially what a tool I use called Burp does to help me test websites) then you have much bigger problems than anything below related to my website. That’s similar to what happened in a recent LastPass breach. There are also different points of attack for MITM attacks.

If someone opens Burp to show you they can deface a website — they can do that to any website they visit. They have essentially hacked themself. They are only showing you something useful if they can explain how an attack can be used against someone else, not only themselves using Burp or ZAP (Zed Attack Proxy).

Your Website Gets an F! Does it matter?

Years ago, I was in a class and someone said, “Your website gets an F in security?!”

I laughed. “Yes. Yes it does. What do all those findings in that F rating mean? What can you do with those findings on my website?”

The question that a penetration tester has to figure out when they get a whole bunch of findings is — which findings actually matter and what is the risk associated with those findings?

Of course, I could run Burp, intercept my own traffic, and show you lots of scary things. Anyone can do that. With any site. That’s not demonstrating anything. That’s what I do every time I test a website as a penetration tester. I essentially capture the traffic and change it on the way to the web server to try to find a way to break into the server or demonstrate an attack against someone who visits that website.

A vulnerability finding alone is not enough to demonstrate risk. If a penetration tester is handing you a report with a bunch of scary findings and not explaining how those findings could affect you or your website, then I would suggest that person is not actually a penetration tester. They are performing what is called a vulnerability scan.

A penetration test goes further to explain each finding, demonstrate how to reproduce it, and accurately explain the impact. In some cases, I find a vulnerability I can’t exploit but I explain how a customer can figure out if the vulnerability can affect them — even without demonstrating an actual exploit. In other cases, I can demonstrate the impact of a finding as I did in this presentation at RSA 2020. See my demo at the end where I used a cross-site scripting flaw in an AWS API to obtain a valid token to make unauthorized calls to that API.

I am thinking about creating a new penetration testing series and demonstrating some attacks like attacking my own website and other sample sites to see what’s possible. But let’s start by looking at some basic web scans and evaluate which findings matter and which findings do not for my particular website without even attempting the actual attacks.

Reviewing the findings for a static website

I’ve been writing about how to deploy a static website for a while now and considering more than just throwing some HTML pages in an S3 bucket. There are many, many other considerations when you get down to it. I’ve had this post in my list to write forever and finally getting around to it because it is relevant to the work I’m doing now with my website and finally have the time.

Of all the things that matter for the security of my static website, the website scanners are the least of my concerns. I’ll explain why in this post. Yes, there are some considerations that matter, which I will attempt to demonstrate in some upcoming posts. But the ability to attack a website because a security header is missing depends on whether the website uses the functionality that security header protects against.

So if anyone tried to scare you with the grade on a website but did not evaluate and explain if and how those findings matter, then you might want to reconsider that person’s expertise and advice.

Penetration testing is more than scanning

This is where penetration testers need to be more than website scanners. They need to understand the issues that exist on a website and the impact of those issues. And that’s why I left this as is for a while. Hopefully, I did not lose business because someone scanned my F-rated site and decided I didn’t know anything about security as a result in the meantime. That’s part of why I am writing this post. Yes, I know. Some security headers are missing. What’s the impact?

Just to be clear, I’m going to focus specifically on the issues found in some online security scanners in this post. I’m talking about a security vulnerability in that list of findings that decided my website should get an F in security, not something in the larger infrastructure I don’t control or other types of misconfigurations found in infrastructure scans. I want to demonstrate and fix some of those issues later.

Let’s look specifically at why my website is getting an “F” and consider the risk associated with those findings.

Do not scan sites without permission

Now what I am about to do is something you probably should *NOT* do with your company website without explicit permission. Why? If there is a vulnerability on your site, what is the company that hosts the page where you ran the scan going to do with it? Are you sure that company is trustworthy? Would you be able to immediately get any findings fixed that may arise now that someone else knows they are present?

I’m going to show you an alternate mechanism for testing for these problems that does not involve exposing your website to an online third-party scanner in the future hopefully (in a separate series I’m planning.) I don’t use most public scanners that store my customer data in them when testing websites. I do use a few trusted sites for public facing content but ensure I change the settings to not expose the data on that site.

And as always, I have no affiliation with the sites I’m going to use below nor have I tested them out for security problems so use them at your own risk.

ImmuniWeb.com

The first site I tried out was ImmuniWeb.

Apparently my grade upgraded to a C+ and pretty much nothing has changed about my website other than some of the content (the text on the pages.) I’m not sure this is the site used to scan my site last time — that was years ago.

But let’s dig into this.

EU GDPR? I don’t store any European data. I don’t even use cookies (CSRF attacks, etc.). N/A.

PCI? I don’t process credit cards. N/A.

Content Security Policy (CSP)? I do not have a CSP on my website. What does a CSP do?

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.

My website does not use any JavaScript. I do not accept any user input by way of forms where a user can enter data and reflect it back onto the website. I do not process any user input that might come from URLs or HTTP headers that someone might try to insert into the page.

I’ve been trying to think of a way someone could abuse a site like that without a CSP specifically by attacking the things a CSP protects against. The risk seems incredibly low and the attack options are few, if any. I’ll write more about CSPs later.

That said, if you process any user input — you should have a CSP on your site. Do it now. I’ll also tell you about some other options you can use to completely eliminate certain categories of attacks in a future post.

Security Headers? What do they protect against? Let’s check out another site for that.

SecurityHeaders.com

Here’s a site where I can look more at security headers.

Oh look. I get an F for security headers here but the other site says no major issues found. Interesting.

HTTP Strict-Transport-Security — I should fix this. But this missing header is generally listed as a low priority finding as it requires a man-in-the-middle attack to take advantage of it. HSTS prevents connecting to a website with HTTP (an unencrypted channel).

My site does have a TLS certificate configured (not SSL, which has been deprecated, for anyone still using that outdated term). You can visit my website via HTTPS, which encrypts data in transit.

Could you visit my website without HTTPS? Possibly. Someone could catch the website at the one point where the user makes the initial HTTP request before the redirect to HTTPS. At that point anything that is possible with HTTP only is possible with my website — if those attacks apply to my website.

However, most modern browsers generally redirect you to HTTPS if it is available (like Google Chrome). If you head to my website at http://2ndSightLab.com you will be automatically redirected to https://2ndSightLab.com. This minimizes the risk. However, I just tried to go to my website via HTTP in Safari and HTTP is blocked on this particular test network. The browser could not connect, meaning Safari does not currently have that protection.

You can also redirect users to HTTPS using AWS CloudFront, but that would be a server side redirect, too late if the attack is client side and the user is redirected before the request ever makes it to the server.

I’ll do a deeper dive on the HSTS header later. Let’s just say that tools like SSLStrip can try to attack a website that lacks HSTS for now.

By the way, if you don’t have an TLS certificate for HTTPS on your website, you should. Troy Hunt has a good post on that topic here.

I would like to call out, as you watch this video, that it’s a good idea to understand the difference between hacking yourself with a proxy on your own laptop like Burp and what someone would need to do to get a MITM on another device and intercept your traffic that way. Thats what I was mentioning about hacking yourself versus hacking someone else. A penetration tester needs to understand the difference.

Also, the penetration tester needs an understanding of whether an attack applies to the website in question specifically or all websites in a particular scenario is useful. If only my website, someone could potentially redirect a user. If all websites, they attacker is generally going to be going after more lucrative objectives like stealing credentials, which is not applicable to my website.

If you are trying to create a static website with an SSL certificate I’m working through how to do that on AWS here with a fully automated deployment pipeline and code stored in GitHub.

As mentioned, I’ll cover HSTS a bit more in a future post as this comes up often on penetration tests.

Content Security Policy (CSP) —This should be very low risk or possibly even N/A as noted already. But I will show you how to add a CSP in a future post and we’ll look at some of the attack vectors.

X-Frame-Options — This would be good to add to prevent clickjacking. But is it possible? And what is the actual risk? No better way to show you than to demonstrate in a future post whether this is possible or not and the implications.

X-Content-Type-Options — All my CSS is embedded into HTML pages. There’s no dynamic content and no JavaScript, forms, or downloads. There’s really nothing to inject that will cause a browser to think this content is something other than it is. MITM attacks and clickjacking are separate issues. I am going with N/A on this one at the moment but reserve the right to change my mind as new research comes to light. Also, I want to demonstrate something that might work even better than nosniff in a future post.

Referrer Policy — I don’t have any sensitive information on this site to be included in the referrals to other websites.

Permissions Policy — which features and APIs can be used in the browser. Let’s look at what this guards against:

The HTTP Permissions-Policy header provides a mechanism to allow and deny the use of browser features in a document or within any me> elements in the document.

I don’t have anything but static content on my site. No JavaScript, etc. However, someone could put my site in an iframe. Would the content in that iframe be able to do anything to my website? I’ll save that for another post. I already mentioned HSTS and that one point at which the content can be served up via HTTP. It would get redirected to HTTPS by modern browsers and server side but perhaps there’s some low risk. A topic for another day. The risk in most cases is low.

Observatory.Mozilla.Org

Here’s another scanner from Mozilla:

As noted, most of what’s in a CSP is not applicable to my site.

HSTS is an issue I’ll explore further later as mentioned already.

X-Frame options — Perhaps clickjacking may be possible but it would be hard to pull off and there’s not much you can do with it on my site besides redirect a user or a slim chance that the missing HSTS tag could affect someone.

I’ve covered all of the above except X-XSS-Protection. It’s interesting that Mozilla lists this here when it has the following on another page on their website:

So give me back that +10 for X-XSS-Protection because it is irrelevant according to Mozilla.

So in general, most of these security headers and findings that give my site an “F” do not yield much in the way of a possible useful attack. In many cases, to carry out the attack requires another larger initial attack to obtain a MITM — in which case you likely have much bigger problems. Perhaps someone could get you to click on a phishing link. Make sure you are at this web URL to avoid that problem:

https://2ndsightlab.com

That said, I might as well add all the headers to give my site a stellar grade, and I’m the type of person to say — if there’s a risk and it’s easy enough to fix, why not fix it? Why leave the door open for any opportunity when that is not necessary? Also someone might use one of those scans inappropriately to try to scare other people who don’t know the difference.

I’ve been very busy and my website has been an afterthought for quite some time, but I’ve wanted to get around to a faster way to deploy websites I use for penetration testing and fix a few other websites in the process. So I figured I should update my own website in the process and fix that “F” that might be misinterpreted by people who don’t understand the details that go into that grade. And I’ll show you how to fix your own website in the process.

Also note that new attacks are always coming to light. I could be missing something here as no one can know everything in cybersecurity. I continue to research and try to find new attacks on websites myself on a daily basis that I can use in my penetration tests and assessments. I plan to do a deep dive into a few of the issues listed above in future posts so stay tuned if you are interested because I’m always trying to find better ways to explain the risks and attacks to customers. I did a deep dive for IANS Research, for example, on DOM XSS and explained how you can pretty much eliminate that risk. If you are an IANS client you can ask your client services representative to provide the link to the video or research report.

If someone is trying to scare you with a scan, make sure they understand the implications of that scan and can explain in detail what those findings mean and why they matter. On the flip side, don’t assume that findings don’t matter and there’s no need to fix them because they are “low risk.” Low risk findings can add up and especially if you are serving up dynamic content or forms that accept user input. Chaining a number of low risk vulnerabilities together can lead to a high priority problem.

The next post covers MITM attacks and how they relate to HSTS among other things.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab