Page parameter (in Seam) or GET parameter (general) are often mentioned as a proper means to transfer information from one view to another. But obviously it is not a good idea to have sensitive data in the url, e.g //myserver/show.jsf?userId=12, since it is easy to manipulate these params and look at data someone is not permitted to look at.
So far I've been using what examples and literature show (couse until now was not important):
<s:link..>
<f:param value="#{user.id}" name="userId" />
</s:link>
in the JSF-file and in the according target page.xml
<param name="userId" value="#{userHome.userId}" />
I am interested in two things (still kind of new to Seam):
1) What different possible strategies of securing unpermitted access, to e.g. different user accounts, are you using, if you want to stick to page parameter? I'm sure some of you have been facing that challenge already. And what are the pros and cons of these strategies.
2) I want to make use of the Seam EntityHome objects here and there in the project since it is a comfortable handling of entities and kind of a DAO structure - but how to efficiently work with HomeObjects if not using page parameter?
Would appreciate to some thoughts and experiences from you guys. Thanks a lot.
josh
GET parameters are not inherently unsafe, all REST services rely on data being put in the URL. Parameters (GET or POST) are unsafe if your user detail page, in your example, does not check if you actually have access to user account "12". Also, don't think POST parameters are any harder to manipulate than GET parameters.
So, your code should check if you are entitled to view sensitive data. To handle unauthorized access, you can just throw an org.jboss.seam.security.AuthorizationException in the setUserId() method if the user is setting an ID he is not entitled to. Launching this exception makes Seam follow the exception handling mechanism described in pages.xml (by default it redirects to the /error.xhtml page with an error message).
#In Identity identity; // The standard Seam Identity component
#In Long sessionUserId; // You should outject this during user login
public void setUserId(Long userId) {
// Grant access is user is an admin or his id is the same as the one
// he is trying to set. Otherwise, exception.
if (!identity.hasRole('admin') && !sessionUserId.equals(userId)) {
throw new AuthorizationException("Not authorized");
}
this.userId = userId;
}
Related
I'm making a actions on google project that will use basic functionality of remembering what the user says and using it for another intent.
So for example, this is what the conversation might look like:
1 User: Hello
2 Bot: Hey! What's your name?
3 User: Joel
4 Bot: Your name is Joel, is that correct?
5 User: Yes that is correct
6 Bot: Awesome, it's great to meet you Joel.
I know how to get the information initially, but I am having trouble with getting the information (the name 'Joel') passed to another intent that is used purely for confirmation.
Here is what I have:
app.intent('greeting', (conv, params) => {
const context = conv.contexts.set('context'); // working good
conv.ask(`I got ${params.name}, is that right?`);
});
app.intent('greeting_1', (conv,params) => {
const context1 = conv.contexts.get('context'); //not working
conv.ask(`Awesome, it's great to meet yoy ${params.name}`);
});
If this helps, specifically the error I'm getting reads:
TypeError: Cannot read property 'userDecision' of undefined
How do I get this to work? I have a feeling I have to save the data in userStorage but I've only really had to do that is very basic cases so I'm not to familiar with that.
Thanks for the help!
First of all, hi!
Your initial thought of storing the data in UserStorage might be correct depending on your use case. Let me elaborate:
Two Ways of Saving Data with Actions On Google Node.JS Client Library
Storing Data In A Conversation
You can use conv.data.name = 'Joel' to save the data between the turns of a conversation. But this data won't be available the next time user comes back.
Storing Data Permanently (As Long As The User Allows It)
This is where userStorage comes into play. You can use conv.user.storage.name = 'Joel' to remember the user's name every time they come back. Keep in mind that this type of permanent storage may require consent from the user depending on where they live.
Legal note: Obtaining consent prior to accessing userStorage. Some
countries have regulations that require developers to obtain consent
from the user before they can access, or save certain information
(e.g. personal information) in the userStorage. If you operate in one
of these countries and you want to access, or save such information in
userStorage, you must use the Confirmation helper to ask consent to
the user and obtain the consent before you can start storing such
information in userStorage.
You also need to explain the data you're saving in your Privacy Policy.
As for you specific use case, storing data that won't change (i.e. name) in userStorage is a much better method. Since if you only save it for one conversation, you'll need to ask for permission again the next time.
These should cover your basic needs of saving data on the platform. However, if you do need a more complex state management solution, you may want to check Dialogflow Contexts.
EDIT: I overlooked that you were already using contexts. But the answer still stands, you don't need to use contexts if all you want to do is to save data during a conversation.
But I think the reason you're having a problem is that you're not setting or getting the context parameters correctly. Take a look at the examples here and here:
The context.set() method gets three parameters; name, lifespan and parameters. You're only passing the name of the context in your code.
And, using only contexts.get() method isn't enough to read parameters of a context. You need to read them like this:
app.intent('Tell Greeting', conv => {
const context1 = conv.contexts.get('context1')
const { color, num } = context1.parameters
})
But, I repeat my original point. You shouldn't make things so complicated for yourself if you don't really need to. Try using conv.data and conv.user.storage if possible.
I'm reading tutorials on ASP .NET Core and Razor Pages.
One of them, when dealing with the BindProperty attribute, has remarks I find hardly understandable:
Razor Pages, by default, bind properties only with non-GET verbs.
Binding to properties can reduce the amount of code you have to write.
Binding reduces code by using the same property to render form fields
(<input asp-for="Customer.Name" />) and accept the input.
For security reasons, you must opt in to binding GET request data to
page model properties. Verify user input before mapping it to
properties. Opting in to this behavior is useful when addressing
scenarios which rely on query string or route values.
To bind a property on GET requests, set the [BindProperty] attribute's
SupportsGet property to true: [BindProperty(SupportsGet = true)]
(emphasis mine) Source: Introduction to Razor Pages in ASP.NET Core ยง Writing a basic form
I do not understand. Why do extra security measures need to be taken when dealing specifically with GET requests?
As far as I can tell, GET requests are supposed to be safer, not less safe than POST requests, because GET only retrieves data, while POST sends data to the server. So, more often than not, POST requests need extra security measures GET reqs don't need.
And yet now I'm reading that it's fine to do X with POST but careful, don't do this with GET recklessly, you must opt-in and be warned, take precautions!
Why are these warnings necessary? What kind of security vulnerabilities can be introduced by binding GET request data to page model properties? And why are these vulnerabilites not applicable to POST requests?
Binding is two-way model, meaning it binds a given element for both rendering ("show this value here") and submitting back ("save this value there"). For example, you'd use binding to populate an input field with a value that a user could then update and POST back. Binding handles dealing with the value automatically.
If you simply want to display a value, you don't need to use binding at all. Simply make it a public property of your model and reference it directly ({Model.PropertyName}).
There are a bunch of reasons for avoiding [BindProperty(SupportsGet = true)] but I think HTTP's RFC 7231, Section 9.4 covers it well:
URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead.
Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI.
for hidden field tampering protection: Id, RowVersion, I use a version of Adam Tuliper AntiModelInjection.
I'm currently investigating a way to prevent tampering of valid options found in select lists/drop downs. Consider a multitenant shared database solution where fk isn't safe enough and options are dynamic filtered in cascading dropdowns.
In the old days of ASP.NET webforms, there was viewstate that added tampering prevention for free. How is select list tampering prevention accomplished in ajax era? Is there a general solution by comparing hashes rather than re-fetching option values from database and comparing manually?
Is ViewState relevant in ASP.NET MVC?
If you can, the single solution here is to filter by the current user ids permission to that data, and then those permissions are validated once again on the save.
If this isn't possible (and there are multiple ways server side to accomplish this via things like a CustomerId fk in your records, to adding to a temporary security cache on the server side, etc) , then a client side value can provide an additional option.
If a client side option is provided like was done with Web Forms, then consider encrypting based on their
a.) User id plus another key
b.) SessionId (session must be established ahead of time though or session ids can change per request until session is established by a value stored in the session object.
c.) Some other distinct value
HTTPS is extremely important here so these values aren't sniffed. In addition ideally you want to make them unique per page. That could be the second key in A above. Why? We don't want an attacker to figure out a way to create new records elsewhere in your web app and be able to figure out what the hashes or encrypted values are for 1,2,3,4,5,6,etc and create essentially a rainbow table of values to fake.
Leblanc, in my experience, client side validation has been used mostly for user convenience. Not having to POST, to only then find out that something is wrong.
Final validation needs to occurs in the server side, away from the ability to manipulate HTML. Common users will not go on to temper with select lists and drop downs. This is done by people trying to break your page or get illegal access to data. I guess my point is final security needs to exist in the server, instead of the client side.
I think a global solution could be created given a few assumptions. Before i build anything I'll like to propose an open solution to see if anyone can find flaws or potential problems.
Given all dropdowns retrieve their data remotely. - in an ajax era and with cascading boxes this is now more common. (We are using kendo dropdowns.)
public SelectList GetLocations(int dependantarg);
The SelectList will be returned back as json - but not before having newtonsoft serialization converter automatically inject: (done at global level)
EncryptedAndSigned property to the json. This property will contain a Serialized version of the full SelectList containing all valid values that is also encrypted.
EncryptedName property to the json. This property will have the controller actionname - For this example the EncryptedName value would be "GetLocations"
When the http post is made EncryptedName : EncryptedAndSigned must be sent in the post also. For this JSON POST example it would be:
{
Location_Id: 4,
GetLocations: 'EncryptedAndSigned value'
}
On the server side:
[ValidateOptionInjection("GetLocations","Location_Id")
public ActionResult Update(Case case)
{
//access case.Location_Id safety knowing that this was a valid option available to the user.
}
I have created a custom User profile template and object in the core database in Sitecore (as per the Security API Cookbook).
I can select this programmatically (as per the Security API Cookbook) so that my extranet users have an extended profile, that covers all the usual suspects (Address, phone, email format etc.)
However, where is this data stored? And how do I access it if I want to query the database to return a subset of users based on this profile data.
A typical requirement for an extranet member system is to extract a list of users to contact either in an email or a phone type campaign. Can this be done with the Sitecore membership system?
UPDATE>
I'm going to take a guess and say the profile data is stored in aspnet_Profile.PropertyValuesBinary .. which would make it nigh on impossible to query and not suited to my purpose. That is unfortunate. So to extend my question, if that is the case, is it possible to get Sitecore to store those values in the text field so they are searchable?
The standard Microsoft implementation of the SqlProfileProvider (which is used in Sitecore by default) stores the user profile information in the aspnet_Profile table. All the properties are serialized into the PropertyNames / PropertyValuesString columns. The PropertyValuesBinary is used to store the binary data (images). You can find more details if you look at the code of System.Web.Profile.SqlProfileProvider, SetPropertyValues method.
Next, all the custom properties you define in the user profile, are serialized to the SerializedData property of the Profile class, and it is again serialized to the PropertyNames / PropertyValuesString columns like any other property.
Also, couple of properties are stored in aspnet_Membership table (for some reason) - Email and Comment.
So, if you are going to query the users by Email, you can use FindUsersByEmail method of MembershipProvider. Otherwise, if you plan to filter by another property value, I suppose, you'll have to get all users and filter the obtained collection.
Hope this helps.
I faced this exact problem last week, didn't come up with a permanent solution, but to solve my particular issue, I wrote a little helper page and added it as a Sitecore application to be accessed from the CMS interface. All it did was query all users, and determine if they had any of like 5-6 profile properties assigned.
var userList = Sitecore.Security.Accounts.UserManager.GetUsers();
That is the relevant line to grab the users, it returns Sitecore.Common.IFilterable
So if you need to do something where you're grabbing profile info from all users, you cn do something like this:
foreach (Sitecore.Security.Accounts.User user in userList)
{
Sitecore.Security.UserProfile profile = user.Profile;
string whatever = profile["Whatever"];
//add whatever to a list or something
}
This worked out very well for my purposes, but I don't know how feasible it will be in your situation.
I'm searching for the best way to handle view-level authorization (where you hide markup based on a user's roles).
The typical way to do this is with the Acegi Security authz tag, as follows:
<authz:authorize ifAnyGranted="ROLE_FOO, ROLE_BAR, ROLE_BLAH">
<!-- protected content here -->
</authz:authorize>
The problem with that approach is that it quickly gets messy. For one, you either hard code the user roles as above or you create a constants file that duplicates them all. Second, there's no way with the current scheme to group roles logically. I suppose one solution is to define a separate role for each UI element, but then the declarative method level security on the business methods would need to be updated for each UI element (would that be a good thing?). This would also cause a proliferation of user roles! The use cases for my application actually mandate very few, e.g., Manager, Manager Supervisor, Super User (can do everything), Read Only, etc.
The solution that comes to mind is to treat the authorizable UI elements similar to message resources. That is, define a series of "authorization points" in a properties file similar to a MessageResources file. My initial thoughts are as follows:
com.lingoswap.home.editUserNameButton.ifAnyGranted=ROLE_FOO, ROLE_BAR, ROLE_BLAH
com.lingoswap.home.deleteAccountButton.ifNotGranted=ROLE_NOOB
com.lingoswap.home.deleteAccountButton.ifAnyGranted=ROLE_ADMIN
...
To protect content on the home page, we would then use a different protected tag (one that borrowed heavily from the original authz, possibly a sub class):
<security:protect component="com.lingoswap.home.editUserNameButton">
<!-- edit user name button -->
</security:protect>
<security:protect component="com.lingoswap.deleteAccountButton">
<!-- show the awesome delete account button that's not for nincompoops -->
</security:protect>
The advantages to this approach are the following:
Easy to test - we can write unit tests that verify the user-role-to-ui-element mappings (of course, it still has to be used on JSPs)
Error checking at runtime (and test time) - if a user role is misspelled in the .properties file, we can throw an Exception
Easy to tweak user roles - the requirements team continually refines the user roles; it'd be nice to change them all in one central location
Easy to understand - we can at a glance view the user role permissions for the entire application
Can be done DRYly (using property Spring placeholders to group related roles, e.g., ${readOnlyGroup} can be used in the properties file instead of the actual role names
The disadvantages seem to be:
Moderate complexity
Others??
Thanks for your advice.
Regards,
LES2
I did somethig similar to the second approach. And because I wanted all my security definitions in one place I implemented my own objectDefinitionSource for the FilterSecurityInterceptor.