I have Cognos report that i want it when clicking on it's URI to get direct into it without requesting the username and password
any suggestion about methods that could be used ?, i have no problem to make the URI use default username and password but not sure how would be possible
Many Thanks!!
Try this
Create very special user. VERY limited.
Then add to your repors's link something like
&CAMNamespace=<Your Namespace>&CAMUsername=<Your user>&CAMPassword=<Password>
It's rather old method. May not work in modern Cognos
You should allow anonymous access to your server.
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 can prevent users opening BIRT report from website that I built. But considering the report's link still in browser's history, any user from this computer still able to open the report by calling the link from history, for instance.
How to prevent the link of BIRT's report stays in the browser, after user close the report? So the only way to open the report is from the website.
Or maybe someone has other better method to achieve the same goal? Like showing a user name and password in BIRT, before user can use the report parameter?
Unless the whole session is encrypted using https, letting the use enter a password in the browser and submit it to the server as suggested by James is a security risk.
The short answer is: Don't use the BIRT servlet directly.
You could use the commercial iHub which probably has an infrastructure for user access control.
If you are using open source BIRT, generate the BIRT Report on the server side as a file (or OutputStream), then return that file to the client under control of your application.
For more details, search the internet for "Integrating BIRT".
If your application isn't written in Java or you don't have enough control/knowledge to do it directly in the application, you could use a "one-time token" approach like this:
Within the application,
generate a random and unique token (it must not be predictable by knowing other tokens)
generate the BIRT report as a file (say, PDF), where the file Name contains the token.
return a "download link" to the user, which links to a simple servlet (see below),
giving the token as part of the URL (e.g. ?token=xxxx)
The servlet:
checks if a token is given in the URL
checks to see if a PDF-file with the filename matching the token exists
if the file exists, return it to the client in the HTTP body and then delete it.
That way, the token is used a one-time key: You can download the BIRT report exactly once if you know the token. This is all done directly from the browser and the token is consumed and therefore useless afterwards
The easiest way to use a password parameter.
select <feilds>
Where 'password' = ?
Use a text box parameter, and when the user runs the report they enter "password" in the text box or the SQL does not return results.
SQL is not case sensitive so, your password would not be case sensitive. Also this is a very low security measure. It is only appropriate to prevent casual access.
JavaScript is case sensitive, so you could write something (like a filter on the query) where your Pa$$worD is in a JavaScrip variable and compare to that for case sensitivity.
Open source BIRT is not intended to provide "Secure" access to data. If you must provide real security of the data, you need to do it before the client has access to BIRT.
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.
If a user attempts to login to my site (username and password), but fails, should I display what field(s) were incorrect? Or, should I simply state that their credentials were invalid?
If I am dealing with a legitimate user, it would be more helpful to show them what fields were incorrect. But, if an illegitimate user is attempting to breach login, it would be more secure to only display that credentials were invalid.
So, I'm wondering if there is an established answer to this question. Are there any known best-practices for dealing with this issue? Or, is it a matter of taking the known pros and cons and deciding based upon the sensitivity of the site?
By default the best practice is to respond that the combination of username / password was not correct. This is considered best practice for public facing logins. If you are dealing with an intranet site you may be able to provide more information.
If you were to respond that the username was correct but the password was wrong you are allowing malicious users to know they have a valid username and from there go on to guess the password.
After having numerous "ethical hacks" performed on sites I've worked on the recommendation has always been display as little as possible. So, if either user name or password fails just display something like "Login failed".
I think that if a user got either wrong, that can mean he got the other wrong as well, and so you should tell him to "recheck everything".
Also, if you'll notify the user either username or password was wrong, meaning the other was right, if he's a malicious user, you're helping him.
Comcast has changed their login process so it happens in two steps. Instead of two input boxes for username and password, you submit your username first. Then on a second page you enter your password.
https://www.comcast.com/Customers/CustomerCentral.cspx
Due to some recent security
improvements, we now require you to
enter your user name and password in
two separate steps.
What could the security improvement possibly be in this system? If anything it seems less secure since you can confirm the existence of a username independently from it's password.
Any ideas on what they're accomplishing here?
My guess would be that they are targetting specific phishing/keylogging software which is "used to" finding all the login information on the same page. It's making the job of some malicious software a little harder.
If you use the "automatically fill in my forms" feature of many browsers, this will also separate the login information into two separate entries in the browser's data store, again making things just a little harder for any software which might try to exploit this feature.
Not sure if Comcast is doing the same thing, but I know a lot of bank websites I use lately started doing the following:
Prompt you for your username
Look up an image and a string that you specified at your account creation.
Display that image + string along with the password box.
The stated goal is so that, if you as a user notice that the image and string don't match what you picked when you created the account, you get suspicious and don't enter your password.
What is the benefit here? I don't see any either, as an attacker's script can just look up the image and string from the real login page. Maybe it makes dumb people feel more safe.
It is strange, on the password page they require your email and password, not the user name.
The user name is not a secret, as you use it in your mail address probably....
They still allow you to "stay signed in" ...
So Actually, I don't think there is a real security benefit
You can get directly to the 2nd login page if you bookmark it....
Simply so when you login to more secure areas of my account, you need to reenter your password instead of use the remember-me function, so if someone gets on the computer, all they can do is access email from a normal session. Yahoo does this also.