Remove language packs from Windows 7

I often have to install different languages/locales on Windows 7 to perform testing in different languages, unfortuately adding all of them into a single installation can take a lot of space, particularly when using a virtual machine.

Using the usual method to ‘remove installed software’ will remove updates, but leaves the languages in place, to completely remove them you must open a command prompt and execute the following:


LPKSETUP

Select the languages you wish to remove, and click continue… it will take a while, but the languages will be removed one at a time.

REFERENCES:

“Referrer-Policy” HTTP Header

A relatively new HTTP Header that is supported by most modern browsers (except MSIE) is the “Referrer-Policy” header. There have been previous attempts to implement similar protections through use of the ‘rel’ (or ‘rev’) attributes on links to external websites. The latest approach takes a different approach and prevents leaking of internal URLs, and in some cases parameters, to external websites. This is important from a security perspective as you might maintain some sensitive information in your page urls, that would otherwise be inadvertently shared with an external website.

Clearly, you’ll need to determine your own level of security based upon your needs. Example: ‘no-referrer’ would be the most strict and would prevent the browser from sending the ‘Referer'(sic) header even to your own websites pages.

Example header values:

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Implementation can be accomplished in many ways, the most simple being and addition to your HTTP server configuration similar to the one shown below for Apache 2.x:

Header always set Referrer-Policy strict-origin

REFERENCES:

Cannot load VirtualBox after upgrading Ubuntu

If your computer uses SecureBoot, you may occasionally encounter this problem after upgrading the operating system. Thankfully, the solution is simple after some initial setup the first time.

The error generally reads something like: Could not load ‘modprobe vboxdrv’

First time:

  1. Create signing keys:

    openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"

  2. Sign the module (vboxdrv for this example):

    sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vboxdrv)

  3. Register the keys to Secure Boot:

    sudo mokutil --import MOK.der

  4. Supply a password for later use after reboot
  5. Reboot and follow instructions to Enroll MOK (Machine Owner Key).
  6. Restart after enrolling
  7. After the reboot, you may also need to load the module:
    sudo modprobe vboxdrv

After future updates you might re-encounter the problem, then you just need:

  1. sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vboxdrv)
  2. sudo modprobe vboxdrv

REFERENCES:

Fixing the Windows 7 is not genuine message

While I’ve run various builds of Linux for many years, I still have to routinely test my work in Windows. While I often attempt to keep my laptops able to dual-boot into Windows, that only (realistically) supports only a single version of Windows. For older versions, I generally rely upon VirtualBox and can then have different configurations available when needed, while keeping my Linux apps open too!

Occasionally, I’ve had a virtual machine running a licensed copy of Windows 7 start warning that it is not activated. This can prove to be annoying for several reasons, as such I did some research and found that others have encountered the same problem and shared the below solutions.

First method:

  1. Open a command prompt in Administrator mode.
  2. Execute “slmgr -rearm”
  3. NOTE: some sites tell you to locate and remove “slui.exe” – DO NOT DO THIS!
  4. Restart Windows
  5. Problem should be resolved

Alternative – reactive with your product key:

  1. Open a command prompt in Administrator mode.
  2. Execute “slmgr –upk
  3. Execute “slmgr –ipk (your product key)
  4. Restart Windows
  5. Problem should be resolved

REFERENCES:

Remove Guest Account in Ubuntu

While the Guest session can be useful for some people, I’ve generally considered it to be security vulnerability as unauthorized users could gain physical access to some areas of your system that are not secured as well as they “should” be.

Additionally, the default behavior that allows for the username(s) to be stored and listed on the login screen are less than ideal.

Here we remove both!

  1. Create the config folder:
    sudo mkdir -p /etc/lightdm/lightdm.conf.d
  2. Create a new config file:
    sudo vi /etc/lightdm/lightdm.conf.d/10-ubuntu.conf
  3. Add the following:

    [SeatDefaults]
    user-session=ubuntu
    greeter-show-manual-login=true
    greeter-hide-users=true
    allow-guest=false
  4. Reboot

REFERENCES:

Content-Security-Policy: block-all-mixed-content

If you are running a secure website, it’s a good idea to prevent non-secure assets from being included on your page. This can often happen through the use of content management system, or even through website vulnerabilities. A simple change in HTTP headers will help browsers to defend against them.


Content-Security-Policy: block-all-mixed-content

Most modern browsers, except MSIE, currently support this approach.
– Firefox 48+

REFERENCES

Content-Security-Policy: upgrade-insecure-requests;

As the web has been shifting to HTTPS for security and performance reasons, there are many methods to migrate users. One simple method is via the use of the Content-Security Header.


Content-Security-Policy: upgrade-insecure-requests;

Most modern browsers, except MSIE, currently support this approach.
– Chrome 43+

REFERENCES

Force cleaning of workspace during automated Maven builds

I’ve been using Maven for years, but once in a while forget to ‘clean‘ before building, resulting in old artifacts being included in the output. This can be problematic when refactoring for security items. Thankfully, it is very easy to add a ‘clean‘ step to your pom.xml to force clean each build.

BONUS – the plugin has some additional capabilities, specifically you can specify files outside of ‘target’ to be removed. This can be useful for any custom reporting or logging that you might create.

The Maven clean plug-in can be added to the pom.xml as such:

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<version>${maven-clean-plugin.version}</version>
<executions>
<execution>
<id>auto-clean</id>
<phase>initialize</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>

REFERENCES:

document.write() Intervention!

The use of document.write() has always been a bad “code smell” in JavaScript. Most web performance guides such as WebPageTest and Yahoo Exception Performance have warned against this practice.

In most cases, document.write() can be replaced by inserting innerHTML into an empty element after the rest of the page loads. This approach also allows the developer to “think” about how the page might react in cases where JavaScript is disabled or not available on the client.

Google has recently changed the default behavior, such that when on a slow (currently 2G) connection, but discussions have also leaned toward including any slow connection.
As such, right now, the following will occur on slow (2G) connections:

  • Chrome 53+ (warning displayed in debugger console)
  • Chrome 55+ (blocked – code will not execute, warning message will appear in debugger console)

For users on slow connections, such as 2G, external scripts dynamically injected via document.write() can delay the display of main page content for tens of seconds, or cause pages to either fail to load or take so long that the user just gives up. Based on instrumentation in Chrome, we’ve learned that pages featuring third-party scripts inserted via document.write() are typically twice as slow to load than other pages on 2G.


My advice – remove all use of document.write() for required content in your code now, as your users MAY NOT see that content if you do not.

REFERENCES:

SameSite cookies

Recently, while reading through the updated 2017 OWASP Top Ten RC1 documentation, last updated in 2013, I noticed a recommendation to use Cookies with the “SameSite=strict” value set to reduce CSRF exposure in section A8.

Consider using the “SameSite=strict” flag on all cookies, which is increasingly supported in browsers.

Similar to the way that HttpOnly and Secure attributes have been added, SameSite allows for additional control.

Per the documentation, as of April 2017 the SameSite attribute is implemented in Chrome 51 and Opera 39. Firefox has an open defect, but I would expect it to be added soon to follow Chrome.


Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;

According to the specification you can issue the SameSite flag without a value and Strict will be assumed:


Set-Cookie: CookieName=CookieValue; SameSite

As many programming languages and server runtime environments do not yet support this for session cookies, you can use the Apache Tier1 configuration to append them.


Header edit Set-Cookie ^(JSESSIONID.*)$ $1;SameSite=Strict
Header edit Set-Cookie ^(PHPSESSID.*)$ $1;SameSite=Strict

It looks like PHP.INI might support the following attribute in a future release, but it’s not there yet!

session.cookie_samesite

REFERENCES: