Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am fairly new to MVC and am interested in keeping my MVC app secure. One of my concern areas, for example, is an Approve page that is available to uses to approve items that are up for review. The issue is that certain users can only approve certain items. When approving the app posts the ID of the item being approved to an ApproveItem ActionResult in the controller. The issue is that in theory (e.g. with FireBug) someone might post random IDs to this ApproveItem controller (including items that they might not be allowed to approve). Instead of trying to catch every issue like this in filtering, why not just use a GUID as the ID? Then I am almost 100% certain that the user is only approving an item that they are allowed to approve.
What do you guys use for security in regard to situations like this? It seems to me that a GUID would be the simplest. What do you think?
Your question (or at least the tile) doesn't really make sense. You can use Guids for Globally Unique Identifers within a security system, but you shouldn't use them AS the security system.
#ePezhman alludes to a potential Insecure Direct Object Reference vulnerability but this isn't an issue if you are correctly validating your users` actions.
What you're suggesting is Security through obscurity. Your app isn't actually secure, it's just really hard to guess some naughty input. What you should be doing is what you're trying to avoid and validate that the current user has the required permissions to perform the action on the entity. That is, is the user allowed to approve the item? and if they aren't you should display an error message or take other appropriate action (logging the attempt, notifying an administrator etc?).
GUID will be very simplest way to achieve this.
Otherwise you can go for "person -roles " level security to approve your items.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
The full rule is the following:
Apps that display user generated content must include a method for
filtering objectionable material, a mechanism for users to flag
offensive content, and the ability to block abusive users from the service
My app does feature user generated content. I have a feature that enables users to flag a post if they find it objectionable. I receive notifications in the database when this happens, and I personally judge if the content should be deleted or not. However, there is no feature that enables a user to block another user directly. There is no "following" or "friend requests" in my app, it is more like a communal forum where you read others content and can post your own content, but don't directly follow others.
my method of blocking others from the service is deleting user accounts and their associated posts from the database. Is what I have enough? I find the wording kind of ambiguous in the guidelines.
The accepted answer is no longer true. I just had an app rejected because there is no mechanism for users to block other users. We already have a user-driven content flagging system, and demonstrated that there was a process in place for reviewing and removing objectionable content and blocking abusive users from the service altogether, but Apple said:
In addition to the reporting mechanism, it would be appropriate to implement a separate blocking mechanism that allows a user to block abusive users.
…where “it would be appropriate to” apparently means “your app is rejected until you.”
We indicated that our staff block users from the whole service if they post abusive content, but Apple says that this is not sufficient; users must now be able to directly block each other.
This is section 1.2 of the updated review guidelines.
You'll be okay. Our team created an app which allowed users to post video content in a communal context. We were required to implement a flagging system (which it sounds like you have), and show that we had a process in place to deal with the flagged content. Once we did that, we were approved.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
Background:
I'm creating an e-commerce controller that has subscription plans to sign-up for.
Step 1: A user picks a plan.
Step 2: Then enters in their credit card info.
Those actions reside in one controller, and that controller will also have actions such as
edit credit card info
changing their subscription plan
canceling a plan, etc.
Problem Statement:
I want to redirect all of the actions in the controller except picking a plan if the user hasn't picked a plan yet.
Example:
In the UI the user will see links for their billing information and subscription settings, but if they click on those links and they don't have a plan picked yet they get redirected to the action/page to pick a plan.
Question
Is a filter the best place to handle that scenario, and if so how would it be coded?
Is there a better way other than using filters?
What I don't want is to put at the beginning of each action an if statement that checks if the user has a plan, and if they don't redirect them to the pick-a-plan page. Seems like there would be a better way.
I think that in this case a Filter can do the work pretty easilly.
A filter similar to the following one should do the trick:
class MyFilter{
exceptPlan(controller:'myController',action:'pickPlan', invert:true){
before = {
if (!session.plan){
redirect action:'pickPlan'
return false
}
}
}
}
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
So I have this web app that in theory may one day become a for-pay application - if anyone actually finds it useful and worth it.
I have all the logic to handle payment, check to see if the account is overdue etc. in place. It is all stored in RavenDB (RavenHQ actually) - not that this should matter to the question at hand.
Now, I am trying to follow best practices, and I want my application to be performant, i.e. not micro-optimizing, but I want to do things in a way that will scale relatively well with load (if it takes off it will be hosted - I would love to not have to pay for more servers than is strictly necessary).
My app uses something close to the default login/account model. Users log in securely using forms authentication over https.
At what point should I check that a user is actually allowed (with regards to payment status etc - a domain model concern really) to be using the web application? Consider that this will mean requesting a single document from the RavenDB backend and checking if the current payment period has expired.
Should I:
Check every time the user logs in, and make them unable to "Remember me" for more than x hours, where x is a relatively small number?
Check in a few central controller actions that the user would visit relatively often - the application would essentially be severely restricted if these actions were not available.
Do a global action filter that checks for every request, then redirects to the "Pay nooooow!" page as soon as stuff expires?
Another option?
RavenDB does clever caching, so I don't think a request for this document would kill performance, but should the application really take off (unlikely, but one can dream), an extra database request per http request will probably lead to Ayende hunting me down and mercilessly beating me. I don't want that.
It seems to me like this is something that others would have thought about and solved, so I am asking - what would be the right way to handle this?
Thanks for any insights!
I don't think this is a framework issue strictly, it's more like how you want your site to behave and then use framework to support it. Generally speaking you want to make the site usable and not too restrictive unless when that's necessary, e.g. surfing the site with no restriction whatsoever, but checking out should be done very securely.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm still learning Rails and how to best design my resource structure. Could someone help me with this? Here's my problem:
I am designing a specialized social network with profiles - every account has one profile. At the moment, an Account stores basic info about the user (username, password, etc.) from when they first sign up. A Profile stores other thinks like a picture link, answers to personality questions (linked back to a Profile via foreign key), and maybe more in the future. There is a one-to-one relationship between Account and Profile. Users can view/edit their own profile and view profiles belonging to others.
My questions:
Is it a good idea to split these two into separate resources altogether (i.e. have two different models) or collapse them into one model with two controllers? I have tried the latter, and it almost seems like more trouble than it's worth. Am I, in this case, fighting against the framework? I'm not sure yet whether users should be able to have more than one account in the future.
If I do split them, should I use a singular or plural resource for the profile? I noticed in the language at guide.rubyonrails.org that get (show) and put (update) work with the ONE and ONLY profile resource. My question with respect to my current situation is: "one and only" with respect to what? The "one and only" profile for the current user's account or with respect to the entire site? If so, how could I have the current user view profiles of other users - should I use a URL parameter like so:
http://www.example.com/profile?id=x, where x is the other user's account id
If I go the plural route, does index showing "all profiles" intend to mean all for the current user or for everyone across the site? Or is this up to my own interpretation?
I would appreciate any help I can get with this, as I feel like I am starting to understand REST and RoR conceptually but am just trying to put it into practice. Thanks!
I would personally keep Account and profile as two separate resources or at the lest 2 separate controllers accessing different parts of the same model.
This allows easy routes like http://www.example.com/profiles/2 for viewing other users and http://www.example.com/accounts/2 for managing your own account without having to add custom routes.
If you have the possibility of adding more profiles to an account, then this is a form of future proofing too.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I know you should use POST whenever data will be modified on a public website. There are several reasons including the fact that search engines will follow all the links and modify the data.
My question is do you think it is OK to use GET behind authenticated pages in something like an admin interface?
One example would be a list of products with a delete link on each row. Since the only way to get to the page is if you are logged in, is there any harm in just using a link with the product ID in the query string?
Elaboration for comments:
I personally don't have any issues or difficulties in implementing the deletes with POST. I have just seen several examples of code in ASP.NET and ASP.NET MVC for "admin like" pages that use GET instead of POST. I am curious about peoples' opinion on the matter.
The temptation of using GETs is that you can create a bunch of delete links without creating dozens of forms per page, or resorting to JavaScript. Yet for various reasons that have already been mentioned, the web depends on GETs not being destructive.
The best practice, if generating one tiny form per delete link in on server is impractical, is to use a GET link to load up a confirmation page from the server which has a POST form that performs the delete. Then do some progressive enhancement:
Delete
If the server gets a GET to /controller/delete/x then serve up a confirmation page with a POST form. If the server gets a POST (or maybe a DELETE) request then do the deletion.
Some people learned some time ago that it's a very bad idea.
Google launched a new app to "speed up browsing" (Google Web Accelerator) that prefetched the linked pages in the browser (no attacks, no third party...), and when someone logged to such protected pages, well the app looked at all those links and said: "Hey, I'll prefetch those ones also because that way I have the page ready when the user requests it"
They have changed the behavior, but anyone can do anything similar any day.
It is still bad practice to use GET for destructive operations - even if it is hidden behind authentication - as it makes it possible (easier?) for someone with knowledge of that URL to exploit it (for example, using XSS). And of course, it is a bad design/coding practice as well, especially if you are trying to create a RESTful service.
There are probably many other reasons as well...
GET ought to be used to retrieve data idempotently and POST ought to be used to update data non-idempotently. That's all. It's certainly not a "best practice" to interchange the methods.
As to XSS and CSRF risks, to prevent the one just HTML-escape any user-controlled input during (re)displaying and to prevent the other just make use of request based tokens and/or captchas.
Yes.
Code may rely (correctly) on GET not being destructive. That code could run in the browser, and thus will be authenticated (link prefetching comes to mind).
It would be a bad practice to delete data based on a GET request. Technically, you can do it, but you'll be out of sync with most well written websites. You are basically creating a new set of rules for your user interface if your use GET requets for deletes. I consider the URLs of your website part of the user interface. If you sent somebody a link like http://www.fakesite.site/posts/delete?ID=1, they would expect to be displayed a page asking if they want to delete post with ID #1, not perform the actual delete.
I do this on pages where I know someone is logged in and I can verify the users right to delete something based on other data which I keep in my session. I would suggest adding a confirmation step: "are you sure you want to delete this thingy?"
GET and POST are very, very similar except for the fact that GETs have a limit on the length of the HTTP action because they are all URL based.
Since you won't be providing access to people who haven't authenticated I don't believe using gets is problematic.