globalStorage, how it could become a problem.

With Javascript 1.7 being implemented in Firefox 2.0, new features are now available to developers. One of these features is session and persistent data storage on the client side using the new DOM Storage API. We have the ability to store session data, or persistent data, which is really cool from a developers point of few, something I will be making use of, and already have put to use in a project.

Now comes the problem for remotely hosted forum services like ProBoards / InvisionFree / insert other here. When you sign up for a forum, you are given a sub domain name like http://username.server.com or http://server.domain.com/user/. So for example if you register a ProBoards forum, you will get something like http://username.proboardsXX.com where XX is the server number. One server could have thousands of forums.

Throughout this I will be using ProBoards as an example, but the same problem exists for other hosting services most likely.

Now, when you set a session variable, it can only be accessed on the forum it is set, which is a good thing, so no danger there. But if we use the persistent API (global storage), we can set the global storage domain to the server (i.e proboards17.com), we can then store any information we want, good thing about this is we can store information and recall it next time the user visits, and this includes closing the browser, as the data is persistent. Cool right? Nope, not really, let me explain…

Lets say I have a forum on server 77, and someone is using a hack of mine from the database (Javascript code that gets placed in the header or footer), and they are also on server 77. The hack doesn’t even need to be in a remote JS file, it can just be a simple “Total visits to this forum” counter for the member, they wouldn’t know what the code really does, because what it would be doing, is storing the username and password in the storage object. Now let’s say that user visits my forum (also on server 77), I then have easy access to record that users username and password from the forum the hack was being used at, I could then send that data to a database to record it.

Isn’t a great deal that can be done to prevent it. Maybe there should be a global flag that can be only used once in the document, this flag could be set to 0 or 1 (false / true) and would be set in the head tag, as most hosting services only allow code inputting inside the body tag. So the flag would not be changeable else where in the document, thus preventing attacks.

Your thoughts?

Thursday, October 26th, 2006 JavaScript, Programming

8 Comments to globalStorage, how it could become a problem.

  1. Surely Firefox could do something like

    2. James on October 26th, 2006

  2. Some of your message get cut off? :P

    3. Peter on October 26th, 2006

  3. Poor James, losing his messae. :P

    That would be problematic, but why in the heck would you need to store the password? I can understand the username to make sure it’s the same user, or they have multiple people use the same computer, but why the password? (Just out of curiosity. I’m pretty sure you’re talking in theoretical sense.)

    Other then that, the storage could be pretty cool. I won’t use it until IE makes one similar to it… then I’ll just make an object to save time in my codes. :P

    4. Chris on October 26th, 2006

  4. Am not understand what you mean Chris.

    The globalStorage object would allow me to collect user information. If I want to gain access to the account I need to record the password. It would be an XSS attack.

    For example…

    Say someone used my code on their forum, and the server # was 88. I have a forum on 88 as well, so when they visit the forum using the code, the globalStorage object saves the credentials, and when that member visits my forum, I can check to see if username and password exists in the globalStorage object and then record them to a database.

    IE supports persistent data, have done since IE 5.5 I think.

    5. Peter on October 26th, 2006

  5. At PB, couldn’t you save pb_username? Or am I misunderstanding the information it saves….?

    6. Chris on October 27th, 2006

  6. If I wanted to collect the members credentials, then I would just storage the pb_username and then get the password from the cookie, or just get both from the cookie. I could just send the whole cookie to the object to be stored. Either way, you can store what you like in it.

    7. Peter on October 27th, 2006

  7. Grr.

    My message basically went along the lines of… i’m sure they could implement the same style security settings (subdomain only) as cookies, or have a locality=’subdomain’ /> included in the sess storage facility.

    And if this gets cut off i’m going to be annoyed =)

    8. James on October 27th, 2006

  8. You would think they would have done something like that. Ah well, it’s a cool feature, people will just need to be careful with what codes they use. As soon as I see any at ProBoards get submitted, then I shall put up a message to warn people.

    I don’t want to ban them completely, as some useful stuff can be done with it. I recently wrote a script to save persistent data for Firefox 2 and IE for something me and E are working on ;)

    9. Peter on October 27th, 2006

Leave a comment

What Am I Doing?

Search

 

Categories