Stop BeEF with Content Security Policy

G5 Cyber Security

2 weeks ago

TL;DR

BeEF (Browser Exploitation Framework) relies on injecting JavaScript into a victim’s browser. A strong Content Security Policy (CSP) can prevent this injection, effectively stopping BeEF hooks. This guide shows you how to implement CSP to protect your web application.

What is BeEF?

BeEF is a penetration testing tool that exploits web browser vulnerabilities. It works by hooking into a victim’s browser and allowing an attacker to execute commands on it. This usually happens through cross-site scripting (XSS) attacks, where malicious JavaScript code is injected into a trusted website.

How Content Security Policy Helps

Content Security Policy lets you control the resources your web application is allowed to load – scripts, styles, images, etc. By defining a strict CSP, you can prevent BeEF’s injected JavaScript from running, even if an XSS vulnerability exists.

Implementing Content Security Policy: Step-by-Step

Understand Your Application’s Needs

Identify all legitimate sources of scripts (your own domains, CDNs).
Determine if you need to allow inline scripts or styles. Avoid this if possible.
List any external resources like fonts or images that are loaded from other domains.

Start with a Report-Only Policy

This allows you to monitor potential CSP violations without blocking anything. Add the following meta tag to your HTML <head> section:

<meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'self'; report-uri /csp-report">

Replace /csp-report with the URL of your reporting endpoint. This is where CSP violation reports will be sent.
Analyze the reports to identify legitimate resources that need to be allowed in your final policy.

Create Your Core Policy

Based on your application’s needs, create a CSP directive. Here are some common directives:

default-src 'self': Only allow resources from the same origin (domain). This is a good starting point.
script-src 'self' https://example.com: Allow scripts from your own domain and https://example.com.
style-src 'self': Only allow styles from the same origin.
img-src 'self' data:: Allow images from your own domain and inline data URIs (e.g., base64 encoded images).

Example policy allowing scripts from your domain and a CDN:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://cdn.example.com">

Deploy the Policy

Once you’re confident your policy is correct, remove the Report-Only attribute:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://cdn.example.com">

Test Thoroughly

Use a browser developer console to check for CSP violations. Look for errors related to blocked scripts or other resources.
Attempt to inject BeEF hooks into your application (in a safe testing environment) and verify that they are blocked by the CSP.

Consider nonce or hash for Inline Scripts

If you absolutely need inline scripts, use either a nonce or a hash to allow them:

Nonce: Generate a random string for each request and add it to your CSP policy and the script tag. This is more secure but requires server-side changes.

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'nonce-{random_value}'">

<script nonce="{random_value}">...your inline script...>

Hash: Calculate the SHA256 hash of your inline script and add it to your CSP policy. This is less flexible but doesn’t require server-side changes for each request.

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'sha256-{hash_value}'">

Regularly Review and Update

As your application evolves, review and update your CSP policy to ensure it remains effective. New resources or vulnerabilities may require adjustments.

Important Considerations

Browser Compatibility: Most modern browsers support CSP. Check Can I Use for compatibility details.
Reporting Endpoint Security: Secure your /csp-report endpoint to prevent attackers from manipulating the reports.
CSP is not a silver bullet: It’s most effective when combined with other security measures, such as input validation and output encoding, to mitigate XSS vulnerabilities in the first place.