I am building a Sharepoint web part that will be used by all users, but can only be modified by admins. The web part connects to a web service which needs credentials. I hard coded credentials in the web part's code.
query.Credentials = new System.Net.NetworkCredential("username", "password", "domain");
query is an instance of the web service class
This may not be a good approach. In regard with security, the source code of the web apart is available to people who are not allowed to see the credentials.
In normal ASP.net applications, credentials can be written into web.config and encrypted. A web part doesn't have a .config file associated. There is a application-level .config file for the whole sharepoint site, but I don't want to modify it for a single webpart. I wonder if there is a webpart-specific way to solve the credential problem? Say we provide a WebBrowsable property of that web part so that privileged users can modify credentials. If this is desirable, how should I make the property displayed in a password ("***") rather than in plain text?
Thanks.
Create custom toolpart, check for condition like SPWeb.UserIsWebAdmin, if so, render fields needed for credentials (input textbox, masked textbox etc).
Read the user name and password out of an encrypted section of the configuration file. See https://web.archive.org/web/1/http://blogs.techrepublic%2ecom%2ecom/programming-and-development/?p=448 for more info on programmatic uses.
In addition to the above, you can store the credentials (securely, of course) on the server, be it config file symlinked in, a file in a known location (e.g., common directory) or even (not recommended) in the environment.
A bonus of this method is it allows dev/test/whatever to have different credentials and not interfere with production while developing/testing/etc.
If you want the web part to be independent of other parts of the system, a property is the simplest option. The main downside to that approach is that you can't set permissions for individual properties, so users will see it. You could have the value be a hash (calculated elsewhere by the admin before adding the web part) but I don't think I'd call that a good solution.
If you want to provide ui to admins only, you should create a custom settings page (CustomAction + layouts page) which saves the credentials in a site property, possibly encrypted so that they can only be read by your custom code in the web part and settings page.
Related
It's not a common question, but I wonder if any tricks or upcoming standards exist.
Belows are a flow and what I want to implement.
Web application loaded from server-side
Client-side script loads some secure contents (not from #1) that need to be protected from web application provider. It could be shown to a user visually.
Web application provider knows where are the secure contents (in Dom path) and possibly may try to catch it by putting a script
However the secure contents shouldn't be hijacked from servers (even from the same origin) or from external application (even from developer tools if possible)
EDIT:
For better understanding, it's for use case where web application doesn't hold user data in their DB but loads the data from somewhere else. In case, I need to protect the data from web application, which is uncommon in regular web application.
You should use a content security policy (CSP) which would enable the browser to deny injection attacks. These can be a little tricky to setup correctly so I would use Report URI to help you get it going. The trick is to use report only mode first until you have validated the settings then switch to enforce.
I'm currently creating a simple script that is essentially just a form that people can fill out an upload a couple of files.
When I click Deploy as a Web App, one of the form items asks "Execute the app as". One of the options is: Me (example#gmail.com)
Is this safe?
Does that mean anyone who has a link to the script essentially becomes logged in to my account?
Are there security risks to this?
One of the most important issues is, who has access to the Apps Script file. The file sharing settings are set totally differently than the web app deployment settings. You can have the Apps Script file SHARED settings, set to not being shared with anyone, and still have anyone be able to access the web app. So, access to the web app, and access to the file are two different things. That's a key point to understand.
The Execute the app as me, is not inherently unsecure. It doesn't log someone into your account. IF you somehow configured your app to give broad access to your account, which you can do, that's obviously a potential security hole. You should set scopes manually in the appsscript.json manifest file that are more restricted. For example, restricted scopes to your Gmail and Drive if the Web App sends an email, or accesses your Google Drive. You can restrict the email scope to only be able to send an email, and restrict the Drive scope to only be able to access files and folders that the script created, or that the user picked with the Google file picker. You can restrict access to only the current spreadsheet, instead of all your spreadsheets.
Are there potential security holes? Yes. But there aren't any security holes that you wouldn't have with any web app. So, it's really dependent upon the practices you use.
Don't use/store settings/parameters in client side HTML, that directly cause a server function to perform an action that you don't want anyone to be able to execute.
How secure your app is depends on some simple practices.
Don't store settings or information in HTML that could cause a security hole. Passwords is the obvious example. Don't put names of files in HTML code. Don't pass settings or parameters in Client side calls to the server that are obviously a direct link to a server function that has broad access to your account.
You can put an underbar at the end of server side function names so that a user can't know the names of your server function.
https://developers.google.com/apps-script/guides/html/communication#private_functions
Have a main server function that then calls a private function, that in turn branches to other functions. So the user will never know the name of the function that is ultimately doing all the real work.
If someone else has access to modify your Script, then yes, he can re-publish the app that will have access to whatever you previously authorized, but won't have new authorizations. Eg, if you used only SpreadsheetApp as your first code and authorized it, someone who has access to modify this script you already published can open all your Spreadsheets and erase them, but wont be able to touch the Docs.
Someone with the published app URL will have none of this, it will only run the scripts you/shared scripters published.
I use "Me"/"Anyone Even Anonymous" quite frequently, published dozens of apps and never had any issue.
We plan to implement a company-internal portal with Liferay 6.2. Since many of the team members are not within the company's network, the access has to be allowed from the internet.
Now I see a big problem with the Guest role, since it 1) can access Guest-viewable content without login and 2) this is the default selection when for example uploading a document.
What I really need, is that only the login page is generally viewable, but all other sites and content is only visible to logged-in users, without the need to explicitely assign the permissions for each item correctly.
So the question is, can I prevent the guest role to access anything beyond the login page, so to say eliminate it from everything within the portal?
Update:
It was proposed to use only private pages. While this might work, it implies as far as I know, that each user has to be member of the site. But then it's no longer possible to have a site structure with different users participating in different sites and still be able to view public infomation (meaning public for all logged-in users) - or am I wrong?
Update 2:
I agree to a solution where one has to prevent the assignments to the guest role programmatically, via hook or via deeper changes in liferay. Yet, I like to double-check that administrative and think of a periodic database job or program using the API which check for relations to the guest role which came in around the hook or by wrong permission settings of a user and delete them again. How could that be done?
When a document is uploaded through a private page, the permissions actually default to be not accessible to "Guest". This is guaranteed easiest if you don't have any public pages.
Also, you can access the API and change the default permissions once a document gets uploaded (no need to override core Liferay functionality like defaults): Just write a service hook that overrides the upload of a document with a version that sets the permissions you want right after a document has been uploaded. This will catch all other upload attempts, e.g. through services, Webdav etc.
Edit (after your comment): Added the link to Dev Guide. The actual use of the API is a bit too much to update this answer with on the fly. You might want to look at old examples like sevencogs (part 2) to get used to the actual API, but DevGuide will describe how to write the plugin in the first place.
You could still use the public pages etc. and disable the guest's VIEW permission on every element but the login page and it's resources.
Now, as you have already noticed, the fact that, by default, whenever creating any content the Guest gets the VIEW permission is a substantial problem.
I'd suggest to simply override the <guest-defaults> values in Liferay's core portlets' resource permission files (the ones in ROOT/WEB-INF/classes/resource-actions/) to remove these default values. If it's not clear to you on how to do it, see, e.g., this forum topic: https://www.liferay.com/community/forums/-/message_boards/message/486154 .
All you need to do is delete all public pages. Every page that you create should be private. Don't worry about login page, reset password and self-registration (if allowed), by default they are public.
Hope this helps.
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
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