devexp

The month July is probably going to be an interesting month for everybody who is familiar with the Twitter service.

On Aviv Raff’s website you can read a new daily bug in twitter. The cool thing is that he will give Twitter 24 hours to manage the bug before posting it on his blog. This means that, if we are lucky or Twitter is unlucky, they don’t manage to fix this bug, we can try out all bugs.

I wonder if this is legal in the first place to post harmful information about a website, in this case Twitter. What they actually can do is tell the world how to get Twitter crashed or how to really annoy the developers. I know that, being a developer, it is handy to have some good testers, but the difference with a tester is that it stays confidential information. Besides some attention, Aviv Raff will not get much out of this and in that case it might be better to cooperate with Twitter and get some recognition from them.

In 2006 there was a ‘Month of the Browser Bugs’ with the same intensions but on a browser level and it seemed to be a ratter big success.

The question is: Will Twitter survive those 31 days and if they can stay one of the leading websites on the level of networking?

If there are real security issues and problems in the core of the system, I guess those bugs won’t be fixed in 24 hours. I’m not the only one thinking this, as there are on the other blogs and news sites a lot of people sharing my opinion. What do you think of this issue? Feel free to comment on this post!

Besides those thoughts it will be very pleasant for us to follow all issues and see how this case evolves…

Sometimes it’s interesting to protect your web content from the world, and there are different ways (or a combination) to do this:

Create a robot.txt file

This file is uploaded into the root folder of a website and makes sure that specific folders shouldn’t be crawled and indexed by search engines. Most of the time this is for images, administration section, documents, etc…

Create the file using notepad and type this:

User-agent: *
Disallow: /images/
Disallow: /cgi-bin/
Disallow: /documents/
Disallow: /administration/

This means that for all search bots (*) these 4 folders will not be crawled. It‘s possible to set these folders for each individual search robot by replacing the * by the name of the robot (ex. Googlebot, MSNbot, …)

Encryption

When using a password, be sure to use encryption.
I guess it could be interesting to write a whole article on this issue, because it’s a bit complex, and I’ll try to do that in the next few days. But if this topic is interesting for you be sure to take a look at MD5

• Info: http://en.wikipedia.org/wiki/MD5
• PHP: http://be2.php.net/md5
• ASP: http://www.freevbcode.com/ShowCode.Asp?ID=2366

.htaccess

An image or document often gets a direct link, created by users and placed in their favorites. That isn’t a big problem when we are talking about an unimportant document or a small image. But when dozens of websites start linking to this document, it’s possible to reach the maximum of your bandwidth in no time. And it certainly may not happen when we are talking about confidential documents.
To restrict these documents from the outer world, we can use the .htaccess file.
This file affects only the directory where it has been placed in and all its subdirectories.

So if you have a directory
/security
and 2 folders in it
/security/docs
/security/images

In this case, put the .access file in the /security if you want all the directories to be secured, or only in the docs folder if this is the only one you want to be secure.
A good hint is to try to use the fewest number of .access file because redundancies can cause infinite loops.
Preventing hot linking is the most important event the .access file will prevent. Instead of getting the file they are hot linking they can get another image like an angry man or a message that this document is not available.
This is how an .htaccess file is build up:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ – [F]

The first two rules have to be kept as they are now; the third rule however needs to be adjusted so it indicates your specific URL.
The fourth line is set up to deny the use of types you like to be denied, you can add as many types as you like using the pipe (|) separator.
To show another file when they want to download a .gif or .jpg, change the fourth line to something like this:

RewriteRule \.(gif|jpg)$ http://www.mydomain.com/angryman.gif [R,L]

These adjustments should implement some security in to your website. Greets.