watchbird-guide

A free, open-source guide to fixing common website security vulnerabilities.

The Watchbird Security Guide: Your Step-by-Step Fix-It Manual

Section: HTTPS Enforcement

Fixing HTTPS Enforcement

The Risk: Without automatic redirection to HTTPS, visitors could accidentally connect to your site insecurely, making them vulnerable to man-in-the-middle attacks where an attacker can see and steal their data.

The Fix:

• For Apache / LiteSpeed Servers (.htaccess file):

  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

• For Nginx Servers (nginx.conf file):

  server {
      listen 80 default_server;
      server_name _;
      return 301 https://$host$request_uri;
  }

Section: Essential Headers

Implementing Essential Security Headers

The Risk: Missing essential security headers can leave your website vulnerable to various attacks, including cross-site scripting (XSS), clickjacking, and protocol downgrade attacks. These headers provide instructions to browsers on how to handle content and connections, significantly enhancing user security.

The Fix:

• Strict-Transport-Security (HSTS)
  • For Apache / LiteSpeed Servers (.htaccess file):

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
    </IfModule>

  • For Nginx Servers (nginx.conf file):

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

• X-Frame-Options
  • For Apache / LiteSpeed Servers (.htaccess file):

    <IfModule mod_headers.c>
        Header set X-Frame-Options "SAMEORIGIN"
    </IfModule>

  • For Nginx Servers (nginx.conf file):

    add_header X-Frame-Options "SAMEORIGIN";

• X-Content-Type-Options
  • For Apache / LiteSpeed Servers (.htaccess file):

    <IfModule mod_headers.c>
        Header set X-Content-Type-Options "nosniff"
    </IfModule>

  • For Nginx Servers (nginx.conf file):

    add_header X-Content-Type-Options "nosniff";

• X-XSS-Protection
  • For Apache / LiteSpeed Servers (.htaccess file):

    <IfModule mod_headers.c>
        Header set X-XSS-Protection "1; mode=block"
    </IfModule>

  • For Nginx Servers (nginx.conf file):

    add_header X-XSS-Protection "1; mode=block";

Section: Server Version Leak

Hiding Your Server Version

The Risk: Revealing your exact server software and version (e.g., Apache/2.4.29) is like giving a burglar the blueprint to your house. Hackers can use this information to find known exploits for that specific version.

The Fix:

• For Apache / LiteSpeed Servers (httpd.conf or apache.conf file):

  ServerSignature Off
  ServerTokens Prod

• For Nginx Servers (nginx.conf file):

  server_tokens off;

Section: Technology Leak

Hiding the X-Powered-By Header

The Risk: This header reveals the technology your site is built on (e.g., PHP, ASP.NET). This gives attackers another piece of information to narrow down their attacks.

The Fix:

• For PHP Applications (php.ini or in PHP code):
  • To disable in php.ini:

    expose_php = Off

  • Alternatively, in PHP code (for PHP 5.3+):

    <?php
    header_remove('X-Powered-By');
    ?>

• For IIS Servers (web.config or IIS Manager):
  • Using IIS Manager:
    1. Open IIS Manager.
    2. Navigate to your site.
    3. Double-click "HTTP Response Headers".
    4. Select "X-Powered-By" and click "Remove".
  • Using web.config:

    <configuration>
       <system.webServer>
          <httpProtocol>
             <customHeaders>
                <remove name="X-Powered-By" />
             </customHeaders>
          </httpProtocol>
       </system.webServer>
    </configuration>

Section: Secure Cookie Flags

Securing Your Cookies

The Risk: Without the 'Secure' flag, cookies can be sent over insecure connections. Without the 'HttpOnly' flag, cookies can be stolen by JavaScript attacks (XSS). Both can lead to account hijacking.

The Fix: This one is code-dependent. The fix must be applied in the application's code when setting cookies. This ensures that cookies are only transmitted over HTTPS and are inaccessible to client-side scripts.

• Example for PHP (using session_set_cookie_params for session cookies):

  <?php
  $lifetime = 0; // Session cookie
  $path = '/';
  $domain = '.yourdomain.com'; // Replace with your domain
  $secure = true; // Only send cookie over HTTPS
  $httponly = true; // Prevent JavaScript access
  session_set_cookie_params($lifetime, $path, $domain, $secure, $httponly);
  session_start();
  ?>

• Example for setting a cookie in JavaScript (simplified, typically done server-side):

  document.cookie = "cookieName=cookieValue; Path=/; Domain=yourdomain.com; Secure; HttpOnly; SameSite=Lax";
  // Note: HttpOnly flag cannot be set directly from client-side JavaScript for security reasons.
  // This example is illustrative; HttpOnly must be set by the server when the cookie is issued.

General Principle:

When setting cookies in any programming language or framework (e.g., Python with Flask/Django, Node.js with Express, Java with Spring), ensure that the Secure and HttpOnly flags are enabled. The Secure flag ensures the cookie is only sent over encrypted HTTPS connections, and the HttpOnly flag prevents client-side scripts from accessing the cookie, mitigating XSS attacks.

---

Thank you for supporting an independent builder.