HTTPS

6 Ways to avoid a Punycode attack

Photo by Arsyad Basyarudin on Unsplash

Research shows a new phishing site is created every 20 seconds and they are usually only live for four hours before hackers take them down and move on to create another deceiving domain. A clever way to cover their tracks and evade detection.

  1. Be cautious if the site presses you to do something quickly. This is a classic strategy by hackers to rush their potential victims so that they are less likely to notice anything suspicious. Often they will offer a “limited time only” deal, and make it difficult to exit the page with ‘are you sure you want to exit’ pop-ups: these are all tactics to make you stay on their site longer and give them your details.
  2. If you are being offered a deal, go to the original company site and check if it’s available there as well, if not it’s most likely a scam doing its best to mimic the established brand and trick visitors into handing over their details.
  3. If some of the letters in the address bar look weird, or the website design looks different, rewrite it or visit the original company URL in a new tab to compare. The letters in the address bar looking strange is a key indicator that punycode is being used to trick you into thinking you are visiting a well-established brand site when in fact you are being taken to a malicious site.
  4. Use a password manager; this reduces the risk of pasting passwords into dodgy sites.
  5. Force your browser to display Punycode names, this option is available in Firefox.
  6. Click on the padlock to view and inspect the HTTPS certificate.

February 5, 2025 by Cyber Security 0

Preventing Cross-Site Scripting Attacks

Photo by Pawel Czerwinski on Unsplash

Implementing HTTP security headers are an essential way to keep your site and your visitors safe from attacks and hackers. In a previous post, we dove into how the X-Frame-Options header and frame-ancestors directive can help combat click jacking. In today’s post, we want to go more in-depth with the X-XSS-Protection header, as well as the newer CSP Reflected-XSS directive, and how they can help prevent cross-site scripting (XSS) attacks.

What is X-XSS Protection?

The x-xss-protection the header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it. It is supported by Internet Explorer 8+, Chrome, and Safari. The recommended configuration is to set this header to the following value, which will enable the XSS protection and instruct the browser to block the response in the event that a malicious script has been inserted from user input, instead of sanitizing.

x-xss-protection: 1; mode=block

Cross-site Scripting (XSS)

Cross-site scripting, also known as XSS, is basically a way to inject code that will perform actions in the user’s browser on behalf of a website. Sometimes this is seen by the user and sometimes it can go totally unnoticed in the background. There are many different types of XSS vulnerabilities, below are two of the most common.

Reflective XSS: These are usually the most common types. Typically these are within HTTP query parameters and are used by server-side scripts to parse and display a page of results for the user.

Persistent XSS: These are when the data from the attacker is actually saved on the server and then displayed to the user, mimicking a normal page.

Other XSS vulnerabilities include DOM-based, stored server, reflected server, stored client, reflected client, and the subset of a client. Below is an example of how an XSS attack works.

X-XSS-Protection Directives

A 0 value disables the XSS Filter, as seen below.

x-xss-protection:0;

A 1 value enables the XSS Filter. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.

x-xss-protection:1; mode=block

Enabling X-XSS Protection Header

The x-xss-protection the header is easy to implement and only requires a slight web server configuration change. You might also want to check to make sure you don’t already have the header enabled. Here is a couple of easy ways to quickly check.

  1. Open up the network tab in Chrome DevTools and if your site is using a security header it will show up on the Headers tab. You can see below that even we are using this security header on the KeyCDN blog.
  2. Another quick way to check your security headers is to quickly scan your site with a free tool, securityheaders.io, created by Scott Helme. This gives you a grade based on all of your security headers and you can see what you might be missing.

Enable in Nginx

add_header x-xss-protection "1; mode=block" always;

Enable in Apache

header always set x-xss-protection "1; mode=block"

Enable on IIS

To enable on IIS simply add it to your site’s Web.config file.
…

<httpProtocol>
    <customHeaders>
        <add name="X-XSS-Protection" value="1; mode=block" />
    </customHeaders>
</httpProtocol>
    .......
</system.webServer>

Reflected-XSS Directive

An important thing to keep in mind is that the X-XSS-Protection header is pretty much being replaced with the new Content Security Policy (CSP) Reflected-XSS directive. The reflected-xss directive instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks. Valid values are allow, block, and filter. This directive is not supported in the <meta> element.

However, it is not supported in all browsers yet, and so it is still recommended to use the x-xss-protection header. However, you could use both the x-xss-protection and reflected-xss together.

Summary

Hopefully, now you understand a little more about what the x-xss-protection HTTP response header does and how it can help prevent cross-site scripting (XSS) attacks. As seen above, this is very easy to implement. We use security headers on our websites and we encourage you to do the same. Together we can make the web a more secure place and help boost the security header usage numbers.

July 29, 2024 by Application Security 0

HTTP Verb Tampering

Photo by Christopher Gower on Unsplash

HTTP is the protocol that lets applications respond to requests and retrieve data. An HTTP verb is one of several actions the application can use when querying the server. Standard HTTP verbs include:

  • GET: retrieves data from specified source
  • HEAD: requests preview of specified resource
  • POST: submits entity to specified resource, such as editing data
  • PUT: transmits new data to the specified resource replacing the old information
  • DELETE: deletes the specified resource entirely

Most web applications use HTTP verbs to authenticate users and manage access privileges. However, malicious actors can bypass authentication and access controls to protect privileged information.

December 2, 2023 by Application Security 0

Hardening Your HTTP Security Headers Part 2

Photo by Maik Jonietz on Unsplash

4. X-Frame-Options

The x-frame-options header provides click jacking protection by not allowing iframes to load on your website. It is supported by IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. Here is an example of what the header looks like:

x-frame-options: SAMEORIGIN

Enable in Nginx

add_header x-frame-options "SAMEORIGIN" always;

Enable in Apache

header always set x-frame-options "SAMEORIGIN"

5. Expect-CT

The expect-ct header prevents miss used certificates from being used by allowing websites to report and optionally enforce Certificate Transparency requirements. When this header is enabled the website is requesting the browser to verify whether or not the certificate appears in the public CT logs. Here is an example of what the header looks like:

expect-ct: max-age=604800, enforce, report-uri=”https://www.example.com/report”

Enable in Nginx

add_header expect-ct "max-age=604800, enforce, report-uri='https://www.example.com/report' always;

Enable in Apache

header always set expect-ct "max-age=604800, enforce, report-uri="https://www.example.com/report"

6. X-Content-Type-Options

The x-content-type-options header prevents Internet Explorer and Google Chrome from sniffing a response away from the declared content-type. This helps reduce the danger of drive-by downloads and helps treat the content the right way. Here is an example of what the header looks like:

x-content-type-options: nosniff

Enable in Nginx

add_header x-content-type-options "nosniff" always;

Enable in Apache

header always set x-content-type-options "nosniff"

7. Feature-Policy

The feature-policy header grants the ability to allow or deny browser features, whether in its own frame or content within an inline frame element (<iframe>). Here is an example of what the header looks like:

feature-policy: autoplay 'none'; camera 'none'

Enable in Nginx

add_header feature-policy "autoplay 'none'; camera 'none'" always;

Enable in Apache

header always set feature-policy "autoplay 'none'; camera 'none'"

October 29, 2023 by Application Security 0

Hardening Your HTTP Security Headers Part 1

Photo by Markus Spiske on Unsplash

There are a lot of things to consider when securing your website or web application, but a good place to start is to explore your HTTP security headers and ensure you are keeping up with best practices. In many cases, they are very easy to implement and only require a slight web server configuration change. HTTP security headers provide yet another layer of security by helping to mitigate attacks and security vulnerabilities. In this post, we will explore some of them to help you better understand their purpose and how to implement them.

What Are HTTP Security Headers?

Whenever a browser requests a page from a web server, the server responds with the content along with HTTP response headers. Some of these headers contain content metadata such as the content-encoding, cache-control, status error codes, etc.

Along with these are also HTTP security headers that tell your browser how to behave when handling your website’s content. For example, by using the strict-transport-security you can force the browser to communicate solely over HTTPS. There are six different HTTP security headers that we will explore below (in no particular order) that you should be aware of and we recommend implementing if possible.

1. Content Security Policy

The content-security-policy the header provides an additional layer of security. This policy helps prevent attacks such as Cross-Site Scripting (XSS) and other code injection attacks by defining content sources that are approved and thus allowing the browser to load them.

All major browsers currently offer full or partial support for content security policy. And it won’t break the delivery of the content if it does happen to be delivered to an older browser, it will simply not be executed.

There are many directives which you can use with content security policy. This example below allows scripts from both the current domain (defined by ‘self’) as well as google-analytics.com.

content-security-policy: script-src ‘self’ https://www.google-analytics.com

To explore all of the directives, and to see implementation on Nginx and Apache, make sure to check out our in-depth post on Content Security Policy.

2. X-XSS-Protection

The x-xss-protection the header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it. It is supported by Internet Explorer 8+, Chrome, and Safari. Here is an example of what the header looks like:

x-xss-protection: 1; mode=block

Enable in Nginx

add_header x-xss-protection “1; mode=block” always;

Enable in Apache

header always set x-xss-protection “1; mode=block”

3. HTTP Strict Transport Security (HSTS)

The strict-transport-security header is a security enhancement that restricts web browsers to access web servers solely over HTTPS. This ensures the connection cannot be established through an insecure HTTP connection which could be susceptible to attacks.

All major modern browsers currently support HTTP strict transport security except for Opera Mini and versions previous of Internet Explorer.

Here is an example of what the header looks like: You can include the max-age, subdomains, and preload.

strict-transport-security: max-age=31536000; includeSubDomains; preload

To read more about this header and see implementation on Nginx and Apache, make sure to check out our in-depth post on HTTP Strict Transport Security.

October 15, 2023 by Application Security 0

Open Source Security Testing Tools You Can Start Using Today

Photo by Andrew on Unsplash

In today’s interconnected world, ensuring your digital assets’ security is paramount. As cyber threats continue to evolve, it’s crucial to have effective security testing tools at your disposal. Fortunately, the open-source community offers a wealth of powerful security testing tools to help identify vulnerabilities and strengthen defenses. In this blog post, we’ll explore some of the top open-source security testing tools you can use today.

  1. OWASP ZAP (Zed Attack Proxy): OWASP ZAP is a popular open-source web application security scanner. It provides a comprehensive set of features for finding vulnerabilities in web applications, including automated scanning, manual testing, and security analysis. ZAP is highly extensible, allowing you to customize and enhance its capabilities according to your specific requirements. It’s an invaluable tool for identifying common web application vulnerabilities like cross-site scripting (XSS), SQL injection, etc.
  2. Nmap (Network Mapper): Nmap is a versatile and powerful open-source network scanning tool for security auditing and network exploration. With its extensive scanning techniques, Nmap can map out hosts, identify open ports, and detect potential vulnerabilities. It supports a scripting engine that enables you to automate tasks and create custom scripts for targeted scanning. Nmap is an essential tool for assessing network security and identifying potential entry points for attackers.
  3. Wireshark: Wireshark is a widely used open-source packet analyzer for network troubleshooting and security analysis. It allows you to capture and examine network traffic at a granular level. Wireshark provides detailed insights into network protocols, allowing you to detect anomalies, analyze network behavior, and identify security threats. Its robust filtering capabilities and extensive protocol support make it an indispensable tool for network security professionals.
  4. Metasploit Framework: The Metasploit Framework is a powerful open-source penetration testing platform that enables you to assess and exploit vulnerabilities in systems and applications. With a vast collection of exploits, payloads, and auxiliary modules, Metasploit simplifies the process of penetration testing and helps security professionals validate the effectiveness of their defenses. It also offers a collaborative community and a wide range of resources for sharing knowledge and expertise.
  5. Nikto is an open-source vulnerability scanner to identify security flaws in web servers and applications. It performs comprehensive tests, including server misconfigurations, outdated software versions, and potentially dangerous files or scripts. Nikto provides detailed scan reports, making prioritizing and remediating identified vulnerabilities easier. Its simple command-line interface and extensive plugin support make it a valuable tool for security testing.

Securing your digital assets requires a proactive and comprehensive approach. By leveraging open-source security testing tools, you can enhance your security posture and protect against potential threats. The tools mentioned in this blog post, including OWASP ZAP, Nmap, Wireshark, Metasploit Framework, and Nikto, offer powerful capabilities to identify vulnerabilities, assess network security, and perform penetration testing. Start exploring these open-source tools today and take a proactive stance in securing your systems and applications. Remember to stay updated with the latest releases and actively participate in the open-source community to maximize the benefits of these valuable resources.

May 18, 2023 by Cyber Security 0

What is an SSL Certificate?

Photo by Stephen Phillips – Hostreviews.co.uk on Unsplash

An SSL certificate (or TLS certificate) is a digital certificate that binds a cryptographic key to your organization’s details. Secure Sockets Layer (SSL) are cryptographic protocols designed to encrypt communication between a server and a web browser.

While SSL certificates are installed server-side, there are visual cues in the browser that show SSL protection. If SSL is present, you may see https:// in the address bar, a padlock, a green address bar, or a combination of the three. SSL secures your connection to a web server and encrypts any transferred data. Encrypting data reduces the cybersecurity risk of man-in-the-middle attacks or many other cyber attacks. SSL has traditionally been used to secure credit card information on e-commerce sites, personal data transfers, and social media sites.

Today, search engines like Google have called for HTTPS everywhere, even if websites don’t handle sensitive data or information like personally identifiable information (PII). HTTPS not only provides critical information security and data integrity but is a requirement for many new web browser features like progressive web apps (PWAs). What is Transport Layer Security (TLS)?

Transport Layer Security (TLS) is the successor to Secure Sockets Layer (SSL). Think of it as a more secure version of SSL. Despite new certificates using TLS (RSA or ECC), it remains common for security certificates to be referred to as SSL certificates.

TLS, like SSL, provides privacy and data integrity between two or more communicating applications. When secured by TLS, connections between your browser and a server must have one or more of the following properties:

The connection is secured by symmetric cryptography. The keys for symmetric encryption are unique to each connection, based on a shared search negotiated at the start of a session through a TLS handshake. The server and your browser negotiate the details of which encryption algorithm and cryptographic keys are used before data is transmitted. Negotiating a shared secret is secure (preventing eavesdropping) and reliable (no attacker can modify messages without being detected, preventing man-in-the-middle attacks).

The identity of communicating parties can be authenticated using public-key cryptography. Public keys are disseminated widely, and private keys are only known to the owner. People can encrypt a message using the receiver’s public key, but only their private key can decrypt. Authentication can be optional but is generally required for at least one of the parties (typically the server).

The connection is reliable because each transmitted message has integrity checked using a message authentication code (MAC), preventing undetected loss or manipulation of data. A MAC is a short piece of information used to confirm the message came from the stated sender and has not been changed. This protects data integrity and authenticity.

In addition, the configuration of TLS can provide additional privacy-related benefits like forwarding secrecy. Forward secrecy ensures future disclosure of session keys only compromises a particular session. This is achieved by generating a unique key for each session, so the compromise of a single session key cannot affect the data exchanged in any other session.

What is Hypertext Transfer Protocol Secure (HTTPS)?

Hypertext Transfer Protocol Secure (HTTPS) is an extension of Hypertext Transfer Protocol (HTTP). It is used to securely transfer data over a network. In HTTPS, the communication is encrypted using TLS.

HTTPS provides authentication of the accessed website, protecting the privacy and integrity of exchanged data. It also protects against man-in-the-middle attacks such as eavesdropping and tampering with transmitted data. Because HTTPS piggybacks HTTP on top of TLS, the entire HTTP protocol is encrypted, including the requested URL (the specific page requested), query parameters, headers, and cookies (which often contain identifying information about the user).

The one thing that eavesdroppers can see is the website address and port numbers which are part of TCP/IP protocols and not protected by HTTPS. This means an eavesdropper can infer the IP address and port number of a web server (the domain name but not the specific page) that you are communicating with, as well as the amount of data transferred and session time.

Modern web browsers know which HTTPS websites to trust based on pre-installed certificate authorities. Certificates authorities like Let’s Encrypt are trusted to provide valid certificates. This means HTTPS connections are only trusted if all the following are true:

You trust your web browser correctly implements HTTPS with valid certificate authorities. You trust the certificate authority will only vouch for legitimate websites. The website you visit provides a valid certificate signed by a trusted certificate authority. The SSL certificate correctly identifies the website and not another entity. You trust SSL/TLS is sufficient to protect against eavesdroppers.

December 29, 2022 by Application Security 0

HTTP Status Codes For Burp Suite Testing

Photo by Vlad Rosh on Unsplash

I’ll preface the testing first by mentioning that it’s important to have familiarity with the HTTP status codes to help us better understand how the server is handling our attack packets. Below is a subset of HTTP status codes from OWASP that can be used as a point of reference:

Status codeMessageDescription
200OKResponse to a successful REST API action. The HTTP method can be GET, POST, PUT, PATCH or DELETE.
201CreatedThe request has been fulfilled and resource created. A URL for the created resource is returned in the Location header.
202AcceptedThe request has been accepted for processing, but processing is not yet complete.
400Bad RequestThe request is malformed, such as message body format error.
401UnauthorizedWrong or no authentication ID/password provided.
403ForbiddenUsed when the authentication succeeded, but the authenticated user doesn’t have permission to the request resource.
404Not FoundWhen a non-existent resource is requested.
406UnacceptableThe client presented a content type in the Accept header which is not supported by the server API.
405Method Not AllowedThe error for an unexpected HTTP method. For example, the REST API is expecting HTTP GET, but HTTP PUT is used.
413Payload too largeUses to signal that the request size exceeded the given limit e.g. regarding file uploads.
415Unsupported Media TypeThe requested content type is not supported by the REST service.
429Too Many RequestsUsed when there may be DOS attack detected or the request is rejected due to rate limiting
500Internal Server ErrorAn unexpected condition prevented the server from fulfilling the request. Be aware that the response should not reveal internal information that helps an attacker, e.g. detailed error messages or stack traces.
501Not ImplementedThe REST service does not implement the requested operation yet.
503Service UnavailableThe REST service is temporarily unable to process the request. Used to inform the client it should retry later.
August 29, 2022 by Application Security 0

Cross-Site Request Forgery (CSRF) Attacks

Photo by Markus Spiske on Unsplash

What is CSRF

Cross-site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.

A successful CSRF attack can be devastating for both the business and the user. It can result in damaged client relationships, unauthorized fund transfers changed passwords and data theft—including stolen session cookies.

CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.

CSRF Attack Example

Before executing an assault, a perpetrator typically studies an application in order to make a forged request appear as legitimate as possible.

For example, a typical GET request for a $100 bank transfer might look like:

A bad actor can embed the request into an innocent-looking hyperlink:

Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer.

Note that if the bank’s website is only using POST requests, it’s impossible to frame malicious requests using a <a> href tag. However, the attack could be delivered in a <form> tag with the automatic execution of the embedded JavaScript.

August 15, 2022 by Application Security 0

How to Check Your HTTP Security Headers

Photo by Kelly Sikkema on Unsplash

Below are three quick and easy ways to check your HTTP security headers, as part of your HTTP response headers.

1. KeyCDN’s HTTP Header Checker Tool

KeyCDN has an online HTTP Header Checker tool that you can easily use to retrieve which HTTP security headers are currently running on your website. Simply input the URL you want to check.

It will then return with your HTTP response headers.

2. Chrome DevTools – Response Headers

Another quick and easy way to access your HTTP security headers, as part of your response headers, is to fire up Chrome DevTools. To run this click into the “Network” panel press Ctrl + R (Cmd + R) to refresh the page. Click into your domain’s request and you will see a section for your response headers.

3. Scan Your Website With securityheaders.io

A third way to check your HTTP security headers is to scan your website on securityheaders.io. This is a handy little tool that was developed by Scott Helme, an information security consultant. It gives your website a score, based on present HTTP security headers, from an A+ grade down to an F grade. Make sure to bookmark it. Here is an example of an A+ grade on his own website.

Here is an example of an F grade without any of the HTTP security headers present on Citi’s corporate website.

It spits out both your raw HTTP headers and gives you a nice summary of each HTTP security header and what is missing.

Scott also created both a Chrome extension and Firefox extension in which you can scan the HTTP security headers of a website you want to analyze. He did an analysis in February 2016 of the Alexa top 1 million sites to see what their HTTP security header usage was and the results might surprise you. The number of sites using the strict-transport-security header nearly doubled. So it appears more people are starting to implement them, especially now that many companies are making the transition to HTTPS. We recommend during an HTTPS migration to do a full evaluation of your current security policies.

Content Security Policy (CSP) especially can be a powerful mechanism to prevent Cross-Site Scripting (XSS) attacks which accounts for 84% of all security vulnerabilities in web sites. However, as you can see above less than 5% of websites are actively using the headers. This needs to change.

Summary

As you can see HTTP security headers can help harden the security of your website and in most scenarios, there is no reason not to use them. If you don’t control access to your own web servers we recommend reaching out to your web host and let them know. Maybe send them a link from securityheaders.io, an F grade is never a good thing!

July 15, 2022 by Application Security 0

Recent Comments

No comments to show.