Archive for the ‘Security’ Category
|Form Security with Autocomplete
Friday, April 10th, 2009
I was looking through my blog this morning because I could have sworn I already wrote this post. I know I’ve had this conversation with Phil Nash of Unintentionally Blank. But I guess I never wrote it down? Oh well…
One of my pet peeves when filling out a form is when I click in the payment field and my credit crard / bank account number drops down because it was saved in the browser from last time I made a payment on that site. How is it that developers on these sites overlook that huge security issue?
There’s a very simple fix for it, and it’s called “autocomplete off”:
The XHTML
<input id="pmt" name="payment" type="text" autocomplete="off"/>The autocomplete="off" makes sure the text field doesn’t expose any saved data. Of course, it would be too easy if this was valid XHTML so it’s not. If you’re concerned with writing 100% valid XHTML, there are valid ways to do this.
Writing valid code
To make this valid, we need to do it with JavaScript. Since I’m pretty sure most people who read this are jQuery freaks (like me), I’ll show the jQuery version of this:
The XHTML
<input id="pmt" name="payment" type="text" />The jQuery
$(function() {
$("input#pmt").attr("autocomplete","off");
});The problem with added security with JavaScript
I don’t really recommend using javaScript for this, only because it’s easily disabled. And then you’re back at square one with the payment info dropping down in the text field
Ideally, I’d like to use PHP to do this, but I can’t find it anywhere so I’m using <noscript>:
The jQuery
$(function() {
$("form#paymentform").html("<input id="pmt" name="payment" type="text" autocomplete="off"/>);
});The XHTML (placed inside the form)
<label for="pmt">Credit Card Number</label> <noscript><input id="pmt" name="payment" type="text" autocomplete="off"/></noscript>
That way, if javascript is enabled you’ll use the jQuery to write the textfield, and if it’s not, you’ll just write it out normally, which will be invalid, but more secure.
Let me know if anyone knows the PHP way to check for JS.
Tags: forms, ui
Posted in Security | 8 Comments »
Using .htaccess to Prevent Bandwidth Theft
Thursday, April 2nd, 2009
Every once in a while Google Analytics will turn up a peculiar behavior where you can tell someone is linking directly to an image hosted on your Web server. Sometimes it can be for good reasons like giving you credit for a project, or make sure files are synced up (cross-domain projects); but it’s usually just out of ignorance or laziness (or myspace).
Either way, hotlinking images like that steals your bandwidth and can effect the performance of your server. So you want to stop it.
There are a few ways you can do this; some people output a special image to a bandwidth thief that says something like “Stop stealing my images”. I don’t like that mainly because you’re intentionally degrading your bandwidth to teach someone a lesson about hotlinking? Bleh.
I prefer using a 403 error, it works just as well in my opinion, and gets the point accross.
.htaccess code
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?csskarma\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]Put that in your .htaccess file (in your root directory). If you don't have an .htaccess file, just create an empty file in the root and name it ".htaccess". Then put this code in there and you'll be good to go.
Don't forget to change out "csskarma" for your web site. You'll definitely notice if you forget that bit.
What's going on
Turn on the rewrite condition:
RewriteEngine OnMatch any request for csskarma.com (NC means "no case" it will match upper or lower case requests):
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?csskarma\.com/ [NC]Allow empty requests, these are harmless and often 404 errors anyway
RewriteCond %{HTTP_REFERER} !^$Replace the stolen image with a 403 "forbidden" error
RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]Tags: htaccess, HTTP
Posted in Security | 8 Comments »
Securing your Development Space
Monday, September 15th, 2008
You can hide your development space from the public many ways, a weird URL no one will find, use a local testing server (localhost), or set up a development server. Up until my last redesign I was just using a directory called dev under csskarma.com. And that was fine, but my file paths would all have to be adjusted when I went live (not a huge deal, but annoying none-the-less).
If you’re a frequent reader, you might remember that in my last post I mentioned that I was coming out of laziness and cleaning up some stuff on my server. So I finally set up my dev server. It’s just a sub-domain, but seems to work well so far.
Not that I have anything on it. but I felt like I should use some best practice stuff and password protect it. In password protecting a directory, you use an .htaccess file coupled with an .htpasswd file (to store the usernames and passwords)
The first thing you need is a list of users you want to grant access to. Let’s say I want to set up a general account for people to access my directories. We’ll make the username guest and the password dontstaylong.
Next, we have to go to a site that will encrypt the password for us, I use htpasswd generator. After plugging in the username and password, you’ll come out with something like this:
Your full .htpasswd file
guest:ZGu8x2pjH62PkTake that code and place it in a file called .htpasswd (you’ll need to create this). You can put that file anywhere on your server, but it’s best to make sure it’s not web accessible (so no one can steal your password). So, if you have a public_html directory or a www, put the file one level higher than that.
Now that we have our .htpasswd file on our server, we can start cutting off access to various parts of our site using an .htaccess file. You can also add multiple users by following the same process as the first one, but put one user per line in the .htpasswd file.
Let’s say I have a directory at http://www.csskarma.com/articles/htpasswd/ that I want to password protect. To do that I would put an .htaccess file in that directory with this code in it:
Your full .htaccess file
AuthType basic
AuthName "This directory is protected"
AuthUserFile /full_server_path_to_file/.htpasswd
Require valid-userImportant: the AuthUserFile must be an absolute server path to the file, relative will not work (at least it didn’t for me).
Lastly, you visit your new password protected directory (username: guest – password: dontstaylong) and marvel at your greatness. This password should apply to all sub directories as well.
In my experience, this is the easiest way to secure an area of your site. However, if you’re passing sensitive information through, you may want something a little more secure than this. Yahoo! provides a good best practices security write-up you can use as a reference.
Anyone have any thoughts/suggestions for beefing up the .htpasswd file?
Tags: htaccess, htpasswd
Posted in Security, Web Development | 5 Comments »
