Skip to content

Securing your webserver against common attacks

Blog
  • 1622031373927-headers-min.webp

    It surprises me (well, actually, dismays me in most cases) that new websites appear online all the time who have clearly spent an inordinate amount of time on cosmetics / appearance, and decent hosting, yet failed to address the elephant in the room when it comes to actually securing the site itself. Almost all the time, when I perform a quick security audit using something simple like the below

    https://securityheaders.io

    I often see something like this

    Not a pretty sight. Not only does this expose your site to unprecedented risk, but also looks bad when others decide to perform a simple (and very public) check. Worse still is the sheer number of so called “security experts” who claim to solve all of your security issues with their “silver bullet” solution (sarcasm intended), yet have neglected to get their own house in order. So that can you do to resolve this issue ? It’s actually much easier than it seems. Dependant on the web server you are running, you can include these headers.

    Apache

    <IfModule mod_headers.c>
    Header set X-Frame-Options "SAMEORIGIN"
    header set X-XSS-Protection "1; mode=block"
    Header set X-Download-Options "noopen"
    Header set X-Content-Type-Options "nosniff"
    Header set Content-Security-Policy "upgrade-insecure-requests"
    Header set Referrer-Policy 'no-referrer' add
    Header set Feature-Policy "geolocation 'self' https://yourdomain.com"
    Header set Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()"
    Header set X-Powered-By "Whatever text you want to appear here"
    Header set Access-Control-Allow-Origin "https://yourdomain.com"
    Header set X-Permitted-Cross-Domain-Policies "none"
    Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    </IfModule>
    

    NGINX

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Download-Options "noopen" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Content-Security-Policy "upgrade-insecure-requests" always;
    add_header Referrer-Policy 'no-referrer' always;
    add_header Feature-Policy "geolocation 'self' https://yourdomain.com" always;
    add_header Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=();";
    add_header X-Powered-By "Whatever text you want to appear here" always;
    add_header Access-Control-Allow-Origin "https://yourdomain.com" always;
    add_header X-Permitted-Cross-Domain-Policies "none" always;
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;" always;
    

    Note, that https://yourdomain.com should be changed to reflect your actual domain. This is just a placeholder to demonstrate how the headers need to be structured.

    Restart Apache or NGINX, and then perform the test again.


    That’s better !

    More detail around these headers can be found here

    https://webdock.io/en/docs/how-guides/security-guides/how-to-configure-security-headers-in-nginx-and-apache


Related Topics
  • 3 Votes
    4 Posts
    330 Views

    I’ve been using this service for a couple of days now, and it’s made my internet access so much faster. That alone is a plus, and I never thought there would be a contender for Cloudflare in this area.

  • 12 Votes
    8 Posts
    287 Views

    @crazycells good question. Gmail being provided by Google is going to be one of the more secure by default out of the box, although you have to bear in mind that you can have the best security in the world, but that is easily diluted by user decision.

    Obviously, it makes sense to secure all cloud based services with at least 2fa protection, or better still, biometric if available, but email still remains vastly unprotected (unless enforced in the sense of 2fa, which I know Sendgrid do) because of user choice (in the sense that users will always go for the path of least resistance when it comes to security to make their lives easier). The ultimate side effect of taking this route is being vulnerable to credentials theft via phishing attacks and social engineering.

    The same principle would easily apply to Proton Mail, who also (from memory) do not enforce 2fa. Based on this fact, neither product is more secure than the other without one form of additional authentication at least being imposed.

    In terms of direct attack on the servers holding mail accounts themselves, this is a far less common type of attack these days as tricking the user is so much simpler than brute forcing a server where you are very likely to be detected by perimeter security (IDS / IPS etc).

  • 1 Votes
    2 Posts
    270 Views

    @mike-jones Hi Mike,

    There are multiple answers to this, so I’m going to provide some of the most important ones here

    JS is a client side library, so you shouldn’t rely on it solely for validation. Any values collected by JS will need to be passed back to the PHP backend for processing, and will need to be fully sanitised first to ensure that your database is not exposed to SQL injection. In order to pass back those values into PHP, you’ll need to use something like

    <script> var myvalue = $('#id').val(); $(document).ready(function() { $.ajax({ type: "POST", url: "https://myserver/myfile.php?id=" + myvalue, success: function() { $("#targetdiv").load('myfile.php?id=myvalue #targetdiv', function() {}); }, //error: ajaxError }); return false; }); </script>

    Then collect that with PHP via a POST / GET request such as

    <?php $myvalue= $_GET['id']; echo "The value is " . $myvalue; ?>

    Of course, the above is a basic example, but is fully functional. Here, the risk level is low in the sense that you are not attempting to manipulate data, but simply request it. However, this in itself would still be vulnerable to SQL injection attack if the request is not sent as OOP (Object Orientated Programming). Here’s an example of how to get the data safely

    <?php function getid($theid) { global $db; $stmt = $db->prepare("SELECT *FROM data where id = ?"); $stmt->execute([$theid]); while ($result= $stmt->fetch(PDO::FETCH_ASSOC)){ $name = $result['name']; $address = $result['address']; $zip = $result['zip']; } return array( 'name' => $name, 'address' => $address, 'zip' => $zip ); } ?>

    Essentially, using the OOP method, we send placeholders rather than actual values. The job of the function is to check the request and automatically sanitise it to ensure we only return what is being asked for, and nothing else. This prevents typical injections such as “AND 1=1” which of course would land up returning everything which isn’t what you want at all for security reasons.

    When calling the function, you’d simply use

    <?php echo getid($myvalue); ?>

    @mike-jones said in Securing javascript -> PHP mysql calls on Website:

    i am pretty sure the user could just use the path to the php file and just type a web address into the search bar

    This is correct, although with no parameters, no data would be returned. You can actually prevent the PHP script from being called directly using something like

    <?php if(!defined('MyConst')) { die('Direct access not permitted'); } ?>

    then on the pages that you need to include it

    <?php define('MyConst', TRUE); ?>

    Obviously, access requests coming directly are not going via your chosen route, therefore, the connection will die because MyConst does not equal TRUE

    @mike-jones said in Securing javascript -> PHP mysql calls on Website:

    Would it be enough to just check if the number are a number 1-100 and if the drop down is one of the 5 specific words and then just not run the rest of the code if it doesn’t fit one of those perameters?

    In my view, no, as this will expose the PHP file to SQL injection attack without any server side checking.

    Hope this is of some use to start with. Happy to elaborate if you’d like.

  • 1 Votes
    13 Posts
    873 Views

    @phenomlab said in Hardening WordPress - Reducing the attack vector:

    @jac Microsoft’s and Google’s Authenticator both support TOTP - essentially, a time based system that changes every 30 seconds. The main principle here is that the device itself carrying the One Time Passcode only needs to be in sync with the source server in terms of time, and can be completely offline with no internet access.

    Provided the time matches on both devices, the One Time Passcode will be accepted. Applications such as Microsoft Authenticator and Authy also support push notification meaning you just choose either yes or no on your device when prompted, and then that response is sent back to the origin which then determines if access is granted or not.

    One of the best looking password less authentication models was CLEF - sadly, this product died out due to a lack of funding (if I recall correctly) although some open source implementations of this have appeared quite recently.

    Essentially, both products will achieve the same goal. TOTP is an industry standard, and widely accepted across the board. Not all services offer push confirmation.

    Many thanks for the detailed reply mate.

    There’s some great advice in there that will help me secure my accounts.

  • 0 Votes
    1 Posts
    208 Views
    No one has replied
  • 0 Votes
    1 Posts
    191 Views
    No one has replied
  • 0 Votes
    1 Posts
    231 Views
    No one has replied
  • 0 Votes
    1 Posts
    292 Views
    No one has replied