Archive for the 'Security' Category

Security treat: the ftp address, username and password of your website’s server broadcasted over the Internet

That post talks about another security problem resulting of the bad interaction between two different applications. The current problem is that the ftp address with the login name and password of your web site can be viewable by anybody on the Internet in a specific situation.

How it happened?

I am using the AceFTP software to connect to the ftp of my website’s server. It is a really nice ftp software. One of the useful features is that you have the possibility to view a file (text, image or webpage) in an embedded web browser. Then if you click on your index.htm file, you will see it instantly into the browser; it is really useful when you do not remember what a specific file was.

I am also using StatCounter as my web site statistic application. I already talked about that beautiful service before. You only have to put a little JavaScript code on one of you webpage, and it will record the entry and exit pages of your visitors.

Now you wander what is the problem?

The problem exists when one of the feature of AceFTP and another one of StatCounter interact together:

  • The preview feature of AceFTP
  • And the possibility to put your statistics public with StatCounter

Note: you need to have in mind that this security problem can be possible with other ftp client softwares that have the same feature and any other web site statistics services that broadcast the stats publicly. I get AceFTP and StatCounter in my example because it is with them that I discovered the problem.

You see the problem coming? When I check a file that contains the JavaScript code of StatCounter in the “embedded browser”, the code on that page is then executed by the ftp client software. Then the visit will be recorded by StatCounter. The problem is that the entry page that StatCounter will show will be something like that:

username:\password@ftpyourdomainname.com/thefilepath.htm

Then if the public statistics of your StatCounter account is at “on”, then anybody can have access to the ftp server of your web site.

Demonstration

  1. I check one of my file containing the StatCounter’s JavaScript code with my ftp client software
  2. Then I check my stats

How can we fix the problem?

  1. Web services like StatCounter could check for the patterns: “* : * @ *”, then hiding them. It is exactly what Bloglines had done when I discovered a problem like this one with their web application.
  2. You could use another option of StatCounter that enable you to ignore the visits that come from your IP address. Then if StatCounter ignore your visits, such activities will not be the recorded.
  3. You could simply stop using the preview feature of AceFTP.

Conclusion

My conclusion is that same as the one I wrote for the Bloglines’ problem with the RSS feed: This experience is a good example of the potential security treats that can appears when more than one system start to interact together.

Technorati: | | | | | |

The software architecture to use for faster security hole patching: Web Applications

Security holes can be found everywhere in software. It can be a problem by the way a programming language is used; it can be a problem with the conception or the use of an un-secure protocol; it can also be a problem of interaction with other software or libraries; it can be a problem with his interaction with the operating system, or it can be a problem with the way users use it.

These problems are real, and many people and billion dollars are spent to try to cope with them. However nothing is perfect and the result is currently seen as marvel by someone and terrible by others.

If a security problem is found, you can bet that an advisory will follow; a patch of the software in cause will be distributed. Software developers thought about developing systems to ease the burden of software updating imposed to users. Some systems are good, others are more debatable. In a case or another, the problem is the same: users need to perform some type of task to patch their software to secure their systems. With the number of software they daily used, they can hardly keep them up-to-date, with or without having the will to do it.

What if they do not own, on their computer, the software they are using? It is sure that not owning them on their computer does not make the code surer, but will the updates be faster? You bet. Think about it. You are using certain functionalities given by a certain web services, web application, API, etc. Someone find a security hole in the thing, and then wrote and publish an advisory about the found security hole. Normally, thousands or millions of people would need to download and install a patch to get rid of the bug and re-secure their systems. But if the same code is use by all these users, you only have to change that code to automatically patch all users. It is probably the greatest security advantage we have by using such online software.

I recently unintentionally tested the concept with Bloglines. I found a bug in their system (in fact it was the relation between a bug in their system and the use of another web service), published an advisory, then the system was patched 1 or 2 days later by the Bloglines developers. Then all the users were patched and secured at the same time.

Technorati: | | | | | | | | | | |

Come back on the Bloglines’ security flaw with secure feeds

Give to Cesar what belong to Cesar. Bloglines has reviewed the previous security flaw I found in their system in interaction with secure web feeds and fixed it.

I was reviewing the posts that bloggers make on the subject and read all the comments on them. It leads me to check if the problem I found on Bloglines was always there. They fixed it.

How have they fixed it? No they did not delete the HTTPS and HTTP Authentication handling feature of Bloglines. They simply make the URL feeds with HTTP Authentication private.



We can’t change the status of such feeds; the system does not give us the possibility anymore. They are private and will remain private. It’s good news. As far as I know, there are no other problems with this feature in Bloglines.

I would like to thank the Bloglines team for their positive answer to my security flaw discovery and for their fast service fix.

Technoratie: [] [] [] [] []




This blog is a regularly updated collection of my thoughts, tips, tricks and ideas about my semantic Web researches and related software development.


RSS Twitter LinkedIN


Follow

Get every new post on this blog delivered to your Inbox.

Join 64 other followers:

Or subscribe to the RSS feed by clicking on the counter:




RSS Twitter LinkedIN