Tag: sniff

Device Fingerprinting

Often it can be beneficial to ‘more’ uniquely identify your users. For applications this is trivial, but in a web browser this can be accomplished via only a few attributes.

  • HTTP – User-Agent, IP Address, Content types and languages accepted.
  • HTTPS/SSL – the keys and encryption methods available to a specific user may vary for each client configuration.
  • HTML5 – local storage and capabilities supported.
  • Geolocation – this is included in HTML5, but also supported in many clients without full HTML5 support, or via browser extensions.
  • JavaScript – Installed version – and many DOM attributes/capabilities such as timezone, installed plugins, screen sizes and fonts from the browser can be detected.
  • Java (Applet) – Installed version – this can often be used to get additional information regarding the client system directly from the VM or Operating System itself. (* Persistent Cookies possible)
  • Flash – Installed version – this can often be used to get additional information regarding the client system directly from the Operating System itself. (* Persistent Cookies possible)
  • Silverlight (for Microsoft Windows) – – Installed version and additional information from Operating System?
  • GoogleGEARS (deprecated) – Installed version and additional information from Operating System such as Geolocation

REFERENCES:

X-Content-Type-Options: nosniff

To prevent XSS/CSRF exploits in MSIE8 and newer, it’s often best to close as many attack vectors as possible. An easy one to implement is an HTTP Header to prevent MSIE from “sniffing” the content to change it when incorrect.

Example: we would not want an HTML page intentionally served with ‘text/plain’ to be rendered as HTML.


X-Content-Type-Options: nosniff
Content-Type: text/plain

This could be added programatically to pages in your application, via a servlet or servlet filter or added to the httpd.conf file.

Apache2 example: httpd.conf

<IfModule headers_module>
Header set X-Content-Type-Options nosniff
</IfModule>

REFERENCES:

MSIE Conditional Comments

This approach is useful in building standards based websites and allows you to prevent it from being “polluted” by various hacks used to support MSIE. MSIE5 and newer support the use of Conditional Comments and thus allow the developer to include additional files or markup for specific versions of the browser. Other browsers will see the content as an HTML comment and thus ignore it.


<!--[if IE]><style type="text/css">@import "/css/IE=Fixes.css";</style><![endif]-->
<!--[if lt IE 5.5000]><style type="text/css">@import "/css/IE50Fixes.css";</style><![endif]-->
<!--[if IE 5.5000]><style type="text/css">@import "/css/IE55Fixes.css";</style><![endif]-->
<!--[if IE 6]><style type="text/css">@import "/css/IE60Fixes.css";</style><![endif]-->
<!--[if IE 7]><style type="text/css">@import "/css/IE70Fixes.css";</style><![endif]-->
<!--[if IE 8]><style type="text/css">@import "/css/IE80Fixes.css";</style><![endif]-->
<!--[if IE 9]><style type="text/css">@import "/css/IE90Fixes.css";</style><![endif]-->
<!--[if lt IE 7]><script type="text/javascript" src="/wiki/skins/common/IEFixes.js"></script><![endif]-->

REFERENCES:

Sniff for SSL capability of browser

If you run a secure server, you often have some non-secure content prior to authentication of a secure session. To provide a mechanism to show a page prior to authentication, you can “sniff” for the clients capability with a small bit of JavaScript.

First establish a global variable on the page:
<script type="text/javascript">
var sslok = 0;
</script>

Then, include a JavaScript file that is ONLY available via a secure
<script type="text/javascript" src="https://www.giantgeek.com.com/secure/sniff.js"></script>

The ‘sniff.js’ file should contain (at a minimum):
sslok = 1;

Finally, check and act on the value:
<script type="text/javascript">
if (sslok === 1) {
window.location.href = 'https://www.giantgeek.com/secure/';
}
</script>

Done!

Detecting browser SSL capability with JavaScript

If you run a secured website using HTTPS (aka SSL) it’s often wise to stop or notify users that are using a browser or client that doesn’t support the proper encryption level required.

Here’s a short method to “sniff” the capabilities prior to forwarding users to the secure area. You could add logic to inform the user of the problem.

As usual I’ve stripped a lot of the XHTML markup for readability.

<html>
<head>
<!– set ‘sslok’ global variable for testing SSL capability –>
<script type=”text/javascript”>
<!–
var sslok = 0;
//–>
</script>
<!– try including source javascript from secure server, this will set “sslok” to 1 if it works –>
<!– note that the /secure directory is protected so that only 128+bit SSL is allowed –>
<script type=”text/javascript” src=”https://www.example.com/secure/ssl-test.js”></script>
<!– if ssl is 1, our javascript include worked, so SSL is successful – redirect to SSL –>
<script type=”text/javascript”>
<!–
if (sslok == ‘1’) {
window.location = ‘https://www.example.com/secure’;
}
//–>
</script>
</head>
<body>
</body>
</html>

Contents of the ‘ssl-test.js’ file:

<!– set sslok to 1, so we know this include succeeded –>
sslok = ‘1’;

NOTE: If you use the same ‘filesystem’ for HTTP & HTTPS you might want to use a server-side program (PHP or Java for example) to generate the JavaScript.  Benefit of that process would be that you could also interrogate and return other SSL attributes such as cypher strength.

Cheers!