Archive for the 'Security' Category

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

Published July 29th, 2005 in Security. 4 Comments Print This Post Print This Post

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

Published July 5th, 2005 in Security. 2 Comments Print This Post Print This Post

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

Published May 22nd, 2005 in Blogging and Security. 0 Comments Print This Post Print This Post

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: [] [] [] [] []

Do not use the Atom Gmail service with online aggregators like Bloglines

Published May 14th, 2005 in Security. 9 Comments Print This Post Print This Post

I study the problem of the secure web feeds since some weeks. I read a surprising post that talks about the Gmail Atom feed service used with Bloglines this morning. An idea came up in my mind while reading the post: it is not possible… can I really have access to login and password of people that subscribe to “secure” web feeds that use SSL and HTTP Authenticate with Bloglines? The answer is sadly: Yes I can.

The problem is that to use the Gmail Atom service in Bloglines, you need to build your feed’s URL like this: https://USERNAME: PASSWORD@gmail.google.com/ gmail/feed/atom, to provide the user and password to the feed’s server.

All the problem is there: you have the username and the password in plaintext directly in the URL.

The first thing I then checked is if I was able to find such strings in online aggregators such as Bloglines. There is the answer:



Why do I have access to these URL? Probably because the Bloglines profile of these users are public and not private.

Then I tested if I was able to have access to these users and passwords by subscribing to the SSL and HTTP Authentication test feed on the silverorange project with Bloglines. I created two Bloglines profiles: one that the profile (Jim) and his blogroll are public and another (Todd) that will check the blogroll of the first account. The scenario goes like this:

1. Jim subscribes to a new SSL and HTTP Authentication protected feed with Bloglines. His profile is public and he does not know the consequences of what he is doing. The address he subscribe to is:

https://testuser:testpass@secure3.silverorange.com/rsstest/
httpauth/rss_with_ssl_and_auth.xml

2. Todd discovers the public profile of Jim and checks his blogroll. He is lured by an entry called “Test Feed (HTTP Auth, SSL)” he checks it, likes it and subscribes to it. Then Todd see this Bloglines page:



3. Todd check more closely to this Bloglines page and remark:



Todd just discovered the user and password of a “secure” web feed. Basically he was not able to see the complete URL of the feed because it is viewable in the Bloglines system as: http://www.bloglines.com/preview?siteid=1830560. However, by subscribing to it, Bloglines shows the complete URL of the feed to the subscribed users.

This is just a test I performed with a SSL and HTTP Authentication RSS test feed available on silverorange.

Now, think about the consequences of this situation when users subscribe to Gmail or any other “secure” web feed using SSL and HTTP Authentication? The problem is real and could have many undesired consequences.

The best thing to do is not using such feeds in online services like Bloglines. Even in stand alone software it could be unsafe. I pointed out a week ago why I do not like this strategy to handle the problem of secure web feeds. This is a beautiful example of the potential problems it can lead to. You can read my article on the problem and the proposal of a solution here: Secure Web Feed Protocol.

This experience is a good example of the potential security treats that can appears when more than one system start to interact together.

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

New applications of the Secure Web Feed Protocol – In Gmail and RSS Calendar

Published May 14th, 2005 in Blogging, Security and Web. 2 Comments Print This Post Print This Post

Five days ago I proposed my article: Secure Web Feed Protocol, to the PST05 conference. Two days after I came around 15 things you can do with RSS. Two of these applications got my attention:

  1. Collect your email from all your email accounts in your RSS reader
    Stay updated on someone’s schedule
  2. I thought: these ideas are wonderful! What about the security of these services? Could they use SWFP? There is what I found.

1. Google is supposed to have tested a RSS feed service for Gmail in their GoogleLabs in 2004. I can not confirm if the service is always available because I do not have any Gmail accounts and I can not sing-in for one. This service put new incoming messages of a Gmail account into a RSS feed. Then if you subscribe to that feed you will see your new Gmail messages directly into your web feed reader. What an excellent idea! However, I was surprised to found that they used SSL to create a secure channel between the feed and the feed reader.

In the section 5 of the SWFP article I explained why I think that using SSL to secure a web feed is not the good strategy to adopt. It is for this reason that I was surprised to discover that they tried to use SSL to secure the inbox web feeds. JC suspected that they did not create it for this purpose but for another application called Google Notifier. I think he is right.

I do not know what was the real purpose of this test but the result is the same: the idea of using RSS feeds to check your mail is interesting. However, using SSL does not seem to be the good strategy to adopt. Not all stand alone feed readers support SSL. If you do not wish to enter the login and password of the private feed each time you want to check for new messages, you will need to do something like that:

https://USERNAME:PASSWORD@gmail.google.com/gmail/feed/atom

This solution is even worse than not encrypting the web feed at all. With this string an intruder could sing-in into your account then check, delete or send messages with your Gmail account. It is far worse than only having access to the unencrypted inbox content.

This is a beautiful idea that could be handled by the Secure Web Feed Protocol. Now check out the second application of RSS feed that could use SWFP.

2. This time we are sharing our calendar with our friends and family using a service called RSS Calendar. When you add something to it all your friends and family will have access to your calendar’s changes. Is that not beautiful? Yeah it is. What about the security of this other service?

You could wish that the planet know that you are going to Mont Washington the 20 Mai 2005. But what if you only wish that your friends and family know it? There is no privacy feature in the service for the moment.

I think that the implementation of the Secure Web Feed Protocol could be really interesting in this case too. Only the people you choose would be able to read your calendar. I like the idea.

You are now thinking: how could the implementation of SWFP could be done in such services? The only thing that will change with what I discussed in the article is the way you will distribute the asymmetric keys

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

Why using SWFP rather than HTTP over SSL?

Published May 1st, 2005 in Blogging, Security and Web. 0 Comments Print This Post Print This Post

This legitimate question has been asked by Daniel Lemire after his reading of the SWF protocol. There is my answer to his question. I added it as the section 7 of my SWFP paper.

The question is hard to answer because it depends on many factors. I’ll compare the two methods together and try to show you the differences between the two protocols.

Usually SSL is used to authenticate the server to the client and, optionally, the client to the server. With the cost of authentication certificates (about 100£ each), the normal clients can’t afford these authentication certificates. It’s why SSL is mainly used to authenticate servers.

Our goal is especially to authenticate the readers to the server. It’s a reason why using SSL as a secure channel and an authentication protocol is not so useful: because the implementation cost is too high; like the revised version of SWFP at section 5.

This is the big difference between SWFP and SSL: their goals.

A solution could be to use HTTP over SSL (HTTPS) with HTTP Authentication. HTTPS would provide the secure channel and HTTP Authentication would provide the authentication mechanism. The problem with this solution is that some feed readers only implement HTTPS, others HTTP Authentication and few implement both. Another problem with this solution is that who says HTTP Authentication also says login and password. In SWFP the authentication is inherent to the system. It’s made with the public key of the legitimate reader present in the secure database of the server. The authentication steps of the reader to the server are transparent to him. I think that this transparency feature is an important one because it simplify the process and brings non-expert users to use it. Only the simpler things, in appearance of, are widely used.

Two types of feed readers are available: the web applications like Bloglines or the standalone software like Omea Reader. Both principles, HTTPS with HTTP Authentication and SWFP, could be implemented in standalone software and the implementation time, cost and difficulty are probably comparables. However, I think that SWFP would be much more easer to implement in web applications. Why? To use HTTPS with HTTP, the web applications would need to create the secure channel themselves with the feed’s server. By example, Bloglines itself would need to create the secure channel with each private feed server. I don’t think that it’s imaginable. However, with SWFP nothing like that would be necessary because the encrypted feed is viewable by anyone who needs it, even web applications. If I check the FeedBurner stats of my blog: 30% of my readers use Bloglines. I think that it’s considerable and that we need to take this fact in count.

Another problem with the HTTP Authentication solution is that it’s not an optimal solution to our problem. If a user is subscribed to many private feeds then he’ll need to enter, each time, a login and password to check the feeds. Personally I don’t think that this is viable. Think about the pain such a situation would engender… nobody would subscribe to such feeds.

Finally one of the beauties of web feeds is that you can archive them for future readings. The problem with the HTTPS solution is that you didn’t really have the choice to archive the encrypted or the unencrypted content. But such a choice is possible with SWFP.

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

SWFP: Secure Web Feed Protocol – A protocol to ensure a secure channel to web feeds

Published April 30th, 2005 in Blogging, Security and Web. 0 Comments Print This Post Print This Post

The last weekend an idea passed through my mind: “It seems that more companies are using content syndication technologies to broadcast their news or information to their employees”. Then I started to write a protocol to take this fact in count. It’s called: SWFP, Secure Web Feed Protocol.

“SWF is a protocol to ensure the secure broadcasting of web feeds’ content over a local network or the Internet. The protocol ensures the encryption of the feeds and the distribution of their encryption symmetric keys.”

It was supposed to be the draft of an idea, something to post here. Finally it revealed to be an article of 12 pages. I worked on it this week and came with this first draft:


View: SWFP: Secure Web Feed Protocol [PDF file]

If you have any question about this paper, don’t hesitate to contact me. If you find flaws in the protocol or modifications to suggest send them to me, they’ll be warmly welcome. I also invite you to leave your comments about this paper here, on this post.

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
465

Categories

Latest blog posts

Recent comments

Follow

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

Join 18 other followers:

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




RSS
465