new to play,
I noticed in tutorial and online documentation that play's secure model
uses Security.connected() method to get current connected user.
my question is, how does it work ? how can play know who sent the last request ?
does it use a cookie ?
if so, copying this cookie would allow me to use different computers for viewing page ?
Yes, Play use cookie to get the user information. The cookie itself is encrypted. Not sure if copy it to another computer allow you to view the page. But I think this is not a security leak. Say, if you have a secure word document, and you copy it to another computer, it will allow the user on that computer to view your doc.
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.
There is an application that we are using it both on XPiNC and browsers.
Before you can access the application, you must log-in with your user.id from lotus notes. The problem is there are several login msgboxes ( where you must again log in with your username and passwords ) saying:
The server says /xsp/.ibmxspres/dojoroot-1.8.1/dojo.
or
The server says /xsp/.ibmxspres/.mini/dojo/.en-us.
or
The server says /xsp/.ibmxspres/.mini/css.
or
The server says /xsp/.ibmxspres/.extlib/icons.
and so on. Even when I just hit F5 when I'm logged on in application ( there is, also, a computed field which displays the username ) those type of messages are being displayed.
What should I do as a developer? Or there must be some settings at the server?
I have the following ACL rights:
ACL: User type: Person and Access: Manager.
Effective access: all the checkboxes are checked except Full Access Administrator
Thanks for your time!
Ok, this should be straight out of the box ;-)
What I find strange is that the ressources you seem to be asked for access to use are some of the "built in" ressources (Dojo, css, etc.) in XPages...???
So first thing is really to test that this has nothing to do with your application:
Create a new application
Set a proper ACL that will force you to log in (Default reader or higher, a person called "Anonymous" no access)
Create a simple XPage and open it from the browser
What happens?
If everything works, then you need to add some elements that use the ressources (css, Dojo, etc.). Then what happens?
I guess you will see the same problems... If so, you need to have a look at the way you have set up your server for web access. Are you using internet sites? Do you use basic or session based authentication?
What does the ACL of your application look like?
What you experience could be caused by "realms" i.e. the "path" to which you log in. A simple example:
If you are required to log in to access the ressource /path/db.nsf/view/doc1?openDocument then your realm will be "/path/db.nsf/view/" - if then you try to create a document using /path/db.nsf/newDoc.xsp then you could be asked for access to the realm "/path/db.nsf/".
I must admit that I haven't seen these issues for quite a while - but that may be due to the fact that I control access to the database as a whole - if users need access to something inside the database I implement it using "public access". But first, let us hear a little more about your findings before we chase it as a realm issue ;-)
EDIT:
Ok, so you are using basic authentication. There are lots of good reasons to use session based authentication instead. However, that does not explain your problem. What OS are you using? An OS with file access in the file structure? Could it be that the user running Domino does not have access to the ressources? Have any (file) restrictions to these directories been set up? You really should not be prompted to login for these ressources....
Did you try another "new" application?
/John
Switch to session based authentication. The multiple prompts point to BASIC where you can't logout unless you close the browser
I am working on a financial web application.
There is a client requirement that if user is logged in and already browsing the app. If he copies and pastes the browser url to another window. In another window, the user should get logged out.
I know http is stateless and there is no inbuilt browser mechanism (cookies etc) to solve it, this needs to be implemented by programming only. I guess people have already solved this problem. Do you know know possible solution to solve this issue?
Sadly, there is no solution.
The browser keeps the cookies and all of the user informations for all the Tabs & Windows you open. It will clear the datas (like cookies that ask to be removed after the session) as soon as you close ALL tabs and windows of your browser. Note that if the user use another browser, the behaviour your want will be respected — browsers dnn't (yet ?) share this kind of informations.
It is simply not possible to solve the problem with code, and you'll have to find work-around.
As a researcher, I've seen one of these solutions : de-auth the user on the HTTP_REFERER (Apache Env. Variable). As soon as the referer was not the application itself (except for the login form), the user was de-authed. But take care of it : the Referer is an info sent by the browser. And no information sent by the browser should be trusted :). The advice remains, if only you want to use Javascript. You'll find someone to use a JS-disabled-browser to bypass your verification.
That's why Application Development is not yet dead ;)
Cheers.
K.
wkhtmltopdf allows to make a screenshot of a browser view with a webkit browser.
I have a Symfony 1.4 application that requires login, which I would like to use wkhtmltopdf to create a "print this page" function.
How can I securely facilitate this. I'm thinking of creating a one-off token on each screen for the print button that allows wkhtmltopdf to login without using the password of the user.
Any suggestions for how to structure this?
We'vbe come to the conclusion to use the built in "keep me logged in" functionality for this problem.
Would you consider a different printing framework ?
What about jquery plugin (e.g. https://github.com/ianoxley/jqueryprintpage#readme) ?
That way you won't have to allow access to the restricted area from outside the session.
If you still want to use wkhtmltopdf, you can easily create an action that receives a url and a user_id and creates a unique token, I might save this token in your DB or in a Key-Value cache (depends what is your system architecture). I wouldn't create the unique token in advance, I think its better creating it on demand (When your user is asking a print).
You have couple of options in order to enable printing in secured actions,
1) Create a custom security filter. In the filter, in addition to authenticated request, you have to allow requests that contain "token" parameter with right combination of url and user
2) Change the action to unsecured. If you don't want the change the security filter, you would have to change each action to "unsecured" and create a function that verifies if either the request is authenticated or it has a proper token parameter.
It would be smart to remove each token after you used it once to make it even harder to guess a token.
In addition you might want to create a periodic worker that clears old tokens that were never in use.
Even though you already decided on an approach, I would still like to add one more alternate option that might help others viewing this issue.
Another alternate route might be to grab the current source of the page being viewed and post that into your printer backend using something like
$.post("/printer", document.documentElement.outerHTML);
This way you can also preprocess the HTML in an easy way. Your backed could first store the HTML and then parse it to for example convert images or perhaps remove some parts of the page that will not be used when printing.
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