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.
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.
Hello fellow developers
I have obviously under estimated a thing when developing my first complex web site, where user creation and login is required.
It appears that cookies can be edited and modified by the user logged in, by using some developer tools i.e. in Google Chrome. That, I never gave a thought.
So, here is my issue.
When the user is logged in, I store the user name in a cookie.
If username-cookie is not blank, and I can find a user file with that name, the user is logged in, per se. Otherwise, no user is logged in.
When the user logs out, I simply expires the cookie, which works fine.
Now, the problem is, that a user obviously can edit the content of a cookie, outside the web application, or with javascript.
What would be the correct approach here to ensure, that the username cookie is not compromised in any way, other by my web application?
Making them read-only is not possible, I assume. Encrypting the cookie and then decrypting might work, I guess. Then, the cookie would be nonsense to the user, and if modified, result in a logout, as no valid username can be found upon decrypting the edited cookie.
I have stalked Googles cookies, and it appears that there are a lot of xxID cookies, which contains garbage. Does that mean, that encrypting/decrypting is the only way to make it work? I also considered some kind of login-ticket, but that would require a table lookup every time a user interacts with my web page.
Can anyone give me a hint as to what would be the correct approach?
Thanks in advance
Best regards,
Karsten Heitmann
You should look up session management for the language you are using.
The traditional approach is that when a user logs on, your application generates a long, cryptographically random token called the "session id" and sets that into a cookie. It stores data like who is logged in on the server side identified by the random value, so when a logged on user comes back, the browser sends the cookie with the random session id and the application can look up session data on the server side. This way an attacker has no way to guess a valid session id for a logged on user, assuming the session id is cryptographically random and long enough (which more precisely means it has enough entropy). Logging out means deleting the session data on the server side, and also removing the cookie, but that is not the most important part - the session will be invalid anyway.
Note that you should not code this yourself. You did not mention the language and environment you are developing in, but session management is rather tricky business if you want to secure it, and it is already provided by most languages / frameworks.
Just for curiosity, the encryption approach you mention is by the way a valid one. Some frameworks actually do that, but you should not attempt to code that either, because it is very easy to get it wrong, lots of things need to be taken care of to make it secure enough. Unfortunately an answer here is not the right format to go into details I'm afraid.
Btw you mention looking at Google. They use their own single sign-on solution, it is very complex compared to simple session management, so it's probably not the best example for you to look at. Find simple websites, most of those work the traditional way.
I want to password protect a web page. I'm wondering if anyone would critique my approach.
An anonymous user would go to the page and a modal would open up asking the user to enter a password. I would of course not display any content at the back in case anyone decides to be clever and display:none; the modal.
Once the user enters the password, I would redirect and save a randomly generated token as a cookie and check for that so that user wouldn't have to keep entering the password.
Just wondering if there are any security issues here aside from a personal physically accessing the computer and also if there would be any improvements that could be made.
I know I'm still being a little vague on some details, so let me know if there's anything important that I left out in regards to exact implementation.
Even though what you describe might work, in general it's a bad idea to implement your own security. Even if you use https to prevent sniffing of the token, someone might find that your random numbers are not really random and be able to guess the next number.
You will be better off using one of the security feature that comes with the framework in which you are building your application. Most frameworks support something like forms-based authentication. It might even support claims-based authN with security tokens.
As you're not mentioning what framework you're using, I can't recommend anything.
It's a horrible idea. The password as a cookie would be transmitted in the clear in every HTTP request. There are plenty of examples of how to do this correctly. I am not going to elaborate because this question is very likely going to be flagged. NEVER save a password anywhere. The first thing to do with a submitted password is compute a hash value. The hash becomes the password.
I am developing a small website with a custom admin page that allow to simply modify and insert contents.
This is how it works: in domain.com/admin there is a page with an autentication form. Of course the only user that know the password is the admin (not me, my client). If the password is right, server send an html page that allow to modify the content of the website. How? Dynamic information are stored in a mongodb database setted up on localhost of server. So, using simple CRUD operation like insert, update and remove, the content of the website will change. In the clientside i simply do same "post" requests to the server, wich makes CRUD operations.
I need to make this system safe. Do i need https for autentication? Do you think that a simple autentication password for admin would be enougth? And what about the way i check if the passwords matches? I was thinking to store the admin password in the database (that have a password too) but maybe is unuseful. i could simply compare two strings cause the password is only one, there are no other registered users different by admin. But i'm not sure, this seems unsafe :D Any idea for the best way to do it??
I'm using node js (NO express). I have a dedicated root VPS.
https will be better, and you can just keep the salt and hash code in database instead of keeping the password directly. likely most of website have a feature to reset password not find the password, they don't keep password directly in file. when someone know the salt and hash code , they can't reverse the password.
I've implemented an login on a site (didnt use asp.net default). When a user logged in I save his ip in the db. If he doesnt doing anything in X min his ip get deleted. Whenever a user trying to enter a page that is restricted I check if his ip is on the db. If so he can continue.
The problem is that if the logged on user is on a wifi network or any other shared network, all the other users will have the same ip, and thats not good. How can I overcome this problem? Is cookies the best answer?
How is the user logging in? Username/Password? I'm assuming the password is stored as a salted hash in the database, so why not pass a cookie back with the user's username and hashed password? Whenever they try and access a restricted area check that username/password hash against your database. Make sure to sanatize the cookie values before checking them against your database to prevent injection. Or, depending on the language this is in, you could use session tracking.
I'm assuming by the tags that you're using WebLogic Server for your solution, although your comment about ASP.net makes me wonder. (although no ASP tags set for the question?)
The short answer is that you're making life harder than it needs to be - if I understand your problem correctly - that you want an idle user's session to be timed out after a certain period of inactivity for security reasons - then you can do this via application configuration with the session-timeout parameter:
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/webapp/web_xml.html#1017275
Wherever possible when security's involved, I always prefer to avoid rolling my own solution. Just not smart enough to trust it. :-)
Apologies if I'm off in my understanding here.