As more and more companies go digital, cybersecurity is forever going to be a concern to the world. Hackers are in every way doing all they can to ensure they compromise the integrity of your system. In the same manner, all hands must be on deck to ensure your organization or website is many steps ahead of them.
Over time, I have received questions from friends, colleagues, and readers on how best to secure a website from potential cyberattacks. The truth is that there are many answers to that question. But I’d rather focus on how to protect users from being victims of phishing attacks and data theft.
In this article, we’ll look at how to ensure your website’s users are protected at all times, especially if your site accepts credit card information. Just as it is with most of my articles, I’ll be taking a practical approach to this.
I’ll show you how a seemingly unprotected website isn’t protecting its users through relatively inexpensive cybersecurity steps. Our target website this time is AllTheThings.com. You may want to check out the website as you read on. If you want to build a more robust system, you’ll find this very useful.
What Is The Major Cyber Threat of Our Website?
The first thing in setting top security protocol is often to determine who you’re protecting your website against. Our target website, ATT, is currently under threat from a hacking group known simply as MGHC. But knowing their name is simply not enough, we need to understand MGHC’s tactics and attack strategies to mitigate them.
Putting 100% effort into securing everything, all the time, is not realistic. If we know MGHC’s “M.O.,” we can secure the most probable target(s) first. For example, are they creating spoof websites that prey on common misspellings of the domain (AllTheThing.com, AllTehThings.com, AllTheThings.co, AlTheThings.com)?
Are they scanning for open ports in the ATT (All The Things) ecosystem, trying to find access to the databases or holes in a web server? Are they phishing users with emails trying to get access to the system, with the plan of using SQL injection to elevate the rights for that compromised user to root?
If they are doing all this, can we detect the IP addresses they are using to do this? And if so, can we block traffic from these IPs? Are they calling into the help desk pretending to be an aggrieved customer, then seducing the customer service agents to reset a password over the phone?
Yes, it’s great to use strong cryptography and valid certificates, but if we lock the front door of the house with ten deadbolts but leave all the windows open, what is the point? Knowing their tactics and blocking them sends a message: “We know you are there, and we are ready to fight you.”
How To Implement Certificate Authority And Encryption
Now that we have limited the scope of the problem let’s talk about CA certs and encryption. The first step is to choose a Certificate Authority. After doing some research, we chose “Let’s Encrypt.” They are “new-ish” on the scene and have innovative ways of handling the issuing and managing certificates that seem promising.
Let’s Encrypt provides X.509 certificates for TLS encryption for free. The certificate is valid for only 90 days but can be renewed at any time. They also offer site owners an automated process of overcoming the manual creation, validation, signing, installation, and renewal of certificates for secure websites.
I like this strategy to certificate validation. It forces the admins to renew in a timely fashion, and the automation reduces the chance that human error will create a vulnerability. To use Let’s Encrypt, we set up a server to run the ACME client as a bot (like CertBot) that handles the challenge-response needed to validate site ownership and the creation of the site’s keys.
One added feature in Let’s Encrypt framework that I am very excited about is their promise to implement Elliptic-curve cryptography by using an Elliptic Curve Digital Signature Algorithm. The core benefits being that ECDSA is just as hard to break (if not harder) than RSA but requires much smaller keys. The net benefit is faster websites since the cryptologic communications take less time.
To recap, once ownership is verified with multiple challenges, the CertBot communicates with the Let’s Encrypt Server to create RSA key pairs. These sets of key pairs are used to communicate in an encrypted fashion onward. The CA certificate is sent to the ATT server through this channel. Installation is automated by the CertBot running of the ATT server.
How To Mitigate Against Known Threat?
Mitigation Begins with Planning. Now that we have an imaginary threat assessment in place (we’re fast right?) we can do a few things right off the bat to make sure we reduced the scope of the problem by limiting the attack vectors and neutralizing popular kill chain events.
#1. Limit the IP addresses ATT resolves to
If we don’t sell outside the US, we can block all non-US IPs. We can also block the IP addresses of known threat actors through automation. This doesn’t stop MGHC; it just makes the task of hiding themselves a little more annoying. The harder we make them work, the more likely they are to attack someone else. Usually, this work is done by implementing a strong Firewall, but sometimes specialized hardware is required to protect against DDoS attacks.
#2. Use only certain versions of Browsers (for each flavor of Browser) along with a very strict rule on the version of TLS the website supports
While this might cause us to lose certain traffic from people with old Browsers, it is a business/security trade-off. An additional strategy is to enable HTTP Public Key Pinning (HPKP). This ensures that we select and pin the version of the CA cert used by the Browser.
#3. Buy up the misspellings and common variations of the domain
Think of how easy it could be to fool people who are not paying attention to their Browsers address bar. This is especially so if the attacker has SEO’d the misspellings or is using social media ads or phishing to lure people unto a fake site. And if the attackers can get a valid CA cert for a misspelled domain, game over.
#4. Register domain names for foreign extensions and alternate spellings with Cyrillic characters
One of the lesser-known attacks is creating a site with a domain that switches some of the vowels with Cyrillic characters, that are indistinguishable from Latin characters by most browsers. One researcher did this with apple.com, replacing the “a” with a Cyrillic а, and getting a valid CA cert for apple.com.
#5. Educate users on what to look for
At the top of the browser, a periodical banner pointing out the green lock and what it means might be ignored by 80% of the traffic. Still, it is just another attempted to teach the user about the security features in their browser and how we are keeping them safe. Educated consumers are worth more than their weight in gold.
#6. Use cache-busting techniques
This is to make sure that the cached version of the home page and other important pages are retrieved directly from the server to prevent cache poisoning attacks. Writing Cache Busting code is fairly simple, but the benefits are enormous.
#7. Monitor the DNS Server(s) for DoS, DDoS, DNS amplification and Fast flux attacks
Another popular way of diverting traffic to a fake site is by taking down the DNS Server tampering with the routing. If the DNS server is down, then the main site should shut down, and users should be alerted. Fast Flux is a more sophisticated DNS attack that is harder to detect or stop.
The most effective countermeasure against a Fast Flux attack is to shut down the domain (which may not be possible if it has been severely compromised). DoS and DNS attacks are hard to defend against, but if we take item 1 seriously, we could reduce the threat by at least 50%.
Depending on industry-specific threats, we may be able to do a lot more (Training for Customer Service, Machine Learning Algorithms scanning the network, Threat Hunting base on APT reports), but this is a good first step. Now that we have “shut all the windows,” we can build a better lock for the “front door,” our CA certificate.
How To Protect Users Credit Card Information?
Protecting credit cards is very important, and needs to be secured from the prying eyes of MGHC. The easiest way to do this is to ensure that the communication between the server and the user is private and encrypted. We can achieve this by creating encrypted sessions using TLS.
Previously known as SSL (Secure Socket Layer), TLS (Transport Layer Security) 1.3 is the latest and greatest. The TLS protocol has two layers, which are the TLS handshake protocols and the TLS record. MGHC might be watching the traffic on the network. Still, we can make everything they see gibberish if we execute a proper TLS handshake, exchange symmetrical keys, and encrypt the communication between the server and the user with these keys.
Understanding how TLS works is great, but understanding how attackers bypass it is better. There are too many TLS attacks to discuss here. Still, they include; Renegotiation attack, Downgrade attacks: FREAK attack and Logjam attack, Cross-protocol attacks: DROWN, BEAST attack, CRIME, and BREACH attacks, Timing attacks on padding, and POODLE attack.
Others are RC4 attacks, Truncation attack, Unholy PAC attack, Sweet32 attack, and Implementation errors, including the Heartbleed bug, BERserk attack, and Cloudflare bug. Many of these issues have been fixed or mitigated against, except for the Protocol Downgrade.
20% of all sites are still vulnerable to this attack. Much of the risk in using TLS is executing the initial handshake. While most sites can be protected by simply enforcing the highest version of TLS that they can afford.
There is exciting and interesting research going on that will make TLS handshakes secure. It would be secure even against quantum computing attacks, namely Supersingular isogeny key exchange. As the research continues, there is an accessible library published by Microsoft on GitHub along with a Java implementation by an independent engineer.
However, I see an opportunity here. SIDH may work better if implemented as a State Machine. I have started a project that involves converting one of the above libraries to Python. I intend to implement the key exchange using AWS Step Functions (a Serverless State Machine) that calls out to a mesh of Lambda Functions (Serverless Stateless Anonymous Functions. All inside of an encrypted firewalled virtual private cloud (VPC).
This would make SIDH usable and highly interoperable, requiring no installation, just the permission to access the Service Mesh via a kind of SAML authentication. You can check it on GitHub as well.
More Common Sense Mitigation to Protect Credit Cards
Once TLS is implemented and fortified, we can take a few more common-sense steps to protect the user’s credit card:
- Obfuscate the credit card number on the page with **** after it’s entered.
- Make sure the credit card number isn’t saved in the cache if the user navigates away from the payment page.
- Create a timer on the payment page, so attacks that require more time will fail.
- Require login and two-factor authentication before a user can make a payment, and lock the account of a user with too many failed password attempts.
- Disable copy and paste in sensitive fields to prevent malicious CSS from stealing card numbers.
- Obfuscate the id of the fields in CSS and HTML tags. This destroys the ability for a user to use autofill, but it also reduces the chances of a malicious plug-in seeing these fields and scraping them.
- Require the user to save payment details instead of entering them repeatedly for consecutive purchases. The less we force users to expose the credit card, the better.
- Using a payment processor like PayPal, GooglePay, AmazonPay, VisaPay, MastercardPay, or Bolt. These third-party tools cost money, but they reduce risk by not requiring the user to enter their credit card number and shift the liability for fraud to the payment processor.
Conclusion
Cybersecurity is one of the primary concerns of every organization. The truth is that these attacks are endless as hackers are not relenting. However, it is the sole responsibility of website owners, and organizations to protect the integrity of their users’ information from cyberattacks. The steps listed in this article will be very useful to mitigate such attacks and increase the security of your websites.
