The first part explained the basics of a content security policy (CSP) and suggested a roadmap for implementation. This part prepares a WordPress site for the implementation.
First, create a child theme of your current theme. A basic child theme is composed of a directory and two almost empty files: style.css and functions.css. Any further modifications will happen in this directory. Essentially, the child theme contains modifications to the original theme and allows automatic updates to the original theme as required. It also allows us to simply switch back to the original if something goes wrong during the development process.
With the child theme in place, consider adding security headers to the site. This is an optional, but beneficial step. Make sure you are comfortable with FTP and editing the .htaccess file; if not, simply skip this step and leave it for some other time. Continue reading “Add Content Security Policy to WordPress [2/4]”
Policy: a principle of behavior, wise conduct, a tool of governance, overall intention and direction as formally expressed by management.
By adding a Content Security Policy (CSP) to a blog, we can specify resources a reader’s browser (Chrome, Firefox, Edge) is allowed to use on a site. We can specify from where a browser can load scripts, styles, images, media, and objects. Specify to where a form can post data. Enable or disable inline scripts and styles; even exactly specify the fingerprint of allowed scripts and styles. Require that each file must have a specified fingerprint to make sure it was not modified.
You may have heard of a recent British Airways hack, or how thousands of UK and Australian governments’ sites were hijacked to mine crypto-currency. Both were compromised via a modified script file. Also a fresh news story about scripts injected into shopping carts. Attacking WordPress sites en masse is nothing new, and in most cases malicious scripts are injected into sites through some weakness, completely out of site owners’ control. Something should be done. Fortunately some smart people figured out how to remedy the situation, at least reduce the risk, so all we have to do is implement few recommendations.
To see how a CSP on a WordPress site looks, check out the source of this site. Right-click anywhere on the page and select “View Page Source” or type Ctrl+U. Take a look at the first <meta> tag, just below the <head>.
What does this do? The policy:
- disables defaults for directives requiring sources (-src),
- specifies two sha256- integrity attributes of inline scripts allowed to run,
- allows loading of scripts from this domain and Cloudflare cdn,
- specifies one sha256- integrity attribute of an allowed inline style,
- allows loading of styles only from this domain,
- allows loading of images only from this domain,
- prevents loading of fonts,
- prevents loading of objects,
- allows forms to post only to this domain,
- requires integrity attributes (sri) to be specified for styles and scripts.
Mozilla has a good reference of policy directives. This is likely to change as new specifications are introduced, but it is a good start. Once the policy is in place it is easy to tinker with.
Continue reading “Add Content Security Policy to WordPress [1/4]”
Scott Helme has a detailed procedure of how to configure Raspberry PI to act as a DNS resolver with DNS-level “content-blocking” for a network. It is a great weekend project, fun and useful. The hardware cost is around 100 CAD on Amazon.
- Content filter on DNS level, including ads and known nasty sites.
- Reduced web traffic. Depends on sites you visit, but 40% is a reasonable expectation.
- Upstream DNS queries are directed over https, so you get some extra privacy.
- Pages load faster, take a look at the example.
- Pi-Hole has a nice admin interface, so you get insight into DNS chatter on the network.
Here are network requests for a home page of a popular news site using default (no filtering) DNS resolver. In total it took 395 requests, 5.3 MB and six minutes to load.
Now if I switch to the DNS resolver on Raspberry PI:
Total of 143 request, 2.7MB to load, and 20.75 seconds. Take a look at all the lines in red with failed status, this is where the domain got blocked by the pi-hole on the Raspberry.
That’s ~ 50% less data and 17 times faster.
Continue reading “Home Network DNS Resolver”
This scenario has been designed to engage the entire cyber security incident response (IR) team and evolve the IR plan and capabilities as quickly as possible. It includes technical, managerial, financial, regulatory, legal, and public relation challenges.
Take a look at your current IR plan and see if it stands up to this test. An organisation that does not have a cyber security IR plan, or a program, must act as if it has already been breached. If you do not have an IR plan get one; NIST SP 800-61 r2 is a good start. Continue reading “Cyber Security Incident Scenario”