I am using Expression Engine in part of a site I am developing and other parts are just using my own PHP. My question is how can I tell who the user is logged in as on a non-EE page? I have access to the EE cookies and the EE database but couldn't find a way to use these values to figure out who the user is. I have a list of all the cookie keys/values at: http://andrewgjohnson.com/cookies.html
the exp_uniqueid cookie value should match the unique_id field in the exp_members table.
Related
I have received a request, and I cannot find a secure way to implement it. If you know a secure way to do this, please let me know.
I'm developing www.abcd.com with ASP.NET MVC. The client already has a xyz.abcd.com domain with an authentication system. They want me to create a page on www.abcd.com, where user can enter a username and password, then by hitting the login button, I open a xyz.abcd.com/login page in a new window and populate username and password with what the user has typed in my page.
I cannot find a way to do it from server-side.
If I want to do it on the client-side, I think it's against "same-origin policy" and also, I'm not sure running both www.abcd.com and xyz.abcd.com on SSL is secure enough to do such a thing.
Could you please let me know, if there is a secure solution?
I think the subdomain application (on xyz.abcd.com) should have explicit support for this to be possible, like for example populating its fields from request parameters or maybe a cookie (though I would rather not do that, especially not in case of the password).
If the subdomain application does not support this, I think you can't populate its fields, not even from abcd.com, let alone from another domain.
Please note that it would be a vulnerability (and against the best practice of course) to auto-populate the password field, which should even be set autocomplete="off" to prevent even the browser itself from filling it in.
Without knowing the context to these applications, I suspect you need some kind of a single sign-on to achieve your real goal.
I am developing a social network and I would like to know if in the profile page of a user I could put the user id stored in database as a parameter in the url or is it a bad idea in terms of security?
I want the url to be bookmarkable. Should I put another thing instead of the user id?
In terms of security there's no problem in putting the user id in a url. For example StackOverflow does it already: https://stackoverflow.com/users/3477044/aliuk
What's important is to verify that the currently authenticated user is allowed to access this url and take actions on its behalf.
most socialnetwork i've been using, use username as url not id, of course it also affects seo, since u have "pretty url".
Security is really depend on how you write your code, say there is a page to edit-profile, if you put on your code something like:
UPDATE .. SET .. WHERE id = $_GET['id']
no question it's dangerous, you should check every user action, like posting/editing profile, etc. who is login, not what's the id on current url
It is secure if you secure your website against sql injection.
But if breach happens all users are vunerable. Only thing that hacker needs to do is find the user profile get his id. Copy output of sql injection. Go to text editor. Press ctrl - f and search for user id.
I was recently told that using mongodb _id fields in a URL is unsafe. I was wondering if that's true.
My site is restricted to registered users, and every user has their URL endpoints which contains an id from mongo. It's the typical mongodb _id field - a SHA1. AFAIK, the id is unguessable, and even if someone hits upon someone else's id, session based authentication in my app doesn't allow access. No one has direct database access other than the application itself.
I'm curious to know if there's anything I'm missing.
Edit: Clarified question. (mongodb ObjectIDs aren't SHA1s)
_id field from MongoDB is (by default) of type ObjectID. It is not a SHA1.
And its string representation (like 4ed7cbfd1d96406ca0000015 is, for sure, URL-safe. I use it everywhere.
I mean, it is safe to expose it everywhere where you would put a regular int identifier (/products/3 or /users/42 or whatever).
On your site you should check if a user is logged in and if he has access to given URL. You should not blindly allow users to visit URLs with ObjectIDs in them, just because they (ids) are not easy to guess (they're easier than SHA1, though)
It's rather good idea to use seemingly random string as _id (or create guid) in URL rather than number. If you have public API, user/1001, user/20032 its just begging for hackers to guess next number and get onto random user info.
So how do you maintain the form security about posting data to different page problem? For instance you have a member and he/she tries to change the personal settings and you redirected member to
www.domain.com/member/change/member_id
member changed the values and post the data to another page by changing the action with firebug or something else. For instance
www.domain.com/member/change/member_id_2
How do you handle this problem without using sessions?
This problem arises when there are no server side validations!
So, the solution is to have server side validations.
Why not use Session state? It's designed for that.
Alternatively use cookies or URL's with unique session style ID embedded in it, which allows you to tie it back to a specific user.
How do you handle members without session?
Before modifying anything, check if the current user has the right to do so. For example, if you're user #1 and your details are at /members/change/1, you post to the same url, and with firebug you change the form to point to /members/change/2. When processing the form, you have to check if the userid in the form is the current user's id, and if not, display an error.
You could crypt the identity information (member_id) and add it as parameter or url path. When the request is posted to the member_id form, you can verify that the crypted member_id (which is part of the request) matches the member_id.
Here's the scenario:
You have two seperate websites that exist in different environments (I.E. different databases, different web servers/domains)
You have full control over the code for both sites, but from the above point, they can not directly communicate with each other's database
You must transfer user from site A to site B securely
What is the best way to implement this? Simply sending the user identifier between the sites via query string wouldn't be secure, even if encrypted, since someone else could obtain the URL. It seems like the standard solution is to pass the user identifier along with another temporary key that web site A created, and web site B knows about. If this is the case, what's the proper way of securely setting up the system with the temporary key?
Thanks!
I am doing something like this. The best thing I can think of right now is passing a HASH of the user ID, or if that makes you worry, the hash of some other user data.
If yuo want temporary keys(I might do something like this too), how about setting up a web service on A that B can call to to get the user ID based on the temporary key. This way it's a totally separate call, and can be secured.
Take a look at "Pass-through Authentication," its a concept that allows a user's identity to be passed from one system to another.
Additionally, another idea that you may want to try is to create a secure token that does not expose the user's information and pass it on. However, this requires both systems to have similar data to verify the token. As the other answer suggested, hashes are very good uses to create non-descriptive bits about sensitive information.
Write a web-service call over HTTPS, at both ends, to retrieve the users details, and that only works for a specific login-pair. Problem solved. You need to make the login-id's at both ends uniform or use single sign on cookies. More details in the paper by Vipin Samar: "Single Sign on Cookies for Web Applications".
They can't get the URL/Passwords unless they go into the application code at one of the servers.
You need to pass information between Site A and Site B, but you don't need to make the user the conduit for that information.
Site B could have a web-service that allows Site A to create a session for the user. In this design the interaction would go as follows:
User clicks button on Site A
Site A calls web-service on Site B which passes a temporary login URL back to Site A
Site A redirects user to the temporary URL on Site B