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.
Related
I'm trying to implement a GET method with Express in my nodeJs application.
I'd like to do something like this in order to display user data :
router.get("/user/:idUser", (req, res) => {
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
How could I proceed ? I thought about using some encryption process to have something like :
/user/PdfgdfJFDGTfrfgdsf
Your question isn't really making sense. You don't want authentication, but you only want a user to be able to view their own data so nobody else can view it.
The ONLY way to solve that is by using some form of authentication. The user has to prove to the server that they are allowed to view that data before the user renders the page for them.
Yes, you could obscure the URL (make it some mostly unguessable string of characters), but it's not clear what problem that is solving. The user themselves won't be able to remember it or type it so it would probably have to be a link in a web page and if it's a link in an unauthenticated web page, then anyone can get to it - thus defeating the purpose.
There are cases where temporary links (often done for privileged downloads) such as what you mention /user/PdfgdfJFDGTfrfgdsf are sent via an authenticated channel (either an authenticated webpage or sent to an email address known to belong to an authenticated user) and these links contain some unique and hard to guess code. The user can then click on that link (in authenticated webpage or in email) and access that resource without further authentication. In that case, the knowledge of the code in the URL is serving as a form of proof of authentication. Because URLs may be logged in service providers or corporate infrastructure and thus not remain entirely private, this technique has its limitations and is typically only used for short term (download this resource in the next 10 minutes) type of uses, not a long term substitute for authentication and not used for things that demand real security. You don't explain enough of your use case to know whether this is practical for your situation or not.
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
That's an inconsistent statement. You say "user doesn't need to be authenticated in order to execute this code" and then you say "I don't want that anybody can execute this request with a user id of someone else.". You can't have both. The user is either required to prove authorization or they aren't. Pick one. It can't be both.
you can use jwt for this and a auth middleware for this
upon decoding jwt token, you can implement logic to check if the decodedToken.user_id (given that you add user_id when encode token payload) is equal to the :idUser in route (or any kind of logic you want) there.
lets say for example i have my website like that:
http://whatever.herokuapp.com/
and i don't want anyone to view it until he enter a password on the URL like that.
http://whatever.herokuapp.com/pw=1231fd1ffs
i am using angular for this project and i am connecting to some apis.
how i can do something like this.
this is what i am looking to do.
Do a GET request and give it the parameter as:
http://whatever.herokuapp.com/?pw=1231fd1ffs
Then, on server side you should check if the password is, in fact, correct and if it is just return the new web.
However, this is not really advisable. Anyone could access if they have the full link with the password. Instead of this you should do a form with a POST request asking for the password. Or even better, a users db so everyone would have his own password and third persons will not be allowed to log in.
After POST request just return the full web the same way you would do it with a GET
Using: PHP, Symfony 1.4, Doctrine, sfGuard
I have a site where the majority of pages could be cached as full HTML pages. But there is the traditional 'user account toolbar' that appears at the top right of most sites (shows the logged in username, logout link etc.)
This obviously prevents the page from being fully cached as HTML so I plan on outputting the page as standard HTML and adding in the username etc. after page load, via Javascript.
When the user logs in, I will create an extra cookie storing just the username. Javascript can then check if the cookie exists and create the account toolbar. The username will only be used for display purposes. In order to actually log in the users will have to go through the normal login page, using their password etc.
I've searched for blog posts etc on this but not found much. Can anyone identify any security or other concerns with this?
As long as the user name is only used for display purposes you should be golden. Alternatly you could use an XHR to grab the username from PHP's $_SESSION.
My concerns are that you'd be using the user name to authenticate that user. Or using the user name as a key to access your cache, where by changing the user name would give an attacker access to another's cache.
You should never, ever store anything sensitive in a cookie. To me, that includes usernames.
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