Protecting your visitors
The web is a hostile environment, as we all know, or do we? Many web developers are in the habit of protecting their own sites, combing their code for possibilities that might allow an intruder to gain unauthorised access to site features. We employ encryption, hashing, tokens and a host of other techniques to mask private information and SSL/TLS is employed to guard the details in-transit. But do we pay as much attention to protecting the remote identities of our users and visitors?
In years gone by, webmasters would make public parts of their site stats and in some cases entire log files. Visitors' IP addresses were there for public viewing. Contributors are allowed to post links, embed images or worst still javascript into forum posts and blog comments. It seems common that as long as it doesn't affect that site's security, it isn't a problem to the developer and/or owner of that site.
Embedded javascript can do a number of things, number one problem would be cookie exposure. Links and embedded media can expose visitors' IP addresses, or session identifiers, if you don't account for the referer headers using redirectors, javascript or on site hosting. User privacy must remain exactly that, private, but unless it threatens the site itself, it is often a point that is overlooked. Images are often allowed in user posted content, although savvy users can choose in Firefox whether images originating from sites other than the one that they are visiting are displayed.
Links are clicked on by choice, so if a user clicks on a link than they take their own chances. However, you should be looking to use a redirector script, so as not to leave session identifiers or user specific URLs in the referer header, for a target site to get details from. Finally, you should never be allowing users to make posts that contain javascript that is then embedded as script in your pages. Convert input to HTML entities, so that embedded script is displayed as plain text and doesn't become part of your markup. Be careful to avoid being fooled through obfuscation or other evasion techniques.
Err on the side of caution, security outweighs functionality
My own preference is to not allow user submitted images and other media, unless it is hosted on my site. It is trivial to embed an img tag and set its CSS style as display: none ;. This could expose to somebody outside of your site or organisation, the IP address of every visitor to that page, without there being any visual indication to the visitors that something is not quite right. The image file doesn't even have to exist, so there's no real bandwidth use, but the IP addresses are still logged. Users can post links to images, but those links are to be handled by a redirector script. Javascript is used sparingly and never submitted by the users.
For the security of both the site and its users, values are tokenised for user cookies and form authentication. Multiple login failures are logged and offending sources banned, not accounts. Known untrusted sources are not given the necessary tokens to make full use of forms and so on. Design your application to make the little things count, not just in protecting your site, but also your users. Make an effort to punish sources of suspected dark activities, not the accounts that they are targeting.
There is more to follow and some of the existing text in this article will likely be edited, but I hope that what is already here is giving you food for thought.
Post a comment:
| 
| 
