I was scanning my server log files the other day and found that this old “bot” is still making the rounds. It help’s to shut the door on this with some configuration. It’s specifically looking for PHP vulnerabilities and is easily identified by the expletive in it’s User-Agent HTTP request headers.
REFERENCES:
This HTTP Header is a feature added by MSIE8 to force it to restrict some XSS vectors that can be disabled by the user. Generally you can add it into your webserver configuration.
X-XSS-Protection: 1; mode=block
REFERENCES:
Crossdomain access can be enabled in JavaScript with a mechanism similar to that in Flash. Instead of hosting a crossdomain.xml file though, crossdomain access is enabled per file, through an additional HTTP response header:
Access-Control-Allow-Origin: *
CORS is a more modern equivalent to JSONP for cross-domain XmlHttpRequests(AJAX) with options to limit domains, subdomains and ports.
Initial browser support:
REFERENCES:
Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs.
If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.
Restricted domains
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="example.com" />
</cross-domain-policy>
Open to all domains (not recommended, but fully backward compatible)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
REFERENCES:
Regardless if you host your own websites, or pay to have them hosted elsewhere, up-time, availability and network performance metrics are important to your visiting guests.
Here are two free services that I’ve found useful for monitoring, notification and reporting.
BTW, you can even use these to watch competitors or sites that you frequent.
Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.
CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.
Implementation takes only minutes as it requires that you:
Some additional advantages I’ve seen since implementing:
REFERENCES:
There are a couple of steps required to force a browser to save/download content instead of displaying it in the browser window.
X-Download-Options: noopen
X-Content-Type-Options:nosniff
Content-Disposition: attachment; filename=example.txt
Content-Type: text/plain
NOTE: MSIE also supports a poorly documented proprietary META tag…
<meta name="DownloadOptions" content="noopen|nosave" />
REFERENCES:
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:
DNS is much like a phone book for the internet. For each domain name (or subdomain like ‘www’), there is an IP address that resembles a phone number. Getting the matching number for each domain can take some time and make your site appear slow, particularly on mobile connections. Fortunately, you can pre-request this information and speed up your site in most cases.
To enable a domains DNS lookup to be performed in advance of the request, you can add a single line to the <head> section of your page.
<link rel="dns-prefetch" href="//giantgeek.com" />
If you want to explicitly turn on (or off) this behavior, you can add one of the following, or their HTTP Header equivalents:
<meta http-equiv="x-dns-prefetch-control" content="on" />
<meta http-equiv="x-dns-prefetch-control" content="off" />
This is supported in all modern browsers:
If should be noted that a similar method can be used to prefetch as page, but I will save that for a different article:
<link rel="prefetch" href="http://www.skotfred.com/" />
REFERENCES:
IE overrides several HTTP error status pages but it has a size threshold. Only if the error page send by the server has a large enough body then IE decides it’s meaningful and displays it.
Usually to be safe you should make error pages that are larger then 512 bytes. The threshold varies per HTTP status code. You can look at what your thresholds are currently set to. In IE 5 and greater the settings are stored in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\ErrorThresholds]
Err Size(bytes):
REFERENCES: