views:

66

answers:

1

If I use mechanize, I can, for instance, create a new google analytics profile for a website. I do this by programmatically filling out the login form and storing the cookies in the database. Then, for at least until the cookie expires, I can access my analytics admin panel without having to enter my username and password again.

Assuming you can't create a new analytics profile any other way (with OpenAuth or any of that, I don't think it works for actually creating a new Google Analytics profile, the Analytics API is for viewing the data, but I need to create an new analytics profile), is storing the cookie in the database a bad thing?

If I do store the cookie in the database, it makes it super easy to programatically login to Google Analytics without the user ever having to go to the browser (maybe the app has functionality that says "user, you can schedule a hook that creates a new anaytics profile for each new domain you create, just enter your credentials once and we'll keep you logged in and safe"). Otherwise I have to keep transferring around emails and passwords which seems worse.

So is storing cookies in the database safe?

A: 

First and foremost this is a flawed approach because the authenticated session will eventually expire and your connection to Google will be broken. Further more you should be using the Google Analytics API.

However, STORING THE SESSION ID IN THE DATABASE IS INSECURE.

This Isn't a recognized vulnerability, at-least not that I know of. But it makes it much easier to attack your application. SQL Injection is very common and you should design your application to limit the impact posed by any given vulnerability. This is why passwords are hashed, because it delays the attacker from obtaining a full compromise. Storing session id's which can be used immediately makes SQL Injection vulnerability against your application more serious.

I am not sure what platform you are on, but I'll assume your using Linux because you care about security :). I recommend storing the username/password in a file. You should adjust the file's privileges such as chmod 700 file_name, and make sure the file is owned by your web server: chown apache:apache file_name. If you are using MySQL make sure you remove file_priv (File Privilges) from the ruby application's user account. File privilege is really nasty because it allows an attacker to read and write to files via sql injection.

Rook