I have website w1 written in rails using auhtlogic for authentication and w2 in PHP(say), I want w2 to access session information stored by w2 and login user into w2 and also retrieve user_id from session.
By default, Rack (which Rails uses to manage its sessions) stores session information in cookies by marshalling the session hash (see here), which results in a string that is specific to Ruby. It would be extremely difficult to use PHP to deserialize this information.
If you're dead set on doing this, you're going to have to handle the session serialization yourself. I think a full solution is outside the scope of a single question on SO, but a few pointers:
It would be wise to store only a session id in the cookie, and then keep the actual session data in a database that would be accessible from both the PHP and Rails apps. If you really want to keep the session information in a cookie (or in another place like memcached, where you'd also have to serialize it), look into serialization strategies that work across languages, like MessagePack.
You'll want to do something to ensure that the cookie is not tampered with by the user. Rack uses HMAC, which is a good solution. I've never used PHP, but I'm sure they also have a library for it.
You probably already know this, but just in case: This is all assuming that your two apps are sharing the same domain name. If they're not, then your users' browsers won't share the cookie between the two apps, and there's not really anything you can do. For example, you could share sessions between railsapp.yourdomain.com and phpapp.yourdomain.com, but not railsapp.com and phpapp.com.
Good luck!
i tried a solution sometime ago that was more a hack, but for my propose it worked.
after login, i used to write the user's cookie in a file in a public directory and when this user tried to access the other server where he had to access too, my application on this second server, just had to "know how to access" the remote file stored in the first server and load this content as cookie. I did used CURL at that time.
Note that it introduce some security breaches, and probably your security will rely on "obscurity" - for example, the algorithm to mount the file name where the cookie is stored and how to access it and any external webserver configuration.. Said that, i think we could think as well use a shared memcached to store the cookies..
Have you considered using Open ID?
Related
A user logs in using default Laravel authentication, which puts an encrypted cookie in the browser, and saves the session in the database.
The user moves to a classic asp page, where I check the cookie value, get the hash, and call the laravel app back passing the session id hash.
Then I use that in laravel to see if there's an active session for that id, and if so I return true, so the user can be logged in, in classic asp.
On each page request in the classic app, I check the last_updated_time in the db and update it on each page. All logging in and out is done in laravel, and classic relies on the database to see if a session is active.
I would also call a public url to get sessions variables and add session variables using laravel, since it's all encrypted and using classic asp for this would be hard.
The only risk I see is session highjacking, but I don't think it's a higher risk than usual.
Is it important to lockdown the laravel URL I call to check if it's a valid session?
Am I missing a security hole here?
Is this method secure?
From what you've stated you probably haven't opened up any security holes. The session cookie is not itself encrypted on the users machine, but you are making sure it is encrypted between their machines and yours, as well as between each of your machines. You should make sure you've set the Secure Flag to help prevent the cookie being accidentally sent over traditional unencrypted transport (HTTP), but as stated, this doesn't effect storing the cookie itself.
That being said, you are essentially hijacking your own users sessions. While a hole might not be introduced now, you are potentially weakening the overall system, which could lead to hole in the future.
Is there a better way to do it?
This might well be a dumb question, but are you sure you need the session? If you're juggling credentials between servers, it sounds more like you want to use Access Tokens and scrap the session.
Using Access Tokens is similar to using sessions, but you need to make your services stateless. This means your no longer storing information about the logged in user any specific machine so you'll need to pull anything you need from the database every time they hit a server requiring that information.
This is a good thing in the long run as it's much easier to scale your services when you don't need to worry so much about where the session is and what's inside it.
OAuth 2.0 is widely used standard (Facebook, Twitter, Google), and was specifically designed to be easy to use. The RFC is complex, but there's a log of good guides out there don't worry.
The one slight down side (if you can call it that) to OAuth 2, is that it MUST happen over an encrypted connection. If your use case can not guarantee encryption over SSL or (preferably) TLS, then you should use OAuth 1.0 (WITH revision A) instead.
This is due to the fact that OAuth 2.0 exposes it's "secret" token in requests, where as OAuth 1.0 only ever uses it to provide a signature hash. If you take this route it's advisable to use someone else's library as the hash is very, specific.
Further Improvement
(Note: This section added after the answer was accepted)
One system I've been exploring recently is Json Web Tokens. These store information about the user to save each machine repeatedly looking it up in a database. Because the token is hashed with a secret, you can be sure that, so long as your secret isn't exposed, a valid token represents a successfully logged in user, without having to touch the database.
You should avoid putting anything too personal in the tokens if possible. If you must store private or secret information in the token, you can encrypt it, or you can use a reverse caching proxy to exchange the JWT for a traditional security token. This may initially seem to defeat the purpose, but it means some of your services may not need database access at all.
I'm no security expert but I don't see an issue with this. The packaged Laravel database session handler works the same way. The cookie contains a hash that references a record in the database. The session data is base64 encoded but that's neither here nor there. I think you could actually avoid rolling your own and just use Laravel's DatabaseSessionHandler.
Illuminate/Session/DatabaseSessionHandler
... I just read a little deeper into your question and noticed the part about the public URL to set and retrieve session data. I think this is a really bad idea. Mostly because it will provide an open door to the end user allowing them to read and write session data. This can only end badly.
Like I said above, the data is only base64 encoded so I believe you'll be able to parse, read and write that to your hearts content within asp.
Edit
Ok... I think this is the last edit. The data is php serialized and then base64 encoded. This question looks like it may help you to that end. If it doesn't and an API endpoint is the only way, find some way to block the end user from accessing it.
Aside from session-hijacking, no. This is the standard way applications interact on a internal basis. Of course there might be a better way to get at the data if you choose a different type of session store other than your database, Memcached for instance.
There are couple of things that can be done.
Make the channel HTTPS. It will make almost impossible to sniff on your transport layer.
Rather than making interactions with your cookie, you could use a JWT to get this task done. Which will help you to use the existing functionality in your system while connecting with ASP system as well. You can write a small REST web service which allows ASP to connect. You could use this lib. You can refer this article which will give you an idea how it should be done.
Please let me know if you need more information.
I have a question regarding usage of cookies for standard login purposes. Say my php script saves a cookie into a users computer each time he logs in. The cookie value is say "Mike" after his username at the website. Can that user somehow manipulate that cookie in his browser to change the value to say "Admin" so suddenly he has access to administration of the website?
If this could happen how to solve such security risk?
--
Additionally... What if someone was to copy cookies from my browser, either he would stare at my computer screen and copy cookies and values into his computer or such intruder could steal cookies from my browser via JavaScript.
How is that taken care of?
Yes, that is a security problem, which extends to any information provided by the client.
Cookies are stored on the user's machine. They can be modified in any way. In fact, the cookies can just be created on the fly and sent via several utilities for making HTTP requests. It isn't even a browser problem.
Never trust any data that comes from the client.
Yes, a user can manipulate cookies if they're stored on their computer.
Use a session.
A 'session' is the server-side storage of connection-relative information that is linked to the user through a variable which is passed back and forth, most often a cookie, however logically, anywhere will do if both your client and server can handle it.
This 'session' is often represented by an integer which the client and server both know.
The problem is, if another client has a session open on the server, we (as a client) could 'hi-jack' this session by replacing our given id with a random id until one is found. The server would now believe we are in fact the other use and could give us access to their private informatin.
For this reason, we have 'keys'. A key is a unique, often alphanumeric, code which is changed on each request-response pair with the server, ensuring that only those who have the latest key are able to gain access.
YES
They can manipulate, edit, modify, create and delete cookies.
You should only store a hash key that you use on the server to look up in a database anything that should be secure.
Yes, users can manipulate cookies. The best way to handle it is to not store user credentials in such a manner that they can gain admin access by changing their user name.
The specifics on how to do this are pretty deep, but a good start would be to just store the users's session identifier instead. That has its own issues, but won't let people break things quite so easily.
Cookies are clientside which means that they can be read, write and delete by the client. A cookie manager plugin makes it easier to change the cookie value.
http://www.ehow.com/how_7149468_edit-cookies-computer.html
Yes a user can easily manipulate the cookies by just going to cooking option which all popular browser provide
I'm not concerned with browser compatibility.
I want to know if I move my state from PHP Controlled ( Server-Side) sessions to the JavaScript Controlled ( Client - Side ) HTML 5 local storage will I gain or loose security.
I think that I would gain security because now instead of having the user identifier residing in a cookie, which is usually a file, or sql database that is easily accessible...it is not inside some sort of internal browser storage. + b.c. it is a newer technology I would hope that more security was designed into it.
Do I gain or loose security by moving from PHP Sessions to JavaScript Local Storage. ( This is for things like user id, page_id, etc, the current state that remains after a reload and longer if needed ).
I have a JavaScript solution I want to replace my PHP Sessions with. That is why I ask. I don't care about browser compatibility.
Here is an informative site on Local Storage. But Security was not mentioned.
Both types of local storage (localStorage and Cookies) use some sort of identifier which is obviously stored on the client.
Both use a hash mechanism to secure it from altering to another user.
Local Storage is more secure then cookies ( see here ).
And obviously you have to write the session protocols if you want to move your user identifier from cookies to localStorage.
Both can be stolen to fake being another user. Though less likely with localStorage.
And to make robust you need a fingerprinting technique that will help with above problem.
I have a JavaScript solution I want to replace my PHP Sessions with.
No. Do not do it. Sessions are stored in the server side. The cookie that is sent out to the browser is typically an identifier for that record. Session stores user-specific data. Almost anything stored on the client side can be easily modified by the user. So if the user modifies the session to point to another user, the security would no longer hold.
LocalStorage is NOT for storing sessions. Stick with PHP sessions, or any other session mechanism that is implemented on the server side.
Update
But the same security flaw is present...a user can login as one
person...fiddle with the session_id of the Session and become someone
else...fiddling with a session_id...equates to fiddling with who you
appear to be to the server ?...this would be the same as fiddling with
an encrypted user_id in local_storage.
No. Suppose I figure out the algorithm you are encrypting with. And I know of another user say UserB. I encrpyted his username using that algorithm. If I somehow overwrite my localStorage with that encrypted string, I am him now. That is not much possible practically. Think of it as there are 100 users and 128 byte-string is the identifier. Are you sure you would be able to fiddle with it and modify it into another record which exists in the table of sessions?
Local storage is best suited for data that you want to cache on the client in a (more permanent) way then with the regular browser cache. The only way it's "more secure" is if you want to allow the user to work with data that's never sent to the server.
If you're worried about session hijacking, the preferred solution would be to use https/ssl and encrypt all traffic between you and the client. There's a general overview of the problem and solutions on wikipedia (we'd need more information to give you anything much more specific than that, though).
You wouldn't gain or lose security as in most browsers all data set by sites are stored in the same folder
I need to build my own system for part of a computer security project without using php sessions (just cookies) and im just lost. All the tutorials ive found use sessions (for good reason) so I was wondering if anyone knew of a roll your own php user authentication tutorial.
You could basically implement something session like yourself.
This would include the following tasks:
generate a random session id for new users (or on login - based on the exact use...)
save it into a cookie
do save additional session inforamtion somewhere on the server together with the session id (e.g. in a database table)
on subsequent page accesses check the session id in the cookie versus the data on the webserver to identify users and grant access
However it should be mentioned that a cookie only based solution is never that good. If a client for example doesn't have cookies enabled it won't work at all. A possible solution for this is to send the session id as GET parameter with every internal link if cookies are not enabled.
Sessions would make it much easier. That being said, where are you getting stuck mate?
To get started using Cookies in PHP, check this out: http://www.w3schools.com/php/php_cookies.asp
You could either
implement your own Session handling as s1lence suggests (which might be exactly what the professor wants you to do) or
implement your own Session handling through appending the session id to the QueryString (making it work for non-cookie browsers) or
you could store the user/password pair in cookies (which would force you to reauthenticate the user for every request)
I wouldn't recommend the latter, but if it's all about avoiding the Session Mechanism it's an option I guess. And a last remark, if this doesn't have something to do with understanding why Session is important you should really question your teachers task.. ;)
You should not use cookie for such system in cause cookie are stored on the client side. And any one can change it. Sessions are stored on the server side and only you can change it (also other system users can change it if they have directory access or db access if you store sessions in db). If you strongly need to use cookie you can encrypt login/password can write to cookie, but the using of sessions is more safely.
I have a simple Ruby on rails application that I want to integrate with an existing php website. I only want that users who's been authenticated by the php application would have access to my Ruby on Rails application (it should appear to the user as the same website, in the same domain, though it can be a different sub-domain if I chose to)
What's the best way to do that?
Thanks for the help,
Li
The most common way to keep a user logged in is to store something like current_user_id:777 in the user's session. Therefore, the easyest way is to share the session between the Rails app and the PHP app. Then, you must use the same convention to store the identity of a logged in user.
A way to do this is to use memcached as the session support.
Problems with this approach: you could set/read the same session variable in the same time from both apps (but it can be avoided).
References:
Storing your php sessions using memcached
Usind memcache as rails session store
The easiest way is to make use of cookies. In the PHP application, this cookie gets set, and the RoR application can read it's value.
But with cookies you'll have to watch out for security, because the contents of the cookie can be set manually, and cookies can also be copied, which allows for stealing another persons cookie.
Another option could be a session which is stored in a database both applications can make use of. The advantage of this option is that the contents of the session is stored on the server, and it can't be altered. The only thing you would have to handle is to identify the user belonging to the cookie.