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:
Categories: WebStandards, Work Tags: acrobat, adobe, cross, crossdomain, domain, file, flash, http, logs, network, policy, server, xml
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.
Categories: WebStandards, Work Tags: availability, free, http, monitoring, network, performance, reporting, server, ssh, web
Here’s an odd one…. I’ve found that if you use the common method of using Conditional Comments to separate MSIE specific CSS, you’ve likely added a performance problem without knowing it… that is, in addition to the network connection and time required for the different CSS files.
It turns out that the standard use of this approach blocks the other downloads until the main CSS is loaded.
The solution is both simple and painless to implement…. just add an empty condition above all of the other content. This works for all approaches, such as those where comments surround the <body> or various <link>, <style> or <script> tags.
<!DOCTYPE html>
<!--[if IE]><![endif]-->
<html lang="en">
...
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: block, blocking, browser, comments, conditional, connections, css, files, hacks, ie, link, msie, network, performance, script, style
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:
- create a (free) account,
- retrieve your existing DNS values from your current provider,
- determine direct vs. CDN “cloud” routing for each subdomain,
- change your DNS records to point to the CloudFlare DNS servers
Some additional advantages I’ve seen since implementing:
- Site remains available in limited capability to users during server outages or upgrades.
- Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
- IPv6 dual-stack support
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: acceleration, akamai, application, browser, cache, cdn, client, cloudflare, content, delivery, fast, http, ipv4, ipv6, network, performance, security, server, speed, web, webapp
These are useful for some advanced caching behavior, but there are cases where you might find them unnecessary for static files (in particular). Most network analysis tools will call attention to this header value, and while it seems like a trivial amount of bandwidth to send from the server to the client, the real reason for the negative score is more likely related to the behaviors that it causes in the client.
It should be noted that the default value used for the ETag is based upon the ‘inode’ of the file, as such it’s IS problematic in clustered server environments. I’ve shown the correction for this below.
Adding the following to your Apache http.conf file is a start:
# Change ETag to remove the iNode (for multi-server environments)
FileETag MTime Size
#Remove ETag from all static content, this could be done globally without the FilesMatch, but we want better control.
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset ETag
</IfModule>
</FilesMatch>
REFERENCES:
Cheers.
Categories: WebStandards, Work Tags: apache, browser, cache, caching, ETag, header, http, network, performance, server
Obviously “Cookies” have a lot of advantages in web applications to maintain “state”, unfortunately using standard server configurations leads to even static content serving them up un-necessarily wasting some (minimal) bandwidth.
Adding the following to the Apache httpd.conf file is a start:
#Remove Cookie from all static content (except HTML as javascript could use it)
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset Cookie
</IfModule>
</FilesMatch>
REFERENCES:
Cheers!
I’ve often found that most JSP developers are uncertain as to why their HTML output contains a lot of extra blank-lines, tabs and carriage returns. White space included in the template text of JSP pages is preserved by default. This can have undesirable effects. For example, a carriage return added after a taglib directive would be added to the response output as an extra line. This cruft is known as WhiteSpace, and it is responsible for a lot of wasted bandwidth and many spacing issues in HTML designs.
The challenge:
- Developers that only use WYSIWYG editors are never even aware of the extra spacing within JSP source code.
- Developers that work in source code often want to format the markup to allow for better visualization and readability of the source code.
- Most IDE’s do not show the developers the special characters within the editor environment, external text editors such as NotePad++ and TextPad can be configured to show them.
Here’s a few suggested approaches on removing these, first development items:
- Remove comments:
- Remove any (and all) JSP style comments
<%-- comment --%> as each line in them will result in a carriage return being sent to the browser.
- While you are at it, remove HTML comments
<!-- comment --> as they often expose potential attack vectors for individuals trying to hack your website.
- Combine your JSP directives,
<%@page %> or <jsp:directive.page /> into a single entry.
- Open and close all tags on a single line when possible.
Compiler options are possible for some platforms:
- The page directive on each JSP can contain the argument to tell the compiler to trim the space in individual JSP’s:
<jsp:directive.page language="java" pageEncoding="utf-8" trimDirectiveWhitespaces="true" />
- For Tomcat (and others?) web.xml can be edited to contain the following in the
jsp-config section:
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<trim-directive-whitespaces>true</trim-directive-whitespaces>
</jsp-property-group>
</jsp-config>
- For Tomcat (and others?) web.xml can be edited to contain the following for the
JSPServlet:
<init-param>
<param-name>trimSpaces</param-name>
<param-value>true</param-value>
</init-param>
- The deployment descriptor can also be used to do so by adding a
trim-directive-whitespaces element to a jsp-property-group element in the deployment descriptor and set it to true.
- Some IDE’s expose the attribute, NetBeans 5.5 uses the following:
- Open the deployment descriptor file in the editor.
- Click the Pages button at the top of the editor.
- Select a JSP property group.
- Select the Trim Directive Whitespaces checkbox.
- Save the deployment descriptor.
- Custom tag authors can eliminate white space from the output generated by a tag file by setting the
trimDirectiveWhiteSpace attribute of the tag directive to true.
JSP Version Matrix for common servers:
| Apache Tomcat 7.0.x |
JSP 2.2 |
| Apache Tomcat 6.0.x |
JSP 2.1 |
| Apache Tomcat 5.5.x |
JSP 2.0 |
| Apache Tomcat 4.1.x |
JSP 1.2 |
| Apache Tomcat 3.3.x |
JSP 1.1 |
| IBM WebSphere Application Server 7.x |
JSP 2.x |
| IBM WebSphere Application Server 6.x |
JSP 2.0 |
| IBM WebSphere Application Server 5.x |
JSP 1.2 |
REFERENCES:
Happy coding!
Categories: Uncategorized Tags: bandwidth, compiler, deployment, descriptor, directive, jsp, network, performance, tags, trim, whitespace
This topic, and Firefox add-on have received a lot of press lately, as such I figured that I’d capture some comments on the topic. HTTP Session hijacking is nothing new, anyone with the ability to monitor your non-secured network traffic can do this with little effort… what’s happened here is that there are now some really simple to use tools to do the job.
In the past, someone would have to passively monitor your network traffic with a tool like WireShark, and all they’d really have to do is wait for you to access a website to watch the ‘HTTP Cookies’ (or even a URL that contains a ’session id’). With that information, they simply need to use the same value that you do to essentially take over your session and your current state. Banks are particularly at risk for this, but in most cases they use HTTPS/SSL for all secure data including logins. Social websites such as Facebook and even GMail, often default to non-secure logins to maximize their server and network performance.
Best defense here… never use non-secure login forms, especially when using a public wireless (or wired) network.
Interesting enough, there’s now a Firefox add-on that monitors for usage of Firesheep on the network, unfortunately neither of these currently work in Linux… links below!
Here’s a useful trick for minimizing server HTTP connections, unfortunately it’s not universally supported so you will need to provide alternate methods for non-supporting browsers (such as MSIE).
This works by placing the content of the image into the URL itself, as such there’s no need to open up a new server connection and no extra caching at any tier.
<img src=”data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub/ /ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7″ alt=”embedded folder icon” width=”16″ height=”14″ />
Categories: WebStandards, Work Tags: base64, data, html, http, image, img, network, optimization, performance, url
I’ve been using an old Linksys WRT-54G (version 2.0) for years, while Linksys released a few firmware updates over the years, none of them really added any new functionality. Thankfully, they had released the source code to the open-source community and several excellent releases have been made available.
Additions such as real-time monitoring/graphing, boosting wireless transmitter power, QoS (Quality of Service) and WOL (Wake-on-LAN) have been added making the router and network much more useful and valuable.
The most prominent versions are:
NOTE: There are several branches on both of these, you can read more at their respective websites.
I was easily able to update from the Linksys firmware (4.21.1) to Tomato 1.25 in only a few minutes, it was even capable of saving my existing configuration making the transition that much easier!
Happy Networking
Categories: Work Tags: firmware, free, linksys, network, opensource, qos, router, tomato, wireless, wol, wrt